A "Never Reboot" Service For Linux

An anonymous reader writes "Ksplice, the company based on the MIT Ksplice project, is now offering its 'never reboot' service for Red Hat, Debian, and other Linux distros. You subscribe and get real-time kernel security updates that apply in-memory instead of rebooting. Last summer we discussed the free service for Ubuntu. Cool tech, but will people really pay $4 a month for this?"

Comments

How long till they..

[mystikkman]

How long till they get sued by Microsoft?

http://www.google.com/patents?id=cVyWAAAAEBAJ&dq=hotpatching

Re:How long till they..

[nmb3000]

Yeah, I love the updates that require a reboot so they can install another update that then requires another reboot.

Ah, see now you're confusing Microsoft with Adobe. Adobe is terrible at requiring reboots for the most trivial tasks. At one point updating Acrobat Reader from the original 7.0 release to the then-newest 7.8 release took 8 restarts.

I'll buy rebooting the system when the kernel is updated, or core services (lsass, winlogon, csrss, etc) get patched, but Acrobat!? The people who write the installers for Adobe's products have long been my arch nemesises (nemesi?) for this very reason.

Re:How long till they..

[Curate]

Oh it's implemented, in Vista (SP1 and later) / Server 2008 / Win7. It does reduce reboots, but does not eliminate them. Some reasons: 1) Not all driver updates are hotpatchable, by their nature. The Ksplice paper discusses some of these problems and omits others entirely. 2) Some of the updates distributed on Patch Tuesday are updates to third party drivers, and since third parties don't use Microsoft's hotpatching technology or some other equivalent, these often end up requiring a reboot. 3) If you're applying a batch of various driver updates (which is the usual Patch Tuesday scenario), if even ONE of those updates to not hotpatchable then you'll still have to reboot at the end. So, hotpatching is not a panacea, it's merely one technique for reducing reboots.

Reading the Ksplice paper, it's the same concept and almost identical implementation as Microsoft's hotpatching. It's pretty unbelievable that Microsoft's hotpatching was not mentioned in the paper at all, not even in the Related Work section or the References section. Hotpatching predates Ksplice by 6 years.

Re:So instead of doing it right...

[oldhack]

An interesting illustration of theory (how it should be) vs. practice (how it pans out).

Depends.

[Hasai]

"Cool tech, but will people really pay $4 a month for this?"

Depends. If it's your laptop, I suspect the answer is no. If it's your server farm, I suspect the answer is yes.

As an aside: Novell used to run contests to see who had the server with the greatest uptime since its last boot. Best one I ever saw was the Netware server that ran so long that everyone forgot where it was and it was accidentally walled-up inside a closet. Wouldn't it be great if the Linux community could run this type of contest? :)

Re:Depends.

[linuxgurugamer]

The following article Linux Watch details a couple of old SCO systems which did the same thing.

Now, before you slam SCO, remember that before 1995 SCO wasn't "The SCO Group" which is infamous for the lawsuit. Back then SCO make some damn fine systems. I had a 80286 system running 32 users for one customer, at a time when Microsoft said it was impossible. That was running SCO Xenix, which was the first good Unix port to the PC.

Re:Huh?

[dotwaffle]

No, they're not.

You see, one radar installation can feed multiple stations, and it's quite common for modern ATCOs to sit at a screen that has feeds from multiple radar sources.

In fact, in the UK we recently pulled out all the old PDPs out of West Drayton and transferred radar control down to Swanwick running on relatively new equipment. I believe this was not done by "clearing the skies" first, they just handed over control to the new guys.

I've heard things about US traffic control being old and antiquated, but I'd hazard a guess to say the vast majority aren't using vacuum tubes, CRTs or the like. I imagine many have converted to electronic paper strip bays for the flight plans too.

Re:Huh?

[pz]

For a server running, say, a big web site, or a database, or something else where time is money, and there are a lot of zeros involved, uptime is crucial. When a stock broker's trading floor system goes down, the loss is measured in millions of dollars per second (disclaimer, my brother used to work for a Wall Street firm, his wife used to work for another, and I have two close friends who still work at a third; my estimate is based on things they have told me). Downtime is just not acceptable under some circumstances.

Sure, if my GoDaddy-hosted web site goes off the air for a minute or two while the virtual server gets rekicked, I can't really complain. I end up rebooting my laptop once or twice per week. My desktop gets rebooted maybe twice per year for some hardware update. Users of single-user machines are generally far more tolerant of reboots since, nominally, they are the ones making the decision to reboot. When there are many users, though, rebooting needs to be coordinated, at the very least, so as not to interrupt work in progress. And, as alluded to above, when there's real money involved, sometimes reboots are not ever acceptable.

For you, rebooting might not be evil, but some people do actually depend on high availability of their computers, and some of them are running Linux.

Re:Yes, they are.

[mysidia]

Very true. However, the Linux kernel is GPL'ed.

They provide binary patches which contain code that is a derivative work of the Linux kernel. What makes the binary ksplice patches derivative is they are converting patches that were created by other people under GPL terms, into a binary form suitable for use with ksplice.

This means those binary patches must be distributed under the GPL, allowing recipients to share those binary patches.

It also means they must make machine-readable source code available to all their patches, along with any changes they have made, and they must provide all compilation scripts, tools, and configuration files they use to build those patches. per the clause of the GPL that states:

The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require,

I can see a lot of people willing to pay $5 or so per month for access to the patches for each distinct OS their systems run.

And some big enterprises paying a per-system fee to ensure everything is fully supported, and that they can always call them for help if something goes wrong with any system.....

However, I don't see that it can be legal for them to force you to agree to pay a per-system fee to use a binary patch.

That would seem to be in violation of your GPL rights.

Given we've already established the binary patch files must be distributed under GPL.

Any kernel-mode components of the patcher must also be under GPL, and also any user-mode components that are specific to the kernel design.

The rest can be reverse-engineered.