Puppy Linux Discussion Forum

hi 666philb and everyone

i would like to try to make a more minimal modular form of fossapup64 from woof-ce

that is get woof-ce to build just

1. an iso with only the initrd and an empty main.sfs file
2. an iso with iso 1 + a main sfs file that only contains basic x jwm and an xterm

so that one can start with the very basics and add applications as sfs files

thanks

william

So you want it to have less than it already has?

puppy_fossapup64_9.5.sfs 97mb
a basic system that boots to desktop. no dri drivers, no apps apart from dillo, urxvt & leafpad

I am not sure about just adding a bunch of SFS packages, to the layered file system.
I really wonder, if it has ever been fully tested.
If there may be a limit, to how many layers, you can have it.
So far, I have found statements that say:

AUFS has a hard limit of 127 layers.

hi bigpup

yes i want to start from the bare minimum

i actually will break it down further
separating out the window manager and xterm

if i have any issues with unionfs

i will just use symlinks which have little overhead and no limits

william

when i work things out
i will have the gurus push these new functions
into the woof-ce master
so anyone can build a minimal modular distro from woof-ce

you will also be able to use a local repository
so you don't have to use woof-ce or git to build a puppy

this will just be an additional function for woof-ce
im not changing the woof-ce system

william

so now i have to relearn woof-ce
so i can modify the files that specify what is added to the build

william

aufs man page says: The maximum number of branches is configurable at compile time (127 by default)

I suspect that could be increased at compile time though I don't know and 127 seems a fair number.

Another factor is the maximum loop devices allowed. Was 255 I believe, but can be configured to be in the millions since kernel 3.1:

https://unix.stackexchange.com/question ... nux-kernel

I don't know how current above is though - these things change sometimes with kernel development.

I'm not sure what if any limit there is in the number of layers allowed for overlayfs. Can't find it mentioned in kernel overlayfs readme so I'm assuming it is dynamic and unlimited, but maybe not... Interested to know.

hi wiak

the unionfs is inherently weak and limited
i dont really intend to use it as the main mount system long term
but since woof-ce is built that way i will start with it

yet another way to link things is to have one image with multiple application folders inside
you only need one loop device to link the image
and then you can symlink each application folder in the image individually to root
the image can be either compressed or uncompressed

almost infinite possibilities with symlinks

william

Looking forward to see what you come up with!

Ok,

I have now created the initrd.gz for FossaPup64 9.5 and it seems to run all just fine.

Now I need people doing testings after I found a good place where to upload.

I don't want to spread this all over the forum until there's nearly a release of Community Puppy.
So please, send me a PM and I will send you a link for download.

More details by PM...

Btw.: how is the Community Puppy going to be called by name?

In the past CE was used for 'Community Edition', but that was just a remaster of official release. This is quite a different pup being described as 'Minimal Modular'. Perhaps FossaMMpup64?

MM then becomes like a brand extension that can be used with other releases too, without having to think about it and to show consistency of idea.

And it is not to large an extension to official pup name scheme.

Another reason not to go with the likes of 'Community' branded CE is that if the idea/release became dominant in terms of what people want to see then it could become mainline official one day (not saying it will, but there is always that possibility). Despite current puppylinux.com FAQ in terms of woof-CE being the one distro to rule them all..., nothing is (or nothing should be) set in stone, and the MM might end up merged into woof-CE anyway.

wanderer wrote: ↑Sat Mar 13, 2021 11:09 pm

hi 666philb and everyone

i would like to try to make a more minimal modular form of fossapup64 from woof-ce

that is get woof-ce to build just

1. an iso with only the initrd and an empty main.sfs file
2. an iso with iso 1 + a main sfs file that only contains basic x jwm and an xterm

so that one can start with the very basics and add applications as sfs files

thanks

william

hi @wanderer ,

fossapup is part way there if you remove the adrv.sfs. this gives you a pretty barebones pup
if you use woofce to build fossapup and remove "zz_adrv" in DISTRO_PKG_SPECS you will get a 97mb pup.sfs.

want smaller ..... start removing stuff from DISTRO_PKG_SPECS

thank you 666phib and everyone

i will try your suggestions

as i said i want this project to be just an extension of woof-ce

1. to make things more accessible to non woof-ce folks (so they can build a puppy from woof-ce quickly and easily)
2. as well as making system that can be built up from a minimal base (so people dont have to ask how they can remove things to get down to a minimal base)

and as posted many more advantages to a minimal modular system

my system will use symlinks and not a unionfs
and will have a script to mount and link/unlink sfs and other files to root

as i understand it taersh is making an initrd that will handle loading things using a unionfs

both a unionfs and symlinks can be used together

william

666philb wrote: ↑Sun Mar 14, 2021 10:58 pm

fossapup is part way there if you remove the adrv.sfs. this gives you a pretty barebones pup
if you use woofce to build fossapup and remove "zz_adrv" in DISTRO_PKG_SPECS you will get a 97mb pup.sfs.

want smaller ..... start removing stuff from DISTRO_PKG_SPECS

97MB is pretty small, though firmware (plus browser dependencies of course) nowadays does tend to be the module that swells up a distro's size.

There are some likely improvements that are not so achievable out of the box. For a start, I presume that pupXXX.sfs comes with JWM/Rox combination rather than allowing for alternative window manager/file-manager choices (such flexibility being a major point of modularising the system overall).

Also, though they are small in size, it is painful to having a specific selection of old Puppy P_apps/utilities forced on users and clogging up the desktop menu of choices (PFind, Pmusic and whatever other "someone's favourite app creation" unnecessarily glued into woof-CE core). Better if all such were kept separate so could be added in optional module or not - better for these old bash/gtkdialog-based apps and similar for stuff like that just to be obtainable as dotpets (i.e. purely optional). Does removing the adrv get rid of them all? To be a community distro, all forum members should be encouraged to create apps/utilities that can be officially published via add-on modules of some sort or another instead of ignoring most and allowing privileged woof-CE users to forcibly include theres'.

There are countless other utilities and apps many would prefer to actually use I'm sure. Or can they be de-selected via DISTRO_PKG_SPECS too?? - what the core should contain is core Puppy system files only - not all these wee programs that should be optional at best.

Certainly an initrd such as taersh has produced is the main thing necessary to allow better modularisation via sfs filesystems.

hi wiak

i agree only the minimal base puppy stuff should go into
iso 1 - initrd only
iso 2 - x jwm xterm

you can add what you want later

i envision 2 base distro specs templates
that will allow the building of iso 1 and 2

and further distro specs templates
that will allow you to put more stuff in

in addition as i understand it taersh's initrd will allow you to choose what sfs files you want to load via a unionfs
and my script will allow you to load the files you want to via symlinks

should be very flexible and adaptable

william

wanderer wrote: ↑Mon Mar 15, 2021 2:51 am

i envision 2 base distro specs templates
that will allow the building of iso 1 and 2

and further distro spec templates
that will allow you to put more stuff in

in addition as i understand it taersh's initrd will allow you to choose what sfs files you want to load via a unionfs
and my script will allow you to load the files you want to via symlinks

should be very flexible and adaptable

Yes that would be very flexible though I doubt additional distro_spec templates are really required, but whatever... Any such template tends to remove flexibility unless they force no particular content but simply a format for inclusion rather than any set-in-stone published listings.

hi wiak

not set in stone

you choose the template you want
or make your own

just allows people (like me)
who dont know what components are required
to see a list of what is needed for each build

william

Question.
How is someone going to pick what they want?

Say I install the minimal Puppy.
Seems I would need to be able to access the internet, to download, and use, added stuff.
A program like Quickpet in Fossapup64 9.5, can do this.
As long as everything is located in a repository it knows to look in.
May want to look at Quickpet code to see how it does stuff.

But, you still need whatever is required, to make a network connection, with your network hardware.

I think you need to pick one of the newest Linux kernels 5 series to use.
But, that is more about how old a computer are you supporting.
I think, a series 5 kernel, will still provide support, for any computer, built around a duel processor.
I guess you could always use change_kernels, to use a older kernel, if needed. If change_kernels is in the minimal sfs.
Well, I guess you are going to use the kernel, that is in Fossapup64 9.5.

hi bigpup

you have bought up the key issue

what do you need for each build

the only way i can think is for a guru
to make various templates of distrospecs for each build

right now i am only interested in the 2 primary builds
1. initrd only
2. x jwm xterm

so i am playing with distrospecs to make these
but it is hit and miss
and a big waste of time

that is the problem
woof-ce was not designed to be modular
but to lump everything into one blob

its all very interesting
but without someone who knows what is needed for each build of woof-ce
i could be doing this for a very long time

william

wanderer wrote: ↑Mon Mar 15, 2021 7:36 am

hi bigpup

you have bought up the key issue

what do you need for each build

...

its all very interesting
but without someone who knows what is needed for each build of woof-ce
i could be doing this for a very long time

william

Well, it is bigpup that started the thread: "It is time to develope a truely community version of Puppy!!!" viewtopic.php?p=18799#p18799

and it was yourself wanderer who started the thread "minimal modular woof-ce puppy" viewtopic.php?p=18391#p18391

I presume that meant either or both of you were planning to build something. Otherwise what is the point or you (both) starting such threads. In the do-ocracy claimed for Puppy Development no-one is planning to do anything for anyone else per se. So telling developers it is time for them to put their heads together and come up with something you feel should exist is hardly likely to get anyone doing that for you.

If you are just wanting to follow what happens at woof-CE already, then nothing needs to be done anyway.

One thread to discuss possible futures for Puppy is nice, but several becomes too many and especially if the thread starters are not actually building anything. Certainly I see the problem you face, but your ideas alone do not themselves create projects - if you can't do it yourself you need to get someone to agree to do it for you and that may not happen.

One good thing, however, is probably taersh's initrd since standard Puppy initrd is poor in its abilities to handle more than a few sfs addons at boot time. That at least should provide some of the versatility you wish for. Beyond that, I suggest you simply both try to simply build something (anything) that might be useful to use with current Puppy and take it from there. It isn't too hard to assemble dotpets from existing packages or sfs files for that matter - these are a form of 'module', so all you need is taersh's initrd, a slimmed down Puppy, and then anyone can build such modules. Maybe not as much as you desire, but all such systems develop as more gets added.

EDIT: For you at least, as you've said long time ago wanderer, tinycorelinux packages are actually squashed filesystems. With taersh's initrd you could, for example, experiment with layering these into a (possibly slimmed down) Pup, and take it from there. i.e. some kind of merged Puppy/tinycorelinux system. Whether it works great or not is besides the point - such attempts to modularise would certainly be interesting (and there is indeed nothing around quite so modular as tinycorelinux).

i agree wiak

what i am doing is strictly for my own amusement
and so is done at my own pace

as for the community puppy
well thats for the community

i have been around long enough not to expect others to do my work

probably i should have not posted this idea on the community puppy thread
but i do think that making things more accessible to the community
would help with a community project

that being said this topic has been moved to its own thread
and there it will stay

i will continue to learn and play with woof-ce
and maybe something will come of it
or maybe not
either way no loss

hopefully taersh's initrd will be useful in the community puppy

for me the most important thing is that it has all been interesting and fun

william

wanderer wrote: ↑Mon Mar 15, 2021 7:36 am

hi bigpup

you have bought up the key issue

what do you need for each build

the only way i can think is for a guru
to make various templates of distrospecs for each build

right now i am only interested in the 2 primary builds
1. initrd only

This is slightly confusing because puppy's initrd is very basic busybox only, where-as even tinycore's initrd has more built into it such as glibc.

2. x jwm xterm

Are you suggesting that all cli tools be built into initrd?

so i am playing with distrospecs to make these
but it is hit and miss
and a big waste of time

that is the problem
woof-ce was not designed to be modular
but to lump everything into one blob

You can have more than on "blob" or "module" in woof-CE e.g. fdrv adrv, devX etc.

wiak wrote: ↑Mon Mar 15, 2021 8:16 am

wanderer wrote: ↑Mon Mar 15, 2021 7:36 am

hi bigpup

you have bought up the key issue

what do you need for each build

...

its all very interesting
but without someone who knows what is needed for each build of woof-ce
i could be doing this for a very long time

william

Well, it is bigpup that started the thread: "It is time to develope a truely community version of Puppy!!!" viewtopic.php?p=18799#p18799

and it was yourself wanderer who started the thread "minimal modular woof-ce puppy" viewtopic.php?p=18391#p18391

I presume that meant either or both of you were planning to build something. Otherwise what is the point or you (both) starting such threads. In the do-ocracy claimed for Puppy Development no-one is planning to do anything for anyone else per se. So telling developers it is time for them to put their heads together and come up with something you feel should exist is hardly likely to get anyone doing that for you.

If you are just wanting to follow what happens at woof-CE already, then nothing needs to be done anyway.

One thread to discuss possible futures for Puppy is nice, but several becomes too many and especially if the thread starters are not actually building anything. Certainly I see the problem you face, but your ideas alone do not themselves create projects - if you can't do it yourself you need to get someone to agree to do it for you and that may not happen.

I think it is good to have a second thread to discuss wonder's ideas to avoid derailing the "It is time to develope a truely community version of Puppy!!!" thread. It isn't that these ideas couldn't be discussed in said thread but there seems to be much more discussion about @wanderer's ideas then the original topic of that thread. As a consequence it is better to have two threadsto avoid derailing that thread. This is in part because wanderer is passionate about this topic.

One good thing, however, is probably taersh's initrd since standard Puppy initrd is poor in its abilities to handle more than a few sfs addons at boot time. That at least should provide some of the versatility you wish for.

For sure. I should see if taersh wan't this merged into woof-CE yet. I haven't sent a PM yet because I have a few things that I'm working on at the moment.

Beyond that, I suggest you simply both try to simply build something (anything) that might be useful to use with current Puppy and take it from there. It isn't too hard to assemble dotpets from existing packages or sfs files for that matter - these are a form of 'module', so all you need is taersh's initrd, a slimmed down Puppy, and then anyone can build such modules. Maybe not as much as you desire, but all such systems develop as more gets added.

This would certainly be good starting point because it would help us identify what we want in these modules and it is less daunting a task then trying to build all these modules from woof for a completely new puppy. The woof approach is more daunting in part because of the learning curve and also because it might require some modification to work the way that wanderer wants.

EDIT: For you at least, as you've said long time ago wanderer, tinycorelinux packages are actually squashed filesystems. With taersh's initrd you could, for example, experiment with layering these into a (possibly slimmed down) Pup, and take it from there. i.e. some kind of merged Puppy/tinycorelinux system. Whether it works great or not is besides the point - such attempts to modularise would certainly be interesting (and there is indeed nothing around quite so modular as tinycorelinux).

For the tiny core concept to work, one doesn't need to be running in an initrd type-ish file system. The same principles could be applied after switch-root. Consequently, I agree with you that wanderer's concept can be started with taersh's init.

wiak wrote: ↑Mon Mar 15, 2021 2:39 am

666philb wrote: ↑Sun Mar 14, 2021 10:58 pm

fossapup is part way there if you remove the adrv.sfs. this gives you a pretty barebones pup
if you use woofce to build fossapup and remove "zz_adrv" in DISTRO_PKG_SPECS you will get a 97mb pup.sfs.

want smaller ..... start removing stuff from DISTRO_PKG_SPECS

97MB is pretty small, though firmware (plus browser dependencies of course) nowadays does tend to be the module that swells up a distro's size.

There are some likely improvements that are not so achievable out of the box. For a start, I presume that pupXXX.sfs comes with JWM/Rox combination rather than allowing for alternative window manager/file-manager choices (such flexibility being a major point of modularising the system overall).

Also, though they are small in size, it is painful to having a specific selection of old Puppy P_apps/utilities forced on users and clogging up the desktop menu of choices (PFind, Pmusic and whatever other "someone's favourite app creation" unnecessarily glued into woof-CE core). Better if all such were kept separate so could be added in optional module or not - better for these old bash/gtkdialog-based apps and similar for stuff like that just to be obtainable as dotpets (i.e. purely optional). Does removing the adrv get rid of them all? To be a community distro, all forum members should be encouraged to create apps/utilities that can be officially published via add-on modules of some sort or another instead of ignoring most and allowing privileged woof-CE users to forcibly include theres'.

There are countless other utilities and apps many would prefer to actually use I'm sure. Or can they be de-selected via DISTRO_PKG_SPECS too?? - what the core should contain is core Puppy system files only - not all these wee programs that should be optional at best.

Certainly an initrd such as taersh has produced is the main thing necessary to allow better modularisation via sfs filesystems.

Maybe then a starting point is to first strip out JWM/Rox to get a slightly smaller base_sfs and then work on a module for a given "window manager, filemanager, desktop" combination.

I'm looking at the dependencies for jwm and rox-filer. At the moment I don't see anything obvious to strip out with these two items except for the terminal. JWM depends on:

rxvt-unicode-256color
dummy transitional package for rxvt-unicode
or rxvt-unicode
RXVT-like terminal emulator with Unicode and 256-color support
or rxvt-unicode-lite
dummy transitional package for rxvt-unicode
or gnome-terminal
GNOME terminal emulator application
or konsole
X terminal emulator
or x-terminal-emulator
virtual package provided by [show 22 providing packages]

But I suspect that this isn't a hard dependency and that other terminals could be made to work without recompiling such as lxterminal. Not sure if the terminal should be lumped in with the window-manager/desktop.

hi everyone

i suddenly realized what should have been obvious to me from the first

there is no need to have more than 2 base templates for distro specs

1. the initrd iso

2. the base x iso

everything else can be added as sfs files made from pets

which would be the natural way to add things anyway

im sure that in time even by trial and error i can make them

and i am working on that now

william

you can add more to the initrd
to have a more complete set of shells and support stuff
but you dont really need to
you can add more shells and support stuff by adding sfs files

likewise with the basic x sfs

but this means you are only working on 2 small parts of woof-ce
much simpler to work with
super fast to build

william

it would be nice to have a script that made pets into sfs files
so they can be used as modules
but that can come later

william

There is using Pkg

 dir2pet DIR                create a pet package from a directory
 dir2sfs DIR                create an sfs package from a directory
 dir2tgz DIR                create a tar.gz file from a directory
 deb2pet DEBFILE            convert local deb file to a pet package
 pet2sfs PETFILE            convert local pet file to an sfs package
 pet2tgz PETFILE            convert local pet file to a tar.gz package
 pet2txz PETFILE            convert local pet file to a tar.xz package
 sfs2pet SFSFILE            convert local sfs file to a pet package
 tgz2pet TARFILE            convert local tar.gz|tgz file to PET
 txz2pet TXZFILE            convert local tar.xz|txz file to PET 

wanderer wrote: ↑Mon Mar 15, 2021 2:57 pm

it would be nice to have a script that made pets into sfs files
so they can be used as modules
but that can come later

william

Search for PaDS

search.php?keywords=PaDS&terms=all&auth ... mit=Search

thanks

i see there are already scripts to do the conversion

now back to trying to figure out the 2 templates

william

wanderer wrote: ↑Mon Mar 15, 2021 2:57 pm

it would be nice to have a script that made pets into sfs files
so they can be used as modules
but that can come later

william

There's PaDS.
PaDS is already included into the initrd.gz I created - which is at 2311Kb yet.

Again, I'm asking for people to PM me to get a download link for testing the initrd.gz.