The future of 32-bit Linux

"Provided you have the necessary libraries" can be a pretty massive undertaking, and is one of the points of the TFA. It's also not a new problem; commercial users of Linux have been complaining about this for over twenty years, and another point of the TFA is that commercial users are beginning to discover just how much they've been reliant upon volunteers, and if they want something differently, they're going to have to start paying to get what they want. And perhaps the main point of TFA is that "solving this in software" is exactly what's being done at the kernel level, because that's a lot smaller/simpler/cheaper than getting every random binary to get recompiled/fixed for 64-bit systems. And new software built/tested/fixed for 32-bit systems.

Meanwhile. IIRC, generally it wasn't the Win95 applications that have problems, it's the *installers* for those Win95-era applications, which relied on 16-bit Win3.1-era binaries that don't work on x86_64.

Offhand I can only think of a handful of Win95-era applications/games that simply didn't work on more modern systems, one relied on Win95 not trapping an illegal memory access, and the others relied on reserved filenames like "CON". (I'm also deliberately skipping over applications that required specific hardware/device drivers that never got ported to later versions of Windows)

But there were plenty of applications that technically ran, but were only ever tested on Win95 and therefore assumed they had full administrator access and behaved accordingly, writing files anywhere they wanted and other questionable assumptions. I should point out that this was in violation of MS's guidelines. WinXP SP2 further tightened down many other areas that were critical for changing Windows' reputation as security swiss cheese, but this "broke binary compatibility" and pissed off a lot of users.

But with regards to the latter; random decades-old Linux binaries will find themselves in the same boat when plonked down into modern distributions; assumptions they made about how things are laid out might not hold, and if they directly interfaced with kernel interfaces (eg OSS, specific /proc files, VFL1, or whatever) they might not get very far.

(In more modern times, the general attitude towards this sort of backwards compatibility has shifted towards "Just run the old system in a VM and firewall the crap out of it" -- That's what MS finally did with Win10, including XP in a sandboxed VM)

That's great, but we're not talking about Java.

(Or the fact that Java shops inevitably end up becoming 3rd-world body farms)