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

Yes, they are.

[KingSkippus]

Stating the obvious, yes, they are.

But third-party companies are under no obligation to offer their products and/or services for free, and this is a service of a third-party company (Ksplice).

If there is a demand for this service, plus an unwillingness to pay Ksplice for it, it's entirely possible (and likely) that someone will come along and offer an open source equivalent. But until the itch is scratched, Ksplice is perfectly within the right to offer the service at a cost.

Re:Yes, they are.

[Bert64]

The diffs themselves only exist in binary form, they are directly derived from the source code already made available by the distributor.

There is absolutely nothing stopping you from using the already available open source ksplice tools to create the exact same binary diffs. The service these guys are offering provides some value-add to this process, namely:

External support - that imaginary finger of blame that companies like to be able to point, even tho it means nothing... Especially important if you value uptime enough to use a system like ksplice in the first place.
Testing - loading untested stuff into your kernel is generally a bad idea, with this service i would know someone else has tried this and made sure it worked.
Time - how much will it cost to have your in house engineers compile and test these patches?
Not free - some people think that anything free is worthless, so they won't even consider this unless it has a price tag.

Re:Huh?

[Donniedarkness]

Nothing bad about it, it's just that sometimes it causes a few problems.

I do tech support at a school. The moment that something goes offline (like our mail server), we start getting calls telling us that things are messed up.

Before anyone asks: Yes, we try our best to only reboot after-hours, and yes, we tell everyone when a service will be down.

Reboots are useful

[kisielk]

I would not trust such a service. Just because a kernel can be upgraded in place doesn't necessarily guarantee that same kernel configuration will be able to boot your system in an outage. Something like a messed up GRUB configuration won't be spotted until you actually try to restart your system. I think part of a regular maintenance strategy is being able to restart your servers and make sure everything is configured to come back up automatically. The last thing you want to is to be trying to figure out what's wrong with your boot config when you have an unplanned outage.

Re:Depends.

[jpmorgan]

Ironically, Xenix was Microsoft's UNIX product, SCO was just a reseller.

Re:How long till they..

[BZ]

The correct plural is "nemeses" (it's a Greek word, not Germanic or Latin as suggested respectively by your two proposed plural forms). Similar to how one pluralizes "axis", "synthesis", "analysis", "genesis", etc, and for the same reasons.

I should note that any sane dictionary will tell you what the plural form of a noun is. Or heck, googling "plural nemesis" in a pinch (first two hits are dictionary entries for "nemesis" that include the plural form). Just for future reference. ;)

Re:How long till they.. Never..

[tuomoks]

First Microsoft is not very eager to sue anyone, second this is totally different mechanism, third Microsoft patent is an old technology - very old because it describes what we did in OS/360, OS/370 operating systems and applications a long, long time ago. Patching memory was (sometimes!) a daily routine for local systems programmer - updating live 24x7 production systems is/was fun but scary!

Anyhow - $4 is cheap when someone is doing the pre-work for you. Actually - the more modularized / structured Linux (Linux == kernel!) gets, the easier it is to support dynamic / online updates with no interruption. There are systems where you can do it already, even all(?) Unix systems allow you to change the whole object in flight if the application is written for it. Actually I designed a while ago one for Windows, load new object, kill the old and the new is automatically used for next call / request / whatever. Tandem Pathway is one very good example, Erlang as a language and a system supports it, systems with failover to another cpu / node have always supported it since Datasaab "non-stop" system from (I think?) early 70's (Cobol kernel!)

Now, giving the "skills" of current "systems programmers", I'm not sure that real time patching is a good idea? Right or wrong, today the "hard" skills, understanding operating systems, their interactions with hardware and applications, etc is very rare! Not a person problem but the documentation, the trust on products / manufacturers / providers, etc are killing the low level skills even the computers handle zeros and ones the same way as day one. And unfortunately the same problems on high level - miracle products will solve all the problems / providers and manufacturers know my problems better than my experienced employees - and I have a bridge to sell!

Re:How long till they..

[jonadab]

> ...which shows what is wrong with Microsoft's kernel

It's not the kernel. It's the filesystem.

Most filesystems, and in particular all the ones that are popular in the Unix world, have an abstraction/redirection layer sitting between a file's directory entry and the actual file contents. Unix people call them "inodes". The details vary somewhat depending on exactly what filesystem you're using, but in general the directory entry points to the inode, and the inode points to the actual file contents wherever they're stored. Because of this, a file can be changed or even replaced in situ, even while another process has the file open and is using it. The inode for the old file remains until the process that was using it lets go, but the directory entry is updated to point to the new inode.

FAT and NTFS don't have inodes, so it's not safe to alter a file while another process has it open. So you have to stop every process that's using the file, before you can do that. The easiest way to do that (and in some cases the only way, e.g., if the file is a shared library that lots of programs use) is to reboot.