Why Linux is Becoming Impossible for Audio Developers to Ignore

[FigBug]

But that's not the point you were making with your original comment. Your original comment was regarding ABIs, which I demonstrated are quite stable.

I just tried installing Tracktion Waveform 8, which isn't that old. Installs and runs on Windows and macOS. Doesn't install on Linux because of broken ABI. When an OS breaks the ABI more often than macOS, you can't say it's "quite stable".

[audiojunkie]

But that's not the point you were making with your original comment. Your original comment was regarding ABIs, which I demonstrated are quite stable.

I just tried installing Tracktion Waveform 8, which isn't that old. Installs and runs on Windows and macOS. Doesn't install on Linux because of broken ABI. When an OS breaks the ABI more often than macOS, you can't say it's "quite stable".

You never mentioned your distro and version.

And in this particular case, Waveform 8 specifically, released in 2017, was notorious for having problems with Missing or incompatible library versions (glibc, libstdc++, Qt-related dependencies, audio back end issues, etc. To use a common descriptive term, Waveform 8 was essentially a dumpster fire, and I blame things more on the developers than on the OS.

Many users could not even get the installer to work. They had to bypass the installer to get it working. The executable itself functioned once installed manually. It wasn't the kernel that was preventing execution. It wasn't the desktop environment that was preventing execution. The actual binary was capable of running. It was the poor packaging and compatibility assumptions, rather than a problem with Linux that caused so many problems.

If software assumes one particular library version and failes somewhere else, that is a compatibility choice made by the application's developers rather than a linux problem. Why not try the same thing on an older Reaper install with your current distro?

[FigBug]

You never mentioned your distro and version.

Ubuntu 20.04

[audiojunkie]

You never mentioned your distro and version.

Ubuntu 20.04

OK. Try an older version of Reaper then? As long as you are meeting the dependency requirements and minimums in the older version, you should be fine. I trust Reaper.

[Tiles]

One thing that's also worth keeping in mind is that many Linux users won't actually use the native Linux build. They'll just run the Windows version through Wine and Yabridge because that's already part of their workflow.

Sorry, but this I don't get. If there is a native build, why wouldn't you use a native build?

Of course it could be that these users already installed the non-native build before it was released and never converted, but I would assume that any new user would pick the native version (unless they are also using a Windows DAW in wine, but then yabridge is not involved).

Because the native Linux build might not even run. And you most likely already have a Wine/Yabridge pipeline in place. So adding another Windows plugin is often the path of least resistance. No experimentation required.

A Windows VST3 is essentially a single binary that will run on virtually any Windows installation. A Linux VST3, on the other hand, is a bundle of files that depends on the correct libraries and runtime environment. Different distributions and package versions can introduce compatibility issues, and even a point release can occasionally break things. That's why many Linux users simply stick with the Windows version through Wine and Yabridge, because it already works reliably in their existing setup.

"If it works under Wine, I leave it alone."

[Tiles]

But that's not the point you were making with your original comment. Your original comment was regarding ABIs, which I demonstrated are quite stable.

I just tried installing Tracktion Waveform 8, which isn't that old. Installs and runs on Windows and macOS. Doesn't install on Linux because of broken ABI. When an OS breaks the ABI more often than macOS, you can't say it's "quite stable".

We have to distinguish between the Kernel ABI and the Distribution ABI. This sometimes gets mixed up.

The Linux kernel ABI is famously stable. Existing userspace binaries continue to run because the kernel maintains strong backward compatibility.

The problem is the userspace ABI provided by individual distributions. Once you depend on glibc, libstdc++, Qt, GTK, multimedia libraries or other userspace components, you are no longer talking about the kernel ABI. Those interfaces are tied to specific distributions and release versions, and they can change much more frequently.

That is exactly why a binary like Tracktion Waveform can run for years on Windows and macOS but fail on Linux. It is not because Linux breaks its kernel ABI, but because Linux does not provide one unified desktop userspace ABI across all distributions.

There is no single "Linux platform" comparable to Windows or macOS. There are many distributions, each with their own userspace stack and compatibility guarantees.

So saying "the Linux ABI is stable" without specifying which ABI is misleading. The kernel ABI is stable. The distribution userspace ABI is a moving target. And everything but stable.

[Tiles]

...And, if I'm not mistaken, flatpak stuff takes much more disk space.

I'm not too happy about that

- Mario

Yes, that is one of the trade-offs with Flatpak. It solves the dependency problem by shipping its own runtimes, but that also means more disk usage due to duplicated libraries and frameworks.

It is a useful workaround, but it does not change the underlying issue: Linux still lacks a unified desktop userspace ABI comparable to Windows or macOS. For simple desktop apps this works well, but for professional software with plugins, audio drivers and hardware integration, it gets much more complicated.

[ruralaudio]

One thing that's also worth keeping in mind is that many Linux users won't actually use the native Linux build. They'll just run the Windows version through Wine and Yabridge because that's already part of their workflow.

Sorry, but this I don't get. If there is a native build, why wouldn't you use a native build?

Of course it could be that these users already installed the non-native build before it was released and never converted, but I would assume that any new user would pick the native version (unless they are also using a Windows DAW in wine, but then yabridge is not involved).

Because the native Linux build might not even run. And you most likely already have a Wine/Yabridge pipeline in place. So adding another Windows plugin is often the path of least resistance. No experimentation required.

A Windows VST3 is essentially a single binary that will run on virtually any Windows installation. A Linux VST3, on the other hand, is a bundle of files that depends on the correct libraries and runtime environment. Different distributions and package versions can introduce compatibility issues, and even a point release can occasionally break things. That's why many Linux users simply stick with the Windows version through Wine and Yabridge, because it already works reliably in their existing setup.

"If it works under Wine, I leave it alone."

Could you give actual examples of this?

I have yet to run into native Linux builds I couldn’t install, but there is indeed Windows versions which doesn’t install, run or authorize on Wine. So this argument seems far from the reality of those of us using Linux as our daily driver for music production.

That being said, I’m really happy I can run and use my plugins from Soundtoys, Plugin Alliance, Fabfilter, Arturia and more, but I really think these vendors should start to support a free choice of OS, digital autonomy and not force anyone to be tied platforms driven by big tech.

[havran]

@audiojunkie : May I ask if you have some kind of personal stake in how well Linux does in this domain?

[havran]

Sorry, but this I don't get. If there is a native build, why wouldn't you use a native build?

WINE provides a more stable binary api than any Linux distro provides. Some times that's the only way a plugin will load if you use a different distro than the plugin author.

https://blog.hiler.eu/win32-the-only-stable-abi/

Thank you. That's an interesting thing to consider, and it makes sense.

[Tiles]

One thing that's also worth keeping in mind is that many Linux users won't actually use the native Linux build. They'll just run the Windows version through Wine and Yabridge because that's already part of their workflow.

Sorry, but this I don't get. If there is a native build, why wouldn't you use a native build?

Of course it could be that these users already installed the non-native build before it was released and never converted, but I would assume that any new user would pick the native version (unless they are also using a Windows DAW in wine, but then yabridge is not involved).

Because the native Linux build might not even run. And you most likely already have a Wine/Yabridge pipeline in place. So adding another Windows plugin is often the path of least resistance. No experimentation required.

A Windows VST3 is essentially a single binary that will run on virtually any Windows installation. A Linux VST3, on the other hand, is a bundle of files that depends on the correct libraries and runtime environment. Different distributions and package versions can introduce compatibility issues, and even a point release can occasionally break things. That's why many Linux users simply stick with the Windows version through Wine and Yabridge, because it already works reliably in their existing setup.

"If it works under Wine, I leave it alone."

Could you give actual examples of this?

I have yet to run into native Linux builds I couldn’t install, but there is indeed Windows versions which doesn’t install, run or authorize on Wine. So this argument seems far from the reality of those of us using Linux as our daily driver for music production.

That being said, I’m really happy I can run and use my plugins from Soundtoys, Plugin Alliance, Fabfilter, Arturia and more, but I really think these vendors should start to support a free choice of OS, digital autonomy and not force anyone to be tied platforms driven by big tech.

And you have tested it on how many distros?

I am talking about the technical reality behind the scenes. I know that a VST3 built on my system is not guaranteed to run everywhere.

For example, my build environment for my VST3 is Ubuntu 22.04:

Ubuntu 22.04 → glibc 2.35

But Rocky 8 uses a much older glibc:

Rocky 8 → glibc 2.28

A binary built on Ubuntu 22.04 may require newer glibc symbols that simply do not exist on Rocky 8. Whether it fails or not depends on the software and the exact symbols and libraries it actually uses, so you cannot even make a reliable assumption without testing. And i haven't. I miss the time to install dozens of distros. But this is not a theoretical problem to me. I have run into this situation many times in practice before.

That is exactly the problem. A VST3 built today on a current Linux system is not automatically expected to run on a Linux system from one or two distribution generations ago, which can easily mean only three or four years difference. Not even a point upgrade is safe as i have experienced in the past. Thanks Ubuntu.

I have encountered this many times: software built on a newer Linux distribution often fails on systems with older userspace components. The same issue can happen with libstdc++, Qt, multimedia libraries and other dependencies.

A common example is the difference between Ubuntu and Debian Stable. Ubuntu generally ships newer userspace components, while Debian Stable intentionally uses more conservative versions. So once you build on newest Ubuntu you might have a problem with newest Debian already. I've been there.

That is the dependency problem. The kernel ABI is stable, but the distribution userspace ABI is not a single stable target. Every distribution and release defines its own combination of libraries and versions. A nightmare for us developers.

but there is indeed Windows versions which doesn’t install, run or authorize on Wine.

That is a different situation. Wine is a compatibility layer translating Windows APIs to Linux. It is not the same as running a native Windows binary on Windows.

The comparison we are talking about is Windows binaries on Windows, where the platform ABI is designed to remain compatible across many versions of the OS.

If a Windows plugin fails under Wine, that is a Wine compatibility issue. It does not prove that the Windows ABI is unstable.

The point is that you cannot really make that comparison. And authorization is a different beast.

You have tested Windows VSTs through Wine on your specific setup. That does not prove that native Linux VSTs have better compatibility across the Linux ecosystem, because you have not tested them across different distributions and releases either.