Assorted questions about snapd use

1

Pasting the below from the bug report (also reported in OMG! Ubuntu!; the bug report should’ve been a forum topic, if anything, as Sergio said, so I’m turning it into a forum post) and then responding to it in a comment. Maybe snappy devs won’t want to get too embroiled in this but if we can keep the discussion civil and try and keep it factual rather than emotional then we can get something out of this when talking about the merits of snappy in the future :slight_smile: Also, if we don’t have this discussion here it’s just going to happen elsewhere so please don’t remove this :stuck_out_tongue: Instead, please move this to cafe if that is more appropriate.

Hello,

This is not really a bug, but it is important to address nonetheless. The question is: Why? Why are we developing Snap packaging, when the rest of the Linux community is going with Flatpak?

I know what you are thinking: I hate Snap, or really love Flatpak. Neither are true, and both are interesting and novel. The problem comes from mere practicality reasons. Namely:

A) According to most surveys, Linux developers and the Linux community (in general) want to use Flatpak more than Snap. In one survey, 66%/33%.

B) Flatpak already has security and confinement going through SELinux, not to mention Wayland support. Snap only has AppArmor (which not as many Linux distributions have), and doesn’t have special Wayland confinement right now.

C) Ubuntu has tried in the past to go their own way with technology, against the general Linux community’s wishes. Mir was arguably a failure. Unity8 was also a failure. Snap is going against the general Linux community again, and it seems like it is going to follow the same pattern. Why would anyone use Ubuntu when the core part of it doesn’t work like everyone else?

D) Flatpak is decentralized, versus Snap’s centralized design. This is a win for OEMs, Embedded Software, and Paid apps, but much fear around Snap comes from people afraid of letting Canonical pretty much run the show, alone by themselves. Do Red Hat, Linux Mint, and the like really want Canonical and Ubuntu to own the core servers for distributing apps?

E) gcalc, a Calculator app, totaled a whopping 58.2 MB in my testing from Ubuntu’s own snapcraft.yaml settings, which is unacceptable. Corebird is another example. 2MB in APT, 12MB in Flatpak, 112MB in Snap.

F) Snap is out-of-date as an APT package in almost all other distributions other than Ubuntu. Flatpak is up-to-date (or nearly) in almost all.

Does this mean Snap doesn’t have a place in the Linux world? Wrong, but I think a different approach is necessary. I can see why Ubuntu would like some things centralized. Here are a few solutions which may be more reasonable than trying to Snap everything:

A) Build Ubuntu out of Flatpaks (like the Linux community in general wants to do), but use Snap for IoT, Ubuntu Core, Servers, and Paid Apps. This is due to Flatpak being best for Desktop apps only.

B) Take the features of Snap, and bring them to Flatpak in a Flatpak fork. In other words, set up a Canonical-powered Flatpak server, and integrate Flatpak into launchpad. In this reasoning, think: The community in general wants Flatpak, therefore, we want to be the place where you want to host your Flatpaks. Besides a Canonical Flatpak server, a ‘ubuntu-core’ runtime, and the like, a forked version of Flatpak could also have things like buying Flatpaks and registering Flatpak names, features that Snappy has. It could even be modified to run in all places Snap would run.

I have done much research, and the only reason I have found why Snappy should be continued in development is for IoT and server. That’s it. Why should we press forward with a product the community generally doesn’t want, has various technical/practical problems, and already is being invented in the form of Flatpak? Ubuntu also needs a reputation boost after the Unity8/Mir failure. Why alienate our users again with another reinvention of something others are working on?

Thoughts?

1 Like
2

My thoughts (I’ve also included my thoughts on how snappy could improve in certain areas which I have bolded (obviously I’m just a snappy user but I’m giving my thoughts anyway)):

A)
Is there a source for that survey?
Also, just because a technology may be more popular now, doesn’t mean that it will be in the future. These are new technologies and things could change very fast. However, given snappy and Flatpak both claim to be universal packaging formats with automatic updating by default (unlike AppImage), surely ‘universal’ implies that we do want one format to win in the end or are we OK with upstream developers having to package for at least two universal packaging formats in the long-term? I suppose ‘universal’ could just mean that it works across all distributions (or aims to) rather than that it’s the sole packaging format that upstreams should use for Linux - distributions can support snappy, or Flatpak, or both, and then upstreams can choose whether to package for one or the other or for both. If, theoretically, every distribution supported snappy and Flatpak by default, then the only downside to having both installed would be more disk space taken up by duplicated platforms and the like, in exchange, developers would be able to package in whichever format they preferred (or both).

B)
‘Flatpak already has security and confinement going through SELinux’ is incorrect, as pointed out by Carlos Soriano, Flatpak actually uses ‘bwrap, which is the same as container technologies like ostree and available in every distro’. This does raise a question for Ubuntu though - not all distributions support AppArmor by default (as far as I’m aware). Why did snappy choose AppArmor rather than alternative technologies (which, if Carlos is correct, are more supported cross-distro) and what will snappy do to improve in this area (I noticed the Solus OS is incorporating/has incorporated patches to support AppArmor and progress is happening there for Debian, but how can we expect this to happen for every distro?).
‘special Wayland confinement’ I don’t know what G.S. means here.

C)
On Mir: stress on ‘arguably’, it’s still actively developed and rather popular in certain areas (one only has to search this forum for ‘mir’ to get an idea of how in demand it seems to be!)
‘against the general Linux community’s wishes’ - what is the view of the ‘general Linux community’? Distros seem to be adopting snappy, Flatpak, or both.
‘Why would anyone use Ubuntu when the core part of it doesn’t work like everyone else?’ - if it works then I imagine that people will probably use it! Like I said for B, if Ubuntu (like other distros) support both snappy and Flatpak then the only downside is more hard drive space taken up (e.g. by having a snappy GNOME platform and a Flatpak GNOME platform installed side-by-side). Also many distributions diverge from the crowd with very different features and still are used by many people! Ubuntu had diverged with Unity and Upstart and was used by many (admittedly there isn’t a consensus in the Linux community around the ‘correct’ DE, but there isn’t a consensus around the ‘correct’ universal packaging format either).

D)
On decentralization…hmm. Snappy theoretically supports multiple stores but I haven’t seen much of that in practice. On the other hand, Flatpak having multiple ‘remotes’ has its downsides as you have to add remotes before installing software. I’m guessing distribution software centers would do this automatically though! Perhaps, if other companies/individuals were willing, the servers could be shared with all the companies/individuals in control of the servers paying for the servers, if this really is an issue. However, maybe this isn’t necessary, Flatpak has made Flathub which is a centralised repository for Flatpaks, who runs that? And why doesn’t that receive the same vitriol as the snappy store? Whoever runs that, it’ll be a group of people or a person, why can you trust them more than you trust Canonical? And is your reason objective, or just subjective in that you don’t like Canonical or something?

E)
@lucyllewy is bringing down the size of Corebird as it uses the GNOME platform snap. Snappy is working on this (with platform snaps in general). Equally it wants to avoid the issue with traditional packaging systems where updates to core libraries can break applications using them (which means you either have a rolling distribution model which is not considered user-friendly for non-technical users or you have a release-based OS with outdated applications by default) - applications should be able to bundle their own libraries, this will allow a release-based OS (user-friendly/‘stable’) with up-to-date applications). But this does take up disk space, yes.

F)
This is true, is it not? Something that snappy needs to work on - keeping snapd up-to-date in all distributions. snapd does update itself from a certain version though (which one?) so once snapd hits that version in all distributions this becomes less of an issue (though it would be nice to try and keep snapd updated in all distributions as it is packaged anyway so people don’t have to download the update on install to get up-to-date snapd)

A(2))
‘like the Linux community in general wants to do’ again, this needs proving (well, I’m not sure it even can be proved!), and opinion can change fast. ‘Flatpak being best for Desktop apps only’ why is snappy no good for desktop apps? Maybe it can improve in some areas but in some ways it’s better? The simple one-file snapcraft.yaml is pretty sweet for developers (as is automated builds from build.snapcraft.io) wanting to push their apps across all Linux distributions! Yeah, this could be an option in the future (much like how Ubuntu now uses Mir for more Core-type stuff and Wayland for the desktop), but snappy is doing well in some ways at the moment and has others it can improve on - much like Flatpak!

B(2))
‘Take the features of Snap, and bring them to Flatpak in a Flatpak fork’ - sounds messy, much like what Ubuntu is trying to do with Unity and GNOME at the moment! Yeah it could work but you could also miss something. Also, why not vice versa? Why not ‘take the features of Flatpak, and bring them to snappy in a snappy fork’?

Looking at the concluding statement, much of it could also be said of Flatpak. It also ‘has various technical/practical problems, and already is being invented in the form of snappy’.

Another point I’d like to make though, is that Flatpak seems to be doing a much better job of appearing distro-neutral. The snapcraft.io website is still, as far as I’m aware, a Canonical website; I think all of the snapd and snapcraft core teams are Canonical employees (do correct me if I’m wrong! - Flatpak’s main dev is Red Hat-employed (I think?!) and then they say there’s just 'other developers); the snappy store is owned by Canonical; snappy’s branding still needs work (see the icon for this forum, for example) whereas Flatpak seemed to have nailed distro-neutral branding from the start… This does increase the vitriol leveled at snappy for not supposedly being distro-neutral. Of course, there’s only so much that snappy can do, it’s the wider Linux community’s responsibility to get involved at some point, but, like I say, Flatpak seem to have done a better job so far of appearing distro-neutral. Seems there’s some work still to do here for snappy.

1 Like
3

Hello, I am the person who filed the bug. I would like to give back my comments on the thoughts mentioned by Ads20000:

A) This survey:

https://solus-project.com/2017/01/18/adopting-flatpak-to-reassemble-third-party-applications/

Not scientific, but the fact is, a distribution chose Flatpak over Snap, because they thought Flatpak was better.

B) I was incorrect on SELinux, apparently. However, Ubuntu did choose AppArmor, which could be a problem. By “special Wayland confinement”, I meant that Flatpak supports isolating windows shown on Wayland while Snap was built to support this on Mir, so it is behind on window isolation.

C) Arguably, yes. I am talking desktop, where it has no future. For GNOME, Mir is ‘not an option’ to quote a lead developer.

Here is the problem: Ubuntu isn’t the only distro out there. Think of the big picture. When Ubuntu is the odd one out, Chances don’t look good for them. There is a reason odd one out distros aren’t as popular.

D) Why doesn’t Snap have a ‘repo’ command? Also, on Flathub, Flathub is a side project. If Canonical started a Flatpak service right now, they would be dominant, easy. Flathub is not centralized, and is not even included with Flatpak. I actually made a request for bundling Flathub with Flatpak, and it was denied.

Trust more than Canonical? Well, Canonical just failed Unity, Unity8, and Mir. Not exactly the best reputation right now.

E) I want things to be bundled, yes. But imagine, if every app is packaged using Snap as according to plan with this setup, the disk image will be several times as much right now. Obviously I anticipate a size boost with even Flatpak, but a Snap move would have a gigantic disk space cost. Far more than Flatpak.

F) True, needs help.

A(2))
‘Flatpack being best for Desktop Apps only’ - I was talking about Flatpak. Flatpak doesn’t work well for servers and IoT, but Snap does. Snap works fine for Desktop Apps, just with tremendous sizes and UI issues.
‘build.snapcraft.io’ is really sweet. That is good.

B(2))
That could also work, and wouldn’t be a bad idea.

Much better job of Appearing Neutral? Not just appearing, it is actually neutral. Snap looks super-Ubuntu.

Finally, as my final point, why doesn’t Canonical explain why Snap is better than Flatpak? Flatpak has a story, a plan. You read the plan, it makes sense why Flatpak is better than Snap. You read Snap’s plan, and it (in my opinion) doesn’t sell the same way. I think you can agree.

Here are some areas which would make Snap far more competitive:
A) Add a ‘repo’ command to add external repositories easily.
B) Some distros might just not feel comfortable including the snap store. To help reassure them, maybe just a small option to disable it, with a small option to re-enable it if disabled.
C) Shrink App Size, maybe allow more runtimes than just the ‘core’ snap
D) Advertise why it is better than Snap. Don’t just say the features, give a solid reason WHY it is better!

5

I’ll respond on the bits that I work most closely with:

A) It’s curious that Solus was lifted up as choosing flatpak when only this week they got AppArmor enabled in their kernels and full support for Solus committed to snappy. [UPDATE: I thought this was committed at the time of the post. It is in the final stages of being committed and the PR is expected to be committed very soon]

“B) I was incorrect on SELinux, apparently. However, Ubuntu did choose AppArmor, which could be a problem. By “special Wayland confinement”, I meant that Flatpak supports isolating windows shown on Wayland while Snap was built to support this on Mir, so it is behind on window isolation.”

First off, snappy uses AppArmor, but it also uses a lot of technologies like device cgroups, seccomp, devpts newinstance, and mount namespaces when constructing its sandbox. They work in concert to provide strong security with the technologies that are available today.

Secondly, snappy also supports systems without AppArmor through classic snaps and snapd devmode, so today snaps are used on Ubuntu, its derivatives, Debian, Fedora, OpenSUSE, Arch and most recently Solus.

Thirdly, AppArmor is a long-established technology that Ubuntu chose many years ago in the distribution since it was relatively easy to use, was root-strong, and had a devoted community around it. Most recently Canonical has focused on upstreaming the Ubuntu delta and that work is almost done (ie, the full AppArmor patchset will be in upstream kernels soon), so all of it will be available everywhere.

Also, snappy itself is written such that any MAC could be used as the MAC backend. Perhaps even more interesting, LSM stacking has picked up and when it is available it will make it so that distributions don’t need to make a choice; eg, SELinux and AppArmor can co-exist and be used simultaneously so, for example, snapd will be able to run strict mode snaps on a Fedora system that has full SELinux policy. In other words, while today it is harder than it needs to be to get full strict mode snaps working, that will soon be a thing of the past.

For historical context, it’s important to understand that snappy had several requirements (and more than just this-- I picked these since they were what led to some of the decisions that were made):

  1. snaps should feel like applications that are integrated into the system
  2. snaps should be able to interact with each other in controlled ways
  3. root-strong security

For ‘1’, snappy is not trying to reinvent containers technologies like Docker (application containers) and LXD (system containers). They do those jobs very well. Instead, when using a snap it should feel integrated with the system-- you see it in ‘top’, different users can use it, the snaps can see each other if the policy allows it, etc. This is possible because we use the global namespace for all but the mount namespace. A MAC like AppArmor allows the snap to operate within the global namespace but still be isolated from privileged parts of the system (eg, systemd) or other snaps.

For ‘2’ snapd has ‘interfaces’ and this is based on templated policy, which is relatively easy to do with AppArmor-- each snap command runs with a security label under a security profile that is based on a default security policy template which may be extended via interfaces. AppArmor uses so-called ‘dynamic labeling’ which means it is very flexible and lends itself to this sort of templated policy.

AppArmor is root strong. We also wanted layers of security so we use AppArmor with seccomp, device cgroups and mount namespaces. We wanted snappy to have strong security for leaf applications like desktop apps, but also for servers and IoT that run as root or need hardware access. Importantly, the design of snappy and interfaces has the concept of auto-connections (for safe accesses) and manual-connections (for privileged accesses) where snapd, the gadget developer, the developer, store and the user all have a voice in the security policy and if it is automatically applied upon install, and the user/admin has full control over interface connections.

As for wayland support-- snapd in master already has a wayland interface and there is a PR undergoing review for using it with modern (ie wayland) desktop environments. These will be available in snapd 2.28 and the Ubuntu Desktop team is working with GNOME and the upstream software (eg, portals) to make those desktop services available to snaps as well. This is healthy collaboration on low level details for the services that snaps/flatpaks will use. Snappy isn’t tied to GNOME either-- these upcoming interfaces will work with Plasma and even more niche wayland desktops like Sway and we welcome collaboration on all fronts. Today, many desktop applications are already shipping as snaps, with more to come. I see no reason why snappy can’t continue to improve and deliver a great desktop app experience.

4 Likes
6

Because there is no “better” here, they are conceptually so different that you cant really merge much on the technical level …

Let me quote what i wrote in the omgubuntu discussion:

"Just to give some historic background here since I read everywhere “both projects are young and/or immature” …

The project this bug was filed under (snappy on launchpad) has a registration date from 2014 …

Snap as generic package format had its first stable release in early/mid 2015 and has since matured a lot on the low level, addressing all possible issues around generic packaging but did not have much support on the desktop at that time …

Features like automatic rollback, transactional and delta upgrades, snap interfaces and the like have been used for kernel snaps, bootloader snaps, server and tooling snaps already for quite a while before in mid/end 2015 dell started selling fully snap based industrial/IoT gateways (since then plenty other commercial vendors, drone and robotics manufacturers joined in).

In early 2016 snap packages were announced to also support desktop apps and to be supported by default in all Ubuntu 16.04 based installs … In or around the same time fedora announced that the til then idling xdg-apps project would be revived and renamed to flatpak …

Flatpak is great as a delivery and execution wrapper for desktop apps, no doubt, and there should be joint operation on this level around i.e. the desktop portals …

But flatpak is by no means a generic package format nor is it as mature as snap on the lower packaging level … Not to mention that with the snapcraft tool you can create a snap within minutes from any existing source (or even binary) by simply creating a single yaml file…

In the end they are similar but completely different things … (like apples and oranges are both fruit) but definitely not equally mature/immature …"

1 Like
7

Great news! :grinning::grinning: Thanks for the technical response :slight_smile:

8

Happy to see that we have a distro other than Ubuntu shipping with Snap!

Also, AppArmor may be amazing, totally. If Snap supports SELinux and AppArmor, that is all for the win!

The major problems with Snappy on the desktop are (in my opinion):

    1. No external repos (this is a big one!)
    1. Gigantic app sizes. Maybe a solution would be to allow people like GNOME to make runtimes like Flatpak, but you can decide whether you want a runtime or not.
    1. Odd UI (though will be fixed eventually)
9

there is:

ogra@styx:~$ snap info snapstore-example
name:      snapstore-example
summary:   "Minimalist example snap store"
publisher: noise
contact:   bret.barker@canonical.com
description: |
  snapstore is a minimalist example of a "store" for snaps, based on the public
  API specs (https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex). It
  allows anyone to host their own collection of snaps for installation on
  supported platforms.
  
  See http://snapcraft.io for more information on creating and using snap
  packages.
  
snap-id:     6Dvc1anJ89H4lOd6TeizeRigV3ubzViG
channels:            
  stable:    0.3 (4) 44MB -
  candidate: 0.3 (4) 44MB -
  beta:      0.3 (4) 44MB -
  edge:      0.3 (8) 8MB  -

Read up about the content interface. We use lib-based-snaps that share their content since the first mir-kiosk snap was released (more than 1.5 years ago). Specifically for Gnome apps check this forum for the gnome-3-24 content snap …

Not sure what that means but if you refer to themes, this is in the works … (there are multiple threads about this in this forum)

1 Like
10

While I’m happy to talk about any one of those topics, having all of them in such an unfocused list generally creates a thread that reads like a rant making it hard to get to agreements, and anyone learning anything at all (myself included obviously) becomes hard because we’ll be jumping from idea to idea without any order. In other words, this is a recipe for speaking across each other.

For that reason, I’m going to close this thread down, and encourage whoever is interested in honestly discussing these ideas to open independent topics covering one piece at a time so that these conversations can be more productive. Again for emphasis: not trying to stop the conversation, but rather to have that same conversation in a way we’ll all find more pleasant to read and participate on.

I’ll make a few final remarks just to encourage the upcoming topics to start on the right foot:

  1. For any statistics, please provide source which details how they were acquired. I believe snaps are more popular today, by a large margin. This is a guess, and I’m saying so. Anyone is free to guess otherwise, but what doesn’t make sense is providing data without a source that would allow us to evaluate the conditions in which it was obtained.
  2. Let’s please try to provide good, up-to-date information. Solus, the very project described in the original points, seems to be pretty happy about snaps.
  3. Along similar lines, we already have a snap that is reused across snaps, so that’s a non-issue really. Also, even assuming snaps have to be large for some other reason, snapd supports deltas which make even such large snaps pretty much irrelevant in practice.
  4. Many of the perceived issues in the desktop are being worked on (design, proper usage, etc), as you can watch here in the forum. But again, we cannot give the proper attention to such technical details right next to high-level points.

So, again, closing it down, but please do feel free to raise independent topics for conversation.