init – a modular linuxfs

[Member lucbertz]

Probably someone of you knows Slax (https://www.slax.org), a one man distribution built by the same developer of Linux Live Kit (https://www.linux-live.org/) set of scripts.

With these scripts the initrfs file of any distribution with aufs kernel support (formerly Slax were based on Slackware; now it is based on Debian) is rebuilt from scratch, adding persistence and modularity of squashfs live filesystem. A similar feature is available in another (too extremely) small distribution, SliTaz (http://www.slitaz.org/), which merges many gz archives in one live filesystem on startup.

I think that apply Linux Live Kit directly to antiX should be a waste, because antiX init already contains persistence and many others initialization cheatcodes not availble in Slax.

I guess if should be feasible to modify init in a not so much revolutionary way so that antiX could have a modular livefs.

Why I love this modularity? Because on boot I could select which parts of linuxfs to load.
For example linuxfs could be splitted in:
01_linuxfs_core
01_linuxfs_core_i586
02_linuxfs_wifi
03_linuxfs_icewm
03_linuxfs_xfce
04_linux_rescue

With boot cheatcodes we could select in which way to start, completely ignoring what is not needed in that context:
01_linuxfs_core (base text mode filesystem)
01_linuxfs_core_i586 + 03_linuxfs_jwm (base text mode filesystem for 586 non pae cpus + xorg and jwm)
01_linuxfs_core + 02_linuxfs_wifi (base text mode filesystem + wifi firmwares and ceni)
01_linuxfs_core + 03_linuxfs_icewm (base text mode filesystem + xorg and icewm)
01_linuxfs_core + 02_linuxfs_wifi + 03_linuxfs_icewm (base text mode filesystem + wifi firmwares and ceni + icewm)

In this way loading on old system could be faster, selecting only needed modules, on the same base there will be the possibility to load different desktops, different drivers, different softwares (rescue mode, office mode, multimedia mode, …)

Probably this idea is out of date, due to high speed of modern machines and USB drive sizes, but I guess if it is so difficult to implement it.

[Member lucbertz]

Helpful

Up

0

::

I don’t like so much Puppy and related distributions.
I already know Porteus (I will retry it, anyway); it was born as a fork of Slax, in fact.

I found also:

liveslack seems to be the more flexible solution (it permits updates, also of kernel, and it can be built from packages), but, like Slax, it is a one-man developed and maintained solution; I prefer to avoid this kind of distributions. Furthermore it is based on Slackware, KISS, rock solid but conservative and with a repository less rich than Debian. I’d like to rewrite this script for Debian, but I’m not skilled to do it and this could be a huge work.

ubuntu-core is the ideal solution (scheme), but it is terrible to have all the needed libraries and dependencies included in each package; snap solution means that also a minimal software should be distributed in huge packages. The snap solution is similar to the apps of mobile OS, but they can’t be applied to current architectures of desktop OS, with many libraries in many versions.

I was not aware about xtra.tgz antiX option. It seems to be great, but it would be better if xtra.tgz file name and path were not hard coded but boot cheatcodes parameter. Anyway I will try it; thank you for the great hint.

Separately, you can place files in …/LiveUsbStorage directory of the liveUSB and, on-demand, access ’em (run executables, extract archives residing there)
only if/when you need ’em (IMO, that’s happyjoy compared to needing to reboot in order to re-select which “modules” to load).

I’m also evaluating this solution, also simply placing directly debian packages in a …/LiveUsbStorage folder and a set of scripts to install them in live only when needed. In this way it could be easy to do updates with apt-get –download-only .

Regarding my _terrible_ examples, they were only mere examples; I will never never never install XFCE on antiX; openbox + lxpanel is enough. 😉

[Author]

Posts