Hacker News Reader

Comment by einpoklum | Hacker News Reader

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

View on HN

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.

> 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

or:

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.

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.

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.

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.

That's because the "wine runtime" is much more stable than the "linux runtime" (whatever that means).

What about distributing via Flatpak? (honest question, I'm curious to see if it actually help lowering the cost of distributing apps for Linux)

Doesn't work for things that are, or use plugins, which is typical in pro-audio. (Our software is primarily used as a plugin.)

That's a good point, flatpak is not a good fit for that.

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

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.

Reply on news.ycombinator.com