Ubuntu 16.04 Reaffirms Support For Snap Packages Along Side Debian Packages

[SebastianB]

One of the major advantages of bundling libraries with your applications from developer pov is that you can easier find and fix bugs because you know its not down to some obscure difference in library versions used.

This is beneficial especially for those projects that rely on being up to date while being considered notoriously hard to compile. Examples would be chromium and calibre. One for security reasons the other for features added in newer versions(like improved ereader support, better quality conversions etc). I don't think it's meant for stuff like vi, less, emacs or make. I mean you could use it for stuff like that, but those work fine with shared libraries.

[zoomblab]

IMO this, not mir nor wayland, is the most important feature that can lead to greater adoption of linux in the desktop space.

[nanonyme]

Except for the fact that libraries are already versioned (apart from some corner cases like Python, where packages do not carry version information, so that different versions of the same package cannot be installed side to side in the same environment). Which means that already you can have as many versions of the same library installed as you like. For instance, in ubuntu wily, you already have two libjpeg packages, one bringing in the jpeg library at version 6.2 and the other one bringing in the same library at version 8. All that needs version 8 uses the single version 8 library, all that needs version 6.2 uses the single version 6.2 library. To take a Python analogy, snap looks a bit like having a "virtualenv" for every piece of software you may have, a mini-distro for every application. Until some deduplication is in place, this is probably going to be a suboptimal experience...

I'd expect this leads into snap packages actually usually having older libs than your system ones as application makers don't want to bother porting software to new API/ABI's when not mandatory

[Linuxxx]

I've been running Archlinux for several years and had less issues with it than when I used Ubuntu or Debian.
The fact that it's a rolling-release distro doesn't mean packages come completely untested and break everything when updated. They spend some time in the "testing" repository before they hit the stable ones. I've never had a breakage because of a stable package update on Arch yet.
Also can't say the Archlinux stock kernel is fully RT. Sure it has CONFIG_PREEMPT=y but it's not at the level of a linux-rt kernel. I haven't experienced a difference or a particular issue from it, or lower gaming performance compared to Fedora/Debian.
And honestly I believe the Arch's default kernel is much more vanilla/generic than the ones from other distros.

I agree that Archlinux and the rolling-release model in general isn't comparable to or better than xdg-app/snappy but please don't speak of things you obviously don't know. Thanks.

My previous reply was eaten up...
Anyway, stopping the Linux kernel doing its work for a userspace request, which PREEMPT does, is bound to have a negative impact; ever heard that there is no free lunch?
Also, checkout the benchmarks which Phoronix have done where different Arch-based distros were compared to generic kernel using ones (like Ubuntu or Fedora). You should notice in the frame-latency graphs that PREEMPT always produces higher max. values, which manifest themselves as stutter in games.
Finally, you should consider why SteamOS is using a generic Linux kernel...

[Scias]

My previous reply was eaten up...

Happens to me too, or sometimes the posts are "unapproved" for god-knows-what reason and appear after some random time.

Anyway, stopping the Linux kernel doing its work for a userspace request, which PREEMPT does, is bound to have a negative impact; ever heard that there is no free lunch?
Also, checkout the benchmarks which Phoronix have done where different Arch-based distros were compared to generic kernel using ones (like Ubuntu or Fedora). You should notice in the frame-latency graphs that PREEMPT always produces higher max. values, which manifest themselves as stutter in games.
Finally, you should consider why SteamOS is using a generic Linux kernel...

I know there's tradeoffs in every situation anyways, but playing games a lot (like Dota 2) on a modest machine I haven't noticed lower framerates or more stutters (maybe because I don't normally pay attention to them anyways). To be honest up until today I didn't even know Archlinux had PREEMPT in its stock kernel and so far lived fine with it (althrough I use linux-ck now, which also has PREEMPT). Benchmarks are something but would the average Joe notice the difference in a real scenario anyways ?

[ThiagoCMC]

I strong believe that OwnCloud developers will LOVE Snappy, since they don't like neither RPM, nor DEB packages.

Also, OwnCloud will not be maintained on Debian anymore... So, Snappy comes to the rescue! What do you guys think?

Snappy allows the upstream developers, to package things on THEIR way! ;-)

[Linuxxx]

I know there's tradeoffs in every situation anyways, but playing games a lot (like Dota 2) on a modest machine I haven't noticed lower framerates or more stutters (maybe because I don't normally pay attention to them anyways). To be honest up until today I didn't even know Archlinux had PREEMPT in its stock kernel and so far lived fine with it (althrough I use linux-ck now, which also has PREEMPT). Benchmarks are something but would the average Joe notice the difference in a real scenario anyways ?

I think they will notice the difference very clearly once Virtual Reality becomes more common...
Also, having less stutter always helps immensely with immersion, IMHO.

But hopefully in the not too distant future Vulkan + Wayland (+ generic Linux kernel :-P) will solve most if not all problems related to stutter [with powerful enough hardware, of course]...

[Lestibournes]

According to what I've seen in a Mark Shuttleworth video explaining Snaps, snaps can be either packaged as apps or as frameworks, and if they are packaged as frameworks then other snaps can specify them as dependencies.

I do wonder why they haven't gone with something like Nix, or created a system with some similar features.

[tuuker]

Finally a packaging system that is easy and works almost always like on windows that has setup like software. Next would be that linux guys should stop scaring casual people with command line and teach more visual way of doing things.

Lets hope this brings end to new software that can break internal system and it is always possible to wipe all user level installed software easily with profile.

[Julius]

I posted this in the OMG Ubuntu comments, but I guess it is worth discussing here too:

Generally sand-boxes as an additional security feature are not bad, but systems like that have been available in Ubuntu for a while (AppArmor etc.). The difference is that Snap is more like Docker, i.e. it can come with its own set of libraries and run isolated from the system etc. It is a bit like a "lite" Docker image (Docker basically has its own stripped down Linux distribution included).

The reason this is seen as a good feature is that developers can include all the latest (unstable) libraries without worrying about system compatibility... and on the other spectrum can also just use old vulnerable libraries just the same and never bother to update them.
Given the workload of maintaining a proper trusted .deb repository and developing good applications that will not easily break due to updated dependencies, switching to a Snap like system is thus in multiple ways attractive for OS developers, application developers and also users who can be pretty sure that their old applications will continue to run.

So this is nice in many ways, but it comes at a security cost especially as it basically makes it easier to develop sloppy code and never bother to update an application (and run untested, vulnerable bleeding edge code), and still have many people using your application without complaining.
Since no-one is really complaining about such sloppy applications, distribution maintainers also have little incentive to regularly enforce updates of applications, and users also have little reason to update their systems as everything seems to work fine.

Canonical clearly has realized that, so they try to push mandatory system updates (like Windows10) and put an according to them very strong confinement/sand-box around all applications. This is in itself good, but clearly a band-aid fix to a problem indirectly caused by the snap system itself. And they also advertise this band-aid as improved security, which it really only is if you are intentionally ignoring the wider implications...
But anyways... this way they can't enforce application updates of new versions that don't exists as the developer never did an update in the first place, and also can't easily enforce a system wide library update that fixes security holes in well programmed applications automatically and/or forces developers of badly programmed applications to release an update as otherwise the software stops working and users complain.
This "annoying" behavior is a feature and not a bug of the .deb system, and one of the main causes why the GNU/Linux ecosystem is considered much more secure than Android or Windows etc.

Thus all they can do is try to keep their sand-box as tight as possible and consider everything that is inside as potentially malicious code (and automatically the user of that application as well). And suddenly we have arrived in the world of Android/iOS (and soon Windows, which is on a similar path from the opposite direction), with a never ending number of exploits and large teams trying to scramble to fix security holes in their sandboxes and find new ways to bolt down the confinements and in the process of doing so often remove a lot of user freedom as collateral damage.

So what we see here is a path to the same kind of toxic app environment that many user try to escape by switching to GNU/Linux, and it is plastered with good intentions and naive users are cheering the developers on.

A very sad sight indeed