Another one on the list is containers, and I did a bit of reading during 2016, wasn't impressed. A Docker container has an absolute minimum size of 3.6MB. I saw one post where the person was proud that he had reduced the size of his Docker container to 25MB.
This idea of putting everything into a container, is so wasteful, and contrary to our Puppy philosophy.
It is all very well that these days we have heaps of storage, but with containers it is very easy to use it up. I am thinking of Quirky running on a Flash stick. Ideally, I would like Quirky to run happily on a 4GB stick.
I was trying to think how containers can be implemented efficiently, and thought, why not use an overlay filesystem, such as overlayfs or aufs? This is Puppy's home turf! This seems like a very good idea, and so I expected the same idea will have occurred to many other people -- which it has, lots of posts, including using overlayfs for Docker.
Firstly though, what is a container? A filesystem that you can chroot into is a container. An environment that you can run an application with isolation from the rest of the system, is a container. The basic requirement is to provide security, such as prevent a rogue app from getting out, or an outside intrusion from getting out.
Containers go some steps beyond the basic chroot, with extra levels of isolation.
This idea of using overlayfs. Instead of copying everything, libraries, etc., into a container, mount it as an overlayfs, with the read-only system as an SFS file underneath. This SFS file can be shared by all containers. This is extremely space efficient, but it also solves some implementation problems, for example as described here:
Right now, I am just reading and learning more. Nowhere near formulating what the proposed "next gen" Quirky will look like.
Currently studying this, a simple implementation of containers, very interesting:
Comments:Firejail Posted on 23 Jan 2017, 14:57 by admin
This is a very interesting simple way of running an application in a container:
First off, I tried something simple:
# firejail seamonkey
At first it failed, I had to create /home folder in my host system, and had to remove the "noroot" line from /etc/firejail/seamonkey.profile.
SeaMonkey started up, I then chose "File -> Open" in the menu, and SeaMonkey immediately crashed. Not a good start, considering that SeaMonkey is one of the officially supported applications.
What really attracted my attention though, is the ability of Firejail to use an existing root filesystem, such as an overlay f.s. that I have setup, by means of the "--chroot" option. Firejail also has the "--overlay" option, where it will create a tmpfs on top of the current f.s. and use that.
The default behaviour, as per my above experiment, is to create a root f.s. on-the-fly, I presume by copying heaps of files from the host system -- it works fast though, so maybe it is done some other way, such as by hardlinks.
I setup a simple overlayfs, using "q.sfs", which is the Quirky filesystem as used in the live-CD, a rw folder on top of that, then created an overlay f.s.:
# mount -t squashfs -o loop,noatime q.sfs q_ro/ro1
# mount -t overlay -o lowerdir=q_ro/ro1,upperdir=q_rw/rw1,workdir=q_rw/work1 overlay q_top1
Inside q_top1, I created /home, and changed /var and /run from symlinks to actual folders, and created /var/cache, /var/lock, /var/log, /var/run and /var/tmp inside q_top1.
Then had a go:
# firejail --chroot=`pwd`/q_top1 seamonkey
...lots of error messages, but SM did start. I quit SM, ran the above again, this time SM reported that it had crashed at startup. OK, there are details to sort out here!
I also tried this:
# firejail --overlay seamonkey
...but it doesn't like /var and /run being symlinks into /tmp. Well, that's the way I have Quirky setup. Perhaps it would be interesting to make them into normal folders and see if Firejail will succeed.