On 09/20/2016 05: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.
> 1) Dealing with compressed data is definitely slower than dealing with
> uncompressed data, and this is valid both for startup time and runtime.

Squashfs is actually very fast at read operations, it trades off a
slower compression time for a faster decompression time. It's been used
for years in Ubuntu Live CD/DVD images, and the compression algorithm is
also used in AppImage (and I think FlatPak).

> 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.

It's possible for snaps to share content with each other, but currently
only if both snaps are from the same developer. You will usually be
bundling your own copies of dependencies though. But, as previous
stated, that's more of a problem for desktop apps than services, and
combined with the squashfs compression doesn't have that much of an
impact on disk space used.

> 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 :-)

Was it running? I installed the Notes app and launched it, after that I
could see "Notes" in ps. Snap processes are run just like any other
process on your machine, they are not hidden or obfuscated in any way.
If it's not a daemon then it's not started automatically when you
install it.

snapd is just the management daemon, it handles snap package management
asynchronously and has an API you can call to interact with it
programatically. But individual snap applications are not run as
children of snapd.

> 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.
>> -chris

Michael Hall

To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to