Linux is pretty much the original open source project. Just fork the repo and maintain 32 bit code yourself if you want to keep it.

> Linux is pretty much the original open source project

It's not. GNU pre-dates Linux by nearly 10 years. But even if you're talking strictly about kernels, 386BSD and Hurd were started before Linux.

> Just fork the repo and maintain 32 bit code yourself if you want to keep it.

I've often noticed -- and not just on here -- that when commenters prefix "just" to a sentence, the work involved is usually non-trivial.

> I've often noticed -- and not just on here -- that when commenters prefix "just" to a sentence, the work involved is usually non-trivial.

That was the joke, yes. The post I was responding to was complaining about "forced" obsolescence while there is nothing of the sort. Upstream maintainers want to drop some legacy code so they can spend more time on newer machines. GP apparently does not want to upgrade and is now complaining that other people don't do the non-trivial work of keeping 32 bit linux updated for free.

Maintaining a 32bit Linux fork which includes just security patches and (critical) bugfixes would actually be a lot less work than keep maintaining 32bit support for all new feature development. Maintaining a "32bit LTS" fork of Linux like this would probably be pretty viable.

Keep in mind that in this space, "security patch" might come in the form of rewriting the architecture specific virtual memory implementation... https://lwn.net/Articles/741878/

You'd hope that we're finished with working around all the CPU bugs now, but yeah, it's not necessarily trivial, and the longer the fork exists, the harder it will be to backport patches. But I can see how you can build a business maintaining a Linux LTS (there are businesses offering Rails LTS, Microsoft offers updates for Windows XP if you pay), so there's some precedent here.

It's also nontrivial for the people currently maintaining the Linux kernel. I interpret the "just" as a way to hint that forcing someone else to keep doing something for free, you could just do it yourself.

You could argue the same for 16 bit CPUs. If the vast majority of CPUs sold are 64 bits, we will to a point (we are already halfway there) where 64 bit CPUs could be cheaper (more competence and variety) and even more energy efficient.

While 16 bit CPUs are good for many purposes, these are not the same purposes where you have run Linux ever and where 32 bit is currently being replaced by 64 bit. So the analogy is not helpful.

Maybe 64 bit CPUs can get more resource efficient than older 32 bit models. But that's a misdirected use of resources if you use such technolgy to make 32 bit CPUs obsolete. With the same technology 32 bit will always use less resource-demanding than 64 bit. And the claim was that 32 bit has so many use cases (basically all phones and many PCs) that economics of scale are possible.

Of course the nonsense model that you don't pay for Internet services directly, but use Javascript and a lot of other bloat software to run advertisements on your phone to pay via a massive detour is not an energy-efficient approach.

linux never ran on 16 bit CPUs. that being said, CPUs like the 8051 are still very much alive today.

> linux never ran on 16 bit CPUs.

https://en.wikipedia.org/wiki/Embeddable_Linux_Kernel_Subset

This was a toy project that was never mainlined

It doesn't need to mainlained in the same Linux upstream to be serious.

I am not familiar with it to say whether it really wasn't that useful for inherent reasons or whether vendors in that space were just more lucky to defend their proprietary solutions than the (mainline) Linux competitors.