1 |
On Thursday 16 Jun 2016 21:25:01 J. García wrote: |
2 |
> El jue, 16-06-2016 a las 19:40 -0400, José Maldonado escribió: |
3 |
> > That is possible, but the goal is to serve Snap container for |
4 |
> > applications that can be downloaded and used by the user, down a |
5 |
> > single |
6 |
> > binary that will have all the dependencies in that binary. Docker and |
7 |
> > LXC obviously can do this, but its scope and possibilities are much |
8 |
> > larger and are not addressed within the scope of normal user of a PC. |
9 |
> > |
10 |
> > |
11 |
> |
12 |
> Docker doesn't get the applications down to a single binary, it's a |
13 |
> package containing everything. A single binary would be something like |
14 |
> what Go does by default, as it compiles every source package imported |
15 |
> into the final binary, that's why even a "hello world" takes ~2MB. |
16 |
> |
17 |
> > |
18 |
> > |
19 |
> > > |
20 |
> > > |
21 |
> > > [AFAIK, Flatpak's for GUI apps accessed via Gnome Software so it's |
22 |
> > > not |
23 |
> > > quite a Snap competitor.] |
24 |
> > > |
25 |
> > > |
26 |
> |
27 |
> They say it's not a GNOME thing only, but born in the GNOME project, |
28 |
> Quote from their FAQ: |
29 |
> |
30 |
> "Is Flatpak tied to GNOME? |
31 |
> |
32 |
> No. While Flatpak has been developed by people with a long involvement |
33 |
> in the GNOME community it is not tied to any desktop. In fact, it was |
34 |
> designed with the explicit goal of allowing it to build applications |
35 |
> using any library stack or programming language an application author |
36 |
> might want." |
37 |
> |
38 |
> I would say is the implementation of something that Lennart P. wrote in |
39 |
> his blog a while back[1](I don't know to what extent is 'his' idea, or |
40 |
> if it just happens that he wrote about it after discussing it with |
41 |
> others), but it seems that he didn't write code for it(I looked at the |
42 |
> contributors in GitHub) |
43 |
> |
44 |
> > Flatpak and Snap, have GUI and command-line. In addition, Flatpak |
45 |
> > packages weigh less than their counterparts Snap, and right now |
46 |
> > several |
47 |
> > free software projects officially support it, including LibreOffice. |
48 |
> > |
49 |
> > |
50 |
> |
51 |
> The flatpak packages take less space because there's a separation |
52 |
> between runtimes and applications, with the runtime(s) containing many |
53 |
> of the libraries/packages required by an application, and intended to |
54 |
> be used by many of these, and the application package only containing |
55 |
> the remaining required libraries, or maybe only the app, so it could |
56 |
> reduce but not eliminate the problem previously discussed of |
57 |
> dependencies being left unmaintained and not upgraded with security |
58 |
> fixes. IMHO Flatpak seems a better option than Snap, and certainly |
59 |
> reducing file system and device access is a good thing about both, but |
60 |
> with these advantages some other problems are created, so it's a trade- |
61 |
> off. |
62 |
> As Andrew Savchenko said previously Snap seems like C:\Program Files |
63 |
> for Linux, but I would add 'with sandboxing' and other security |
64 |
> features, and that certainly makes it better than than Windows to be |
65 |
> fair. |
66 |
> Maybe we will see Snaps/Flatpaks of popular proprietary software that's |
67 |
> only available for Windows and MacOS right now that has no real FOSS |
68 |
> competitor e.g. AutoCAD and family, I often hear the excuse of these |
69 |
> vendors not supporting Linux because of the many distributions. Getting |
70 |
> LibreCAD to the level of AutoCAD would take a decade or more at the |
71 |
> pace it is going, right know it reminds me of AutoCAD 2004, and it |
72 |
> isn't even a that level. Trying to be optimistic maybe we'll see a new |
73 |
> wave of users in Linux as a result of these new packaging systems, and |
74 |
> in the long run if the GNU/Linux user base grows and learns about the |
75 |
> Free Software philosophy and get tired of having to pay large sums of |
76 |
> money to Autodesk and other companies for a yearly permission to use |
77 |
> their software, they would contribute to the FOSS alternatives with |
78 |
> money to get people working full time on these, and we could see them |
79 |
> grow to be real competitors. |
80 |
> That said I hope upstreams don't start bundling libraries into their |
81 |
> software as a result of this(at least not more than some already do |
82 |
> now), that's really annoying and it could create a nightmare of the |
83 |
> likes of java(I mean most java developers seemingly putting every jar |
84 |
> they come across in their 'source' trees and then forget about it for |
85 |
> the rest of their lifes, or at least until Oracle breaks them, after |
86 |
> years and years of deprecation). |
87 |
> |
88 |
> [1] http://0pointer.net/blog/revisiting-how-we-put-together-linux-syste |
89 |
> ms.html |
90 |
> |
91 |
|
92 |
How does Nix compare to flatpack, docker, snap, et al. from a gentoo |
93 |
perspective? |
94 |
|
95 |
https://nixos.org/nix/about.html |
96 |
|
97 |
-- |
98 |
Regards, |
99 |
Mick |