8 ms·

Canonical’s Snap: The Good, the Bad, and the Ugly

55 points by slyall 10y ago

IshKebab 10y ago
That didn't really give any details about what is good, bad or ugly about Snap.
danieldk 10y ago
This piece is only about politics, which is the usual drama: most players have an NIH-attitude and we'll end up with three different standards. No one is helped except for news outlets who can proceed to construct a nice dramatic 'he said, she said' story. It would be more interesting to see an in-depth technical comparison of Linux app container implementations, so that an outsider can make an informed choice.
- bkor 10y ago
  Politics are quite important to do right and politics is different from NIH. The article notes two important things: 1) Canonical wanting to do big announcements. This causes problems if you want to work with communities. They'll try and work and get support, but one person per distribution isn't the same as working with the entire community. So when the announcement implies that there's broad support, the communities feel like it is a big lie. That'll destroy the willingness to cooperate. 2) Canonical likes to keep control. E.g. the CLA. Canonical has special rights nobody else will have. Companies don't like this at all, it changes the working together into helping a competitor. It doesn't make business sense. Canonical tries to solve things by e.g. saying you keep the copyright, but that is just ignoring the actual issue. This CLA has been an issue for various Canonical projects for many years. An "we might change this" I don't trust. Similarly, Canonical rolled this out while the code only supports the Canonical proprietary app store. Someone else now made a open/free source (not sure which) store, but at the moment the experience quite assumes just one app store. Those two things together make people want to refrain from spending time (doesn't matter much if they're paid or not). Note: I'm biased and I like Flatpak as well as AppImage. I don't see the problem in having multiple standards. Canonical is IMO very good at having a great Ubuntu experience. They're (again IMO) terrible at doing cross distribution work due to reasons explained above.
  - cbHXBY1D 10y ago
    I too am leaning toward Flatpak. I expect it, like other products from Red Hat (systemd, pulseaudio) will eventually be the winner in the end.
  - digi_owl 10y ago
    Canonical want to be in control because they are looking at trademarks etc. Also they are a small player in the pool compared to certain other companies, and thus have to fight harder to be heard. Btw, all you need to distribute snaps is a web server afaik.
- alex_duf 10y ago
  NIH?
  - insulanian 10y ago
    Not Invented Here
- legulere 10y ago
  I think it's more that there are 3 different factions. The modernists (Redhat, Suse, Arch, ...) Cannonical (which are also modernists, but Cannonical and the modernists don't work together) The don't change anything faction (Gentoo, Slackware, ...) > It would be more interesting to see an in-depth technical comparison of Linux app container implementations, so that an outsider can make an informed choice. If one takes MIR/Wayland as an example, the differences will probably be minuscle, so social factors will be way more important than technical ones.
  - digi_owl 10y ago
    I dunno about "don't change anything" with regards to Gentoo. Frankly both Gentoo and Slackware is in the end about letting the admin/user have the final say. Even if this means blowing their virtual foot of with a virtual shotgun. You can see this in how gentoo provides all manner of useflags that ebuilds take into account, and how slackware have no dependency enforcement. The impression i have is that Canonical and certain DE people get in a row over trademarks and UX. Canonical wants to present a certain UX when people use their distro, while the DE people wants a fixed experience for their DE (to the point of reshaping whole distros to their demands). Those two goals clash.
cs702 10y ago
The technical criticisms here are not really directed at Snap, but at the trade-offs inherent to the sandboxed-application packaging model in general. Speaking as day-to-day desktop Linux user, a working sandboxed-app model would be a BIG improvement over rpms and debs. I would LOVE to be able to install any version of any application, or multiple versions, independently of OS and library versions, without having to compile from source code, grapple with conflicting dependencies, etc. Are there any F/LOSS alternatives to Snap that are as widely used and tested? If there aren't any, Snap is really our "least worst" alternative.
- NoGravitas 10y ago
  There is allegedly a standard, xdg-app, from freedesktop.org. Flatpak, mentioned in the article, is AFAIK the only existing implementation of the standard, and seems to be associated with Gnome and loosely associated with Fedora.
  - bkor 10y ago
    Xdg-app was renamed into Flatpak. It is a standard like Snappy probably has a document describing the technical workings. Flatpak (though I like it) is too new, preventing anyone from calling it a de facto standard. For Flatpak, the scope is limited to just desktop apps. Then to break out of the sandbox it'll provide 'Portals'. They work a bit like Mac OS X / Android / iOS. The goal is to limit the permissions by default. User interaction of portals should be great, you don't really notice the difference. Portal support will only come to GTK as of 3.22 (September 2016), see https://blogs.gnome.org/mclasen/2016/07/08/portals-using-gtk-in-a-flatpak/ https://blogs.gnome.org/mclasen/2016/07/08/portals-using-gtk.... Until Qt/GTK+ supports these portals Flatpak does NOT fully sandbox else you'd have problems using the app. Sandbox is done using standard kernel functionality (namespaces, etc). Snappy requires AppArmor. Without that, no sandboxing. There's a promise to also support SELinux, though not sure what timeframe they intend. Snappy on distributions without AppArmor (e.g. Fedora) will NOT sandbox the app! Snappy IIRC is not just limited to desktop apps, which IMO limits the sandbox options. AppImage can do sandboxing using other software (Firejail) which again relies on AppArmor. It seems the AppArmor profile comes with the app, which IMO defeats the security. This as IMO it would be nice to not have to trust the app you just installed. For all above: any effective sandboxing requires Wayland/Mir, not X11. Noticed someone said you might be able to make X11 secure by putting an app within xephyr/xnest security filtering like program, but IMO that's a blue sky idea (tell me once it works and one of the sandbox solutions provides full integrated support).
throw2016 10y ago
This unfortunately reads like a hit piece with no information of Snap at all. It's like the author did not even install Snap raising questions about the premise and purpose of the article. Where is the good, bad and ugly? For instance branding Ubuntu initiatives like Snap or Mir as 'NIH' and leaving Redhat supported ones like XDG, Flatpak, Systemd etc is itself an act of politics and manipulation. This leaves little room for informed discussion. Linux is heavily politicised with tons of vested interests and thousands of folks and projects sponsored by or in the employment of various players. Maybe its time to stop tiptoeing around the politics and let it out in the open so there can be more informed discussion and less of the simplistic PR driven fantasy narratives like 'fedora is independent but Ubuntu is not' that this article pushes.
jhasse 10y ago
Is it correct that I'll need to login with an Ubuntu One account to install a Snap package?
- dkarapetyan 10y ago
  Of course not. That wouldn't make any sense. Do you need to log into any account to install rpm or deb package?
- marcoceppi 10y ago
  You do not need to login to anything to install a snap.
SFJulie 10y ago
systemd a superior solution ? Guh. If we had not systemd and had kept it simple stupid, there would be no need for snap: - you compile the application in static (à la windows) - and you do a chroot (or as they call it a namespace). Ksss, I am wrong, I see it. But then, when you make a multi-tiers architecture, how do you make stuff communicate? Well, easy, web services. But how do you know where they are? How do you print? How do you register PlayMediaKey as a way to start your application? How do you make sure the «right application» can set the time (ntp/system preferences) while other applications are kept away? Guh .... registry base? Autodiscovery? You need a bus? An IPC? And what of the mess of Xorg? How do I prevent applications to see or intercept informations they should not see? Most engineers have troubles with a basic group/permission model already and OSX/AD have proven that a more complex schema based on a complex namespace often in practice results to poorer results.... how do we make access secured? Oh! you still have the "one application in foreground has all rights"... the kind of tablet model à la iOS. But then, we are losing the advantage of multitasking... like listening to music while writing or playing games. So back again in square one of being confined BUT able to cooperate. JAVA and its JVM was a way to answer this problem: let's forget all of this and control at the application layer of the JVM. But then, how do you talk to hardware? java or not, application needs to know about the hardware, but we have no fixed address for HW devices (minor/major nodes are long gone, and PCI/USB vendor id are not pointing to a single HW target since long) So maybe we could have a virtual HW that talks to the real HW with a translation in the middle ? (VMware, Xen...) Ho! But I want to make sure I develop for a single target! Well, good luck unifying games dev in a single image while making sure the screensaver don't override it, while not preventing security applications to do emergency locks... and still having the right level of acceleration... And then, the world of confinment is biting his tails always asking itself the same questions. For the old persons, let's just accept that easy image deployment could be like on Amiga/C64/amstrad &al: a unique HW, with a single application. You jump to org and execute the ASM in single mode. Problem solved. But the more we expect from easy to code with cooperation (wouldn't it be ridiculous to put printer/HD/SD driver in a text application, network/audio/video driver in a browser) the more our apps are dependent from an ecosystem that is a moving target. Basically there can be no easy confinement (application snapshot) without a unified abstraction of HW and services as well of their properties whereas the complexity of OS is growing (more HW, more protocols, more "required dependencies" à la systemd). Basically confined image deployment on heterogeneous system/HW is a chimera unless you confine yourself to very basic tasks that requires no dependencies (like mono post calculus in FORTRAN using stdin/stdout). We are just in the hell of the dependencies. And I don't think there is any silver bullet for this situation. This problem grows more than linearly in complexity as a cross product of all the potential differences in the configuration space. Let's forget about chimeras. The complexity is dooming the costs model of application development. As the HW/OS landscape is splitting in different direction with legacy systems still needing updates, development has to face the world of a constant progress/obsolescence where devs are told to forget about past platforms to be hype, and customers have the need to keep their legacy systems in production. Sometimes there is no solutions to a problem.
dkarapetyan 10y ago
This is again more political bullshit. I know exactly what is going to happen. We are again going to have 3 different ways to package containerized applications and someone is going to come along and create another `fpm` but this time for containerized applications. I'm going to go back to pretending that `deb` and `rpm` don't exist and my packaging format is `fpm`.
- em3rgent0rdr 10y ago
  https://xkcd.com/927/ https://xkcd.com/927/ "How Standards Proliferate" :P
joveian 10y ago
"Snap is the equivalent of static linking". So why not statically link? Encouraging software to work with static linking would be helpful for unikernels also. With delta compression, I think my weekly updates on Arch are at least 200MiB, not even counting particularly large packages. Over a month, nearly half the system is replaced. For static linking (or equivalent) to be practical for those of us with limited bandwidth connections there would need to be some excellent cross-binary delta compression. In some situations it is useful, but for a general purpose system I think shared libraries make more sense. OpenPandora's PND system is another example of prior art. http://pandorawiki.org/Introduction_to_PNDs http://pandorawiki.org/Introduction_to_PNDs
- deleted 10y ago
  [deleted]
marcoceppi 10y ago
> CoreOS and Red Hat are sponsors of The New Stack.

55 points by slyall 10y ago

That didn't really give any details about what is good, bad or ugly about Snap.

This piece is only about politics, which is the usual drama: most players have an NIH-attitude and we'll end up with three different standards. No one is helped except for news outlets who can proceed to construct a nice dramatic 'he said, she said' story. It would be more interesting to see an in-depth technical comparison of Linux app container implementations, so that an outsider can make an informed choice.

bkor 10y ago
Politics are quite important to do right and politics is different from NIH. The article notes two important things: 1) Canonical wanting to do big announcements. This causes problems if you want to work with communities. They'll try and work and get support, but one person per distribution isn't the same as working with the entire community. So when the announcement implies that there's broad support, the communities feel like it is a big lie. That'll destroy the willingness to cooperate. 2) Canonical likes to keep control. E.g. the CLA. Canonical has special rights nobody else will have. Companies don't like this at all, it changes the working together into helping a competitor. It doesn't make business sense. Canonical tries to solve things by e.g. saying you keep the copyright, but that is just ignoring the actual issue. This CLA has been an issue for various Canonical projects for many years. An "we might change this" I don't trust. Similarly, Canonical rolled this out while the code only supports the Canonical proprietary app store. Someone else now made a open/free source (not sure which) store, but at the moment the experience quite assumes just one app store. Those two things together make people want to refrain from spending time (doesn't matter much if they're paid or not). Note: I'm biased and I like Flatpak as well as AppImage. I don't see the problem in having multiple standards. Canonical is IMO very good at having a great Ubuntu experience. They're (again IMO) terrible at doing cross distribution work due to reasons explained above.
- cbHXBY1D 10y ago
  I too am leaning toward Flatpak. I expect it, like other products from Red Hat (systemd, pulseaudio) will eventually be the winner in the end.
- digi_owl 10y ago
  Canonical want to be in control because they are looking at trademarks etc. Also they are a small player in the pool compared to certain other companies, and thus have to fight harder to be heard. Btw, all you need to distribute snaps is a web server afaik.
alex_duf 10y ago
NIH?
- insulanian 10y ago
  Not Invented Here
legulere 10y ago
I think it's more that there are 3 different factions. The modernists (Redhat, Suse, Arch, ...) Cannonical (which are also modernists, but Cannonical and the modernists don't work together) The don't change anything faction (Gentoo, Slackware, ...) > It would be more interesting to see an in-depth technical comparison of Linux app container implementations, so that an outsider can make an informed choice. If one takes MIR/Wayland as an example, the differences will probably be minuscle, so social factors will be way more important than technical ones.
- digi_owl 10y ago
  I dunno about "don't change anything" with regards to Gentoo. Frankly both Gentoo and Slackware is in the end about letting the admin/user have the final say. Even if this means blowing their virtual foot of with a virtual shotgun. You can see this in how gentoo provides all manner of useflags that ebuilds take into account, and how slackware have no dependency enforcement. The impression i have is that Canonical and certain DE people get in a row over trademarks and UX. Canonical wants to present a certain UX when people use their distro, while the DE people wants a fixed experience for their DE (to the point of reshaping whole distros to their demands). Those two goals clash.

cs702 10y ago

The technical criticisms here are not really directed at Snap, but at the trade-offs inherent to the sandboxed-application packaging model in general. Speaking as day-to-day desktop Linux user, a working sandboxed-app model would be a BIG improvement over rpms and debs. I would LOVE to be able to install any version of any application, or multiple versions, independently of OS and library versions, without having to compile from source code, grapple with conflicting dependencies, etc. Are there any F/LOSS alternatives to Snap that are as widely used and tested? If there aren't any, Snap is really our "least worst" alternative.

NoGravitas 10y ago
There is allegedly a standard, xdg-app, from freedesktop.org. Flatpak, mentioned in the article, is AFAIK the only existing implementation of the standard, and seems to be associated with Gnome and loosely associated with Fedora.
- bkor 10y ago
  Xdg-app was renamed into Flatpak. It is a standard like Snappy probably has a document describing the technical workings. Flatpak (though I like it) is too new, preventing anyone from calling it a de facto standard. For Flatpak, the scope is limited to just desktop apps. Then to break out of the sandbox it'll provide 'Portals'. They work a bit like Mac OS X / Android / iOS. The goal is to limit the permissions by default. User interaction of portals should be great, you don't really notice the difference. Portal support will only come to GTK as of 3.22 (September 2016), see https://blogs.gnome.org/mclasen/2016/07/08/portals-using-gtk-in-a-flatpak/ https://blogs.gnome.org/mclasen/2016/07/08/portals-using-gtk.... Until Qt/GTK+ supports these portals Flatpak does NOT fully sandbox else you'd have problems using the app. Sandbox is done using standard kernel functionality (namespaces, etc). Snappy requires AppArmor. Without that, no sandboxing. There's a promise to also support SELinux, though not sure what timeframe they intend. Snappy on distributions without AppArmor (e.g. Fedora) will NOT sandbox the app! Snappy IIRC is not just limited to desktop apps, which IMO limits the sandbox options. AppImage can do sandboxing using other software (Firejail) which again relies on AppArmor. It seems the AppArmor profile comes with the app, which IMO defeats the security. This as IMO it would be nice to not have to trust the app you just installed. For all above: any effective sandboxing requires Wayland/Mir, not X11. Noticed someone said you might be able to make X11 secure by putting an app within xephyr/xnest security filtering like program, but IMO that's a blue sky idea (tell me once it works and one of the sandbox solutions provides full integrated support).

throw2016 10y ago

This unfortunately reads like a hit piece with no information of Snap at all. It's like the author did not even install Snap raising questions about the premise and purpose of the article. Where is the good, bad and ugly? For instance branding Ubuntu initiatives like Snap or Mir as 'NIH' and leaving Redhat supported ones like XDG, Flatpak, Systemd etc is itself an act of politics and manipulation. This leaves little room for informed discussion. Linux is heavily politicised with tons of vested interests and thousands of folks and projects sponsored by or in the employment of various players. Maybe its time to stop tiptoeing around the politics and let it out in the open so there can be more informed discussion and less of the simplistic PR driven fantasy narratives like 'fedora is independent but Ubuntu is not' that this article pushes.

jhasse 10y ago

Is it correct that I'll need to login with an Ubuntu One account to install a Snap package?

dkarapetyan 10y ago
Of course not. That wouldn't make any sense. Do you need to log into any account to install rpm or deb package?
marcoceppi 10y ago
You do not need to login to anything to install a snap.

SFJulie 10y ago

systemd a superior solution ? Guh. If we had not systemd and had kept it simple stupid, there would be no need for snap: - you compile the application in static (à la windows) - and you do a chroot (or as they call it a namespace). Ksss, I am wrong, I see it. But then, when you make a multi-tiers architecture, how do you make stuff communicate? Well, easy, web services. But how do you know where they are? How do you print? How do you register PlayMediaKey as a way to start your application? How do you make sure the «right application» can set the time (ntp/system preferences) while other applications are kept away? Guh .... registry base? Autodiscovery? You need a bus? An IPC? And what of the mess of Xorg? How do I prevent applications to see or intercept informations they should not see? Most engineers have troubles with a basic group/permission model already and OSX/AD have proven that a more complex schema based on a complex namespace often in practice results to poorer results.... how do we make access secured? Oh! you still have the "one application in foreground has all rights"... the kind of tablet model à la iOS. But then, we are losing the advantage of multitasking... like listening to music while writing or playing games. So back again in square one of being confined BUT able to cooperate. JAVA and its JVM was a way to answer this problem: let's forget all of this and control at the application layer of the JVM. But then, how do you talk to hardware? java or not, application needs to know about the hardware, but we have no fixed address for HW devices (minor/major nodes are long gone, and PCI/USB vendor id are not pointing to a single HW target since long) So maybe we could have a virtual HW that talks to the real HW with a translation in the middle ? (VMware, Xen...) Ho! But I want to make sure I develop for a single target! Well, good luck unifying games dev in a single image while making sure the screensaver don't override it, while not preventing security applications to do emergency locks... and still having the right level of acceleration... And then, the world of confinment is biting his tails always asking itself the same questions. For the old persons, let's just accept that easy image deployment could be like on Amiga/C64/amstrad &al: a unique HW, with a single application. You jump to org and execute the ASM in single mode. Problem solved. But the more we expect from easy to code with cooperation (wouldn't it be ridiculous to put printer/HD/SD driver in a text application, network/audio/video driver in a browser) the more our apps are dependent from an ecosystem that is a moving target. Basically there can be no easy confinement (application snapshot) without a unified abstraction of HW and services as well of their properties whereas the complexity of OS is growing (more HW, more protocols, more "required dependencies" à la systemd). Basically confined image deployment on heterogeneous system/HW is a chimera unless you confine yourself to very basic tasks that requires no dependencies (like mono post calculus in FORTRAN using stdin/stdout). We are just in the hell of the dependencies. And I don't think there is any silver bullet for this situation. This problem grows more than linearly in complexity as a cross product of all the potential differences in the configuration space. Let's forget about chimeras. The complexity is dooming the costs model of application development. As the HW/OS landscape is splitting in different direction with legacy systems still needing updates, development has to face the world of a constant progress/obsolescence where devs are told to forget about past platforms to be hype, and customers have the need to keep their legacy systems in production. Sometimes there is no solutions to a problem.

dkarapetyan 10y ago

This is again more political bullshit. I know exactly what is going to happen. We are again going to have 3 different ways to package containerized applications and someone is going to come along and create another `fpm` but this time for containerized applications. I'm going to go back to pretending that `deb` and `rpm` don't exist and my packaging format is `fpm`.

em3rgent0rdr 10y ago
https://xkcd.com/927/ https://xkcd.com/927/ "How Standards Proliferate" :P

joveian 10y ago

"Snap is the equivalent of static linking". So why not statically link? Encouraging software to work with static linking would be helpful for unikernels also. With delta compression, I think my weekly updates on Arch are at least 200MiB, not even counting particularly large packages. Over a month, nearly half the system is replaced. For static linking (or equivalent) to be practical for those of us with limited bandwidth connections there would need to be some excellent cross-binary delta compression. In some situations it is useful, but for a general purpose system I think shared libraries make more sense. OpenPandora's PND system is another example of prior art. http://pandorawiki.org/Introduction_to_PNDs http://pandorawiki.org/Introduction_to_PNDs

deleted 10y ago
[deleted]

marcoceppi 10y ago

> CoreOS and Red Hat are sponsors of The New Stack.