That’s no less true than games written in C, or otherwise with few dependencies. Doom is way more portable than RCT precisely because it’s written in C instead of assembly.

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.

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.

compressed instruction set /= variable-width […]

Oh for sure, but before the days of super-scalars I don’t think the people pushing RISC would have agreed with you. Non-fixed instruction width is prototypically CISC.

For simpler cores it very much does matter, and “simpler core” here can also could mean barely superscalar, but with insane vector width, like one of 1024 GPU cores consisting mostly of APUs, no fancy branch prediction silicon, supporting enough hardware threads to hide latency and keep those APUs saturated. (Yes the RISC-V vector extension has opcodes for gather/scatter in case you’re wondering).

If you can simplify the instruction decoding that’s always a benefit - moreso the more cores you have.

Then, last but not least: RISC-V absolutely deserves the name it has because the whole thing started out at Berkeley.

You’ll get no disagreement from me on that. Maybe you misunderstood what I meant by “CISC-V would be just as exciting”? I meant that if there was a popular, well designed, open source CISC architecture that was looking to be the eventual future of computing instead of RISC-V then that would be just as exciting as RISC-V is now.

The original debate from the 80s that defined what RISC and CISC mean has already been settled and neither of those categories really apply anymore. Today all high performance CPUs are superscalar, use microcode, reorder instructions, have variable width instructions, vector instructions, etc. These are exactly the bits of complexity RISC was supposed to avoid in order to achieve higher clock speeds and therefore better performance. The microcode used in modern CPUs is very RISC like, and the instruction sets of ARM64/RISC-V and their extensions would have likely been called CISC in the 80s. All that to say the whole RISC vs CISC thing doesn’t really apply anymore and neither does it explain any differences between x86 and ARM. There are differences and they do matter, but by an large it’s not due to RISC vs CISC.

As for an example: if we compare the M1 and the 7840u (similar CPUs on a similar process node, one arm64 the other AMD64), the 7840u beats the M1 in performance per watt and outright performance. See https://www.cpu-monkey.com/en/compare_cpu-amd_ryzen_7_7840u-vs-apple_m1. Though the M1 has substantially better battery life than any 7840u laptop, which very clearly has nothing to do with performance per watt but rather design elements adjacent to the CPU.

In conclusion the major benefit of ARM and RISC-V really has very little to do with the ISA itself, but their more open nature allows manufacturers to build products that AMD and Intel can’t or don’t. CISC-V would be just as exciting.

Kinda. IANAL, but here’s my understanding: If you’re explicitly dual-licensing and publish the proprietary license then contributions can be assumed to also follow the same dual licensing. You’d need to be extremely careful with writing the proprietary license though, since your business is now using non-employee proprietary code.

If you write “the copyright holder may choose to allow an entity to use this work”, then you do actually need permission from every contributor. If you write “this work may be copied, modified and redistributed freely by Blah enterprises” now the business cannot be sold without losing access (or possibly have it’s name changed). If you write “Neshura may freely copy, modify and redistribute this” then you can’t be fired or move jobs without the company losing access.

You can also never ever change this license, since every contributor needs to agree. So if a mistake is made when writing it you’re just fucked.

On the other hand with a CLA that transfers copyright ownership you don’t need to dual-license at all since everything already belongs to the business. Much less risky.

Only until you have any other contributor, as you’re then no longer the sole copyright holder. If you still want to work like that you’ll need a CLA.

CRTs (apart from some exceptions) did not have a display buffer. The analog display signal is used to directly control the output of each electron gun in the CRT, without any digital processing happening in-between. The computer on the other end however does have display buffers, just like they do now; however eliminating extra buffers (like those used by modern monitors) does reduce latency.

if youre boiling water, it can be any arbitrary temperature above 100.

That’s not how boiling works. The water heats up to its boiling point where it stops and boils. While boiling the temperature does not increase, it stays exactly at the boiling point. This is called “Latent Heat”, at its boiling point water will absorb heat without increasing in temperature until it has absorbed enough for its phase to change.

There is an exception to this called superheating

100F is a fever; if you’re experiencing those regularly you should go see a doctor.

TLDs are valid in emails, as are IP V6 addresses, so checking for a . is technically not correct. For example a@b and a@[IPv6:2001:db8::1] are both valid email addresses.