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