mikeb wrote:wouldn't it be nice to have saved configs and data and changes all in ram with option to not save whenever you want and all done automatically and with no need for a symlinks or other such methods ...
oh it is....
yes mode 12 would do nothing at shutdown.
PUPMODE=13 should have been dropped / replaced many moons ago.
Mike
I think you've either (a) mis-spoke, reversing the roles of PUPMODE's 12 and 13; or (b) intending to continue the sarcasm of the first part of the quoted text, may have left the reader confused.
If you are serious that some PUPMODE should have been dropped, than it should be 12; and I'd agree with you.
The attached screenshot is from Lupu 5.28, playdaz's "original", now about 4 years old. Its a frugal install to a hard drive. I don't know if older Pups can be configured using jpeps boot parameter modification, [pmedia=ataflash] or whether their SaveConfiguration can be set to ONLY "ASK AT SHUTDOWN."
SaveConfiguration settings are reached via: Menu>System>Puppy Event Manager; then clicking the Save Session tab.
On my setup a Save Icon appears on the desktop [to enable manual Saves]; and at Shutdown a dialog appears offering the choice to Save or No Save. I'll discuss the effects of No Save below.
mikeb wrote:Pups operate entirely in RAM.
This is only partially true...indeed addition sfs are not necessarily loaded to ram at all.
Correct, Also discussed further below.
For usb the current session is in ram but the save file is not... the ram session is saved at shutdown and periodically... seems like this is what you are talking about and in this case you can opt to not save iff you add an addon script.
Almost correct. IIRC, your Pup of choice is a highly modified version of one of, I think, the 4 Series; Lupu being among the 5 Series. I don't have a working Wary, Racy or Saluki to test. The only "script" I'm certain of is jpep's modification of the boot parameter. However, shinobar has been very active in modifying PupSaveConfig,
http://www.murga-linux.com/puppy/viewto ... 081#457081. His recent modification, standard in Carolina and Carolina-Vanguard, includes the choice to Never Save with even the dialog at Shutdown being absent.
For hard drives and other fast media there is no ram for changes...the save file is used exclusively so any changes are instantly added.
That's the default setting you get on a frugal install when Grub4dos writes the Menu.lst. jpep's parameter modification and the user's configuration of SaveSession can change that.
The following has been my experience with Lupu and several of this year's litter of pups, frugally installed to hard drives, boot parameter changed to pmedia-ataflash, and SaveSession set to 0:
Change Wallpaper, don't save, old wallpaper appears on reboot.
Load SFS-on-the-fly, don't save, SFS isn't loaded on reboot.
Install pet, restart X if necessary, run pet, don't save, pet not present on reboot.
I admit being rather confused regarding how Puppies handle SFSes. From experience when an SFS is loaded, but not as yet opened, some portion of it exists in RAM. Usually there's a listing on the Menu. If, in fact, it has been loaded, even if there is no listing on the Menu, typing the name of its executable or wrapper in a terminal will either open the application or produce an error message other than "command not found."
Some time ago, in attempting to compare resource usage of installed pets, SFSes and Program Folders --applications decompress outside the SaveFile linked to the OS via scripts-- I used the then current LibreOffice as the test subject. As an SFS (with, I think gz compression) it required about 175 Mb of hard drive. As a decompressed Program Folder it took, IIRC, about 500 Mbs of hard drive. As an installed pet, it required the SaveFile use 500 Mbs of hard drive in addition to anything else in the SaveFile. As a loaded, but not opened, SFS it required about 35 Mb of RAM.
The "Urban Dictionary" gives other definitions, but the one I first learned for "blivit" was "ten pounds of shit in a 5 pound bag."
So here's my problem with how Puppies handle SFSes. I don't have a Swap File. And my computer has 4 Gbs of RAM --3.5 recognized running 32-bit OSes. So I can't explore the problem. What happens when you only have, say, 512 Mbs of RAM, your OS is using, say, 100 Mbs of that, and you attempt to open an application which requires 500 Mb? System crash? Application doesn't open? Something else?
The more important question is this: When an SFS is loaded and opened, the files you can observe if you had decompressed the SFS appear when you browse to their location. Or to be clearer, if you decompressed an SFS you can browse thru its files and folders and observe and delete or modify say its executable at /usr/local/bin. if, instead, you load the SFS and browse to /usr/local/bin you'll also see that SFS's executable. But what you are seeing is then only be in RAM. What happens if you delete that executable and --being in PUPMODE 13 configured not to automatically save-- shutdown without saving? My guess would be that the "deletion" would not have been written. That on reboot, the SFS will be decompressed from its "pristine" compressed file; still have an executable; and still be functional. But that's a guess.
"I'll be back" after testing.
mikesLr