| |||||||||||||
|
| |||||||||||||
The end of the road for Firefox 2The end of the road for Firefox 2Posted Nov 6, 2008 4:42 UTC (Thu) by afalko (subscriber, #37028)In reply to: The end of the road for Firefox 2 by walken Parent article: The end of the road for Firefox 2
I too have not upgraded for this reason. In my case, I'm a Gentoo user who is only updating his systems for security updates only. Firefox2 is so perfect for me I have no motivation to risk breaking the stability of my system and browsing experience for feature I'm happy without.
(Log in to post comments)
The end of the road for Firefox 2 Posted Nov 6, 2008 8:48 UTC (Thu) by Los__D (subscriber, #15263) [Link]
Well, if security updates is a feature you are happy without, by all means, stay with FF2
The end of the road for Firefox 2 Posted Nov 6, 2008 9:03 UTC (Thu) by walken (subscriber, #7089) [Link]
No, I expect that debian will release lenny before security updates are dropped on ff2. And if lenny gets delayed, I expect debian will make a decision and either upgrade firefox in an etch dot-release, or decide to handle security updates themselves somehow.
Yeah, I'm a true debian believer :)
The end of the road for Firefox 2 Posted Nov 6, 2008 9:15 UTC (Thu) by Los__D (subscriber, #15263) [Link]
Hehe, they'll probably be ready.
My response was mostly to afalko, whose situation doesn't really strike me as similar to yours, but more to good old "it ain't broken...".
The end of the road for Firefox 2 Posted Nov 6, 2008 10:01 UTC (Thu) by NAR (subscriber, #1313) [Link]
Given that upgrades in general (and Linux upgrades in particular) have a tendency to break working systems, I think it's a perfectly reasonable stance...
The end of the road for Firefox 2 Posted Nov 6, 2008 10:13 UTC (Thu) by Los__D (subscriber, #15263) [Link]
Of course it is.
- If you don't find security updates to your browser important (which there certainly is valid reasons not to).
The end of the road for Firefox 2 Posted Nov 6, 2008 17:47 UTC (Thu) by afalko (subscriber, #37028) [Link]
I did not mean that security updates were not important. FF2 is still supported atm. If it happens to become unsupported, no problem, I'll upgrade to FF3 and adapt to the changes, good or bad.
I used live by the motto, "If its broken fix it, if it works breaks it." But that was when I didn't have real work to do --- at least not that important or computer dependent work. Now I live by "if its working, don't break it, if its broken (I consider something with a security hole to be broken), try to fix it without turning the entire system upside down".
The end of the road for Firefox 2 Posted Nov 7, 2008 11:55 UTC (Fri) by Los__D (subscriber, #15263) [Link]
Ah, then we are in complete agreement :)
"If it ain't broke" --- test it? Posted Nov 6, 2008 21:01 UTC (Thu) by AnswerGuy (guest, #1256) [Link]
The old sysadmin adage: "if it ain't broke, don't fix it!" hinges on the assumption that we would know if it's "broke"[sic].
Security issues are the obvious and dangerous counter example to this assumption. If there's a vulnerability then a subtle attacker may be exploiting it for arbitrary lengths of time without exposing the breakage to their victims.
Frequently the sysadmin is also extending this philosophy to the next logical adage ... "better the devil you know ..."
To mitigate the risks posed by upgrading (the upgrade will break stuff) perhaps we'd be better off asking how we can effectively adopt some analog to the "test driven development" model which is the heart of agile programming methodologies.
How could we automate a test suite of the functionality of our systems so that we could deploy a set of changes (upgrades, new package installations, configuration changes, etc) with confidence that nothing (that we tested for) was broken in the process.
First we have to have a way to rollback from our changes.
The old brute force method is to swap out whole (spare) machines or hard drives ... restore the existing system (or replicate it) ... then deploy the changes. There the rollback is to switch back to the primary (non-spare) system or hard drives. (This is a simplification since we also must be aware of the changes that may have occurred to "live" (production) data during the testing --- that can be arbitrarily complicated for specific applications).
It may be possible to use LVM snapshotting as a more elegant and far more lightweight alternative to wholesale drive/system replacement. I would love to see a good HOWTO covering that process.
Next we need a framework for running our tests.
For servers the functionality tests can start with the same tools we use for monitoring our services. So if we have reasonable coverage through things like Nagios then we should be able to add the test system to the monitoring system fairly easily ---- and see alerts for any service that's obviously broken.
However this only tests for obvious breakage. Monitoring systems are designed to and tune to minimize load, for example. So if our system under test has capacity handling issue --- if the upgrades would make our new copy of BIND fall over when all our systems are hammering on it for DNS requests ... or (more likely) our LDAP server upgrades kill the LDAP performance under high load (or truncate bulk queries, or whatever) ... these or things that have to be tested for separately.
So we need a suite of capacity/load tests.
Testing for workstations for user/interactive issues is far trickier.
Ideally we should work with the upstream maintainers to help develop test suites ... those can be used during development, after packaging, and by distribution maintainers to test for integration issues (things that only show up when combining the packages with others in the same distribution) ... and finally these could be packaged up so that savvy sysadmins could re-use them to test for deployment issues.
What I'm proposing is that we build "soup to nuts" testing to catch issues at any stage from development to deployment.
And I know it's not gonna happen overnight.
|
|
||||||||||||