But 12 bits is not "billions of identifiers" -- it's 4096. Once you exhaust that counter in the same millisecond, you are still relying on a gamble that your random source will not generate the exact same bit sequence for the previous same counter value. And this thread started out with the OP explaining that random collisions are much more common than we'd like them to be, for various reasons.

Are you offering an easy fix for that "Linux" line on your SBOM?

No, I'm making an aesthetic critique of a promotional blog post, as an author of commercial technical blog posts myself.

I found that reducing my "Linux" lines from ~21000 (including net-pf-16-proto-21) down to those ~3000 I might actually use (e.g. udp_tunnel) to be a fairly effective method of not having to care about each and every newly discovered memory safety hazard.

I remember my earlier days of Linux of having to compile a kernel module to read from cdrom. Seems like Linux has gone too far in the other direction of having modules that you will probably never need.

That's the same thing that people say about MS Office: nobody uses more than 15% of its feature set, but everyone uses a different 15%. "Linux" having these modules is what keeps it relevant and prevalent in different fields and niches. Whether distro's should ship this many modules by default is a different question, but then we're no longer talking about Linux the kernel.

Not just shipping features - that part is little more than disk space, for features already neatly isolated into modules. I see potential in improved tooling to express "do not autoload anything below this tree" in a more reliable and manageable manner. I know my 15% (far below that, actually), and many more users could express theirs in some deploy config.. If only that did not incur the cost of watching upstream changing things for no reason, or for the recurring reason of kconfig being a fairly error-prone method of expressing & validating dependency trees.

Not forever, backports were introduced with Sarge IIRC. And typically versions only appears in backports that are also in testing/unstable, e.g. Linux 6.19 is currently in trixie-backports but the non-LTS kernels between 6.12 and 6.18 were not available there, nor is the current 7.0 (yet).

It is, just like a calculator is a small computer. It's not a personal computing device though, in the sense that the user can't develop and deploy their own software/tools on it.

Even if that were true, that has nothing to do with browsing the web on it

Of course they could. The products could be impounded at customs.

This is simply Cloudflare seeing the possibility of an infinite stream of income... these APIs are cheap to execute for them but are always tied to billing.

Indeed. We address them as Siri, Alexa or Google.

Even Microsoft doesn't install a spellcheck dictionary unprompted; that happens when a user/admin goes into the app configuration and changes the language support options.

How do you propose to implement that "drop everything except what you need" policy? Do your containers come with a detailed list of which OS services and syscalls are required? I think your idea has the same issue as what held back the adoption of selinux: many developers think that having to enumerate their application's behaviour like that is an undue burden.

A compounding issue is that using AF_ALG doesn't require a separate syscall: it's just using SYS_socket with the first argument set to 38. Your container behaviour specification needs to be specific enough to not only enumerate allowed syscalls, but the allowed values for each syscall parameter.

There are those who are paranoid and those who are expedient. If you're truly paranoid, you spin up the thing you want to run, measure what it does, and open the holes to allow it to do what it needs to. It's tedious and sometimes error-prone, but in some environments it is necessary.

In the vast majority of the world, you set permissions to what's reasonable and trust that most of the time things will work out pretty well and have a plan for if you need to fix things on the fly.

I personally am not terribly paranoid, but I've worked places where we had to be pretty paranoid (shared hosting).

> I want the syntax and grammar (and illusion?) of one continuous thread of execution

Then you shouldn't be using a low-level systems language? You can simply choose a higher-level abstraction language that better matches your programming preferences.