That is what I am arguing. An "engineering disaster" requires a bit more than it just being a crappy car.

Sort of makes sense if he's going to do revisionism on so spectacular a design fuckup as the Pinto where even a layman can see the accident waiting to happen.
Next up - revising the "Liberty Ship" fuckup and extended coverup that led to more sinkings than the German U-Boat fleet until the press took a photo of one broken in half in the fitting out dock. Let's revise it to it all being OK because the corner cutters made a pile of money out of it thanks to the taxpayer and that's the way corporate American should be - none of this pesky accountability.

Bullshit. That was before high strength low alloy steel shaved a lot of $ off the price of the car. There were expensive bits just for cosmetic purposes back then.
The Japanese were building cars for a lot less than Ford back then but Ford and GM didn't care or notice.

True, but it is easier this way than to store non-redacted copies on the side when you want to use them in court later. (They are not letting go of that data. No government agency ever will unless forced to in a way they cannot ignore...) And most of the general public will be too stupid to know or understand.

IMHO it's nowhere near ready yet but other opinions can vary.
I think like Pulseaudio and NetworkManager before it the software has been rushed out in an alpha state and that's a systemic problem with RedHat and gnome which has spread to other distros (via gnome).

The problem above was on a developers machine where he had a typo in the hostname of an NFS mount so the entire thing locked up on boot and needed to be started up from a rescue CD. That's a newbie level fuckup and not something a person writing an init system should have problems with by the time they tell people their software is ready for release.

I've seen another where a system just would not start because the network card had been replaced - what a piece of crap. It's for laptops and not for hardware that may change.

With many BIOSes, mice and keyboards do not work on USB hubs. That is two. The third one is for anything else.

It is actually a pretty good example, because it was not "an engineering disaster". That is just what the incompetent public mistakenly concluded.

If you had read TFA, you would know that the "fix" did not help one bit, likely because these cases of fire mainly happened at speeds where nothing practical can prevent the tank from rupturing. TFA does not say whether Ford knew that though, but they may well have.

Indeed. Just as the primary problem in IT security, for example, or in medicine.

Well, it says there was no reduction of fatalities from requiring gas-tanks to survive impacts up to 30mph (the pinto failed at 25mph, while others failed at 27-28mph). Assuming that the "fix" was installed (which is sensible, as there was a recall), it did indeed made no discernible difference.

The thing that the public needs to learn is to trust engineers. Sure, engineers are subject to political pressure, so have the public bring in their own engineers. But they _must_ be engineers. Anybody else will get it wrong and do (sometimes far) more harm than good.

And safety engineering is getting degraded by their need to not stick out with one failure that is far more pronounced than in other models/brands, even if they manage to reduce overall risk that way. Stupid.

Very much this. Like worrying about flying, but not about the drive to the airport, when the latter is far more dangerous.

Really, stay away from process management. You do not have what it takes to get it right. And your desire for the respective systemd-functionality now becomes abundantly clear: You want it to do things that you are not smart enough to do yourself. That is not good engineering at all.

I re-iterate: Process management is not the task of an init-system. It can only suck at it. The sysV-init designers realized that and only provided the bare minimum, leaving the actual service designers to do their own that does it right. Systemd instead tries to solve a problem it has no business solving. That is not good at all.

I cannot see how you can be more dishonest, greedy and evil as a researcher. If anything in IP deserves to be called "stealing" then this is it.

How can a service handle a situation when it is down? The services have to register in advance how to handle things. Moreover other services might still have issues.

  B depends on C and C needs to reinitiate with B, but D is also talking to C. How does the new B signal C?

As for it being contrived that's one of the key issues in process management how to handle chains and stacks of processes. That doesn't happen much in the sysv world because sysv handles it so badly that everything ended up having to write its own process manager.