Re: [gentoo-user] Re: Gentoo is supporting officially Snap packages?

[J.]

El jue, 16-06-2016 a las 19:40 -0400, José Maldonado escribió:
> That is possible, but the goal is to serve Snap container for
> applications that can be downloaded and used by the user, down a
> single
> binary that will have all the dependencies in that binary. Docker and
> LXC obviously can do this, but its scope and possibilities are much
> larger and are not addressed within the scope of normal user of a PC.
> 
Docker doesn't get the applications down to a single binary, it's a
package containing everything. A single binary would be something like
what Go does by default, as it compiles every source package imported
into the final binary, that's why even a "hello world" takes ~2MB.

> 
> > 
> > [AFAIK, Flatpak's for GUI apps accessed via Gnome Software so it's
> > not
> > quite a Snap competitor.]
> > 
They say it's not a GNOME thing only, but born in the GNOME project,
Quote from their FAQ:

"Is Flatpak tied to GNOME?

No. While Flatpak has been developed by people with a long involvement
in the GNOME community it is not tied to any desktop. In fact, it was
designed with the explicit goal of allowing it to build applications
using any library stack or programming language an application author
might want."

I would say is the implementation of something that Lennart P. wrote in
his blog a while back[1](I don't know to what extent is 'his' idea, or
if it just happens that he wrote about it after discussing it with
others), but it seems that he didn't write code for it(I looked at the
contributors in GitHub)


> Flatpak and Snap, have GUI and command-line. In addition, Flatpak
> packages weigh less than their counterparts Snap, and right now
> several
> free software projects officially support it, including LibreOffice.
> 
The flatpak packages take less space because there's a separation
between runtimes and applications, with the runtime(s) containing many
of the libraries/packages required by an application, and intended to
be used by many of these, and the application package only containing
the remaining required libraries, or maybe only the app, so it could
reduce but not eliminate the problem previously discussed of
dependencies being left unmaintained and not upgraded with security
fixes. IMHO Flatpak seems a better option than Snap, and certainly
reducing file system and device access is a good thing about both, but
with these advantages some other problems are created, so it's a trade-
off.
As Andrew Savchenko said previously Snap seems like C:\Program Files
for Linux, but I would add 'with sandboxing' and other security
features, and that certainly makes it better than than Windows to be
fair.
Maybe we will see Snaps/Flatpaks of popular proprietary software that's
only available for Windows and MacOS right now that has no real FOSS
competitor e.g. AutoCAD and family, I often hear the excuse of these
vendors not supporting Linux because of the many distributions. Getting
LibreCAD to the level of AutoCAD would take a decade or more at the
pace it is going, right know it reminds me of AutoCAD 2004, and it
isn't even a that level. Trying to be optimistic maybe we'll see a new
wave of users in Linux as a result of these new packaging systems, and
in the long run if the GNU/Linux user base grows and learns about the
Free Software philosophy and get tired of having to pay large sums of
money to Autodesk and other companies for a yearly permission to use
their software, they would contribute to the FOSS alternatives with
money to get people working full time on these, and we could see them
grow to be real competitors.
That said I hope upstreams don't start bundling libraries into their
software as a result of this(at least not more than some already do
now), that's really annoying and it could create a nightmare of the
likes of java(I mean most java developers seemingly putting every jar
they come across in their 'source' trees and then forget about it for
the rest of their lifes, or at least until Oracle breaks them, after
years and years of deprecation).

[1] http://0pointer.net/blog/revisiting-how-we-put-together-linux-syste
ms.html