Ubuntu 16.04 LTS Will Bring Snap Packages For Up-To-Date, More Secure Apps (neowin.net)

An anonymous reader points us to a report on Neowin: Canonical, Ubuntu's parent company, has announced that Ubuntu 16.04 LTS (Long Term Support) will come with support for the snap packaging format and tools. As a result, end users will get more up-to-date apps, something that proved tricky in the past due âoethe complexity of packaging and providing updates,â which prevented updates to some apps being delivered. Snaps will make the Ubuntu platform more unified, developers will more easily be able to create software for PC, Server, Mobile, or IoT devices. The other major benefit of snaps is that that they're more secure than software installed through deb packages. Snaps are isolated from the rest of the system, meaning that malware packaged with a snap won't be able to affect your Ubuntu installation.

Comments

Like Static Linking!

[TechyImmigrant]

This is like static linking. Just link in all the code from all the libraries your program uses. Back to the simple life.

uhhh...

[Anonymous Coward]

... the amount of bullshit in those statements is causing ringing in my ears.

Another outbreak

[edittard]

Another outbreak of â disease.

Re:Another outbreak

[rtkluttz]

Yes... it looks like just another implementation (outbreak) of an app store. An app store where "security" means secured against us (the owners of the devices and computers) more than against any bad actors. I hope to be proven wrong, but that is usually where these sandboxed environments end up.

Re:Another outbreak

[Anonymous Coward]

Yeah, I wish Ubuntu would stop trying to put us in a walled garden jail. If they'd release the source code of their packages, that'd be one thing... but this closed source proprietary shit they're trying to push on us has got to go !

Re:Another outbreak

[Hylandr]

Ubuntu is the slowest Linux distribution by far that I have worked with anyways. This is just a more clandestine way to kill it off.

Re:Another outbreak

[Anonymous Coward]

I think you may fundamentally misunderstand the purpose of the Snap packaging. This is more akin to Windows installers, that contain all the required libraries and dependencies already packaged within the Snap package. This is also a response to complaints like Linus's about how packaging programs on Linux is a pain because so much of it depends on shared libraries.

I can see the benefit of both. Steam manages to do its own thing in a similar fashion (though Steam provides it through the Steam Runtime, not necessarily separate for each game).

Statically linking things can take up more space, larger packages, etc, but then you don't have to worry about having to port your packages between individual Linux distros (despite that different distros are largely a permutation of the same thing).

Using shared libraries takes up less space (since you don't have to package the shared libraries with the executable / binary / source) however it makes it a huge pain if you want to use a newer version of a program on an older version of an OS (an LTS release, for instance).

Since disk space and bandwidth are not significant concerns for a lot of people nowadays, I think that snap packaging is a good way to go in 2016 and I hope other distros pick it up as well.

Why?

[binarylarry]

When you think about what sucks in Ubuntu right now, are apt and deb really the worst offenders that need work?

Re:Why?

[LichtSpektren]

Just curious, what do you think "sucks" in Ubuntu right now? Hopefully this won't be a complaint about the Amazon shopping lens (off by default in 16.04) or Unity (because at least seven other DEs are supported by Canonical).

Re:Why?

[Anonymous Coward]

You know what really sucks about Linux right now? You do, my friend. It's you.

Re:Why?

[TechyImmigrant]

How does Amazon shopping lens interfere with my bash shell session?

Re:Why?

[NotInHere]

I see one advantage in snap apps. The current situation is depicted in this nice xkcd https://xkcd.com/1200/ perhaps in the future we will have more isolated applications.

Re:Why?

[SumDog]

Exactly. Package management with dependencies is what Linux does RIGHT! Look at Android and it's horrible "you have to update the whole damn firmware because nothing is managed by packages!"

Apks and MacOS app containers add so much redundancy. If you have a library with a security problem, you can now have 50 of that library with a security problem scattered everywhere. In the Linux world with proper package management, if develops use the system libraries, then their apps get those security updates.

Re:Why?

[RghtHndSd]

Here is one that I ran into a week ago. Had some odd behavior, and I want to reinstall ubuntu without losing the files. Here are the instructions: https://help.ubuntu.com/commun...

... choose manual partitioning ("Something-else" option), then select Ubuntu system partition, set its mount point as "/". Be sure to keep the same format type, the same size, and untick the "Format" checkbox or all data on "/" will be deleted!. Also set other partitions (/boot, /home... see DiskSpace) if needed.

This is an extremely dangerous way to reinstall.

Re:Why?

[fisted]

The same way it interferes with your redundant RAID array.

Re:Why?

[grumbel]

The lack of a packaging format for third party apps has been one of the biggest and most persistent problems in the Linux landscape for ages. I have no idea of the quality of the work Ubuntu is doing here and it does seem to duplicate the work going on with xdg-app, but I really wouldn't mind getting rid of tarballs and shelf extracting shell scripts. The monolithic dependency trees that package managers require at the moment just don't scale and never provided a good way for third party apps to plug into them (just adding random third party repos is inherently fragile and insecure).

Re:Why?

[Anonymous Coward]

Just curious, what do you think "sucks" in Ubuntu right now?

Security updates that break stuff.

Re:Why?

[Junta]

Except this is more about isolating their on-filesystem footprint, but they still at runtime pretty much have run of things. So a package can't 'update' the system-wide openssl with a malicious version as a side-effect, but it still could happily access files in your home directory to be able to log on to whatever (also could lay down a library in user directory and manipulate LD_LIBRARY_PATH for children so it could try to opportunistically spawn a browser with a different library path to be nefarious)

Conversely, you *cannot* apply something like an openssl update that would apply across the board using 'snap', and any effort to do so with deb would be ignored by 'snap' packages.

Re:Why?

[jofas]

Why? You're choosing to go under the friggin hood, of course you'll incur a higher risk.

Re:Why?

[Anonymous Coward]

random hangs von ubuntu14.04 in virtualbox5, if given more than 1 cpu.
ONLY Ubuntu hangs - Debian has no problems.

Re:Why?

[Anonymous Coward]

No. But I don't think this is about "fixing" apt and deb. Rather, I think it about control.

Re:Why?

[jofas]

This is a fallacy. The reverse is also true: the admin account won't be able to access your personal accounts online.... by itself. If you choose to have local applications retain your credentials, that's your problem, not root's.

Re:Why?

[Anonymous Coward]

> Just adding random third party repos is inherently fragile and insecure

why? What would be better?

Re:Why?

[binarylarry]

The answer to the comic's problem isn't a new package manager, it's two factor authentication.

Re:Why?

[RabidReindeer]

Whatever you're smoking is something that's stronger than anything legal in Colorado.

Third party app packaging support for Linux is something that's been around for ages. RPM for Red Hat and friends, dpkg for Debian/Ubuntu, and other lesser-known facilities for other systems. In actuality, probably 80+ percent of the stock repositories of the popular Linux distros are "third party" apps which have been built as distro-specific system packages - they're just part of the official repos, that's all. Other than that, packages I design and build myself of my own apps install and are managed in exactly the same way.

If your complaint is with dependencies, the main repository systems handle that as well. How well a given app will deal with dependencies depends on how well the package maintainer defined its needs, but the installers can do a very good job of making things "just work".

This "monolithic dependency tree" thing you're talking about doesn't even make sense to me. A YUM repo has had its packages scanned by a tool that constructs a dependency database in order to make dependency resolution faster, but by that definition, any read-mostly database is a "monolithic depency tree" or something similar. And you can't just jam in your own package to someone else's repo. The repo servers are designed to permit only authorized personnel to add packages and update the dependency database and to declare via appropriate signatures that assure that the repo isn't being circumvented.

If you use a random third-party repo, you are at risk, yes, but every repo is a risk. It's just that some repos have public trust and others depend on faith. If I was to set up and host repo, it would have the same security capabilities as the master Debian repos, just not the widespread faith.

Now if you want to talk about the problems that come from mixing dependencies from multiple repos where the dependencies were built with different capabilities, that's another issue entirely. There is, unfortunately, no real way to tell if a given repo's version of mencoder comes standard with the codes that my package might require. And it would be an interesting challenge to be able to resolve a problem like that, considering that every app (third party or not) could have a different collection of features and capabilities to be added, excluded or interfere with each other.

Re:Why?

[Burz]

Who gives a shit about an extra 3-5 MB of libraries per app when traditional repos are compiling apps against library revisions that the authors never tested with? This has added a lot of unpredictability to running Linux systems (especially desktops).

OS X is a model of successful packaging and distribution and its about time some Linux distros were taking inspiration from it.

OTOH, even not considering library revisions, Linux packaging never was "proper" for applications beyond the server space or lab. It is a recipe for driving real app developers away from your platform, in part because you can't really define where your platform ends and where the apps begin. Though not necessarily "Linux" itself, the typical Linux distro is its own little hell when it comes to independently distributing applications to users.

Re:Why?

[Kjella]

When you think about what sucks in Ubuntu right now, are apt and deb really the worst offenders that need work?

By far no. But sometimes all those dependencies drag you into cascading updates that you don't want. Like I once wanted a new feature in KDevelop, but really I didn't want to touch the rest of my KDE apps because they were working fine. But KDevelop insisted on updating the KDE libraries, which lead to apt-get insisting on new versions of almost everything. If a "snap" could let me install that one application in isolation that's certainly a feature I could like. And maybe the other way around too, if I really don't like the way an application f*cked up their UI I can easily run an old version without conflicts and complaints because I had to pin a package and thus all its dependencies too. I wouldn't want every package to be like that, but when it's the right tool for what you want it seems useful.

Re:Why?

[Burz]

The monolithic dependency trees that package managers require at the moment just don't scale and never provided a good way for third party apps to plug into them (just adding random third party repos is inherently fragile and insecure).

Exactly. And it resembles a whole host of other maladies brought on by what amounts to a sick subculture. Seriously, this is a class of system developers who cannot whip up one shred of empathy for application developers.

The best thing you can do for app developers is to nail down all your core APIs (a rich set of them) and define everything else as "option" or "3rd party". That way the app dev can at least start out writing apps that check for the OS version. Yes, for most apps the dependency check should stop at the OS version!!! Its so basic to the experience of personal computing, yet insistently rejected by 'repo culture'. No, we must have interchangeable-everything to the point where interesting new hardware features almost never get a chance to be expressed in the GUI (which is another aspect that discourages app developers).

Re: Why?

[JonathanHirschbaum]

redundant RAID sounds redundant

Re:Why?

[Anonymous Coward]

Assume package P1 depends on library L1.x.y.z for values of x=a,y=b,z >= a. P1 has been tested against all known versions of L.x.y.z up to the last one L.x.y.z for z=b. Now a version L1.x.y.z for z=c comes out. It fixes a bug that P1 assumes, and also a security flaw. Package P2 also depends on L1, but L1.x.y.z for z=c is not an issue.

We can't patch and break P1, we can't not patch and leave P2 vulnerable. Since P1 and P2 actually only search for L1.x.y then leaving both versions of L1 present won't work.

This is why either single function VMs are required (one runs P1, another runs P2) such that P1 can use the old version of L1, or you use a form of lighter weight encapsulation such as containerisation to contain (pun intended) the risk of an old L1 to run P1. Depending on how the containerisation works you can link all containers' L1 to one L1 bar that for P1, although then you need to make sure that the host is sufficiently secure, so there are tradeoffs.

Anyway, it's something that has exercised me and I've written about for over a decade...

Re: Why?

[TechyImmigrant]

My redundant RAID array feels like it's been groomed by Amazon Shopping lens.

Re:Why?

[thegarbz]

Apks and MacOS app containers add so much redundancy.

With great redundancy comes great portability. I appreciate that Linux is a large collection of small packages and that package management in Linux is a true wonder of software engineering, however it is far from perfect. Very far from perfect. If you happily stay within the exact version and release of a package that someone provided you then everything is usually quite peachy even between upgrades of major distro versions.

However as soon as you put that comfort blanket aside you can quite quickly find yourself in package management hell breaking parts of the system as you go, or worse still I've seen plenty of cases of a completely hosed package manager which is stuck in an endless cycle of being unable to repair itself as it is trying to meet dependencies by uninstalling software which it refuses to do as that breaks dependencies. I saw this one on a change from MySQL to PostgreSQL, the end result was uninstalling the database and all packages depending on it and then reinstalling them all from the ground up.

Package management isn't broken, it does the best it is able to. But there definitely is a use case along side it for a compartmentalised format that brings all required packages with it, especially if you want to remain cutting edge on software versions and not wait for the masters of your distro to trickle the treats down to you.

Re:Why?

[hitmark]

Yes and no.

The basic problem with deb, and rpm, and similar package manager, are that they get hung up on the package name and version.

Meaning that you can only have one version of a particular name installed at any one time.

Want to install another version? Either you remove the old version or you change the name to avoid a conflict. But changing the name plays havoc with the dependencies tracking.

If deb and/or rpm was changed so that the manager could handle tracking multiple versions of the same package name, the need for the likes of snappy, xdg-app, or a myriad of similar systems would not be needed.

You can see this if you check out NixOS/Guix or Gobolinux that have implemented slightly different solutions to the same problem.

Re:Why?

[chmod a x mojo]

Honestly, and I don't know if this is still the case but, how about when "upgrading" to the newest release the recommended way is to reinstall the damn system since their update methods are / were nowhere near reliable enough.

I'll take Debian thanks, upgrading from release to release is easily do able, with well documented errata and workarounds posted.

Then there is the fact that they feel the need to take Debian UNSTABLE, screw around with it a bit and probably introduce some extra bugs, and then call it STABLE software at 1/4 the time Debian or RedHat - actual stable systems releasers - usually takes.

Re:Why?

[Anonymous Coward]

It's not about the 3-5 MB (though in many cases we are talking more like 10-30 MB per app, which quickly ends up several GB overall), but as said in the previous post about the 100s of security holes that will be updated months late if ever.
I.e. it brings the Android model of security (which is: just close your eyes hard enough to not see the holes) to Linux.

Re:Why?

[Anonymous Coward]

Package management with dependencies is what Linux does RIGHT!

I'd pretty much agree but my use case for snap would be where you are basically running a stable LTS version but there's just a particular package, with a lot of dependencies, that you really need a newer version of. In that case it's good to have the choice to do this without upgrading (in the worst case) the entire system.

Re:Why?

[Anonymous Coward]

Packaging format is not an impediment. Nothing prevents you from installing your app and all its dependencies into a subdirectory like /opt/my-project and distributing a tarball. Using the ELF ${ORIGIN} linker macro, you can even ship subtrees that can be transparently moved around as a bundle anywhere on the filesystem, just like OS X applications. So, for example, you could create my-project.zip or my-project.tgz that unpacks to my-project, and reliably execute the binaries straight out of my-project/bin regardless of where you unpacked my-project/, and without static compilation.

glibc has excellent ABI compatibility. It makes extensive use of ELF symbol versioning, which puts it lightyears ahead of Visual Studio's CRT and is much better than Apple's awkward MACOSX_DEPLOYMENT framework. So you don't need to statically compile libc or ship your own copy, as people often did 10+ years ago.

The persistent problem is that there's no single Linux platform. Not only are there myriad distributions, but they're constantly evolving, especially when it comes to system configuration and desktop integration. The real problems, such as they are, are much higher up the stack than packaging. systemd is trying to address that problem by inserting itself at the center of the universe, but irony of ironies, containers mean everybody is running dozens of different instances of systemd.

These container solutions don't solve anything real. They're shiny new tools for sysadmins to play with, and big fat excuses for developers to create even worse and packages.

Re:Why?

[armanox]

Well, I do believe that is the idea of a "stable" release. The trend of rolling release that has become so popular these days is what you should be against. If I release software for RHEL 5, I can be pretty certain that the libraries will not change for the life of RHEL 5. However, Fedora changes the kernel version, and then we get Arch and Gentoo that are constantly updated, plus based on the Fedora Project's Google+ page more and more people are just running Rawhide claiming that traditional releases are too slow (and then they cry when a third party repo, like RPMFusion, breaks).

Re:Why?

[Rutulian]

Why? That has been the standard way to do what you are trying to do on linux since forever. The way installers, like the Ubuntu installers, work under the hood is 1) they format the disk, 2) they set up a staging area, and 3) they install everything the system needs using the package manager. Afterward they will do some initial config to get the system to boot. The package manager will only install files that belong to its packages. So it won't 1) delete or empty directories that have already been created, or 2) overwrite or delete files that don't belong to it (ie: user-created files). Config files that have been modified from their defaults will be overwritten, but in many cases there is a *.d/ directory that allows you to put in custom config that won't get overwritten when you update or reinstall. That's why things like network interfaces are preserved when you update, because the interface configs are written into a .d/ directory, allowing the package-owned config file to be upgraded without wiping away the interfaces.

So to do a safe reinstall, the instructions are accurate. Tell the installer not to format the disk, use the same partitions that were already in place, and that's it. It is actually a very well designed system. If I anticipated needing to do this frequently, the only thing I might do is keep /home on a separate partition (and maybe /usr/local depending on how much I use it) so that I would be able to format the root partition safely. But like I say, not necessary to safely reinstall without losing your files.

Re:Why?

[F.Ultra]

Well each to their own I suppose, myself I have upgraded numerous servers and desktops all the way from 8.04 to 14.04LTS (and 15.10 for the desktops) without any problems what so ever. Not claiming that you didn't experience problems, just that it's not universal. I bet that you can find installs where Debian could not be upgraded without problems or any other distribution for that matter.

Re:Why?

[jmcvetta]

Actually that cartoon is not the current situation on Ubuntu. By default root login is disabled and the user account has sudo privileges. So in a sense the user account is the admin account.

Unless you want to authenticate (password, fingerprint, whatever) for every single action you take, at some point the computer needs to be in an "unlocked" mode. Best practice is always to lock it when one steps away from the keyboard, even for a moment.

If you're really paranoid, you could set up a script to monitor the webcam, and lock the computer when no one is sitting in front of it. This might be a good place to start: http://tech.shantanugoel.com/2...

Re:Why?

[F.Ultra]

I agree wholeheartedly. As a developer, Linux distributions are a god send, you simply build debs and rpms for your application and send out to customers. With something like Windows (which mimics the approach that we see here kind of) you now have to keep track of each and every library that you use, and make sure that you fetch, compile and distribute to all your clients when there is a security hole in either one of them.

Re:Why?

[igloo-x]

LTS to LTS distribution upgrades (e.g,. from 12.04 to 14.04) aren't usually possible on launch day. At least with 12.04 to 14.04, you had to wait until 14.04.1, which came a couple of months after.

Though to be honest, if your operation hinges on in-place distribution upgrades on production systems, you've got bigger problems.

Re:Why?

[igloo-x]

It's insecure because .deb files can contain installation shell scripts which are executed as root each time an updated version of said .deb file is pulled down.

So by default, anyone who has write access to those repos has root on your box.

A better way would be some degree of sandboxing so a malicious package can't fuck with the entire system.

Re: Why?

[Anonymous Coward]

Anyway, it's something that has exercised me and I've written about for over a decade...

What, exactly, does that phrase mean?

Re:Why?

[king neckbeard]

You're leaving out the work of the distribution. In a stable distribution, the distro only upgrades for bugfixes and security updates. If the assumed behavior is a bug, then P1 has a bug for depending on a flaw. If it's merely a deprecated feature, then exclude the changes that make it stop working. At some point in time, there was hopefully some mail between the distro and the developers of P1 and P2 so the issue gets resolved upstream. Distros are generally for users, not developers.

Re:Why?

[amiga3D]

If you're afraid then stay away from the command line. It's dangerous and scary.

Re:Why?

[jrumney]

Servers generally don't have major issues with upgrades, but desktops - definitely around the timeframe where they switched from XFree86 to Xorg there was some breakage where for a few versions every new release would break booting to the desktop for one reason or another, until Xorg reached the point a couple of years later where it worked in pretty much all situations without a config file.

Re:Why?

[jrumney]

Android has incremental updates now. My last system update was about a 6MB download.

Re:Why?

[Rutulian]

Not really. Deb and rpm can handle multiple versions just fine, as long as the underlying software supports multiple versions. Remember, a package is just a collection of files with some instructions where to put them. So if you try to install two files with the same name in one place, you are going to have problems. In other words, it's not the versioning, it's the inherent limitation of the filesystem itself. If a library renames itself between versions, though, it won't have problems. Very few libraries go to the trouble to do that, though.

Re: Why?

[jofas]

All good points, which Snap in no way addresses.

Re: Why?

[jofas]

1) as I mentioned to someone else here, Snap does not solve this. Root installs, so be responsible for root! 2) there is a trade off in liability with the convenience of package management, which is that it's up to the sysadmin to approve software sources before installing them. No one gets a free lunch.

Re:Why?

[F.Ultra]

Of course but that is not Ubuntu specific which was my point, XFree86 to Xorg transition happened on all distributions. Myself I was burned several times with Gentoo when GCC changed their ABI in the 3.x series (or if it was in the 2.x series, don't really remember).

Re:Why?

[Anonymous Coward]

Or do something Gentoo has fixed years ago and use slots. Multiple versions of the same package. There is absolutely nothing, except poor distro design decision, that prevents that. And poor distro design decisions are then fixed by even poorer pseudo-solutions like snappy....

Captcha: coffins. because that's what these containers are. coffins.

Re:Why?

[Anonymous Coward]

Not really. The only difference is this:

* With a Linux distro, you package your application and TELL THE PACKAGE which other deps to pull in at the moment of installation

* With a, say, Windows installer (and this is not specific to Windows per se), you package your application ALONG WITH the deps you'd otherwise tell it to pull in.

Re:Why?

[perryizgr8]

Also, it seems ubuntu needs to restart after every batch of updates nowadays. I thought this was only a problem with windows.

Re:Why?

[goarilla]

Though to be honest, if your operation hinges on in-place distribution upgrades on production systems, you've got bigger problems.

As someone who was originally hhired for IT janitor work. I find myself in the uncomfortable situation of suddenly being responsible for the ancient linux infrastructure. I would like to know what you think the proper procedure for upgrading a production server would be. Personally I would do an in place upgrade after I've tested it on a cloned system, restored from a recent backup on a local VM. I assume most of you have Virtual Infrastructure and configuration management (puppet, chef) in place. And spin up an upgraded VM and rebuild the server in its entirety ? Any insights will be greatly appreciated.

Re:Why?

[F.Ultra]

Which is exactly what I said but you missed the big elephant in the room: When there is the next big security hole in say OpenSSL then you have to rebuild your Windows installer, distribute it and hope that all your customers install the new version, quite easy if we are only talking about one or two dependencies but some projects can draw in lots of dependencies and all of a sudden you have to play maintainer for all these dependencies.

Re: Why?

[thegarbz]

Indeed. I was just pointing out that Linux package manager is not all rainbows and roses.

Re:Why?

[Anonymous Coward]

Err, there is SONAME that do that by default.

You get one versioned lib name, and then you can set up a generic link to whatever of the versions you want.

But traditional packaging ignores soname, because you can't have foo-1.0.rpm and foo-1.1.rpm installed at the same time.

The only way you can get around that is by doing something silly like foo-0-1.0.rpm and foo-1-1.1.rpm, effectively making them two different packages.

But that in turn plays havoc with dependencies, as now you have to make sure the package that needs foo 1.1 depends on foo-1 1.1, and not foo 1.1.

Go check out Gobolinux, there this is handled right. you can have foo 1.0 and foo 1.1 installed side by side without having to play mind games with the package names, and the system JUST WORKS. No namespaces, no pr package containers, just using the tools that have been with *nix since the early days.

And unlike things like xdg-apps or snappy, you can do a reverse dependency check on any of the versions to see exactly what depends on them, and take action accordingly.

Re:Why?

[jaxn]

I literally watched someone google the word "redundant" for about 15 minutes in a meeting once. He was skipping from dictionary site to dictionary site reading the definitions of redundant. I wanted to stop the meeting and address it, but I feared my humor might be lost on the bunch.

Re:Why?

[Anonymous Coward]

[With my snappy upstream hat on]
This is not true. Snaps don't have access to $HOME of the running user.

Re: Why?

[Anonymous Coward]

[With my snappy upstream hat on]

1) snap packages cannot have scripts, you will never run any 3rd party code as root while installing *any* package.
2) *all* executables shipped by snap packages run under heavy confinement, having no access to the outside system and no access to user data except where the user explicitly chooses for this to happen (access to user data, the system is off-limits at all times)
3) users cannot install snap packages without being root (this is controlled by policykit so can be changed later) though this check is entirely arbitrary. Snapd runs as root, snap (CLI) just talks to it over a socket.

More Complexity

[Anonymous Coward]

It sounds like another layer of complexity to me. Whether it's justified I guess is to be seen, but I have my doubts.

Snaps!

[Anonymous Coward]

Modern snap snappers know that only snaps can snap snaps, so give up on your insecure luddite packages and use snappy app snaps! Snaps!

Re: Snaps!

[Anonymous Coward]

Aww, snap.

Re:Snaps!

[aliquis]

Modern snap snappers know that only snaps can snap snaps, so give up on your insecure luddite packages and use snappy app snaps! Snaps!

I want a separate package-manager for every package I install. Surely there's one which does something better than everything else?

Re:Snaps!

[Anonymous Coward]

"I want a separate package-manager for every package I install."

You're looking for Windows? I think I saw him drinking at the High Overhead.

Stupid appers

[Anonymous Coward]

they can decide to bundle specific versions of a library with their app.

Do. Not. Want.

Re:Stupid appers

[Junta]

I agree, funny thing is that application packaging can *already* bundle their own version of a library, if they cared. That's part of the whole point of the /opt/ filesystem hierarchy, to give applications their own space to apply *whatever* they want

Re:Stupid appers

[ewhac]

I can think of one case where you might actually sorta maybe kinda want this: Media applications.

More specifically, video editing applications. 'ffmpeg' has been a moving target for years. The command line arguments and API to the various libraries is in constant flux. Part of this is good, in that ffmpeg can add new features, refine the quality and reliability of the codecs, and keep up with new developments in digital video. However, it also means that an application can't really rely on the interface to ffmpeg remaining stable. If you code your app to ffmpeg v2.5, but the user upgrades the system copy to v3.0.1, then your app will break. But even if the interfaces don't change, the internal implementation of the codecs may be tweaked or changed completely, meaning that a video that looked fine with a particular collection of settings may look completely different in a newer version.

So, yes, loathe as I am to admit it, there are certain cases where binding to a specific version of a library is actually what you want. However, given that LD_LIBRARY_PATH and LD_PRELOAD still work (not to mention the version range-checked dependencies .deb packages offer), it doesn't explain why you would need a new packaging format to accomplish this.

Re:Stupid appers

[Anonymous Coward]

Great. Now when ffmpeg has another 0day, you'll have to update all of your snaps instead of just updating ffmpeg.

What you really want is for ffmpeg to behave like a mature package and support side by side installations (e.g. ffmpeg-2.5 and ffmpeg-3.0); then the user can choose which one links to /etc/ffmpeg with update-alternatives.

Re:Stupid appers

[Anonymous Coward]

Steam already does this to an extent. It causes no limit to grief among AMD graphics card users using the radeon drivers.

Re:Stupid appers

[Rutulian]

It's not really the version of the library that's the problem, in the majority of cases. As a few have already mentioned, the interfaces often don't change between library versions, so older software can often compile fine against newer libraries. The problem is, most people want binary distributions. Source distributions are great, and very flexible, until you want to A) install something closed-source, or B) install something large and complex, like LibreOffice. Most people, myself included, don't care to sit around and wait for 2-3 hrs for something to compile just so they can get some work done. If you can just install it, you are usually much happier.

The problem is, to get binaries to share dependencies, it is not just the filenames and locations that must be same. The symbol tables have to be exactly what the app is looking for (ie: linked against). So that means, the build environment has to be the same, or at least generic enough, to get the required compatibility. If you change something like glibc, everything compiled against it has to be recompiled and relinked. That is the major source of frustration, and it is not an easy problem to solve.

Re:Stupid appers

[Junta]

What I'm saying is that a software provider so inclined may package their content into /opt/ and pull in dependencies of their liking. Hell up to and including glibc itself, if they are absolutely crazy enough. I know this painfully well as I have worked on a team to provide *one* set of rpms that could be installed on *any* rpm based distribution, and there was a whole lot of senseless library bundling involved to make that work, which I objected to but they did it anyway. Suddenly we were on the hook for every single bug and advisory those libraries incurred, a nightmare.

My current primary project has a similar goal of supporting multiple versions of multiple distributions. However this time I got my way of per-target repositories, in no small part due to an automated build process where per-version and per-distro repositories are automatically generated by the build process. We still have a couple of deviations (due to the version in-distro being uselessly ancient for our uses, for example), but we still package those to coexist with upstream library and use our '/opt' namespace as a means to deliver potentially incompatible libraries we need.

You don't have to have the user compile from source to use /opt.

SNAP!

[TechyImmigrant]

SNAP

Just sayin'

Winlux 4va !

[Anonymous Coward]

Yeah, we already have regedit... Err gconf, now every app will come with its own set of dll.. Err .so...
Time to try pcbsd !

Re:Winlux 4va !

[SumDog]

and we have svchost.exe too (it's called SystemD)

Re:Winlux 4va !

[NotInHere]

Well I hope that open source packages won't switch to the new snap system, as of course it adds duplication, and now many application providers have to update one of their libraries only because of some badlock vuln or something. Some app store owners try to counter this by threatening app owners to take down their apps if they don't update the libraries. But this only gets the biggest libraries and those with most light shined on them, the small library might never get updated.

Yes, poettering has seen correctly that the duplication can be fought with fs level dedup like btrfs is doing it, but that still doesn't solve the update problem.

Where the snap system shines at is closed source applications and open source applications which both get shipped outside of the distro's packaging system: if adopted by all distros, you can ship cross-distro binaries without having to bother about some distro's settings for their libraries.

And closed source applications is one of the areas the linux desktop sucks at. There are almost no linux versions of many more or less popular closed sourced applications.

Re:Winlux 4va !

[Anonymous Coward]

Yep, Gnome has provided us the excellence of Metro UI and systemd has introduced the equivalent of binary eventlog.

Re:Winlux 4va !

[F.Ultra]

So you don't know that svchost.exe or systemd does but still made a post.

Re:Winlux 4va !

[stub667]

Well I hope that open source packages won't switch to the new snap system, as of course it adds duplication, and now many application providers have to update one of their libraries only because of some badlock vuln or something. Some app store owners try to counter this by threatening app owners to take down their apps if they don't update the libraries. But this only gets the biggest libraries and those with most light shined on them, the small library might never get updated.

Where the snap system shines at is closed source applications and open source applications which both get shipped outside of the distro's packaging system: if adopted by all distros, you can ship cross-distro binaries without having to bother about some distro's settings for their libraries.

The other part of snaps that I think *does* make it attractive for some open source software is that the application is installed and run in a container. This is great for those web browsers that more and more think of themselves as operating systems, and to a lesser extent many other applications. Being able to control the camera and mike from outside of the container, restrict it from writing to the parent containers filesystem at all except for ~/Downloads, block all incoming connections, restrict outgoing connections... At the moment, users place a huge amount of trust in people we don't know to write secure and non-malicious software and by easily putting this software in a sandbox we can lower that mandatory trust level somewhat.

Re: Winlux 4va !

[Anonymous Coward]

I always thought of srvchost.exe as being like xinetd.

Re: Winlux 4va !

[F.Ultra]

svchost.exe has no counterpart in the Unix world. At some point in time, Microsoft decided to rewrite all their system services (init deamons) as dll:s instead of exe:s so they needed an exe that could load a dll and execute a specific set of functions in it and it became svchost.exe so ever system service written by Microsoft is seen as svchost.exe in Task Manager which for one thing made it into favourite nr 1 among malware/trojan writers.

32 Bit EFI

[johnsmithperson123]

The really sweet feature is native support for 32-bit EFI. Finally all of us who bought cheap BayTrail tablets can install Ubuntu like normal people.

Re:32 Bit EFI

[Anonymous Coward]

What about drivers? There are instructions on the web for installing linux (including ubuntu) on bay trail laptops, which presumably apply as well to tablets. The subsequent problem that I encounter was the lack of wifi and audio drivers, which led me to revert to Windows and to largely write that hardware off. This was on an Asus X205TA (which I returned) and on a Lenovo IdeaCentre Stick 300 (which I've kept).

Re:32 Bit EFI

[Anonymous Coward]

Normal people don't install Ubuntu.

Re: Ubuntu has LUDDITE software, NOT APPS!

[Anonymous Coward]

Of course Ubuntu doesn't have apps... They just said they have Snaps! Pay attention, man.

Great.

[Anonymous Coward]

Can't wait to have thirty copies of libssl installed when the next big security vulnerability hits.

XKCD

[darkain]

Obligatory XKCD reference: https://xkcd.com/927/

'More secure'

[Junta]

More secure as in 'have to wait for app packager to update openssl library rather than updating it system wide and taking care of all dynamically linked apps'.

In fact, for 'security' I'm having a real time linking the rhetoric to a meaningful benefit. Among the benefits of this sort of strategy, I don't see how security would be one of them.

Re:'More secure'

[Anonymous Coward]

You don't need to ship your own copy of openssl, snap packages can reference system libraries.

The main security benefit is that snap apps are installed in their own sandbox and don't need root access to install.

Re:'More secure'

[Anonymous Coward]

Except for the simple issue that in order to actually run on more than one (version of the-) distribution, snap 'packages' will bundle all these rather security sensitive libraries (openssl, libpng, libjpeg, libsqlite, etc.) - like they do on commercial operating systems without package managers.

Re:'More secure'

[sad_]

they don't need root? now shit is really going to hit the fan.
when installing ubuntu on somebodies pc, it stays stable because they can't install any of that crap that you see every single person installing on windows. now they will be able to do so on linux too, opening the door to all kinds of nasty uncontrolled stuff.

Re:'More secure'

[perryizgr8]

But that's the whole point. No nasty stuff can happen because every program is sandboxed.

Re:'More secure'

[Junta]

But... it isn't.... I mean, not really.... A non-admin user may install an app into their home directory, so that's a matter of 'convenience' and 'user doesn't need to sudo to install', but it can still access home directory and stuff... Basically precisely the scenario poked fun at by the xkcd talking about how his system would protect itself from installing drivers, but would merrily let applications at his browsing history and such.

'sandbox' generally only has meaning if you have a very small and well-defined universe of defined things an environment can do. Running javascript in a sandbox is possible to be meaningful because the functionality is limited (e.g. you can't just ask to open a random file on the local filesystem', it has a lot of restrictions about where it can and cannot request data from on the internet, etc). Here 'security' refers to 'system protected from user when user installs what they like', which was previously possible, but without the niceties of package management (in part because if you are building something to live in '/home', there's not a whole lot of dependencies and stuff to sanely handle...)

Re:Ubuntu has LUDDITE software, NOT APPS!

[Anonymous Coward]

Not your best effort.

Scant on details, high on assumptions

[digitalderbs]

The details on this new packaging system are scarce--and I've checked--but it looks like a reimplementation of Docker, which would be a welcome addition. A number of comments have stated that this would lead to library fragmentation and security problems with a large number of library 'copies' needing updates. However, if this is implemented like Docker, all the apps would depend on a core image that would be updated in itself.

Frankly, docker apps are the future of package management. Each app is sandboxed (like a chroot jail), and you can establish firewall-like access to the app for directories, services and such. Also, dependency hell goes away because these apps use the advantages of static and dynamic libraries. As long as a package is using a core image (like Ubuntu 16.04), then updates to that image are automatically upgraded to all apps.

The only puzzling aspect of this is why ubuntu didn't just use Docker. X connections are non trivial with Docker, and perhaps this new system makes access more straightforward. In any event, I think there's more than meets the eye here. Apt rocks, but docker is better for package management.

Re:Scant on details, high on assumptions

[Etcetera]

Also, dependency hell goes away because these apps use the advantages of static and dynamic libraries. As long as a package is using a core image (like Ubuntu 16.04), then updates to that image are automatically upgraded to all apps.

This is 2016. What Linux distro out there still has a "dependency hell" problem? Yum and Apt-get are a decade old and handle dependency resolution. If your packages are compiled against a "core image" (or actual, bona fide release) and your repo is generated wrong and you're experiencing "dependency hell" then either:
a) someone is doing something wrong, or
b) you have an actual, bona-fide file conflict that can't be automatically resolved

Re:Scant on details, high on assumptions

[Anonymous Coward]

I can't speak to Yum, because I'm not intimately familiar with the process. But, Apt packages are only as good as the developers that write them. Having done work to package "upstream" versions of Thrift and Boost, and backporting literally dozens of packages from "New" versions of Ubuntu to work on my company's "older" LTS version of Ubuntu... I can assure you that dependency hell is still alive and kicking.

As a recent example - Samba doesn't impose particular version dependences to do a configure && make && make install cycle on a standard Precise or Trusty image; However, if you try backporting the "latest" Samba 4.3.3 image from Xenial back to even Trusty, you will rapidly find yourself looking at a complete fucking mess - why? Because package names and virtual packages and version dependencies for the Xenial version of the package are completely arbitrary. I can take the same code and compile it properly on any Precise or Trusty system, but try building the same version as a Deb package, and it's a host of "dependency not found" errors, all the way down.

Somebody claiming that "package management" is a solved problem on Ubuntu and Debian is someone who's never bothered to actually create one of those "just works!" packages. It's a VERY hard problem, and has a million brittle corner cases that will fuck you sideways if you don't know what you're doing. Not to mention that I literally cannot, right now, update a Trusty system to the latest set of packages available, because at some point along the way, the systemtap package picked up a bug in its preinst or postinst script that prevent the package from upgrading properly, which in turn, means that every time I try to apply new packages, I end up with a "package not configured, can't install new packages" error message.

Re:Scant on details, high on assumptions

[Anonymous Coward]

I suppose it's a different hell, one you have to walk through instead of reside in.

To be more specific, this hell is if you want to package or install an application that uses library version X but system provides only up to version Y less than X, or some other application breaks with version greater than Y.

I prefer that hell to some of the worse hells, but it can still be a mess.

Re:Scant on details, high on assumptions

[Anonymous Coward]

The term "dependency hell" was and is a problem unique to Windows. Until Visual Studio 2013, Microsoft shipped a unique C runtime with every compiler version, plus a system C runtime, each one mutually incompatible with the others. If library A was compiled with Visual Studio 2010, but library B compiled under VS 2008, you often couldn't combine them in the same process because if a pointer allocated from A's CRT's malloc was deallocated using B's CRT's free you could get a segfault, at least if you were lucky. If you were unlucky you just got random heap corruption.

With VS 2013 Microsoft made their first tentative steps toward backward compatibility, but only moving forward. That puts it at least 25 years behind Unix (including Linux) in terms of the sophistication of its dynamic linker and run-time environment in the context of ABI compatibility. Windows PE format is straight out of the 1980s. And while Microsoft has done some amazing work with PE, it works mostly because of built-in limitations. Most Windows developers can't even fathom something like the per-symbol versioning that ELF provides. Or if they know of it, they'll say it's impractical to maintain such backward compatibility, which is just evidence that they're suffering from Stockholm Syndrome.

If you think cyclic dependencies are a problem with Apt, know that trying to build anything remotely like Apt for Windows would be many magnitudes worse. It's basically incomparable. No sane person would even _imagine_ trying to share dependencies at that scale under Windows.

Re:Scant on details, high on assumptions

[Rutulian]

The details on this new packaging system are scarce--and I've checked--but it looks like a reimplementation of Docker,

I guess we'll find out more in time, because I too couldn't find any details on how this is implemented. If it does use containers (a la Docker), that would be really cool. As soon as Docker started getting more fleshed out, this was the first application I thought of that would be perfect for it.

An application being able to use alternative libraries is definitely a need on modern linux. I can't count the number of times that I needed to do massive upgrades of the system just to install a newer version of an app I was using. My only worry is that this will depend on the non-laziness of app developers to work well. Snap packages can use the underlying system, but only if app developers take the time to specify their dependencies, which is something they already don't want to do, apparently. So instead, they bundle their own libraries, even if they are already available on the system, and we get OSX bundles, which I'm not a big fan of. Ideally the snap system would default to using a system library if it meets a dependency and only a bundled library if that dependency is not met, but based on the scarce information available that doesn't seem to be the case.

It would also be nice if there was a quick way to determine library versions in all installed snaps, so that you can see which might be vulnerable to recent security errata, for example. Not sure if they have plans for tools like that, but it would sure be useful.

Re:Scant on details, high on assumptions

[Etcetera]

I can't speak to Yum, because I'm not intimately familiar with the process. But, Apt packages are only as good as the developers that write them. Having done work to package "upstream" versions of Thrift and Boost, and backporting literally dozens of packages from "New" versions of Ubuntu to work on my company's "older" LTS version of Ubuntu... I can assure you that dependency hell is still alive and kicking.

As a Red Hat / RPM guy, this kind of confirms what I'd suspected from my relatively brief interactions on the Debian side -- it's an ecosystem and tooling problem more than anything. RPM dependencies are calculated from files and SONAMEs, but can also be specified manually by the packager, including version inequalities of other packages.

Boost and other "no stable release" libraries are a distinct problem. At that point, you might as well simply be installing static libraries again at compile time. If you need dynamic environments at compile time, that's what you'd use SCL's (Software Collections) for, such as https://www.softwarecollections.org/en/scls/denisarnaud/boost157/

Obviously, taking a newer/older package from a different core release, or a different distribution, is going to give you dependency problems. (It astonishes me that people still think rpmfind.net is expected to "just work" when doing an install onto their box...) If you are trying to install something that requires (at *runtime* a library that's incompatible with the ABI version of the library that's on your machine, and that doesn't have a set of compatibility libraries present, then the fact that it doesn't work is a feature, not a bug, of dependency resolution.

Otherwise, just recompile the RPM for the release of the OS you're running on (usually a dedicated build host, but doesn't have to be) and install from there. The only tweaking that'd need to be done is if the RPM format itself changed (spec file directives) between that version and the box you're on.

As a recent example - Samba doesn't impose particular version dependences to do a configure && make && make install cycle on a standard Precise or Trusty image; However, if you try backporting the "latest" Samba 4.3.3 image from Xenial back to even Trusty, you will rapidly find yourself looking at a complete fucking mess - why? Because package names and virtual packages and version dependencies for the Xenial version of the package are completely arbitrary. I can take the same code and compile it properly on any Precise or Trusty system, but try building the same version as a Deb package, and it's a host of "dependency not found" errors, all the way down.

Well, then that's really a problem with the community not enforcing proper requirement standards that reflect reality on important packages. In the VAST majority of cases on the Red Hat side over the past 6-7 years, I can take a current version from the latest Fedora (or even rawhide, the rolling dev branch), recompile it on a previous stable release of Fedora, RHEL, or CentOS, and things work OK so long as there hasn't been an incompatible ABI change. The main problems that have cropped up in recent years are basically because of incompatible .spec file demands and the systemd BS.

Somebody claiming that "package management" is a solved problem on Ubuntu and Debian is someone who's never bothered to actually create one of those "just works!" packages. It's a VERY hard problem, and has a million brittle corner cases that will fuck you sideways if you don't know what you're doing. Not to mention that I literally cannot, right now, update a Trusty system to the latest set of packages available, because at some point along the way, the systemtap package picked up a bug in its preinst or postinst script that prevent the package from upgrading properly, which in turn, means that every time I try

Re:Scant on details, high on assumptions

[Rutulian]

g. RPM dependencies are calculated from files and SONAMEs, but can also be specified manually by the packager, including version inequalities of other packages.

Debian has this too, and I think it is actually a good deal more flexible than rpm, at least from what I remember from my brief stint with Red Hat back in the day. There's a reason Debian was able to have apt long before Red Hat/Fedora had yum.

https://www.debian.org/doc/man...

Well, then that's really a problem with the community not enforcing proper requirement standards that reflect reality on important packages.

This is the real problem. And I dare say it is 99% an Ubuntu problem because they really like to break everything with each subsequent release. Debian has been a rolling release distribution since forever and is renown for the incredible robustness with which packages can be shared between stable, testing, and even unstable, as well as the ease of transitioning from one to the other (ex: when testing becomes the new stable). And they have once or twice had to do some massive renaming of library dependencies, but managed without a hiccup, which is a testament to the quality of the deb system.

No, the problem is Ubuntu. Their versioning is a constant clusterfsck of broken, incompatible package naming. And they heavily abuse "virtual" packages for their own purposes which leads to the breakage in Samba like the GP described. It is horrible release management and is one of the many things wrong with Ubuntu. However, Ubuntu manages to stay more up-to-date, and has some pretty nifty userland tools, so I find myself using it much more than Debian. But I lament every time I have to upgrade, or if I want to move packages between versions.

Snap sounds like a system with some much-needed features, but what I would really like is for those features to be integrated into deb. Unfortunately, Ubuntu is following their usual pattern of aloofness. Both Debian and Ubuntu would benefit tremendously if they could work together to enhance deb. Transactional updates? Who doesn't want that? That is a great feature. But nope, that's not going to happen, apparently. We're going to end up with another Mir, or Upstart, or Compiz (shudder).

Re: Scant on details, high on assumptions

[jofas]

Haha. Spoken like someone who never tried to install Mandriva Linux and have Yum break X.

Re:Scant on details, high on assumptions

[Anonymous Coward]

which would be a welcome addition.

No it wouldn't. Operating systems already do all the
things docker purports to do. Docker will have all the same
problems as the OS when mature. For the same reasons.
But with an added layer of complexity.

Docker is unfortunately a classic example of the ignorant
unwilling to learn from history and condemned to repeat it.

Apt rocks, but docker is better for package management.

That's laughable. Docker solves only a fraction of the package management problem that apt and the OS cover. And badly at that.

Re:Scant on details, high on assumptions

[Junta]

You are assuming good practices. Yes, I can have a dockerfile and properly maintain and rebuild periodically 'from scratch' as it were to pick up updates.

However there are a crap ton of ones out there that are not so disciplined. They did a docker pull and started just going to town, doing a docker commit against a running instance to get a new image, rather than doing something that would assure package updates. And also this is *if* the maintainer is even paying attention at all.

It's also a licensing nightmare for companies. If a company ships software, they frequently have to have their lawyers sign off on *everything*. With docker, they are on the hook for *everything*. Every advisory, every copyright holder, everything short of the kernel itself.

And finally, for *just* addressing library dependencies, docker is stupid overkill. You need to have a unix domain socket and everyone has to be in a group to start it and the storage architecture is wacky and the default network behavior is very weird, and for a common usage uid namespaces just muck things up. It all makes sense toward the goal of 'containers almost like VMs', but for a day to day usage, it's overkill. Basically, doing a mount namespace and *maybe* a pid namespace is appropriate for more seamless use of applications in such an environment using an executable with privileges as a helper.

Re:Scant on details, high on assumptions

[Junta]

Yes, docker is *image* management (which is handy enough), it is in no way a package management solution.

Wow...

[ThatsNotPudding]

People are still using Ubuntu?

Re:Wow...

[Anonymous Coward]

Well, not everyone can be a faggot like you, can they?

wow. so edgy

[Anonymous Coward]

Yes, grampa, people still use Ubuntu. The only bad part about Ubuntu is the Unity desktop environment. Xubuntu and Ubuntu MATE don't suck.

If you make the mistake of downloading the vanilla Ubuntu ISO, all you have to do is install a better desktop environment (apt-get install xfce4 or apt-get install mate-desktop), logout, login with the new DE, and then remove unity (apt get purge unity*).

This is important

[Anonymous Coward]

This is important, why?

Read about it before commenting, people!

[emblemparade]

Wow, people commenting seem to have so little information about what this actually is. (Canonical is partly to blame for, as usual, doing a poor job at messaging.)

This is not replacing the Debian build system or Debian packages. Ubuntu will continue to be based on Debian.

This is an additional packaging system that makes it exceptionally easy to more reliably distribute Linux applications and services. Underneath it uses LXC (also originally developed at Canonical), the same jail-like technology that powers Docker and LXD. It basically lets the application get its own "view" of the operating system's filesystem (using AuFS) so that you can distribute required dependencies with the application. Of course it can't override the Linux kernel or other important system services, but it actually solves a major hurdle in distributing software across various OS library baselines. Until now, we've been using PPAs or other external Debian repositories to distribute software -- you can still use them if you prefer, but these are tied to the baseline and need constant tweaking to the packagers. A Snappy package made now should be able to run years from now without a problem. The Snapcraft packaging tool is very easy to use and does so much of the hard work for you: you can even just give it a git repository URL, and it will pull and build and package. I see it being very useful for something like Steam.

Also, like Docker, Snappy uses SHA-signed diffs, so package updates will be very fast. It also makes it trivial to switch between versions.

The announcement is that Ubuntu 16.04 will come with Snappy built in, so you can immediately install Snappy packages if you want. You don't have to.

There is also a new flavor of Ubuntu called "Snappy Ubuntu Core" in which the base OS itself is a Snappy image, so that it gets updates the same way as the other packages, and in the same way you can switch between versions. It is useful for various special use cases. For example, a phone OS will have an easier and safer job upgrading while letting the user trivially revert back if things break. It is not the official Ubuntu recommended for all users, but rather a building block for developers to create specialized Ubuntu-and-Snappy-based distributions.

Re:Read about it before commenting, people!

[Rutulian]

Interesting. That's more information than I was able to find anywhere else. Thanks.

Here's what I'm most worried about, though. How dependent is it on non-lazy packagers? In other words, the easiest and most convenient way to package anything is to ship with all dependencies and the app uses those. The problem, though, is each application is then solely responsible for updating itself, including to patch bugs in any dependencies, so it quickly leads to running a million app updaters in the background, which is the current nightmare on Windows and OS X. Ideally, this system would be smart enough to use the base system by default and only use the supplied dependency if the base system can't provide it or if there is a conflict of some sort. But I doubt it will do that, which means it is on the packagers to check the base system first before installing their own dependencies. Somehow I doubt they are going to do that, though.

Re:Read about it before commenting, people!

[Anonymous Coward]

Wow, people commenting seem to have so little information about what this actually is. (Canonical is partly to blame for, as usual, doing a poor job at messaging.)

This is not replacing the Debian build system or Debian packages. Ubuntu will continue to be based on Debian.

This is an additional packaging system that makes it exceptionally easy to more reliably distribute Linux applications and services. Underneath it uses LXC (also originally developed at Canonical), the same jail-like technology that powers Docker and LXD. It basically lets the application get its own "view" of the operating system's filesystem (using AuFS) so that you can distribute required dependencies with the application. Of course it can't override the Linux kernel or other important system services, but it actually solves a major hurdle in distributing software across various OS library baselines. Until now, we've been using PPAs or other external Debian repositories to distribute software -- you can still use them if you prefer, but these are tied to the baseline and need constant tweaking to the packagers. A Snappy package made now should be able to run years from now without a problem. The Snapcraft packaging tool is very easy to use and does so much of the hard work for you: you can even just give it a git repository URL, and it will pull and build and package. I see it being very useful for something like Steam.

Also, like Docker, Snappy uses SHA-signed diffs, so package updates will be very fast. It also makes it trivial to switch between versions.

The announcement is that Ubuntu 16.04 will come with Snappy built in, so you can immediately install Snappy packages if you want. You don't have to.

There is also a new flavor of Ubuntu called "Snappy Ubuntu Core" in which the base OS itself is a Snappy image, so that it gets updates the same way as the other packages, and in the same way you can switch between versions. It is useful for various special use cases. For example, a phone OS will have an easier and safer job upgrading while letting the user trivially revert back if things break. It is not the official Ubuntu recommended for all users, but rather a building block for developers to create specialized Ubuntu-and-Snappy-based distributions.

Wow what a load of bullshit!

Im an upstream developer on snappy but patent poster should really read before telling others how snappy works.

Im on a phone now so I cannot comment more but seriously people, read our announcement in full, read the source.

Ffsss

Re:Read about it before commenting, people!

[Anonymous Coward]

Its better than, say, static binding. Even if the main executable is a closed source blob, the packaging isn't. You should be able pull apart the snap and reassemble it with updated dependencies.

Need a safe "reinstall" button

[tepples]

I read the complaint as there not being a safe "reinstall" button that sets the installer to use the same partitions and not format anything.

Re:Need a safe "reinstall" button

[Hylandr]

You kids and your 'installers'. I admit they are nice now, but in 1997 you had to know how to do things and some methods were easier or safer than others.

I think this is what RghtHndSd was referring to.

Whoooaaaah There Skipper

[Anonymous Coward]

Frankly, docker apps are the future of package management. Each app is sandboxed (like a chroot jail), and you can establish firewall-like access to the app for directories, services and such.

I keep reading this and I get the feeling everyone imagines chroot solves something. Compromise a jail, the system (a chroot) is still compromised. The database the chroot connects to might still get dumped.

Are chroots useful? Yes. Is it "more secure?" maybe.

Re:Whoooaaaah There Skipper

[Gazzonyx]

Frankly, docker apps are the future of package management. Each app is sandboxed (like a chroot jail), and you can establish firewall-like access to the app for directories, services and such.

I keep reading this and I get the feeling everyone imagines chroot solves something. Compromise a jail, the system (a chroot) is still compromised. The database the chroot connects to might still get dumped.

Are chroots useful? Yes. Is it "more secure?" maybe.

More specifically, chroots are a single layer of security and a robust security scheme should always have multiple layers.

Why do this then?

[HalAtWork]

So outdated libraries you have to rely on third parties to update in sync? That doesn't sound terribly safe.

Re:Why do this then?

[allo]

You mean like most windows programs?

Re:Why do this then?

[HalAtWork]

That's one example, yes.

Re:Why do this then?

[TechyImmigrant]

It alters the risk profile.

Shared libraries require that all the library code be present making ROP attacks easier and when there's a vulnerability in the library it is present in all the programs that link to the shared library.

Static libraries require only the code that used to be present, making ROP attacks harder. When there's a vulnerability in a set of versions of the library it is only exposed if the vulnerable code is linked and the a vulnerable version is linked.

So neither is perfect, but I like stand alone binaries that don't have shared library dependencies. They don't lead to trouble when I move them between linux versions.