WDL_Arch three layers approach

[wiak]

Now that I am also using WDL_Arch64 as a 'server_for_the_whole_house' via tiger vncserver and VirtualGL (for hardware accelerated graphics done on server) I have basically adopted a three layers approach to its implementation, which consists of 08firstrib_rootfs (folder or sfs), 50upper_changes (folder or sfs), and optional external media non-numbered upper_changes folder.

First layer (08firstrib_rootfs) contains core WDL_Arch64 that I am less likely to regularly change - it contains what I arrange the f_buildplugin to produce during build_firstrib_rootfs distro build.

Then after first boot (with no 50upper_changes made yet), I add new larger or more likely to be upgraded apps, so these new apps go into standard external media upper_changes.

Finally, once I'm satisfied I have all the apps and utilities the whole household generally uses or wants, I rename that upper_changes folder as 50upper_changes (or whatever layer load number I want for it), so basically as a rollback file that could be deleted if I want to get rid of it. Being now thus numbered it will get auto mounted as a read-only layer on next boot.

Then on reboot, I use w_changes=RAM1 (or RAM2) mode, which creates a new (non-numbered) read/write upper_changes folder in RAM so I can choose thereafter, at end of any session whether to save changes (as read/write upper_changes folder) back to disk media or not.

On the rare occasions when I want to upgrade any of these big apps inside 50upper_changes I just delete the external non-numbered upper_media folder (or keep a copy of it modified to retain only config information I can keep there). I then rename 50upper_changes back to simply upper_changes (so will be writable on next boot), reboot, use pacman to upgrade or add whatever I like, and then rename upper_changes back to 50upper_changes per previous description.

Advantage is that actual upper_changes folder isn't actually needed at all or can be kept at tiny size so when using any in-RAM mode loading and persistence saving tends to be very fast indeed and not waste RAM.

Current server is chock full of stuff (mainly because of my demanding kids and for my partner's business running needs) including:

GTK, Qt5, Libreoffice, wps office, cherrytree, Chromium, latest full inkscape, full gimp, blender, kdenlive, masterpdfeditor, nomacs, Okular, tesseract ocr, gimagereader, OCRFeeder, tigervnc server/virtualGL etc, skype, viber, discord, zoom, msoft teams, minetest, supertuxkart racer, and much more... and of course all the usual: openbox/tint2, geany, pcmanfm, wex, Precord, lxterminal, mtpaint, and all the usual Puppy-sized apps along with pretty full-on compiler dev system for compiling and so on with gcc, git, Python3, perl...etc

Special mention for calculator 'Speedcrunch' - for business users much better to have history mechanism provided by Speedcrunch (alternative that is also very good, but too complex for my partner: Qalculate).
Also Okular is amazing for extracting/modifying tables out of pdf files for use in excel/libreoffice or wps spreadsheet) - pity it is HUGE cos uses so many kde libs (I don't use KDE, but found nothing as powerful as okular though 'tabula' is a simpler java-based alternative). Fortunately okular does not result in extra CPU or RAM demands (just storage space) so system not slowed down at all - its speed basically being determined by simple openbox/tint2 as desktop (no way I'd load KDE...) so same kind of resource usage and speed a typical Puppy user would be used to on their equally old hardware (aside from the server I normally install this onto old 2008 core2duo systems and runs like lightning).

Anyway, with that setup I have no need of further messing around loading/unloading sfs modules or portable apps - and accessible to anyone in the house via vncviewer too (though actually have same system copied over onto various computers in the house anyway, but some of these are older machines that can't themselves run OpenGL above version 2.1 so use server to do the accelerated hardware graphics when needed. Overall, proving easy to maintain, which is vitally important since my partner's business depends on its specially configured functionality and I don't myself have time to mess around continually configuring the system trying to get apps/new-apps to work...

Of course I do have 100 module loading layers (as layer-numbered normal folders or as layer-numbered sfs files or any combination of both) available with WeeDogLinux as it stands, and actually do load Puppy apps/portable-apps via one or two of these when wanted, but overall just want everything available and loaded all the time.

[rockedge]

I am also using a similar 3 layer approach with WeeDog64-Void as well. I could make a small script to do the upper_changes name changes when I need 50upper_changes to be writable and save the current upper_changes by renaming it. Once finished they are renamed again.

[wiak]

I am also using a similar 3 layer approach with WeeDog64-Void as well. I could make a small script to do the upper_changes name changes when I need 50upper_changes to be writable and save the current upper_changes by renaming it. Once finished they are renamed again.

I'm actually now using one further extra addon layer (51upper_changes) because makes it easier for me adding a few extra big apps without disturbing what is already installed. Also, I'm usually running with read/write upper_changes in RAM (w_changes=RAM1 mode), so I've been working on the rsync back to upper_changes on media script (wd_saveRAM1.sh). That script was only written to work with root user, and I think it was faulty anyway... Been struggling with it all night (brain a bit dead) - main issue being to get it working for the multi-user logins I now have on my system. I don't want to use gksu type solutions since gksu now deprecated and anyway I prefer to only allow users given sudo wheel group rights to be allowed to save to upper_changes - practical reasons for the business set up I have really. Normal users can still write out to folders not in upper_changes as long as they have file system permissions for wherever they want to write. However, all of my normal users (family) are so far all being given sudo wheel group rights so can use wd_saveRAM1.sh successfully (now). Amazing how tricky it can be to get utilities working with non-root user (a disadvantage from working too long as root user only - forget how to apply permissions to best effect), but important to do so securely anyway.

One day I'll get round to the 'merge' script required for RAM2 mode (where on-media upper-changes is mounted as a read-only layer), but I'm having enough trouble with the simple wd_saveRAM1 mode script so am in no hurry with the RAM2 version... I have the idea planned out though, using temp overlay for merge,
but too busy at the moment to write it and not essential for me at present - just that script that's missing though - the current dev version of initrd.gz does cater for that RAM2 mode already.