How to stop the USB auto save feature?

[drunkjedi]

It's for Fatdog only, yet.
Wait till others implement it too.

[backi]

Would be exciting !!!!
....how and where to promote this implementation ?
This Fat-Dog concept is quite cool .

[phat7]

phat7; As Mike Walsh said, not all apps come as SFS.
I`d say a 1GB Save file is pretty typical for anyone who tries lots of apps.

Yeah, but you said "don't use pets" and you claimed that the file can be kept as small as 64MB. Where is your excuse now for your 1GB file? The point you made 3 years ago is still valid and I like it. 64MB may be ridiculously small and of no use but 1GB is a sign of bad file management.

To stop autosaving is already an option, to stop saving at shutdown has been discussed again and again in this forum and several solutions are on the table and working well but with a bloated save file you still need to save at some point and you still suffer from long saving times. Trimming the fat and taking out the garbage is still the way to go.

[sunburnt]

phat7; SFS is preferred, but pet only does not mean I don`t want to try the app.
Someone here said they were using a 32MB save file.
If only conf. changes and settings are kept in it, then it can be quite small.

rufwoof; No, not on the page as such, groups of apps in SFS files.
There would be mostly single app SFS files of course.

AND. You`re right about SFS problems. That`s why I suggested eliminating the union FS.
There is a long web page somewhere that lists all the problems with union file systems.
Rox apps and relocatable apps are the most viable. Run from anywhere and any device.
I have run SFS files and relocatable apps mounted over a Samba LAN on diskless PC.

[phat7]

phat7; SFS is preferred, but pet only does not mean I don`t want to try the app.
Someone here said they were using a 32MB save file.
If only conf. changes and settings are kept in it, then it can be quite small

Add some MB for apps and it can still be small. Still no excuse for a 1GB save file. The safest way to try apps is to start without a save file. Or you can keep a special small save file anly for tests. This will keep your main file unharmed. A matter of organization.

[8Geee]

While I don't think either exttreme is calleed for, something like 256Mb is OK. Consider a security update to openssl, or bash, or other "important" file. While 1Gb gives ample save-file room, 64Mb does not, and forces a remaster. Another point here to consider is how old the USB stick in question is. One of the new Stubby ones is about $5 and tolerates an ext3 and 3fs save. Older ones are not tolerant/slow. This second point raises a third point of ext2 vs. ext3 (or 4) as the file system. Ext2 though secure cannot rewrite, so all changes just pile up, and fill even a 1Gb save quicker than one thinks. Ext3 or 4 is not secure, but can rewrite. Therefore only the changes (deltas) are stored. This reduces savefile-creep a lot. Using ext3 or 4 presumes ample security measures such as keeping up to date on security advisories, and configuring the browser. This is extra work, and the more servers and shares one uses, the more complicated this becomes. In addition unused ] servers and shares are still detected, and listed in security updates.

IMHO this boils down to a matter of just how one uses Puppy. Simpler requests and environments can trim a lot of servers and shares out, reducing the security load. But the browser chosen must still be configured away from default settings, which with more modern versions is complex, and time consuming.

Ultimately, once one does get the Puppy "just right" remaster is strongly advised with a burn from iso to CD or DVD. For insurance that all new stuff gets transferred to the remaster, perform 2 shutdowns b/4 the remaster attempt.

JMHO & Regards
8Geee

[sunburnt]

Hi 8Geee; These are some excellent points you raise here.
Ideally only changes ( Delta ) would be saved, making it quick.

A 64MB Save file would probably work for SFS files only.
Then again, even it may not be sufficent for a long term.