@p
>> Popularity is not what I'm taking about. It's usability.
>"No one will use it" is popularity.

The two terms are entangled, you can't have a software be popular without it being usable (or having no other competition). By a substantial enough decrease in usability you lose popularity. "No one will use it" is not popularity in the way I meant it, it means as in "No one will use it, because it is unusable."

And to remove ambiguity even more, "no one" is a hyperbole meaning negligible amount to the point of irrelevance. No one daily drives Windows 3.1 in $current_year is a valid statement, despite it being very likely false because at least 1 person on the whole planet probably still uses it every day. And if you think that is not valid, we are arguing whether "No one" or "99.9% of people using computers" is big enough difference to mean something in the statement.

>> If Linux had that, its server market share would be way lower than what it is now.
>This is a popularity thing again.

Again, an unusable piece of software cannot be popular in a space with competition.

>Sometimes it means "faster". It's a matter of degree, though: you sit down at a machine and we've written most of the system software in C because it's easier to write a correct C program than the equivalent in assembly [...]

Yes, that is the point I was trying to make. That certain compromises have to be made, and at least in the context of OP (Linux) a lot of what can be called "bloat" are tradeoffs of complexity and security surface for making something fast. There's no denying some of it can be removed with little consequences, but a lot of the complex stuff cannot.

Going back to the 9front example, those tradeoffs don't have to be made because it is a project that doesn't necessarily need them. 9front doesn't need shared kernel-userspace ring buffers for async IO (io_uring) to push tens and if not hundreds of gigabytes per second around. Does Linux need them? Debatable.