You cannot statically compile a lot of stuff. Too many Linux libraries are GPLed, and that only works for open source applications.

And then one day the underlying libraries will have security problems. Your statically linked application has just become a gaping hole.

And finally, you don't want your statically compiled binary to be hundreds of megabytes and take forever to launch, do you? But seeing how many people here are advocating Snap/Flat/AppImage, I guess it's not a problem? But why would you need a Linux userspace or OS in the first place when all you are doing is running virtual containers? You can run them on Windows or MacOS as well.

Not many libraries use the GPL because “that only works for open source applications”.

That said, you can just copy the .so files if you want to run the old binary.

Furthermore, binaries are mmapped, so even if it is very large, it will still launch relatively quickly since only the parts needed to launch are read into memory.

LD_LIBRARY_PATH again?

Can you stop for a second and realize your "solutions" are absolute unmitigated crap and 99.999% of people of the world wouldn't bother even if they could?

In Windows you don't have to do that. You can compile an application in Windows 11 and run it in Windows XP for Christ's sake (if you don't use new Windows APIs).

Show me a way to compile anything in Ubuntu 24 using only its own libraries and have it run in Ubuntu 6, huh? Without virtualizating/chrooting/crap like that. No, you can't? Fine.

> Not many libraries use the GPL

Let me start: Qt. Before your spew "GTK", who is going to pay for porting the code to GTK/GTKMM (since GTK is C only)?

End of your wonderful story. You really want to bend reality to make Linux look "OK". It's not. It's bad.

First, LD_LIBRARY_PATH works well (or has for me). If for some reason the elf interpreter is unable to use the older libc, just use the old elf interpreter. Second, do static linking to achieve what you want. Then it will run on the older Ubuntu trivially.

That of course requires updating the application when a vulnerability is found in a library, but this is no different from Windows where you have to update many applications to fix vulnerabilities in third party libraries. The number of vendor updates to fix the same libjpeg of libpng issues on Windows is truly staggering.

The Qt libraries do not use the GPL. They use the same LGPL that GTK does. You are making stuff up to bash open source UNIX machines (which is what Linux machines are).

For 99.99999% average people out there none of this utter cryptic crap works even remotely which basically means it doesn't exist.

Can you stop with anecdotal evidence? I don't care that you can make old software works. I can do as well, you know. Been there long before you even knew Linux existed. Had a nice little trip with GCC 2.96 by RedHat if you even remember that fiasco of epic proportions.

Then you acknowledge that what you said earlier was untrue.

> Then you acknowledge that what you said earlier was untrue.

Where did I?

Or something that's available to 0.0001% of its users has become an OS "feature"?

Who are you kidding, man? What else, you gonna claim Linux is "fine" because people can write assembler code for it? It can even run on your PC?

That's not what a desktop OS is about. That's not how it's used.

In reference to running old software, you said:

  > In Linux nothing even close is possible.

Now you say it is possible, but are fabricating figures for how many people can do it. Thus, you acknowledge what you said was untrue. Both things cannot be true simultaneously.

This is a feature of Linux. Linus Torvalds is very adamant about supporting old binaries with new kernels, even if it is not commonly done.

This is a broken mindset, that you should be able to take an app and use it for 5+ years. When computers were in their infancy, and systems were only updated every 4-6 years, it might have made sense, but this doesn't in our modern software environment.

Nowadays all software is built on libraries and frameworks, and they have security issues and even just bugs, and you want to get those fixes. If you want to run 5+ year old software, you can now do it natively in a VM in almost any computer; so why does my shiny new OS have to run ancient binaries again?

Because you might want to run more than one program at a time without having to spin up a VM to do it.

I run many programs at the same time AND run VMs; as long as you have enough memory, this shouldn't be an issue.

Without intending to be inflammatory, I think that the mindset that you are espousing is broken.

Security is is a real issue for a subset of computing tasks. To further your point, for those tasks you can argue that constant vigilance and patching are a necessity of the modern world (an alternative and arguably better approach would be that formal verification and not updating, as often applied in safety critical control systems.) However, security is often used as a pernicious ruse for forcing obsolesence: want the latest security patches? update to the latest OS version. Oh look, the latest OS version no longer runs on your perfectly good hardware. Or similarly, oh look, your perfectly good software no longer runs on the latest OS version.

But now consider the subset of computing that does not need to involve security either because it has literally no security implications, or because it can be sandboxed by the OS (e.g. games, music and video production, architectural design, scientific simulation, mathematical research, ...) There is a large body of this kind of software that works perfectly well for any number of years (modulo forced obsolesce initiatives like "modernising" the UI or moving to the cloud). I would argue that the primary function of the OS should be to provide a stable platform for running such software securely. Yes, the user could learn how run it under emulation, in a container or VM, but then what is the purpose of the OS?

The alternative is a high software maintenance burden/cost to everyone (for applications to just keep the lights on, or users to stay current in a churning software landscape) and/or the destruction of a massive amount value in developed but no longer easily able to be run software: this value destruction here is twofold: (1) the licensee can no longer run the software that they pay for, and (2) the effort expended to develop said software is discarded.

Okay, I understand what you are trying to say, but some of what you are using as examples doesn't support your argument. Games, unless they are simple single player games, need the network. Scientific sims and math research are best served on the latest hardware, which often needs the latest OS/software to get the most out of it. I think your arguing that MOST software should run without needing to be updated, and when we lived in a dial-up world and before, that was a very viable position. But with all of our machines on an always on network, the OS has to be kept up to date.

Most businesses just want things to work; their software/hardware costs are often rounding errors when amortized over their lifetime. I'm sympathetic to users who have paid for programs wanting to run them forever, but software businesses have to make money and sell new versions, so they add new features and follow the OS upgrades. It's hard for businesses to support older software or a big diversity of versions; it's why companies mandate a standard and try to enforce it.

With Microsoft, they are making millions on OS and related basic programs, and so can afford to support things for a long time. With OSS like Linux, there is less funding and less people who are interested in running old versions. As someone who has had to keep some software up to date on Linux, it can sometimes be more of a pain to update a package (because of dependencies) them to just recompile the thing from source. The 5 years that LTS releases get are good for 2 average commercial update cycles, which I think is reasonable. Beyond that, people's skills are going to be out of date.

A statically compiled app that used Xorg won’t run on many Linux distributions at the moment.

A statically compiled app that used Jack for audio might have problems running on PipeWire.

A statically compiled app from 2012 that used PolicyKit for authorization might not work today when asking for sudo. Everyone’s moved on to polkit.

The meme is wrong, don’t regurgitate nonsense. I can guarantee you my Windows app compiled in 2007 still has the UAC prompt and the audio system working correctly.

> A statically compiled app that used Xorg won’t run on many Linux distributions at the moment.

Not a single major distribution doesn't ship Xwayland by default. The entire gaming community relies on X11 continuing to work, just like they rely on x86 libraries to stick around.

> A statically compiled app that used Jack for audio might have problems running on PipeWire.

A statically compiled app that uses Jack for audio might have problems running on Pulseaudio/ALSA/OSS. Jack's never a thing that's generally available, so claiming it's a backwards compatibility issue is nonsense. If your application requires Jack, then you need to ship it.

Note that you'll also have issues on Windows and Mac because Jack - unsurprisingly - is not installed by default on those platforms either.

> A statically compiled app from 2012 that used PolicyKit for authorization might not work today when asking for sudo. Everyone’s moved on to polkit.

If you used policykit correctly you should have either used the dbus protocol, or the command line utilities. These are the APIs for userspace and they haven't changed since 2012.

What distro are you using that doesn't package Xwayland or pipewire-jack? Sure those are compatibility layers, but so is WoW64. The Linux and Windows backcompat strategies aren't all that different here.

pipewire-jack won't work with a program that links libjack statically. Pipewire preloads its own .so and hijacks those library calls.