4 ms·

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,

by wheels 5y 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.)

rpmisms 5y ago
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.
yjftsjthsd-h 5y ago
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.
- wheels 5y ago
  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 5y ago
    That is unfortunate; it sucks that the cost of WONTFIXing a ticket isn't zero:\
- edflsafoiewq 5y ago
  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...
  - yjftsjthsd-h 5y ago
    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 5y ago
    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 5y ago
      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 5y ago
        I assume that doesn't work for closed-source software.
emersion 5y ago
Packages aren't supposed to be submitted and maintained by the developers themselves. The distribution maintainers and community is supposed to do it.
- wheels 5y ago
  That only works for open source packages.
  - oblio 5y ago
    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.
smoldesu 5y ago
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 5y ago
  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 5y ago
    > 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 5y ago
      > 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.

by wheels 5y ago

rpmisms 5y ago

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.

yjftsjthsd-h 5y ago

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.

wheels 5y ago
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 5y ago
  That is unfortunate; it sucks that the cost of WONTFIXing a ticket isn't zero:\
edflsafoiewq 5y ago
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...
- yjftsjthsd-h 5y ago
  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 5y ago
  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 5y ago
    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 5y ago
      I assume that doesn't work for closed-source software.

emersion 5y ago

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

wheels 5y ago
That only works for open source packages.
- oblio 5y ago
  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.

smoldesu 5y ago

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 5y ago
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 5y ago
  > 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 5y ago
    > 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.