mikeb wrote:If we are dealing with aufs itself I have noticed it can take a few seconds for files to propagate through the system when dealing with an sfs with thousands of files...the devx is a good example, but it probably takes longer for menus to sort out so its not a problem as such.
Yes.
As far as I know, shinobar's sfs_load is mounting an AUFS, to load SFS Modules. Also I have noticed a -sometimes- huge delay until the sfs_load GUI to execute an application from the currently loaded SFS appears on the screen. I have noticed also, this is dependent to the WM in use.
My experiences:
- JWM needs sometimes to be refreshed manually (though, it is fast)
- IceWM is also fast and I did never ever need to refresh it manually
- Openbox is really fast, even for a full menu like I do have over here (currently 821 .desktop files in /usr/share/applications)
BUT:
- when FbPanel is used as the panel for Openbox these 821 .desktop files (menu entries) resulting in an huge delay
- this huge delay is related to FbPanel itself
- the code, producing this issue is to be found in /usr/sbin/fixmenus
Code: Select all
if (grep "openbox" /etc/windowmanager) then
[ `which variconlinks` ] && variconlinks #100404 for my fbpanel pkg.
[ `which tempicons` ] && tempicons
fi
- responsible line is: [ `which variconlinks` ] && variconlinks #100404 for my fbpanel pkg
- this line creates a huge amount of icons from all over the running OS for the FbPanel to use
Currently I don't have any other WM/Panel installed, than Openbox and Tint2. If loading my LP2_WindowManagers.sfs Openbox (the OS) will use automatically FbPanel instead of tint2. Therefor I have modified /usr/sbin/fixmenus to execute refresh/rebuild of Openbox menu at first - before any else WM/Panel is refreshed/rebuild.
So, while FbPanel is stiil updating its icons, I can run any newly added application from Openbox menu immediately.
Also, I don't use sfs_load as it is supposed to use. I do use it only as back end script, since I have my own GUI to load/unload SFS Modules and all the menu entries already built into the OS. So, there is no need to run /usr/sbin/fixmenus when loading an SFS by the use of sfs_load in back end (console) mode. That's why shinobar has introduced option --skip-fixmenus in sfs_load version 1.9 and above. Especially for the use of the SFS P.L.U.S. RunScripts!
Code I usually do use, to load any SFS Module:
Code: Select all
sfs_load --cli --skip-fixmenus --quiet "$LP2BDL/$SFS_file"
Code I usually do use, to unload any SFS Module:
Code: Select all
sfs_load --unload --cli --skip-fixmenus --quiet "$LP2BDL/$SFS_file"
$LP2BDL is current boot directory, like: /mnt/sdd1/LazY
$SFS_file is the SFS Module to load, like LP2_WindowManagers.sfs
Just as an aside I am fiddling with the initrd at the moment and it takes 1.5 seconds to run the init script including loading a 94mb pup sfs to ram on a pentium 3.
Mine is a bit slower than yours, since I've added some stuff to be able to load each SFS Module I want to load at boot up - just by an option to be placed in a boot menu entry in menu.lst (or even entered in console)
This
will load the XorgHigh automatically at boot up. It goes straight to where the zdrv.sfs usually goes: /intird/pup_z.
However, I really don't care about the speed of booting the OS, if it has been done in 20, 40 or even 60 seconds etc.pp. since I'm usually brushing my teeth, washing my face, entering the bathroom or pulling off my clothes when returning to home, at such boot times.
Here's the module activate/deactivate script I have on puppy in use at the moment. I am a slob and should tart it up but it does the job.
Its in the right click rox menu and toggles load/unload.
Yes, I can load/unload SFS Modules by clicking it as well. Plus: I do have a Openbox menu Category (menu pipe), which offers to me all current loaded SFS Modules to be unloaded, when clicking its menu entry.
Sorry, but can't post an image at the moment, because I'm still using the MochiMoppelTest-called LazY Puppy 2.0.2-005 EN version by using the created save file - still works, but this version hasn't included above named Openbox feature.