Slashdot Mirror
No More Need To Reboot Fedora w/ Ksplice
An anonymous reader writes "Ksplice, the technology that allows Linux kernel updates without a reboot, is now free for users of the Fedora distribution. Using Ksplice is like 'replacing your car's engine while speeding down the highway,' and it can potentially save your Linux systems from a lot of downtime. Since Fedora users often live on the bleeding edge of Linux development, Ksplice makes it even easier to do so, and without reboots!"
But do the windows "snap" to one side of the screen? See? Simple! ($100 please)
Changing your car's oil while driving down the highway could be tricky, too.
Remember to maintain your supply of
http://www.imagepoop.com/image/660/I-Reboot-As-Much-As-I-Get-Laid.html
There's no -1 for "I don't get it."
"Using Ksplice is like 'replacing your car's engine while speeding down the highway,'"
So in other words it's something you'd never want to risk doing because it'd almost certainly cause a crash?
I think they should've thought about a different analogy for this one...
this may be based on Free software (residing in the machine needing its kernel patched), but it appears that patch preparation is based on a subscription service provided by the Ksplice Uptrack people. That's the part which is (selectively) free-as-in-beer. This isn't organic to the kernel or the normal methods of kernel updating.
That means there's libre-free software and a service provided by a non-distro company which is, for selected distros, gratis-free. For now.
The technical description sounds like the ancient OS patching techniques the old mainframes I used to work on used.
And frankly, I'd still feel a little more comfortable with a reboot, since I'd worry a bit about state consistency of kernel and client processes. But, I guess smarter people than me says it OK, so what do I know?
Welcome to the Panopticon. Used to be a prison, now it's your home.
WTF are you talking about? Kill -9 gets rid of apps if you really need too, rebooting is for windows users.
... and it has been free for Ubuntu, as indicated on their web page (http://www.ksplice.com/pricing)
Lisp systems did this 30+ years ago: reload new compiled functions, and keep going. New calls go to the new function, old function becomes garbage when no more threads are executing it.
Great job reading the article... "The service for Fedora and Ubuntu Desktop is free of charge. For other distributions, the subscription fee starts at $3.95 per system a month, after a 30-day free trial."
Here's a cookie... *psst* it's MAGIC
Unless they are in uninterruptible sleep.
The Tao of math: The numbers you can count are not the real numbers.
Linux user = more brains than money ...?
Mac user = more money than brains
Windows user =
Other than just screwing around in your garage it's still $50 a year per server if you actually need.
Well, if you manage to get your "updates" accepted by the machine's update process, you pwn the machine after the update anyway, even with conventional rebooting updates.
The Tao of math: The numbers you can count are not the real numbers.
Looks like you might be referring to this http://developers.slashdot.org/comments.pl?sid=130313&cid=10876098
No brain, no pain.
Processes in the 'D' state cannot be killed, even by root. They're waiting on I/O and nothing short of giving them the I/O they're waiting for or rebooting will kill them.
No, the grandparent means uninterruptible sleep.
Processes sleep in a way that can't be interrupted in some cases. For instance, when writing to a file. The logic of that that if it was possible, the application would have to retry the interrupted call, and since a write is assumed to be uninterruptible nobody tries to check if it was interrupted.
This ocassionally creates problems, like when something in the disk subsystem goes wonky, and a write call never returns, leaving the process sleeping and unkillable forever.
There was a patch to create a killable state, that allows fatal signals to be processed in such cases, since the process would die immediately anyway. I'm not sure how fully is this integrated, but while I remember unkillable processes in the past, I don't think I had any in the last couple of years.
I've seen this happen to processes fairly recently. (A couple months ago.) It wouldn't have bothered me, but it meant I couldn't replace the files they were writing to. My workflow at the time was sufficiently inflexible that this basically required me to reboot to continue working when it happened. I stopped using the program that caused the problem, and improved my workflow to be more flexible. I'd hate to run into the problem again though. I'd love to see a patch like the one you pointed to become an integral part of disk I/O in the future.
Insert self-referential sig here.
I recall seeing this problem with NFS some years back - don't know if it's still the case. The clients with open connections would freeze solid if the server abruptly dropped the connection, for whatever reason, and would stay
that way until either forcibly rebooted or until the server reconnected.
I think that the server could be mounted in a "soft" state to prevent that but was told there was too much of a performance penalty.
Pain is merely failure leaving the body
well for starters, Apple doesn't officially support using Blades or Virtual Machines (they did "allow" VMWare to do it", but only on Mac Hardware) which are where many enterprise Linux installs are living nowdays on IBM, Dell, or HP farms. Apple hardware doesn't really have an enterprise presence or connections to the type of SAN hardware running in many places. You have to ASK to buy a Mac and not many IT departments would allow that. You don't have to ASK to try out a Linux install, you can beg "forgiveness" later on because generally you won't cost the company monie$$, or at least risks they wouldn't have spent money on in the first place. While Macs are cool, as far as enterprise uses, it is still pretty limited. I have several macs (so I'm not a hater) but I could never get my IT manager to take them seriously.