pets2sfsgui - convert pets to sfs and combine sfs files into one. SFSconvert to convert between 3 and 4 versionsmikeb wrote:Well one of the most pointless wrappers ever... it seems to do the same as the original command...
But regardless I was thinking more in terms of pet2sfs ... in slax I have deb2lzm and tgz2lzm for slackware which are handy tools for quick tests.
The process is so simple it hardly warrents a wrapper really... an understanding of a linux file tree and the usual unpacking tools are all thats needed.
The only other point is compatability...sfs is not backwards compatible and versions 3 and 4 are not even that...as long as the sfs is made on the distro it will be used for then there is no problem.
As it happens I build my version 3 sfs on puppy 2 so it works for all. Version 4 I do with lucid for similar reasons. mksquashfs and unsquashfs are not tied to kernel versions either so building can be done outside of the kernel needed but that will not include the ability to use such as lzma or xz to create (unpack ok)
just to fill in a few blanks.
mike
Keep your savefile slim and healthy
I think combining sfs to overcome the crappy needless limitations of puppies sfs handling is the daftest thing to come out of the puppy world. The rest is a 2 line job...unpack/pack. Also these 'wizards' leave no room to strip out the needless crud thats usually in there....a quick test before doing the job properly manually perhaps.
Was not impressed when there was the version 3 to 4 change which was not backwards compatible in order to appease the kernel gods either
yay rant over.
hotdog coaches
mike
ps ...no the daftest is using the devx files to supply tk/tcl or python or qt4 or...well really people what kind of minimalist distro is this??
pps and the kernel sources are 10 times the size needed to build drivers... is that a punishment for wanting to build yer own or something lol
Was not impressed when there was the version 3 to 4 change which was not backwards compatible in order to appease the kernel gods either
yay rant over.
hotdog coaches
mike
ps ...no the daftest is using the devx files to supply tk/tcl or python or qt4 or...well really people what kind of minimalist distro is this??
pps and the kernel sources are 10 times the size needed to build drivers... is that a punishment for wanting to build yer own or something lol
Those applications are very tiny and does just that what is wanted. Works very well and very quick. As for combining SFS files don't think it's daft at all. It's a quick fix and works without any problems whatsoever. No further changing of initrd? or whatever crap required. So if you are permanently running say JRE/wine/opera, etc. A quick combination of those sfs's into one works like a bomb. Easy fixes for laymen like me. LOLmikeb wrote:I think combining sfs to overcome the crappy needless limitations of puppies sfs handling is the daftest thing to come out of the puppy world. The rest is a 2 line job...unpack/pack. Also these 'wizards' leave no room to strip out the needless crud thats usually in there....a quick test before doing the job properly manually perhaps.
Was not impressed when there was the version 3 to 4 change which was not backwards compatible in order to appease the kernel gods either
yay rant over.
hotdog coaches
mike
ps ...no the daftest is using the devx files to supply tk/tcl or python or qt4 or...well really people what kind of minimalist distro is this??
pps and the kernel sources are 10 times the size needed to build drivers... is that a punishment for wanting to build yer own or something lol
Nah its crappy 
my smallest sfs/module is around 200k but all load in a blink of an eye and I only have to replace the 200k if there is an update. java and wine...even more reason to keep separate.
If the initrd was written well in the first place this discussion would not be happening...slax managed it 8-9 years ago...whats puppies excuse?
Lazy pup and lighthouse do it, I do it...frogs do it, dogs do it, everybody but barry does it...lets do it, lets have one application per sfs.
{mikeb does a tap dance}
Of course it won't happen...change is something to avoid unless its someone elses update.
mike.... who likes to let off steam ...
my smallest sfs/module is around 200k but all load in a blink of an eye and I only have to replace the 200k if there is an update. java and wine...even more reason to keep separate.
If the initrd was written well in the first place this discussion would not be happening...slax managed it 8-9 years ago...whats puppies excuse?
Lazy pup and lighthouse do it, I do it...frogs do it, dogs do it, everybody but barry does it...lets do it, lets have one application per sfs.
{mikeb does a tap dance}
Of course it won't happen...change is something to avoid unless its someone elses update.
mike.... who likes to let off steam ...
Just install the bloody pets or load the SFS's and then do a remaster. LOLmikeb wrote:Nah its crappy
my smallest sfs/module is around 200k but all load in a blink of an eye and I only have to replace the 200k if there is an update. java and wine...even more reason to keep separate.
If the initrd was written well in the first place this discussion would not be happening...slax managed it 8-9 years ago...whats puppies excuse?
Lazy pup and lighthouse do it, I do it...frogs do it, dogs do it, everybody but barry does it...lets do it, lets have one application per sfs.
{mikeb does a tap dance}
Of course it won't happen...change is something to avoid unless its someone elses update.
mike.... who likes to let off steam ...
nah...I want a slim core for on a stick recovery times or maybe compiling or just to have less to upload...and don't want to declog old versions and remaster again every time one program changes.
Modular is fun to be, it stops you sinking when you are at sea.
Anyway whenever I remaster there is always one daft thing left undone..... doing the whole system at once means mire chance of dismal failure.
Notice how I turn frustration into rhyme.
michel
Modular is fun to be, it stops you sinking when you are at sea.
Anyway whenever I remaster there is always one daft thing left undone..... doing the whole system at once means mire chance of dismal failure.
Notice how I turn frustration into rhyme.
michel
I only use JRE, wine and opera. Installed it and remastered. Not bothered to install anything else or run other SFS's. So, with that installed the base SFS is still only 120MB. I can live with thatmikeb wrote:nah...I want a slim core for on a stick recovery times or maybe compiling or just to have less to upload...and don't want to declog old versions and remaster again every time one program changes.
Modular is fun to be, it stops you sinking when you are at sea.
Anyway whenever I remaster there is always one daft thing left undone..... doing the whole system at once means mire chance of dismal failure.
Notice how I turn frustration into rhyme.
michel
Last edited by nic007 on Thu 30 Jan 2014, 15:59, edited 1 time in total.
hi,
how is it that my browser's cache is limited to 30 MB, but the pup_rw/root/.cache folder continuously grows? Right now it is 67.2MB. What is that amount of data over the 30 MB?
how is it that my browser's cache is limited to 30 MB, but the pup_rw/root/.cache folder continuously grows? Right now it is 67.2MB. What is that amount of data over the 30 MB?
Last edited by fobq on Mon 24 Mar 2014, 04:53, edited 1 time in total.
Didn't want to allow this very useful, simple tidbit from SFR to get lost in the shuffle - IMO, it sucessfully addresses one of a frugal Puppy's biggest shortcomings (a growing savefile), for those having difficulty with certain directories "sticking" between reboots, after being moved. From this thread - http://www.murga-linux.com/puppy/viewtopic.php?t=86187 -
Bob
p.s. - Maybe this should be added to the first post...??SFR wrote:The problem is that after moving the directory outside of the savefile and symlinking it back, we have a situation where the directory is still in the savefile (/initrd/pup_ro1/), but in tmpfs is symlink.
So, during saving the session, cp (used in snapmergepuppy) will refuse to overwrite a directory with a symlink.
BTW, perhaps it's possible, but I haven't found a way to force cp to overwrite a dir with a symlink...
A simple workaround could be:
1. Move the directory outside of the savefile.
2. Save the session (this will delete the dir from the savefile).
3. Then create the symlink in place of moved directory.
4. And save the session again.
Greetings!
Bob
well specifically its working around the shortcomings of snapmergepuppy used for usb installs ONLY to copy the tmpfs pup_rw to the save file. PUPMODE=13 relies on code that does not really do its job properly and this is one example. Not sure if its that related to the thread ,either rewrite snapmergepuppy or scrap mode 13 altogether and replacing it with something better would be a more appropriate topic.IMO, it sucessfully addresses one of a frugal Puppy's biggest shortcomings (
And well yes no real protection against a full save file and no real attempt in the default releases to reduce save file usage either. Here is a system with a shortcoming, here is a set of apps to make sure it fails at some point by over using it (ie not doing some of th ethings mentioned here) , and lets not have any protection is not a good design strategy really.
mike
A strategy that works for me is to avoid having a savefile all together because I have enough RAM (4G) and I use the cloud (Google Drive/Dropbox) and seldom save stuff locally.
I edit puppy_precise_5.7.1.sfs using editsfs.pet to....
1. bypass firstrun screens/2-barks:
> create symlink /etc/localtime to my specific timezone /usr/share/zoneinfo/America/Toronto
> create blank file /etc/personal_settings_popup_disabled
> comment out the 2-barks and welcome statements in /usr/sbin/delayedrun script
> edit /etc/xdg/template/jwmrc menu to execute "busybox reboot" and "busybox poweroff" during shutdown.
2. Add software (google-chrome and firefox in my case) and app settings/files (e.g. additional fonts, /root/.mozilla, /root/.config/google-chrome) to puppy_precise_5.7.1. sfs
3. If you've made changes to your desktop icons you will need to write the changes to puppy_precise_5.7.1.sfs also. Desktop settings are in /root/choices/ and /root/.config/
4. Configure bootloader to boot puppy with "pfix=ram"
This way, puppy will boot up entirely in RAM without firstrun popup & 2 barks, already setup for use.
It runs lightning fast because everything is in RAM.
When you reboot/shutdown, it will do it right away without prompting for a savefile.
You get a pristine copy of puppy everytime you reboot.
For me, I found it is the most efficient and cleanest way of using puppy.
I edit puppy_precise_5.7.1.sfs using editsfs.pet to....
1. bypass firstrun screens/2-barks:
> create symlink /etc/localtime to my specific timezone /usr/share/zoneinfo/America/Toronto
> create blank file /etc/personal_settings_popup_disabled
> comment out the 2-barks and welcome statements in /usr/sbin/delayedrun script
> edit /etc/xdg/template/jwmrc menu to execute "busybox reboot" and "busybox poweroff" during shutdown.
2. Add software (google-chrome and firefox in my case) and app settings/files (e.g. additional fonts, /root/.mozilla, /root/.config/google-chrome) to puppy_precise_5.7.1. sfs
3. If you've made changes to your desktop icons you will need to write the changes to puppy_precise_5.7.1.sfs also. Desktop settings are in /root/choices/ and /root/.config/
4. Configure bootloader to boot puppy with "pfix=ram"
This way, puppy will boot up entirely in RAM without firstrun popup & 2 barks, already setup for use.
It runs lightning fast because everything is in RAM.
When you reboot/shutdown, it will do it right away without prompting for a savefile.
You get a pristine copy of puppy everytime you reboot.
For me, I found it is the most efficient and cleanest way of using puppy.
slim savefile
A strategy that works for me is to avoid having a savefile all together because I have enough RAM (4G) and I use the cloud (Google Drive/Dropbox) and seldom save stuff locally.
I edit puppy_precise_5.7.1.sfs using editsfs.pet to....
1. bypass firstrun screens/2-barks:
> create symlink /etc/localtime to my specific timezone /usr/share/zoneinfo/America/Toronto
> create blank file /etc/personal_settings_popup_disabled
> comment out the 2-barks and welcome statements in /usr/sbin/delayedrun script
> edit /etc/xdg/template/jwmrc menu to execute "busybox reboot" and "busybox poweroff" during shutdown.
2. Add software (google-chrome and firefox in my case) and app settings/files (e.g. additional fonts, /root/.mozilla, /root/.config/google-chrome) to puppy_precise_5.7.1. sfs
3. If you've made changes to your desktop icons you will need to write the changes to puppy_precise_5.7.1.sfs also. Desktop settings are in /root/choices/ and /root/.config/
4. Configure bootloader to boot puppy with "pfix=ram"
This way, puppy will boot up entirely in RAM without firstrun popup & 2 barks, already setup for use.
It runs lightning fast because everything is in RAM.
When you reboot/shutdown, it will do it right away without prompting for a savefile.
You get a pristine copy of puppy everytime you reboot.
For me, I found it is the most efficient and cleanest way of using puppy.
I edit puppy_precise_5.7.1.sfs using editsfs.pet to....
1. bypass firstrun screens/2-barks:
> create symlink /etc/localtime to my specific timezone /usr/share/zoneinfo/America/Toronto
> create blank file /etc/personal_settings_popup_disabled
> comment out the 2-barks and welcome statements in /usr/sbin/delayedrun script
> edit /etc/xdg/template/jwmrc menu to execute "busybox reboot" and "busybox poweroff" during shutdown.
2. Add software (google-chrome and firefox in my case) and app settings/files (e.g. additional fonts, /root/.mozilla, /root/.config/google-chrome) to puppy_precise_5.7.1. sfs
3. If you've made changes to your desktop icons you will need to write the changes to puppy_precise_5.7.1.sfs also. Desktop settings are in /root/choices/ and /root/.config/
4. Configure bootloader to boot puppy with "pfix=ram"
This way, puppy will boot up entirely in RAM without firstrun popup & 2 barks, already setup for use.
It runs lightning fast because everything is in RAM.
When you reboot/shutdown, it will do it right away without prompting for a savefile.
You get a pristine copy of puppy everytime you reboot.
For me, I found it is the most efficient and cleanest way of using puppy.
Fully agree timothyli ..have not used a save file for years ( a save sfs for persistent changes loaded to ram) but regardless of yer methods its still worth taking steps to reduce the system space usage since that still has to work withing the limitations of save file/RAM/cloud so the information in this thread is useful generally.
mike
mike
