-- Leo's gemini proxy
-- Connecting to nytpu.com:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini;lang=en-US;charset=utf-8
There's been a lot of discussion on my fediverse timeline about flatpak and a need for a “universal” package manager so you don't have to package your program for 1,500 distros. While I agree with the sentiment, I cannot possibly understand why anyone would think that flatpak, snaps, appimages, or docker is the way to go. I'm mostly focusing on flatpak because that's what the recent discussion has been about but believe me the other container programs have just as many problems (snap in particular is far worse than flatpak).
The biggest issue is that the “universal” package managers are in no way universal. Want to use flatpaks or snaps or appimages on BSD? Fuck you use a better OS! Want to use snaps or appimages on a systemd-less and/or glibc-less Linux? Fuck you use a better distro!
IMO if you're claiming to be “universal” you should work on all POSIX systems; but ⅔ of the most popular platforms **don't even work on all Linux distributions**. Even if you don't care about *BSD or OSX or illumos or Haiku or Minix or any other system support I see no way they could possibly be called universal when they don't even support Linux.
You may say “well you're arguing for installing directly onto the system, how can containerization be less secure than that?” And you're right, containerization is more secure than directly installing like a traditional package manager, but it also provides a false sense of security.
In traditional package managers it's heavily emphasized that you need to trust the packagers for your distribution—that's a big reason why I've used Debian on my servers before but not ubuntu, I don't trust canonical. On the AUR there are innumerable warnings saying “Don't trust the packagers! Verify the PKGBUILDs yourself before installing!” On the other hand, flatpak portrays itself as a secure sandbox.
> It is advertised as offering a sandbox environment in which users can run application software in isolation from the rest of the system
snap has similar marketing. I will give points to appimage though, they don't falsely market “security” or “isolation” and focus purely on the “simple packaging & distribution“ and “no installation” features.
Unfortunately flatpak is not secure at all; I personally would never run a flatpak on any system I consider important. It both lacks security by design and the developers have also shown callous disregard for fixing security issues.
The purported benefits provided are either not benefits at all or are in no way tied to flatpak & co. despite what people may say.
Firstly I'm just going to pick apart this quote because it was copied and pasted by someone a thousand times in a fediverse thread and it irritated me:
> Apart from offering a single bundle for different Linux distributions, Flatpak offers integration to the Linux desktops making it easier to browse, install and use Flatpak applications, e.g. the Gnome Software Center can be used to install a Flatpak.Flatpaks are forward compatible i.e. the same Flatpak app can run on the next releases of a distribution without changes.Run-time dependencies are maintained which can be used by the application.
> Apart from offering a single bundle for different Linux distributions…
This is the only real benefit I acknowledge for all these things. Even then, there's nothing saying you can't just pick one package manager and make packages for that, and then expect the community to maintain packages for their pet distros.
> …Flatpak offers integration to the Linux desktops making it easier to browse, install and use Flatpak applications, e.g. the Gnome Software Center can be used to install a Flatpak.
Why is this unique to flatpak? There is objectively nothing stopping traditional package managers from having a GUI for browsing, I see no reason why that's supposedly something only flatpak offers. In fact, KDE has a package–manager-agnostic app store called Discover:
It doesn't even introduce another competing format (See XKCD 927), instead it integrates with the existing package manager for your distro to provide an app-store like experience.
> Flatpaks are forward compatible i.e. the same Flatpak app can run on the next releases of a distribution without changes. Run-time dependencies are maintained which can be used by the application.
Wow, it's almost as if that's exactly what dynamic linking is! I just install a new version of the library and as long as it's ABI-compatible I can use it with all the existing programs! Unfortunately flatpak doesn't do that so you're usually left with very outdated libraries that often have multiple CVEs open for them. If you are going to bundle dependencies at least statically link so you get a performance boost rather than dynamically linking but without any of the benefits of dynamic linking.
In case people can't comprehend this, a big selling point for a distro is what's in its repos. If you expect people to use flatpak everywhere then you're not going to have one repo anyways because you need ultra-stable, security-backported repos for Debian; regular stable repos for a whole bunch of distros; bleeding-edge repos for Arch and co.; repos that don't depend on systemd (not even possible for snap and appimage); repos that don't depend on glibc (not even possible for snap, appimage, nor flatpak); and then you're just ignoring even more special distros like Gentoo or Slackware that don't even use traditional package styles.
And then you're including proprietary software in your repos. You cannot expect a large portion of Linux users to use your repos if you have proprietary software in them at all, even if they don't need to install it.
Why does a universal package manager need to use containers or any of that shit? If you want to make something universal, in my experience you have to make it simple and easy to implement everywhere rather than adding layer upon layer of complexity. *BSD isn't likely to implement Linux cgroups any more than Linux is likely to implement *BSD jails; and if your implementation relies on the intricacies of one or the other then it's going to be neigh-impossible to port it to any other system.
Here's a random package solution that I just came up with. A package is a .tar.gz archive of the following structure:
packagename-version.tar.gz ├── METADATA.txt │ ↑ package name, description, version, url, etc. ├── HASHES.txt │ ↑ hashes of all non-metadata files to verify integrity ├── SIGNATURES.txt (optional) │ ↑ PGP or BSD Signify signatures of HASHES.txt and METADATA.txt ├── bin │ └── [binaries go here] │ ↑ possibly add subfolders for different architectures so you could │ have multi-architecture packages. ├── lib │ └── [libraries] │ ↑ if the package is a library. possibly mutually exclusive with /bin ├── doc │ ├── man │ │ └ [man pages go here] │ ├── html │ │ └ [html documentation goes here] │ └── other │ └ [miscellaneous documentation goes here] ├── overlay │ └── [files that need to be placed in specific spots] └── [... more sections would presumably be added ...]
This is the most distilled and generic you can possibly make a package as far as I can think of. It would probably be trivial to write a package manager for pretty much any *nix system that uses this format.
While it would be much simpler to just have a compressed mock filesystem like Arch packagesᵃ, the reality is that most distros have different standards and preferences on where to place files and to maintain the portability of the manager it'd be better to let each distro configure where each file is placed. In this format, each type of file is in a generic folder so each OS could install it in the proper spot. Systems that use `/usr/bin` could install files from `bin` there, while systems that use `/bin` could instead install binaries there. If the program *needs* files to be in a specific location (configuration, etc.) then they'd be placed in a mock filesystem in the overlay directory.
Libraries and other dependencies should either be statically linked or listed in a dependency list in METADATA.txt, rather than potentially bundling horribly outdated libraries with the package.
The metadata files are stored inside the tarball to make distribution easier. With this scheme you only need to distribute one comprehensive archive instead of the package archive and a bunch of sidecar metadata files.
⁂
-- Response ended
-- Page fetched on Fri Apr 26 20:02:50 2024