Get to know Ksplice: kernel patching was never this easy.

The benefit I see here is that it provides you with a kernel that has all the latest security updates without having to recompile, upgrade, etc. When you reboot next, you have the same kernel you had last time you rebooted (unless you've done an upgrade in the meantime), so you know it's going to boot.

ksplice doesn't modify the kernel on-disk, only in memory. In the unlikely (so far for us) situation that one of those patches is incompatible, causes problems, crashes your system, etc. and you want to reboot to a known-good configuration, just log into their system and deactivate the server, and it won't be able to do any updates.

Your post seems to assume that ksplice changes your booting kernel, and thus who knows if it will boot next time. This doesn't happen. Unless you upgrade your kernel yourself (e.g. through yum or apt), you're always booting from the same (insecure) kernel, and the ksplice daemon reapplies the patches again after you boot to get you up-to-date.

It's really a marvellous technology, and it's worked very well for us so far.

The most valuable thing I took out of it was that it is a good lesson in marketing a product. I mean, the tech itself obviously took a lot of work, but it doesn't really attack what people doing dynamic upgrade consider hard problems -- in particular, it doesn't do changes to data very well.

However, look at the way it was presented. Firstly we get good stats to the effect that the vast majority of kernel updates are things that can be done without solving difficult data update problems. This was a particularly important point to make at a research-related conference.

But the marketing doesn't stop there -- they also run a service which you can use to generate updates for you, so you can track from kernel to kernel automatically.

So, the end result is a strong argument for something which a) works most of the time; b) will work for you without much effort on your part; and (most importantly) c) is fantastic bragging rights: "My OS doesn't ever need rebooting!"

In the wrong hands, this would have been a mediocre research project. "Sure we can upgrade the kernel, but we have to interpose functions, create shadow data structures, the result isn't anything like what a "real" kernel would look like after reboot so you have no guarantee of anything, and sometimes it doesn't work". Instead we get something that everybody is talking about and is rapidly emerging as a strong selling point for Linux. My respect to the KSplice team for doing three jobs well: research, implementation, and marketing.

However, Ksplice mainly supports security patches which tend to be localized and less risky than large semantic changes or feature additions. I suspect that such changes are extremely unlikely to produce an unbootable system.

They do have limited support for type changes to data - e.g., adding a field to a struct. These must be performed using a "shadow data structure" which holds fields that were added to the original structure. This would cause patches to diverge a bit from the original kernel versions.

However, since Ksplice aims primarily to support security patches, I suspect that both function signature and type changes are less common than they would be for general OS (or application) evolution.