I saw a post re: "Run Browser in RAM" in Puppy distro area
There, s243a has written a script to do this.
However, I think no script in required in WeeDogLinux to do this since its flexible initrd/init makes it easy to arrange for any chosen programs to run in RAM (from either a numbered sfs file, or a numbered raw directory).
For the purposes of this HowTo, I'll assume firefox:
1. Download the tar.bz2 (or whatever) from Mozilla.
2. Uncompress it and make it into an sfs of name, say 03firefox.sfs (the 03 will cause it to be placed in overlayfs layer 03, but you can change that number to any position you want in the range 00 to 99; i.e. you can have up to 100 sfs module layers in any order you wish in WDL - good for rollback session effects).
3. Place 03firefox.sfs in the directory you will boot from, let's say /WDL_whatever (i.e. alongside WDL vmlinuz and initrd.gz).
4. Place any numbered sfs file you DO NOT want in RAM into an alternative location, say /WDL_whatever/not2RAM (for example: put 01firstrib_rootfs.sfs in there).
5. On grub(whatever) kernel line include the following WeeDogLinux boot option arguments:
Code: Select all
w_copy2ram w_changes=EXIT w_altNN=UUID=xxxxxxyyyyyy=/WDL_whatever w_bootfrom=UUID=xxxxxxyyyyyy=/WDL_whatever/not2RAMUse the appropriate UUID of course - as found from blkid; yes, you can even use different devices/partition (UUIDs) for different sfs modules if you wish...
Note that you could optionally use device/partition LABEL(s) instead of UUID, or even direct device paths such as /mnt/sdb1/xxx (but direct device paths not so reliable if booting from usb since system can randomly change device name order).
That should be pretty much all there is to it (except I haven't completed user script to save the changes out of RAM at the end of a session yet - but can do that manually with cp -a command anyway...). Brief explanation:
w_changes=EXIT copies any existing stored upper_changes folder into RAM and uses that copy (at end of use you need utility to replace the old stored upper_changes if you so wish, maybe using rsync or just a straight overwrite copy works). Note: I chose the EXIT terminology in case any DebianDog user wanted to try WDL since (maybe) similar end result to their changes=EXIT kernel line argument, but I don't know how Porteus code their arrangement (did things my own way) and I have yet to code any save2flash type functionality so nothing automatically actually happens on 'EXIT' as yet since I haven't wanted/needed that myself thus far... In practice, I do however use w_changes=EXIT on my own system to use a previous upper_changes directory but generally without saving new work back at the end - though sometimes I do just overwrite the old upper_changes directory, from the running with persistence in RAM system, with cp -a command (but rsync arrangement would be better - I'll think up my own approach to that later)
w_altNN contains path to a secondary directory that contains 2-digit numbered sfs files (or numbered raw uncompressed directories) - but these do not ever get copied to RAM (but are mounted from their original location). In above example, I'm putting 01firstrib_rootfs.sfs in there.
w_bootfrom is path location of vmlinuz and initrd.gz but also any numbered sfs (or numbered raw uncompressed directory) that will get copied into RAM when the argument w_copy2ram has also been given on grubXXX kernel line (which it is in this example). This is where I'm putting the browser, 03firefox.sfs. Note that if I had also wanted 01firstrib_rootfs.sfs copied into RAM prior to use, I could have put it in this path instead (or as well as 03firefox.sfs).
So no script required. WeeDogLinux is clever enough to allow that usage simply by appropriate boot options. If you're lucky, some Puppy dev may try and now hack similar functionality into Puppy initrd/init; please ask them to kindly acknowledge the above methodology/implementation-method to WeeDogLinux - assuming they succeed in their hack it would be nice of them to remember that little detail...
Of course, you may want special handling for profiles and so on, in which case some extra scripting might well be useful.
Note that the above is only one of a couple of methods of arranging this in WDL. A more direct method is simply to edit the file w_init, that latest (dev-only) WDL allows placed in the w_bootfrom location. That simple directly editable text file contains the mount overlay stanza, so you can directly mount and add layers to it - simply edit it in geany - (without needing numbered filenames if you wish), but the method outlined in this HowTo is probably much better.
Final note: Above should work since WDL system designed with such flexibility in mind, but haven't tested that exact configuration as yet. I'm sure it will work (optimist).
wiak