Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

A "Never Reboot" Service For Linux

kdawson posted more than 4 years ago | from the bits-don't-rot dept.

Security 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?"

cancel ×

321 comments

Sorry! There are no comments related to the filter you selected.

Free? (-1, Troll)

NCTRNAL (780392) | more than 4 years ago | (#31080384)

Aren't Linux and the rest of them supposed to be "FREE* software?

Yes, they are. (5, Informative)

KingSkippus (799657) | more than 4 years ago | (#31080466)

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. (2, Informative)

NAR8789 (894504) | more than 4 years ago | (#31080904)

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.

Re:Yes, they are. (4, Interesting)

mysidia (191772) | more than 4 years ago | (#31081164)

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 [gnu.org] 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.

Re:Free? (3, Insightful)

adolf (21054) | more than 4 years ago | (#31080596)

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.

Re:Free? (1, Interesting)

Jeremiah Cornelius (137) | more than 4 years ago | (#31081114)

I'm not afraid of money.

I'm afraid of some startup jokers - possibly funded by TLA's - taking my money to 'root' my servers!

Re:Free? (1, Informative)

Anonymous Coward | more than 4 years ago | (#31080660)

"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:Free? (1)

kimvette (919543) | more than 4 years ago | (#31080778)

If it weren't for companies like Redhat, Mandrake (Mandriva), (pre-Darl) Caldera, and Novell trying to find ways to convince people to pay for "free" software, how likely do you think it is that we would have a useful Linux today?

How long till they.. (5, Interesting)

mystikkman (1487801) | more than 4 years ago | (#31080388)

How long till they get sued by Microsoft?

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

Re:How long till they.. (5, Insightful)

wcb4 (75520) | more than 4 years ago | (#31080408)

Its a shame that MS never figured out how to actually implement this. How many times do I have to restart my computer to finish applying update?

Re:How long till they.. (1)

maxume (22995) | more than 4 years ago | (#31080776)

Lately it has been once every month or two.

Re:How long till they.. (2, Insightful)

rootofevil (188401) | more than 4 years ago | (#31080814)

dont you mean once or twice a month?

these emergency IE patches are getting tiresome.

Re:How long till they.. (1)

maxume (22995) | more than 4 years ago | (#31081080)

Well, I don't use IE actively, so I don't worry about it (I have updates set to download automatically, and then I used a group policy to have it only prompt me to restart once every 1,000 minutes once I choose to install the updates).

Re:How long till they.. (0)

Anonymous Coward | more than 4 years ago | (#31081090)

No, once every month or two. Unlike Apple, Microsoft figured out how to update their browser without needing to take the whole system offline.

Re:How long till they.. (5, Insightful)

nextekcarl (1402899) | more than 4 years ago | (#31080922)

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

Re:How long till they.. (5, Insightful)

JSG (82708) | more than 4 years ago | (#31080498)

The patent on this was filed in 2002. Yet in 2010 I am still making a handsome profit in overtime rebooting customer systems on a "patch Tuesday" monthly frenzy.

Please MS, don't implement this one.

So instead of doing it right... (2, Interesting)

drolli (522659) | more than 4 years ago | (#31080416)

..an using some Microkernel OS in which something like this would come as a well-controlled feature, we are using a monolithic kernel and self-modifying code?

Re:So instead of doing it right... (4, Interesting)

oldhack (1037484) | more than 4 years ago | (#31080446)

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

Re:So instead of doing it right... (4, Insightful)

el_tedward (1612093) | more than 4 years ago | (#31080626)

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.

Re:So instead of doing it right... (2)

BikeHelmet (1437881) | more than 4 years ago | (#31080488)

As long as you purge ALL the memory pages used by a chunk of the kernel, nothing can go wrong, right? ;)

Hey, it seems to work...

Re:So instead of doing it right... (2, Insightful)

Anonymous Coward | more than 4 years ago | (#31080548)

Advantages of a microkernel:

Modules can be rebooted/maintained separately from the core kernel .... check

The core kernel can be updated.....Nope but Linux has this anyway

In kernel bug isolation & security....Nope

Given there isn't a microkernel with 1/10 the other capabilities/hw support/usage of linux, doesn't it make sense to add stuff to linux instead of waiting for this mythical desktop microkernel.

Re:So instead of doing it right... (3, Insightful)

drolli (522659) | more than 4 years ago | (#31080636)

l4? qnx?

Re:So instead of doing it right... (1)

BenoitRen (998927) | more than 4 years ago | (#31080828)

Given there isn't a microkernel with 1/10 the other capabilities/hw support/usage of linux, doesn't it make sense to add stuff to linux instead of waiting for this mythical desktop microkernel.

No. Linux is, and has always been, predominantly for servers. It's a losing battle to turn it into the perfect desktop OS.

I'm waiting for Haiku.

Re:So instead of doing it right... (2, Insightful)

Blakey Rat (99501) | more than 4 years ago | (#31080652)

It would probably cost more than $4 a month to rewrite the Linux kernel to that extent. :)

Re:So instead of doing it right... (0)

Anonymous Coward | more than 4 years ago | (#31080668)

That depends on how long you want it to take...

making stuff up (1, Insightful)

Anonymous Coward | more than 4 years ago | (#31081094)

Well-controlled live changes are not inherent to microkernels. Monolithic design does not preclude well-controlled live changes; all you need is persistent memory and a kernel that can resume operation on that memory. Stage the new kernel and switch. This has been done for HA systems.

Can one argue that microkernels are more amenable to well-controlled live changes? Perhaps.

That's the best you can say about it. The rest is a fiction that exists exclusively in your head.

I foresee uptime.netcraft.com domination (-1, Troll)

Anonymous Coward | more than 4 years ago | (#31080458)

Useless stats ftw!

$4 a month too much? (0)

Anonymous Coward | more than 4 years ago | (#31080460)

Is $4 a month too much for the benefits of instant(ish) security patches and 24/7 kernel uptime, I don't run any dedicated servers, but if i had a couple i wanted to setup and leave for years serving content without worrying about them I wouldn't mind paying ~20GBP to almost forget about a ubuntu LTS/RHEL install with autoupdates.

Huh? (0)

Frosty Piss (770223) | more than 4 years ago | (#31080464)

Would someone smarter than me please explain what is so evil about rebooting now and then?

Re:Huh? (4, Informative)

Donniedarkness (895066) | more than 4 years ago | (#31080504)

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.

Re:Huh? (1)

aztektum (170569) | more than 4 years ago | (#31080790)

Set your voicemail to "Yes, we know this is down. Check your e-mail." or some such and shut your ringer off. Works for me.

That might work for you (4, Funny)

Chuck Chunder (21021) | more than 4 years ago | (#31080850)

but telling people to check their email when their mail server is offline probably doesn't work for them.

Re:Huh? (1)

b4k3d b34nz (900066) | more than 4 years ago | (#31080974)

"Have you tried turning it off and on again?"
"Is it definitely plugged in?"

Re:Huh? (1)

muphin (842524) | more than 4 years ago | (#31081162)

i can picture the guys saying that on "The I.T Crowd [imdb.com] " .. shame they didnt make so many episodes.

Re:Huh? (0)

Anonymous Coward | more than 4 years ago | (#31080886)

> The moment that something goes offline (like our mail server),
> we start getting calls telling us that things are messed up.

So? It is your job (or Service Desk to be more specific) to answer these calls and inform your users that the service will be aviable shortly. And the main benefitient of given service (be it mail server) requires it to be higly available kindly inform him that it is certainly possible but requires more money. And if they will to spend more money on making the mail server highly available I think that there is less job for you then (answering the calls) and also you will be more satisfied since you'll be running more advanced stuff.

I can't really think of IT service that cannot be HA clustered. Mail systems? I think any decent mail system supports clustering.

I know that such setup is not free (usually it requires more hardware and licenses) but since you are complaining about getting offline - have you ever considered setting up a cluster and proposed it to your management?

Re:Huh? (2, Funny)

gandhi_2 (1108023) | more than 4 years ago | (#31081052)

I just place blame on the user. And when they get defensive, I point out their defensiveness as proof of their guilt. Pretty soon, they learn not to complain.

Re:Huh? (1)

davester666 (731373) | more than 4 years ago | (#31080512)

You have to save all your work and can't use your computer for 1-3 minutes as your computer stops/boots up again. And you'll probably have to login again, so you'll need to remember and type in your user name and password. And then relaunch all your applications.

Re:Huh? (0)

Anonymous Coward | more than 4 years ago | (#31080556)

You have to save all your work and can't use your computer for 1-3 minutes as your computer stops/boots up again. And you'll probably have to login again, so you'll need to remember and type in your user name and password. And then relaunch all your applications.

Actually, it's more about servers, not workstations. A server reboot affects all users and services that rely on that server, whereas a workstation reboot only affects the person doing the rebooting.

Re:Huh? (0)

Anonymous Coward | more than 4 years ago | (#31080516)

It compromises uptime counters and serves as one more painful reminder that the glory days of the VAX are gone.

It once was said that in order to be a true VAX sysop, you had to know first-hand how many digits the VMS uptime counter had on it for the days field.

Sources say three.

Re:Huh? (0)

Anonymous Coward | more than 4 years ago | (#31080838)

I once ran a heavily used FreeBSD-4.9 server for 719 days; until the day it outran its UPS. Are you sure VAX bragged about three digit day fields? Why?

Re:Huh? (1, Insightful)

Anonymous Coward | more than 4 years ago | (#31080542)

In critical services, 100% uptime is essential. Imagine a server used in air traffic control...

Re:Huh? (1)

amRadioHed (463061) | more than 4 years ago | (#31080590)

Aren't most of the air traffic control servers still using hardware with tubes? I wouldn't be surprised if they haven't updated a kernel in the last 30 years.

Re:Huh? (3, Interesting)

dotwaffle (610149) | more than 4 years ago | (#31080748)

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? (1)

Sponge Bath (413667) | more than 4 years ago | (#31081196)

...we recently pulled out all the old PDPs

How recent? Which models? Are the old machines being made available on eBay?

Re:Huh? (1)

MichaelSmith (789609) | more than 4 years ago | (#31081002)

Aren't most of the air traffic control servers still using hardware with tubes? I wouldn't be surprised if they haven't updated a kernel in the last 30 years.

Older hardware would be alphas or comparable hardware expected to run unix. Newer machines are more likely to be commodity servers. Kernels in use won't be cutting edge from Linus's git tree. They will be a few versions behind and integrated for the application.

Generally in ATC you can have downtime for maintenance but you have to be able to say when it will happen. As the other poster said you can reconfigure to hand off traffic to another center or another part of the same center, but it takes planning or people get upset.

Re:Huh? (1)

darth dickinson (169021) | more than 4 years ago | (#31080646)

One would hope that there would be redundancy in such a situation...

Re:Huh? (1)

hedwards (940851) | more than 4 years ago | (#31080764)

Yes, but if it's truly a critical service you're talking about redundancy and probably a set up where you can afford to take down one server at a time every few months to reboot/clear the gunk. If you've only got one machine, you're already fucked. You just haven't noticed yet.

Re:Huh? (1)

MichaelSmith (789609) | more than 4 years ago | (#31080562)

Would someone smarter than me please explain what is so evil about rebooting now and then?

Some organizations who have operational requirements to provide a service continuously. For them there is no acceptable downtime. Having said that I think their safety managers would have a few things to say about software which auto updates kernels on the fly, but that is a different issue. Their preference would be to never update their systems.

Re:Huh? (0)

Anonymous Coward | more than 4 years ago | (#31080666)

Shouldn't they have enough redundant load-balanced servers to survive multiple hardware failures in that case? In which case they could reboot the machines one at a time without disrupting service.

Re:Huh? (1)

MichaelSmith (789609) | more than 4 years ago | (#31080680)

Yeah but how do you make your user interface redundant and load balancing? It is the most important part of the system.

Re:Huh? (0)

Anonymous Coward | more than 4 years ago | (#31080934)

By storing all the user session information in the database, the way god intended it to be, not on the web server. Then it does not matter which web server the user hits, the experience is the same. They could get a button served from one sever, the javascript from another, the html from a third and the css from yet another, and there would be no difference.

Re:Huh? (1)

MichaelSmith (789609) | more than 4 years ago | (#31081030)

I am not talking about web servers.

Re:Huh? (1)

Welsh Dwarf (743630) | more than 4 years ago | (#31081146)

Same goes for any other type of server, you just make sure that any non deterministic parts of your server calls are shared among the cluster. How you do this is up to you (memcached/database) just make sure it's 100% replicated.

Then when one machine stops doing what it's supposed to (or looks like it might), your heartbeat script writen for the occasion kicks in, rotates the offending machine out of the cluster and, if you really have the budget, rotates a spare into it's place which then syncs with the other machines and off you go.

Re:Huh? (1)

MichaelSmith (789609) | more than 4 years ago | (#31081226)

I am not even talking about servers. How about when there is an actual person sitting in front of a screen which is attached to the system you are updating. If it is going down you need to move that actual person (and their infrastructure: communications, etc) to a different screen, or move their job to a different person; and all without interrupting the task at hand. Thats not easy.

Re:Huh? (2, Interesting)

danlor (309557) | more than 4 years ago | (#31080572)

You run a server of any kind. In the old days of novell, we had severs with 6 year uptimes. Not possible today simply from patches, not crashes.

This service has the potential to get us closer to that ever distant 100% uptime. It could definately stack another 9 on 99.999

It can be quite beneficial (2, Interesting)

XanC (644172) | more than 4 years ago | (#31080576)

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.

Re:Huh? (1)

skiman1979 (725635) | more than 4 years ago | (#31080678)

Would someone smarter than me please explain what is so evil about rebooting now and then?

Downtime just KILLS a system's availability requirement.

Re:Huh? (0)

Anonymous Coward | more than 4 years ago | (#31080920)

Would someone smarter than me please explain what is so evil about rebooting now and then?

Downtime just KILLS a system's availability requirement.

So put the machines in a cluster and only reboot one of them at a time. geez.

Re:Huh? (2, Insightful)

Anonymous Coward | more than 4 years ago | (#31080714)

At an individual computer level it's not so bad, but in an enterprise it can be troubling.

A couple of examples: a zero-day exploit of Microsoft Windows (surely this would never happen) requires a patch be applied and the computers rebooted for thousands of users. Even assuming that the reboot can be enforced with 100% reliability (seldom to never), the 1-3 minutes will impact productivity for at least some users. Sure, desktops can be rebooted at night, but laptop users that take their machines with them and never have them powered up unless they are using them will be impacted. Imagine a company with an average productivity value of $10/hr, $20/hr, or $30/hr. Imagine this company has 100 laptop users or 1,000 or 10,000. Multiplication makes that 1-3 minutes each expensive.

A different scenario involving servers where services must be available: say web servers that require database servers and both require directory servers. There may be several of each of these for load balancing or fault tolerance, possibly clusters, and real world examples may be far more complex. Reboots must be coordinated based on which nodes of which clusters can be taken down without impacting service. Often, additional commands must be added to gracefully transfer service, notify a load balancer device, possibly tell a monitoring server that its in scheduled maintenance mode and not to send a bunch of emails to the support team because the server is down. Ideally one web server and one database server and one directory server go down and all come back up, followed by another set, etc, and cluster master roles are reallocated correctly, etc.

Obviously there are ways to script, automate, plan, and mitigate all of this, but if it didn't have to reboot in the first place... that would be nice, huh?

Re:Huh? (0)

Anonymous Coward | more than 4 years ago | (#31080740)

For some systems there's no problem rebooting during a maintenance window. In others, it's a problem. For example, if you have a semi-critical system in an international organization, it's often difficult to get a maintenance window because it's not critical enough to invest in HA yet important enough that people complain if it goes offline. Believe me, it's idiotic but never under-estimate the politics that goes on in an international organization. There are also critical systems that does not have maintenance windows yet fall under regulations such as SOX, PCI or maybe health related so they must be updated. These can include certain types of hardware controllers, telephony devices, etc.. In many cases having a full cluster solution for these systems is too expensive so ksplice can be the next best thing.

Re:Huh? (1)

Angst Badger (8636) | more than 4 years ago | (#31080742)

It depends on what your system is doing. If you're an end user running desktop apps, mostly it's just a pain in the ass. If you're maintaining a server that does something that has to be available all the time, the results range from expensive to disastrous. If the server in question handles credit card transactions for a bank, downtime costs the bank money -- they profit from transaction fees -- and it also costs vendors that use the bank's services. If the server handles air traffic control, the operation of a nuclear power plant, or life support for patients in a hospital, downtime can cost lives. It all depends on what the machine is responsible for.

While it's probably not all that directly important to you (or, for that matter, for me, since I am blessedly free of sysadmin duties at the moment), it does affect all of us indirectly, since the perceived reliability of Linux has a marked effect on the resources any number of companies and institutions are willing to pour into it, some of which is going to be source code that is then shared by everyone.

But the short answer is it doesn't matter much in 99.9% of cases. For the remaining 0.1%, rebooting can be a very big deal.

Re:Huh? (3, Interesting)

pz (113803) | more than 4 years ago | (#31080774)

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:Huh? (0)

Anonymous Coward | more than 4 years ago | (#31081174)

Would someone smarter than me please explain what is so evil about rebooting now and then?

It's time taken from your work to fix what MS screwed up. It's time taken offline from users. It often entails repeated reboots because, if you check for updates after applying one set and rebooting, you find there is yet anther set to run (and reboot after). I have had this happen up to three times in a row. So why don't they display and make available all updates at the same time? It makes your uptime a butt of jokes from people running Linux who have uptimes measured in well over a year. It's a sign of gross incompetence among the people who develop MS OSes. As a system gets more and more SW installed, including boot-time loads, the time lost to a reboot takes longer and longer.

Sorry, dinner's ready or I'd go on with a lot more.

Hah! -- captcha = condemn

Re:Huh? (0)

Anonymous Coward | more than 4 years ago | (#31081204)

You're a fucking moron.

Hell yeah! (3, Funny)

Zocalo (252965) | more than 4 years ago | (#31080484)

Immortality baby! Immortality! [xkcd.com]

who gives a fuck? (-1, Troll)

Anonymous Coward | more than 4 years ago | (#31080490)

linux is for faggots anyways.




FAGGOTS!

Re:who gives a fuck? (0, Troll)

JSG (82708) | more than 4 years ago | (#31080586)

In Britain we burn faggots (or eat the offal variety) not try and install an OS on them.

WEIRDO!

Re:who gives a fuck? (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#31081088)

i think burning faggots is a good idea.

4/month to keep your uptime? (1)

Zerth (26112) | more than 4 years ago | (#31080500)

Maybe if it was almost 497.1 days:)

Rebooting is a Good Thing... (2, Insightful)

Dice (109560) | more than 4 years ago | (#31080508)

Those who do not perform scheduled reboots of their servers do not know whether their servers will come back up properly after unscheduled reboots. How often have you seen someone add a service to a machine which becomes a critical part of your infrastructure then they forget to add it into the RC system?

Re:Rebooting is a Good Thing... (1)

MichaelSmith (789609) | more than 4 years ago | (#31080592)

Thats really a configuration management issue. I find the BSD startup scripts to be superior in this regard because the service won't start if it is not configured to start when the system starts.

Re:Rebooting is a Good Thing... (1)

Pretzalzz (577309) | more than 4 years ago | (#31080632)

I was going to post something similar from a less serious angle. I never reboot because I'm never sure the computer will reboot correctly and I'd rather not have to spend half an hour dealing with the problem. I upgrade things like grub and sysvinit more often than I reboot and until I personally test it there is no guarantee that it will work.

Re:Rebooting is a Good Thing... (1)

sl149q (1537343) | more than 4 years ago | (#31080906)

The new distro will be a "splice here" to get you running a pre-started system. You simply won't need startup scripts as you will never actually reboot. Just keep running the one you started. If your hardware crashes just restart at synchronization point and off you go, either with the same or new hardware. The people building the initial builds (i.e. running system with default services) have to worry about getting them started, but after deployment it won't (shouldn't) be necessary.

Re:Rebooting is a Good Thing... (0)

Anonymous Coward | more than 4 years ago | (#31080672)

Thats exactly right. The cause of THAT problem is the lack of a unified management interface that would otherwise make system configuration changes mandatory to commit to nv storage.But even beyond that, sometimes the boot order of things can prevent what you just did from the command line to setup that new service from actually working at 'startup time'.... Will the interfaces your config file references exist when your startup script executes? Will the dhcp server have responded and given you a default gateway so that dns resolution works? Will the local sql database be running or will it have 'crashed' and require a manual start or table rebuild? Will your NFS mounted directory actually be mounted at the time your script runs or does that depend on something else?

Re:Rebooting is a Good Thing... (2, Funny)

Hasai (131313) | more than 4 years ago | (#31080690)

....How often have you seen someone add a service to a machine which becomes a critical part of your infrastructure then they forget to add it into the RC system?

Um, never?

Re:Rebooting is a Good Thing... (1)

Locklin (1074657) | more than 4 years ago | (#31081046)

I rebooted my workstation before heading home today. Just a moment ago, I realised that eth0 isn't set to get an IP address via DHCP. It's running, but I can't connect to it from home tonight! Lesson learned... never reboot.

hrm... (5, Insightful)

Charliemopps (1157495) | more than 4 years ago | (#31080518)

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.

Re:hrm... (1)

postbigbang (761081) | more than 4 years ago | (#31080604)

One thinks that this is a rootkit server looking for a kernel marked X.

Pardon my ignorance (1)

Emperor Tiberius (673354) | more than 4 years ago | (#31080534)

But couldn't this still have the potential to pork your system and force a reboot? Wonder what their policy is on that...

4 bucks a month? (2, Insightful)

s4ltyd0g (452701) | more than 4 years ago | (#31080568)

Not expensive if the technology works. My time is more valuable and down servers cost money. The cost is paltry in comparison.

Re:4 bucks a month? (2, Interesting)

OzPeter (195038) | more than 4 years ago | (#31080842)

Thats a big *if* What it means is that you are deferring quality control assessment of patches to an outside company. I for one don't want changes made to a system without my approval or consideration.

Re:4 bucks a month? (1)

Rakshasa Taisab (244699) | more than 4 years ago | (#31081112)

If they are experts in the field and have a large userbase testing the patches, are you not perhaps suffering from a slight spell of HUBRIS in thinking you can do better?

And who is to say you can't do QA before applying?

Windows? (1)

HaeMaker (221642) | more than 4 years ago | (#31080606)

Anyone else notice they do not support windows, but the Windows Update dialog is the most prominent in the background image?

Re:Windows? (1)

The MAZZTer (911996) | more than 4 years ago | (#31080854)

Well when you think of "rebooting" you think of WU. It just nagged me like 30 seconds ago to do it.

Ugh, just reboot (2, Insightful)

jpmorgan (517966) | more than 4 years ago | (#31080628)

99% of people I've seen bragging about long up-times tend to have perfectly patched and up-to-date OS installations on disk, and a dozen vulnerabilities still loaded into memory. And I'm not talking just about the OS kernel.

If you don't know exactly what an update touches, just reboot.

Re:Ugh, just reboot (1)

Nerdfest (867930) | more than 4 years ago | (#31080712)

That's completely true. This ensures that you have the patches in memory as well. I've been using it for about 6 months, and it's very cool. There's a few little things, like 'uname -a' gives the old version, and you can't really hibernate after an in-memory patch, but the product is great, and the company has answered any questions I've asked them.

Re:Ugh, just reboot (1)

jpmorgan (517966) | more than 4 years ago | (#31080812)

Fair enough... but I'm more concerned about applications. If you're really on top of the ball then maybe this service might work.

But generally people run servers for a reason. And just applying patches to kernels in-memory isn't really going to help you when your software stack needs a security update. You've still got to take the application down to get that fix into memory... and god help you if the patch was to a library.

I just don't see how it's worth the effort. How much extra time does it take to do a reboot and be guaranteed that you've got all the vulnerabilities excised from memory? If you're really competent you can do it the hard way and save a few seconds of actual downtime... but it just strikes me that if you're in that kind of position redundancy would be better. And if you're not, this kind of technology encourages dangerous practices.

They better be encrypted! (2, Interesting)

Hurricane78 (562437) | more than 4 years ago | (#31080644)

Because I can’t imagine a easier way to obtain an instant-botnet, than to “spice” such a patch. ;)

By the way: Who came up with remote updates? Why not just compile the kernel locally, like normal people do, and then use a special patching tool?

Re:They better be encrypted! (5, Funny)

Anonymous Coward | more than 4 years ago | (#31081158)

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?

Depends. (4, Interesting)

Hasai (131313) | more than 4 years ago | (#31080676)

"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. (1)

cryoman23 (1646557) | more than 4 years ago | (#31080930)

ya i think that would be a really cool competition to have.

Re:Depends. (3, Interesting)

linuxgurugamer (917289) | more than 4 years ago | (#31081066)

The following article Linux Watch [linux-watch.com] 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.

What is the use of such service? (2, Insightful)

kosmosik (654958) | more than 4 years ago | (#31080810)

I don't really personally see any use of such service. If you need FT or HA system you need to design it as such from ground up. In this case paying 4 bucks just solves some problems with rebooting after kernel upgrade. I dont have problem with that. I just reboot in next service window. In normal situation mission critical systems have some sort of redundancy not only to cope with planned service reboots but with other unplanned disasters. So usually you have a N+1 redundant cluster in which you can reboot the servers using some procedure that was worked out while DESIGNING the system. Also I see quite few security issues with patching the kernel this way. In mission critical services you usually do test everything before rolling it out to the systems so using such feature just makes things more complicated (that just simply reboot the machine with my current procedures).

I cannot find anything about security details on their webpage. They state "Ksplice Uptrack uses cryptography to authenticate the update feed.". So what? Fedora also used cryptography and once their servers got rooted the whole chain collapsed. So if I was to use their service I wish to know how exactly their security is implemented since I would be getting kernel patches (quite critical stuff) from them. At least with RHEL I know a about their security procedures (quite rigorious). From support point of view. Does f.e. Red Hat or Oracle support systems patched this way?

It is a nice feature but IMO not suitable for enterprises yet.

Re:What is the use of such service? (1)

Chuck Chunder (21021) | more than 4 years ago | (#31081004)

I just reboot in next service window. In normal situation mission critical systems have some sort of redundancy not only to cope with planned service reboots but with other unplanned disasters

That is certainly true such activity often requires a bit of human babysitting, if only to verify that everything bounces back and syncs as it should. If the process really is seamless then $4 could mean your (much more expensive) engineers spend their time on other productive things.

That said I'm not sure it's an idea that will take off in practice, even if it is a very clever idea. I think it's something that a lot of people will be nervous about (including me). With the current patching mechanisms you can be fairly clear what your system is running. This seems a bit too much like magic right now but it's entirely possible that one day it will just seem normal.

Uptime (0)

Anonymous Coward | more than 4 years ago | (#31080968)

I sure know a lot of people pay a lot more than $4 per month for "Uptime!"

Never Reboot - Never stop paying (1)

FewClues (724340) | more than 4 years ago | (#31081044)

This sounds more like a Microsoft solution than a Linux solution. $48 a year is exactly $48 more than I paid for my OS. But the question is: Are we so lazy that we will pay $48 a year to not have to reboot the system? I mean lay down and take a break while its rebooting and you'll be fine.

Sooo (1)

geekoid (135745) | more than 4 years ago | (#31081064)

Linux is a service now?

A lot of people will think that, and it's competitors won't do anything to counter it.

"If you want the most stable version of Linux, its 4 dollars a month? And they have the nerve to call it free. After purchases Windows 8, all the patches and upgrades are free for at least 3 years."

fucKer (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#31081074)

Restarting is not a bug... (1)

CoverStory (1020095) | more than 4 years ago | (#31081092)

If you can't reliably restart your server on your own schedule, what makes you think it will gracefully restart when something happens that you can't control?

Reboots are useful (3, Informative)

TheVoice900 (467327) | more than 4 years ago | (#31081138)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>