Think of it like this: would you think highly of a physics/engineering book that showed free body diagrams with mistakes in them? This is the same kind of a thing. It's a hack job that could have be made into something great, but wasn't.
Slashdot videos: Now with more Slashdot!
I must be weird then. I tried to kill myself once, and I put extra care into making sure that I didn't make anyone suffer unnecessarily. Sure I had family and whatnot, their suffering couldn't be helped, but I chose a way to go that would not expose any additional people to suffering, and certainly I couldn't even imagine physically hurting anyone while doing so - it'd be a truly despicable act. The way I went about it, it'd be very unlikely that anyone would accidentally find my body or witness my death.
Frankly said, H&H was, at least in the editions I had access to, full of circuits that either outright didn't work, or barely worked, and seemed like a slightly overpraised hack. I don't recommend that book to anyone.
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.
especially as it transfers a lot of stress onto the weakest part of the socket (the contacts).
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