Namrok wrote on Yesterday, 14:21:

So, I did run into a real world case of this just gaming. I tried to play an older game, Harvest: Massive Encounter. It apparently had a Linux native version. It attempted to install a batch of binaries that were no longer supported in Mint 22.1, and so it completely failed to run. It actually ended up working better running the Windows version through Proton than trying to get the Linux version working properly. I have to admit, it was unexpected. As I continue down this path, I wonder if I'll find Linux has better compatibility with 10-20 year old Windows software thanks to heavy development into Wine/Proton than it has with 10-20 year old Linux software.

This is not a linux issue.

The issue here is the distro is not supplying version latest-1 of libfoo, and the game dev or you aren't supplying it. The difference to the Wine project, is that it seems everyone is being tricked into installing it which happens to provide all the necessary 20 year old ABIs in the name of getting to play their games, in a massive package that is a re-implementation of the WinAPI that won't be changing for an app that's 20 years old anyway. So of course it works.

There are runtimes people have assembled similar to what Wine provides to get WinAPI support, but for the older/other libs that Linux executable format games use from back in the day. They just aren't getting attention because, people focus on the narrative blasting linux as sucking for backwards compatibility, and people then never look. The libs never went away.

Flatpak was never really needed to solve this. For the people talking about 10 year support, I have worked in both open source and closed source (commercial) and we support multiple distros, and go back 10 years often with customers. Any competent application developer knows what to do to support the users.

Is Windows 10 really that loved people don't want to upgrade? or is it just the stricter hardware requirements?

I find Windows 10 does the job but I don't love it. Been using 11 for over a year now and for me its about the same. It does the job but that's it.
If MS want to give me a free upgrade to yet another mediocre for free then fine.

Anything that can't upgrade I'll run it unsupported till it breaks, that's what I've done previous times without issue.

chinny22 wrote on Today, 02:37:

Is Windows 10 really that loved people don't want to upgrade? or is it just the stricter hardware requirements?

No, it's just that people just don't want to upgrade (especially if it is perceived as forced), period.
So each time a new version of Windows comes - it's the same old tune - sucks, old one was so much better, I'm staying with it.
3-5 years later a good portion of people moves, finds out it is not so bad, gets used to it, then the next one arrives, and it all repeats.

chinny22 wrote on Today, 02:37:

Anything that can't upgrade I'll run it unsupported till it breaks, that's what I've done previous times without issue.

Indeed.

keenmaster486 wrote on Yesterday, 06:05:

I'm serious - standardization is here. Debian, apt, that whole ecosystem... it's the Windows of Linux, in a good way.

I'm not convinced.
Debian release cycle is 2 years.
RHEL - 3 years, and they seem to actually care about binary compatibility.

RHEL 10 just got released - current "el10" RPM packages should work with future 10.x releases, probably until 2028.
For how long can we expect current DEB packages to work?

eM-!3 wrote on Yesterday, 08:21:

The same issue exist in Windows when new MSVC or .NET is released and you get a binary file without dependencies.

But for Windows, I hardly ever get a binary file without dependencies.

During the last 10 years, only TWO major Windows versions got released.
For a third-party vendor, this means: only TWO testing environments.
Do a clean install of Win10, test everything, do a clean install of Win11, test again - and the product is ready to ship!

Really, it's hard for a software vendor not to notice missing dependencies.

the3dfxdude wrote on Yesterday, 21:12:

This is not a linux issue.

Indeed - Linux is just the kernel.
But this is a HUGE issue of all Linux-based operating systems.

The issue here is the distro is not supplying version latest-1 of libfoo

Or the fact that the latest version API isn't compatible with latest-1.