Well first of all Linus has never been overly concerned with market share, just building a technically damn good kernel so I doubt this will have much practical influence on his work. It's got to be frustrating though, Linux works on massively huge and complex servers. It works on the smallest mobile and embedded devices. But a regular desktop that from the kernel's side is rather simple, one CPU and usually one GPU and pretty much no exotic devices (from the kernel side all USB devices look the same, for example) and no absurd limits being pushed in any direction.

I think the last real significant desktop feature was when they increased interactivity by changing the default time slice from 100 Hz to 1000 Hz and that was in 2004 or so. Heck, I would say it was at least as ready as the BSD kernel was when Apple created OS X in 2001. It's quite telling that the one thing Google did not want to rewrite when they made Android was the kernel. All else they ripped out and replaced with Apache licensed code, but not that. Well that and a bunch of Google proprietary APIs, but that's another flame war. I think I'd feel just the same in his shoes.

Given our track record with Juniper, "drop everything and patch now" is a foolhardy approach, especially with something as important as a border router or firewall. I wouldn't apply any of their patches without seeing a long track record of safety. With heartbleed there was an unknown level of risk that they would be attacked; with any given Juniper patch there is a known risk the network would just go down.

Of course, given the choice, I wouldn't select a Juniper device to route packets to a doghouse, and would never place one as a mission critical node on any network. Then again, that's not my choice to make, just one we have to live with.

They're solidly in the realm of the legal in the US because of USC 17 512(d):

If they don't respond to DMCA notices they fail condition (C) and become liable. This has been established legal history since way back when web pages used to link to illegal MP3 files, perhaps longer. It's not true in the general case, just because you point them to other website that might contain something illegal won't get you into trouble. But pointing directly to infringing content and claiming you aren't liable because you're not the one hosting it doesn't fly.

What drugs are you on really? You make as much sense as saying that because this knife didn't come with an EULA not to behead unbelievers the manufacturer supports what the Islamic State is doing in Iraq/Syria. I've never to my knowledge bought or owned anything that has a political agenda as condition for use and newer will. I do care how they were produced (no child labor, animal testing, destroying the rain forest, social dumping or so on) but I'd never buy a car that had the gall to tell me where I could and couldn't drive in the EULA. So are you nuts, a troll or just trying to kill OSS? Because you make RMS look pragmatic.

I think he was just pinging me for the ideas, which do predate my efforts and is certainly fair -- I started my whole "object" approach to c in 1985.

Of course, the whole point was to avoid using compiler tech that generated code I didn't intend it to generate, and in that sense, I got what I was after.

I wish I could still write my code in assembler, though. I was never more at home than when churning out 6809 or 68000 code.

Since that's not actually a license, I pick lightsaber. Not as clumsy or random as C++. An elegant weapon, for a more civilized age.

Thanks, looks like very interesting reading. Bookmarked it.

Of course if you take into account the energy expenditure it will take to pull the excess CO2 and other chemicals back out of the atmosphere, that number goes down a bit.

(Impractical to do, and therefore will never be done, you say? Okay, take into account the costs of living with a permanently impacted atmosphere, instead)

Why instead of? We can (and should, and will) do both.

Apparently the sound from your mic and the echo from your gyroscopes were both parsed by your speech-to-text converter. I guess it works better than we thought!

Apple fixed that problem. The iPhone has no battery door, so it can't be removed in case you don't want the phone to spy on you.

When you look at the technical advancements in agriculture, they're composed of small features integrated in to (or bolted on to) existing equipment. You don't need a new tractor, you just need to mount a GPS receiver and a database onto your old one. A processor no bigger than a cell phone can do lots of that. Adding electrically operated valves to an existing fertilizer or pesticide spray system? Again, very small. It doesn't have to auto-steer, it just has to know where it is, and where it's been.

The makers don't have to build the tractors, they just want to improve them.

I realize reading the article is considered bad form, but if you read it you'd learn they think they were breached sometime between April and June. Heartbleed was announced in April. That's somewhere between zero to two months. Lots of big shops have a monthly patching cycle, and you don't just drop every patch into a mission critical system the day it arrives.

They said they think they were breached sometime between April and June. Heartbleed was announced in April. The window was zero to two months, not five.

And it's not that data security is a low priority, it's just that it may not be as high a priority as network availability. This is health care, where problems in communication might affect patient outcomes. "Hey, sysadmin, Doctor Green couldn't respond to his page last night, and the patient died as a result." These are the kinds of arguments that are thrown at the IT departments at every health care provider. Whether or not we consider them rational or valid is irrelevant.

So in that backdrop, we might try to understand that they probably don't just slam in every patch that the vendor has to offer, at least not without a giant process circus. I would guess that they have a patch intake process, where they have to run the patch by some engineering team that evaluates the nature of the patch, and devises some kind of testing plan to execute in their lab environment. They then have to pass it to the testing team who will set up and execute the patch process in the lab, document all their findings, and then turn the patch over to the production network team. They'll put it on their list, and they'll have their own manager who says "whoa, why are you security guys rushing to slam this patch in to my border router? Let's slow down and think about this one."

I could easily see it taking a month in a big, regulated corporate environment.

If that is true, why do the wheels need skin in the first place? I doubt anything on that mission is there for decoration...