I so enjoy reading this stuff. To think how it was created "out of nothing". How brilliant minds invested time and energy into creating it...
Too bad I understand only very little of it, but yeah, still quite exciting reading about it (-:
How do live vs. installed Puppy compare in performance?
On being brilliant
Hi Marble42,
If it interests you, stick with it. The biggest mistake most people make is underestimating their ability to understand. Learning anything means taking the time to picture what’s taking place and the vocabulary to describe it. Someday, you’ll read a post and say to yourself “I knew that
If it interests you, stick with it. The biggest mistake most people make is underestimating their ability to understand. Learning anything means taking the time to picture what’s taking place and the vocabulary to describe it. Someday, you’ll read a post and say to yourself “I knew that
Hello,The beauty of, and secret to Puppy is a AUFS.
Puppy doesn't decompress everything into one layer, but a stack of layers. Difference being you can add and remove layers at will. (.sfs files etc).
This is also how Puppy's Frugal install root file system remains read only. This is why Puppy is essentially Bulletproof...
Close the Windows, and open your eyes, to a whole new world
I am Lead Dog of the
Puppy Linux Users Group on Facebook
Join us!
Puppy since 2.15CE...
I am Lead Dog of the
Puppy Linux Users Group on Facebook
Join us!
Puppy since 2.15CE...
I used a Debian Live CD to install the vmlinuz ...etc to the HDD and set grub4dos menu to boot that. Instead of using a save file or folder I opted to use a save partition ... and then proceeded to move everything out of what is in effect the main puppy sfs to the save area (partition). That meant the main sfs could be left empty (file exists but is just 4K and contains nothing). I use the same single partition as both where the /live folder (main sfs etc.) is stored, as well as being the save partition. That partition is also where grub4dos is installed.
Installed that way I can either boot frugally ... or as a full install. The main difference is that the frugal install is set to only save changes if I specifically ask to do so, otherwise all changes are lost. With full install boot, all changes are preserved as and when they occur. Mostly I boot frugally so that I boot the exact same version each and every time. As and when changes/updates occur however I can either reboot frugally (to fresh/pristine version), apply the updates and then save those changes, or boot full and apply the updates before rebooting frugally again.
That way you boot in effect factory fresh each and every time. If you store docs/data elsewhere then any changes to those docs/data can be persistent across reboots.
Performance wise there's little overall difference broadly. If you load everything into ram during bootup then it will be slower to boot, but run quickly thereafter. If you load nothing and the system reads things as-and-when needed then a program might be slow to load the first time but then is as quick as being ram loaded thereafter. Typically on more modern kit there will be sufficient memory space available to keep most things loaded in ram once read in once.
The main benefit of puppy style as I see it is being able to boot the exact same version each and every time, along with the option to be able to update that as and when required (security updates etc.). Other than that performance wise its swings and roundabouts (one quicker at booting, initially slower to load each program; The other slower to boot, quicker to run/load a program the first time that its run during a session). I'd guess that overall not loading into ram, reading as-when-used would have the overall edge as there are many files/programs that aren't used during a session and they wouldn't be read into ram, whereas loading the entire filesystem (ram boot) reads everything into ram each time its booted (whether a file/program is used during a session or not). That said, reading compressed file data (sfs style) into ram typically involves half as much IO data transfer (due to being compressed) plus decompression time, which for faster compression/decompression engines can be faster than reading twice as much IO (non compressed) data without having to decompress.
I finally settled with Debian due to their extensive repository and core stability. A concern however is that I believe in the next stable release from Debian they're moving away from AUFS and writing directly to the bottom layer may no longer be a option (i.e. puppy frugal style). That said I've seen some indications of how aufs might be installed into that forthcoming stable version ... so hopefully that moving away from aufs policy wont be a puppy style boot showstopper.
Installed that way I can either boot frugally ... or as a full install. The main difference is that the frugal install is set to only save changes if I specifically ask to do so, otherwise all changes are lost. With full install boot, all changes are preserved as and when they occur. Mostly I boot frugally so that I boot the exact same version each and every time. As and when changes/updates occur however I can either reboot frugally (to fresh/pristine version), apply the updates and then save those changes, or boot full and apply the updates before rebooting frugally again.
That way you boot in effect factory fresh each and every time. If you store docs/data elsewhere then any changes to those docs/data can be persistent across reboots.
Performance wise there's little overall difference broadly. If you load everything into ram during bootup then it will be slower to boot, but run quickly thereafter. If you load nothing and the system reads things as-and-when needed then a program might be slow to load the first time but then is as quick as being ram loaded thereafter. Typically on more modern kit there will be sufficient memory space available to keep most things loaded in ram once read in once.
The main benefit of puppy style as I see it is being able to boot the exact same version each and every time, along with the option to be able to update that as and when required (security updates etc.). Other than that performance wise its swings and roundabouts (one quicker at booting, initially slower to load each program; The other slower to boot, quicker to run/load a program the first time that its run during a session). I'd guess that overall not loading into ram, reading as-when-used would have the overall edge as there are many files/programs that aren't used during a session and they wouldn't be read into ram, whereas loading the entire filesystem (ram boot) reads everything into ram each time its booted (whether a file/program is used during a session or not). That said, reading compressed file data (sfs style) into ram typically involves half as much IO data transfer (due to being compressed) plus decompression time, which for faster compression/decompression engines can be faster than reading twice as much IO (non compressed) data without having to decompress.
I finally settled with Debian due to their extensive repository and core stability. A concern however is that I believe in the next stable release from Debian they're moving away from AUFS and writing directly to the bottom layer may no longer be a option (i.e. puppy frugal style). That said I've seen some indications of how aufs might be installed into that forthcoming stable version ... so hopefully that moving away from aufs policy wont be a puppy style boot showstopper.
As a matter of fact, they have moved already, quite awhile ago - in 2014 when OverlayFS was merged with Linux kernel 3.18. Debian just blindly adopted the mainline trend and abandoned AUFS except for the LTS Debian Jessie's kernel 3.16. In my unscientific view, that was a huge mistake. Debian Live (stretch/sid) with OverlayFS boots so painfully and indecently slowly even with systemd! And also, you don't install AUFS, it's a kernel option (either a module or built-in) and is built during compilation. https://lists.debian.org/debian-kernel/ ... 00136.htmlrufwoof wrote:... A concern however is that I believe in the next stable release from Debian they're moving away from AUFS and writing directly to the bottom layer may no longer be a option (i.e. puppy frugal style). That said I've seen some indications of how aufs might be installed into that forthcoming stable version ... so hopefully that moving away from aufs policy wont be a puppy style boot showstopper.
Re: On being brilliant
[quote="mikeslr"]Hi Marble42,
If it interests you, stick with it. The biggest mistake most people make is underestimating their ability to understand. Learning anything means taking the time to picture what’s taking place and the vocabulary to describe it. Someday, you’ll read a post and say to yourself “I knew that
If it interests you, stick with it. The biggest mistake most people make is underestimating their ability to understand. Learning anything means taking the time to picture what’s taking place and the vocabulary to describe it. Someday, you’ll read a post and say to yourself “I knew that
Thanks Ankin.anikin wrote:As a matter of fact, they have moved already, quite awhile ago - in 2014 when OverlayFS was merged with Linux kernel 3.18. Debian just blindly adopted the mainline trend and abandoned AUFS except for the LTS Debian Jessie's kernel 3.16. In my unscientific view, that was a huge mistake. Debian Live (stretch/sid) with OverlayFS boots so painfully and indecently slowly even with systemd! And also, you don't install AUFS, it's a kernel option (either a module or built-in) and is built during compilation. https://lists.debian.org/debian-kernel/ ... 00136.htmlrufwoof wrote:... A concern however is that I believe in the next stable release from Debian they're moving away from AUFS and writing directly to the bottom layer may no longer be a option (i.e. puppy frugal style). That said I've seen some indications of how aufs might be installed into that forthcoming stable version ... so hopefully that moving away from aufs policy wont be a puppy style boot showstopper.
I intend to keep good/regular backups before running updates (apt-get dist-upgrade) until Jessie migrates over to Stretch and hopefully that will take care of itself (maintain live-boot/puppy style saves functionality) ... or if not - roll back to the backup and dig deeper to figure out a workaround (perhaps a kernel module/patch).
I'm still running the official stable 3.16 kernel (as patched up by Debian)
Code: Select all
user@debian:~$ uname -a
Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1 (2016-12-30) x86_64 GNU/Linux