Savefolder without 'mount -o bind' - works
Interesting (at least to newbie me, likely not for you old hats )
Fresh puppy (frugal, ram booted). Copy /root to /mnt/puppy/sda4/root
#!/bin/bash
export HOME=/mnt/sda4/puppy/root
cd /
mv root root-orig
ln -s /mnt/sda4/puppy/root root
then restart x
Now all changes to app configurations etc. are stored in /mnt/sda4/puppy/root i.e. HDD (preserved).
I tried changing the gtk_theme, rebooted and the original theme seen, re-ran the above redirection code/script retarted jwm and the new theme showed.
)Fresh puppy (frugal, ram booted). Copy /root to /mnt/puppy/sda4/root
#!/bin/bash
export HOME=/mnt/sda4/puppy/root
cd /
mv root root-orig
ln -s /mnt/sda4/puppy/root root
then restart x
Now all changes to app configurations etc. are stored in /mnt/sda4/puppy/root i.e. HDD (preserved).
I tried changing the gtk_theme, rebooted and the original theme seen, re-ran the above redirection code/script retarted jwm and the new theme showed.
Well that sort of reproduces puppy 1 in a fashion which could only save part of the filesystem I suppose.
A save file or folder contains changes to all the system folders.
All this linking out of configs seems odd to me anyway...better to stop the configs being so large....and if yer system is a pile of links to a hard drive use a full install.
..not of puppy I may add cos thats not what its built for.
hairy knees
mike
A save file or folder contains changes to all the system folders.
All this linking out of configs seems odd to me anyway...better to stop the configs being so large....and if yer system is a pile of links to a hard drive use a full install.
..not of puppy I may add cos thats not what its built for.hairy knees
mike
Savefile/no savefile is all or nothing. With linking you have the flexibility of anywhere between the two. Modularity. My core puppy is minimal : leafpad (notes), galculator (calculator), mplayer (play/burn DVD's etc), Osmo diary/calendar etc. All booted from read only, so secure. That's expanded by a sfs load that adds in Libre Office (i.e. more advanced text editing, drawing, calculating) and Multi-Media (Openshot video editing, Blender 3D animating, Inkscape, Audacity sound editing), Again from read only medium so secure. Which is further expandable via adding in additional SFS's - Skype ...etc.
Switching (linking) enables either the fixed copy only to be used - or not, so for example load up Libre with its initial read only copy defaults, edit a document, shutdown, or for a pre-configured/adjusted version to be switched in (out), where that might be configured to particular non standard settings and where any changes to that configuration are preserved. Similar for browser. Option to use either the fixed read only copy, or switch to using a pre-configured one where the bookmarks etc from previous sessions are preserved. Most of the time I don't want any binaries/libs (core) changes to occur. The core works well and if changes/additions are required then I'll just make the changes and remaster a new core - typically infrequently. Most of the time I want application level changes to be preserved - if for instance I opt for a new choice of theme for Libre Office - typically more often.
The other factor is updates. When Libre Office is a sfs then swapping that out for another (usually later) version doesn't involve having to remaster. For instance my core puppy has no browser, so the browser used is whichever I select to load as a sfs (or download from Mozilla/wherever).
For online banking I typically boot the core read only copy, run a script that downloads the latest browser direct from the provider and surf to the banks web site using that - all 100% in (clean) ram, with no HDD's mounted. Afterwards I'll reset and load up a more general purpose arrangement that in having been more widely exposed is less secure.
With savefile (or no savefile) its all or nothing, binaries, libs, application configs etc. With linking its modular e.g. no save of bin's/lib's save of app's or ... whatever.
Sounds more complicated than it is in practice. For example for Osmo the CASE statement is
(Osmo)
cd ~
rm -rf ./.osmo
ln -s $APP_DIR/root/.osmo .osmo
/usr/bin/osmo &
exit;;
so any changes are preserved having been pointed to be the HDD version of the .osmo config files. So I either start Osmo via the normal Puppy menu, in which case (being ram booted with no save file) is the original default osmo settings where any changes aren't preserved, or I load Osmo via a gtk dialog list box, that pops up when a second taskbar button (red book) to the right of the main puppy menu button (green go button) is clicked that loads the version of Osmo where changes are preserved across reboots.
Switching (linking) enables either the fixed copy only to be used - or not, so for example load up Libre with its initial read only copy defaults, edit a document, shutdown, or for a pre-configured/adjusted version to be switched in (out), where that might be configured to particular non standard settings and where any changes to that configuration are preserved. Similar for browser. Option to use either the fixed read only copy, or switch to using a pre-configured one where the bookmarks etc from previous sessions are preserved. Most of the time I don't want any binaries/libs (core) changes to occur. The core works well and if changes/additions are required then I'll just make the changes and remaster a new core - typically infrequently. Most of the time I want application level changes to be preserved - if for instance I opt for a new choice of theme for Libre Office - typically more often.
The other factor is updates. When Libre Office is a sfs then swapping that out for another (usually later) version doesn't involve having to remaster. For instance my core puppy has no browser, so the browser used is whichever I select to load as a sfs (or download from Mozilla/wherever).
For online banking I typically boot the core read only copy, run a script that downloads the latest browser direct from the provider and surf to the banks web site using that - all 100% in (clean) ram, with no HDD's mounted. Afterwards I'll reset and load up a more general purpose arrangement that in having been more widely exposed is less secure.
With savefile (or no savefile) its all or nothing, binaries, libs, application configs etc. With linking its modular e.g. no save of bin's/lib's save of app's or ... whatever.
Sounds more complicated than it is in practice. For example for Osmo the CASE statement is
(Osmo)
cd ~
rm -rf ./.osmo
ln -s $APP_DIR/root/.osmo .osmo
/usr/bin/osmo &
exit;;
so any changes are preserved having been pointed to be the HDD version of the .osmo config files. So I either start Osmo via the normal Puppy menu, in which case (being ram booted with no save file) is the original default osmo settings where any changes aren't preserved, or I load Osmo via a gtk dialog list box, that pops up when a second taskbar button (red book) to the right of the main puppy menu button (green go button) is clicked that loads the version of Osmo where changes are preserved across reboots.
- Attachments
-
- menu.jpg
- (47.33 KiB) Downloaded 571 times
I don't use "puppys overstuffed menu" that much, mainly my own secondary less-full menu.
I never liked the main puppy menu from the start personally, all the cryptic names that are pretty meaningless to newbie's, "Text editor", "Calculator" ...etc type menu's IMO are easier.
I can see the reasoning - guiding new users to learn app/program names by having those as the first part of each menu item, followed by a brief description of that that app/program does, but even now I seem to scan/search around the menu tree quite a lot when using things that I use less regularly.
I never liked the main puppy menu from the start personally, all the cryptic names that are pretty meaningless to newbie's, "Text editor", "Calculator" ...etc type menu's IMO are easier.
I can see the reasoning - guiding new users to learn app/program names by having those as the first part of each menu item, followed by a brief description of that that app/program does, but even now I seem to scan/search around the menu tree quite a lot when using things that I use less regularly.
Try the attached pet. Is a simple modification of this pet, just to allow installation in Racy and appears to work after minimal (just rebooting...) testingninotix wrote:It would be nice to have Racy 5.5 with save folder functionality, anybody?
Backup your savefile before doing anything.
Uninstalling the pet should get you back to your previous state.
- Attachments
-
- Racy_SaveDir-1.pet
- Add save directory functionality to Racy 5.5
- (133.03 KiB) Downloaded 198 times
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==