Ubuntu 16.04 Reaffirms Support For Snap Packages Along Side Debian Packages

[callegar]

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...

[Cerberus]

How does it do that though? Is it like a winsxs and a registry? And really does it matter how? There is no possible way it can be secure.

If anyone can create snaps, are they secure? That's the best part of the snap package - that it can be installed as some sort of container on top of your Ubuntu operating system and won't have any impact on the rest of the installed applications and libraries. In the same way, you can also bring a certain package to Ubuntu that is required by a newer software version.
"The security mechanisms in snap packages allow us to open up the platform for much faster iteration across all of our flavours as snap applications are isolated from the rest of the system," said Olli Ries, VP Engineering Ubuntu Client Platform, Canonical. "Users can install a snap without having to worry whether it will have an impact on their other apps or their system."
Lastly, this major change in Ubuntu Linux will finally solve any issue app developers had with previous versions of the operating system when they either tried to include their project in the main software repositories or just update an existing one but couldn't because of missing dependencies. Also, a snap package can be used on desktop, server, mobile, embedded, or IoT systems.

Taken from Softpedia.

[unixfan2001]

How does it do that though? Is it like a winsxs and a registry? And really does it matter how? There is no possible way it can be secure.

Simply put, the libraries are included inside the application bundle itself. The application then calls these internal libraries.

No possible way it can be secure? Mac OS X, ROX Desktop, RiscOS, AppImageKit et al, would like to disagree.

[jwtalbot]

or maybe we just need to have a rethink about how we handle multiple versions of a library. Maybe we need a system whereby every version of a given library is on the system and the program just calls the one it needs. So if both your desktop and Firefox are built against libXYZ.so but Firefox needs a new version it just calls the library version it needs. In short, a bit like how the versioning in Direct3D works. That is in contrast to Snappy which by what I am reading ends up with a system that looks a bit like your windows Program Files folder, where every program has to have it's own version of most libraries

You would have to get every one to standardise on a naming convention for library versions (Never going to happen) and how do you security check the almost infinit library versions (No one has the time) Snappy sandboxes them.. both issues fixed!

[bug77]

How does it do that though? Is it like a winsxs and a registry? And really does it matter how? There is no possible way it can be secure.

Apparently Snappy is just gravy on top of Docker.

[Julius]

Good critical discussion with developer feedback here:

http://www.omgubuntu.co.uk/2016/04/ubuntu-16-04-lts-snap-packages

[nox86]

I like how I can share one library with the rest of the system via the Debian packaging. With Snap, I'll end up with multiple copies of that library that take up more space. Meh.

ROFL, who cares about additional 1-2Gb of disk, even with RPi?

But how about bugfixing: Shouldn't we update all packages containing bugged lib?

[Linuxxx]

This is going to be a real game-changer as far as Linux distros are concerned!
With Ubuntu LTS + Snappy, there are practically no other distros that come even close when considering: stability AND support AND up-to-dateness.
Fedora?
Even if XDG-App should be production-ready, the support time-frame of only ~1 year for a given release is way too short...
(And they can't even be bothered to update their Mesa stack; still at 11.1.0 since 3 months for F23! https://bodhi.fedoraproject.org/upda...016-1977f72adb)
Arch?
Way too unstable and untested updates plus they can't even ship a non-realtime Linux kernel as an option, let alone by default! (In Ubuntu and Fedora, a generic Linux kernel is the default as it should be, but if you really insist on a real-time kernel and thus higher latency frame-times during gaming, Ubuntu gives you the option to install one anyway.)

Ubuntu - the hero we don't deserve, but which we desperately need!

[Scias]

Arch?
Way too unstable and untested updates plus they can't even ship a non-realtime Linux kernel as an option, let alone by default! (In Ubuntu and Fedora, a generic Linux kernel is the default as it should be, but if you really insist on a real-time kernel and thus higher latency frame-times during gaming, Ubuntu gives you the option to install one anyway.)

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.

[Linuxxx]

I've been running Archlinux for several years and had less issues with it than when I used Ubuntu or Debian. I don't know where you've seen that they ship a rt-kernel as default but that's just wrong. Almost everything is upstream stock on Arch including the kernel.
Also 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 package update on Arch yet.

So please don't speak of things you obviously don't know. Thanks.

How about you run "uname -a" and post the output here?
I can guarantee that it will contain PREEMPT, which means the kernel freezes itself for userspace, typical for a (soft)real-time kernel!
But forcing the Linux kernel to stop its own tasks randomly is never a good idea, as other processes and their latencies will have to suffer for this; ever heard that there is no free lunch?
Also, you might want to consider why SteamOS doesn't activate PREEMPT for its gaming OS...

So, please inform yourself better next time instead of drinking the Arch Kool-Aid (TM) and looking down on others. Thanks!