As crazy as it might sound, the GP-B mission has validated means of following a zero acceleration orbit with sub-micron precision. The precision achieved was that the residual acceleration was on the order of 1E-11 g. So yeah, we can definitely follow a zero-acceleration orbit with crazy precision!

Everyone here seems to forget that a variant of Pascal is, for better or worse, also standardized as an IEC 61131-3 language. It's called Structured Text (ST). It is in rather widespread use in industrial automation. ST is also one of the languages you can use to write the actions of the Sequential Function Charts (SFCs), also known as Grafcet. SFCs provide most of UML State Diagram functionality. Standardized support for state machines is still not in C++, after so many years!

So Pascal isn't dead in the mainstream, it's just that it's not the mainstream you might think of. A lot of products in your fridge have been packed in machines controlled in part by Pascal code.

I wrote a lot of I/O code/drivers in Pascal, and also what would pass for a rudimentary run-to-completion realtime OS kernel. There was nothing fundamentally worse about it, compared to C, except for the lack of finesse in the code generator. It worked just fine, and I'd rewrite in assembly the few functions/procedures that had to be faster than compiled code.

If you are not a professional full-time driver then no, you have not. And if you are a professional driver, then still you have not been scored on your driving.

This government regulation isn't about protecting you from idiot drivers. It's about protecting you from the long tail of accidents that happen in spite of everyone following the rules. People aren't infallible. Occasionally, we make mistakes even with the best of training. Unless you're a race driver, your driver "training" is nowhere near the amount of training the olympic athletes receive. Yet, invariably enough, in every olympics there's a bunch of snafus committed by the best trained people. That should be the only thing you need to see to realize that, once again, no matter how well prepared you are, you will make mistakes even if your weally, weally wish not to. I mean fuck, these people are fucking competing for olympic medals. They are the best of the best worldwide. And they do mess up. So yes, no matter how good you think you are, you will commit random errors on the road that may prove deadly. The regulations and the technical means here are to make those random things less deadly. That's all.

I think that the part of the issue is that there's really not all that much standardization that has force of law when it comes to ECUs. It's sad to see that they use an ECM that has such silly issues.

The printed part is a concrete skeleton that acts as a form that needs to cure and then be filled with concrete. None of the finishing work is printed. It is basically a cast-concrete structure, where the typical metal forms were replaced with a 3D-printed skeleton. Of course the printed skeleton is a couple orders of magnitude rougher than what you'd get with metal forms, so the walls need heavy finishing before they can be presentable.

What they've done is perhaps a step in the right direction, but they are very, very far from truly 3D-printing an entire building. First of all, they'll need to have an inline concrete mixer that can continuously mix a fast-curing mix, so that they could print shapes that are filled-in. They also need to change the shape of the nozzle so that the deformed (compressed) shape will be rectangular, and not oval as it is now. They really did everything without much thought or understanding of what it takes to do it right. It is, at best, cargo cult 3D printing. They did all the right moves without understanding what it really takes to do it.

Nope. They simply don't take all cases to trial, and some crimes go unpunished. As happens now anyway, since with a plea bargain you're punishing some other crime, not the one that really happened. You really need to look outside of the U.S. legal system. In many a European country, a crime won't be prosecuted for the reason that it had low social consequences. It's IMHO a rather valid reason not to prosecute, it's in fact what the U.S. prosecutors have yet to learn. Yeah, the law says that you shouldn't smoke marijuana. Yeah, you did break the law. No, it didn't really cause much suffering for anyone. Thus, no prosecution. That's how it's supposed to be in the civilized world. Of course, ideally we shouldn't have stupid laws to begin with.

You're just making a bunch of stuff up. Plea bargains and prosecutorial discretion are entirely separate issues. What, you think that in jurisdictions without the plea bargain, the prosecutors take all cases? You're nuts.

The problem is that you have a system that's not inherently safe - it merely rides on the unproven safety of one single component. A resilient system would have many barriers that you have to break down in order to gain access. This one has just one. For all we know, it has already been broken.

Electrically-programmable fused PROMs suffer from bit rot and simply are not made anymore. I hate the damn things with a passion, they are one of the causes of good legacy test equipment turning getting bricked. The legacy OTP EPROMs require high voltage for programming and the only concern with them is slow charge decay. These days, it's FLASH all the way.

Alas, you're making up imaginary problems. Every high-rel firmware-based system will not only verify the integrity of the firmware upon boot-up, but continuously during operation. I mean, heck, we're not even talking about the cars here - my washer and dryer are both running continuous firmware CRCs in the background, all the time, as well as RAM integrity and plausibility checks.

Never mind that the inside of an ECU module is quite isolated from exterior noise. Every circuit going through the box has extensive filtering and surge protection. The logic supply voltages will be within spec all the while the battery voltage swings every which way (think of a range from single volts to a hundred or two).

It's not hard, it's simply not part of the usual product specs. The device is supposed to do stuff, that's the primary thrust when doing the development. The mindset of the entire industry must change before we start expecting things to be secure but otherwise buggy first, not - as it is now - functionally perfect but insecure.

Moreover: which cycles? Core? FSB? Memory? Eh? Under what test conditions?

Given that we had 80-bit extended precision FPU registers in 8087 chips 30 years ago, I don't think the 64-bit path/register assertion holds any water. I have lots of code that uses 128 bit registers and runs on pretty boring consumer CPUs. The reason to increase data path width is not to address more data, but to increase the throughput. I use 128 bit registers with code that uses no virtual memory and runs with a couple MBytes of RAM.

I was running VMs on Z80 hardware - it was slow, since they were software-emulating the CPU (I did 6502 and Z80), but hey, you don't need any special hardware or CPU features for virtualization. The special features are performance optimizations, nothing else.