Hacker News Reader

Hacker News

Comment by bartkmq | Hacker News Reader

Parent Full thread

bartkmq

I can think of a few reasons

(1) Use of a different libc (alpine linux with musl)

(2) most builds are not reproducible, rebuilds are needed for security reasons

(3) non-rolling release distros (-> most distros) fork the upstream projects to backport fixes for their older releases

(4) Different filesystem structure (Gobo Linux)

(6) Most distros want to use the build system associated with their own package manager

There are probably many more than that. Most distros don't even try to stay close the upstream repo and instead maintain a lot of patches.

In the future we will most likely have an distro-specific basic system build and container apps (snap, appimage, flatpak) build directly by upstream on non-server systems.

View on HN

> In the future we will most likely have an distro-specific basic system build and container apps (snap, appimage, flatpak) build directly by upstream on non-server systems.

I sure hope not. A better system would be something like NIX/GUIX or even Gobolinux, that give us a single package as today, but with the option of installing multiple versions in parallel if upstream has screwed up the API (again).

Flatpak and like will just be and excuse for upsteam to bundle everything and the kitchen sink, resulting in bloat and having to update a mass of paks rather than individual libs in case a flaw is found.

You've got good points and I admit I'm split on this issue.

In theory i would rather have everything handled by the package manager but container apps provide a few useful advantages:

  - sandboxing/isolation out of the box
  - being able to report bugs directly to upstream
  - It's easier to distribute a small app to all distributions (for some value of all)*
  - much easier to distribute proprietary applications (subjective advantage)
  - much easier to install old versions of an application (sometimes needed)
  - it's possible to record the bandwidth/ram/cpu usage; with a standard package that's quiet difficult

7) CPU architecture,

8) output binary format (though these days people generally only use ELF or PE),

9) compile time options (eg some packages will allow you to choose which TLS library to use at compile time)

10) hardware specific optimisations

Basically just a plethora of reasons

Reply on news.ycombinator.com