Why Linux is Becoming Impossible for Audio Developers to Ignore

[Tiles]

For the build environment, a Docker container or VM could also help. You could keep the known working 20.04 toolchain without having to run your whole system on it. And if it's a GitHub project, you could also use Actions to automate builds and testing across different environments.

Either way, it is not as straightforward as on Windows, where you have one main target platform and one standard place to build against. On Linux you always have to decide which part of the ecosystem you want to optimize for.

I’d really love to advise against Ubuntu 24 here, especially when I think about the issues I had with Python, glibc, and AMD drivers, or things like breaking auto-login so that you suddenly have to unlock apps individually with a password, the Snap drama, and so on.

In my opinion Ubuntu is simply moving in the completely wrong direction and is doing too many things its own way nowadays instead of staying aligned with the wider Linux ecosystem.

But that’s something everyone has to figure out for themselves.

[GaryG]

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.

Yep, that's what I reported to him when he released it. But guessing as he hasn't recompiled yet that it isn't a priority....

[FigBug]

Ok Linux users, time to put your money where your mouth is. Try my new synth Identity, and vote for it in the KVRDC26:

https://www.kvraudio.com/kvr-developer- ... dc26-35351 (Not sure why the link doesn't jump right to my synth until you reload)

[audiojunkie]

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.

You can compile your plugins and you can test your plugins on the same machine. Just don't expect software that was compiled on a newer library to work on a distro with an older library. It's a simple rule that isn't that hard.

[audiojunkie]

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.

This is not a problem. This was resolved back in the 90s. Backwards library compatibility became "the law" back then, and it resolved the issue.

Developers must compile to the oldest library version that they wish to support. If the current version of a library is, for example, foo3.5, and the version of foo that you are compiling to is foo 3.1, then all distros that have foo3.1 and higher should work, because foo is backwards compatible.

However, if the developer compiles to foo3.5, and yet wants to support distros that still use older library versions, then the developer is making a mistake. The reason is that there may be distros still using foo3.1, foo3.2, foo3.3, etc. and they are not compatible with foo3.5. Libraries are not forwards compatible. They are backwards compatible. This was all ironed out in the 90s.

[FigBug]

You can compile your plugins and you can test your plugins on the same machine. Just don't expect software that was compiled on a newer library to work on a distro with an older library. It's a simple rule that isn't that hard.

No, I need to compile on an older machine as you say, but the DAW I need to test in doesn't work on that machine.

[audiojunkie]

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.

Yep, that's what I reported to him when he released it. But guessing as he hasn't recompiled yet that it isn't a priority....

The good news is that eventually, the distros that didn't work will support it and the plugin will run, once the distros upgrade.

[audiojunkie]

You can compile your plugins and you can test your plugins on the same machine. Just don't expect software that was compiled on a newer library to work on a distro with an older library. It's a simple rule that isn't that hard.

No, I need to compile on an older machine as you say, but the DAW I need to test in doesn't work on that machine.

Then you need to use a VM with the older distro and compile from there. Run your work system from a modern distro. Problem solved. It's really easy to do.

[FigBug]

You can compile your plugins and you can test your plugins on the same machine. Just don't expect software that was compiled on a newer library to work on a distro with an older library. It's a simple rule that isn't that hard.

No, I need to compile on an older machine as you say, but the DAW I need to test in doesn't work on that machine.

Then you need to use a VM with the older distro and compile from there. Run your work system from a modern distro. Problem solved. It's really easy to do.

All this for an extra 5% in sales? f**k it, I'm out.

[Tiles]

You can compile your plugins and you can test your plugins on the same machine. Just don't expect software that was compiled on a newer library to work on a distro with an older library. It's a simple rule that isn't that hard.

No, I need to compile on an older machine as you say, but the DAW I need to test in doesn't work on that machine.

Exactly. This is the real dilemma.

It's not about not knowing "the rule". The hard part is finding the sweet spot where your build environment is old enough that your binaries run on as many Linux distributions as possible, but still new enough that you can actually use modern tools, compilers and test environments. And this is an ever-moving target.

The bigger and most probably never resolvable issue is that Linux still lacks a universally agreed binary compatibility target across distributions. This has been a fundamental issue since the early days of Linux and is a direct consequence of how the ecosystem has developed.

If there were stronger common standards for binary compatibility, this whole process would be much easier for developers.

[audiojunkie]

You can compile your plugins and you can test your plugins on the same machine. Just don't expect software that was compiled on a newer library to work on a distro with an older library. It's a simple rule that isn't that hard.

No, I need to compile on an older machine as you say, but the DAW I need to test in doesn't work on that machine.

Then you need to use a VM with the older distro and compile from there. Run your work system from a modern distro. Problem solved. It's really easy to do.

All this for an extra 5% in sales? f**k it, I'm out.

Do you even sell anything? I'm only aware of you having free software. Setting up a VM is standard operating procedure for development. You aren't supposed to be using the same system you compile on for anything else, in order to keep your packages clean. I'm sorry if you feel that way, but that's they way most development is done. I find it hard to believe you wouldn't know this, as an "experienced" developer. Maybe you need to look to another field? You obviously aren't happy doing the steps a normal developer would take.

[JsinOwl]

For better or worse, Linux can, and will be ignored until capitalism dictates otherwise.

[Largos]

You can compile your plugins and you can test your plugins on the same machine. Just don't expect software that was compiled on a newer library to work on a distro with an older library. It's a simple rule that isn't that hard.

No, I need to compile on an older machine as you say, but the DAW I need to test in doesn't work on that machine.

Then you need to use a VM with the older distro and compile from there. Run your work system from a modern distro. Problem solved. It's really easy to do.

All this for an extra 5% in sales? f**k it, I'm out.

Surge devs use a docker image which they have put the stuff up for here https://github.com/surge-synthesizer/sst-dockerimages I don't use docker personally, i've just seen baconpaul say that that's there to help developers build for linux.

[Tiles]

Docker images are definitely useful and a good way to keep a reproducible build environment.

But Docker doesn't remove the underlying complexity, it mostly contains one part of it. For smaller projects this can work very well. For larger projects with multiple platforms, dependencies, toolchains and real-world testing requirements, the amount of infrastructure around it can become a project of its own.

It helps with the build environment, but it doesn't magically solve distribution, testing and support across a fragmented ecosystem.

[MirkoVanHauten]

You can compile your plugins and you can test your plugins on the same machine. Just don't expect software that was compiled on a newer library to work on a distro with an older library. It's a simple rule that isn't that hard.

No, I need to compile on an older machine as you say, but the DAW I need to test in doesn't work on that machine.

Then you need to use a VM with the older distro and compile from there. Run your work system from a modern distro. Problem solved. It's really easy to do.

All this for an extra 5% in sales? f**k it, I'm out.

Do you even sell anything? I'm only aware of you having free software. Setting up a VM is standard operating procedure for development. You aren't supposed to be using the same system you compile on for anything else, in order to keep your packages clean. I'm sorry if you feel that way, but that's they way most development is done. I find it hard to believe you wouldn't know this, as an "experienced" developer. Maybe you need to look to another field? You obviously aren't happy doing the steps a normal developer would take.

Jeez, I wonder why devs avoid Linux and its community... Do As We WiSh Or YoU'rE nOt A rEaL dEv