Slashdot Mirror
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?"
How long till they get sued by Microsoft?
http://www.google.com/patents?id=cVyWAAAAEBAJ&dq=hotpatching
An interesting illustration of theory (how it should be) vs. practice (how it pans out).
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
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.
Immortality baby! Immortality!
UNIX? They're not even circumcised! Savages!
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.
Earn a % of cash back from Newegg, Tiger Direct, Walmart.com, and more: http://www.mrrebates.com?refid=458505
Color me stupid but wouldn't any application in which you'd rather not be rebooting (i.e. Router, firewall, file server, etc...) be the exact same application in which you'd NEVER want some 3rd party having access to your kernel? I mean, if a large percent of distros were using this I can just imagine it would be the A#1 target for every malicious coder in the world.
I've said it before, and I'll say it again:
Just because it's free software, doesn't mean that it's afraid of money.
Kid-proof tablet..
Designing your own operating system isn't exactly a small feat.. Linux already has very good penetration into the server market, and offers the security that most organizations should have. Linux is what Windows should be. There's a LOT you can do with that kernel.
Obviously complexity makes security difficult, but there's nothing wrong with making something complex if you're actually capable of managing it. Is setting up a rock solid firewall difficult for the average person in IT? Should we just get rid of anything in security that is relatively complex? I'd much rather have more options (not necessarily obfuscation) than be pigeon holed into something just because it's simple. Security is not simple, and it never will be.
l4? qnx?
"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? :)
Regards;
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.
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.
Put my fist through my alarm clock with its ding-dong death inside my ear. - The Blackjacks.
but telling people to check their email when their mail server is offline probably doesn't work for them.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
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.
Why not just compile the kernel locally, like normal people do
Um. Someone else want to break the news, or should I just go ahead and tell him?
The occasional reboot, under controlled circumstances, is an excellent test of what will happen in an emergency situation. Mainly, it answers the question of whether the server and required services actually will all come back up by themselves.
More importantly, if your service architecture can't handle the scheduled outage of individual servers, then it is unquestionably broken.
If you are concerned with individual server uptimes having a bearing on anything except your e-penis, then You're Doing It Wrong.
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!
Ok, I'll do it.
Dear Hurricane78,
please, do not be alarmed. You suffer from an interesting form of amnesia that makes you believe we are still living sometime in February 2010. You also thought that J Cameron's (not to be confused with the late 20th-century fictionfilmer J Cameron. This one is more like the factfilmer D Attenborough) documentary on our early days on Pandora was syfy. But that's ok.
The fact is, however, that these days, normal people run "stock" kernels provided by "distros". It works pretty well and we think Linux is almost "ready for the desktop" now. If only we could get multiple monitors to work....
While we're at it, I should also tell you that Ubuntu is no longer with us. They never really recovered from the unexpected Crappy Century bug after it's version numbers began to repeat in the early 2100s, turning almost all computers into a "Warty".
This may all come as a shock to you. But do not worry. The nature of your amnesia means that you will very soon - right about now in fact - have convinced yourself that this post was humorous in nature and not actually reflective of reality. Trust me, many wish they could live in your world. The end of the 20th/beginning of the 21st century was the highlight for the human race. In fact, many of us are currently working on a project - codename "Charging" - that would result in the creation of a VR set in this glorious era. Like "Second Life", only more immersive. Now if you'll excuse me, I have to go and figure out where we'll get the energy to power this VR from....