LXer: Goodbye rpm and deb. Hello Snaps!
 

Published at LXer:

Cross-distribution support for Snaps could turn the fragmented Linux desktop into one big platform and fix the Linux desktop mess.

Read More...

Sounds interesting.

This is indeed an interesting idea, even though I use Slackware which compiles by source, if this did work well I wouldn't mind seeing it in Slackware, ...IF it works well.

At what cost? Can anyone see what is lost by the all-in-one cluster-bang?

If it can be added optionally I don't see a problem. Rolling your own packages would obviously still be an option for those who prefer it.

I actually see nothing wrong as long as it is not mandatory and if introduced differently not like how systemd was introduced and the outright tone that it was a requirement..

The problem with this movement is that dev.'s will only make the standard package with standard features. Distros will lose even more of their "unique" characteristics and Linux will move towards the options only being RedHat, Suse, Debian or Ubuntu. I suppose if the person does not like this and this is the future we are moving towards then source based distros could avoid it, in the same way that they do not use .deb or .rpm unless they choose to.

Will be interesting to see if RedHat comes out with their version ala systemd v. upstart or will they allow Ubuntu to take credit and take the lead on package design.

This is worrying -- it sounds like the idea is to have Windows-style every application installs every library -- so one would end up with 18 copies of the same library all of slightly different versions taking up disk space.
Seems like something useful for, say, Skype or other third-party binary but a bad idea if every application were to be deployed this way.
The "containerizing" sounds weird also -- as if you can't access GIMP output files with image magic tools or something? Yes, I know that's an exaggeration but, really, it's not as though any old application run as non-root can modify the executables of any other application. If they mean that on installing one application one doesn't mess with the libraries of another then we're back to 18 different versions of libpango or whatever.

I really wish I could recall the name of the project I read about recently to add a layer of metadata to the packages of each distribution so that any distribution could read their contents, dependencies and the like. It seemed a much less radical approach.

Sorry, I'll double-post rather than editing. I just recalled that this is already a thing -- it's called "Unzipping an application into /opt". Granted in that case most of the time the package is using system libraries but I have dropped .so files into application directories in /opt to resolve dependency issues in the past.

Yeah, after reading some more and thinking about it it doesn't sound like it is a great idea after all. Mainly because of all the lib that will be installed and how to keep track of them.

Yeah, I'm not a big fan of the idea, although I admit the current state of packaging isn't the most ideal either.

Snaps, or flatpaks. It depends on who wins, Redhat or Canonical. Both have serious faults, but both can probably be fixed eventually. Debs and rpms will certainly survive and be used for at least some packages, if not most. One problem with snaps and flatpaks is the size of the installation package. For instance, a snap for LibreOffice comes in at more than a gigabyte. Whether or not that is acceptable is way up in the air. So far, all we've had is marketing propaganda, because all this is currently market driven, by both Redhat and Canonical. Both want to win the hearts and minds of Linux consumers. Neither will take over Linux in the near term, and the long term is too murky to even guess at. But we'll get lots of propaganda for months, if not years.