[schmichael]

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.

[amelius]

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.

[curt15]

Flatpak ticks all of those boxes: https://github.com/flatpak/flatpak/wiki/Tips-&-Tricks

[FZY0E1RnLM]

Sounds like Nix or Guix.

[schmichael]

Lots of package management systems support these features. Even MSIs from Microsoft despite Windows ironically lacking a centralized repo until recently.

[2ion]

No streamlined enterprise support (insurance), no nix or guix, except for running ON established enterprise linux distributions.

[yjftsjthsd-h]

Both nix and guix are happy to run on top of an existing Linux distro.

[ashtonkem]

That's an organizational limitation, not a technical one.

[zrm]

> 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]

> 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.

[im3w1l]

Mobile apps are a hellscape. It's an example of how wrong things can go. Apps treat their privilege model as a license to abuse all their privileges as much as possible.

Ability to read Contact list? Location access? Great let's upload it all to the Googbook analytics for data mining our customers.

[schmichael]

But what's the alternative? No MAC and every app has all user privileges by default like most Linux distros?

I would argue the concept has not failed, just the implementations have fallen short. And for good reason! It's an extremely complex confluence of cutting edge technology, UX, security, privacy, etc. It's been improving, and surely the open source community can do it even better (or at least with a greater focus on privacy).

[nikau]

It would be nice to have a prompt when the phone asks for phone book access:

Allow Deny Fake

The Fake would just have generated names and numbers to pollute their data mining.

[ric2b]

> Libraries should have major versions and the latest of each major version should be compatible with anything using that major version

Should, but accidental breaking changes are a thing. Plus flatpack more or less solves this by having standard runtimes (base collections of libraries/dependencies that flatpack apps target) that get security updates.

> 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.

With Snap, developers explicitly ask for the permissions they need and the approval process evaluates if it makes sense for that app to have those permissions (and by default or not).

[zrm]

> Should, but accidental breaking changes are a thing.

They're a thing either way. If a library has a security update that breaks your app, your choices are to have a security vulnerability or to have a broken app, until somebody fixes whatever is broken in either the library or the app. The only good option is to fix the breakage quickly -- or do better testing to begin with.

> Plus flatpack more or less solves this by having standard runtimes (base collections of libraries/dependencies that flatpack apps target) that get security updates.

At which point they might as well be their own packages so that you only have to install one copy of that version, since they're the same for every application anyway.

> With Snap, developers explicitly ask for the permissions they need and the approval process evaluates if it makes sense for that app to have those permissions (and by default or not).

This is not a solution to the hardness. If the developer doesn't understand the permissions model well enough to know to ask for a given permission they need, the app is broken. If they ask for permissions they don't need, either the approvers need to understand the app well enough to know it doesn't need that, or they approve permissions it doesn't need.

It doesn't get you out of needing somebody who understands both the app and the permissions model well enough to be able to correctly specify which permissions the app needs and doesn't.

[ric2b]

This permissions model and approval process already works in mobile app stores. Yeah, if the developer doesn't understand the permissions model they ship a broken app, so what? Are we supposed to expose our computers so that incompetent developers don't break their own apps accidentally?

[zrm]

> This permissions model and approval process already works in mobile app stores.

The permissions are too coarse-grained. Flashlight apps ask for ridiculous permissions and get them. Some permissions are "too dangerous" so you can't have them even if the user trusts you completely and you have a good reason, which makes certain apps impossible. It's rubbish.

> Yeah, if the developer doesn't understand the permissions model they ship a broken app, so what?

So then they err on the side of requesting too many permissions, which is made even worse when they're coarse-grained.

> Are we supposed to expose our computers so that incompetent developers don't break their own apps accidentally?

What Linux does, to start, is to not package things from incompetent developers. If your app is nothing but a fork of Thunderbird that uploads all the user's contacts to your server, Debian isn't going to package that because there's no demand for it. But you could get the equivalent thing into the app stores, because things get there when developers push them there, not when packagers pull them there.

Then the Linux apps have the source code for anybody to view and modify. If the app was originally written to do something problematic, you can modify the app not to do that before distributing it.

That makes the permissions model much less important, because the problem of malicious apps is much reduced and all you need it for is containing bugs.

Your app isn't supposed to access the network, so you assert as such. Then if it has a bug or somehow gets compromised, the system can at least prevent it from accessing the network.

But you don't have such an aggressive tension between false positives and false negatives because more of the false positives got eliminated through having access to the source code and not packaging garbage apps to begin with. If a Debian packager doesn't restrict the app from accessing the network even though it didn't really need to, probably doesn't matter anyway. If an app store does the same thing, that was the only thing preventing the app from sucking up all your contacts and sending them to a third party server.

[afiori]

> 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.

As I see it the problem that containerization in snaps and similar solution is the isolation of system configuration.

I agree that permissions are an hard problem and honestly I am not sure how much they are relevant for snaps, but what is theory is feasible is that installing a snap could be completely and reversible.

I believe that is true of flatpack at least.

[zrm]

> As I see it the problem that containerization in snaps and similar solution is the isolation of system configuration.

If you drop your app's config file in /etc/ and nothing ever touches it, isolation isn't really buying you anything. If something does, that could still be what you want to happen.

For example, suppose there is a P2P app that can operate either by having you forward a port from your router (which is not always available) or by operating as a Tor onion service. To do the latter it has to modify Tor's configuration so that it allows incoming connections to the application's port. It's something you want to happen, it's something the package can clean back up again when it's uninstalled, but that doesn't work if the two otherwise independent applications have their configurations isolated from each other.

So it's still the permissions problem.

[afiori]

I would say that more than having your own config be left alone, the complex case is when two different applications want to mess up a third party configuration.

Software repos as a whole in part exist to solve and harmonize these cases.

[alkonaut]

> people have to maintain them all separately.

Yes. I think most people (most people don't run Linux in any form) would like to think of their system as having a collection of independent applictions, not a set of libraries.

If people are expected to "maintain", or even understand, the concept of shared libraries, then I think the system is only geared to power users and tinkerers (the current user base more or less).

[zrm]

The people who maintain the libraries are not the users, they're the library package maintainers.

If you move the libraries into the application packages then the package maintainers for every application also have to maintain every library they use, duplicating the efforts of one another. The users then suffer when they do it poorly because they don't have the time or domain expertise to maintain multiple third party libraries in addition to their own application.

[2ion]

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]

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

[stubish]

rpm/yum shares a number of apts problems, and certainly doesn't fix all of them.

[enriquto]

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]

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]

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]

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.

[znpy]

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

[BiteCode_dev]

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]

> 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.

[navaati]

And Flatpak is that much more than snap is !