A "Never Reboot" Service For Linux 321
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?"
Yes, they are. (Score:5, Informative)
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:Huh? (Score:5, Informative)
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.
Re:Free? (Score:1, Informative)
"FREE" as in "you are free to obtain the software and its source and do with them what you wish" unlike non-free software that has restrictions on its use and no access to the source code.
Re:Yes, they are. (Score:2, Informative)
Actually, if I'm not mistaken ksplice already is completely free and open source. They operate kind of like Red Hat--what you're paying for is support. From what I can tell though, there's one crucial difference--ksplice can't function without support. Now in either case you are free to provide your own support, but I think the task of providing ksplice patches is just nontrivial enough (due to the nature of the problem, not ksplice's design), that the economies here significantly favor everyone paying one company to do it, rather than anyone trying to do it themselves.
Reboots are useful (Score:4, Informative)
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:How long till they.. (Score:2, Informative)
Microsoft does have it (some limitations and restrictions apply -- results may vary, see inside for details, etc, etc)
More of Microsoft's patches used to be available hotfixes.
This is something you would need to specifically look up on their web site. If you want a hot patch, you may find that you can do one, for some security fixes, after reading up on the fix, and following the right procedures, but not through Windows update.
Windows update by default applies security updates the safe way, by using a reboot.
Hot patching on Windows is way too dangerous to do automatically, so it's not automatic. You have to manually decide [microsoft.com], to use HotPatching to apply some updates, after reading the KB articles, determining which patches you can HP, and do careful testing.
There was some sort of resurgence of coldfixes that require reboots, anyways. Don't try to hot patch Windows, unless you know what you are doing.
Sometimes they even confused matters by calling patches that required a reboot hotfix anyways, even though hotfix specifically means a patch that can be applied live and take effect without reboot, how insane.
Re:Depends. (Score:4, Informative)
Ironically, Xenix was Microsoft's UNIX product, SCO was just a reseller.
Re:Huh? (Score:3, Informative)
NetWare was bulletproof, for what it did.
http://www.novell.com/coolsolutions/netware/img/bartb_uptime.gif [novell.com]
http://www.theregister.co.uk/2001/04/12/missing_novell_server_discovered_after/ [theregister.co.uk]
Re:How long till they.. (Score:3, Informative)
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. ;)
Ksplice explanation - with pretty pictures! (Score:1, Informative)
Re:So instead of doing it right... (Score:0, Informative)
On the contrary. Strict Linux (as in, the kernel) has fairly little going for it. It'sa copy of UNIX that is fundamentally incompatible with UNIX. The one major advantage (which has its own downsides), is the GPL and all that implies, eg. the way that drivers get maintained once the initial creator disappears.
The NT kernel, on the other hand, has a lot going for it. It's the most recently designed kernel, and in some ways it shows. Windows' problem is not the kernel.
Re:Huh? (Score:3, Informative)
3.x Netware was pretty darn bulletproof, provided you didn't mind copying the Bindery stuff to every different server, and one had to use IPX or nothing.
There are three things from it that were notable:
1: If a user doesn't have access to something, it doesn't show up in a listing. No directories or files with "access denied" messages, just making them more curious.
2: The OS was simple and had very limited functionality. Want some feature? Buy a third party NLM. Netware 3.11 had next to no attack surface.
3: The console commands kept the riffraff out. No point and drool interface. To use it, you had to at know the basics of what you were doing.
The one thing I wish was passed on to modern operating systems was feature #1. Out of sight, out of mind. If a directory isn't shown, a user won't bother trying to get access to it, as opposed to something saying "permission denied".
Re:How long till they.. Never.. (Score:4, Informative)
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:Yes, they are. (Score:4, Informative)
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:How long till they.. (Score:3, Informative)
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.
Re:How long till they.. (Score:2, Informative)
Re:So instead of doing it right... (Score:3, Informative)
No, xnu is not a microkernel. See this. [wikipedia.org]