If you want to wait 45 minutes for your potatoes to cook, it's your thing. It's not my thing, though. Mine are done in 15 after the steam valve starts venting. Fuckin' big ass russets, uncut. If that means that i'm stuck in the 70s, so be it.

You don't know much about how to cook, then. Do you think that suddenly, what has worked for cooking in 1970s, doesn't anymore?

So, hybrid and electric owners magically wear the roads less? I don't think so.

I personally would love a per-mile tax at such a rate. Heck, I'd be OK with 2 cents. I pay more than that, per mile, in taxes at the pump. I drive about 400 miles per month, so that'd be $8. As far as I'm concerned, my and my wife's road use taxes wouldn't even zero out my state tax refund, and I'd be paying less at the pump. Win-win.

There has been much improvement in lowering thread and sync primitive overheads since 10.6, as well as improving the scheduler. About the only thing OS X really doesn't like is mechanical hard drives - it performs much worse from 10.9 onwards than Windows when you have a mechanical hard drive.

I do it on modern hardware, in production, on a 125us update cycle in the velocity loop, using off-the-shelf everything and old Dell PCs for prototyping, and it works, so perhaps you're doing something wrong.

It's just a collective whoosh :)

It's not that fast, actually.

It's not, and it doesn't run on tiny systems either. It requires ~300MB of RAM just to boot up. It's basically a hack done to stroke someone's fancy. It's not practical in any sense of the word. You could rewrite it in C and it would run just as fast. Its speed is mostly related to the architectural choices, and many of them are just plain wrong. Way too much of the API is blocking - that means that the internal architecture is broken, pretty much, and won't scale, and wastes power. It's basically a demonstration of a cargo cult approach to design: someone thinks that if only they do a ritual (assembly), it'll be fast.

That's the whole point. It's not open source. The 32 bit kernel is old and not developed anymore.

There are other problems in the architecture of this, where the fact that they use assembly simply doesn't help. When you're talking of speed and power efficiency, you need a good scheduler, timer coalescence, event-driven non-blocking code, etc. Having a judiciously done architecture in C could make it much faster than Menuet is. The assembly circlejerk doesn't make much sense, at least not to me when I write low-level, bare-metal C almost every day. You could generate almost identical assembly from a modern C compiler - it's all about architecting the same. I only write assembly when there's no way to coax a C compiler into producing the code that's fast enough, and even that only makes sense for backwards architectures that have old C compilers.

There are synchronized spindle paper machines/offset printers, running on top of Windows and CODESYS, where if the realtime cycle is late twice in a row, the whole thing throws the emergency brakes on, and you have lots of cleaning-up to do, and costly downtime. And, frankly said, it just doesn't happen, not because of the BIOS or any other monsters are in your closet. So there.

There's more that I forgot to add: there are tons of EtherCat-based I/O available for cheap on eBay, so as long as your old Dell box has an Intel ethernet adapter, or you add one to it, you can have distributed, hard-realtime, fast I/O all over the place - no need for stupid parallel port bits if you can buy a bus coupler and dozens of I/O modules for under $100. And you can easily do realtime distributed variables between your hosts, if you have more than one host, etc. And it's all cheap.

Given that Beckhoff's TwinCAT 2 and 3 - both free downloads - allow just that, and much more, I don't really see the point. Heck, anything that uses the realtime CODESYS stack allows you to do that, it's just that I know of TwinCAT. All those old Dell machines you may have hanging around can be great PLCs. Heck, the PLC (61131) libraries include functions that access hardware ports directly from realtime code, so you can bit-bang your parallel port with 1-2 microsecond jitter, if you wish so.

Best thing? It runs on top of standard Windows (XP or 7).

IOW, if you value your time, you won't care about such hacks. If you really want to run 61131 languages on bare metal, just get your CODESYS license, use an existing BSP or write your own, and you'll be set.

That's only moronic if you don't understand what you're reading. Nobody is talking of removing all means of manually controlling the car - only the means that don't make any sense in a self-driving car.

I'd much rather have a nice sidestick instead of the stupid steering wheel + pedals contraption. I'm thinking of putting one in my car, actually, with the RHD dash airbag assembly. The instrument cluster can go in the middle.

Everything depends on where you are. There are places, even in the U.S., where incident rates are a couple times over the national average.