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.

I think that everyone here forgets how that USB C receptacle is meant to be used. In a year or two, you'll have monitors with USB C connectors on the back. Those monitors will provide both power and data over USB C. They'll probably also provide a couple USB 2 or USB 3 receptacles for backwards-compatibility, although you can just use a USB-C to USB 3 or USB 2 cable. You won't need a dongle. It's a short-term stop-gap.

The way USB C is meant to be used is that you have a monitor with a bunch of USB C receptacles in the back. You plug in your wired keyboard, your LEAP motion controller, your hard drive, and your laptop all into USB C receptacles in the back of the monitor. You don't need any other connection to the laptop - it's powered, it feeds the display its data, and it communicates with other USB peripherals. That's what USB C is designed for, and that's a future I look very much forward to.

The main difference between USB C and Thunderbolt is the implementation cost, and the applicability of USB C to low-end devices that only push 12 Mbit data over the link. It's not really cost effective at the moment to implement Thunderbolt in a $5 keyboard. USB C? Sure. It's just USB 2 with a different plug at the end. You can have it in a $0.90 microcontroller, less if you use a high-volume custom part. That's also why a bog standard monitor gets much more added value by implementing solely USB C than any other connection standard.

Have you actually looked, seen and understood what you're talking about?

A Lightning connector has the mechanical properties of a metal slab, more or less. It's a cast metal part, encasing a PCB, with some molded-in Z connector strips. It's more durable than a piece of anodized duraluminum of same mechanical dimensions.

A Micro USB connector is a flimsy sheet metal case, with the front and back open, with a set of flimsy contacts on a plastic carrier inside of it. Both the plug and the receptacle have cavities that, over time, get filled with dust, and both have long, unsupported, very delicate parts that just wait the be pushed against and buckled. It almost seems like someone with no mechanical engineering background designed that thing. It's a design that a mechanically oblivious EE might come with. It is, mechanically, about as inferior to Lightning as practicable. Everything they could fuck up, they did.

As a mechanical engineer, I consider the mini and micro USB connectors to be evil abominations. Say what you wish about walled gardens, but the Lightning plug is an outstanding design, mechanically and electrically. The receptacle is just as superb. I'd love it very much to just drop the micro- and mini USB connectors overnight, and adopt the Lightning connector for USB.

I don't even know what the fuck do people think when they insist that USB 2.0 is somehow CPU-hungry. I have developed fixed function hardware (a small FPGA - too small to host most soft CPU cores) that can push 100 Mbits/s from a 5MHz A/D converter over USB, and wrote firmware for fairly small microcontrollers (64kb code space) to receive said USB data and dump it to disk. It all works in hard real time, too. And I mean hard real time - the on-disk layout is pre-allocated before the data is to be transferred, so that as long as the hard drive doesn't die in the middle of things, it truly has guaranteed bandwidth with very minimal buffering (a couple USB and SATA transactions worth).

The only reason USB is considered CPU intensive is because people with no understanding of how scalable protocol stacks are to be implemented got their hands on the host driver architecture, and the same caliber of people also write userland drivers that make me cringe.