John Andersen wrote:
Huge overwrought rant snipped...
Now lets suppose it was a power supply, or a memory module. What then?
If this machine is so sensitive
You seem to be really scared of some bogeyman that doesn't exist. Who are you writing to or about? I never said anything about a sensitive machine. If my desktop was to go out randomly for a day or weeks due to attempts to make a "complete" upgrade work, it wouldn't be acceptable either.
If this machine can't be taken off line
Another bogeyman -- no one said the machine couldn't be taken offline for a kernel reboot or hardware upgrade. I asked a hard technical question, maybe that triggered your way-off-base rant: If the kernel of an Operating system can be replaced while running, then what possible program above the kernel can't be hot-upgraded (i.e. without taking the machine down). If there is any rant, maybe this is it. When Windows 95, 98 and ME came out -- it was a running source of amusement about how primitive Windows was because it required rebooting on not, just OS updates, but even user-level software. Among unix users, it was considered a primitive throw-back -- because unix users never got a "Permission Denied" message when deleting or renaming a file they had access to. It's long been a bug-a-boo on Windows; not being able to delete "in-use" files -- making updates famously difficult! It's A BUG!!! Not a feature! If you weren't installing a kernel, changing hardware or reformatting the system disk, you didn't need to reboot. Then along unix's and linux's on the PC. On PC's people were "used" to the need to reboot when installing software. So for some reason, most of the PC-*nix distributions unconsciously(?) leaned toward Microsoft as a model for how to do things on the PC. Unfortunately, instead of bringing unix ways to the PC ("we don't need no stinkin' reboots for no userspace-update badges"), MS seduced them unto the dumb side of software updating. :-( ( :-))
why don't you have a hot spare?
How does a hot spare allow upgrading a few (or one) package at a time on a live machine to see how it runs with your live configuration? Or how does it help upgrading, testing and verifying one package or one package group at a time? How can one consider it more user-friendly to force users into a full update rather than allowing incremental upgrades of only the packages they need? Why replace everything if most of everything is working? Why not just add or replace the one new package you are interested in? But maybe most important: How does install a hot-spare while logged in *remotely* (as mentioned in the base-note) over ssh?
You want to go from 9.3 to 10.3, seamlessly, on a machine that (by all accounts) hasn't been down for more then a heartbeat since 9.3!?!
Seemlessly? Hasn't been down since 9.3? Oh no! More scary bogeymen!! Dude, chill out, pop a reality pill. Those are your personal demons and projections. I think the longest thisi machine has been up, non-interrupted, has been around 8 months. At the very least, there are kernel's that come out and need to be upgraded to. But even in the kernel world, responsible software (kernel) engineers are addressing that problem. They aren't ranting about users not wanting to have to be down for software updates -- they are going one better -- kernel replacement with out reboots! I'll say it again -- the only software that was famously known for requiring reboots for user-level software was Windows 95 and 98. That's not a standard to strive for.
Why? What ever for? [go from 9.3 to 10.3]
Why not? If I can do it one package at a time and not experience any downtime, It might go better with the usually, shiny new kernels that come out regularly w/better hardware support, more efficient algorithms, etc. Or are you trying to make the case that there are no improvements in 10.3 vs. 9.3 worth upgrading for? If I find a bug in a software program, wouldn't it be more productive to report that bug against 10.3? Do you think reporting a bug against 9.3 would even be accepted, let alone useful?
If its not broke, don't fix it.
Not a bad sentiment, but this is the computer industry. You either move ahead, or get left behind. Take your pick. I choose to move ahead -- on my schedule when its convenient for me. You seem to feel that one should be a slave to the Distro's schedule and jump on every update in the prescribed manner. How quaint. In the real world, business schedules or practices don't and shouldn't be forced to revolve around a distro maker's release schedule.
Prepare its replacement, but leave it the hell alone, and don't try upgrading in place across a compiler change, 3 (or was it 4) kernel changes, disk driver changes, USB changes, etc, etc, etc.
??? Why not? It's a great machine -- the hardware started with P-II/450's, but allowed upgrading to dual P-III/1G -- why I upgrade hardware and software to squeeze a longer life out of the HW? That's what linux does! It might not be sufficient for a state-of-the-art desktop, but for a disk-server....she's doing great! From 7.2KATA to 15K-SCSI driven, with over a Terabyte of PATA space and a SATA controller& drive waiting in the wings. If I don't upgrade the software, how will I support the newer hardware? Even the network -- from built-in 100Mb (now disabled), to running a dual 1Gb -- it's been tuned to serve up disk material faster than many laptop drives through the early "aught's".
You've already waited TOO LONG to be ranting at others for poor planning or weak upgrade abilities.
Too late -- to want good software? Yeah...but "ranting at others" about it? Dude, it's your veins that are poppin' off your head. Cut back on the testosterone pills and reread my original note. There's no rant.
You're the one in trouble here, do to your own mismanagement and absence of planning. Try to remember the 6 Ps: Prior Planning Prevents Piss Pour Performance.
I think you're focused on the one "P": preaching. You seem to have a need to create crises where there are none, so you can get up on a soap-box and self-aggrandize while tilting at windmills (and bogeymen). I am in no trouble (at least not related to hardware upgrades...:-), and there has been no mismanagement. Quite the opposite. There has been deliberate planning *NOT* to upgrade every to every new release due based on stability concerns. You are either incredibly naive or sadistic if you think people should be on the "alpha-test-train" by being the first on their blocks to upgrade to each new version. Sorry dude, but 10.0 sucked. So did 10.1. 10.2 at least "worked" but wasn't a net benefit over 9.3. 10.3 is the first version that was stable enough to warrant an upgrade consideration (and about time, had been concerned about the future of promoting SuSE as a best-of- breed linux, as I've done since my trying it in the 7.x time frame. In case you hadn't noticed, customers aren't leaping to install Vista over the top of XP, either -- because XP is _still_ a superior product in nearly every respect. Customers should be allowed to upgrade on their schedule -- not yours, and not the OS-manufacturer's. Congress should pass a law requiring a release of sources for widely used, manufacturer-abandoned software. It's potentially a country-wide IT infrastructure stability and productivity issue. The customers should be allowed to do their own planning rather than living by some externally imposed event -- especially in a slowing economy, where software 'giants' may try to squeeze income out of customers who's businesses would be better off staying put for the time being. I've wasted too much time indulging your created bogeyman foolishness. There is no hardware crisis or "can't be down" crisis -- you made those up in response to what I can only assume are your personal "issues". My only preference is for software-updates not requiring a machine's unnecessary downtime. It's not like it can't be done -- and has not already been done by me scores of times before and hundreds of others of computer scientists managing their own hardware. It may not be your idea of standard "IT" practice for the non-computer literate masses, but that's not me. Go back and reread the base note. I asked if anyone else did what I did and if there were already tools to do or assist in what I was doing. I was asking if anyone else who did as I did might find such tools useful... and that I had begun work on some of my own helper-scripts to help me do some of the 'research' leg-work needed with such upgrades. As for conflicting versions of compiler and glib versions -- EVEN WINDOWS XP in 2001 supported side-by-side dynamic linking with different versions of libraries in memory at the same time for different applications. And where is linux in this "ease of use issue?" I mention in passing that I find the Distro support for updates to be poor -- only supporting upgrades from the immediately previous version (even MS doesn't stoop so low these days), and forcing a user to take a computer "off-line" and be physically present to shuffle DVD's, CD's or floppies -- PC-console only maintenance was (is) a BAD feature of PC-based software. Remote system administration (including software updates), was long considered a strength of Unix...to remind people of that is a *good thing*. Linux should be able to be managed (and updated) remotely. If it can't, it's little better than Windows management. While a windows admin can effectively admin ~20-30 machines in their domain, a unix or linux admin can as easily deal with 2-3x as many due to remote administration. Being forced to walk around to each computer and take it offline to babysit offline-updates is a major step backwards. The main issues here are being able to do selective package updates, as a way of upgrading a machine "over time", remotely, vs. taking it down and forcing me to babysit a computer install process. The computer is there to serve ME, not the other way around. How long have you been in submission to the tyranny of the server or the distro update? I wonder if this is a good basis for another IBM Blade server commercial....the overweight Dilbertian manager type is all apoplectic about his servers' requirements and doing things when the servers' tell him to...when they say jump, when their Distro vendors say jump...etc. Get off the Distro-Beta treadmill. Upgrade when *you* want to and when it's right for your business. Hmmm...maybe I should try my hand at writing ad-copy in my spare time... :-) -l -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org