Goodbye apt and yum? Ubuntu’s snap apps are coming to distros everywhere

More secure replacement for debs coming to Fedora, Arch, Debian, and more.

Read the whole story

 

[h3nrch]

stormcrash[/url]":1xf9p1v3]

DCRoss[/url]":1xf9p1v3]

stormcrash[/url]":1xf9p1v3]Holy Crap! A unified package manager being adopted by nearly every major Linux Distro! Linux as a desktop platform just got a lot more viable to develop/distribute for. The days of .deb vs .rpm could soon be at an end

And the days of .dsnap vs .rsnap will be coming instead.

Did you miss the part where it said the changes per distro are made in snapd and not in the packages themselves? So no, there will not be .dsnap and .rsnap, just .snap and a tailored daemon per platform that the package makers don't have to think about

So snapd is really a dependency manager and .snap is the common API? In the short term it might be attractive but it's not hard to see fragmentation occur as cloud specific distros dominate. Canonical should have included AWS, GCS, and Azure first.

 

[berrardo]

the whole dependency bundling trend (single jar apps included) is enabled by not caring whether your app is 10MB or 100MB.

Except, of course, for the TENS OF MILLIONS of us who "enjoy" bandwidth of less than 5Mbits. (At most 0.5MB per second.)

You guys who live in the ivory towers and the steel&glass cocoons need to remember that. Guess how long it takes to "grab" a 1.5GB distro. Have mercy.

 

[berrardo]

each library is only installed once?

The way I understand it, each library is installed *once per app*. If 15 apps use it, 15 app.snaps contain the library.

 

[jjduru]

The_Barbarian[/url]":10o91p4o]>and could replace your package manager

No. Fuck off

Now tell us how you really feel...

 

[jjduru]

Blinken[/url]":nzvbi9sx]Slackware 4 life! /s

Sorry to burst your bubble sunshine, but Slackware was antiquated more than 12 years ago. Check the year in your calendar app. If you have one.

 

[riversidedrive]

Oh snap!

P.S. Three pages of comments and no one said it yet?!

 

[georgeh2k]

snap sounds like a good thing. As a side issue from the article describing security issues with X, people have been talking about replacing the X window system for years and years. Wayland was started in 2008. Mir was announced in 2013. Here it is 2016, and there still is not much adoption at all of either replacement for X. For any replacement of X, I'll believe it when I see it.

 

[Gooberslot]

Snaps by default don't have the same access to the file system that Linux applications typically have, he said. For example, a browser delivered in a snap package would be unable to read a user's SSH keys, because snap-based applications are given their own private space and can only read and write in that area.

I'm curious how that is going to work. A paint program like Krita is going to need to access image files all over the filesystem. Same thing with a browser, I don't want to be told I can only save downloaded files in one particular directory.

 

[rupucis]

If snap packages were meant for Ubuntu phones, why does my Ubuntu phone get updates in the form of system images and why does using apt-get on it break stock apps?

 

[raxx7]

Gooberslot[/url]":3igo4nug]

Snaps by default don't have the same access to the file system that Linux applications typically have, he said. For example, a browser delivered in a snap package would be unable to read a user's SSH keys, because snap-based applications are given their own private space and can only read and write in that area.

I'm curious how that is going to work. A paint program like Krita is going to need to access image files all over the filesystem. Same thing with a browser, I don't want to be told I can only save downloaded files in one particular directory.

The builder of the snap can define what the snap needs to have access to. In such case, it should be built with full access to the host file system.
No miracles here, just more options.

 

[raxx7]

berrardo[/url]":15gstie3]

each library is only installed once?

The way I understand it, each library is installed *once per app*. If 15 apps use it, 15 app.snaps contain the library.

snap (much like flatpak) uses the concept of "frameworks", which will contain libraries and etc.
Each snap depends on one (or more) frameworks.
Each frame work needed is installed once per system.

Other libraries needed by the snap are included in the snap itself and thus duplicated, even if two snaps happen to use the same exact library.
Given that btrfs supports de-duplication, I suspect snap developers are more into relying on that to save space than to add de-duplication support into snap.

 

[raxx7]

h3nrch[/url]":3kz8oxkb]

stormcrash[/url]":3kz8oxkb]

DCRoss[/url]":3kz8oxkb]

stormcrash[/url]":3kz8oxkb]Holy Crap! A unified package manager being adopted by nearly every major Linux Distro! Linux as a desktop platform just got a lot more viable to develop/distribute for. The days of .deb vs .rpm could soon be at an end

And the days of .dsnap vs .rsnap will be coming instead.

Did you miss the part where it said the changes per distro are made in snapd and not in the packages themselves? So no, there will not be .dsnap and .rsnap, just .snap and a tailored daemon per platform that the package makers don't have to think about

So snapd is really a dependency manager and .snap is the common API? In the short term it might be attractive but it's not hard to see fragmentation occur as cloud specific distros dominate. Canonical should have included AWS, GCS, and Azure first.

Err... no.
Let me try and make a bit of sense of what snap/flatpak (and to a degree, docker) are.

Currently it's hard/impossible to pack an application in such a way it works across all Linux distributions, much less while using a proper packaging system (deb/atp, rpm/yum, etc).

The fault does not lie with the kernel, as Linus is actually very strict on keeping backward compatibility on the interface between the kernel and the applications.

The fault lies with the fact different distributions use different packaging systems, use different conventions as for where some files are, have different sets of libraries available, different sets of services, etc.

Enter containers, which have been available in Linux for a bit now.
A container is like chroot on steroids: it's an environment where you run programs, with as much or as little access to the base system as required.
Or you can think of it as a step down from a virtual machine, except a container requires much less resources.

Containers can be used for a ton of things.
You can put an application binary and it's required libraries in a directory, launch it inside a container and the application will thing it has the machine all for itself (can even give it it's own IP address).
Or you can actually use a container to run one Linux distribution inside another.
Possibilities are endless.

One of them is distribution of applications independent of Linux distribution.
The basic idea is simple: each application runs on it's own clean sheet box, with access to standard features of the Linux kernel and standard features provided by snapd.
Everything else is packaged with the application. Snap apps works across distributions because snap apps don't have even have direct access to the main system.

Snap apps also depend on snap frameworks.
Snap frameworks allow snap apps to share resources and to work together. But like snap apps, snap frameworks don't have direct access to the main system, so snap frameworks are also distribution independent.

Well, at least in theory, of course. If your snap app depends on Mir, it will only run on Ubuntu.

 

[Haravikk]

I'm excited by this; while I expect it will mainly be used more by GUI and user-facing apps, I hope we might see some adaptations in the server space too.

I use aptitude mainly, and while there's nothing wrong with it, I do like the idea of better isolation programs. Could also go a long way to making installations and updates more accessible to the less savvy users; there are some excellent Linux distros with very user-friendly UIs and such, but updating and managing apps can still be a pain, and many users don't even know what's really going on behind the scenes.

 

[bonaparte]

I see this as great for frequently updated user apps like the Web browser, steam, media player etc. Snaps put the update schedule back in the hands of the developer. They can roll out new versions rapidly without having to wait for the distributions to package the app.

It's also great for developers of new apps not yet included in a distribution. They can publish the app and users can install it in a hassle free manner on any distribution with snapd.

I think the concern about running multiple libraries leaving it hard to fix vulnerabilities is overblown, ultimately there is always a trade off between convenience and security. It's up to the user to decide if they trust a package distributor to keep on top of security issues.

Should you still want centrally managed libraries on a stable base system the traditional apt/yum/portage etc systems aren't going anywhere.

 

[Deleted member 192806]

raxx7[/url]":2mwy55yc]

h3nrch[/url]":2mwy55yc]

stormcrash[/url]":2mwy55yc]

DCRoss[/url]":2mwy55yc]

stormcrash[/url]":2mwy55yc]Holy Crap! A unified package manager being adopted by nearly every major Linux Distro! Linux as a desktop platform just got a lot more viable to develop/distribute for. The days of .deb vs .rpm could soon be at an end

And the days of .dsnap vs .rsnap will be coming instead.

Did you miss the part where it said the changes per distro are made in snapd and not in the packages themselves? So no, there will not be .dsnap and .rsnap, just .snap and a tailored daemon per platform that the package makers don't have to think about

So snapd is really a dependency manager and .snap is the common API? In the short term it might be attractive but it's not hard to see fragmentation occur as cloud specific distros dominate. Canonical should have included AWS, GCS, and Azure first.

Err... no.
Let me try and make a bit of sense of what snap/flatpak (and to a degree, docker) are.

Currently it's hard/impossible to pack an application in such a way it works across all Linux distributions, much less while using a proper packaging system (deb/atp, rpm/yum, etc).

The fault does not lie with the kernel, as Linus is actually very strict on keeping backward compatibility on the interface between the kernel and the applications.

The fault lies with the fact different distributions use different packaging systems, use different conventions as for where some files are, have different sets of libraries available, different sets of services, etc.

Enter containers, which have been available in Linux for a bit now.
A container is like chroot on steroids: it's an environment where you run programs, with as much or as little access to the base system as required.
Or you can think of it as a step down from a virtual machine, except a container requires much less resources.

Containers can be used for a ton of things.
You can put an application binary and it's required libraries in a directory, launch it inside a container and the application will thing it has the machine all for itself (can even give it it's own IP address).
Or you can actually use a container to run one Linux distribution inside another.
Possibilities are endless.

One of them is distribution of applications independent of Linux distribution.
The basic idea is simple: each application runs on it's own clean sheet box, with access to standard features of the Linux kernel and standard features provided by snapd.
Everything else is packaged with the application. Snap apps works across distributions because snap apps don't have even have direct access to the main system.

Snap apps also depend on snap frameworks.
Snap frameworks allow snap apps to share resources and to work together. But like snap apps, snap frameworks don't have direct access to the main system, so snap frameworks are also distribution independent.

Well, at least in theory, of course. If your snap app depends on Mir, it will only run on Ubuntu.

It's those properties that have led some to suggest something similar for Windows.

 

[AdamWill]

rupucis[/url]":2hnchxb6]If snap packages were meant for Ubuntu phones, why does my Ubuntu phone get updates in the form of system images and why does using apt-get on it break stock apps?

For the same reason updates for Android phones don't come from the app store. The whole *point* here is to draw a line in the sand between the system space on one hand and the app space on the other, as opposed to having no distinction between them (as is the case with traditional distro packaging, where everything's just a package).

 

[lewax00]

lewax00[/url]":1aqmwtve]
Windows doesn't have a great solution either, their solution is basically just have a copy of every library for every application that needs it (with a few exceptions, like the MSVC++ redistributables...but that's done using it's own convention that nothing else seems to follow so it's a special case). Linux's system allows sharing, but makes it more difficult for multiple versions of the same library.

At this risk of nitpicking, this isn't so much a limitation of Windows as much as standard practice for developers. You could check for DLLs in a global folder and choose whether or not to install your own based on version (or, if you're working with assemblies, check if there a matching assembly in the global assembly cache). It's just that it's far more common for developers to package required DLLs with an application.

Back on topic, I'm mixed on this. On one hand, I think this is a boon for teams that package their own programs (instead of cases where the distro does the packaging), as it reduces the number of packages they need to maintain.

On the other hand, I feel like this is going to create library bloat. For better or worse, one thing shared libraries do on a system is lock the distro to a specific library version (glibc versions are usually locked for each debian release, for example). If you allow developers to choose library versions arbitrarily, then inevitably one developer will use v1.0, one will use v1.1, one will use v1.2, even though they all probably could have compiled against v1.0 without issue.

We'll have to see how much adoption this gets. Personally, I'd rather see a better way to manually update packages than a new package format (yes, this doesn't solve the isolation or maintainer headache, but it would solve the 'waiting for distro update' problem). One thing I've loved in Arch and Slack is how easy it is for me to create an updated package on my own if the one in the distro is out of date, or doesn't have the options I want. Updating a deb manually and repackaging can be challenging.

I'm not saying it's the OS's fault, but that's the standard convention. The same is true of Linux, the system is more convention than requirement. But the different conventions have different advantages and disadvantages.

As for versions, generally speaking if the library maintainer does their versioning by generally accepted practices, replacing 1.1 with 1.2 shouldn't break anything, so the app written against 1.1 should still work with 1.2. Version 2.0 won't necessarily be compatible, but then you usually use a different file name. (Again, all convention, not a functional requirement, so it won't necessarily hold if the developers aren't following it.)

 

[Voo42]

kgb999[/url]":ckhdschw]
Someone has to make the Snap package. And someone has to keep the package binaries updated to the latest versions. So, as far as that goes, who produces and maintains the binaries? It seems like we end up in the exact same situation - with installable packages likely being maintained by arbitrary third-parties completely distinct from the development teams that are maintaining the code being developed.

The difference is that you only have to create one snap package and it will work for all distributions and versions thereof that support the package.

Anybody who doesn't see the enormous advantage of that clearly has never tried to package up some open source software for different distributions. Because that's a gigantic pain that takes lots of time and effort and testing. And then version n+1 of some distro is installed and you can go through the whole process again.

In practice you need other people to take your sourcecode and package it up for their distribution and you're not involved at all. Which to me always seems like a gigantic waste of valuable manhours.

Here's Linus point of view on it.

 

[Voo42]

lewax00[/url]":3hkwu2gq]
As for versions, generally speaking if the library maintainer does their versioning by generally accepted practices, replacing 1.1 with 1.2 shouldn't break anything, so the app written against 1.1 should still work with 1.2. Version 2.0 won't necessarily be compatible, but then you usually use a different file name. (Again, all convention, not a functional requirement, so it won't necessarily hold if the developers aren't following it.)

It's a nice dream, but I dare you to update glibc on Ubuntu 15.10 (2.21) to 2.23.

I mean I haven't tried and it might just work fine, but chances are that the whole system is just going to implode.
And if you can't upgrade the lowest common denominator (for most projects at least), that limits your options tremendously.

 

[somidscr21]

sigma8[/url]":180oyftt]How does it include all of its dependent libraries, remain containerized, and not interfere with other packages' libraries, yet each library is only installed once? Sounds like it's either a) impossible, or b) still a dependency quagmire, where we'll have some centrally located library folder (now, potentially, with many versions symlinked into various "containers").

I would assume snapd itself is the one looking at the libraries required. The snaps wouldn't need to see into each other, just allow snapd to look into them.

 

[rupucis]

AdamWill[/url]":1llgqyx6]
For the same reason updates for Android phones don't come from the app store. The whole *point* here is to draw a line in the sand between the system space on one hand and the app space on the other, as opposed to having no distinction between them (as is the case with traditional distro packaging, where everything's just a package).

And what does that serve?
The reason I bought the phone in the first place was that - while I knew I'd be getting worse performance and noapps compared to android - I wanted a phone OS that would let me get updates regardless of whether the manufacturer or the OS maker have packaged it for my phone.
I wanted a phone OS that handles package management in what I consider to be the right way. The way it works on desktop and server Ubuntu.
When I bought it, I thought I was getting Ubuntu with a touch interface, not Android with horrible performance and no apps.

 

[shadedmagus]

AdamWill[/url]":3azp93za]

rex86[/url]":3azp93za]The ability to package once and run everywhere, even just for non-graphical programs, sounds like a great idea but somehow I expect RH et al. in a year or two to release their own completely new packaging systems that are fundamentally incompatible with Ubuntu's snap. Just because they can.

It's the Linux problem all over again -- too many men with huge egos. :/

There've been two somewhat-similar systems all along. Looking at the history, they seem to be more or less contemporaneous. The first commit to Flatpak (when it was known as xdg-app) was in December 2014 - see history of https://github.com/flatpak/flatpak . December 2014 also seems to be when Ubuntu announced what was more or less Snappy:

http://www.markshuttleworth.com/archives/1434

this is basically an attempt to re-position Snappy as a 'universal' app package framework, while utterly ignoring Flatpak.

So this is yet another instance of Canonical's NIH Syndrome?

I don't know anything about either framework, but it sounds like this is what you're saying.

EDIT: Not sure why this is getting downvoted...Canonical has a history of rolling their own solution instead of adopting a more global alternative. Unity instead of GNOME/KDE/XFCE/etc, Mir instead of Wayland, upstart instead of launchd or openRC (although that's not a thing since they've followed Debian and adopted systemd) and now snapd instead of xdg-app/flatpak.

 

[CaptainPiccard]

Counter argument:

http://kmkeen.com/maintainers-matter/20 ... 6-472.html

 

[AdamWill]

shadedmagus[/url]":1vpdo0eb]
So this is yet another instance of Canonical's NIH Syndrome?

I don't know anything about either framework, but it sounds like this is what you're saying.

I wouldn't say that, really - as I said, the two are more or less contemporaneous and started in slightly different places, they've just both kinda converged on the same space. I don't know whether there have been any moves from either side to try and work together or at least come up with some kind of compatibility (e.g. agreeing on the contents of some standard base layers so developers can build snaps and flatpaks out of the same content, or indeed making it easy to build both snaps and flatpaks from the same bits), so I can't say that one side or the other is being terrible here.

I *do* think this PR was a pretty shitty move on Canonical's part: they can hardly claim ignorance of Flatpak, and it is also the case that neither of them is remotely baked yet, but Canonical seems to be trying to push Snappy over the top by pretending it's all done and ready for people to use, and distributions are adopting it (and utterly papering over the existence of Flatpak). Which is not at all a true representation. Flatpak's developers have been mainly communicating through blogs and technical channels so far precisely because there's a lot of work to do and a lot of buy-in to achieve.

(They also sent this PR out as if it came from some sort of independent organization, but Snappy is very much a Canonical owned project: all its devs are Canonical employees, and it falls under Canonical's CLA).

 

[yawaramin]

Sounds like the Nix package manager. If it also gets ported to Mac OS (macOS?), I'm all for it. Windows support would be icing on the cake.

 

[Voo42]

AdamWill[/url]":2fyzb18r]
I *do* think this PR was a pretty shitty move on Canonical's part: they can hardly claim ignorance of Flatpak, and it is also the case that neither of them is remotely baked yet,

I thought snapd was already shipping in Ubuntu 16.04? Shipping installed by default in a major distribution, seems like a fair point in time to start PR.

 

[MosquitoBait]

Voo42[/url]":17889bbr]

AdamWill[/url]":17889bbr]
I *do* think this PR was a pretty shitty move on Canonical's part: they can hardly claim ignorance of Flatpak, and it is also the case that neither of them is remotely baked yet,

I thought snapd was already shipping in Ubuntu 16.04? Shipping installed by default in a major distribution, seems like a fair point in time to start PR.

Ubuntu ships lots of half-baked crap. Them shipping it doesn't make it production-ready.

 

[blacke]

MosquitoBait[/url]":1kvh5y9q]

Voo42[/url]":1kvh5y9q]

AdamWill[/url]":1kvh5y9q]
I *do* think this PR was a pretty shitty move on Canonical's part: they can hardly claim ignorance of Flatpak, and it is also the case that neither of them is remotely baked yet,

I thought snapd was already shipping in Ubuntu 16.04? Shipping installed by default in a major distribution, seems like a fair point in time to start PR.

Ubuntu ships lots of half-baked crap. Them shipping it doesn't make it production-ready.

Of course not, but it certainly makes it PR-ready.

 

[AdamWill]

Voo42[/url]":9hsppgis]

AdamWill[/url]":9hsppgis]
I *do* think this PR was a pretty shitty move on Canonical's part: they can hardly claim ignorance of Flatpak, and it is also the case that neither of them is remotely baked yet,

I thought snapd was already shipping in Ubuntu 16.04? Shipping installed by default in a major distribution, seems like a fair point in time to start PR.

It would be a reasonable time to issue a PR about it being installed in Ubuntu 16.04. It doesn't really justify issuing a PR titled "Universal “snap” packages launch on multiple Linux distros" and with the lead "...enabling a single binary package to work perfectly and securely on any Linux desktop, server, cloud or device"

because it can't remotely do that yet. This has been mentioned before, but for anyone who missed it - the install instructions for Fedora, for instance, tell you to disable SELinux (thus making the entire system significantly *less* secure), and snap's confinement is entirely disabled in the Fedora build:

https://copr-be.cloud.fedoraproject.org ... ild.log.gz

+ ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --disable-confinement --enable-rootfs-is-core-snap

note the `--disable-confinement` there. This is rather hard to reconcile with "enabling a single binary package to work perfectly and securely on any Linux desktop".

 

[lewax00]

Voo42[/url]":2xz03ykq]

AdamWill[/url]":2xz03ykq]
I *do* think this PR was a pretty shitty move on Canonical's part: they can hardly claim ignorance of Flatpak, and it is also the case that neither of them is remotely baked yet,

I thought snapd was already shipping in Ubuntu 16.04? Shipping installed by default in a major distribution, seems like a fair point in time to start PR.

It would be a reasonable time to issue a PR about it being installed in Ubuntu 16.04. It doesn't really justify issuing a PR titled "Universal “snap” packages launch on multiple Linux distros" and with the lead "...enabling a single binary package to work perfectly and securely on any Linux desktop, server, cloud or device"

because it can't remotely do that yet.

Clearly you don't do PR. You have to announce the big, flashy, potential future now to get people's attention. Sure, it'll probably turn out to be over-promised and under-delivered, but that's not the PR guy's problem.