On Tue, Sep 20, 2016 at 10:51 PM, Christopher Schultz <
> 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>
> >> 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
> >>>> 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
> >>> 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.
1) Dealing with compressed data is definitely slower than dealing with
uncompressed data, and this is valid both for startup time and runtime.
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. This is advertized as Pros but for me is Cons.
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 :-)
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