Sorry gyro, it's been a long time since I looked at Barry's boot code.
The " ? " was because of the " I can't remember " thing.
I'd have to look at the boot code to get a better idea of what's going on.
live mounting of sfs is it possible ?
modified load_sfs-08 works on puppy 412 barebones
Well I got it to work. Changed toYes, removed a single space character.
I have attached a copy of the script that worked for me.
It also has the "execute" quotes removed from "$self" in the error messages.
Edit: I 've now attached a ".pet" that contains a slightly modified "load_sfs" script, and also includes a crude "unload_sfs" script. Both use "jwm -restart" instead of "restartwm".
It also contains a "loadsfs" script in /etc/init.d, this runs "fixmenus" at startup, in case an sfs was loaded but not unloaded, during the previous session.
Edit: Both scripts now use "refresh-menus" from 420rc2.
Copied parameter checking from load_sfs to unload_sfs.
gyro
Code: Select all
mount -o remount,append:"$mount_point" =ro /
Code: Select all
mount -o remount,append:"$mount_point"=ro /
I have attached a copy of the script that worked for me.
It also has the "execute" quotes removed from "$self" in the error messages.
Edit: I 've now attached a ".pet" that contains a slightly modified "load_sfs" script, and also includes a crude "unload_sfs" script. Both use "jwm -restart" instead of "restartwm".
It also contains a "loadsfs" script in /etc/init.d, this runs "fixmenus" at startup, in case an sfs was loaded but not unloaded, during the previous session.
Edit: Both scripts now use "refresh-menus" from 420rc2.
Copied parameter checking from load_sfs to unload_sfs.
gyro
- Attachments
-
- load_sfs_g4-0.8.pet
- my latest load_sfs and unload_sfs scripts.
- (2.63 KiB) Downloaded 576 times
Last edited by gyro on Mon 09 Mar 2009, 12:35, edited 4 times in total.
Stop restarting X? - solved for JWM
On Puppy 4.1.2, JWM can be restarted from the menu without restarting X. How can this be done from a script?
Edit: For JWM use "jwm -restart"
gyro
Edit: For JWM use "jwm -restart"
gyro
-
TheBlackSheep
- Posts: 20
- Joined: Sun 23 Nov 2008, 09:24
- Location: Lancashire, UK
Being able to dynamically mount sfs's seems like a really good idea but I was wondering if there's an order issue when you load several one after another.
e.g. if one SFS has a version of a library in it and another SFS has a later version of the same library, doesn't the order in which they are virtually mounted affect what will be seen by the OS. Further, if you've installed some software via the PET repository (which presumably goes into your 2fs file) doesn't this effectively sit on top of all SFS's or would dynamically loading an SFS after booting effectively sit the other side of this, i.e. on top of the 2fs layer?
...or am I missing something here?
Chris
e.g. if one SFS has a version of a library in it and another SFS has a later version of the same library, doesn't the order in which they are virtually mounted affect what will be seen by the OS. Further, if you've installed some software via the PET repository (which presumably goes into your 2fs file) doesn't this effectively sit on top of all SFS's or would dynamically loading an SFS after booting effectively sit the other side of this, i.e. on top of the 2fs layer?
...or am I missing something here?
Chris
TheBlackSheep,
My understanding is that the 2fs is always on top, i.e. takes precedence over all SFS.
Also, if different SFS files contain different versions of the same file, then the order of loading is significant.
Provided these limitations are kept in mind, there are still occasions where dynamic loading of SFS could be useful.
gyro
My understanding is that the 2fs is always on top, i.e. takes precedence over all SFS.
Also, if different SFS files contain different versions of the same file, then the order of loading is significant.
Provided these limitations are kept in mind, there are still occasions where dynamic loading of SFS could be useful.
gyro
-
TheBlackSheep
- Posts: 20
- Joined: Sun 23 Nov 2008, 09:24
- Location: Lancashire, UK
Hi Gyro,
Yes, very much agreed, very useful - a minimal distro that could load/unload sfs files would be perfect. I have a really small low-end sub-notebook (IBM 240X PIII 500Mhz, 10.4" screen with 128Mb+swap) that I use for hols and travelling etc - you could call it a "poor man's netbook" - bought off ebay for <50GBP. It runs the standard 4.1.2 ok although it's not really up to the job for multimedia.
With a minimal distro like barebones and a few SFS files to run office (OpenOffice), internet (say Opera+Flash) or possibly even a media player (VLC - if I could get it to work ok on this laptop) when I needed them would be great. I have an SFS I built of lazarus (the open source version of Delphi) and it's 122Mb on it's own and it still needs the devx SFS on top of that before it will fully compile anything (I haven't worked out why - fpc is in the lazarus SFS so unless it still needs the linkers from the Devx SFS or whatever and I need to include these too - I digress).
Anyway, the point is, I wonder if the ideal here would be to create a dynamic loader management system, something that allows you to specify the order in which the SFS's are loaded and manages the unloading of them (although definitely problematic if applications are running) - possibly unloads them all and reloads what's left in the relevant order. Similar to the dialog that appears when you specify what SFS's to auto-load at boot time but with an option to shuffle the order in which they are loaded.
I presume SLAX takes an arbritrary stance here and just tries to load and unload depending on the click of the mouse, what's top-most at the end of the load takes precedence - in Puppy's case the 2fs file takes precedence over everything based on what you mentioned before.
If I get a chance over the weekend I'll do some testing with some dummy files to see what happens to overlapping SFS's when you take the rug from under them so to speak - unless someone has already done this and can explain what happens.
Chris
Yes, very much agreed, very useful - a minimal distro that could load/unload sfs files would be perfect. I have a really small low-end sub-notebook (IBM 240X PIII 500Mhz, 10.4" screen with 128Mb+swap) that I use for hols and travelling etc - you could call it a "poor man's netbook" - bought off ebay for <50GBP. It runs the standard 4.1.2 ok although it's not really up to the job for multimedia.
With a minimal distro like barebones and a few SFS files to run office (OpenOffice), internet (say Opera+Flash) or possibly even a media player (VLC - if I could get it to work ok on this laptop) when I needed them would be great. I have an SFS I built of lazarus (the open source version of Delphi) and it's 122Mb on it's own and it still needs the devx SFS on top of that before it will fully compile anything (I haven't worked out why - fpc is in the lazarus SFS so unless it still needs the linkers from the Devx SFS or whatever and I need to include these too - I digress).
Anyway, the point is, I wonder if the ideal here would be to create a dynamic loader management system, something that allows you to specify the order in which the SFS's are loaded and manages the unloading of them (although definitely problematic if applications are running) - possibly unloads them all and reloads what's left in the relevant order. Similar to the dialog that appears when you specify what SFS's to auto-load at boot time but with an option to shuffle the order in which they are loaded.
I presume SLAX takes an arbritrary stance here and just tries to load and unload depending on the click of the mouse, what's top-most at the end of the load takes precedence - in Puppy's case the 2fs file takes precedence over everything based on what you mentioned before.
If I get a chance over the weekend I'll do some testing with some dummy files to see what happens to overlapping SFS's when you take the rug from under them so to speak - unless someone has already done this and can explain what happens.
Chris
Hi TheBlackSheep,
I'm thinking of creating an SFS for each occasion, e.g. an Internet one, a working with documents one, a programming one, a games one, etc... Each SFS would contain all the programs etc that I want for the particular occasion. If this live mounting and unmounting was working, then I would most likely only mount one SFS at a time.
(Like you I'm targeting this at a small machine, mines a 7in EeePC.)
One advantage of using SFS files, on a frugal install, to contain the bulk of the stuff that doesn't change, is that it makes possible a minimal pup_save.2fs. (My EeePC takes a long long time to save the 2fs file to the SD card.)
I expect that your testing will show that only the top most copy of a file is visible.
gyro
I'm thinking of creating an SFS for each occasion, e.g. an Internet one, a working with documents one, a programming one, a games one, etc... Each SFS would contain all the programs etc that I want for the particular occasion. If this live mounting and unmounting was working, then I would most likely only mount one SFS at a time.
(Like you I'm targeting this at a small machine, mines a 7in EeePC.)
One advantage of using SFS files, on a frugal install, to contain the bulk of the stuff that doesn't change, is that it makes possible a minimal pup_save.2fs. (My EeePC takes a long long time to save the 2fs file to the SD card.)
I expect that your testing will show that only the top most copy of a file is visible.
gyro
-
TheBlackSheep
- Posts: 20
- Joined: Sun 23 Nov 2008, 09:24
- Location: Lancashire, UK
hi gyro
made some test SFS files and tried loading and unloading and changing the order but something not right somewhere (sometimes the SFS files would appear in the filesystem sometimes they wouldn't) - also regularly got into a muddle with the /dev/loopx files, and couldn't then load or unload the SFS again.
like you I think this could be a winner for low spec'd devices. have not given up on it yet so will persevere...
chris
made some test SFS files and tried loading and unloading and changing the order but something not right somewhere (sometimes the SFS files would appear in the filesystem sometimes they wouldn't) - also regularly got into a muddle with the /dev/loopx files, and couldn't then load or unload the SFS again.
like you I think this could be a winner for low spec'd devices. have not given up on it yet so will persevere...
chris
Did you notice if the files not appearing in the filesystem corresponded to files with the same name as existing files? And files appearing in the filesystem corresponded to files with names that did not already exist in the filesystem?TheBlackSheep wrote:(sometimes the SFS files would appear in the filesystem sometimes they wouldn't)
gyro
The other thing that would be cool to look at is whether you can load sfs files to ram.
In Grafpup 104 you could if they were on the CD but not if you copied them to the hard drive; Nathan said he was going to fix that, but I don't think he ever did.
The advantage of loading to ram is faster startup times, which should be nice for big programs like Openoffice and firefox.
In Grafpup 104 you could if they were on the CD but not if you copied them to the hard drive; Nathan said he was going to fix that, but I don't think he ever did.
The advantage of loading to ram is faster startup times, which should be nice for big programs like Openoffice and firefox.
Do you know a good gtkdialog program? Please post a link here
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
I have created a semi barebones puppy derivative which I call ChoicePup4.1.2 which incorporates load_sfs and unload_sfs. As well I have custom tailored 26 packages into .sfs packages for loading. They can be loaded at boot or on the fly. Take a look if you're interested.
Enjoy, J
Enjoy, J