Comment by wheels
5 years ago
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.)
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.
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...
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.
2 replies →
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.
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.
That is unfortunate; it sucks that the cost of WONTFIXing a ticket isn't zero:\
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.
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.)
> 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.
3 replies →
> 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.
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.
Packages aren't supposed to be submitted and maintained by the developers themselves. The distribution maintainers and community is supposed to do it.
That only works for open source packages.
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.