__dev

The source is this survey/article by axios: https://www.axios.com/ford-pickup-trucks-history

That's simply the paradox of car-centric design: It also sucks for cars. The only way to actually make driving better is to provide viable alternatives.

Shared dependencies or death
Docker

🤔

See https://www.youtube.com/watch?v=RJh9yTIBY48 for potassium chloride as well as the other alkaline metals.

Not sure what you're expecting that fuse to do when the battery is on fire from crash damage?

BEL is alive and well in unicode: https://unicodeplus.com/U+0007

Around half of disabled people can't drive, but everyone who can drive can use some kind of micro-mobility.

No difference in mileage, maybe. Certainly a huge difference in danger to pedestrians and cyclists.

All those Europeans towing with their small cars must just be my imagination then.

3000 lbs is well within the towing capacity of a VW Golf with a braked trailer. Not to mention a van.

It's a long story. In short: In Latin script u and v were the same letter "u" but had two pronunciations depending on whether it was being used as a vowel or consonant. But when adapting the alphabet to Germanic languages (including Old English) the same two sounds were from two different letters, so they put two "u"s together to make double u: vv.

The full story: https://www.youtube.com/watch?v=sg2j7mZ9-2Y

I'm more familiar with RISC-V than I am with ARM though it's my understanding they're quite similar.

• ARM/RISC-V are load-store architectures, meaning they divide instructions between loading/storing and doing computation. x86 on the other hand is a register-memory architecture, having instructions that do both computation as well as loading/storing.

• ARM/RISC-V also have weaker guarantees as to memory ordering allowing for less synchronization between cores, however RISC-V has an extension to enforce the same guarantees as x86 and Apple's M-series CPU have a similar extension for ARM. If you want to emulate x86 applications on ARM/RISC-V these kinds of extensions are essential for performance.

• ARM/RISC-V instructions are variable width but only in a limited sense. They have "compressed instructions" - 2 bytes instead of 4 - to increase instruction density in order to compete with x86's true variable width instructions. They're fairly close in instruction density, though compressed instructions are annoying for compilers to handle due to instruction alignment. 4 byte instructions must be aligned to 4 bytes, so if you have 3 instructions A, B and C but only B has a compressed version then you can't actually use it because there must be 4 bytes between instructions A and C.

• ARM/RISC-V also makes backwards compatibility entirely optional, Apple's M-series don't implement 32-bit mode for instance, whereas x86-64 still has "real mode" for running 16 bit operating systems.

There's also a number of other differences, like the number of registers, page table formats, operating modes, etc, but those are the more fundamental ones I can think of.

Up until your post I had thought it exactly was the size of the instruction set with x86 having lots of very specific multi-step-in-a-single instruction as well as crufty instruction for backwards compatibility (like MPSADBW).

The MPSADBW thing likely comes from the hackaday article on why "x86 needs to die". The kinda funny thing about that is MPSADBW is actually a really important instruction for (apparently) video decoding; ARM even has a similar instruction called SABD.

x86 does have a large number of instructions (even more so if you want to count the variants of each), but ARM does not have a small number of instructions and a lot of that instruction complexity stops at the decoder. There's a whole lot more to a CPU than the decoder.