SFS files vs program folders: test results are in!

Using applications, configuring, problems
Post Reply
Message
Author
User avatar
mikeslr
Posts: 3890
Joined: Mon 16 Jun 2008, 21:20
Location: 500 seconds from Sol

SFS files vs program folders: test results are in!

#1 Post by mikeslr »

Hi All,

Pets vs. SFSes vs. Program Folders? And the winner is Program Folders! Maybe.

As the attached Chart Shows, Program Folders use less of your computer's resources, which means they can more efficiently be run on computers with less resources. This is particularly important if limited RAM is a concern. Or the size of your SaveFile: note in particular that to successfully install LibreOffice as a pet required 500 megs of a SaveFile just for itself, requiring the SaveFile to be resized from 512 to 768 Mbs. Only SFSes use available Hard-drive (including USB-Key drives if you have that type of installation) space more efficiently. Using 01micko's Get-LibreOffice pet to download LibreOffice4 created a 144 Mb SFS in xz compression. Converting to gz compression resulted in a 173 Mb file. Decompression resulted in a folder occupying 543 Mbs of harddrive. But is Hard-drive space a significant concern today? Similarly, Program Folders make fewer demands on one's CPU.
Perhaps this is why there are advocates of Full Installs. Like Full Installs, the files in Program Folders are not compressed. Or why Kirk and Jamesbond have developed the use of a Save Folder as an alternative to a SaveFile in Fatdog64?
So why the “Maybe
Attachments
Comparison.png
Comparison of System Usage by Pets, Sfses & Program Folders
(105.06 KiB) Downloaded 1354 times
Last edited by mikeslr on Thu 04 Apr 2019, 23:27, edited 2 times in total.

User avatar
cowboy
Posts: 250
Joined: Thu 03 Feb 2011, 22:04
Location: North America; the Western Hemisphere; Yonder

program folders post

#2 Post by cowboy »

mikeslr,

I shudder when I think of the time this must have cost you - just wanted you to know that your experiments, and explanations, of the uses of program folders are great reading.

I appreciate the efforts that you make in discovering more efficient ways to operate in Puppy. Always pleased to see a "mikeslr" post on the forum.

Thanks.
[i]"you fix what you can fix and you let the rest go.."[/i] - Cormac McCarthy - No Country For Old Men.

User avatar
mikeslr
Posts: 3890
Joined: Mon 16 Jun 2008, 21:20
Location: 500 seconds from Sol

LibreOffice4 Progrm Folder Crash

#3 Post by mikeslr »

Hi Cowboy,

Thanks for the appreciation.

LibreOffice4 run from a program folder crashed in both Precise and retro-precise. It didn't in Thin Slacko. I don't know if the problem is with the build, the Pup or other. So on my desktop, where resources are not an issue,
Edit: LibreOffice4 both as an xz SFS and as a Program Folder crashed in Exprimo. I've reverted to 3.6.3 gz SFS.
I do strongly recommend FreeOffice for use when resources are limited. It was designed to run "as a portable" --from a folder-- which only occupies 99 Mbs of disk space. Think Puppy from a USB-Key. Reads and writes Microsoft file format, although the first time you save a document you'll have to select other than its native format. If set as default, clicking an ".odt" text document, an ".odg" presentation or an ".xls" spreadsheet will open it, but doesn't recognze the ".ods" --default Libre/OpenOffice-- spreadsheet file format however you try to open it.
Other than the perversity of Microsoft and others, I don't know why .xls isn't the default spreadsheet format in all spreadsheet apps. Or for that matter, there isn't a universally used file format for text and presentation files. It's not like graphic, sound and video where formats indicate different compression or containers used, is it? Who buys/uses business applications because of the unique file formats of their applications?

mikesLr

Pelo

mikeslr that is real good work,full study.

#4 Post by Pelo »

mikeslr that is real good work,full study. I use SFS a lot, but Libre Office, quite never (version Windows in case of need, in a far future)
"whereas,
Care of CPU, this is where apps fail or not. RAM is there to help, use it.
basic Linux idea is that unused memory is wasted memory.
" And i agree with that. ".so it
is typical in Linux to see RAM full or near full all the time...and,
it will stay that way, and dump out the oldest stuff as soon as
something _new_ is opened which needs space.." to Swap, is existing..

RAM is a Out house, the cooker needs the more as possible untill the cooker can open the fridge door or the oven. Or in an aircraft it would be the Cargo compratment, that avoid the pilot to land to load some food or kerozen.

I load as SFS full distro , (famous underdog) and its rare that my laptop crashes. It happened with my acer aspire 512mb RAM. But with 512MB RAM Libre office will crash as soon you work with a document with some 'mise en page', i mean titles, graphics and images included. Not because of RAM, Processor (only one often) cannot manage all changes to do just by typing a new line, that will change pages, summary and so on..

The problem with a suite, it's when only writer is needed.. if ever it is needed by Puppy users. Never writer will knock down processors... Look how big is writer in Libre Office..
Often processors are too busy at upload, opening docs, but not after..
Libre Office is very slow, but more with calc.. Or Big documents, with images included..But Microsoft office was not better.. Word suddenly garbled everything, when i was at the office.
Don't deny Abiword, because it is a light text maker, processors will loose the thread later..

Try not to include Java.
"Libreoffice calc uses all memory until operating system freezes, when using external references to websites" official bug in
Then when your document is 5GB, of course it is needed to upload it full in RAM, spreadsheet or text, if your RAM is 4GB, processors cannnot send anything to swap.

foxpup
Posts: 1132
Joined: Fri 29 Jul 2016, 21:08

#5 Post by foxpup »

Nice work mikeslr! What hard work!

It confirms a lot of my impressions.

I used to use LibreOffice a lot. I used it with Wary5.5. The last version of LO for Wary is the last 5.0.1 version iirc, because of general lib issues.
I also preferred the portable mode: just unpack on /mnt/home/ in a folder and copy .desktop files into /usr/share/applications. The .desktop files need some editing to define the correct paths. That's all.
Firefox is similar! And there is also the fine firefox-portable from Shinobar that helps you to set it up.

One other reason I like portable is this: I always have a few puppies installed (frugally) to choose from. They can all use the same portable! Well not entirely, it depends a bit: 32 or 64 bit, more recent or older puppies, but in general, a lot of puppies can share the same portable.

For java in LibreOffice: it is rarely needed except for the database.
mikeslr wrote:Like Full Installs, the files in Program Folders are not compressed. Or why Kirk and Jamesbond have developed the use of a Save Folder as an alternative to a SaveFile in Fatdog64?
Savefiles are not compressed either, are they? One advantage of a folder over a file that I can think of, is, you do not need to resize, the size is not fixed.

User avatar
mikeslr
Posts: 3890
Joined: Mon 16 Jun 2008, 21:20
Location: 500 seconds from Sol

#6 Post by mikeslr »

Hi foxpup,

Well, a SaveFile, having a fixed size, isn't, itself, compressed. But the files you install into them are. Hence the acronym "sfs" --squashed file system. The compression and decompression take place 'behind the scene' managed by Puppy when you've chosen a Frugal Install.

If you compare the size of an SFS to that of a pet of the same application you might not realize that SFSes are compressed because pets are also compressed.

Usually, gzip compression is used. This chart will provides some idea of how much compression takes place, and also the time and computer resources involved. https://catchchallenger.first-world.inf ... LZ4_vs_LZO. The time and memory factors were one of the reasons a "Full Install" was developed to be used by those computer systems which have less than 256 Mbs of RAM.


mikesLr

Peterm321
Posts: 411
Joined: Thu 29 Jan 2009, 14:09
Location: UK

#7 Post by Peterm321 »

A while ago I recompiled mksquashfs to use gzip with compression level 1. The default compression was slow. For a relatively small increase in SFS size, thje time taken to make the SFS was greatly reduced. I presume there might be some benefit in using fast compression: faster decompression, eg if using SFS to store an archive of programs. I never did any benchmarking to be sure.

The disadvantage of the version I uploaded is that it does not support xz / bzip etc compression.

http://murga-linux.com/puppy/viewtopic.php?t=89173

User avatar
LazY Puppy
Posts: 1934
Joined: Fri 21 Nov 2014, 18:14
Location: Germany

#8 Post by LazY Puppy »

Peterm321 wrote:A while ago I recompiled mksquashfs to use gzip with compression level 1. The default compression was slow. For a relatively small increase in SFS size, thje time taken to make the SFS was greatly reduced. I presume there might be some benefit in using fast compression: faster decompression, eg if using SFS to store an archive of programs. I never did any benchmarking to be sure.

The disadvantage of the version I uploaded is that it does not support xz / bzip etc compression.

http://murga-linux.com/puppy/viewtopic.php?t=89173
I'm still using it in all my 32bit derivatives!

Would be cool to have a 64bit version?
RSH

"you only wanted to work your Puppies in German", "you are a separatist in that you want Germany to secede from Europe" (musher0) :lol:

No, but I gave my old drum kit away for free to a music store collecting instruments for refugees! :wink:

Pelo

Highly compressed does not mean less RAM,

#9 Post by Pelo »

Compressed means less size for storage, generally by removing all blanks (not only). like the air of inflatable boats, you will have to blow to re-inflate.
Is the question really a problem ? I like SFS. When choice if offered i choose SFS. Pet only if stuff is needed permanently. So you could understand why i am against Libre Office included in ISOs, huge ISOs that needs time to download. L.O is not only writer, even if you don't use calc, maths, and databases. We know that, look at 'business' chapter of the forum.
if you need writer, use Abiword or tiny text makers. 7MB i/o 250, no need to flat and unflat. to zip and unzip, that will slow your computer and get your old processor explode at opening your old laptop.
Highly compressed does not mean less RAM, it means lot of work.
SFS on the fly should be unmounted when shutdown.
Use tools for Puppy, i know this is not easy nowadays. Debian Packages are raw... nobody to trim the fat. Libre office should be trimmed too. We don't need the English dictionnary as we don't type in English, if ever we had to type. PuPPy Linux users are not office workers. Devs, please stop playing businessmen.. Nobody use Puppy to work. To play developpers, yes, there are a lot (not so many, 200 ?)
Use light OOo. Not enough for you ? wait for the passengers claims,
Sfs Kde Office is 47MB.. well it is full of bugs.

Pelo

computers with 256Mb RAM...?

#10 Post by Pelo »

computers with 256Mb RAM.... with 512MB on my Acer Laptop. It is difficult to have fun. Compression has nothing to do, everything has to be decompressed to run. That is more work, not less. :evil:

Peterm321
Posts: 411
Joined: Thu 29 Jan 2009, 14:09
Location: UK

#11 Post by Peterm321 »

LazY Puppy Wed 23 Aug 2017, 22:50 wrote: Would be cool to have a 64bit version?
It would have to be compliled in a 64 Bit Puppy to work.

With 2GB of RAM, I have never even tried a PAE / 64 Bit OS of any
type, never mind downloaded one with the DEVX module which would be
needed for compiling.

But the hack (if even you could call it a hack) was simplicity itself.
If memory recall is right, a change to just one line of code. NB to
replace the default gzip compression of 9 to 1. If you knew where that
9 was (presumably an INT or SHORTINT 32/16 bits) it might be
adjustable by binary editor.

User avatar
mikeslr
Posts: 3890
Joined: Mon 16 Jun 2008, 21:20
Location: 500 seconds from Sol

Program Folders -- Still Useful, but not as much

#12 Post by mikeslr »

Hi All,

Thanks pelo and foxpup for digging up this old thread. IIRC, it predates gyro's development of SaveFolders which may be why tests using SaveFolders weren't conducted.

Unlike a SaveFile, which has a fixed size and whose content is compressed, a SaveFolder has no fixed size --starts small, and as entries into it are made expands automatically to, if necessary, the entire available space of the partition/drive on which it is located-- and the contents you install aren't compressed.

Consequently, many of the benefits derived from using a Program Folder can be obtained simply by using a SaveFolder rather than a SaveFile.

Additionally, the amount of RAM in (or which can be installed into) modern computers has reduced the advantage. IIRC, the computer I ran the test on had 4 Gbs of RAM. My current Desktop has 8 Gbs. How much significance does an additional 100 or so Mbs (or even 500 Mbs) of RAM for applications usages have?

There remain some circumstances where I recommend the use of Program Folders even when a SaveFolder is used. My experience has been that despite taking every precaution I could think of to prevent applications from being automatically written to a SaveFolder --remove Automatic Save, configure PPM to install to /tmpfs-- occasionally and randomly some applications or (worse yet) parts of applications were automatically written to SaveFolders. More an annoyance than anything else, as I haven't known those occasions to actually cause problems. But, obviously, if in building a yet-to-be-tested application it never was permitted to install anything, even that annoyance would have been avoided.

My current practice, therefore, is to primarily use SFSes of large applications; especially when they've been packaged by someone else. :)

Tahrpup64 and Xenialpup64 (and their remasters) don't manage multi-architecture systems (64 +32 bit) and their libraries the same way as the Ubuntus whose binaries were used in building them. A program folder, like an SFS, isolates an application's libraries from the folders of a Puppy's shared libraries. Such isolation may enable the application to locate the libraries it requires.

I find several applications which can be 'run without installing' useful. Among those are blender, cool-reader, foxitreader, and masterpdfeditor. Basically, you just download their respective package, decompress it anywhere, and click its executable/binary*. [Discussions elsewhere on how to create menu entries or run by dragging binary to desktop]. When a new version is available, I can try it out without overwriting the old version. So, essentially, they have already been structured as 'Program Folders' and the only reason I can think of for including them within a Puppy --such as in /opt-- would be to make it easy to include them in a remaster.

mikesLr

* Some of these have as dependencies Qt or other libraries. I do install those libraries. Still, running a 'pre-packaged' application which requires the installation of a few libraries is easier than having to build it from scratch.

Pelo

to remember

#13 Post by Pelo »

"I find several applications which can be 'run without installing' useful. Among those are blender, cool-reader, foxitreader, and masterpdfeditor"

Post Reply