No More Need To Reboot Fedora w/ Ksplice 262
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!"
Re:Awesome! (Score:3, Interesting)
how about is linux with memory leaks? (Score:2, Interesting)
how about is linux with memory leaks? is the base os good? what about X? most of the apps? what about apps get stuck in background that need a reboot to unload?
interesting (Score:4, Interesting)
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?
Re:Hmm... (Score:1, Interesting)
All you gotta do is have a skateboard, a rope, a small person, and a lot of oil. Rope goes around the skateboard, small person goes on the skateboard, passenger opens hood, you look out the window and drive, passenger opens the oil and starts pouring as fast as he can, small person opens the drain while under the car, oil drains out and passenger keeps pouring until the oil leaking out goes from black to bronze. Wha La, a moving oil change. Think outside the box like this guy did.
So... (Score:3, Interesting)
Mac user = more money than brains
Windows user =
Re:interesting (Score:5, Interesting)
When you have around 1500 production servers to patch, such as with the memmap 0 bug last year, doing them one-by-one, or even in small batches, remotely over IP KVM takes a long-ass time. This is nice for those types of situations.
Re:Old hat (Score:1, Interesting)
I recall reading a tale of LISP code being in one of the satellites sent out in the 70s. There was apparently a bug in the code which they were able to analyze, debug, fix, and reload - from within the current buggy version while the probe was heading off into space. I haven't messed with LISP nearly enough, but after reading that it entered the realm of Very Neat Things to me.
Re:interesting (Score:3, Interesting)
OK, you see how all of those things still lead to doing a reboot? Now, imagine automating the process AND using ksplice. And I agree that automating the process would have been super awesome, but unfortunately that's just the sort of design process and forethought which was shunned at the place I worked at that time. So I left.
Ports? (Score:1, Interesting)
TFA says that they are making the code available to be directly included in the Fedora distribution. Fedora is pretty strict about what they include in their distribution so if it's included it will have to be Free Software.
Accordingly, what's to prevent anyone from taking the Fedora version and porting it to the other Linux distributions that this outfit is currently charging a user fee for?
Other comments above state that the use of this thing requires a specially crafted patch instead of the regular "here's a new kernel package" that you get from the distribution's repositories. If so, then wouldn't it be worthwhile to use the technology that is revealed in the Free Software Fedora version to make a patch-creating kernel update reader program (KURP - Kernel Update Reader Patch) that would scan a standard kernel update and create the required patch?
Then this technology could become available as a stock feature in all Linux distributions, without charge.
Of course, if the technology isn't Free Software then this whole scheme goes off the rails, but if it's not Free Software it won't be included in Fedora anyway.
Debugging in space: a case for dynamic systems. (Score:3, Interesting)
Looks like you might be referring to this http://developers.slashdot.org/comments.pl?sid=130313&cid=10876098 [slashdot.org]
Re:interesting (Score:3, Interesting)
Re:interesting (Score:5, Interesting)
Seriously? I patched 5500 linux servers in 24 hours *by myself*, all the while they were churning through collider data from the LHC. This would be, in my opinion, what I would call a production environment. Shortcuts are nice, but sometimes you don't need them if your environment is engineered properly.
Re:how about is linux with memory leaks? (Score:2, Interesting)
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.
Re:Scary analogy (Score:3, Interesting)
I keep telling people NOT to reboot their database servers to fix problems but its a reflex reaction that seem to be hard-wired into the DNA of all admins.
Years of training on Windows systems ... they can't help it. Really, they can't, and it's a legitimate tactic in most Windows environments (well, often it's the only thing you can do.) Yes, it has gotten better in recent years, I must admit, but I still find myself having to reboot more often that I think is reasonable.
I've had users who reflexively re-install the application when they see something they don't like. It doesn't help matters when they do so using a four-year-old version they had lying around in a drawer. You just want to reach out and shake them, all the while shouting at the top of your lungs "WHAT on EARTH made you think that was a good idea?" It doesn't help that they generally won't admit what they've done, and I have to figure it out from what they're telling me on the phone. "What? What do you mean there's no DIAGNOSTIC menu. What version are you running, anyway?"
Then, to top it off, when they're informed that they've blown away their entire system configuration and that it's going to have to be rebuilt from scratch, they get upset want to know why we didn't make backups (???). I've often thought that might be a good value-added service we could offer, but it's not up to me anyways. Now, the vast majority of our user base is a hell of a lot smarter than that, but there are always those few who you just know had that umbilical cord wrapped around their neck.
Re:Scary analogy (Score:3, Interesting)
Re:Scary analogy (Score:3, Interesting)
I think they wanted something like "It's like R2-D2 repairing and fortifying your X-Wing while you're in flight," but they probably couldn't get the trademarks.
Re:Old hat (Score:3, Interesting)
Almost, but not quite. In Squeak, the VM itself is statically compiled (via C), so you can't modify that at run time. With SqueakNOS, you can modify device drivers, but there are still some bits that you can't modify.
This is actually pretty trivial for late-bound languages in general. With LanguageKit, we can replace methods written in Objective-C with methods written in Smalltalk or JavaScript at run time too.
Re:Old hat (Score:3, Interesting)
Bizarre that you got modded flamebait, but...
Almost, but not quite. In Squeak, the VM itself is statically compiled (via C), so you can't modify that at run time.
Eh, that's largely picking nits. Did the Lisp machine let you change the hardware running those lisp expressions? No? Then why would you expect to be able to modify the virtual machine running compiled Smalltalk bytecodes?
With LanguageKit, we can replace methods written in Objective-C with methods written in Smalltalk or JavaScript at run time too.
Interesting... I've fiddled with Objective-C a little, here and there, and as a Smalltalk wanker, I quite like it. I might have to go back and take another look, assuming I can find some time when I'm not oscillating between writing experimental webapps in Seaside on Squeak, and giving myself migraines with Haskell... :)