I realized you don't know what you're talking about right here. It would take until the heat death of the universe to brute force a 128-bit AES key.
Seems like you're making an assumption that AES itself hasn't been backdoored and that the implementation of the same is also correct, neither of which I would assume. Steve
My first question is: Why? Why, if they're both hateful and fearful of change, would they need to change? Why not a newer version of Windows or a Mac?
Users aren't oriented towards their OS, they're oriented towards their tasks. Their typical question will begin with "How do I..." and then continue into "but then how do I...". So your first issue is to determine what they use and how they use it and then find out the best way to solve each of those individual use cases or problems. For example, "How do I manage my finances, I currently use Quicken?" or "How do I upload pictures from my camera?". You need to solve each of those use cases in a sane manner that's easy to use and just as good or better than what they have. Typical users, especially the ones you describe, don't want to spend any more time with their computer than they need to.
Don't underestimate a user's ability to forget things that they do on their computer. Again, they're task-oriented and so they won't necessarily remember that they need a certain program to update some infrequently used spreadsheet twice a year.
Only if you can help them complete their tasks should you switch; you shouldn't switch them to Linux because you perceive it as better; it might not be better for them and then they'll have a tainted view of Linux when in fact the problem was that they couldn't use their silly banner-creation software from 1999 on it.
It helps Mozilla by reducing the amount of code they have to maintain at one time. With a six-week release schedule, if they had to maintain each version for a year, they'd end up supporting eight or nine version simultaneously.
But it's simply not realistic for the software to change significantly in 6 weeks. Web standards don't change that much in 6 weeks to warrant this much changing in the browser. Therefore, they're supporting largely the same codebase for months and months, same as before. At some point they add major new features and these are the ones that should get the new major version number.
Simply incrementing the major version every 6 weeks will hurt Mozilla and Firefox.
Can you cite any examples where something worked in Firefox 4 but not Firefox 5?
Asking what is broken within *this* particular version is completely missing the point. The point is that someone needs to now go back to their PHB and say that FF is now at new version. Resources for the business need to be taken to examine what changed and how those changed bits will affect the organization's web site. And now this process needs to be repeated every six weeks.
At some point, something major *will* change between versions. In the past, one could look at it and say "ok, version 4.0.1 came out, probably just addressed something minor. Version 5 just came out, must be a major new release, we should look at what changed." The new numbering scheme and release schedule makes it much more time consuming to support Firefox because now every release needs to be examined with the care and attention previously only reserved for major versions.
Well-publicized schedule? New version every 6 weeks.
You missed the word "sane" in my post. Six weeks != sane release schedule for major versions of this software. And yes, the version number incrementing *does* indicate a major version.
You're right again in that people don't want to update their software, that's why Firefox (again like Chrome) does it automatically.
Hmm. Not sure if FF actually does update automatically between major versions, I didn't think so. In any event, major version changes in Firefox have broken add-ons which is a failure for the user.
I don't care if Mozilla releases every 6 weeks, every 3 weeks, or every 3 hours. I do care about supporting the browser on multiple web sites and having to work with developers and users alike. Keeping the version numbers on a major/minor/bug fix scheme actually does work; it wasn't a broken model. This version number bouncing is not for the benefit of the user. Seems to be Mozilla with a case of version number envy; their number is smaller than IE and Chrome and they want to fix it, regardless of whether it benefits anyone.
Who, exactly, is the rapid release schedule helping? It's certainly not helping web developers and organizations who try to list their supported browser versions and actually try to code towards those versions. The quickest path to get the corporate PHBs to stop supporting your browser is to have the IT staff say "Guess what, the next version of Firefox is already out so we need to make updates." At some places, support for browsers other than IE is tenuous at best, so making it more difficult to support these browsers only hurts the browser manufacturers.
Want to gain more support? Release a stable product, with wide support for standards and add-ons, and do so on a sane, well-publicized schedule. People don't care about version numbers; updating software isn't something people want or like to do. Why are you making it more difficult and cumbersome for users to use your product?
Doubt is not a pleasant condition, but certainty is absurd. - Voltaire