Given the choice I prefer native package -> AUR package -> AppImage -> Flatpack, in that order. (snap, you'll notice, is absent)

Arch is pretty good at making the native packages work, so that's always ideal. The community is generally pretty good at competently packaging AURs, and they'll do it for slightly less free things, so that fills a lot of gaps. AppImages and Flatpaks are great when they work, but opaque and difficult to diagnose when they don't :/ And snap is just... unpleasant. It's insistence to auto update separately from my package manager has really turned me off of it's whole ecosystem. No thanks.

flatpak > appimage for security and updates.

Well you can statically link stuff in a flatpak… a distribution package however gets automatically rebuilt when a dependency changes, if it's statically linked.

sorry, is this an argument that appimage has advantages over flatpak for security and updates? could u elaborate?

No I'm saying that flatpack can be as bad as appimage because nobody checks.

Why AppImage over Flatpack? I like the Flatpack ability to easily restrict network access to binaries. Probably possibly in all of the packaging formats, but limiting permissions feels like a functional piece of Flatpack.

Because AppImages need no daemons and plumbing. They are self contained binaries which contain everything it needs to run.

Running a big infra to run a single binary once in a while feels like a burden to some of us.

Flatpak also doesn't need daemons beyond what the app is using.

Yet you need to install flatpak package and its dependencies to run flatpak applications. Not to mention the flatpak package contains a four ".service." files, too.

They might not be triggered and launched all the time, but this mode of operation is different from .appimage files, which are just ordinary binary files you directly run.

Snap really sucks because it forces you to have a /home/user/snap folder on the same filesystem as /. If you don't have that (e.g. home folder symlinked to another filesystem), then snap starts breaking in very weird ways.

https://forum.snapcraft.io/t/limitations-in-snapd/9718

This actually means that at some point I will have to move away from Ubuntu.

Debian is very nice these days if you don't mind a tiny bit of enabling non-free repos. Or Pop OS for a more It Just Works approach, if their desktop suits your fancy.

Right now I'm stuck with nVidia's Jetson line of products which is vendor-locked to Ubuntu. The problem is that while you can extend them with a large SSD drive, these products have a really small disk used for /. I could run another OS inside a Docker container, all to avoid this limitation in snap, but of course things will not become prettier.

You've been able to run the root on (nvme) SSD for a while now with Dusty's scripts, and more recently with the official installer.

I have great sympathy though, I am also using Ubuntu on Jetson and resent snap, especially since the new releases are 20.04 which have it more tightly integrated.

You can change the root parameter in extlinux.conf to point to whatever block storage you want it to

Or reconfigure U-Boot to load extlinux.conf (and the kernel image, initrd, etc) entirely from other type of media. IIRC NVMe, USB and external SDs are all supported

Thanks, I'll have to look into it.

Why don't you just mount your big disk on /home, like we used to do in the olden days?

Because I suspect that snap uses both /home/user/snap and /var/.../snap, and needs them to be on the same disk (to allow hardlinking, I suppose).

Have you tried it?

Sounds like something a bindmount might fix.

Back in the olden days before simple and convenient packaging systems like snap had been invented, we had to get pretty creative so that stuff didn't freak out because it was split across filesystems.

I haven't tried it, but I can remember people on forums having mixed results with a bindmount. I guess there is no guarantee that it works until Snap has been running for a while without problems.

I don't see anything there about needing to be on the same filesystem, just that the path is of the form /home/$user/snap. It says that having a home directory that isn't mounted at boot doesn't work, but that's different. Am I missing something?

I'm not sure why you'd need to symlink /home/ to another filesystem instead of just mounting that on /home/ directly, that's what I'm doing with root on ZFS and a separate dataset for /home/ with it's own mountpoint.

Snap also stores stuff in /var/snap, and that probably also has to live on the same filesystem.

Anyway, now I'm working around limitations in Snap instead of Snap working around its own limitations in certain circumstances. The fact that Snap shows weird behavior and illogical error messages in these cases tells me that Snap is not (yet) up to the task of fulfilling this rather fundamental role in my OS.

Either static or dynamic is fine, package management has to be solved at another layer a la Nix.

Nix is effectively transforming dynamic binaries to static ones. Might as well skip the step, stop pretending that drive space is expensive, and link everything statically.

No. The Nix approach lets you retain the reuse, and it can be extended to allow for uniform security patching as well (which has been done already in the Guix project).

And if you really want a single redistributable binary, any existing package can easily be bundled into one without decompiling it.

Traditional static linking is strictly worse.

Huh, never heard it put this way. I guess it's true though.

Anyone disagree?

What about completely optional dependencies which might get loaded at runtime based on some dynamic criteria? Dynamic libs are not primarily for space saving. Also, there are thousands of other packaging problems not solved by static binaries, so yes, I do disagree with grandparent commenter :D

Farid Zakaria recently gave a talk¹ (at NixCon 2022) where I think he put it better: Nix (and Guix) blur the line between dynamic and static linking.

I think this is true, because with Nix and Guix, you actually have an end result with the positive characteristics of both kinds of linking.

His talk, based on his work on shrinkwrap² and nix-harden-needed², called for the creation of a new executable format for the Nix world. Seems apropos as a reminder that there are other possibilities!

(I think these kinds of solutions are definitely within reach for Valve from a technical perspective. Other tools are using them today.)

--

1a: https://youtu.be/HZKFe4mCkr4

1b: https://youtu.be/lzk4sldexX4

2: https://fzakaria.com/2022/03/15/shrinkwrap-taming-dynamic-sh...

3: https://fzakaria.com/2022/09/12/making-runpath-redundant-for...

Conceptually that's kind of true, if you only consider the end result for a given binary, (since it would load only shared libs as if they were statically linked).

But multiple derivations can share dependencies, which does save space and also makes it easy to identify dependencies of a given derivation, where statically linking would make that opaque.

Also, the story goes way beyond binaries, as dependencies often carry additional resources not bundled into the binary.

RAM is still expensive…

appimage > flatpack > snap

I agree static binaries or at the very least something akin to nix where every binary has a pinned dynamic lib.

Please, $DEITY, deliver us from this hell wrought by Canonical.