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.

As long as it's driveable, it should keep on driving - precisely the opposite of what most people would do. So yeah, I'd go with autonomous any day in such a situation - I can duck and cover and don't have to pay attention to the road.

I hate these people, just so you know.

Has your laptop been tested to work under water? I mean, shit, I like to sit and read in the bathtub, it'd be nice if I could, well, rest it on my lap, with the bottom half submerged you know. If I'm not coming across clear: the goal of a test program isn't to send people to the moon on a first launch.

Now you're anthropomorphizing and it sounds really silly.

So, you're making shit up. At least we know who you're paid by.

No. But before they even think of selling such a product, they must have a plan for customer disclosure and field updates in place, as otherwise offering such product becomes a big liability once the first vulnerability disclosure gets into the open. Here at least they were informed about it in advance, someone else could have simply leaked the disclosure anonymously.

The company in question have set themselves up for failure, and I'm not very sympathetic to their plight. If you distribute shit with firmware in it, you have two options:

1. Don't worry about upgrades, but apply a software development process that would be applicable to a "launch and forget" space mission. Thus you invest up front into ensuring that the damn thing will perform to specifications before you launch it. It's expensive, but you can truly deploy the product and at least have a lot of tangible evidence that you applied state-of-the-art engineering to ensuring that the customers should be secure. You did your due diligence.

2. Use a loose development process, and ensure that there is a (perhaps tiered) system of customer notification, field upgrades, and service contracts.

This is a no brainer really, if you've got half a brain, that is.