6 ms·

Id rather have static binaries than a flatpak/snap for "universal distribution", personally.

amelius 4y ago
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 https://forum.snapcraft.io/t/limitations-in-snapd/9718 This actually means that at some point I will have to move away from Ubuntu.
- bityard 4y ago
  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.
  - amelius 4y ago
    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.
    - Y_Y 4y ago
      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.
    - lgeek 4y ago
      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
      - amelius 4y ago
        Thanks, I'll have to look into it.
- Gordonjcp 4y ago
  Why don't you just mount your big disk on /home, like we used to do in the olden days?
  - amelius 4y ago
    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).
    - Gordonjcp 4y ago
      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.
      - amelius 4y ago
        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.
- manchmalscott 4y ago
  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.
  - amelius 4y ago
    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.
kaba0 4y ago
Either static or dynamic is fine, package management has to be solved at another layer a la Nix.
- AmalgatedAmoeba 4y ago
  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.
  - pxc 4y ago
    No. The Nix approach lets you retain the reuse, and it can be extended to allow quick, unified 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 recompiling it. Traditional static linking is strictly worse.
  - ParetoOptimal 4y ago
    Huh, never heard it put this way. I guess it's true though. Anyone disagree?
    - pxc 4y ago
      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 https://youtu.be/HZKFe4mCkr4 1b: https://youtu.be/lzk4sldexX4 https://youtu.be/lzk4sldexX4 2: https://fzakaria.com/2022/03/15/shrinkwrap-taming-dynamic-shared-objects.html https://fzakaria.com/2022/03/15/shrinkwrap-taming-dynamic-sh... 3: https://fzakaria.com/2022/09/12/making-runpath-redundant-for-nix.html https://fzakaria.com/2022/09/12/making-runpath-redundant-for...
zeta0134 4y ago
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.
- modzu 4y ago
  flatpak > appimage for security and updates.
  - bombolo 4y ago
    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.
    - modzu 4y ago
      sorry, is this an argument that appimage has advantages over flatpak for security and updates? could u elaborate?
      - bombolo 4y ago
        No I'm saying that flatpack can be as bad as appimage because nobody checks.
- 0cf8612b2e1e 4y ago
  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.
bombolo 4y ago
appimage > flatpack > snap
rowanG077 4y ago
I agree static binaries or at the very least something akin to nix where every binary has a pinned dynamic lib.
rubicks 4y ago
Please, $DEITY, deliver us from this hell wrought by Canonical.

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 https://forum.snapcraft.io/t/limitations-in-snapd/9718 This actually means that at some point I will have to move away from Ubuntu.

bityard 4y ago
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.
- amelius 4y ago
  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.
  - Y_Y 4y ago
    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.
  - lgeek 4y ago
    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
    - amelius 4y ago
      Thanks, I'll have to look into it.
Gordonjcp 4y ago
Why don't you just mount your big disk on /home, like we used to do in the olden days?
- amelius 4y ago
  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).
  - Gordonjcp 4y ago
    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.
    - amelius 4y ago
      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.
manchmalscott 4y ago
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.
- amelius 4y ago
  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.

kaba0 4y ago

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

AmalgatedAmoeba 4y ago
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.
- pxc 4y ago
  No. The Nix approach lets you retain the reuse, and it can be extended to allow quick, unified 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 recompiling it. Traditional static linking is strictly worse.
- ParetoOptimal 4y ago
  Huh, never heard it put this way. I guess it's true though. Anyone disagree?
  - pxc 4y ago
    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 https://youtu.be/HZKFe4mCkr4 1b: https://youtu.be/lzk4sldexX4 https://youtu.be/lzk4sldexX4 2: https://fzakaria.com/2022/03/15/shrinkwrap-taming-dynamic-shared-objects.html https://fzakaria.com/2022/03/15/shrinkwrap-taming-dynamic-sh... 3: https://fzakaria.com/2022/09/12/making-runpath-redundant-for-nix.html https://fzakaria.com/2022/09/12/making-runpath-redundant-for...

zeta0134 4y ago

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.

modzu 4y ago
flatpak > appimage for security and updates.
- bombolo 4y ago
  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.
  - modzu 4y ago
    sorry, is this an argument that appimage has advantages over flatpak for security and updates? could u elaborate?
    - bombolo 4y ago
      No I'm saying that flatpack can be as bad as appimage because nobody checks.
0cf8612b2e1e 4y ago
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.

bombolo 4y ago

appimage > flatpack > snap

rowanG077 4y ago

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

rubicks 4y ago

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