Hacker News new | ask | show | jobs
by kick 2294 days ago
Do developers not know how to statically compile software anymore?

Also, you shouldn't be writing your own packaging scripts: leave those to distribution packagers. There are thousands of people who work on packaging these things, and the user of the distribution is much safer if they don't touch software distributed by random people.

This stuff is completely stable, just don't break the assumptions of the system without knowing what you're doing.

2 comments

Depending on distributors means that your users will only use ages old versions of your software, thus you receive support requests for stuffprobably already fixed/changed. Sending users back to distros also takes time.

And for static linking: That is kind of happening with those modern snap and flatpack and whatever systems for handling applications, but it's bad for security. I want to update my system zlib in case there is an issue instead if depending on all applications consuming compressed unteusted streams updating their package in time. And I certainly don't want each little tool bundling their own Qt.

Oh, but you still need to make a deb, rpm, nix, whatnot then compose with the os tooling, conventions and expectations. And use those to provide your conf/update/failure, menu integration, permission system, logging, init system, notifications, etc.

Or provide an app image and ignore most integration.

This is my point exactly: to get stability, you remove diversity.

Static linking, one packaging system, and you don't have to care about how diverse the universe it.

But it also means you don't benefit from what make those differences add: security updates, dependancy graph, automation, signing, jails, user documentation and training, os integration, native window theming, etc.

Oh, but you still need to make a deb, rpm, nix, whatnot then compose with the os tooling, conventions and expectations. And use those to provide your conf/update/failure, menu integration, permission system, logging, init system, notifications, etc.

This shouldn't need to be done? The distribution's packagers handle most of this. Except for Nix, maybe? I hear they have a particularly fucked up ecosystem for packaging.

No.

The chances your project matches the criterias to be included into any distrib repo are very low, and it's a lot of work and problems by itself.

They are not app stores you pay to get into. The gate keepers have a very strict opinion on what to let in and how. And it's all done manually, and fedora policy is not debian's is not gentoo's.

Plus, statically linked projects are almost never accepted. Back to square one.

Besides, what if it's not free software ?

> The distribution's packagers handle most of this.

And often fuck it up and introduce bugs or even vulnerabilities, intentionally ignore the developer, or simply fail to update packages in a reasonable time frame.

Relying on free labor to package software for you is a terrible terrible idea that helps keep Linux Desktop a shitshow.

Disagree strongly and as a user I feel distributions and package maintainers are a necessary defense against overly opinionated developers.

I'm glad there is a layer there that will patch and configure to better integrate into the system and in some (very rare) cases remove user hostile "functionality".

Sometimes it's better to trust the developers, not the packagers. Example is the Debian SSH vulnerability from 2008: https://www.debian.org/security/2008/dsa-1576

This was a bug introduced in packaging. See https://lwn.net/Articles/281436/ for more details.