11 ms·

I think there are some very good critiques of snap (performance, provenance, reproducibility, namespacing, etc), and the first couple points in this article see

I think there are some very good critiques of snap (performance, provenance, reproducibility, namespacing, etc), and the first couple points in this article seem reasonable. However I can't agree with this: > apt/deb is a wonderful package management system and everyone is happy with it, at least the majority of Ubuntu/Debian users. Besides, dnf/rpm is also a similar packaging system for Fedora/RH systems and everyone is happy with that too. Debs and rpms are great at assembling tightly coupled monolithic systems. Great! Let's keep using them for the base system. However when I want to install a QT app on a Gnome system or gasp a proprietary app, Debs are insufficient. I want all of the QT libs embedded in the package. I want the proprietary app in a container. I want MAC with a polished UX. I don't want debs to worry about those features. I want an "app store" done right: open yet verifiable. Protection in depth.

znpy 6y ago
Then snaps could be the solution for proprietary software, not for regular software.
- BiteCode_dev 6y ago
  Statistically, proprietary software is regular software. But yeah, snaps is a great solution for that, espacially because getting a non FOSS software is not possible in official distro repos, and hosting your own repo is HARD. And that's what's happening. I installed Telegram using a snap because of this.
  - Yetanfou 6y ago
    > Statistically, proprietary software is regular software. Statistically, proprietary software in the world of Linux is a black swan. Free software is the rule, proprietary software the exception to the rule which tends to be used only when there are no alternatives.
amelius 6y ago
And I want: - a user-space install option - rollback functionality (!) - being able to install multiple versions at the same time and switch between them - if I really need to: being able to install the latest version (and even an unstable release); if that means that apt-get has to download and compile stuff, then I'm ok with that.
- FZY0E1RnLM 6y ago
  Sounds like Nix or Guix.
  - 2ion 6y ago
    No streamlined enterprise support (insurance), no nix or guix, except for running ON established enterprise linux distributions.
    - ashtonkem 6y ago
      That's an organizational limitation, not a technical one.
    - yjftsjthsd-h 6y ago
      Both nix and guix are happy to run on top of an existing Linux distro.
  - schmichael 6y ago
    Lots of package management systems support these features. Even MSIs from Microsoft despite Windows ironically lacking a centralized repo until recently.
- curt15 6y ago
  Flatpak ticks all of those boxes: https://github.com/flatpak/flatpak/wiki/Tips-&-Tricks https://github.com/flatpak/flatpak/wiki/Tips-&-Tricks
navaati 6y ago
And Flatpak is that much more than snap is !
2ion 6y ago
I can only comment on snap for the server (non-desktop) side of things but packages in Ubuntu, which are Debian packages, contain random (none or a lot) amounts of shell scripts /var/lib/dpkg/info/* which may fail for any reason and introduce any number of side effects into the system, as they handle sometimes very complex software migrations and can change any number of things. Surely the desktop has some history here too (packaged proprietary graphics drivers for example doing unspeakable things to Xorg configs come to mind). Snap is a way to contain / scope this kind of scripted activity. This is a welcome change. Additionally, deb/apt has much worse transaction support than yum and its successors (you can simply roll back yum transactions, good luck rolling back a borked APT system where package maintainer scripts already have done unspeakable things to the system and you're kind of stuck). APT's configuration system is also arcane and badly documented; debhelpers that control how most packages are built and work are tens of thousands of lines of perl, python, C++, C, makefile and m4 code that somehow work but are in no way a way to build straightforward predictable packages. It's ultra flexible, but also ultra complex. The trend in package / release management is going towards simplification, and not complication. A stop gap solution were many projects that allow the generation of Debian packages from venvs, random directory trees (for which you could also use the deprecated old-style DEBIAN package format and pass it to dpkg-build without the arcane dpkg-* toolchain, but again, Debian claims these this kind of packaging is not "well formed", and who knows when it gets removed). Snaps are just a different way to do integrated containerized applications with scoped config management, versioning and a release system on top (which makes the difference). Perhaps somebody could make a better solution. Meanwhile, RedHat introduced AppStreams -- probably Canonical also felt it needed an answer to that. Ubuntu's exposure to their "universe" repository component, many packages in which are badly maintained and are not a great part of the release QA, is also a huge risk as an enterprise distribution (where the money is) so it is no surprise that Canonical is looking to decouple their core offering on the server platform from that and maybe at some point remove it from the base install altogether ("take your own risk") and then drop it.
- brnt 6y ago
  If rpm/yum fixes much of apts problem, why didn't Ubuntu change for that?
enriquto 6y ago
What you want is static executables. It is sad that those are not typically packaged in dependence-free debs, but there's nothing really against it.
- Wowfunhappy 6y ago
  Yes, sign me up please! You don't necessarily need to go all the way down to statically linking libc, but if just about everything else could be included in the binary, that would be lovely. We have come up with such convoluted solutions to this problem—Docker, nix, Snap, etc—when the simple option is sitting in front of us. And it works! On my Mac, I don't want to install homebrew or MacPorts—Package managers make me feel like I never know the state of my system—so when I need a command line tool, I try to either track down or otherwise compile (in a VM) a static binary. When I can find them, they work perfectly!
  - enriquto 6y ago
    You can link libc statically, it's probably smaller than the other stuff you use. If you are really worried about size you can use the musl which is quite smaller. The only problem I have found with static linking is for programs that use opengl, that need to be linked to a specific version of the graphics drivers. If you try to statically link a program that depends on libGL, it may work for you with an nvidia chipsed, but then it will fail at runtime for somebody that does not have the same type of graphic card. I do not know of a clean solution for this problem, regarding static linking; but I would love to know.
    - Wowfunhappy 6y ago
      I'm not against linking libc statically, but the reason I brought that up is to preempt a counterargument I always see: what happens if a security vulnerability is found in libc, and just about every single program needs to be recompiled? My response is either (A) so what, go ahead, it's worth the complexity tradeoff for static binaries, but also (B) you can link a tiny handful of core system libraries dynamically, and still reap most of the simplicity benefits of static linking. The latter approach solves the OpenGL problem too. If there are real cases where users would need to swap that out, go ahead and link it dynamically. The goal needn't to remove all dependencies, but to avoid the quagmire of hundreds (or more) of nested dependencies.
deleted 6y ago
[deleted]
zrm 6y ago
> I want all of the QT libs embedded in the package. I don't understand why anybody wants this. Libraries should have major versions and the latest of each major version should be compatible with anything using that major version, because that's what major version means for a library. You might then need to have more than one major version of the library installed, but any two applications using the same one should be able to use the same copy, and then have it maintained by one person in one place. If every package has a separate copy of every library, people have to maintain them all separately. When that library has a security update, you now have to update five dozen packages instead of one or two, and have a security vulnerability if any of the maintainers don't keep up in a timely fashion. Which not all of them will. > I want the proprietary app in a container. People want containers to be magic but they're actually a hard problem. You want the app not to be able to do anything you don't want it to but still be able to do everything you do want it to. A backup app that can't read my files is useless; it can't back them up. But it shouldn't be able to modify or delete them. But it should be able to modify its own state. It shouldn't have general network access but should be able to communicate with the backup server, which might have to be specified by the user and not the package maintainer. It doesn't need access to the GPU or the ability to use gigabytes of memory, but it does need to be able to transfer a lot of data over the network, but the data it transfers is lower priority than other network packets. That requires the person configuring the app's container to have both detailed knowledge of the app and detailed knowledge of the container system. It's common for this not to be the case. And that's why containers are a mess, not anything to do with the package manager, which should have little to do with the container system outside of packaging the app's default container configuration with the app.
- schmichael 6y ago
  > I don't understand why anybody wants this. Because creating debs is largely a completely distinct undertaking from the dependency and build management the developer of an app does. Bundles, whether via images or static binaries, allow app developers to distribute their app against the exact dependencies it was developed against -- potentially using the same build system. There's obviously tradeoffs to each approach, which is why I don't think there's one right way to distribute every bit of executable code on a system. > People want containers to be magic but they're actually a hard problem. I work on a container orchestrator, so I understand some of the difficulty. :) Mobile apps are years ahead of desktop apps when it comes to containerizing in a user friendly way. Obviously there's plenty of work still to be done, but the problem is far from intractable and the benefits are enormous.

znpy 6y ago

Then snaps could be the solution for proprietary software, not for regular software.

BiteCode_dev 6y ago
Statistically, proprietary software is regular software. But yeah, snaps is a great solution for that, espacially because getting a non FOSS software is not possible in official distro repos, and hosting your own repo is HARD. And that's what's happening. I installed Telegram using a snap because of this.
- Yetanfou 6y ago
  > Statistically, proprietary software is regular software. Statistically, proprietary software in the world of Linux is a black swan. Free software is the rule, proprietary software the exception to the rule which tends to be used only when there are no alternatives.

amelius 6y ago

And I want: - a user-space install option - rollback functionality (!) - being able to install multiple versions at the same time and switch between them - if I really need to: being able to install the latest version (and even an unstable release); if that means that apt-get has to download and compile stuff, then I'm ok with that.

FZY0E1RnLM 6y ago
Sounds like Nix or Guix.
- 2ion 6y ago
  No streamlined enterprise support (insurance), no nix or guix, except for running ON established enterprise linux distributions.
  - ashtonkem 6y ago
    That's an organizational limitation, not a technical one.
  - yjftsjthsd-h 6y ago
    Both nix and guix are happy to run on top of an existing Linux distro.
- schmichael 6y ago
  Lots of package management systems support these features. Even MSIs from Microsoft despite Windows ironically lacking a centralized repo until recently.
curt15 6y ago
Flatpak ticks all of those boxes: https://github.com/flatpak/flatpak/wiki/Tips-&-Tricks https://github.com/flatpak/flatpak/wiki/Tips-&-Tricks

navaati 6y ago

And Flatpak is that much more than snap is !

2ion 6y ago

I can only comment on snap for the server (non-desktop) side of things but packages in Ubuntu, which are Debian packages, contain random (none or a lot) amounts of shell scripts /var/lib/dpkg/info/* which may fail for any reason and introduce any number of side effects into the system, as they handle sometimes very complex software migrations and can change any number of things. Surely the desktop has some history here too (packaged proprietary graphics drivers for example doing unspeakable things to Xorg configs come to mind). Snap is a way to contain / scope this kind of scripted activity. This is a welcome change. Additionally, deb/apt has much worse transaction support than yum and its successors (you can simply roll back yum transactions, good luck rolling back a borked APT system where package maintainer scripts already have done unspeakable things to the system and you're kind of stuck). APT's configuration system is also arcane and badly documented; debhelpers that control how most packages are built and work are tens of thousands of lines of perl, python, C++, C, makefile and m4 code that somehow work but are in no way a way to build straightforward predictable packages. It's ultra flexible, but also ultra complex. The trend in package / release management is going towards simplification, and not complication. A stop gap solution were many projects that allow the generation of Debian packages from venvs, random directory trees (for which you could also use the deprecated old-style DEBIAN package format and pass it to dpkg-build without the arcane dpkg-* toolchain, but again, Debian claims these this kind of packaging is not "well formed", and who knows when it gets removed). Snaps are just a different way to do integrated containerized applications with scoped config management, versioning and a release system on top (which makes the difference). Perhaps somebody could make a better solution. Meanwhile, RedHat introduced AppStreams -- probably Canonical also felt it needed an answer to that. Ubuntu's exposure to their "universe" repository component, many packages in which are badly maintained and are not a great part of the release QA, is also a huge risk as an enterprise distribution (where the money is) so it is no surprise that Canonical is looking to decouple their core offering on the server platform from that and maybe at some point remove it from the base install altogether ("take your own risk") and then drop it.

brnt 6y ago
If rpm/yum fixes much of apts problem, why didn't Ubuntu change for that?

enriquto 6y ago

What you want is static executables. It is sad that those are not typically packaged in dependence-free debs, but there's nothing really against it.

Wowfunhappy 6y ago
Yes, sign me up please! You don't necessarily need to go all the way down to statically linking libc, but if just about everything else could be included in the binary, that would be lovely. We have come up with such convoluted solutions to this problem—Docker, nix, Snap, etc—when the simple option is sitting in front of us. And it works! On my Mac, I don't want to install homebrew or MacPorts—Package managers make me feel like I never know the state of my system—so when I need a command line tool, I try to either track down or otherwise compile (in a VM) a static binary. When I can find them, they work perfectly!
- enriquto 6y ago
  You can link libc statically, it's probably smaller than the other stuff you use. If you are really worried about size you can use the musl which is quite smaller. The only problem I have found with static linking is for programs that use opengl, that need to be linked to a specific version of the graphics drivers. If you try to statically link a program that depends on libGL, it may work for you with an nvidia chipsed, but then it will fail at runtime for somebody that does not have the same type of graphic card. I do not know of a clean solution for this problem, regarding static linking; but I would love to know.
  - Wowfunhappy 6y ago
    I'm not against linking libc statically, but the reason I brought that up is to preempt a counterargument I always see: what happens if a security vulnerability is found in libc, and just about every single program needs to be recompiled? My response is either (A) so what, go ahead, it's worth the complexity tradeoff for static binaries, but also (B) you can link a tiny handful of core system libraries dynamically, and still reap most of the simplicity benefits of static linking. The latter approach solves the OpenGL problem too. If there are real cases where users would need to swap that out, go ahead and link it dynamically. The goal needn't to remove all dependencies, but to avoid the quagmire of hundreds (or more) of nested dependencies.

deleted 6y ago

[deleted]

zrm 6y ago

> I want all of the QT libs embedded in the package. I don't understand why anybody wants this. Libraries should have major versions and the latest of each major version should be compatible with anything using that major version, because that's what major version means for a library. You might then need to have more than one major version of the library installed, but any two applications using the same one should be able to use the same copy, and then have it maintained by one person in one place. If every package has a separate copy of every library, people have to maintain them all separately. When that library has a security update, you now have to update five dozen packages instead of one or two, and have a security vulnerability if any of the maintainers don't keep up in a timely fashion. Which not all of them will. > I want the proprietary app in a container. People want containers to be magic but they're actually a hard problem. You want the app not to be able to do anything you don't want it to but still be able to do everything you do want it to. A backup app that can't read my files is useless; it can't back them up. But it shouldn't be able to modify or delete them. But it should be able to modify its own state. It shouldn't have general network access but should be able to communicate with the backup server, which might have to be specified by the user and not the package maintainer. It doesn't need access to the GPU or the ability to use gigabytes of memory, but it does need to be able to transfer a lot of data over the network, but the data it transfers is lower priority than other network packets. That requires the person configuring the app's container to have both detailed knowledge of the app and detailed knowledge of the container system. It's common for this not to be the case. And that's why containers are a mess, not anything to do with the package manager, which should have little to do with the container system outside of packaging the app's default container configuration with the app.

schmichael 6y ago
> I don't understand why anybody wants this. Because creating debs is largely a completely distinct undertaking from the dependency and build management the developer of an app does. Bundles, whether via images or static binaries, allow app developers to distribute their app against the exact dependencies it was developed against -- potentially using the same build system. There's obviously tradeoffs to each approach, which is why I don't think there's one right way to distribute every bit of executable code on a system. > People want containers to be magic but they're actually a hard problem. I work on a container orchestrator, so I understand some of the difficulty. :) Mobile apps are years ahead of desktop apps when it comes to containerizing in a user friendly way. Obviously there's plenty of work still to be done, but the problem is far from intractable and the benefits are enormous.