Poem: An Improvement To Puppy

[wanderer]

hi all

this post is in part an answer to both
the perennial question of a stripped down puppy
but also a suggestion on how puppy could be improved

the heart of puppy is
1. the concept (small fast flexible full featured)
2. and all the cool apps developed by the puppy community

the puppy boot process and the use of a unionfs
are irrelevant and unnecessarily complex

my suggestion is to replace them with
apps symlinked into a ramdrive

this system is far more simple robust and flexible
than the current puppy system

probably the tinycore and dcore ramdrives
would be a good place to start
and they could be modified to include what is desired from puppy

i have no dog in this race since i am satisfied with what i use

i now use
upupbb32 (a very polished system) thanks peebee
tinycore (corepup)
and dcore (which uses the debian stretch repository)

just food for thought

wanderer

[s243a]

my suggestion is to replace them with
apps symlinked into a ramdrive

this system is far more simple

I don't think simplicity is that important here because most of the complexity is encapsulated in tools maintained by others.

robust

A layered approach helps to identify incremental changes. We can merge the layers via union sfs or alternatively we can copy and/or link the files to a seperate folder. If the links are symbolic this could be less robust if the media which the files reside on becomes unavailable.

and flexible

On advantage of a layered file system is that it's faster to add and remove layers. In contrast once the layers are merged the symlink approach would likely make reading the directories faster. Anyway, puppy doesn't require a layered file system. A full install assumes that the file system isn't layered. That said, one can also make a layered file system look like a full install. So a full install to ramdisk, would perhaps resemble the idea of a distro running in ramdisk except for the use of symlinks for installed packages beyond the base.

We can though accomplish what you want by installing packages into a sandbox. The sandbox would create a read-write layer that would capture incremental changes due to the package install, when installation is finished this layer could be unmounted and then the changes could be symlinked into the ramdisk.

probably the tinycore and dcore ramdrives
would be a good place to start
and they could be modified to include what is desired from puppy

I see that there is a bionic version of dcore. Bionic (uses libc6 2.27) is almost as new as buster (uses libc62.28-10). When I built Tiny Puduan. I should of used dcore rather than tinycore.

[s243a]

I was thinking that one advantage of the symlink approach is that it might tell us which fils are frequently used. If a file is frequently used we might be more likely to want it in ram. Each file on a Linux file system has three timestamps. One of these times stamps is access time. However, if the file is read-only I suspect that the access time isn't updated when the file is accessed. I could be wrong. However, my understanding is that symbolic links have their own timestamps. Consequently, we could get around any possible limitations with access time on read-only files by accessing them via symbolic links rather than directly.

The access time of a symbolic link can be read as follows:

Code: Select all

$stat -c --%x file or symlink

https://unix.stackexchange.com/question ... pdating-it

and this will not change the access time of the symbolic link.

[wanderer]

hi 243a

once you begin experimenting with using symlinks instead of unionfs
you will see how much better the system is

many many advantages
no whiteout files
no need for the processor to reconcile the layers
ability to load and unload compressed and uncompressed folders without rebooting
etc etc etc

but i also want to stress that symlinking to a ramdrive
is superior to the complex boot process that puppy uses

and as i have said
there is no conflict between the puppy philosophy
and using this system
if fact both can be used at the same time

the puppy init file is equivalent to the tinycore config file
and the complete boot process is generally equivalent
so only minor modifications need be made

tinycore/dcore/corepup
can be easily made to load puppy sfs files and pets
and the ramdrive can be easily opened and modified to manage puppy processes

check it out

wanderer

[williwaw]

this system is far more simple robust and flexible

simple enough for the less accomplished puppiest to jump the hurdles from user to developer ?

[s243a]

hi 243a

once you begin experimenting with using symlinks instead of unionfs
you will see how much better the system is

I don't like the word "better" here but I will experiment with it.

many many advantages
no whiteout files
no need for the processor to reconcile the layers

I presume that all this is cached so in theory, I wouldn't expect a lot of overhead. That said some file managers seem to waste a lot of resources with frequent scans of the directory and when they do so perhaps they aren't using the cache.
**I'm just guessing on the technical details here.

When such processes fail to use cache I think I/O speed is more the issue than processor resources.

That all said as I noted in a previous post it is a tradeoff between an upfront cost (the symlink approach) vs an operating cost (the aufs approach).

ability to load and unload compressed and uncompressed folders without rebooting
etc etc etc

We load and unload sfs fils all the time in a running puppy.

but i also want to stress that symlinking to a ramdrive
is superior to the complex boot process that puppy uses

One advantage that I see of a ramdrive is a faster boot. I'm not sure what other differences there might be though between a puppy running in ramdrive vs a puppy running in normal ram.

and as i have said
there is no conflict between the puppy philosophy
and using this system
if fact both can be used at the same time

If there isn't a conflict then why change it? Granted I'm all for options so it's worth exploring other PUPMODE options.

the puppy init file is equivalent to the tinycore config file
and the complete boot process is generally equivalent
so only minor modifications need be made

I don't want to get lost in the weeds here but I'm sure that both processes do a lot of similar things.

tinycore/dcore/corepup
can be easily made to load puppy sfs files and pets
and the ramdrive can be easily opened and modified to manage puppy processes

check it out

wanderer

I will. I have a different use-case in mind though. I'm thinking of using dcore as the base of a sandbox for maybe something like a chrooted web browser that can run on older puppies. Other functionality could be built into the sandbox like Scottman's package manager (i.e. package), and maybe tools to load pets/sfs files by links as an alternative option to the standard puppy way.

[wanderer]

hi williwaw

yes simple enough for anyone to use and develop
even me

try it

i am going to turn dcore stretch into corepup 9
dcore is actually the better system
and puppy tinycore and dcore
can all be merged together

will post more on the corepup thread

wanderer

[s243a]

hi williwaw

yes simple enough for anyone to use and develop
even me

try it

i am going to turn dcore stretch into corepup 9
dcore is actually the better system
and puppy tinycore and dcore
can all be merged together

will post more on the corepup thread

wanderer

The advance that I see with dcore is that the libs are more compatible with debian/ubuntu (and therefore puppy). The downside I see is that it doesn't come with a window manager. The 16MB tinycore release comes with a window manager but doesn't match the glibc releases of debian/ubuntu.

[wanderer]

try dcore-plus
it has a window manager

but a whole bunch of window managers can be easily added
including corepup-jwm
a very stripped down version of jwm i use for corepup

wanderer

[wanderer]

i put dcore-plus and dcore
in the corepup respository
so they are easy to get to

wanderer

hey i like the poem thing

[mikewalsh]

I'd say I'm no longer a 'typical' Puppy user.

RAM ain't an issue - currently 16 GB, soon to be 32 GB in the next couple of days. Storage amount is now so OTT as to be ridiculous - previously around 1.5 TB (including external HDDs), now approaching 5 TB (and that's just the internals)! And my Pentium Gold - 'Coffee Lake' dual-core w/HT, so quad core really - at nearly 4 Ghz is plenty fast enough for me.

But although I could now run anything I wanted, I still stick with Puppy, 'cos it does everything I need from it. Plus, I know what I'm doing, and love 'tinkering' with it..... She works fine for me just the way she is. Most of the 'hard' work was done years ago, by BK (for whom I have the utmost respect) and the 'early' Puppy community. And we still have a very talented, 'core' group of developers/enthusiasts who unstintingly give of their very best.

"Horses for courses", I guess. This community's got a lot of life in it yet.....and still manages to come up with novel approaches to many of the perennial issues.

I shall always be a fan.

Mike.

[s243a]

i put dcore-plus and dcore
in the corepup respository
so they are easy to get to

wanderer

hey i like the poem thing

I also see that there is a dcore-plus_bionic, which is newer than stretch:

http://mirror.cpsc.ucalgary.ca/mirror/t ... re-bionic/

The problem is that core-Plus is much larger than TinyCore, but perhaps it can be trimmed to only include the FLTK/FLWM graphical desktop environment.

That said if core-Plus includes more than one window manager on the ISO, I should remember that only one of these will be loaded into ram (e.g. the symlink approach.)..or so I think. I still need to try it.

[wanderer]

dcore-plus stretch is a good place to start
because it includes a window manager and wifi
but it can be stripped down to the size of dcore

i am going to use dcore stretch
because i like debian
and dont trust ubuntu

no need for the most up to date version
because we want something stable to work on
and we are going to modify it to our needs anyway

wanderer

[wanderer]

yes mike

i love puppy
will always be a fan
my primary distro is upupbb32 (thanks peebee)

but trying to improve puppy

i have a new computer with i7 and 32 gigs of ram
cant wait to try puppy on it

wanderer