I own few of these, and you are look at this with rose-colored glasses. First, carburetors and early mechanical injection systems sucked. Second, no safety features whatsoever, not even ABS, means that you really have to take it easy in all but perfect road conditions. Third, with 40+ years of use, even well-cared mechanical systems start falling apart in unexpected way. Fourth, even when everything works most sports car from that era couldn't keep up with modern-day Corolla.

Having daily-driver classic car is a rare distinction, this means you are ether loaded or exceptionally good DIY or often both.

This is response to security researchers showing how vulnerable cars are. Automakers decided that the best way to stop malicious attackers from exploiting numerous vulnerabilities is to go after white hats with paid-for legislation.
 
Idiots.

What do men need education for? Everyone knows than man's place is in the kitchen! Everyone knows men attend higher education only to find an eligible wife to care for them.

Time to start masculanism movement, because anti-male gender discrimination hit mainstream.

I didn't know Columbia University had such a strong community of voyeurism fetishists in the engineering department. Otherwise, why would anyone want low-quality, discrete, remotely accessible and insecure (IoT) cameras that don't require maintenance? Everyone already has smartphone cameras that are readily available and can be connected.

I don't think you are fully considering the possibility of maliciousness. RdRand, because of on-chip whitening is completely opaque, there is no way to audit its functionality. How can we trust something like that with such crucial cryptographic functionality? If your seed your RNGs with predictable seed, then all of your crypto can be easily broken.

Sure, if CPU is backdoored, then your system is compromised no matter what you do, and it can leak all secrets in whichever way. Most of that can be detected post hoc or even heuristically. What is insidious about potential RdRand-based backdoor is the leak would take form of normal functionality, so there is no payload or suspicious communications to intercept and reverse-engineer.

I am not saying that RdRand should not be used, I am saying that RdRand should not be used in a way that makes system that easy to compromise. Why, for example, Ts'o did not use mixing function for this? Whole implementation reads like an entry into underhanded crypto competition.

RdRand could be non-random without negative impact, but what if it is maliciously non-random? For example, manipulating RdRand to consistently pump duplicate of the output buffer will result in a very compromised seeding (0x0000..).

This won't work nearly as well as the authors expect. The moment such system gains adoption, the rules will change and anti-detection and algorithm poisoning techniques will be adopted. For example, proposed approach would likely be completely defeated by first making 10 "constructive" FAQ copy-paste postings. Also, spam is much easier to detect than trolling, since spam is not unique. Still it took years and complicated spam-detecting analytical algorithms to reduce it to manageable levels.

Are they planning to adjust how RdRand is used in random.c ?

I keep mine on. While it could be annoying, if you don't expect it to show up and it does, it is huge red flag for you to start paying attention.

Web of trust cannot survive politics, if we tolerate any bad behavior from any trusted parties, then nobody could be trusted and whole construct falls apart.

I have some bad news, your brick have been leaking cryptographic keys via heat signature side channel for months now. I should have your root any year now.