easy logo How Easy works

Partially updated: May 29, 2017
Easy is a "new paradigm" for a Linux distribution, a blend of the best ideas from Puppy and Quirky, and a fundamental rethink of the security, maintainability and ease-of-use.

A good way to explain what Easy Linux is all about, is to follow the user (that's you) experience, from downloading the deployed file, to installing and discovering it's features. To start, you would go to one of the websites hosting Easy Linux and download it...

Download

Unlike most other Linux distributions, Easy is not deployed as an image for a CD disk (ISO file). Instead, Easy is an image for an external drive, such as USB Flash stick, SD-card or USB solid state disk (SSD).

One might immediately counter that ISO files can also be written to Flash media -- yes, but that is not an installation -- the distribution still has to be installed somewhere. With Easy, what is written to the Flash media is the installation, nothing more to be done. You can run Easy from the external media indefinitely, but there is also the option of installing to internal drive.

The file you download is named easy-<version>-<architecture>.img.gz, for example easy-0.1.6-amd64.img.gz. The ".gz" on the end means that it is gzip compressed, and with Puppy (and derivatives), if you click on it, there will be an offer to uncompress it. With many other distributions, you have to open a terminal and do it manually:

# gunzip easy-0.1.6-amd64.img.gz

Having done so, you will have easy-0.1.6-amd64.img:
easy-image

...the above snapshot is a ROX-Filer file manager window in Easy Linux.

Installation
This web page is describing how Easy works, not installation. There will be a separate page for that, however, it can be mentioned here how easy it is. Just install one of the free GUI tools for writing an image file to a drive, such as USB Image Tool for Windows, or Etch for Windows, Mac and Linux. Or, in Linux it is easy to do on the commandline (for the example of the external drive being /dev/sdb):
# gunzip --stdout easy-0.1.6-amd64.img.gz | dd of=/dev/sdb bs=1M
# sync

The file easy-0.1.6-amd64.img is an image file, that can be written to any drive. Although it is only 521MB, at first bootup it will expand to use the entire drive. So any drive, from 2GB upwards, is suitable (although at least 8GB is recommended for ongoing usage).

Internally, the file contains a 519MB fat32 partition. If you are already running Easy Linux, you can just click on this file to open it up and see inside. With other Linux distributions, you have to do it from the commandline:

# mkdir mntpt
# mount -t vfat -o loop,offset=1048576 easy-0.1.6-amd64.img mntpt

The fat32 partition actually starts 1MB into the file (which is 1048576 bytes), the first 1MB has partition table and other stuff.

With Easy, being easy, you just click on the file, and you can see what is in the vfat partition:
easy-image-opened


You should immediately recognise one file in there, vmlinuz, which is the Linux kernel. The image file has Syslinux installed in it, which is a boot manager. The files boot.msg, help.msg, ldlinux.sys, logo.16, syslinux.cfg, and more in the EFI folder, are part of Syslinux.

Once written to a drive, Easy will boot up on any desktop PC or laptop with x86 64-bit CPU, older pre-2012 PCs with traditional BIOS-firmware, and modern PCs with UEFI-firmware. If you don't understand what BIOS or UEFI mean, don't worry.

q.sfs

This is an approximately 380MB file that contains all of Easy Linux. It is the entire filesystem, which basically means that it has all of the applications, utilities, data and documentation. It packs a lot into a small space -- for example, Easy includes the SeaMonkey browser suite (based on Firefox, but also has WYSIWYG HTML editor, chat, addressbook, mail & newsgroups), and the Libreoffice suite. It also includes drivers for most hardware, such as network, printing, scanning, cameras.

Technical note: File q.sfs is what is called a squashfs filesystem. It is compressed, with xz compression.

initrd.q

This is a startup filesystem. At bootup, the Linux kernel loads this into RAM and it does various setup operations, before switching over to using q.sfs.
Being a bit more specific, after loading initrd.q, the kernel runs a file inside it called init.

This init is of great interest to us, it shows how Easy is structured at the nuts-and-bolts level.

With Easy, once again, being easy, just click on initrd.q and it will open up and you can see what is in it. And, if you fancy getting into modifying Easy, you can make changes and save it back to initrd.q (popup messages will explain how), and your change will be back in the original easy-0.1.6-amd64.img -- and hey, you have customised Easy! And yes, the same can be done to q.sfs.

Alright, click on initrd.q, and this is what we see:
initrd-q-opened

...it is a tiny Linux filesystem, just enough to boot up on. Some technical notes: The file initrd.q is only 3.2MB and contains static utilities (utilities that do not need shared library files to run), it is not compressed. It is a cpio filesystem.

init script

One way to explain what init does is to insert the code into this web-page, along with explanation of each segment. If you are not familiar with Linux shell scripts, no problem, the accompanying explanation is sufficient. If you do have such knowledge, you can see what is happening in more depth.

Here is the first segment of the script. It is just some setting-up stuff. If it is gobbledy-gook to you, no problem:

#!/bin/sh
#(c) Copyright Barry Kauler, 30 January 2017. Licence: GPL v3 (/usr/share/doc/legal).
#simple script in initramfs to boot Easy Linux.
#deloyed as a drive image, with one 519MB fat32 partition, containing vmlinuz, initrd.q, q.sfs
#text colors: 34=blue, 33=yellow, 32=green, 31=red, 35=purple, 36=aquablue, 38=black

export TEXTDOMAIN=easyinitrd
export OUTPUT_CHARSET=UTF-8
mount -t proc none /proc
mount -t sysfs none /sys
mount -t rootfs -o remount,rw rootfs /
ln -s /proc/mounts /etc/mtab 2> /dev/null
export PATH="/bin:/sbin"

err_exit() {
 echo -e "\\033[1;31mERROR: ${1}\\033[0;39m" #red
 echo 'Have now dropped into a shell in the initramfs.'
 echo 'Note1: Type "exit", the init script will attempt to continue, however,'
 echo '       only an expert who is debugging the bootup should do this.'
 echo 'Note2: On some PCs the keyboard does not work at this stage of bootup.'
 echo 'PLEASE HOLD DOWN THE POWER BUTTON TO SHUTDOWN'
 /bin/sh
}

#170206 reintroducing aufs in the kernel:
if grep -qw aufs /proc/filesystems; then
 LAYERFS='aufs'
 RO='=ro'
else
 LAYERFS='overlay'
 RO=''
fi

There is one important point that can be extracted from the above code: aufs and overlay.

The fundamental basis of how Easy works is based on a layered filesystem, of which aufs and overlay are two implementations. The use of a layered filesystem goes back to Puppy Linux, in fact, in Puppy the layered f.s. is also the core feature of Puppy.

Easy uses the layered f.s. somewhat differently from Puppy. But first, just what is a layered f.s.?

Layered filesystem

This picture illustrates the basic principle:

layered-fs

There need to be at least two layers, one read-write (rw) and one read-only (ro). With the overlay implementation, there can only be one rw layer, but many ro layers -- aufs is a bit more flexible.

The basic idea is that whatever is on the rw layer takes precedence. For example, if there is /usr/bin/afile on both layers, only the one on the rw layer will be seen. If there is no /usr/bin/afile on the rw layer, then the one on the ro layer will be seen.

Files can also be deleted and renamed on the rw layer. Special files are created on the rw layer. For example, /usr/bin/afile is changed to /usr/bin/afile2.

What you see as the user, is the top, which may be the / folder.


File q.sfs is compressed and stays compressed. When mounted as a ro layer though, all of its files are accessed as a normal filesystem. All changes will only occur on the rw layer.

In Easy, the rw layer is just a folder. Everything that you do will be in here: network setup, installed packages, whatever. As it is just a folder in the drive, the storage capacity is limited only by the size of the drive.
I mention this point because Puppy Linux has the concept of a "save file", where the rw layer is a file, of a certain size, which does become a problem for users, when they run out of space in that file, then have to make it bigger.
Easy avoids that complication entirely.

Well, a few technical notes about the Puppy "save file", for those with Puppy experience. The main advantage of having a save-file is that it can be in a non-Linux partition, such as fat or ntfs. Some Puppy users do what is called a "frugal install" into a fat or ntfs partition where they have Windows installed. Easy requires a partition with a Linux filesystem. Incidentally, Easy is also capable of a frugal install.

Continuing with the init script, the next thing it does is locate the drive that it has booted off. It may seem odd that the script has to search for it, given that vmlinuz and initrd.q have already been read from it. But that happens prior to the Linux kernel running, and the kernel has to identify the drives in the PC and assign drive-names to them.

Finding the boot partition

Here is the next segment of code:

###find drives###
#find the drive we are booting on (has vmlinuz, initrd.q, q.sfs), and working drv...
. /BOOT_SPECS #has BOOT_DISKID, BOOT_PARTNUM, BOOT_FS, BOOT_DIR, WKG_DISKID, WKG_PARTNUM, WKG_FS, WKG_DIR, Q_DISTRO_VERSION
echo -n -e "\\033[1;35mSearching drives:\\033[0;39m\n " #purple
CNT=0; Pb=''; Pw=''; BOOT_DRV=''; WKG_DRV=''
while [ $CNT -lt 8 ];do #drives may take couple seconds to become available.
 sleep 1
 CNT=$(($CNT+1))
 for aDRV in /sys/block/sd[a-z] /sys/block/mmcblk[0-9]
 do
  DRV=${aDRV:11:7} #extract drv from /sys/block/<drv>
  echo -n " ${DRV}"
  fdisk -l /dev/${DRV} > diskinfo-${DRV} 2>/dev/null
  if grep "$BOOT_DISKID" diskinfo-${DRV} >/dev/null;then BOOT_DRV="$DRV"; fi
  if grep "$WKG_DISKID" diskinfo-${DRV} >/dev/null;then WKG_DRV="$DRV"; fi
  [ "$BOOT_DRV" -a "$WKG_DRV" ] && break 2
 done
done
[ ! "$BOOT_DRV" ] && err_exit 'Boot drive not found'
[ ! "$WKG_DRV" ] && err_exit 'Working drive not found'
[ "${BOOT_DRV:0:3}" == "mmc" ] && Pb='p'
[ "${WKG_DRV:0:3}" == "mmc" ] && Pw='p'
BOOT_DEV="${BOOT_DRV}${Pb}${BOOT_PARTNUM}"
WKG_DEV="${WKG_DRV}${Pw}${WKG_PARTNUM}"
echo -e "\n  Boot-partition: ${BOOT_DEV}, working-partition: ${WKG_DEV}"
mkdir -p /mnt/${BOOT_DEV}
mkdir -p /mnt/${WKG_DEV}

The key to identification of the boot partition is the file BOOT_SPECS, which is inside initrd.q. Essentially, what the above code does is read BOOT_SPECS and from that identify where Easy is installed. Here is the content of the file:

BOOT_DISKID='694ED775-12F8-4969-9FEA-30189D251140'
BOOT_PARTNUM=1
BOOT_FS='vfat'
BOOT_DIR=''
WKG_DISKID='694ED775-12F8-4969-9FEA-30189D251140'
WKG_PARTNUM=2
WKG_FS='ext4'
WKG_DIR=''
Q_DISTRO_VERSION=0.1.6

The disk ID is a unique identifier of the drive. The script scans the drives looking for this identifier. This is very fast. The reason that there is a waiting loop, is that the kernel needs two or three seconds to identify the drives and assign the drive names.

Puppy Linux users will be familiar with the search for installed files at bootup. With the Puppy live-CD for example all partitions are searched for the session save-file. This takes time. Easy does not do any searching, as the the partitions are hard-coded into initrd.q, file BOOT_SPECS.

Note also, the "BOOT_*" and "WKG_*" variables. Boot and working drives and partitions may be different, or not. Also, there are optional folders that Easy may be installed in.

The above BOOT_SPECS is for the image file that you download, easy-0.1.6-amd64.img.gz. As mentioned before, this image only has one partition, fat32, 519MB.
The working partition is where you will be after bootup, and this is created on-the-fly at first bootup, to fill the drive. This is partition number 2, and is (or rather will be) an ext4 filesystem.

The essence of the above is extreme flexibility. By putting appropriate entries into BOOT_SPECS, Easy can be installed anywhere.

Performance measurements

The init script needs to make decisions based on the amount of RAM and read-speed of the working drive. This is the next segment of code:

###performance measurements###
FREEK=`grep '^MemFree:' /proc/meminfo | tr -s ' ' | cut -f 2 -d ' '` #free RAM
#echo 3 > /proc/sys/vm/drop_caches #clear memory caches. note, could use "hdparm -t ..." but it is slower.
TIMEs="$(dd if=/dev/${WKG_DRV} of=/dev/null skip=524288 bs=1024 count=1 2>&1 | grep -o '[0-9.]* seconds,' | cut -f 1 -d ' ')" #read speed.
TIME10k=$(dc ${TIMEs} 10000 mul p | cut -f 1 -d '.') #cheap usb3 flash stick: 15, internal eMMC: 47

Moving on, at first bootup, the second (working) partition does not exist, so has to be created...

Create the working partition

The init script now has to create the working partition, if it does not exist, which is the case with our easy-0.1.6-amd64.img.gz file, then mount it and perform some initializations. Here is the code:

###[create and] mount working partition###
if ! grep " ${WKG_DEV}$" /proc/partitions >/dev/null;then
 echo -e "\\033[1;35mCreating ${WKG_FS} partition ${WKG_DEV} to fill drive\\033[0;39m" #purple
 echo -e "n\n${WKG_PARTNUM}\n\n\nw" | fdisk -u /dev/$WKG_DRV > err.log 2>&1
 sync
 if grep -i 'failed to write disklabel' err.log;then #confused by invalid backup gpt
  echo -e "\\033[1;31mFixing secondary GPT, will take awhile\\033[0;39m" #red
  echo -e 'x\ne\nw\nY' | gdisk /dev/${WKG_DRV} > err.log2 2>&1
  sync
  echo -e "n\n${WKG_PARTNUM}\n\n\nw" | fdisk -u /dev/${WKG_DRV} > err.log3 2>&1
  sync
  if grep 'failed' err.log2 err.log3 ;then err_exit "Failed to create working partition ${WKG_DEV}" ; fi
  echo -e "\\033[1;32m...done, ${WKG_DEV} created, now creating ${WKG_FS} filesystem\\033[0;39m" #green
 fi
 mke2fs -q -t ${WKG_FS} -O ^has_journal -L easy2 -m 0 -b 4096 /dev/${WKG_DEV} #only supporting ext2/3/4
fi
mount -t ${WKG_FS} /dev/${WKG_DEV} /mnt/${WKG_DEV}
[ $? -ne 0 ] && err_exit "Unable to mount working-partition ${WKG_DEV}"
if [ ! -d /mnt/${WKG_DEV}/${WKG_DIR}repository ];then #populate with skeleton directory hierarchy.
 cp -a -f /skeleton/* /mnt/${WKG_DEV}/${WKG_DIR}
 cp -a -f /skeleton/.[a-z]* /mnt/${WKG_DEV}/${WKG_DIR}
fi

###set date and time###
#could read .session/etc/clock and run hwclock, but for now this probably good enough (refer: rc.shutdown)...
[ -s /mnt/${WKG_DEV}/${WKG_DIR}.session/root/.var/local/shutdown_date_saved ] && date -s "`cat /mnt/${WKG_DEV}/${WKG_DIR}.session/root/.var/local/shutdown_date_saved`" > /dev/null

###mount boot partition###
if [ "$BOOT_DEV" != "$WKG_DEV" ];then
 mount -t ${BOOT_FS} /dev/$BOOT_DEV /mnt/$BOOT_DEV
 [ $? -ne 0 ] && err_exit "Unable to mount boot-partition ${BOOT_DEV}"
fi
[ ! -f /mnt/$BOOT_DEV/${BOOT_DIR}q.sfs ] && err_exit "$(LANG=${wkgLANG} gettext 'Boot-partition does not have file q.sfs')"

This segment of code was quite tricky to implement. The problem is created by the GUID Partition Table (GPT) mechanism, which the image file has to use  to boot on modern UEFI-firmware PCs. The GPT is essentially a table specifying the partitions on the drive.
The primary GPT is located near the beginning of the drive, and a secondary, or backup, GPT at the physical end of the drive. The problem is that the Easy image file does not have a secondary GPT, being only 521MB and the drive may be 2GB or greater. if the drive has been used before, it may have a GPT at the end of the drive from previous usage, and this may confuse Linux (and the fdisk utility). it is even possible that Linux may decide the secondary GPT is the valid one!

The above code uses a special utility named gdisk, to fix this situation. It copies the primary GPT to the physical end of the drive. The script then creates partition #2, to fill the drive.
The mke2fs utility is then used to create an ext4 filesystem in the second partition.

Finally, some directories are created in the new partition. Note in particular, repository, .session, containers, and home directories.
Folder .session has already been mentioned as the rw layer of the layered filesystem -- it is preceded by a "." as that makes it invisible -- reason being that you should not directly access a layer, only from the top.

Recovery and maintenance

As the above title says, this segment of code is concerned with recovery and maintenance. Here it is:

###recovery, maintenance###
[ "$qfix" ] && QFIX=$qfix #kernel boot param
if [ "$QFIX" ];then
 for ONEFIX in `echo -n "$QFIX" | tr ',' ' '`
 do
  case $ONEFIX in
   fsck|FSCK) echo -n "${WKG_DEV},${WKG_FS},REQUEST" > /mnt/${WKG_DEV}/${WKG_DIR}.session/.fsckme.flg ;;
   back|bak|BACK|BAK) echo -n ",erase" > /mnt/${WKG_DEV}/${WKG_DIR}.session/.rollback.flg ;;
  esac
 done
fi
export wkgLANG="$(grep '^LANG=' /mnt/${WKG_DEV}/${WKG_DIR}.session/etc/profile 2>/dev/null | cut -f 2 -d '=')"
[ ! "$wkgLANG" ] && export wkgLANG=C
[ -s /mnt/${WKG_DEV}/${WKG_DIR}.session/.fsckme.flg ] && fscheck ${WKG_DRV} ${WKG_DEV} #ex: improper shutdown
[ -s /mnt/${WKG_DEV}/${WKG_DIR}.session/.rollback.flg ] && rollback ${WKG_DRV} ${WKG_DEV}

What the above code is doing, is it looks for the existence of files .fsckme.flg and .rollback.flg in the .session folder. .fsckme.flg specifies that a filesystem check is required, .rollback.flg specifies to roll back to an earlier version or snapshot of Easy (or to roll forward).

Filesystem check and rollback may also be specified on the kernel boot commandline, as "qfix=fsck" and "qfix=bak", or both as "qfix=fsck,bak". In the latter case, there are no options, it just deletes the .session folder (rw layer).

Rollback is a very powerful feature of Easy. it enables you to rollback to an earlier version of Easy, and/or to an earlier snapshot of the .session folder. Unlike Quirky Linux, that implemented this in a very slow and failure-prone way, Easy does it as an atomic operation, very fast and failure-proof.

Version control

The aforementioned rollback is part of Easy Version Control. Version control is a powerful feature of Easy. A record is kept of past versions, and snapshots or the .session folder (the rw layer) can be made at any time. Version control also extends to containers, however, let's hold off explaining that for now.

This is a big chunk of code:

###version control###
if [ ! -d /mnt/${WKG_DEV}/${WKG_DIR}repository/easy-${Q_DISTRO_VERSION} ];then
 echo -e "\\033[1;35m$(LANG=${wkgLANG} gettext 'One-time only operation, creating a snapshot of Easy Linux')\\033[0;39m"
 echo "  $(LANG=${wkgLANG} gettext 'This will allow future rollback with the Easy Version Control Manager')"
 echo "  $(LANG=${wkgLANG} gettext 'Creating:') /mnt/${WKG_DEV}/${WKG_DIR}repository/easy-${Q_DISTRO_VERSION}"
 mkdir /mnt/${WKG_DEV}/${WKG_DIR}repository/easy-${Q_DISTRO_VERSION}
 if [ -f /mnt/${WKG_DEV}/${WKG_DIR}.session/etc/DISTRO_SPECS ];then
  prevVER="$(grep '^DISTRO_VERSION=' /mnt/${WKG_DEV}/${WKG_DIR}.session/etc/DISTRO_SPECS | cut -f 2 -d '=')"
  touch /mnt/${WKG_DEV}/${WKG_DIR}.session/.delayedrun_version_upgrade #see /usr/sbin/delayedrun
 else
  prevVER=""
 fi
 echo -n '  initrd.q'; cp -f /mnt/${BOOT_DEV}/${BOOT_DIR}initrd.q /mnt/${WKG_DEV}/${WKG_DIR}repository/easy-${Q_DISTRO_VERSION}/
 echo -n ' vmlinuz'; cp -f /mnt/${BOOT_DEV}/${BOOT_DIR}vmlinuz /mnt/${WKG_DEV}/${WKG_DIR}repository/easy-${Q_DISTRO_VERSION}/
 echo -n ' q.sfs'; cp -f /mnt/${BOOT_DEV}/${BOOT_DIR}q.sfs /mnt/${WKG_DEV}/${WKG_DIR}repository/easy-${Q_DISTRO_VERSION}/
 
  if [ ! "$prevVER" ];then
   #.session folder (rw layer) is empty, but need a session.sfs anyway...
   echo -n ' session'; mksquashfs /mnt/${WKG_DEV}/${WKG_DIR}.session /mnt/${WKG_DEV}/${WKG_DIR}repository/easy-${Q_DISTRO_VERSION}/session.sfs -comp gzip >/dev/null
  else
   rm -f /mnt/${WKG_DEV}/${WKG_DIR}.session/.[a-z]* #precaution.
   #need to merge .session (rw layer) with easy-$prevVER/session.sfs, create new session.sfs...
   mkdir sro snew /mnt/${WKG_DEV}/${WKG_DIR}swork #170320
   mount -t squashfs -o loop,noatime /mnt/${WKG_DEV}/${WKG_DIR}repository/easy-${prevVER}/session.sfs sro
   if [ "$LAYERFS" == "aufs" ];then
    mount -t aufs -o br=/mnt/${WKG_DEV}/${WKG_DIR}.session=rw:sro=ro aufs snew
   else
    mount -t overlay -o lowerdir=sro,upperdir=/mnt/${WKG_DEV}/${WKG_DIR}.session,workdir=/mnt/${WKG_DEV}/${WKG_DIR}swork overlay snew
   fi
   echo -e 'dev\nmnt\nproc\nrun\nsys\ntmp\nvar\nlost+found\n.XLOADED' > exclusions1 #170525 exclusions.
   echo -n ' session'; mksquashfs snew /mnt/${WKG_DEV}/${WKG_DIR}repository/easy-${Q_DISTRO_VERSION}/session.sfs -ef exclusions1 -comp gzip >/dev/null
   sync
   umount snew
   umount sro
   rm -rf /mnt/${WKG_DEV}/${WKG_DIR}swork #170320
   rm -rf /mnt/${WKG_DEV}/${WKG_DIR}.session/*
   rm -f /mnt/${WKG_DEV}/${WKG_DIR}repository/easy-${prevVER}/session.sfs #remove session.sfs in prev. version.
  fi
 mkdir -p /mnt/${WKG_DEV}/${WKG_DIR}.session/etc
 #also save any container sessions:
 for EXE in `ls -1 /mnt/${WKG_DEV}/${WKG_DIR}containers | tr '\n' ' '`
 do
  [ ! -d /mnt/${WKG_DEV}/${WKG_DIR}containers/${EXE}/.session ] && continue
  #echo -n " ec-${EXE}"; mksquashfs /mnt/${WKG_DEV}/${WKG_DIR}containers/${EXE}/.session /mnt/${WKG_DEV}/${WKG_DIR}containers/${EXE}/rw-${prevVER}.sfs -comp gzip >/dev/null
  cp -f /mnt/${WKG_DEV}/${WKG_DIR}containers/${EXE}/configuration /mnt/${WKG_DEV}/${WKG_DIR}containers/${EXE}/configuration-${Q_DISTRO_VERSION}
 done
 echo
 touch /mnt/${WKG_DEV}/${WKG_DIR}repository/easy-${Q_DISTRO_VERSION}/configuration
 touch /mnt/${WKG_DEV}/${WKG_DIR}repository/easy-${Q_DISTRO_VERSION}/configuration-${Q_DISTRO_VERSION}
fi

Don't get bogged down in the above code. Basically, it detects a version upgrade, and saves it in the repository folder. Say we are booting up Easy version 0.1.6 for the first time. The above code will create folder repository/easy-0.1.6 and save all required files in it.

One extra thing to note, is that if there is a version upgrade to say 0.1.7, the state of the .session folder of the previous version is saved as file session.sfs in the new easy-0.1.7 folder. This session.sfs will be loaded as a ro layer, on top of q.sfs.

Dwell on this point for a moment. The rw layer of the previous version has now been frozen, as session.sfs, a ro file. Thus, we have carried over everything that you have done, all files created, installed, etc, in the last version, and the new rw layer will be now be empty.
if perhaps, you don't like what you did in the previous version, no problem, just delete that new session.sfs or move it elsewhere -- then you will be starting the new version with a clean slate.

You can see above, code for saving the rw layer of containers, but once again, will postpone further explanation.

Recompress q.sfs

The QuickSetup GUI app in Easy, has a checkbox to choose to recompress q.sfs from xz compression to gz. The reason for it being xz-compressed is that it makes for a smaller download of the image file from the Internet. However, when mounted as a ro layer, files are uncompressed on-the-fly, and this is slower than gz (gzip) compression. Hence, to get slightly faster operating speed, especially noticeable at app startup, it is a good idea to tick the checkbox. Though, the speed improvement may only be noticeable with slow CPUs. The code:

###recompress q.sfs### improve operating speed, recompress q.sfs (refer quicksetup)
if [ -s /mnt/${WKG_DEV}/${WKG_DIR}.session/.qsfs.flg ];then
 echo -e "\\033[1;35m$(LANG=${wkgLANG} gettext 'Recompressing q.sfs, xz to gz, please wait')\\033[0;39m" #purple
 mkdir /mntsfs
 mount -r -t squashfs -o loop,noatime /mnt/${WKG_DEV}/${WKG_DIR}repository/easy-${Q_DISTRO_VERSION}/q.sfs /mntsfs
 mksquashfs /mntsfs /mnt/${WKG_DEV}/${WKG_DIR}q-gz.sfs -comp gzip #>/dev/null
 sync
 umount /mntsfs
 mv -f /mnt/${WKG_DEV}/${WKG_DIR}q-gz.sfs /mnt/${WKG_DEV}/${WKG_DIR}repository/easy-${Q_DISTRO_VERSION}/q.sfs
 sync
 rm -f /mnt/${WKG_DEV}/${WKG_DIR}.session/.qsfs.flg
fi

Now to progress onto creating the layered filesystem, first, the ro layers...

q.sfs as bottom ro layer

File q.sfs, as already described, is a squashfs filesystem, with all of Easy Linux. This init script now mounts this, getting ready to mount it into the layered filesystem:

###setup bottom ro layer, with q.sfs###
echo -e "\\033[1;35m$(LANG=${wkgLANG} gettext 'Mounting read-only layer of layered filesystem')\\033[0;39m" #purple
QSFSbytes0=`stat -c %s /mnt/${WKG_DEV}/${WKG_DIR}repository/easy-${Q_DISTRO_VERSION}/q.sfs`
QSFSbytes1=$(($QSFSbytes0+500000))
mount -t tmpfs -o size=${QSFSbytes1} tmpfs /q_ro
mkdir /q_ro/q_sfs
#decide whether to copy q.sfs to RAM, or not...
CPYflg=0
[ $FREEK -gt 1100000 ] && CPYflg=1 #>1GB ram then copy
[ $TIME10k -lt 16 ] && CPYflg=0    #but fast drive so don't copy.
[ $FREEK -gt 3100000 ] && CPYflg=1 #but heaps of ram, so copy.
if [ $CPYflg -eq 0 ];then
 #do not copy q.sfs into ram, mount where it is...
 echo "  $(LANG=${wkgLANG} gettext 'Mounting squashfs file q.sfs')"
 QSFS_PATH="/mnt/${WKG_DEV}/${WKG_DIR}repository/easy-${Q_DISTRO_VERSION}/" #need this for setting up containers.
 mount -r -t squashfs -o noatime,loop /mnt/${WKG_DEV}/${WKG_DIR}repository/easy-${Q_DISTRO_VERSION}/q.sfs /q_ro/q_sfs
else
 echo "  $(LANG=${wkgLANG} gettext 'Copying q.sfs to RAM, then mounting')"
 [ ! -f /q_ro/q.sfs ] && cp -a /mnt/${WKG_DEV}/${WKG_DIR}repository/easy-${Q_DISTRO_VERSION}/q.sfs /q_ro/
 QSFS_PATH="/mnt/q_ro/" #need this for setting up containers.
 mount -r -t squashfs -o noatime,loop /q_ro/q.sfs /q_ro/q_sfs
fi
[ $? -ne 0 ] && err_exit "$(LANG=${wkgLANG} gettext 'Failed to mount q.sfs')"
cp -f /q_ro/q_sfs/etc/DISTRO_SPECS /mnt/${WKG_DEV}/${WKG_DIR}.session/etc/ #need to be sure correct one is on top.
EXTRASFS=""; sessionSFS=""
 mkdir /q_ro/session
 mount -r -t squashfs -o loop,noatime /mnt/${WKG_DEV}/${WKG_DIR}repository/easy-${Q_DISTRO_VERSION}/session.sfs /q_ro/session
 sessionSFS="/q_ro/session${RO}:"
#precaution...
. /q_ro/q_sfs/etc/DISTRO_SPECS
[ "$DISTRO_VERSION" != "$Q_DISTRO_VERSION" ] && echo -e "\\033[1;31m$(gettext 'WARNING, versions do not match.') initrd.q: ${Q_DISTRO_VERSION}, q.sfs: ${DISTRO_VERSION}\\033[0;39m" #red

So far, q.sfs and session.sfs, squashfs filesystems, have been mounted, getting ready to put them into the layered filesystem. But we are not done. There may be a need to load even more ro layers...

Extra SFS files

As with Puppy, Easy can also load extra SFS files, as ro layers. These have to be specified in a configuration file:

###load extra sfs on ro layer###
#the configuration file defines any more sfs files to load. q.sfs is always loaded
# (on bottom), and session.sfs on top of ro layers.
. /mnt/${WKG_DEV}/${WKG_DIR}repository/easy-${Q_DISTRO_VERSION}/configuration
for NUM in 4 3 2 1
do
 eval "ROsfs=\$EASY_LAYER_RO${NUM}" #implements indirection. EASY_LAYER_RO1='devx*.sfs' in configuration file, will assign 'devx*.sfs' to ROsfs. 170320 170523
 if [ "$ROsfs" ];then
  #170523 check file exists. note, may have a glob wildcard...
  FNDSFSS="$(ls -1 /mnt/${WKG_DEV}/${WKG_DIR}repository/easy-${Q_DISTRO_VERSION}/${ROsfs} | tr '\n' ' ')"
  for FNDSFS in $FNDSFSS
  do
   ANAME="$(basename $FNDSFS .sfs)"
   mkdir /q_ro/$ANAME
   echo "  $(LANG=${wkgLANG} gettext 'Mounting extra squashfs file:') ${ANAME}.sfs"
   mount -r -t squashfs -o noatime,loop /mnt/${WKG_DEV}/${WKG_DIR}repository/easy-${Q_DISTRO_VERSION}/${ANAME}.sfs /q_ro/${ANAME}
   EXTRASFS="/q_ro/${ANAME}${RO}:${EXTRASFS}" #170206
  done
 fi
done

sync
[ "$BOOT_DEV" != "$WKG_DEV" ] && umount /dev/${BOOT_DEV}

With the current code, there can be up to four extra SFS files loaded. This applies to the main Easy system, but SFS files may also be loaded in each container.

Mount the layered f.s. and switch_root

Here is the rest of the script. Basically, it creates the layered filesystem, using aufs or overlay, does some housekeeping, then performs a switch_root operation onto the top of the layered filesystem:

###the big moment, create layered f.s.###
#echo -e "\\033[1;35m$(LANG=${wkgLANG} gettext 'Creating layered filesystem, with read-write folder:') /mnt/${WKG_DEV}/.session\\033[0;39m"
echo -e "\\033[1;35m$(LANG=${wkgLANG} gettext 'Creating layered filesystem, type:') ${LAYERFS}\\033[0;39m"
if [ "$LAYERFS" == "aufs" ];then #170525
 mount -t aufs -o br=/mnt/${WKG_DEV}/${WKG_DIR}.session=rw:${sessionSFS}${EXTRASFS}/q_ro/q_sfs=ro aufs /q_new
else
 mount -t overlay -o lowerdir=${sessionSFS}${EXTRASFS}/q_ro/q_sfs,upperdir=/mnt/${WKG_DEV}/${WKG_DIR}.session,workdir=/mnt/${WKG_DEV}/${WKG_DIR}.tempwork overlay /q_new
fi
[ $? -ne 0 ] && err_exit "$(LANG=${wkgLANG} gettext 'Failed to create layered filesystem')"

#/etc/rc.d/rc.sysinit will append to PUPSTATE, get the ball rolling here...
#PUPMODE, bit-1 (partition has session), bit-2 (bottom layer is sfs) --rough equiv to puppy
echo -e "PUPMODE=6\nBOOT_DEV='${BOOT_DEV}'\nBOOT_FS='${BOOT_FS}'\nBOOT_DIR='${BOOT_DIR}'\nWKG_DEV='${WKG_DEV}'\nWKG_FS='${WKG_FS}'\nWKG_DIR='${WKG_DIR}'\nQSFS_PATH='${QSFS_PATH}'" > /q_new/etc/rc.d/PUPSTATE

###relocate mount-points prior to switch_root###
echo -e "\\033[1;35m$(LANG=${wkgLANG} gettext 'Performing a switch_root onto the layered filesystem')\\033[0;39m" #purple
#move the mount points...
[ ! -d /q_new/mnt/q_ro ] && mkdir /q_new/mnt/q_ro
[ ! -d /q_new/mnt/${WKG_DEV} ] && mkdir /q_new/mnt/${WKG_DEV}
[ ! -d /q_new/mnt/${BOOT_DEV} ] && mkdir /q_new/mnt/${BOOT_DEV}
mount -o move /q_ro /q_new/mnt/q_ro
mount -o move /mnt/${WKG_DEV} /q_new/mnt/${WKG_DEV}

mount -t devtmpfs devtmpfs /q_new/dev #need to do this before switch_root.
sync
umount /sys
umount /proc
exec switch_root /q_new /sbin/init

###END###

Some very interesting things are happening in this segment of code. Take a close look at the mounting of the layered filesystem, using overlay:

 mount -t overlay -o lowerdir=/q_ro/session:${EXTRASFS}/q_ro/q_sfs,\
   upperdir=/mnt/${WKG_DEV}/${WKG_DIR}.session,\
   workdir=/mnt/${WKG_DEV}/${WKG_DIR}.tempwork overlay /q_new 

ro layers

This can specify multiple read-only layers, delimited by ":". Each layer is a folder, and in our case there are SFS files mounted on those folders. The folder on the left is on top, which has session.sfs, and the folder on the right is at the bottom layer and it has q.sfs.

rw layer

The .session folder has the read-write layer. At the first bootup of Easy, this will have nothing in it (also session.sfs will be empty). But after switch_root, this is where all your changes will appear -- it is quite interesting to look at this folder, as long as you don't try to change it's contents while the layered filesystem is mounted.

Top of layered f.s.

the topmost folder is /q_new, and this is the user's view, where you see the end result of all those stacked layers. It is a folder at this point in the code, but by magic, switch root will transform it into "/".


Yes, there is "magic" that happens now. Filesystems that are mounted on folders in the initramfs are moved onto /q_new. For example, /q_ro actually has a tmpfs filesyestem mounted on it, and SFS files mounted in subdirectories under /q_ro -- /q_ro is moved to /q_new/mnt/q_ro.

Don't get too distracted trying to understand every step above, unless you are a scripting wiz and all of the above is obvious! The main point is that the layers are setup, and a switch_root occurs onto /q_new, which to the user suddenly becomes "/".

After the switch_root

This is a momentous occasion. Suddenly we are in the working environment. it is very much worthwhile thinking a bit more about just what has happened with this switch_root.

I mentioned the name above, "initramfs". This is the name of the filesystem in which the init script is running. As already described, the kernel loads initrd.q into RAM, and this becomes the tiny Linux filesystem, and init is run. At switch_root, all of this initramfs is deleted, as no longer needed.

Deleted, yes, but then what happens to that folder /q_new? switch_root basically performs a chroot operation onto it, then deletes all of the initramfs. Yet that /q_new survives, as "/", but it is not really anywhere, it is kind of in the void, in RAM.

A diagram might help to understand the situation, using the example of this being version 0.1.6 and the drive is /dev/sdb:
after-switch_root

It is very helpful to have an understanding of this, as after booting up Easy and you look at "/" in the file manager, you will no doubt wonder where are all those files physically located? ROX-Filer will show this:
top-of-layers

With a "normal" Linux distribution, what you see above are folders physically in a partition. However, with Easy, that "/" is a construct, the top view of those layers -- you can think of it as being somewhere in RAM.

To know where the actual files are physically located, you have to look down into the layers. The rw layer is the .session folder in the second partition (that we call the "working partition") -- in the example, it is /dev/sdb2. The session.sfs file, the top ro layer, is also in the working partition.

The bottom ro layer is file q.sfs and that may be in the working partition, or has been copied into RAM. There  is a bit of a trick here, because in the latter case, you can actually see q.sfs in /mnt/sdb2/q_ro -- just accept this for now, to avoid getting your thoughts twisted!

The working partition

Staying with the example of the drive being /dev/sdb. How do you get at those folders and files in the working partition, /dev/sdb2? Actually, it is quite simple and logical, look at /mnt/sdb2 in the file manager. or, on the desktop:
desktop-partitions

This is on my baby laptop, where /dev/sdb is a USB Flash stick that I have booted Easy off. The orange ball at top-right of the sdb2 icon identifies it as unmountable. Click on sdb1 or sdb2 and you can view the contents.

Or, in ROX-Filer, go to /mnt/sdb2 and you will be at the same place, looking at the contents of the working partition.

I need to make a comment about these boot and working partitions. The descriptions so far have been treating them as separate, which is the case with the easy-0.1.6-amd64.img.gz download file (or whatever version you download). However, bear in mind that I have designed Easy so that boot partition and working partition could be the same. in which case it would have to be a Linux partition. This will have to be a topic for another time.

So, if you click on the "sdb2" desktop icon, this is what you will see:
working-partition

I configured ROX-Filer to display hidden folders and files, so that you can see .session and .tempwork -- you can look in those folders, but don't change anything, as the aufs/overlay manager will get upset.

The three folders of interest to the user are containers, home and repository:

containers

This is where applications can be run in isolation. Each container is a layered filesystem, very similar to the main one, with ro layer q.sfs, and a rw folder. Additional SFS files may be loaded as ro layers, for example the "devx" SFS for compiling source packages (Puppy users will know all about that!). Containers serve two purposes, isolation and/or security. There is a lot more to say on this topic!

home

Easy, like Puppy, is a single-user system. With Easy, the home folder has a different meaning to that in Linux/Unix, it is, quite literally, your "home". The basic idea is that this is where you store all your "stuff". Downloaded files, photos, videos, anything. I am attempting to get the apps in Easy to open in the home folder whenever "File -> Open..." menu operation is performed, though this is a work-in-progress.
The home folder is permanent storage, it is not affected by the version control mechanisms, upgrading, downgrading, snapshots.

repository

This is a repository for Easy versions and snapshots. For example, if you upgrade from version 0.1.6 to 0.1.7, all of version 0.1.6 is saved in folder repository/easy-0.1.6, and you can at any time roll back -- the menu "Filesystem - > Easy Version Control" handles this.


I am drawing a line at this point. Now that you are in a running Easy Linux, we can explore from this new viewpoint...



Easy is now running, and the architecture can be further examined. To start, there has been the example given earlier of upgrading Easy from version 0.1.6 to 0.1.7. But, how actually do you perform an upgrade?

Upgrade to next version

I have not yet written a GUI app to download and install a new version, but it is so easy to do manually, that it is way down on my to-do list. Say that the new easy-0.1.7-amd64.img.gz is available on the Internet. Download it, click on it, and there will be an offer to uncompress, accept, and you have easy-0.1.7-amd64.img. Click on it again, and a ROX-Filer window will open showing all the contents of the 519MB fat32 partition -- see snapshot back at the start of this web page -- for convenience, reproduced here:
easy-image-opened

Now for the upgrade. Click on the desktop icon for the boot partition. In examples given earlier, that was /dev/sdb1. OK, ROX-Filer will open and this is what You will see:
boot-partition

...look familiar? Drag the new initrd.q, q.sfs and vmlinuz into the boot partition, replacing the old ones, then reboot, and that's it, you have upgraded.

it can't get any easier than that. At a reboot, the init script in the initramfs will create a new repository/easy-0.1.7 folder in the working partition, and will save all the new files (initrd.q, q.sfs and vmlinuz) into it, and perform some other upgrade operations. All automatic.

Easy Version Control

With the complete history saved in the repository folder, everything is in place for rolling back, or forward. There is even a nice GUI to do do it:
easy-version-control

If the user is currently running version 0.1.7, a rollback can be done to either a snapshot in the current version, or to  an earlier version or snapshot.

You can take a snapshot at any time. All that this does is save the current .session folder, the rw layer, as a file named rw-<date>.sfs, in the repository.

In the above example, when still running version 0.1.6, I took a snapshot at date "201702072248", that is year, month, day, hour, minute. The file rw-201702072248.sfs is saved in folder repository/easy-0.1.6.

So in the above example, there is a choice of rolling back to the pristine "Release 0.1.6", or to version 0.1.6 with snapshot "201702072248".

It should be noted that keeping all of the history, past versions, snapshots, is going to use up a lot of the drive space. Yes, but drives have been growing in size -- in the shops in Perth, Australia, I see that new stock of USB Flash drives are all 16GB. That is now the entry-level capacity.

Even so, keeping a long history will chew up a big chunk of that capacity. Or you might be using an older, smaller, memory drive. In that case, the history can be pruned. I haven't put that into the GUI, but it is easy to do manually -- just delete the history that you don't want anymore -- for example, get rid of version 0.1.6 by deleting folder repository/easy-0.1.6.

Note also, with Quirky Linux, I used xdelta3 to create difference files for older versions. This is a considerable space saving, but is very slow. So I abandoned it.

Another thing to consider, is that the user's "home" is outside of this rollback/snapshot mechanism. "/mnt/sdb2/home" (for the example of sdb2 being the working partition) is where you can keep all your personal files. Downloads, videos, photos, etc. Try and put as much as you can in here, instead of bulking up the .session folder.

repository sub-folder

All of the files belonging to a particular version of Easy are in a sub-folder inside the repository folder, for example repository/easy-0.1.7. If you were to look inside one of these sub-folders, this is indicative of what you would see:
repository-easy-version

The configuration file has variables. I will add more in time, but for now, it just specifies what extra SFS files to load at bootup.

The rw-201702172230.sfs file is a snapshot. There can be any number of these.

But what about that session.sfs? That is an interesting one. It  gets loaded at bootup at the top or the ro layers. It is the merge of the .session folder and session.sfs of the previous version.
In a nutshell, it is accumulating all of your changes, as a compressed SFS file, freezing them as a ro layer.

This picture should clarify how that session.sfs is created:
session-upgrade
A layered filesystem is created consisting of only the .session folder and the session.sfs of version 0.1.6. The top is actually the merge of the two, and this becomes the compressed ro session.sfs for version 0.1.7. And, most importantly, the .session folder is then cleared upon the upgrade to 0.1.7.

So it is an accumulative affect, as you keep upgrading. The reasons for having this session.sfs are still evolving in my mind. One reason of course, is that it has compressed all of the earlier rw changes, saving space. Another reason is a security feature, kind of locking-in, or freezing, the prior work. Another reason is that you could simply throw it away and just have a new empty session.sfs, thus getting rid of all the baggage from the past.

Easy containers

Easy has been designed as "container friendly". I thought about how containers would fit in, that is, be highly integrated with the rest of Easy, extremely easy to setup and use, and be very efficient.

There are ready-made container solutions out there, such as LXC and Docker, however, for now I am playing with "homebrew" containers. I am far from being a security or container expert, but for my own satisfaction I want to play with containers created from basic principles.

So, Easy Containers are not going to be guaranteed secure isolation, and may have other issues, but it is an on-going learning process, and hopefully they will be refined in the months ahead.
It should also be noted that one of the existing solutions such as LXC or Docker could be made to work in Easy linux.

Starting by looking at containers already created in my currently running Easy. ROX-Filer shows the containers folder in the working partition:
containers1

Burrowing down, looking inside the seamonkey folder:
containers-sm

This is a container for SeaMonkey, the web browser suite. It runs as a layered filesystem, just like the main Easy filesystem, with q.sfs on the bottom (the .ro0 folder), a read-write layer (the .session folder), and the "top" (the container folder).

But, back-tracking for a moment. How did the SeaMonkey container get created? And how to run it?
Well, I have setup Easy so that seamonkey and sh0 are pre-created, however, it is very easy to create a container for any application -- there is a nice GUI, called Easy Containers. Here is a snapshot:

ec-gui


An existing container can have its behaviour modified, or be deleted, as shown.

To create a new container, it is just a matter of selecting an app from the drop-down list, choose appropriate security options, then click the "create" button.

There is help available for making the best decisions regarding security, but also there are templates that will preset the checkboxes when you choose an app.

Technical note: these templates are located at /usr/local/easy_containers/templates

Furthermore, a new menu entry is automatically created, just like this one for SeaMonkey:
ec-menu-sm

...two SeaMonkey entries. You can choose to run it normally or in the container!

Note the special icon used to denote apps that run in a container.

There isn't anything more to say, that's it, container created and ready to use.


What actually happens if you select that containerized SeaMonkey entry in the menu, is that it executes "ec-chroot seamonkey", instead of just "seamonkey".

ec-chroot is a script, found in /usr/local/easy_containers/. In a nutshell, it will "start" the container, then chroot into it and run the app.
By "start", I mean that the layered filesystem will be setup. ec-chroot calls another script to do this, named start-container.

When the app terminates, or the container is in other ways exited, ec-chroot calls stop-container, which kills all processes running in the container and unmounts everything.

This technical description of scripts is only mentioned if you are interested. For someone who is just a user, the GUI does it all, and very simply.

A note about the efficiency of Easy Containers. There is virtually no overhead to add that SeaMonkey container. No files are duplicated. The same q.sfs is used as for the main Easy Linux.
Of course, running SeaMonkey, it will create its own cache files and so on.

The container layered filesystem

What is the point of running an app inside a container? I am thinking about the user, who isn't concerned about the technical details, just what practical benefits the container concept brings, or what problems.

Broadly, there are two reasons, one, to provide isolation from the rest of Easy Linux, and second, security. A diagram helps here, to show the filesystem you have access to while running in a container:
container-layers
The example is for the seamonkey container. q.sfs is mounted on folder .ro0 and this becomes the bottom read-only layer (also, there can be more ro layers). The folder .session is rw, and the user's view in the running container is folder container. This was already explained, however, think about it...

The app running in the container, or any file manager or terminal emulator, will only be able to see the files in folder container. Which is the content of q.sfs and any changes made on the rw layer. That's it, the rest of the system is just not there.

Yet, as folder .session is just a folder in the working partition, the entire storage area of the working partition is available. If the working partition has 14.5GB free space, that's how much free space you will have in your container.

After you exit from the container, if you want to access files created in the container, just look at /mnt/sdb2/containers/seamonkey/.session (the the example of working partition being sdb2). Or, while your container is running, /mnt/sdb2/containers/seamonkey/container.

There are security options, that will impose further restrictions on what can be done, with a view to keeping someone with ill-intent from somehow accessing outside the container. This is neat, but there is a downside. Some apps might not work, or not properly, especially as more of the security options are turned on.

Improving and customizing Easy

This is early days for Easy. It is the latest in the Quirky Linux series of experimental distributions, and a new incarnation of Quirky may not look much like previous releases. Prior to Easy, Quirky was designed as a traditional full-installation only, not using a layered filesystem, no initramfs, and special ramdisk for filesystem repair and system rollback.
Easy was a sudden idea in January 2017, a completely different approach, going back to the layered filesystem and a initramfs, and has now borne fruit.

Easy releases so far have been built with Ubuntu Xenial Xerus 16.04 binary DEB packages, however, that is incidental. The Quirky build system inherits the capability of the Woof build system in Puppy, to use the binary packages of almost any other distribution. It is really a matter of convenience: in the past, we have built puppies from packages that we compiled from source, using the T2-project, however, it is pragmatic to leaverage off the efforts of one of the major distros. In the case of Ubuntu, using their DEBs gives Easy binary compatibility with their package repositories, and we are able to install any packages from their repositories.

So, don't make the mistake of thinking that Easy (or earlier Quirkies, or Puppy) is a clone of Ubuntu. The only common factor is we are using their binary packages. That's it. In almost every respect that you can think of, Easy is different.

Anyway, this is early days for Easy, and input is most welcome. I have only just got started with containers. I have setup a very efficient infrastructure, but of course the devil is in the details. If you would like to look into improving containers, getting apps to run, improving security, etc., go for it!

One thing to note about Easy is that it inherits the run-as-root-only from Puppy. Instead, there is a different approach, to run specific Internet apps as user "spot". So, the user, you, remain always as the root-user, or administrator. You can find some documentation that justifies this locally here:
About root, spot and fido

With containers, the situation changes somewhat. Perhaps spot has become redundant. Running as "root" inside a container, with user namespace isolated from the main system, would seem to be OK.

If you are not a developer or into coding, but a user with an interest in customizing Easy, there are tools that can make this a lot of fun.
As has already been explained on this web page, just by clicking on the downloaded Easy image file, for example file easy-0.1.7-amd64.img.gz, you can open it up and see the files inside (similarly, you click on the file to close it up again).

Inside the image file, a most important file is q.sfs, which has the entire Easy Linux filesystem, from "/" down. Well, there are GUI tools to create your own q.sfs, and just replace the old one, then close up the image file, and you have a customized Easy! Sometimes this is referred to as remastering, though that term really applies to optical media.

If you would like to explore remastering, look at a couple of tools in the Setup menu:
setup-menu

The two entries of interest are Remaster Easy Linux and Remove builtin packages. Note, Puppy Linux has these as well, I have rewritten them for Easy.
By removing packages that are already in q.sfs, and installing your own packages, either compiled yourself or from the Ubuntu repositories, you can then create your own q.sfs and put it into the deployable image file. Voila, you have your own customized Easy Linux!

It is not just changes in packages, but bug fixes, user-interface improvements, etc., will also go into your new q.sfs.

Disclaimers, legal, miscellania

Some final notes about Easy Linux. Where not explicitly stated or implied, code, text, artwork and concepts are copyrighted to myself, Barry Kauler, with GPL license version 3. Refer here for the GPL statement.

Regarding responsibility for what I have uploaded for distribution on the Internet, although I have acted in good faith, there is a complete disclaimer of all responsibility. This applies to everything, including code and documentation. You download and use Easy Linux with this understanding.

This How Easy Works web page was written at an early stage of the development of Easy, and sample code and snapshots may differ from the latest release. Though, it should be a matter of detail, and the overall concepts should be the same. This web page is expected to be upgraded incrementally, but there is no guarantee that it matches exactly with the latest release.

Easy is currently considered to be alpha-quality, and in some places pre-alpha. Please bear this in mind when using it.


Have fun! I look forward to interacting with you on the forum.

Regards,
Barry Kauler
May 2017