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...
DownloadUnlike most other Linux distributions, Easy is not deployed as as 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--.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.gzHaving done so, you will have easy-0.1.6-amd64.img:
...the above snapshot is a ROX-Filer file manager window in Easy Linux.
InstallationThe 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 mntptThe 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:
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.sfsThis 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, withxz compression.
initrd.qThis 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 calledinit.
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:
...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 scriptOne 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:
|There is one important point that can be extracted from the above code: aufs andoverlay.|
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 filesystemThis picture illustrates the basic principle:
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 partitionHere is the next segment of code:
|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'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 measurementsThe 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:
|Moving on, at first bootup, the second (working) partition does not exist, so has to be created...|
Create the working partitionThe 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:
|This segment of code was quite tricky to implement. The problem is created by theGUID 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 maintenanceAs the above title says, this segment of code is concerned with recovery and maintenance. Here it is:
|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 controlThe 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:
|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.sfsThe 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:
|Now to progress onto creating the layered filesystem, first, the ro layers...|
q.sfs as bottom ro layerFile 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:
|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 filesAs with Puppy, Easy can also load extra SFS files, as ro layers. These have to be specified in a configuration file:
|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_rootHere 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:
|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 ,\
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_rootThis 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:
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:
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 partitionStaying 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:
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:
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:
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 versionI 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:
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:
...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 ControlWith 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:
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-.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-folderAll 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:
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:
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 containersEasy 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:
Burrowing down, looking inside the seamonkey folder:
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 .ro0folder), 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:
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 filesystemWhat 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:
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 EasyThis 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:
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, miscellaniaSome 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.
Have fun! I look forward to interacting with you on the forum.
more details here: http://murga-linux.com/puppy/viewtopic.php?search_id=2108242921&t=109958 and here: http://barryk.org/news/?viewDetailed=00515
easy-1.0.4-aarch64.img.gz created for rock64
- Internet Archive HTML5 Uploader 1.6.3
GZIP Uplevel BACK
HTML Uplevel BACK
ISO IMAGE Uplevel BACK
Uploaded by allytonx on