Assorted questions about snapd use

[gjsman]

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 for Solus Linux, 66%/33%.

B) Flatpak already has security and confinement, not to mention Wayland support. Snap only has AppArmor (which not as many Linux distributions have), and doesn't have special Wayland desktop window 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?

[Zygmunt Krynicki (zyga)]

We are developing snapd because people we interact with actually like snaps. I applaud flatpak and appimage developers but I don't think we should ask an ill-defined "community" and then choose to close the shop because they voted one or another way. As for the claimed data: who did you ask?, how many people are in this community? how many people understand how flatpak, appimage and snapd work? how many developers vs users did you ask?

Asking community about complex technical decisions is like asking for random people about brexit. Most people cannot grasp the complexity behind the problem, yet alone have an opinion.

In the case of "linux community" there is no such thing, there is no way to enumerate us, let alone make scientifically valid studies.

So really, we develop snapd because we think it's a great way to distribute software, the people that interact with us (users and developers alike) like what they are getting and I have never seen this amount of positive feedback on a project as young as this.

[Justyn Butler (justyn)]

It would be great to see some more detailed responses to this from Canonical and the Snappy team.

I think many people like myself are looking at the Snap/Flatpak situation and seeing Mir/Wayland all over again, at least when it comes to the desktop. It feels like it could play out in almost exactly the same way.

If Canonical can articulate why they think Snaps should be used over Flatpak, particularly moving forward as each system picks up features and begins to resemble the other anyway, then it might help put minds at ease.

Also, is Snap handicapped in becoming a "universal" packaging format to be used across distros if it requires contributors to sign a CLA licensing their code to Canonical, whereas Flatpak does not?

[Nate Graham (pointedstick)]

If I could guess, it's because the folks making Snappy believe it is superior to Flatpak. OpenSUSE chairman Richard Brown, who loves Flatpak, had some words of warning for Flatpak in a recent talk at GUADEC:

https://www.youtube.com/watch?v=SPr--u4n8Xo

https://speakerdeck.com/sysrich/guadec-2017-flatpak-future-or-resurrected-dinosaur

All three technologies (Flatpak, Snappy, and AppImage) are very new and immature. It seems premature to announce any single one as the winner already, though I will say that it's sort of an unfortunate situation to have as usual so much reinvention of the wheel--especially for a technology aiming to reduce fragmentation.

[Oliver Grawert (ogra)]

if you actually want a discussion use https://forum.snapcraft.io/ and not the bug tracker ...

[Sergio Schvezov (sergiusens)]

This is the wrong place to discuss this, if it even is a discussion at all.

[Alberto Salvia Novella (es20490446e)]

There's really nothing to discuss: they do Snappy because they think it's a better alternative, the same that if I do a painting it would be because I liked to.

Nobody needs approval to start working on something. If you dislike the option, just pick up a different one. Having options is the first step for having better standards.

[Ads20000 (ads20000)]

I've created a thread here https://forum.snapcraft.io/t/why-snappy-the-big-debate/1738/
I know snappy devs may not want to get too embroiled but I think if we're going to have the debate we may as well have a civil one on the forums :)

[Khurshid Alam (khurshid-alam)]

A) You only scratched the surface on your counter point A. Yes, Flatpak is for desktop users, not for rest of the world. As we speak snap core is being used in various iot devices. I heard Honeywell will use snap in their next generation thermostat!! Read https://www.ubuntu.com/internet-of-things

SNAP is miles ahead and wins.

B) WRONG.

Apparmor is default in debian and Ubuntu based distro. Do you have any idea how many disto based on debian? Check this out and get awed :

https://upload.wikimedia.org/wikipedia/commons/1/1b/Linux_Distribution_Timeline.svg

C) That's your assumption. Ubuntu doesn't go against anything.....It goes with flow.....

Blame RH for forcing immature technology on general Linux community. Wayland, Systemd, Pulseaudio, Telepathy...we have seen it all. Wayland, after nearly 10 years development, still buggy and slow, can't play well with video drivers...hell it can't even take screenshot on desktop, where Mir after very short time can do all. Mir had far less devs than Wayland.

Mir is still in development and beside it didn't actually fail but rather Mark cut out the development due to financial crisis. And RH is far bigger company than canonical.

D) Nobody cares about which one is centralized and which one is not. The thing what matter is which one works. And SNAP works. You do not have the right idea about internal working of snaps.

You see,

The big difference is that Snap can also run services, and if you go to http://snapcraft.io you wont find just apps, but also databases and servers! with limitations though, like GVFS access, which can be "relaxed" for specific Snaps. Flatpak at the moment doesn't have no such scheme.

So, short Snap does everything Flatpak does, and more! plus it currently has a more user friendly CLI, which is fantastic.

E) And flatpak along with runtime is over 1 GB for calculator app. Snap app + run-time is far smaller than flatpak! Don't believe me? You better believe it. :P

F) Out of date only for Gnome apps, similarly various server tools and standard libraries already available as snaps. It is also possible to offer full Gnome with snaps !!!!! I doubt that opposite can be true.

I believe Canonical intends to do the right thing but they do not have the money to pull it off. If Canonical has the money, Ubuntu will be ios/android in linux world.

[Seth Arnold (seth-arnold)]

On Thu, Aug 17, 2017 at 09:54:44PM -0000, Khurshid Alam wrote:
> Apparmor is default in debian and Ubuntu based distro. Do you have any
> idea how many disto based on debian? Check this out and get awed :

AppArmor is available in Debian but not the default. A discussion is
underway about testing AppArmor on-by-default in Debian testing in the
lead-up to releasing Buster (what a mouthful):

https://lists.debian.org/debian-devel/2017/08/msg00090.html

Thanks

[gjsman (g.s.)]

Hi, I am the poster of this comment.

I have some responses to comments to defend my position.

A) I didn't say Snap was useless, I think it is doing amazing things in IoT. But snapping everything may not work.

B) As said by Seth Arnold, AppArmor is NOT default in Debian.

C) Ubuntu doesn't go against anything? They are going against Flatpak with Snap. They went against everyone with Unity. They went against everyone with Mir. They went against everyone with Convergence. And over and over, Failure, Failure, Failure. I am worried that

"Blame RH for forcing immature technology on general Linux community. Wayland, Systemd, Pulseaudio, Telepathy...we have seen it all. Wayland, after nearly 10 years development, still buggy and slow, can't play well with video drivers...hell it can't even take screenshot on desktop, where Mir after very short time can do all. Mir had far less devs than Wayland."

Mir could not even copy and paste until recently. Don't say Mir was free of issues.

Red Hat forcing immature technology? Wayland is still buggy, but it is getting better, default on Fedora. Can't play well with video drivers? Still did better than Mir. Mir had far less devs than Wayland, true. So instead of fighting the larger, join them and use your devs to improve it. If you can't beat 'em, join 'em. Would have made Wayland come quicker, and would have possibly saved some money.

D) Nobody? Look at the posts. Look in the communities for various distributions. I have seen this being perhaps the top complaint with Snap!

E) Wrong! The org.gnome.Platform runtime is approximately 200MB, and gedit (similar in size to gcalc) is 1.6MB in Flatpak. That is less than 1/4 the size you thought Flatpak would be.

F) The opposite would be true, but isn't yet because Flatpak has more security settings. Which is a better problem to have.

"It would be great to see some more detailed responses to this from Canonical and the Snappy team.

I think many people like myself are looking at the Snap/Flatpak situation and seeing Mir/Wayland all over again, at least when it comes to the desktop. It feels like it could play out in almost exactly the same way.

If Canonical can articulate why they think Snaps should be used over Flatpak, particularly moving forward as each system picks up features and begins to resemble the other anyway, then it might help put minds at ease."

I totally agree. Canonical, GIVE us a real, solid reason why Snap is better than Flatpak! I see Snap becoming the next Mir/Unity, and part of the reason I filed this bug was because I didn't want Canonical wasting a ton of money to damage their reputation if it happens again.

"We are developing snapd because people we interact with actually like snaps. I applaud flatpak and appimage developers but I don't think we should ask an ill-defined "community" and then choose to close the shop because they voted one or another way. As for the claimed data: who did you ask?, how many people are in this community? how many people understand how flatpak, appimage and snapd work? how many developers vs users did you ask?"

I saw Solus, who chose Flatpak voicing the similar concerns as mine.

The community is ill-def...

[gjsman (g.s.)]

At least, could we abandon the idea for snapping everything in 18.04?

https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-17.04-Unity-8-Snaps-Talk

Apps this size... not a good thing.

[Justin Zobel (justin-zobel)]

Justin from Solus here. Projects evolve and opinions change over time. Solus now offers Snaps in addition to Flatpak: https://solus-project.com/2017/08/15/solus-3-released/

I could lay out our reasoning for you with my own words, but I think Ikey put together a strong argument already: https://plus.google.com/u/0/+IkeyDoherty/posts/QF86urMjkqo

[Daniel van Vugt (vanvugt)]

E) In the bug description you point out that a Snap can easily be an order of magnitude larger than a Flatpak. However in comment #10 it is said that "The org.gnome.Platform runtime is approximately 200MB". So it sounds like a Flatpak'd desktop can ship smaller apps by having more/larger dependencies built in to the core. That sounds reasonable for a desktop, but is contrary to Snappy's initial design. Snaps could do the same if we wanted; that's just a fixable bug/feature and not an argument against Snaps' existence.

But I think all sides are losing the size argument (see iOS too). If you write plain C code then your binary size should be on the same order of magnitude as the source code. It contains the same /information/.

[gjsman (g.s.)]

I actually filed this bug because I wanted Snap to either drop the desktop or improve the desktop based on my points.

I could have revised my text more, but submitted it late at night. Still, if Snap can fix some of the points I have made, then yeah, Go Snap!

[gjsman (g.s.)]

This discussion will continue on:

https://forum.snapcraft.io/t/why-snappy-the-big-debate/1738/

I urge all readers of this to please continue the discussion there. The more technical responses and thought we have, the better for everyone.

[gjsman (g.s.)]

Discussion on external repositories:

https://forum.snapcraft.io/t/external-repositories/1760/1

[Damiön la Bagh (kat-amsterdam)]

This really comes down to the big difference between the philosophy behind Canonical, RedHat and their respective communities.

RedHat's business model is make things as difficult as possible to install, use, configure and maintain so they can sell expensive courses to teach people how to perform those tasks. When people using RedHat even after the course can't figure it out they sell expensive support contracts and use expensive consultants to help you on your way.
The GNU/Linux community behind them create things that are expressly over-complicated to use and maintain. This gives them a sense of status, as only they know how to use it and also gives them some sense of job security. This is great for Enterprise environments that expect this type of treatment. This group is trying to communicate with computers as if they themselves are computers.

Canonical's business model is make things people *want* to use, are comfortable using and are more 'human' in feel. They are not trying to screw everyone over with courses, unreasonable support contracts and expensive consultants. They are trying to nurture and protect their community to achieve both their own commercial goals as well as the goals of the community.
 This section of the GNU/Linux community doesn't want to type a jumble of hard to remember symbols and characters just to run, install, configure or maintain their application. They want something that just works with as little hassle as possible and can go a bit deeper if they need to fine tune something. This group is trying to interact with computers as humans.

Due to these differences;
Snap needs to exist for the Ubuntu 'human' community and to balance out Flatpacks complexity.

==== Extra arguments ===
Same argument for the existence of AppArmour. From a security standpoint AppArmour is much safer than the extremely complex SELinux because AppArmour is less complex to configure. Thus reducing the chance someone makes a typo in the config that results in a security disaster.

As was the argument for Upstart. Upstart just works, out of the box, no lengthy configuration necessary. systemd is a configuration nightmare with insane hard-to-type commands no-one can remember.

Someone was talking about the Canonical License Agreement as well in this thread. The CLA is there to protect your ass from being sued by Patent Trolls. Caonical steps up to the plate to take responsibility for your application. It's there to protect GNU software writers from Patent trolls and a real shame people are still blind to this.
========================

[Gustavo Niemeyer (niemeyer)]

Everyone, let's please be respectful. We don't view open ended aggressive and dismissive comments about any community with good eyes. Even ignoring the fact that this a cross-distribution project with members of many of those communities right here, we in the open source world are in fact a pretty small universe and 1) depend on each other; 2) work with each other; 3) have *friends* across those psychological walls.

Let's please not have further comments here. The original creator of this issue is being extremely kind in creating independent topics in the forum so that the conversation can be organized and civilized. If you care about the points originally presented above, please go to the forum and kindly read what is being said and feel free to present your views in context and in a productive way:

https://forum.snapcraft.io

[N. W. (nw9165-3201)]

Question turned around:

https://github.com/flatpak/flatpak/issues/1288