M4 Macs can't virtualise older macOS

One time I had to run a very old version of Eagle CAD on Linux and it turned out that even tho I had a native Linux version, it was easier to run the windows version in wine! I guess stable interfaces have their advantages.

Linux (the ecosystem; not necessarily the kernel) is actively hostile to binary software.

the community has been joking that win32 is the most stable Linux api

I have a half-joking, half-serious thought: has anyone written a desktop environment for Linux that uses the Win32 API? Since Win32 is much more stable than Qt and GTK, it would be easier to target that API. The side bonus is API compatibility with Windows.

This might not have been viable 25 years ago when KDE and GNOME were in their infancy, but WINE has come a very long way since then. Standardizing on Win32 would eliminate the churn of dealing with Qt and GTK major version revisions.

ReactOS comes to mind, although it's not Linux.

It baffles me as to why. I think it’s hilarious how Linus is so careful to not break user space (for good reason) and all the user space libraries break every week.

Because every distro runs it’s compilers with a variety of flags and safety features and library versions and ABI quirks that make supporting stable ABIs a pain in the butt.

Back when IDA Pro for Linux & macOS was finally released, they decided to make every OS a separate license purchase. The net result of this was that every single person I knew who used it just kept buying Windows licenses and using it under WINE when they wanted to use it on their other computers.

Distribution maintainers pretty much do whatever they want with the OS level ABI. That on top of whatever those user space libraries want to do anyways makes native application ABI stability basically impossible.

> has anyone written a desktop environment for Linux that uses the Win32 API?

No, but window managers who use Xt, Xaw or Motif are ok.

> Standardizing on Win32 would eliminate the churn of dealing with Qt and GTK major version revisions.

What makes it so hard to write a GUI toolkit that is long-term (say for 25 years) backwards compatible. If Microsoft is capable of doing this, why can't open-source developers?

In the Linux desktop world, there is no single entity in control over the entire software stack ranging from the kernel all the way up to the desktop environment. In a typical Linux distribution, you have the Linux kernel (run by Linus Torvalds), various command-line tools written by many different developers and managed by different projects (some of them are part of the GNU Project, but others aren't), some type of display system (this used to be solely X11, but Wayland is growing in popularity these days), one or more GUI toolkits (Qt, GTK, some custom ones), and a desktop environment (typically KDE or GNOME, but others exist). The goal of a Linux distribution is to take these disparate parts and present a coherent system to the user.

The problem, though, is that because the Linux desktop is made up of disparate parts from separate teams that have separate, often competing visions for their roles in the Linux ecosystem, often major changes are made with little regard to how they affect the system as a whole. This is the essence of the lack of control over the entire software stack. Thus, the developers of X11/Wayland, Qt, GTK, and other infrastructure can make breaking changes, and application developers relying on those subsystems have to either adapt or lobby for forks. Thus, the churn.

By comparison, Microsoft is in full control over Windows, and Apple is in full control over macOS. Even the BSDs are in full control over their base systems (for example, OpenBSD isn't just a kernel; the OpenBSD team also has control over the command-line tools that make up the base system), though I'm not aware of any BSD (besides macOS) that is in full control over GUI environments. It's not to say there is no churn in these environments; indeed, macOS does not prioritize backwards compatibility like Windows does and thus there's some churn macOS developers need to deal with in order to keep up with the latest releases. But there seems to be a lot of churn at the GUI level in the Linux desktop ecosystem.

Of course

Source software is the way to go (compiled specifically for one version of thé targeted OS, you sont have many issue)

Distribution opaque binaries are indeed not the best way, even if you can do it easily with static linking

Again, how do Windows and macOS (to an extent) solve this? It’s possible, just not incentivized. Show me the incentives and I’ll show you the outcomes.

I think the main thing is that it's common for apps to bundle their dependencies. The default for Linux is to use the system libraries for everything - not just glibc but also things like zlib, libpng, etc. As a result you have to go to significant extra effort to make a portable binary app, e.g. linking against musl.

That's one of the attractions of Go, and to a lesser extent Rust; it's way less work than C to get a portable binary.

I think 90% of the problems I've encountered are due to glibc. They could easily fix all of them by adding a GCC flag that would allow you to compile against old glibc versions.

They'll never do that though because they are ideologically opposed to it.