Good feed-back. Not surprisingly the main objections in all had to do with SFSes. Clarity's suggestion to drop 4b entirely is very tempting. I'll explain below why I'm reluctant.
You may find this surprising about someone who spent his life writing. While my ability to visualize things in four dimensions is strong, my ability to remember the exact meaning of terms is weak. I struggle to find the right words to describe what I see. Being precise takes time and effort. And why I've never tried to learn more than the rudiments of any programming language.
The real problem is that we have to live with the direction taken by others. Maybe someone knows why the Linux Org chose to develop Overlays rather than AUFS. An initrd can be written to manage either, albeit, grub's code must be modified. cf. https://www.forum.puppylinux.com/viewto ... 82#p117782
AUFS is, AFAIK, much more flexible and user-friendly. dimkr and I keep mis-communicating because the same term is used for two entirely different things. What I've sometimes referred to as 'alphabet.sfses' and 'application.sfs' --in order to provide necessary terms-- are handled differently because of the code in initrd treats them differently. Both are squash-file-systems. Both may include files obtained anywhere. Adrv.sfs, bdrv.sfs, fdrv.sfs, ydrv.sfs zdrv.sfs –alphabet drives-- must be located adjacent to puppy_version.sfs in order for their contents to be copied into RAM; and cannot be 'unloaded' [except by a reboot after such file-system on storage is moved or deleted]. Mistfire has modified the initrd in Quickpup to handle more 'alphabet.sfses'. By convention we limit the contents of fdrv.sfs and zdrv.sfs, but don't limit what adrv.sfs and ydrv.sfs contain. Initrd, itself, doesn't care. As a result of its code, the only thing which matters to initrd is the name we assign to the SFS. To conserve writing I've referred to them as adrv.sfs, etc. But the name actually used must specify the Puppy which is to use it, e.g. fdrv_dpupbw64_10.0.6.sfs. On boot-up bookworm64_10.0.6's initrd will ignore files with the name fdrv.sfs, fdrv_bionicpup64_8.0.sfs and even fdrv_dpupbw64_10.0.5.sfs.
'Alphabet.sfses' are system files. It makes sense that you can't remove system files from a running system.
Application.sfses are not system files. Their content can be anything, even just documents or pixmaps. I have an SFS which only contains dozens of fonts I rarely, but occasionally, use. We can name them anything, e.g. gimp.sfs, graphic-suite.sfs, junk.sfs. Their content, however, can not conflict with that of system files, including the content of a Save. They are not copied into RAM unless and until we choose to load them. They must 'hang from /mnt' but otherwise can be anywhere. And while we can choose to un-SFS-load them at any time under AUFS, if a Save is in use it will contain instructions to sfs-load previously loaded application.sfses unless and until we choose to SFS-(un)load it and execute a Save to preserve that condition.
Under Overlays alphabet.sfses have the same limitations as under AUFS, but more. Under Overlays, 'applications.sfses' can be loaded on-the fly. But the code to unload them on-the-fly developed under AUFS doesn't work. Fredx181 has published an alternate sfs-load whose purpose was to permit unloading SFSes on the fly under Overlays. He designated it as 'experimental' . I think it has been incorporated under Bookworm64. I did not test it extensively. [I think I used it once to load then unload the aforementioned 'fonts.sfs'.] All the applications I use can be installed via synaptic and/or available thanks to Mikewalsh's and other's work on portables. When possible, I choose the latter.
While I think the availability of portables should emphasized, I am unwilling to entirely discount the potential of 'application.sfses' and entirely fail to mention them. This is what I think is the essential difference:
I don't code. But Puppys have the dir2sfs code builtin that can be used to create a simple SFS, or after extraction repackage a pet or deb as an SFS. For more complicated applications, there's PaDS. PaDS will combine any number of pets, debs, and other packages and generate an SFS. In bookworm64 I can use synaptic to download but not install an application and all its dependencies, then copy the downloaded files from /var/cach/SOMEWHERE –where synaptic placed them-- into a specifically named folder and use PaDS to generate an SFS. Any application –or suite of applications-- which can be installed by synaptic and function can be packaged as an SFS, loaded and function. An installed application always requires RAM. An unloaded SFS requires no RAM. My desktop has 16Gbs of RAM. How an application becomes useable doesn't matter to me. But it does to what I believe are Puppys 'target audience': Window refugee's with older computers with limited RAM. PaDS GUI and its easy to follow instructions means even they could create SFSes to use as and when they wanted. And it doesn't matter which Puppy they choose to run --except as noted below in response to jasper- if the major distro offered the application and its infra-structure could be used.
Mikewalsh and others have published an extensive number of portables, I think some for each category of applications. But they won't run OOTB under every Puppy. Some are 'wrap-arounds' for AppImages which, 'though supposedly containing all dependencies, don't account for a Puppy's lack of the infra-structure built into Major Distros. I have sufficient knowledge that I can use the work Mike and others have done as templates to create other portables, e.g. a portable Waterfox using firefox portable as a template. But much is beyond me, and 'way above the paygrade' of a newby. Application SFSes remain an important vehicle for someone to obtain a Puppy possessing all the capabilities they need.
Jasper, as you know from your updates to applications, a woofed Puppy is a snapshot of the version of some major distro at the time the Puppy is created, lacking some of the infra-structure used by the Major and substituting Puppys own infra-structure to the extent necessary to achieve a functioning system. 'Binary-compatible' only means that the binaries of that Major can be directly installed. It's a 'term of art' we've used; never intended to suggest 'identical with'. Ubuntu 20 is not identical with Ubuntu 20.4. The Qt5 versions used in 20 prevent use of Qt5 dependent applications created for Ubuntu 20.4. Ubuntu does a system-wide upgrade. As a 'snapshot' we would have to develop a work-around, if possible.
I think someone who understands the 'import' and 'export' functions should consider working in the development of portables.
dimkr, you're right about not specifically mentioning the existence of more than one package manager. I think that the ability to install from the major's repo and applications created for Puppys is sufficient without mentioning how.
Will review what's been written and present another 'Draft' tomorrow.