Ric Moore <[email protected]> wrote:
That approach worked a lot better before X. Something like the change
from XFree86 to X.org screws everything up since a lot of users like
WIMP interfaces. Same for any significant change to the GUI.
On Sun, 2006-10-29 at 20:44 -0700, David G. Miller wrote:
Works well for user apps but I lived through the evolution of ipfwadm ->
ipchains -> iptables. Need to be careful with system stuff. It would
be nice to see core functionality supported for upgrades even if every
oddball app isn't. One of the arguments against supporting upgrades is,
"if it ain't broke, don't fix it." That is, once a release supports a
platform, why change. As with my laptop example, there are good reasons
to upgrade from an OS release that only marginally supports a hardware
platform to one that fully supports it. Let's hope somebody at
All the more reason to use the old timey /usr/local system
upgrades won't touch it. Maybe we need to adjust our tinfoil and go
retro, the old timers had methodologies that may need revisiting. Ric
It would be nice to see something like:
1) Critical system functionality -> gets upgraded.
2) Common applications -> upgraded or at least at reasonable stab at it.
3) Other stuff -> install new config and save the old as rpmsave.
The goal would be that a functioning system gets upgraded to the new OS
release that, for the most part, works. That is, everything works but
it's possible that some settings are left to the admin/user to bring
Politics, n. Strife of interests masquerading as a contest of principles.
-- Ambrose Bierce