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