Puppy Linux Discussion Forum

hi taersh

 i use upupbb32 

 what do the extensions do  


 thanks 

 wanderer

Hi.

They add ability to use

bdrv.sfs
cdrv.sfs
gdrv.sfs
mdrv.sfs
ndrv.sfs
vdrv.sfs

in addition to the default adrv.sfs, fdrv.sfs and ydrv.sfs.

So, you can have eg. for the use in FossaPup64 9.5:

adrv_fossapup64_9.5.sfs
bdrv_fossapup64_9.5.sfs
cdrv_fossapup64_9.5.sfs
gdrv_fossapup64_9.5.sfs
mdrv_fossapup64_9.5.sfs
ndrv_fossapup64_9.5.sfs
vdrv_fossapup64_9.5.sfs
ydrv_fossapup64_9.5.sfs
zdrv_fossapup64_9.5.sfs

What's so difficult to understand on my explanations above?

Hi @taersh

This appears to extend the PUP Startup architecture.

Questions
Should this be included in WoofCE Pups? Have you submitted this?

Curious

I tried to do so. Though, I discovered that the init script already again had changed in Woof-CE which would force me to do all the work again to submit this to Woof-CE. Since there is no Puppy yet built with that new init script there's no possibility to make testings on the modified new init script.

Also I had some problems to handle github - even a program plus some help offered by @rerwin couldn't make it easier to me working with github. So, I gave up and removed my github account already. Sorry, but it's much too complicated for me...

Hi taersh,

Primarily I just want to thank you for your work in this area. I did click the "thank you button". Although I think the system you developed in LazyPuppy is more flexible and, thus, generally superior there are some areas where --what I've referred to as-- 'alphabet.SFSes' have their uses.
In LazyPuppy you championed the use of 'application' SFSes as an alternative to installing pets. Application.SFSes can be an application; and application suite; or even just a bunch of applications having in common only that the user frequently wants them to be available. They can be unloaded when not needed and make it easy to test the utility of updating applications: unload the old, load the new, test and revert if necessary as the old is not over-written. Often a reboot isn't necessary,
In contrast, to update an alphabet.sfs, the old version must be renamed and the system rebooted. When present where Puppy will find them an alphabet.sfs will be copied into RAM and can not be 'unloaded'.

I thought of two area --systems-- where an alphabet.sfs would be superior primarily because the user will rarely need to update and will almost always want the system available. One, if possible, would be language input systems discussed here, viewtopic.php?p=6455#p6455.

Another would be Qt-libs. To conserve space and bandwidth, Puppy Devs frequently don't include Qt-libs. I always have to download, package and use them as they are dependencies of some of the applications I frequently use.

I was wondering if you might suggest some other uses.

@mikeslr
Thanks for clicking the Thank You button.

They can be unloaded when not needed and make it easy to test the utility of updating applications: unload the old, load the new, test and revert if necessary as the old is not over-written. Often a reboot isn't necessary,

A reboot or even a restart of the X server usually could be avoided, if one knows what's locking the .sfs from unloading. A good example is KdenLive used from a .sfs modules. When KdenLive is started there's some other programs started in front of KdenLive or started simultaneously. On the latest KdenLive versions these programs are: klogd klauncher kdeinit5 - earlier versions would have kdeinit4 instead of kdeinit5. If one at least kills klauncher kdeinit5 the .sfs module of KdenLive will unload without any problems or being refused to unload.

That's why I created the new SFS PLUS 2 and its RunScripts - which I will upload an updated version within a few days. The issue on editing an existing RunScript is solved now and it fills out the forms almost automated immediately, as soon as the .sfs module is opened/mounted by the SFS PLUS 2 GUI. So, creating a RunScript to run programs from .sfs modules has become much more easy as it ever was.

These RunScripts have option to unload the .sfs module automatically after exiting the program. They also have a section to define those programs to be killed after the program is exited and before trying to automatically unload the .sfs module.

Example section/definition from the KdenLive RunScript

ProgsToKill="klogd klauncher kdeinit5"

Apart from my extended use of the additional alphabet .sfs modules in my OS I definitely prefer the use of .sfs modules to load/unload via sfs_load. As a side note: I think shinobar's sfs_load still is one of the best on top programs ever developed for Puppy Linux!

As for the use of the additional alphabet .sfs modules there was multiple reasons for me to do extended possibilities for its use. My main Puppy is my own Woof-CE build from Bionic64 called ArtStudio64, which is a full featured Audio, Graphics and Video Workstation. Here's what I do use my additional alphabet .sfs modules for:

adrv = testing and (if wanted or chosen to) keep system updates from the original developer (Bionic64 = 666philb)
bdrv = testing/keeping some of my own developments like the SFS PLUS 2, JWM Right-Click Substitute etc.
cdrv = testing additional programs, perhaps to be added later to the base .sfs, currently some Audio programs
gdrv = additional Graphics programs dependencies, currently stuff like image magick
mdrv = additional Music programs, everything that I want to use but don't want to have inside the base .sfs
ndrv = testing new programs to decide later to keep or to drop them, currently ZynFusion Synthesizer, Gluqlo screensaver etc.
vdrv = additional Video programs, currently testing peek GIF Screen-Video recorder
ydrv = additional files extracted from the devx .sfs, plus some development dependencies

Rebuilding each one of the above listed additional alphabet .sfs modules takes much less time than to rebuild the base .sfs module.

By the way: the modified init scripts have an additional option to be able to boot Puppy with and/or without to load the additional alphabet .sfs modules: padrvs=off - default is padrvs=on.

For the 64bit versions there's also an option to choose to boot with and/or without the 32bit compatibility .sfs module: pcompatsfs=on - default is pcompatsfs=off. Though, this .sfs module needs to be renamed then. E.g. compat32_ArtStudio64_1.0.0.sfs or another e.g. compat32_bionicpup64_8.0.sfs. I never understood why the 32bit compatibility doesn't follow the naming rules of the Puppy as they are used for all those other .sfs modules.

taersh wrote: ↑Mon Oct 05, 2020 6:49 pm

Hi.

I have uploaded new initrd.gz files for BionicPup32 (upupbb 19.03), BionicPup64 and FossaPup64.

All initrd.gz files are updated to use the Puppy with additional:

bdrv.sfs
cdrv.sfs
gdrv.sfs
mdrv.sfs
ndrv.sfs
vdrv.sfs

in addition to the default adrv.sfs, fdrv.sfs and ydrv.sfs.

Just to mention: the intird.gz files do include an updated sfs_load, extended to avoid all the above extra *drv.sfs from unloading.

I want to try on Fossapup64 to get some extra sfs working to change the default behaviour. But which sfs is top priority? Are all the new cdrv, gdrv, mdrv, ndrv, vdrv only for extra program not yet installed in system default? Can anything be higher priority than the original defaults programs?

ps: or documents, not just program. In Fossapup64 adrv there is /root/conkrc document but I would like to add new sfs with new conkyrc to ignore adrv conkyrc. Just one simple change.

Dash