You can tune the piano for any temperament you wish.

Motors at the wheels actually don't make much engineering sense. They only look sensible if you haven't run the numbers and haven't done real design work. Most electric cars out there are not gas platforms, and would make very poor gas platforms. So you kinda made your problems up.

When you connect/disconnect them, the high current circuit is off. There's only a limited-current control circuit available, and I'm not sure if that circuit isn't designed for inherent safety in explosive environments. It certainly could be.

So, Microsoft is still Microsoft. Good to know.

Firmware is stored on the magnetic medium on hard drives, so I don't see why they'd do it any other way on SSDs. Over the hundreds of millions of drives shipped, not having a large dedicated firmware flash saves real money.

It'd be a rather different design today. These parts simply had a process issue, they'd have failed whether they were ROMs or something else.

I presume that the drive treats its firmware as just a special range of blocks/sectors, subject to the same management as everything else. Eventually, you power cycle it, and the bootloader can't find any viable firmware blocks. It then appears bricked. That's the only explanation I see.

There are no limited lifespan devices on an RPI, of any revision, other than flash memory. If you replaced the boot flash and SD flash with mask-programmed devices, it'd certainly boot a 100 years from now. No doubt about it.

Nope. We have space hardware out there that is in very bad, high-radiation environment, and has lasted for decades. The capacitors aren't a problem if you designed the system to last long.

That's what tantalum and ceramic caps are for. BTW, there are zero electrolytics in the RPi.

About 80% of my work is embedded. You still writing out those state machines by hand? Tsk tsk tsk. I can't even begin to imagine being productive in embedded work without lots of code-generating tools. With a proper high-level language used to define communications protocols, for example, I can do in a day what would probably take me two weeks after all bugs are out. I have many such examples. I only use code generation because it works. And the code it produces can be as pretty, readable and comprehensible as I want it to be.

That's quite hard to pull off, in fact. Mr Young and his modulus would like to have a word. When you have a composite of two materials, the less deformable one (metal vs. plastic!) will transfer more stress, when subjected to external loads. In a Lightning plug, the plastic mold around the Z (vertical) contact strips carries mostly the stresses related to shear forces on the contacts themselves. It's mostly isolated from any gross insertion alignment forces.

That's why I insist that you can't analyze such things without relevant mechanical engineering background. It just sounds silly.

BTW, Ligtning is mechanically a Molex design - let's put the credit where it's due :)

There aren't, because C++11 is, well, a standard for 4 years only, and C++98 implementations were spotty well into the middle of the following decade. Finally, not that many people are writing kernels from scratch...

I'm sorry, you're really doing it wrong, and I'm not trying to pull a "no true scotsman" on you. moc output code doesn't have to be readable, even though it's not an outright mess. For other code that you'd be writing generators for, it's on you to make it readable, and with the right approach it can work wonderfully. The 0mq folks use their own tool, gsl, and even though their own use of code generation inside of gsl is an abominable mess, you can actually use gsl to generate some very nice, readable code. In fact, the whole point of such code generation is that it will be, by necessity, much more uniform and of higher quality than handwritten code - once you debug the generator, it'll do its job whether you are tired or not.

It's not the only tool like that out there. If you're masochistic enough, you can even write code generators in xslt :)

That's what external monitors are nominally for - the standard USB C laptop setup is with an external monitor acting as a USB C dock. Finally, with USB C you can actually use non-Apple power supplies to keep your laptop going. There will be such products available very soon from a lot of third parties.