Why Linux is Becoming Impossible for Audio Developers to Ignore

[DRMR]

Ubuntu 20.04

While I still build for 20.04 libc it's kind of ridiculous to expect everyone else to do as well.

Any modern dev I recommend to pick an "older libc" for their builds, to cover edge-case users like yourself, but I think most will maybe do 22.04 at the latest today. I personally use Debian Stable (13 as of writing), and if I notice a plugin doesn't run because of its libc dependency I notify the dev and request that they build on an older libc like Ubuntu 22.04

If you are still running 20.04 as a daily driver (not just a build target) then you can expect these kind of issues. Don't blame the platform, but blame your own laziness to not update


Note that this has absolutely nothing to de with "ABI stability". The issue here is libc compatibility which is only forward-compatible and not backwards.
(in the sense that a system can run binaries made using older libc, but not newer)

[ruralaudio]

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.

Thanks for taking your time to explain, but I have to admit this technical perspective is out of my zone of understanding. Since this thread is about Why Linux is Becoming Impossible for Audio Developers to Ignore, and we have several developers doing awesome work in making native Linux versions of their plugins, I think it's important to underline, that I have never experienced this as a problem before as part of the community.

It's my impressions from the linuxaudio.dev interviews, that it's not something experienced devs are seing as a problem too.

Here is an example for the interview with Artemiy Pavlov from Sinevibes

"After starting with macOS (), then Windows (), what motivated you to do native Linux builds as well?

It was a moment when we realized that there are no real reasons not to do it! Our code is very clean and simple, with no platform-dependent bits at all, so we could do the builds very quickly as you have seen by yourself. We are also very happy when we can give our users more choice for where to run our plugins, and also collaborate with other musicians who might run a different OS than themselves."

Link: https://linuxaudio.dev/developers-spotlight/sinevibes

[stoopicus]

I mean - sure, if I ever do it that will be why, it's simply easy to do so for me, easier than windows for sure at any rate.

But that's not really a compelling reason for non-linux users to do it

[legendCNCD]

I can't believe the libc is still problem. It was a problem in 1995... this and all the tinkering with everything when trying to do a simple thing, is why ~nobody uses linux on desktop.

[Tiles]

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.

Thanks for taking your time to explain, but I have to admit this technical perspective is out of my zone of understanding. Since this thread is about Why Linux is Becoming Impossible for Audio Developers to Ignore, and we have several developers doing awesome work in making native Linux versions of their plugins, I think it's important to underline, that I have never experienced this as a problem before as part of the community.

It's my impressions from the linuxaudio.dev interviews, that it's not something experienced devs are seing as a problem too.

Here is an example for the interview with Artemiy Pavlov from Sinevibes

"After starting with macOS (), then Windows (), what motivated you to do native Linux builds as well?

It was a moment when we realized that there are no real reasons not to do it! Our code is very clean and simple, with no platform-dependent bits at all, so we could do the builds very quickly as you have seen by yourself. We are also very happy when we can give our users more choice for where to run our plugins, and also collaborate with other musicians who might run a different OS than themselves."

Link: https://linuxaudio.dev/developers-spotlight/sinevibes

I don't think that quote actually contradicts my point.

Artemiy is describing his own project. He explicitly says their codebase is very clean, simple, and contains virtually no platform dependent code. Under those conditions, adding Linux support can indeed be straightforward.

It also helps that Sinevibes targets a fairly narrow Linux platform. They ship x86_64 VST3 builds, not multiple plugin formats or architectures. That's a perfectly valid choice, but it also keeps the scope much smaller than trying to support the Linux ecosystem as a whole.

That doesn't mean every plugin is built that way. Plenty of commercial plugins depend on platform specific SDKs, third party libraries, copy protection systems, installers, proprietary frameworks, or other components that are outside the developer's control. For those projects, Linux support can be significantly more complicated.

So I don't doubt his experience at all. I just don't think it's something that can be generalized to every audio developer.

[Tiles]

I can't believe the libc is still problem. It was a problem in 1995... this and all the tinkering with everything when trying to do a simple thing, is why ~nobody uses linux on desktop.

Nope, still there, it is systemic

It's not only a problem for commercial vendors either.

A good example is Blender. They have their own build infrastructure and still chose to target an older baseline (Rocky Linux 8 ) to avoid newer glibc dependencies and keep compatibility with a wider range of distributions.

That doesn't mean Linux is unusable or that developers can't solve these problems. It means that binary distribution across many different Linux environments requires deliberate decisions and additional work.

For open source projects this can often be handled by distributions rebuilding the software themselves. For developers shipping prebuilt binaries, the responsibility usually falls on the developer.

[legendCNCD]

Man...
Oh yeah, we used to actually build the software ourselves on linux, makefile editing and all. Would NOT go back to that

[audiojunkie]

I just tried installing Tracktion Waveform 8, which isn't that old.

Try an older version of Reaper then?

This is like telling an X-Box user to "just try a Wii".

No, this is simply to demonstrate that the problem is with Tracktion. It’s not to make him actually use Reaper.

[audiojunkie]

Could you give actual examples of this?

I have yet to run into native Linux builds I couldn’t install

Although a happy linux user, for the sake of fairness; the recent Mikey Audio reverb, uses the recent glibc 2.43 so doesn't work on popular distros like Mint or Ubuntu still on 2.39.

Whereas the Windows version is fine in yabridge...

Mikey Audio compiled it using a wrong distro version. The libraries are backwards compatible. He should have compiled it on an old version. As it stands, this binary will work in the future when Mint and Ubuntu catch up.

[FigBug]

Ubuntu 20.04

While I still build for 20.04 libc it's kind of ridiculous to expect everyone else to do as well.

I'm still running 20.04 because that was the advice I was given in this thread (and other places)! Build on an older Ubuntu and then the binaries produced will run everywhere. But it is getting to the point where Ubuntu 20.04 is too old, since modern software will no longer run on it.

The newest gcc that installs is 13, which has pretty limited c++23 support and is holding me back from using more modern c++ features. More modern daws also don't install, so I can't test on the build machine which is a giant pain.

It's probably time to upgrade to 24.04, not sure how many customers I'll drop because of that, probably not many. It's just that my build infrastructure works and I don't want to touch it.

[Tiles]

This is actually a good example of the problem. The advice "build on an older Ubuntu and your binaries will run everywhere" works until the build system itself becomes too old.

You are then stuck between old glibc compatibility and modern toolchains. Blender ran into a similar issue and chose Rocky Linux 8 as a stable build baseline. Which is already pretty aged again.

For build infrastructure I would probably look at Debian Stable, Rocky/Alma Linux, or Fedora depending on whether compatibility or newer toolchains are more important. The bigger point is that Linux doesn't have one stable ABI target like Windows or macOS, so every developer has to choose their compromise.

[audiojunkie]

Ubuntu 20.04

While I still build for 20.04 libc it's kind of ridiculous to expect everyone else to do as well.

I'm still running 20.04 because that was the advice I was given in this thread (and other places)! Build on an older Ubuntu and then the binaries produced will run everywhere. But it is getting to the point where Ubuntu 20.04 is too old, since modern software will no longer run on it.

The newest gcc that installs is 13, which has pretty limited c++23 support and is holding me back from using more modern c++ features. More modern daws also don't install, so I can't test on the build machine which is a giant pain.

It's probably time to upgrade to 24.04, not sure how many customers I'll drop because of that, probably not many. It's just that my build infrastructure works and I don't want to touch it.

No, the advice you were given was to “compile” on an older version. For everyday work, “use” an uptodate version.

[FigBug]

No, the advice you were given was to “compile” on an older version. For everyday work, “use” an uptodate version.

My everyday work is building plugins! If I can't compile and test on the same machine, that is a major workflow issue.

[DRMR]

Build on an older Ubuntu and then the binaries produced will run everywhere.

Exactly, build. That doesn't say that you should run this as your daily driver

(especially since, as you experience, others may not do the same)

[DRMR]

It's probably time to upgrade to 24.04

So I would do 22.04 and then upgrade in two years time again. With 22.04 you likely cover 99% of customers. 20.04 would be that 0.9% extra.

If you build for 24.04 you will most certainly get a significant amount of users that won't be able to run your builds.

For me this is the only compromise, but ymmv depending on what other tools and dependencies you need for your builds.

And I agree to being able to test, but expecting other devs to follow the exact same rules is unrealistic (and yeah that means you can't run all the software for your tests).