[wheels]

For an audio app that I work on, it's similar, but different: around 1% of the users are on Linux, and around a third of the bugs / complaints come from Linux, but they're virtually all Linux specific.

We're having to seriously consider dropping Linux support because the support / maintenance load is so high. (This comes significantly from the libraries we're using having worse Linux support, and a lot from the Linux audio ecosystem in general not being very mature; and then a whole bunch of it is people wanting packages for dozens of different systems.)

[yjftsjthsd-h]

I would think you can deal with platform-specific issues by saying "we support Ubuntu [or whatever you're willing to do]; anything else you're on your own" up front. But yeah, audio is a general weak spot.

[edflsafoiewq]

I won't buy closed source programs with "Linux ports" anymore for this reason: it seems to always mean "some dev got it working on one Ubuntu version once". The last bug of this form I hit was a program trying to read a hardcoded path that apparently exists on Ubuntu and blissfully segfaulting if it didn't exist...

[wheels]

What you may be missing is that that comes from necessity -- again, for an app like ours, 1% of our users are on Linux. Producing packages for Ubuntu along takes about as much time as producing for Windows and macOS, where almost all of our users are.

Testing and packaging for, say, the top 5 distros would get the effort-per-user to an even crazier extreme -- we'd literally be at the point that supporting a user on Linux takes 200 times more effort than supporting a user on Windows. You either need a very large number of users, or a very large value per use for that to make sense.

For non-OSS projects, most of the time the smart decision is just not to support Linux. I've worked at other pro-audio companies, and they had Linux versions internally that they didn't release because of the support costs.

[jatone]

have you thought about offloading that work to the distributions themselves? I'd be curious to see what say ubuntu would charge for them maintaining your packages for you. you just need to provide a tarball to them.

[saagarjha]

I assume that doesn't work for closed-source software.

[yjftsjthsd-h]

I mean, "Linux" isn't enough to target, and in all fairness, if they say it's for Ubuntu then that's what they support. One would hope that they do say they're targeting Ubuntu, of course.

[wheels]

We do that. In bold. Still doesn't stop people from writing to us at least once a week asking for something else or reporting that the Ubuntu package doesn't work on their distro.

[yjftsjthsd-h]

That is unfortunate; it sucks that the cost of WONTFIXing a ticket isn't zero:\

[smoldesu]

With Pipewire and containerized distribution (eg. AppImage or god forbid, Flatpak), distributing Linux software can really be as complicated as you want it to be. Granted, audio software is still a bit confusing compared to Windows or MacOS, but with the advent of PipeWire I think most people are ready to put those days behind them.

Another alternative is to drop Linux support and let your users make a Wine installer if they really care about your software. Most VST plugins and audio software works boringly well through Wine, even scaling up to be a viable route for supporting games.

[wheels]

Yes, it is a VST plugin (and standalone), and amusingly probably works better in Wine than Native, aside from the fonts being craptastic. Containerized distribution doesn't really work for plug-ins.

This is the first time I'm reading of Pipewire, and it sounds promising, but will need to have host support before it becomes a reasonable VST / LADSPA replacement. (I didn't see if that's among its goals, but such would seem reasonable.)

[thefr0g]

> Yes, it is a VST plugin

Shouldn't that be the easiest way to distribute audio software for linux? It's just a static shared library and maybe some data.

> This is the first time I'm reading of Pipewire, and it sounds promising, but will need to have host support before it becomes a reasonable VST / LADSPA replacement.

I'm pretty sure they didn't mention pipewire as a replacement for vst or lv2 (or ladspa lol). It's benefit would be for your standalone since it supports alsa, jack and pulseaudio clients and can get decent latency.

[wheels]

> It's just a static shared library [...]

No. First, "static shared library" is self-contradicting: libraries are either shared or static, not both.

The longer answer is that plugins have to be compiled with the `-fPIC` flag to be loadable. The `-fPIC` flag basically says that it has relocatable symbols. You can't link against system-provided static libraries because they're never (by design) compiled with `-fPIC`. It might be possible for us to configure our build system to recompile every library we depend on as static and relocatable, but that'd be quite a bit of effort to set up.

As such, we have to link against shared libraries, and you can have conflicts with the host if it is also pulling in those shared libraries. Ardour, on Linux, specifically, in their own packages, pull in a bunch of non-system shared libraries that conflict with the system ones, which breaks our plugin. There are other shenanigans with other hosts.

[account42]

> It might be possible for us to configure our build system to recompile every library we depend on as static and relocatable, but that'd be quite a bit of effort to set up.

Sounds like you already know the solution to your problems. Link all your dependencies into your plugin, hide all symbols except the plugin interface and base system ones and you can make your plugin distro-agnostic. If you depend on external shared libraries then yes, your interface to the system becomes a lot more complex and thereby brittle.

[wheels]

There are 53 shared libraries that our small app depends on (this is not strange on Linux). Getting them set up to all be built independently by our build system would be a large task, and a large thing to maintain. Technically it's probably the best way to go, but it's probably a week solid of work, and probably not worth it to support our small number of Linux users.

[AnIdiotOnTheNet]

> but with the advent of PipeWire I think most people are ready to put those days behind them

Maybe. On the otherhand I heard similar things about Pulse and Wayland and a decade later they're still problematic.

[rpmisms]

Linux audio support is generally a pain. Have you considered officially supporting one audio library and just saying YMMV if you use something else? For example, only support ALSA.

[emersion]

Packages aren't supposed to be submitted and maintained by the developers themselves. The distribution maintainers and community is supposed to do it.

[wheels]

That only works for open source packages.

[oblio]

Ah, I know that one!

Easy! Just make it open source and get rid of your livelihood. Make it open core so people will hate you just as much (bonus points if your software can be ripped off by a hyperscaler) or go Red Hat and be 100% open source and basically turn into a consultancy which is not what a lot of people want to do with their lives.

I'm just being sarcastic, in case anyone was wondering.