Goodbye apt and yum? Ubuntu’s snap apps are coming to distros everywhere

[Patrick O'Callaghan]

http://arstechnica.co.uk/information-technology/2016/06/ubuntu-snap-app
s-are-coming-to-distros-everywhere-bye-apt-yum/

At first glance this looks really interesting and will be available on
Fedora, though according to the article RedHat haven't yet decided to
support it officially.

Any thoughts?

poc

[Tom Horsley]

On Wed, 15 Jun 2016 22:56:17 +0100
Patrick O'Callaghan wrote:
> Any thoughts?

I don't think this ought to be done via yet another
package format, because that will mean I'd still need
someone to create the package and if there isn't one,
I can't install (without lots more work).

I'd rather see a package manager deal with this by allowing
me to add any kind of repo from any distro and have it provide
the "containerizing" as it installs apps from conflicting
distros or with conflicting dependencies.

[James Hogarth]

On 15 Jun 2016 22:57, "Patrick O'Callaghan"  wrote:
> http://arstechnica.co.uk/information-technology/2016/06/ubuntu-snap-app
> s-are-coming-to-distros-everywhere-bye-apt-yum/
>
> At first glance this looks really interesting and will be available on
> Fedora, though according to the article RedHat haven't yet decided to
> support it officially.
>
> Any thoughts?

Be careful of the phrase "be available on Fedora" as it's in a COPR which
anyone can create and build in.

There has been no package review request for snapd and the instructions
have you disabling selinux in addition to the Fedora build disabling what
containment technology snap has in place (which relies on seccomp and
apparmor so is disabled in the Arch AUR build as well).

Using snap in a maintainable way (ie being notified of and installing
updates) only works with the Ubuntu Store as well, and Canonical have not
published any specs much less reference code for custom repositories (the
go code actually has the store hard coded, not even config files).

As a consequence I'd strongly advise being wary of this and avoiding it for
the time being.

What you should be aware of though is Flatpak which is a cross distro
initiative for contained applications similar to Canonical's Snap. This is
in Fedora and Arch official repositories right now, and in Debian
experimental and am Ubuntu PPA whilst it's being finalised.

This was formally known as xdg-app and had been worked on in an upstream
cross distro manner for a number of years now... rather than just being
dropped on the world by a single company ;)

[EGO-II.1]

> On Jun 15, 2016, at 7:45 PM, James Hogarth  wrote:
>
> On 15 Jun 2016 22:57, "Patrick O'Callaghan" <[e-mail] > wrote:
> > http://arstechnica.co.uk/information-technology/2016/06/ubuntu-snap-app http://arstechnica.co.uk/information-technology/2016/06/ubuntu-snap-app
> > s-are-coming-to-distros-everywhere-bye-apt-yum/
> >
> > At first glance this looks really interesting and will be available on
> > Fedora, though according to the article RedHat haven't yet decided to
> > support it officially.
> >
> > Any thoughts?
>
> Be careful of the phrase "be available on Fedora" as it's in a COPR which anyone can create and build in.
>
> There has been no package review request for snapd and the instructions have you disabling selinux in addition to the Fedora build disabling what containment technology snap has in place (which relies on seccomp and apparmor so is disabled in the Arch AUR build as well).
>
> Using snap in a maintainable way (ie being notified of and installing updates) only works with the Ubuntu Store as well, and Canonical have not published any specs much less reference code for custom repositories (the go code actually has the store hard coded, not even config files).
>
> As a consequence I'd strongly advise being wary of this and avoiding it for the time being.
>
> What you should be aware of though is Flatpak which is a cross distro initiative for contained applications similar to Canonical's Snap. This is in Fedora and Arch official repositories right now, and in Debian experimental and am Ubuntu PPA whilst it's being finalised.
>
> This was formally known as xdg-app and had been worked on in an upstream cross distro manner for a number of years now... rather than just being dropped on the world by a single company ;)
>
> --
> users mailing list
> [e-mail]
> To unsubscribe or change subscription options:
> https://lists.fedoraproject.org/admin/lists/[e-mail]
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
> Have a question? Ask away: http://ask.fedoraproject.org

I’m not feeling it. Anything that might have me disabling my SELinux which I’m STILL trying to understand and comprehend?…is not considered “friendly and benign” to me. I’ll stick with what I know so far…my “dnf”..and my RPM packages. SO thanks but No Thanks. (Don’t understand the incessant need to ALWAYS throw the newest "thing-a-ma-bobber” into what’s already working. I guess its all in the name of progress?…after all didn’t they push systemd into init’s place?…LoL! I guess it is what it is…and the consequences be dammned!

EGO II

[Patrick O'Callaghan]

On Thu, 2016-06-16 at 00:45 +0100, James Hogarth wrote:
> On 15 Jun 2016 22:57, "Patrick O'Callaghan" 
> wrote:
> > http://arstechnica.co.uk/information-technology/2016/06/ubuntu-snap
> > -app
> > s-are-coming-to-distros-everywhere-bye-apt-yum/
> >
> > At first glance this looks really interesting and will be available
> > on
> > Fedora, though according to the article RedHat haven't yet decided
> > to
> > support it officially.
> >
> > Any thoughts?
>
> Be careful of the phrase "be available on Fedora" as it's in a COPR
> which
> anyone can create and build in.
>
> There has been no package review request for snapd and the
> instructions
> have you disabling selinux in addition to the Fedora build disabling
> what
> containment technology snap has in place (which relies on seccomp and
> apparmor so is disabled in the Arch AUR build as well).
>
> Using snap in a maintainable way (ie being notified of and installing
> updates) only works with the Ubuntu Store as well, and Canonical have
> not
> published any specs much less reference code for custom repositories
> (the
> go code actually has the store hard coded, not even config files).
>
> As a consequence I'd strongly advise being wary of this and avoiding
> it for
> the time being.
>
> What you should be aware of though is Flatpak which is a cross distro
> initiative for contained applications similar to Canonical's Snap.
> This is
> in Fedora and Arch official repositories right now, and in Debian
> experimental and am Ubuntu PPA whilst it's being finalised.
>
> This was formally known as xdg-app and had been worked on in an
> upstream
> cross distro manner for a number of years now... rather than just
> being
> dropped on the world by a single company ;)

Thanks, that's the perspective I was looking for. I support the
principal of a cross-distro package and repo system if it can be done
right, but from what you say this may not be it, at least not yet.

poc

[Tim]

Allegedly, on or about 15 June 2016, Patrick O'Callaghan sent:
> http://arstechnica.co.uk/information-technology/2016/06/ubuntu-snap-app
> s-are-coming-to-distros-everywhere-bye-apt-yum/
>
> At first glance this looks really interesting and will be available on
> Fedora, though according to the article RedHat haven't yet decided to
> support it officially.

At first glance, this looks appalling!

.... Applications often require a lot of dependencies,
      making things more complicated, for example, when one
      application needs one version of another piece of
      software and a second application needs a different
      version of that other piece of software

"Snap packages solve this problem by creating
      self-contained packages," we noted in our
      review of Ubuntu 16.04, which brought snaps to
      servers and desktops. "With snap packages,
      applications are installed in their own container,
      and all the third-party applications are installed
      with them so there are no version conflicts.

Which means some of these things are going to be huge.  The point of
shared libraries is efficiency.  Just wait to you install a dozen things
that required Java, for instance, and they all decide that they need to
bring in their own, rather than use a system installation.

Just because you can buy terabyte drives doesn't mean that you should
try to fill them up.

I'm still staggered by the massive inefficiencies of modern computing.
I now have a gigahertz processor, and it's not a thousand times faster
to use the computer than my first PC.  And it's not *just* the hard
drive speed that's a bottleneck to that.  I also have 2 gigs of RAM, and
that's not enough.

[Mike Wright]

On 06/15/2016 08:29 PM, Tim wrote:
> Allegedly, on or about 15 June 2016, Patrick O'Callaghan sent:
> > http://arstechnica.co.uk/information-technology/2016/06/ubuntu-snap-app
> > s-are-coming-to-distros-everywhere-bye-apt-yum/
> >
> > At first glance this looks really interesting and will be available on
> > Fedora, though according to the article RedHat haven't yet decided to
> > support it officially.
>
> At first glance, this looks appalling!
>    .... Applications often require a lot of dependencies,
>    making things more complicated, for example, when one
>    application needs one version of another piece of
>    software and a second application needs a different
>    version of that other piece of software
>
>    "Snap packages solve this problem by creating
>    self-contained packages," we noted in our
>    review of Ubuntu 16.04, which brought snaps to
>    servers and desktops. "With snap packages,
>    applications are installed in their own container,
>    and all the third-party applications are installed
>    with them so there are no version conflicts.
>
> Which means some of these things are going to be huge.  The point of
> shared libraries is efficiency.  Just wait to you install a dozen things
> that required Java, for instance, and they all decide that they need to
> bring in their own, rather than use a system installation.

If I understand what you're saying, I don't think it's that bad.  When 
you pull in your first snap snapd loads a minimalistic version of your 
distro, then loads the snap.  After that the "core" snap accumulates the 
bits and pieces, the dependencies, etc. so you build up a system with 
only the pieces you require.  Think dung beetle versus feedlot.

After POC brought it up I started exploring.  I have some ubuntu 16.04's 
VMs and didn't even know about this project.  Using "snap find" came up 
with a list of 84 apps.  So there are not a lot there yet but some of 
what was there was pretty interesting.

The basic pieces are server, snapd, client, snap, and builder, 
snapcraft.  Everything lives in a "parallel universe" so there are no 
conflicts with your original host system.

I'm going to reserve judgement until I get a better feel for it but so 
far I like the concept.  I can't compare it to Flatpak yet.  That one's 
new to me to.

[Andrew Haley]

On 16/06/16 04:29, Tim wrote:
> The point of shared libraries is efficiency.  Just wait to you
> install a dozen things that required Java, for instance, and they
> all decide that they need to bring in their own, rather than use a
> system installation.

Here's a thought: couldn't this system use MD5sums to de-dupe shared
files?  Then you'd solve the dependency problems and not waste space
on duplicated files.

Andrew.

[stan]

On Thu, 16 Jun 2016 10:51:29 +0100
Andrew Haley  wrote:
> On 16/06/16 04:29, Tim wrote:
> > The point of shared libraries is efficiency.  Just wait to you
> > install a dozen things that required Java, for instance, and they
> > all decide that they need to bring in their own, rather than use a
> > system installation.
>
> Here's a thought: couldn't this system use MD5sums to de-dupe shared
> files?  Then you'd solve the dependency problems and not waste space
> on duplicated files.

I think that what you are envisioning has already been done by this
version of linux and its package manager.

https://nixos.org/nix/

I remember reading a critique of this scheme on the nix list at one
time, by someone from Fedora, and the critique made sense, but I can't
remember what it was.  I just mention it to highlight that thoughtful
and knowledgeable people can find flaws in nix's way of doing things.

What I want is a system that allows installed packages that might be
orphaned to continue functioning.  And transparent upgrades in
parallel.  The package manager could be instructed to find unused
leaves and remove them, or to remove older versions of libraries or
applications.  No more releases, just a continuous process of upgrade,
with rollback capability.

If someone releases a newer version of a package that other packages
depend on, it installs without demur, and as those packages are
upgraded, they install quietly, and their old versions are removed.
When the old package has no more references to it, it is garbage
collected.

Security issues?  For sure.  But I think they could be managed.  In
return, that file viewer you loved from three releases ago, that is no
longer in the repositories, still functions, with all its warts and
features and security holes.

Not an expert, so maybe this is completely flawed and unworkable in the
real world.