Linda Walsh wrote:
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.
In your original post, you, perhaps inadvertently, implied that the machine couldn't be taken offline to do a fresh install.
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).
Wholesale replacement of basic system libraries will end in utter chaos, as the install system nees the new libraries, and the older software needs the old libraries.
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 your in-place software forks off ANY child processes, and their required libraries are missing, the whole server is going to be worthless for the rest of your installation procedure anyways.
If you weren't installing a kernel, changing hardware or reformatting the system disk, you didn't need to reboot.
Updating a kernel compiled against the same libraries is significantly different than upgrading all of the libraries. 1. The new kernel is only copied into place...it doesn't become active until AFTER the reboot. 2. Replaced libraries (old ones removed) causes significant chaos -- the reason is that the system is "live"...and the old executables are expecting the old libraries, not the replacement libraries. I once made the mistake of trying to upgrade glibc5 to glibc6. The result was not pleasant. And I've been a *nix person since the early 1980's.
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. :-( ( :-))
This is an entirely different problem.
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.
glibc is not considered to be "user level software". It's intrinsic to nearly everything except the kernel itself, and that ONLY because the kernel statically links whatever it needs.
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?
In every place I've ever worked "why not upgrade?" is not a sufficient reason to upgrade a server. If it's doing what it needs to do, then there's no reason to upgrade. On the other hand, if there is some new functionality which can be obtained by upgrading, then do it. But, also, at every place I've ever been at, when an upgrade of that sort comes around, it's not done on a production machine while it's in use. The upgrade is FIRST done on a test machine, and tested for days to weeks. Once the test configuration is approved, THEN it's put onto the production machine. If you were using industry standard testing procedures, you would have worked out this upgrade process already on the non-production machine, and therefore, wouldn't be asking this question on this list. So, in summary, your company needs to become acquianted with the concept of "test platform" vs "production platform" Untested installations, and especially upgrade procedures are NEVER done on a production machine. That's *WHY* you should have test machines.
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?
Are you finding software bugs in your 9.3 software?
If its not broke, don't fix it.
Not a bad sentiment, but this is the computer industry.
Same holds true. One Fortune 50 company I worked at had an HP-UX server which was so old HP sent us a letter telling us that this particular machine would no longer be covered under the site maintenance contract, because the hardware was more than 10 years old. Upgrading IT solely for the purpose of upgrading is one of the surest ways to cause chaos in the workplace -- AND make the I.T. people look really, REALLY bad. Generally, you keep all your platforms on a "known good" version of the O.S. unless a new release of an app fixes a bug, or offers a new NEEDED capability, **AND** that new software release is not offered on the currently installed version of the O.S.
You either move ahead, or get left behind. Take your pick. I
Plenty of Fortune 500 companies are maintaining their market competitiveness without striving to maintain "bleeding edge" modernity in their IT shop. Business and business reasons ALONE determine when to upgrade. Stop viewing the OS installation as a fashion statement. Your girlfriends at the bar aren't going to be whispering to each other, "Can you BELIEVE it...she's using LAST SPRING's software."
choose to move ahead -- on my schedule when its convenient for me.
That's the wrong schedule. You need to do it when it's convenient for the business. That's why you're employed.
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.
IF it's necessary to upgrade this machine now, then you need to hop on a plane, and do this upgrade properly. At this point, I'm leaving the remaining 50% of this unaddressed, because I have other things I need to do. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org