My personal tricks to save settings aren't a part of the Modular Concept.
I just linked this as an reply to nooby!
It is not relevant for this thread, because I can use this Modular Concept(and so the user does) also when using a personal storage file (save file).
Got it NOW?!?!?!
And by the way, just to keep you informed: there is no LazY Puppy Creators (as a multiple) - there is only one: ME.
You should have already know this, if you were able to read and to understand what currently reading.
And again: this here is not for LazY Puppy. Go complain in its EN Forum, if you would have anything to complain about it. Though, I doubt you would get any further answer from me.
This is my last reply to you in this here thread. To me, sorry I have to say this, you are now OUT!
Yes, I usually also do have around 30 to 40 SFS Modules loaded, without any noticeable result to Operating Systems performance.mikeb wrote:I suspect this notion comes from unionfs which slowed down considerably with only a few layers. I regularly have 20 to 40 sfs loaded by default and get no appreciable performance hit on pentium 3 machines which noticed the drag of the standard drive icons in puppy. I noticed mention of some problems with recent kernels and aufs ... not sure of the current situation as 2.6.33 is the newest I normally use.
I also have sfs as small as 200-300k in the set...one per app usually.
I have SFS Modules from 11KB up to 300+ MB. The funny thing I have noticed so far: time to laod an SFS seems not really to make a difference, if the SFS is sized in KB or even in MB.
That's why I've suspected that there must be a difference between loading an SFS at boot up and loading an SFS via sfs_load.
Yeah, already noticed this. Though, there is no reasonable point for me to see, why this hasn't changed in those 10 Puppy Linux years.On the other hand see what's happening in this thread.... not exactly productive when good ideas are getting lost but this is pretty typical and note very little activity in this forum alone reaches the main puppy releases.
If the SFS's application is a real binary, I can freely define if the SFS should be unloaded after its application is exited. Please note the onformation at second post, and there especially read the thread of multi-session CD/DVD (my solution, created for 8-bit). For the use of the Modular Concept, how I do prefer and suggesting it, the use of sfs_load is needed!oldyeller wrote:If you load by the menu when needing a program, does it unload when it is closed? Are the SFS done automatically for loading and unloading and no need for SFS-load on the fly?
This Modular Concept is built on top of sfs_load and all its pretty comfort would get lost immediately, if there wouldn't be shinobar's sfs_load. Though, I'm currently using a little modified version to be able to load SFS from different locations (and not only from boot partition or boot directory). I'm convince by now, I would be able to create this also for the use without shinobar's sfs_load. But why should I try so?
To laod more than 6 SFS Modules (I assume, you do mean at boot up, when using a save file) also sfs_load can be used. Itself uses a file /etc/init.d/sfs_load for this.How would you link to a Appdir or load more than 6 SFS?
While running the OS, shinobar's sfs_load generates mount point directories automatically for each SFS to load.
There is no need to link to AppDirs, because you can run them from every location you want to store it. But AppDirs aren't really a part of this here. It could be a nice addition, but I'm not an expert for this - still learning while doing some of this stuff (like the RoxApp Builder, which isn't a part of this here as well). If you want to know anything about AppDirs or RoxApps or Program Folders, go to RoxApp Builder thread in Puppy Projects Forum and do read my information over there. There are also some links to a few RoxApp Dirs for the use on un-unioned SFS Modules (I think, un-unioned means: not mounted to the pup_roX directories, instead mounted to /mnt or anywhere else).