4 ms·

The lack of pro-audio software is definitely a thing. Mixxx is pretty good though for DJing. It's better than most of the rest of the pro-audio landscape on L

by wheels 3y ago

The lack of pro-audio software is definitely a thing. Mixxx is pretty good though for DJing. It's better than most of the rest of the pro-audio landscape on Linux. There are now also pretty good DAWs (Bitwig, especially). Releasing binaries is still a PITA for Linux. That's one of the main reason it has so little support from closed source consumer software. If you care, see my comment history on my company dropping Linux support for a pro-audio app, even though our software works on Linux. But for development tools, it's you-win-some-you-lose-some. There are some development tools (the Valgrind suite, for example) that I still miss after mostly switching to macOS. Going from Linux to macOS also means losing great tools.

einpoklum 3y ago
> Releasing binaries is still a PITA for Linux. Is it really that bad? I mean, many small FOSS programs provide packages for multiple distributions. Are they busting their balls building that stuff?
- wheels 3y ago
  Most of the time those packages, or the build files for them, are contributed by the distributions themselves, or avid users of those distros. (Reference: I have multiple software projects I've created that are a part of every Linux distribution. I've never packaged any of them myself.) Even big enterprise companies usually work directly with the distros under NDA, and the distros produce the packages. That works for FOSS, but not for smaller closed-source consumer apps. And it's not just building, it's also testing and debugging. It's just not tractable for a small company to test on dozens of different distros / versions for such a small percentage of users.
  - boudin 3y ago
    What about distributing via Flatpak? (honest question, I'm curious to see if it actually help lowering the cost of distributing apps for Linux)
    - wiz21c 3y ago
      dunno but for example you got more than one audio stack on linux so they should at least test both, with different hardwares, etc. Not sure flatpak would help here...
      - boudin 3y ago
        I was talking about about the problem of having to package software per distro. Regarding audio, if you decide to target several audio stack yes indeed. I hope this get eliminated by Pipewire really soon. It's already the case as a end user (Pipewire replaces Pulseaudio, Jack and the userland part of Alsa) but I don't know if all use cases are covered yet. If I'm not mistaken Pipewire started from the need to be able sandbox multimedia streams in Flatpak , so I guess Flatpak might be indirectly helping here :) Regarding hardware it's the same problem for any operating system though, testing with all hardware can be tricky for a small company.
    - wheels 3y ago
      Doesn't work for things that are, or use plugins, which is typical in pro-audio. (Our software is primarily used as a plugin.)
      - boudin 3y ago
        That's a good point, flatpak is not a good fit for that.
  - hedora 3y ago
    Oddly, for video games, it’s easier to get older windows games to run under linux than windows. It’s annoying that this isn’t true for modern Linux desktop software.
    - hnfong 3y ago
      That's because the "wine runtime" is much more stable than the "linux runtime" (whatever that means).
  - einpoklum 3y ago
    > Most of the time those packages, or the build files for them, are contributed by the distributions themselves I'm not sure about your statistical claim. Of course my impression is purely anecdotal, but I'm thinking of examples like: https://mkvtoolnix.download/downloads.html https://mkvtoolnix.download/downloads.html or: https://www.monetdb.org/easy-setup/ https://www.monetdb.org/easy-setup/ (and press the Linux button) they seem to providing their own builds. And - if you wrote your build system reasonably (e.g. CMake, properly check for dependencies etc.) - then building on different distros would not be much of a headache. You may not provide 40 different binary packages, and they may only fit recent versions of the popular distributions, but - after you set this up once, I wonder if it isn't just running a script after you have your versioned source tarball release.
    - wheels 3y ago
      Literally most of the packages on the page you link there explicitly say that they're maintained by other people. The author seems to maintain an RPM and a DEB setup, which is already more than most. And my point is absolutely not that some people don't go nuts there, but that's not where or how most Linux users get their software. It's mostly coming from stuff packaged by the distributions. And I am sure that's how most open source packages on Linux are built. Again, I spent a lot of time in that world. (Former KDE core developer, former employee at SAP Linux Lab, friends working at all major distros, have a bunch of my stuff in every distro, talks at lots of Linux conferences, etc.) Building really isn't the problem. It's testing and supporting. Building is relatively easy. But you can't just ship commercial packages without testing them. Pulling out a Debian 11 VM because someone's having problems with your software there under Wayland, but not X11, but it seems to work in Sid... Again for the 0.01% of your customers using that configuration, ... it's hard. And it rarely makes economic sense unless you've got a disproportionate number of users on Linux, or a ginormus user base. You can't assume because something works on Arch Linux that it also works on Mate. Or that something on Ubuntu works on Debian. Or Redhat on SUSE. And then your users may have any of 3-4 versions of those installed. By the time you get to a specific configuration you're dealing with often debugging things for a single-digit number of users.
      - 3y ago

by wheels 3y ago

einpoklum 3y ago

> Releasing binaries is still a PITA for Linux. Is it really that bad? I mean, many small FOSS programs provide packages for multiple distributions. Are they busting their balls building that stuff?

wheels 3y ago
Most of the time those packages, or the build files for them, are contributed by the distributions themselves, or avid users of those distros. (Reference: I have multiple software projects I've created that are a part of every Linux distribution. I've never packaged any of them myself.) Even big enterprise companies usually work directly with the distros under NDA, and the distros produce the packages. That works for FOSS, but not for smaller closed-source consumer apps. And it's not just building, it's also testing and debugging. It's just not tractable for a small company to test on dozens of different distros / versions for such a small percentage of users.
- boudin 3y ago
  What about distributing via Flatpak? (honest question, I'm curious to see if it actually help lowering the cost of distributing apps for Linux)
  - wiz21c 3y ago
    dunno but for example you got more than one audio stack on linux so they should at least test both, with different hardwares, etc. Not sure flatpak would help here...
    - boudin 3y ago
      I was talking about about the problem of having to package software per distro. Regarding audio, if you decide to target several audio stack yes indeed. I hope this get eliminated by Pipewire really soon. It's already the case as a end user (Pipewire replaces Pulseaudio, Jack and the userland part of Alsa) but I don't know if all use cases are covered yet. If I'm not mistaken Pipewire started from the need to be able sandbox multimedia streams in Flatpak , so I guess Flatpak might be indirectly helping here :) Regarding hardware it's the same problem for any operating system though, testing with all hardware can be tricky for a small company.
  - wheels 3y ago
    Doesn't work for things that are, or use plugins, which is typical in pro-audio. (Our software is primarily used as a plugin.)
    - boudin 3y ago
      That's a good point, flatpak is not a good fit for that.
- hedora 3y ago
  Oddly, for video games, it’s easier to get older windows games to run under linux than windows. It’s annoying that this isn’t true for modern Linux desktop software.
  - hnfong 3y ago
    That's because the "wine runtime" is much more stable than the "linux runtime" (whatever that means).
- einpoklum 3y ago
  > Most of the time those packages, or the build files for them, are contributed by the distributions themselves I'm not sure about your statistical claim. Of course my impression is purely anecdotal, but I'm thinking of examples like: https://mkvtoolnix.download/downloads.html https://mkvtoolnix.download/downloads.html or: https://www.monetdb.org/easy-setup/ https://www.monetdb.org/easy-setup/ (and press the Linux button) they seem to providing their own builds. And - if you wrote your build system reasonably (e.g. CMake, properly check for dependencies etc.) - then building on different distros would not be much of a headache. You may not provide 40 different binary packages, and they may only fit recent versions of the popular distributions, but - after you set this up once, I wonder if it isn't just running a script after you have your versioned source tarball release.
  - wheels 3y ago
    Literally most of the packages on the page you link there explicitly say that they're maintained by other people. The author seems to maintain an RPM and a DEB setup, which is already more than most. And my point is absolutely not that some people don't go nuts there, but that's not where or how most Linux users get their software. It's mostly coming from stuff packaged by the distributions. And I am sure that's how most open source packages on Linux are built. Again, I spent a lot of time in that world. (Former KDE core developer, former employee at SAP Linux Lab, friends working at all major distros, have a bunch of my stuff in every distro, talks at lots of Linux conferences, etc.) Building really isn't the problem. It's testing and supporting. Building is relatively easy. But you can't just ship commercial packages without testing them. Pulling out a Debian 11 VM because someone's having problems with your software there under Wayland, but not X11, but it seems to work in Sid... Again for the 0.01% of your customers using that configuration, ... it's hard. And it rarely makes economic sense unless you've got a disproportionate number of users on Linux, or a ginormus user base. You can't assume because something works on Arch Linux that it also works on Mate. Or that something on Ubuntu works on Debian. Or Redhat on SUSE. And then your users may have any of 3-4 versions of those installed. By the time you get to a specific configuration you're dealing with often debugging things for a single-digit number of users.
    - 3y ago