3 ms·

> 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 c

> 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.
- wheels 3y ago
  To make this more numerical: Windows is about 66% of our customers, macOS about 33%, Linux about 1%. On Windows we currently only test on x64 for Windows 10 and Widows 11. On macOS we test 4 configurations. Each Windows configuration we test is 33% of our users. Each macOS configuration about 8%. Linux is starting at 1%, and previously we tested only one configuration, which was already 8x more costly than macOS. But there were a lot of complaints from people using other distros / versions, which resulted in anger, bad reviews, claims that we don't understand Linux... To get reasonable coverage of the Linux desktop landscape, we'd need to test probably 20+ different configurations, meaning each of them would cover about 0.05% of our customers. The QA tests take multiple hours to run through. That makes supporting a Linux user a staggering 160x more expensive than supporting a macOS user, and 660x more expensive than supporting a Windows user. Again, you need either a giant user base, or a disproportionate number on Linux (which is the opposite of true in pro-audio) to even hit break-even on Linux users.

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.

wheels 3y ago
To make this more numerical: Windows is about 66% of our customers, macOS about 33%, Linux about 1%. On Windows we currently only test on x64 for Windows 10 and Widows 11. On macOS we test 4 configurations. Each Windows configuration we test is 33% of our users. Each macOS configuration about 8%. Linux is starting at 1%, and previously we tested only one configuration, which was already 8x more costly than macOS. But there were a lot of complaints from people using other distros / versions, which resulted in anger, bad reviews, claims that we don't understand Linux... To get reasonable coverage of the Linux desktop landscape, we'd need to test probably 20+ different configurations, meaning each of them would cover about 0.05% of our customers. The QA tests take multiple hours to run through. That makes supporting a Linux user a staggering 160x more expensive than supporting a macOS user, and 660x more expensive than supporting a Windows user. Again, you need either a giant user base, or a disproportionate number on Linux (which is the opposite of true in pro-audio) to even hit break-even on Linux users.