Hacker News Reader

Comment by Dwedit | Hacker News Reader

The high-quality ports are being limited by how dependencies work on Linux distros. You're tied to a very specific version of a library. Fine if you can just recompile the code every time the version changes, but not fine if you're shipping an unchanging binary.

Meanwhile in Windows land, you static link everything and import only the system DLLs, and everything is great. You can't do that on Linux even if you wanted to.

View on HN

That is what closed-source software does on Linux and Windows and Mac. Usually all required libraries are shipped with the executable. Most don’t link statically, sometimes this even isn’t possible.

People also ship Microsoft’s system libraries. Windows tends to be in “undefined state” due to missing package management (file corruption), broken Windows-Update or whatever went wrong.

It is hard teaching developers not to package their software for Linux! Native packages are maintained by distributions and require well documented dependencies only. Instead many developers maintain themself various packages for outdated distributions not used by anyone. Examples?

    * Amazons MP3-Downloader (that’s old)
    * Valve (shipping only for Ubuntu but they learned to allow redistribution quickly, one of the first requests came from Arch)     
     * Microsoft with Teams (yes, they should know better…)

But they want to package?

Do it once with Flatpak. No Snap! No AppImage. Just Flatpak. It is designed for that usage.

Else?

Provide binaries in tar.gz, document instructions, allow in any case redistribution. Always. If need the distribution maintainers will care. If not the users can copie them just on disk.

Its pretty easy to statically link with musl on linux.

I heard that attempting to load dynamic libraries from an executable using MUSL was difficult. Specifically when the library you want to load imports libc.

Reply on news.ycombinator.com