Martin, On 9/20/16 5:44 PM, Martin Grigorov wrote: > Hi Chris, > > On Tue, Sep 20, 2016 at 10:51 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> Martin, >> >> On 9/20/16 3:28 PM, Martin Grigorov wrote: >>> Hi Michael, >>> >>> On Tue, Sep 20, 2016 at 9:11 PM, Michael Hall <mhall...@gmail.com> >> wrote: >>> >>>> Hi Martin, >>>> >>>> >>>> On 09/20/2016 02:56 PM, Martin Grigorov wrote: >>>>> Hi Michael, >>>>> >>>>> On Tue, Sep 20, 2016 at 3:10 PM, Michael Hall <mhall...@gmail.com> >>>> wrote: >>>>> >>>>>> Hi Coty, >>>>>> >>>>>> Have you had an opportunity to try this yet? If you need help please >> let >>>>>> me know, or you could find help on #snappy on Freenode or >>>>>> https://gitter.im/ubuntu/snappy-playpen (a new slack-like service >>>>>> connected to github) >>>>>> >>>>> >>>>> I am an Ubuntu user and I've tried once Snap. >>>>> I've installed the featured Notes application and I was amazed to see >>>> that >>>>> it downloaded 60Mb for such a simple application! After being unzipped >> it >>>>> is 196MB !! >>>>> Then I removed it. >>>>> I hope Canonical will keep .deb around for the near future! >>>>> >>>> >>>> .deb package aren't going away, snaps are just a new option that bring a >>>> >>> >>> Yes, I know that .deb isn't going away. >>> I just said it to express my frustration with those 196MB. >>> >>> >>>> lot of benefit. Desktop apps like Notes are currently quite large >>>> because they bundle the whole GUI toolkit that they use. This is >>>> something that has a solution underway, but it won't affect services >>>> like tomcat nearly as much, >>>> >>>> The Tomcat snap does include a JRE though, so you always know that one >>>> is available and that Tomcat will work with it. Even with that the >>>> >>> >>> What if I need different combination of Tomcat and JRE versions than what >>> your Snap versions provide ? >>> Let's say I experience some bug in the bundled JRE version (e.g. X) and >>> your next Snap version bundles JRE X+1 but also Tomcat Y+1. >>> What if I need JRE X+1 and Tomcat Y because there is a regression in Y+1 >> ? >>> Just thinking loud here. >>> >>> >>>> resulting snap is only 48MB. Snaps are never "unzipped", instead they >>>> are loop-mounted into your filesystem, so the download size is the >>>> >>> >>> I haven't read about squashfs, so I'm not sure how exactly it works. >>> 196MB is what "du" program reports. >>> If it is not disk size then I hope this 60MB download is not unzipped in >>> the RAM. >>> http://snapcraft.io/ says "That directory will be compressed into a >>> squashfs - a zipped directory - and then it will be mounted at >>> /snap/<name>/current when the snap is installed." >> >> It's like an executable JAR file, except that the kernel loads the thing >> as a filesystem. So 'du' will tell you it's bigger than it actually is >> (it's bigger on the inside than it is on the outside). > > >> That 60MiB download isn't being uncompressed elsewhere on the disk or >> into RAM. It's being decompressed on the fly as necessary, just like a >> remotely-mounted filesystem isn't copied locally whenever you access >> files. Sore, a file or two might have some parts cached locally, but you >> aren't sucking-down your entire multi-petabyte SAN contents when you >> login to your corporate network. >> > > Thanks for the explanation! > But I think the example with reading data from SAN is not exactly the same > as executing a process in the kernel. > To start the process the kernel needs to load (big?!) part of the zipped > bundle. Everything else might be loaded if needed later.
ZIP files store their catalog at the end of the file, and most
filesystems store their catalogs at the beginning of the "file". Both
have a structure which describes the file names and where the data can
be found. I think it's a reasonable analogy.
> 1) Dealing with compressed data is definitely slower than dealing with
> uncompressed data, and this is valid both for startup time and runtime.
Agreed. I was using the SAN as an example of something that "takes time"
much in the same way as reading from a ZIP file "takes time". Of course,
for the SAN example, the CPU isn't doing any work waiting for the data
to become available while in the ZIP case it's being used to decompress
the content.
> 2) Snaps share nothing, by design. So if more than one app needs the same
> dependency then it is not just about the disk space but also duplicated
> stuff in memory.
Possibly. I know that VM hypervisors perform page-merging but I have no
idea if "normal" OSs do that. It's possible that loading libcrypt in 10
processes only gets you a single copy of libcrypt in memory, even if
they were loaded from separate Snaps. (Same versions of libcrypt, of
course.)
> This is advertized as Pros but for me is Cons.
Meh. This solves a particular problem and the use case is valid. If you
can do everything without Snaps (e.g. a typical server configuration)
then go for it. If Snaps solve a problem for you ("DLL hell") then use
that instead.
> 3) I cannot find any information about a running Notes app (I've installed
> it again for the testing!) neither with 'ps', nor with 'htop', nor with
> 'snap'. All I can find is a parent 'snapd' process with several forks. If I
> need to install a spy software I'll pack it as a Snap :-)
Try lsof and grep for the loopback-mounted filesystem prefix. 'mount'
ought to show you the loopback-mounted fs and you can see where it's
been mounted.
> So far I see more drawbacks than benefits. But I am a developer with a
> desktop. I guess the points above might not be a problem for server
> administrators.
No, I think Snaps are pretty much worthless for server admins, which is
why I'm skeptical about the usefulness of packaging Apache Tomcat as a Snap.
-chris
signature.asc
Description: OpenPGP digital signature
