I think you are referring to BEV cars. The definition of EV includes hybrid and plug-hybrid (which the fine article is about, by the way).

I don't understand if your comment is ironic. Intel is notorious for equipping different processors produced in the same period with different features. Sometimes even among different cores on the same chip. Sometimes later products have less features enabled (see e.g. AVX512 for Alder Lake).

> A flat-earther would just tell you that you're not able to maintain a straight path over such long distances without relying on external guides that would definitely put you on curved paths.

Do flat-earther reject the existence of LASER, too?

Flat-earthers don't accept that a flat plane implies infinite line of sight (especially at sea), so who knows.

What has always baffled me is how CS uses the word "safety" where all other industries use "robustness".

A robust design is one that not only is correct, but also ensures the functionality even when boundary conditions deviate from the ideal. It's a mix of stability, predictability and fault tolerance. Probably "reliable" can be used as a synonym.

At the same time, in all industries except CS "safety" has a specific meaning of not causing injuries to the user.

In the design of a drill, for example, if the motor is guaranteed to spin at the intended rpm independently of orientation, temperature and state of charge of the battery, that's a robust design. You'll hear the word "safe" only if it has two triggers to ensure both hands are on the handles during operation.

You use safety more in relation to correctness aspects of algorithms. Some safety properties you can actually prove. When it comes to robustness it is more about dealing with things sometimes being incorrect regardless of the safety mechanisms. So, a try catch for something that isn't actually expected to normally fail makes you robust against the scenario when that does fail. But you'd use e.g. a type system to prevent classes of failures as safety mechanism.

It's a very soft distinction, I agree. And possibly one that translates less well to the physical world where wear and tear are a big factor for robustness. You can't prove an engine to be safe after thousands of hours. But you can make it robust against a lot of expected stuff it will encounter over those hours. Safety features tend to be more about protecting people than the equipment.

Without any context safety _can_ mean a lot of things, but it's usually used as a property of a system and used alongside liveness.

Basically, safety is "bad things won't happen" and liveness is "good things eventually happen".

This is almost always the way safety is used in a CS context.

> What has always baffled me is how CS uses the word "safety" where all other industries use "robustness".

FWIW "safety factors" are an important part of all kinds of engineering. The term is overloaded and more elusive in CS because of the protean qualities of algorithmic constructs, but that's another discussion.

I think in things like philosophy/debate/etc it's common to talk about "safe assumptions". I always figured that's the metaphor being leaned on here.

I agree it's confusing when you step outside of CS world though.

> At the same time, in all industries except CS "safety" has a specific meaning of not causing injuries to the user.

That makes sense, as CS is transversal to industries. Same practices that can contribute to literally save lifes in one domain will just avoid minor irritating feeling in an other.

If this was true, teachers and trainers would have the easiest job in the world: just insulting their pupils would stop them from failing an exam, race or whatever again.

The comment is clearly sarcasm.

> Not sure what changed

IP4 address exhaustion.

Well done!

My remarks:

1) in calloc() you correctly check size*n against SIZE_MAX, but in multiple other spots you don't check size+META_SIZE.

2) the field is_mmap is useless: it can be replaced by (size>=MMAP_THRESHOLD) practically everywhere. The only corner case where this doesn't work is a large block initially backed by mmap() that's then shrunk via realloc() to under the threshold. But realloc() has other inconsistencies anyway, see next point.

3) realloc() shows the signs of a refactoring gone wild. The first if on block->size lacks a test on is_mmap, as split_block() doesn't seem to do the right thing with mmapped blocks...

4) free_list does not in fact track free nodes, as its name suggests, but all nodes, whether they are free or not. Wouldn't it be better to add a node to the list only when it's freed? I leave to you to iron out all the corner cases!

> how many Italian dictators had biscuits named after them.

So, how many?

Well, it seems Garibaldi biscuits were genuinely named after this guy. However Bourbon was named for the House of Bourbon, a French royal family.

I'm discounting the Peek Freens Trotsky assortment because Trotsky was, of course, Russian.

So, one. Which is still more than you might expect.

> House of Bourbon, a French royal family

Which also ruled in Spain and multiple different parts of Italy (like Parma and the Two Sicilies).

Also, Trotsky was only a only a butcher and repressor, never a dictator, as he didn't held power.

Please, before commenting on this article, be sure to read Qualcomm's reply posted by adhoc_slime: https://news.ycombinator.com/item?id=46007805

Wait... your interpreter reads from stdin. Shouldn't it read its first arg, instead?

IIRC interpreters can also read their programs from stdin. Try piping a script to bash and see if it works.

(Actually, this is how the `curl install.sh | bash` anti pattern works. )

Independently of what the interpreter can do, it's #! that doesn't pass the file to it.

I think that was what I was trying to figure out, how the program was passed. but OpenBSD does not do nested interpreters, it looks like if I had tried Linux it would have worked.