woof-CE
woof-CE copied to clipboard
puppylinux-woof-CE
sfs loading in overlay
sfs_load.overlay does not appear to be aware of loaded SFSs and offers to load/queu the nls and doc SFSs that are already loaded. If an extra sfs is installed and you remove it from queu and then click on it will be reinstalled and the same SFs is loaded in 2 initrd directories
Also clicking on an SFS is confusing as it loads the sfs and then suggest to queu it “installing” is questionable too as ldconfig does not follow symlincs so “installed” SFSs does not run properly if libs are included.
I think that clicking on an SFS should only offer to queu or view (or at least show some warning about libs)
If it loads it then should apdate the path in ld.so.conf libraries are present in the pseudo-installed SFS are identified.
Otherwise good SFSs may be dismissed because the pseudo-installation fails.
Tested in dpup 10.0.55
I think that clicking on an SFS should only offer to queu or view
I tend to agree, and I thing sfs_load is not that important.
Some users see dynamic SFS loading as a key feature of Puppy and indeed, it's pretty unique. That's why I gave it a shot in #3398: this PR is included in the 10.0.x development builds to collect feedback, mostly.
I wonder how many users constantly change the set of SFSs they use or use their computers in a way that forces them not to reboot. I want to achieve stability and good user experience with overlay, before the beta of 10.0.0 in early 2023. If #3398 introduces a big risk of breakage or data loss, or if it's too limited and confusing, I don't mind pushing it out of scope for the stable 10.0.0 release and support SFS loading only at boot time.
dynamic SFS loading as a key feature of Puppy
And should be kept!
What if dynamic SFSs are mounted in the /DSFS (or some other new directory at the root of the file system) with links to / but with /DSFS/lib and /DSFS/usr/lib also added in ld.so.conf by default (and maybe LD_LIBRARY_PATH)
An extra directory in the loader's search path will slow down all applications. I don't like that.
Not in real life and if it is usually empty and at the bottom of the search stack in ld.so.conf. Besides we are talking about adding a couple of milliseconds opening an app, not running it.
I'm mostly worried about scripts. Puppy uses many shell scripts, and those milliseconds add up quickly.
Not quite on subject but close enough 🙄 sfs_load.overlay can not tell if nls and doc SFSs are loaded (see pic)
The structure of an overlayfs stack cannot be changed. So dynamic sfs loading as per sfs_load, dies with aufs. (Please prove me wrong.)
My daily workhorse Puppy for the last few years is a xenialpup using overlayfs via my old "mio" project. I've grown used to living without sfs_load. I don't change the sfs files in any Puppy very often. But running applications as AppDirs, which are located outside the stack, has helped.
sfs_load.overlay simulates SFS loading under PUPMODE 5 and 13 using symlinks, it's not too bad.
@dimkr , Interesting, but useless for me. I never run pupmode=13, only pupmode=12 with savefolder, it's the simplest.
I'm quite happy with my portable applications as AppDir's. Takes max 3 symlinks to "install", delete symlinks to "uninstall".