Your average sysadmin (or even your above-average sysadmin) is going to be pretty hard-pressed to figure out which services a given library vulnerability "really" affects. Without really understanding the code, it's hard to say. The only safe thing is to restart everything.

Sure. You just have to restart everything using libc, like for instance:

$ sudo lsof -c init 2>/dev/null | grep libc
init 1 root DEL REG 251,0 269825 /lib/tls/i686/cmov/libc-2.11.1.so

Notice how it's deleted, so presumably init is using an old libc version that was upgraded. Hope it doesn't contain vulnerabilities! If you can't tolerate rebooting your system, you probably can't tolerate restarting every single process, either. And if you can leave unpatched libc running in all these daemons, why not an unpatched kernel too?

All that said, it would be nice if distros could apply patches live automatically for the benefit of regular users, who ignore the "please reboot" message (or even just take hours to notice it). At least it will reduce vulnerabilities. But this can't fairly be billed as a way to avoid rebooting altogether, which is how it's often presented: "No More Need To Reboot". Wrong.

Okay, this is a legitimate point. If you use clustering or something, then you might be immune to most hardware failures. Even if you use regular hardware, if you have enough hardware redundancy you're only subject to CPU/RAM/motherboard failure, and most of that's hot-swappable for upgrades with the right OS. Not perfect, but say planned downtime once per five or ten years for an OS upgrade, probably acceptable. It's possible.

But it's much more common these days to just design systems you can reboot nodes without downtime, so I don't see hot-patching allowing "No More Need To Reboot" except in a very small minority of setups. Better to think of it as a tool to increase security by letting you deploy patches faster.

I run a 16-core server with 16 GB of RAM. I'm going to deploy a second one soon with automatic failover to eliminate downtime for routine administration. It's perfectly possible for the vast majority of services. I'll grant that there will always be exceptions, probably for the most part custom-written applications that weren't designed for redundancy.

You can't reboot one mainframe at a time without affecting service, if you only have one mainframe. Rebooting it's going to leave you with no running servers, and it's hard to provide service then. :) Instead, you're forced to design the system so you never have to reboot it, which is much harder.

And for hardware failures? Or critical service restarts? Or a bug causing an OS crash? Put it this way: you can either try to minimize the downtime of each server, or make it so that the downtime of one server doesn't affect service. The former is much more complicated and error-prone, and is still going to fail sometimes, so you need the latter regardless if you're really aiming for reliability. And the latter makes the former unnecessary.

The difference between mainframes and regular PCs is that one mainframe's role is taken on by many PCs. With proper setup, you should have redundancy between the PCs, so you can reboot them one at a time without affecting service. You can't do that if you only have only one mainframe. Even with two, you can only do it if you can afford to double your load. So this might be needed for mainframes, but not for PCs.

Okay, so even suppose this is perfectly reliable. Let's say I'm running a high-availability server and can't stand any downtime. Now when my kernel needs an update, I don't have to reboot, great!

So what about when, say, libc needs an update? As long as programs are still using it, they'll be using the outdated version. Am I supposed to restart all programs using libc? That will cause downtime just like a reboot (although maybe a bit less).

Or what about when I need a hardware upgrade? Or there's a hardware failure? Or what happens when that critical application requiring 100% uptime needs a security fix? What am I supposed to do then?

There's no way to avoid outages completely for any given machine. PC OSes aren't meant for that. Any high-availability service needs to be able to tolerate the failure of any one machine. So why not just reboot it when you get a critical update to the kernel or major system library? That way you know that the machine reboots properly, too.

My suspicion is that this is mainly meant to lure in Linux users who want the "please reboot your computer" messages to go away. But those messages are misleading. If you Ksplice and never reboot, your libraries will remain outdated indefinitely – it's not secure. Distros would do better to ask for reboots only on security updates, and to do so for libraries and running applications (if they can't be easily restarted) as well as kernel updates.

Libre is French. The Latin equivalent is liber.

I said that. In those cases, I don't object to unions much or at all. However, that's not the status quo today, contrary to what you implied. Unions today are protected by the government far beyond what free trade would give them.

I'm not a laissez-faire capitalist, nor a libertarian. I'm in favor of government regulation to help the poor and achieve other social goals. I also agree that unions were important historically in improving the standard of living in America, if only because of the lack of other options. However, I don't think most unions are good for society at large today, and I think government protection of unions should end.

I'm not about to get into an argument about why I think all this, particularly not on Slashdot. I only posted to object to your implication that collective bargaining as we know it today is the result of a free market. It's the regulations prohibiting the employer from firing union members that require them to negotiate. Otherwise most unions would be destroyed pretty quickly.

You were the one who first mentioned free markets, not me. You were trying to paint today's teachers' unions as the product of a free market (or at least that's how I read "Should they not be allowed to negotiate their best pay package? Don't you trust free markets?" in your post). I never said I supported totally free markets, and I don't.

It's not nuts at all: it's the only way to break a union. It's how Reagan destroyed the air traffic controller union, for example. I also recall reading years ago that when a Canadian Wal-Mart's employees tried to unionize, Wal-Mart couldn't fire or otherwise penalize them under local law, so instead they simply shut down that store.

I'd go so far as to say that firing people is the standard response to a strike, where it's legal. The employer is hurt, but the union members are hurt far more – so the next batch knows to never try that again. If firing people for job actions were legal (they're deliberately not doing their job . . .), most unions probably wouldn't exist.

Sure I do. In a free market, an employer would be able to fire anyone immediately as soon as they so much as joined a union, let alone took any job action. But doing that is generally illegal, and that's the sole reason most unions can exist today. If a union can exist without legal protection (as was often the case in the 1800s and early 1900s), I'm not necessarily against it.

But then all your grades get sent to the school, right?

SSDs have plenty of capacity. The problem is price per unit capacity. You can get 1 TB SSDs . . . they just cost over $3000. (But one of them claims 1.4 GB/s read/write speeds. Nice.)

True, but you're not going to get the same experience as an actual native <video> implementation. You might be able to implement the HTML5 video APIs, but that would take work. You'd also have a hard time making it work correctly with CSS, etc. You could only do an ugly hack this way, not a proper implementation. So I think it's more likely that sites will just encode to both VP8 and H.264 rather than try to hack something like this up for Firefox.

It's not possible to compute p(A and B) from just p(A) and p(B). You need other information, like p(A|B) or p(B|A). For example, flip two coins, X and Y. If A = "X is heads", B = "Y is heads", then p(A) = 1/2, p(B) = 1/2, p(A and B) = 1/4. If A = "X is heads", B = "X is tails", then p(A) = 1/2, p(B) = 1/2, p(A and B) = 0. So the gate couldn't possibly mean either of those things.