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
