Linux devs open up universal Ubuntu Snap packages to other distros

What Linux needed?

This might be the key to make Linux a more common platform users. Packages are written for one installer and can be installed on any supporting distro.

What is interesting is that Snap was written by Canonical for their purposes but released as FOSS so others could use it. This Linux users can still have our cake and eat it too. Many distors with effectively one package manager for the applications.

Static linking returns...

essentially. Sounds like a good idea until your "Snap-app's" each with their own SSL library set etc. are updated at various frequencies (or more likely infrequencies) and your security scans look like Swiss cheese.

Before retiring, one of my least favorite activities was sorting through the security issues from old, decrepit, and buggy versions of Java that vendors had bundled with their application. They typically promised to support only the version they bundled, and as we were a US DoD agency, we were required to have support for niceties like security issues. This was not a problem until a vendor's favorite java became an unsupported product, at which point we had to start writing POA&M or Acceptance of Risk documents about the Java that Sun or Oracle no longer supported. Sometimes we had four or five versions, of which two or three no longer had support. That left us in a bind: replacing the unsupported Java gave us an unsupported Java application. Explaining that to the CIO was not pleasant, who was extremely averse to signing an Acceptance of Risk.

Snap appears to be a codification into open source of this noxious practice.

PBI

Snaps seem to be basically the same thing as PBIs in PC-BSD. Except PBIs were discontinued.

Interesting?

"I'm sure that Microsoft will want that for their Ubuntu compatibility layer."

Is this significant or is it old news that I hadn't noticed before?

It's a stupid idea

It gives the illusion of security by sandboxing. This illusion creates the illusion that you can simply run "apps" from untrusted sources. This means that people will just download whatever "app" they find which means they will enter "$programname free download" into a search engine and click the first link... which likely isn't the trustworthy source... and likely is malware, reducing security to a sandbox which only pretends to work against certain problems and probably will even fail at that.

Typical problems I see are something called "Abofalle" in German, where you think you download some free software, but instead sign a contract forcing you to pay money to some criminal. There probably will be downright malware in those packages, too. After all, if the user wants to execute a certain program, they will give it all the rights it want. A rights system only works if the application cannot determine if it got the rights or not and I can always edit the list of rights the application has.

We live in a sad age when people just write code without thinking about it first.

Great, so a common library gets a security upgrade and we have to update every single package....

I must admit that when I first saw the announcements I thought it was just an extension of keeping applications and dependencies together in /opt. I'd missed out the containerisation. On the whole it seems like a step forward. However, as Matthew Garrett has pointed out in relation to X there's a vulnerability where containerised applications still depend on a leaky common service. It's not yet clear to me how much sharing of common libraries will continue. I suppose the answer is to look at the Pi version of Ubuntu Core. Another thing to do when I get a round tuit.

I'm glad to see this.

I really don't buy the downsides against this.

"If you have multiple copies of dependencies, all the apps that depend on it won't get security fixes when a single dependency is updated."

This seems to be a nice goal, but doesn't seem to work in the real world. Dependencies in distros seem to stagnate a bit as apps progress. Dependencies/Apps don't get updates because of conflicts so NO ONE gets the new security update because versions are locked to avoid conflicts.

I guess I'm just really tired of seeing a new version of software I use (or new software that I WANT to use) on the developers web site with lots of additions I really want. Then realizing the version I have on my distro of choice is ancient, and there are no binaries for my distro. So, I grab the code and build it. Only to find out it requires a library version that is also not in my distro. Sigh, so I grab and build that. Then realize that library won't build with the gcc version on my distro. So, I go grab that, and so on until I finally have a nice blob sitting out on /opt for the app. I am a developer for a living, and I get enough of building software at work. When I want to use an app I just want to hit install and be done.

And finally, if a library in a distro is not frequently updated, snap packages would actually be more likely to be newer, more secure, versions with bug fixes, because the developer himself can keep the package updated as he develops the app. I would much rather have 3 out of 5 snap packages with the newest code/dependencies than have 5 standard debs all on old versions because their dependencies don't play nicely with all of the apps, or the volunteer packager didn't feel like taking the time to update the library.

Now, I won't call this a silver bullet to replace all things binary distribution. But, it sure looks to fix a really big issue that is widespread on Linux. Allowing the developer himself to "easily" package his latest and greatest version for a smattering of distros seems like a good idea to me.