@phnt

> 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, popularity depends on usability; they're not entangled. There are plenty of really usable things that no one uses. And an abstract general/universal "usability" is a concept designed for mass-market adoption. I say this, people act like it's crazy and don't factor it in, but I'm sure it's obvious: usability varies widely and usability for some groups is mutually exclusive and it even varies by application for a single person. awk is not very usable for a person that does not use the shell, but Excel is not very usable for a person that has a dozen machines with a 20GB TSV on each and they want an answer without copying 240GB across the network and then loading it into RAM. A hacker, a data analyst, a DBA, a bizops drone, a CFO, a small business owner, and a secretary all have very different concerns and they want something different from tabular data. That leads to the next point:

> negligible amount to the point of irrelevance

kdb has fewer users than IE6, but because they are writing the microsecond trading bots, if they write a bug that causes enough bad trades, the market crashes. Nuclear missiles have very, very few users: negligible to the point of irrelevance. Or not all users of a tool are exactly the same.

User count in absolute numbers only means anything if you are pushing a mass-market utility so that your investors can maximize their exit. It does not mean anything here. If I write a script and it never leaves my box, it doesn't matter: the script still fucking works, its existence still makes a difference to me, and I can maintain it myself. There is really zero reason to keep treating user count as significant for anything other than VD.

> we are arguing whether "No one" or "99.9% of people using computers" is big enough difference to mean something in the statement.

No. I am not and have not argued that. We're at cross-purposes if you're reading that into what I'm saying. I am not being overly literal about your use of "no one": I am saying the numbers do not matter.

Software at the threshold that you can maintain it yourself is qualitatively different, and that was entirely the point I was making. "Forget the number of users" turned into you trying to tell me about the number of users and then some point about usability that I think was incorrect, separate discussion: my entire point was that if you can maintain it yourself, you do not have to care, and this makes bloat a serious limiting factor. I'm not going to ever end up maintaining Linux myself; some group might fork it, but they'll have to make some cuts. Look at the people that keep doing "de-Googled" Chromium and "de-Googled" Android forks: without exception, they have had a bug that downloaded binaries from Google and executed them. Microsoft forked Go and got bit by that stupid Go feature that downloads binaries from Google. This means Chrome, Android, and Go are above the level of complexity where a small team can maintain parallel development. (The excessive complexity is a gatekeeping maneuver: your budget must be this tall to become a credible competing browser.)

So there is a complexity threshold for something that needs maintenance: past a certain point, you need a team and a budget. (And I think you need to consider who you're even talking about. Who's buying big-ass servers and then trying to push several thousand reqs/s without a budget? It's not some Mastodon dingus that doesn't wanna update their kernel because they believe in an invisible taint, that's a probably a team. If such a team has a reason to push that much traffic from a single machine then they have a budget to maintain relevant parts of their stack.)

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

Who said otherwise? But you keep treating "usable" and "popular" like you can't have one without the other and like there's a universal metric for the former and like the latter is relevant to the discussion.

> 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

Sure. I mean, something like ten years ago Linus said that he didn't have a plan for kernel bloat and that it was past the point where he could review most patches. This is the problem, you know, Linux is bloated. It's not a speed tradeoff; the mechanics of the schedulers are, sure, but if you look at the commit history, most of the schedulers (process, I/O, etc.) have one initial author. Likewise with filesystems. This is because the first version is a design more than it is a wad of code.

> 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.

Well, for any given feature, you know. ATA-over-Ethernet came from Plan 9, because Coraid was using Plan 9 and wanted to speed up storage. I don't think they've removed it from 9front but the important thing is that if it's not bloated, you can extend really easily when you need it. CPUs don't push as hard as ASICs or GPUs but they're much more flexible and being general-purpose makes a big difference.