minimal modular puppy (from fossapup64)

[bigpup]

The Woof-CE readme, has just been updated, with some new changes, on building with Woof-CE.
https://github.com/puppylinux-woof-CE/w ... ub-actions
Note:
Readme content is lower down on the page .

[peppyy]

Feel free to delete this, (or even ban me), but what is Fossapu64
I thought I was the typo master.

[wanderer]

yeah i just noticed thanks

william

[taersh]

Minimal Modular Puppy (Community/Cluster Puppy) Woof-CE/CP

taersh's initrd can be added to the puppy community repository as an option
until it is accepted in the main woof-ce master

This is never going to happen!

Inside of my initrd.gz is a lot of stuff that doesn't have anything to do with Woof-CE.
I simply doubt something apart from the changes in init script will make its way into Woof-CE.
Even the changes in init script itself...

Especially, since I don't have a git/github account and I'm not able to do the necessary steps to make a pull-request.
I tried once, but failed in complete!
So, obviously no chance to get anything of that into Woof-CE.

On the other hand, I think the best would/could be, to make a fork of Woof-CE, rename it (perhaps Woof-CP) and to develop/modify it, so it will create Community Puppies instead of Official Puppies. The CP could either stand for Community Puppy or even Cluster Puppy.

[wanderer]

hi taersh

i agree with you

the new improved woof-ce looks great
for woof-ce gurus
(and i thank you very much woof-ce guys for all your work)

however for the average user/developer
something much more accessible is needed

so i will continue work on my simpler system
(which is a subsystem of woof-ce)
and which will consist of (as noted above)

1. an iso build script
2. a module maker script
3. a repository for modules
4. a collection of build templates
(with the components/apps separated into sections)

that way gurus like you and non gurus like me
can have a fast easy simple way to make puppies
without using git or the full woof-ce
and we can easily add things to the puppy system
without the need to merge anything in git

you can see how your initrd fits perfectly in this system
it will just be kept as a module (or modules)
to be used and tested with different builds

i also agree with you that the community puppy
should be separate from the main woof-ce

and i feel it should be made with this simpler system we are working on
because the system it is more accessible to the community as a whole

woof-ce will provide the
2 base isos (initrd and base-x main.sfs)
and the modules that will be added to them

i assume that the distrospecs file in woof-ce
is essentially the same thing as our build templates
with 2 critical differences
1. the components/apps are not divided out in the form
2. and it does not make the apps into standalone modules

maybe over time we will even learn enough about how to use woof-ce
to implement these design features into a sub branch of the master

right now i am trying to learn how to use the new woof-ce
and the first step is to get woof-ce to make the 2 base isos

william

[Clarity]

Please, NO ONE GET angry for this question: "Is there something wrong or confusing about the Puppy build directions presented?"

If so, please share. I am a lowly user, and am curious as it seems simple. But, I am not you and dont see things thru your eyes.

Your comments would be helpful, I believe. And, for those who may think the answer is obvious, I have been paying attention along the way, so I am not clueless. Please understand my concern is about the directions, the difficulty in the directions, and any ideas that exist in the ability of the directions to lead to a PUPPY outcome.

So, this is not a challenge to ones' preference, instead, it seeks mere understanding of the directions and the effort that the developers are presenting.

Help

[wanderer]

hi clarity

thanks for all your help and encouragement

if your question is "is there a problem with the woof-ce instructions"
and if that question is directed to me

my answer is no
there is no problem
woof-ce i would assume builds a very nice puppy iso

but it lacks (at least in my present understanding of it)
a number of functions i want

i want to be able to build a puppy iso in stages
with its components being individual modules

i assume distrospecs is the template for each build
but the list is not separated into clear groups of components/applications
so someone (at least not me) can logically delete what they dont want
and build the iso in stages
and add the components/applications as modules

no problem
just designed differently

i play with tinycore/dcore
which are designed this way
so it is not like i need to find a system of this kind
for my own use

but i think that it would be of interest and use
to the puppy community
to be able to do this

the simple system
that i am trying to build
should make it easier for people
to begin building and modifying puppy isos
and that would be useful in building a community puppy

and that is what this is all about

im not asking anyone to build this for me
like i said i already have one

i am playing with woof-ce now
and maybe i will figure out how to make woof-ce do these things

but there is no deadline

william

[taersh]

Hi.

I have downloaded the Woof-CE-testing branch.
Renamed it to Woof-CP and stored it locally for future adventures.

I added my initrd.gz additions to Woof-CP.
I added option to build a ClusterPup64 1.0.0 from the FossaPup packages.
Successfully created the ClusterPup64-1.0.0.iso.
All initrd.gz additions are stored inside the new initrd.gz.

I modified Woof-CP to create a nempup_ClusterPup64_1.0.0.sfs.
Successfully created the nempup_ClusterPup64_1.0.0.sfs.

I modified Woof-CP to create an additional SDRV .sfs and to have selected contents within that SDRV .sfs.
I chose to exclude AbiWord, DeadBeef, Gnumeric plus some more from the built.
Successfully created the new ClusterPup64-1.0.0.iso including the new SDRV .sfs.
All selected contents are stored inside the new SDRV .sfs.
AbiWord, DeadBeef, Gnumeric etc.pp. are gone.

Though, I didn't boot yet ClusterPup64 1.0.0. Will reboot after doing this post.

ClusterPup64-100-Screenshot.jpg (224.9 KiB) Viewed 801 times

[wiak]

Please, NO ONE GET angry for this question: "Is there something wrong or confusing about the Puppy build directions presented?"

Yes, I understand what wanderer is saying Clarity. The build directions for woof-CE are straightforward. So it is easy to run the woof-CE build scripts in the appropriate order and churn out FossaPup64, or some other published woof-CE Pup. So let's run it again and there is 'another' copy of FossaPup64 (or whatever). But there already is a downloadable iso of FossaPup64...

Wanderer wants an extremely different version of FossaPup (a very bare one indeed). That is not the simple matter of simply running the woof-CE build scripts in the appropriate order. Not simple at all.

On a positive note though, some work by dimkr up at woof-CE in just merged into the build system in the last day or two seems almost designed to provide some of the flexibility wanderer is looking for in terms of providing a very cut down Puppy core (with even more or the major apps in separate adrv).

I can't say that dimkr has made these additions because of wanderer but I suspect all such wishes do have an influence, in terms of priority, on what gets developed:

viewtopic.php?p=20236#p20236

[wiak]

Hi.

I have downloaded the Woof-CE-testing branch.
Renamed it to Woof-CP and stored it locally for future adventures.

I added my initrd.gz additions to Woof-CP.
I added option to build a ClusterPup64 1.0.0 from the FossaPup packages.
Successfully created the ClusterPup64-1.0.0.iso.
All initrd.gz additions are stored inside the new initrd.gz.

I think that idea of using a separate fork is a good idea for this project, and that initrd that is modified to allow far more sfs modules certainly matches much of what has been specified as the modular Pup desired. So it is a good mix to use all the enhancements to upstream official woof-CE (and thus track them in simple way via new forks when required) and then customise the build results, by various sometimes simple means, in a fork of the build system IMO.

You can also employ simple remastering techniques as part of the process, bearing in mind that remastering steps can themselves be scripted.

[taersh]

Hi.

I modified Woof-CP to create an additional MDRV .sfs and to have selected contents within that MDRV .sfs.
Successfully created the new ClusterPup64-1.0.0.iso including the new SDRV .sfs AND MDRV .sfs.
All selected contents are stored inside the new SDRV .sfs AND MDRV .sfs.

Rebooted successfully into ClusterPup64 1.0.0. Though, I only got 640x480 screen resolution. When exiting to prompt I could not enter anything by keyboard. Xorgwizard (GUI version) didn't change anything after restarting X.

Need to build a plain FossaPup64 to check. Perhaps something is broken in Woof-CE's FossaPup64 build templates.

[s243a]

I'm now added the ability to move the relevant metadata from woof-installed-packages

For example here is what we get in the target folder which is the core/cli components from the base sfs

this doesn't included busybox and root-fs puppy stuff. I want to make those separate modules. In the final distribution modules can be merged but I want to separate the stuff that is puppy specific so that it is easy to update only puppy specific stuff. Also busybox might be something I want to replace with a different version. For instance I like how tinycore's busybox seperates the parts of busybox that require "su" from those that don't.

[Clarity]

Thanks @wiak and others, too.

My comments, as I tried to express was asking about the directions, and its intent to allow us to build a specific PUP to our liking. It was about the README instructions that the Developers are presenting to make things both clear, straigthforward, and easy in both objective and understanding.

So, it was and is NOT directed to any one person as wanderer might surmise. So to that end, I offer wanderer an apology if he felt it directed; even as it was not.

So, from the posts since my post, it appears that a few of us have actually tried the directions...even as we have NOT stated such.

Thanks to everyone, BOTH, here and the developers contributing to Puppy success. The achievements by those involved, directly or indirectly with woofCE and Puppy Linux is phenomenal.

To me, woofCE is Puppy Linux. It allows the generation of a Linux that meets needs of those who use the outcome. On the forum, WE users support those outcomes by our feedbacks and contributions.

That, again "to me", is what Puppy Linux is and what it is about. Namely;

1. a distro created by WoofCE and reproduceable if need.

2. a distro created by WoofCE that is supported by its author(s) via forum participation.

3. This comes in light that it is NOT predicated on how much or how little is included in the production or support of a particular woofCE output.

4. And, as is typical starting with Barry Kauler, it has a "base" set of apps built-in for general use

Anything else, to me, is a fork or a remaster.

[wanderer]

hi clarity

i didnt mean to assume
i apologize

yes woof-ce directions are clear and easy to use
yes i also feel woof-ce is the core of puppy because it is the living repository of all the puppy development over time

looks like gurus s243a and taersh and the woof-ce team are continuing to expand its capabilities

thank you very much gurus for all your work

i am also playing with the new woof-ce and am looking forward to its further development

william

[wiak]

Anything else, to me, is a fork or a remaster.

I have lengthy thoughts about the situation. Apologies in advance.

I presume you are talking about actual Pups created via means other than only direct via woof-CE, Clarity. Neither the DebianDogs, FatDog, or WeeDogLinux are forks or remasters of Puppy - they are alternatives (though FatDog certainly grew its original roots from Puppy, and DebianDog was originally partly an attempt to emulate the look and feel of Puppy - but DD is a DebianLive system that primarily uses a modified Porteus initrd, not Puppy's, for its aufs layering functionality). WDL was my own experimental implementation/design-philosophy-idea to try and create a distro starting with a simple core which contained only busybox and official package manager of upstream larger distro (being xbps from Void originally), and more particularly it was created simply as my experimental use overlayfs for a layers system following my reading of kernel notes on overlayfs - nothing to do with Puppy at all other than my detailing what I was doing on the old forum and being familiar with frugal installation more generally (including having started using Knoppix, then DamnSmallLinux, then, at around the same time, tinycorelinux, Slitaz, and Puppy, then Porteus itself, and then DebianDog - but previously used early Red Hat Linux and even earlier Yddrasil Linux/GNU/X and earlier still Sun OS UNIX variants...).

I do purposively make WDL design as simple and completely accessible/readable as possible, however, in the hope some of any innovations encourage development of other distros. It is not at all, however, intended as a replacement or a competition - it's simply my 'own' Linux distro implementation, and as such, to some extent is like a painting - everyone in Linux development uses much the same underlying paint... But aside from its relatively unique initrd/init overlayfs functionality implementation, it relies heavily on the amazing work by busybox developers and the various upstream repos and their excellent package managers (Void Linux, Ubuntu, Debian, Devuan, and Arch Linux) for its build completion, up-to-date availability of package and key system developments, and practical usage. Outside of its flexible build model and plugin usability, much of WDL has nothing to do with me either.

All Linux distros are re-workings of old ideas and algorithms and code tricks that continually get added to and become available via the likes of Stack Exchange. WDL initrd/init was not based at all on any other Linux distro (I find most initrd/init codes to complex to bother reading) - indeed I primarily just read the kernel notes and man pages on mount command and as logically as I could cobbled the whole thing together, line by line of script, as creatively/functionally as I could. Aside from that initrd component, most of my current inspiration has come from documentation from Void Linux (I was particularly inspired by the standalone capabilities of Void's xbps package manager) and system-level configurations (which are very different from those in Puppy), and directly from Arch Linux Wiki.

The later added WDL_Debian-based designs (aside from the more novel WDLGO lego-like variants) are much simpler in implementation/design since just using debootstrap to build the root filesystem and using apt thereafter... WDL_Arch is almost as simple, since following a similar archbootstrap procedure, upstream Arch design does everything for me - I take little credit for that... WDL_Void, in other words, is somewhat more unique overall, though again, for the most part, most credit for what ends up as a completed distro again belongs to Void Linux developers themselves. However, WDL initrd/init is indeed the heart of the system and for that most of my thanks go to the kernel overlayfs developers; my contribution has mainly been in relation to the build system modular plugin design and the way I have implemented the layer handling in terms of the sfs and raw filesystem layer functionality WeeDogLinux provides.

As far as Puppy and woof-CE is concerned, I agree with you that alternative Puppy's invisaged are either forks or remasters of what current woof-CE provides by default. However, woof-CE was a series of scripts the originator of Puppy, BarryK, handed over to the community to develop whatever way they chose.

In terms of what is official Puppy, what you are really talking about is not the technology but rather the human authority - BarryK passing the mantle to 01micko and so on. In that sense, Puppy is not a community distribution - it's development remains tightly controlled via delegation. Otherwise, if the community decided woof-CE was not the build mechanism they wanted, then they could simply change it to a form they find better and the result would remain Puppy. As things stand, without 01micko agreement, any build that basically uses underlying Puppy system scripts, but deviates from simply using what woof-CE provides, can only be created as a fork (and thus not called Puppy), a remaster, a re-working of Puppy or whatever we want to call it, but not Puppy itself.

However, it was a tradition that Puppy community produced once upon a time a Puppy Community Edition, which was itself a remaster of the official BarryK produced Pup at the time, which itself did not use woof since I believe woof itself is a late addition to the Puppy creation process.

Personally I agree with the sentiments wanderer expressed somewhere: Puppy is a lovely wee system that continues to have a lot going for it as a distro, but I don't love the let's say "less-than-elegant" design of woof-CE, by which I mean it is not the easiest code to maintain or add to. Furthermore, it be cannot be driven/automated easily via a commandline script (it requires interactive human input during its run, rather than optionally having the capability of being driven via a configuration script). To my taste, it is a convoluted mess, and only a total re-design/re-write could fix that, but unless that is attempted its admirable developers have no choice but to make the best of what they have.

It is not therefore that I am criticising the hard work of some of those involved with woof-CE (some of the 'old guard' have been real development-blocking pains, IMO however - that is my opinion) - they make the best of what they have. But I am criticising woof-CE design; despite its good original intention to allow Puppy to keep going; it is too inflexible and set in stone. Contributing to it in terms of adding new features or fixing problems does not unfortunately address that design issue. So, somewhat per wanderer, I like Puppy - at one time, there was nothing like it, but I do not love woof-CE despite the fact it is the only means for producing current distros officially recognised by the name Puppy Linux.

[wanderer]

hi all

i think that the reason we are all here
is that we all see the value in small efficient systems
as opposed to bloatware

all the puppy forum projects
follow this model
whatever their origin or organization

i will call that the spirit of puppy (and tinycore slitaz etc)

unfortunately the idea of an official puppy
has clouded this issue
and created the illusion
that one approach is inherently more valuable than the other

however if one pays attention
one can see that we are all really working together
to the same end
everything on the forum is synergistic

thankfully the forum administrators
have recognized this
and given everyone their own space

i do believe that woof-ce needs a simpler front end
to aid with entry and contributions
as well as a number of additional capabilities (minimal modular)
and that is what i am working on (i.e. nagging others to work on)

i also believe that all of the other projects on the forum
need to have an accessible entry point for non gurus

i think the biggest challenge for us all
is to accept that we are all working together on the same conceptual project
thankfully the forum is a great way to do this

remember what the ancients said

"it is impossible to reach such a great truth by a single path"

william

[s243a]

Is development really driven by woof-CE, or do people tinker with their system and if they like the changes incorporate said changes into woof-CE. Woof is more of a build tool then a development tool. The build process is too time consuming to actually be the principle means of testing changes to a given version of puppylinux. Woof does a great job at building what we expect from a puppy linux distribution but the more we wish to experiment with changing the way puppy works the more burdensome the modification of the build system becomes, and may at some point distract from the end goal that one is trying to achieve.

The burden of maintaining the build system isn't really a problem for collaborative efforts at making a better puppy (as we know it) because the innovations of each contributor can be utilized by all in the build process but for an individual trying to make more radical change not only is the extra burden of maintaining a build tool questionable but the efforts could be wasted if the larger woof-CE development community doesn't like the changes. Even simple changes have been rejected which likely would have little impact on how woof-CE works. For instance the following issue seemsd to gather little traction:

Some puppy core scripts shares the same filename as the files from mainstream package such as init, mount, umount, losetup, ps, poweroff. This examples can overwritten by packages from mainstream linux distro which cause trouble on puppy. The best solution here was to move these commands to for example /lib/puppy and declare it on $PATH like this

export PATH=/lib/puppy:$PATH

This will prevent the puppy core scripts from being overwritten by mainstream linux package.

https://github.com/puppylinux-woof-CE/w ... 4455298731

and @mistfire eventually decided to close it and the related pull request. But these pull requests by mistfire would make it easier for people to use the package manager of the upstream lunux flavor should the user. choose.

Consider the following comment by gyro:

But it seems that we are not talking about these things, but rather a more basic Puppy thing, i.e. How close of an integratiion to the upstream Linux is Woof-ce supposed to achieve?
As I recall, it was never meant to be 100%, but a means to provide Puppy wilth access to the huge number of applications available in upstream repositories, but for the core of Puppy to remain Puppy, no matter if it's a uPUP or a dPUP or an sPUP, etc...
That's why Puppy does not support the use of upstream kernels, and has retained the PPM, (for all it's problems).
(Woof-ce's biggest problem is that it has been too successful.)
Perhaps we need to reflect on the significant difference between Puppy and "FatDog" etc...

As to the actual patch, I think it is just as likely to cause as much time wasting for current contributors to Pupp Linux, as it is to avoid problems in the future.

https://github.com/puppylinux-woof-CE/w ... -797431585

but puppy shouldn't be different just for the sake of being different. Puppy has it's unique features, like it's small size relative to it's functionality, kernal support for aufs, a layered file system and package manager that can work with many different repo types. If puppy is compatible enough to run the package manager of it's upstream flavors than puppy users can get the advantages of these tools such as their update features:

Strange thing is since I added the apt plugin SFS I have begun to use apt update and apt upgrade with success on a Fossapup64.

Only tricky thing at the moment is I need a tiny script that deletes and copies the correct /sbin/init and /sbin/poweroff when needed.
The swap needs to be done so Fossapup64 can shutdown or reboot cleanly as a Puppy using Puppy's init and poweroff. Otherwise the reboot or shutdown is handled by systemd components which will not deal with pup save modes and shutdown cleanly.

This is of course a true tinkerer's calling and so far not mainstream enough to be used casually. But the apt update/upgrade has been pulling the Ubuntu updates and PPA's and installing them.

I edited the main Fossapup SFS to have duplicate copies of /sbin/init, /sbin/poweroff and /sbin/reboot (symlink to poweroff) built in from the ground up.

WeeDog32-Void and WeeDog64-Void are rolling distros and can be upgraded about every hour if so inclined.

Though my most solid machine is a web/file server running Tahr64....never updated anything in 4 years in this OS.

viewtopic.php?p=19135#p19135

and I know a image based approach is safer but a lot of puppy users have the skills to troubleshoot issues should they arise and there is no long term commitment by the woof-CE team to provide updates for old puppies. If one can modularization puppy then they can focus updates on a specific module (e.g. the core/cli components of the base sfs) rather than having to update the whole system at once. Also having the option to only update part of the system can reduce the total size of the updated system.

[wanderer]

thank you so much s243a

for working on the minimal modular puppy

i think as you have said it will solve a great many problems

william

[wanderer]

here is another possibility of a minimal modular system

let us say you have a number of different systems
with different components

if you made them into modules

you could have an iso build script
that only chose the modules that were compatible
with that particular build

individual modules could be also modified if needed
to be compatible with a particular build
and you would only have to work on that particular module

you wouldnt have to do this all at once
just one module at a time
at your leisure

this way you could integrate all the various projects on this forum
into one meta project

and then everything would be a part of the official puppy

william

[wanderer]

only 4 pieces to the system

1. a repository of modules
2. a module maker script
3. an iso build script
4. iso templates

william

[Grey]

If you make the modular system easy and accessible to everyone, then release the genie from the bottle and maybe even open the Pandora's box. There will be so many versions of pseudo Puppy that no one will be able to figure out this mess. Who will support this whole zoo of variations? How do you explain the difference to users? There will be Chaos. There is already a situation where users are scattered among variations. The system should be handled by some abstract team, and users should ask, complain, and make suggestions. Otherwise, the system will live for a month and die.

[wanderer]

hi grey

assuming anyone will ever even do this
as simple and powerful as it is

anyone can start it if s243a does all the actual hard work
and makes the 2 base isos from woof-ce

i will if no one else does

the individual that has the repository
will have control of that repository

the point is you wont have to get permission to experiment or contribute

it wont cause any chaos
people are doing this now
everyone works on their own stuff
and posts what they want others to use or test
and explains what it is to everyone

it will only allow the community to easily work together

i hope eventually a few lines of development will emerge
and people will be able to use and contribute to them

for example an up to date community puppy

and maybe maintaining a legacy puppy

there are a few basic rules you should follow
like having unique number ids for each module
so the iso build script doesnt become confused
i posted some of them previously

but there is no way to mess things up
things that people want will develop further
and things that dont work out will simply become inactive

william

[Grey]

but there is no way to mess things up

Okay. Time will tell

[dimkr]

The only candidate I see for an up-to-date Puppy, developed in the open, with multiple developers behind it, without manual hacks and undocumented tricks, is this:

viewtopic.php?f=118&t=2199&start=40
https://github.com/puppylinux-woof-CE/woof-CE/releases

It can easily become 'modular', by moving packages to adrv. And it should be easy to add support for building a 'xdrv' (or whatever you call it) in woof-CE.

[amethyst]

To add additional drives like bdrv,cdrv, dddrv, eeeedrv or whatever just requires changes to initrd.gz (and the sfs_load script) and the implementation thereof can be facilitated by various other scripts. So as far as that is concerned, it really does not have anything to do with the actual development or build of a new variation of Puppy it can be achieved with the current mainstream Puppys. Fossapup has already started the modular approach with the addition of the adrv for programmes/libraries, etc, as far as I know (I use older Puppy's), now that concept can be refined further. No need to re-invent the wheel. I have one initrd.gz which has all these additional drives (I think it's about 30) enabled which I use on all my Puppy's (I just change the DISTRO_SPECS for different Puppy's). I use 32-bit Puppy's but it also works with the 64-bit Puppy I use on occasion. Personally, I don't really use these additional drives but they are available if I wanted to.

[wiak]

Well whether it is worthwhile pursuing an alternative build process (and no doubt still utilising woof-CE as part of that process) or not, at least I think most can agree that this is an interesting discussion since it brings up ideas that may or may not be easy to implement or accommodate via current woof-CE developments alone. There is already plenty of variety of distros available on this forum, some Pups, some not. Personally I think that is a good thing since choice illustrates alternative ideas and innovations, and thus inspires development for all, and stops us getting too bored in this time of Covid.

What would not be good would be the idea that distro development is a competition, a threat, or that any distro design is superior, or should never be challenged or changed such that new and potentially good ideas are summarily refused or prevented because of fear or protectionism of any kind. The more open a Linux distro is, the more accommodating and flexible it is, the better it is. Those who advocate for no change, as if time should stand still, should never be considered as acting in the best interests of the distro they advocate for - fact is, it is not necessary to be so defensive if a distro is good and has active development - the more varied the ideas the better (though of course most ideas may never see the light of day).

Whether it is better for a distro to be the result of community consensus or the benevolent dictatorship of a select few is itself debatable. Too many cooks can certainly spoil any broth.

[wanderer]

hi dimkr and amethest

thank you (and all the woof-ce gurus)
for all your help and hard work

yes puppy is a fantastic system
and woof-ce can make just about anything you want already

(that is i assume if you understand the distrospecs file)

what i am proposing is just something of a simple front end for woof-ce
and a way for the whole community to participate

woof-ce provides the base parts

the modules

and my system just allows people
to build and modify (develop) puppy isos
quickly and easily

like a build time in 1 minute or so
on their own computer

it also allows the entire community to collaborate
simply by exchanging modules

if any useful stuff is developed
it hopefully will find its way back into woof-ce

and the cycle will begin again

of course it can be used with any system
or any combination of systems
not just woof-ce
and so modules from other systems can be included
if they are modified to be compatible with that particular build

the only thing needed to start
is for some guru to get woof-ce to make the first 2 isos
(a initrd only iso and a base x main.sfs file)
and then more and more modules can be added over time

i think s243a is doing that now

i cannot do it because i dont understand woof-ce well enough
to have it build the isos or the modules

lets give this a try and see if it proves to be useful
nothing to lose

william

[s243a]

here is another possibility of a minimal modular system

let us say you have a number of different systems
with different components

if you made them into modules

you could have an iso build script
that only chose the modules that were compatible
with that particular build

That's sort of the idea I had in mind and woof-CE sort of does this now with the adrv, fdrv, etc, partitioning scheme but if we consider the possibility that a module might be a smaller unit than a final layer than the adrv, fdrv, etc scheme represents a more course partitioning -- as it is currently implemented -- than I have in mind.

only 4 pieces to the system

1. a repository of modules

If you have a module maker (e.g. woof-CE or Woof-Next) then this isn't completely necessary but is nice to have and I like the idea as it will reduce the time it takes for someone to assemble a system.

2. a module maker script
3. an iso build script
4. iso templates

Currently in woof-CE the templates are defined in folders like this:

/woof-distro/x86_64/ubuntu/focal64

but the templates are designed to produce a complete ISO and don't define a step to produce intermediate modules beyond the various adrv, fdrv, etc that form the layers of the final ISO. One might for instance what to produce intermediate modules that can be select based on various desktop flavour configurations, which include choices of window managers, file-managers and desktops. All these flavour components might be included in a JWM module or a LxQT module etc.

The initial developer of a puppy flavour with binary comparability towards a particular upstream flavor of linux might only be interested in development in full of one of these desktop variants but if the intermediate modules are developed for the other variants it produces a starting point for someone wishing to finalize one of the other flavors.

Many Linux distro's release there distribution in several flavours and others in the puppy community have commented on this. For instance @sc0ttman writes:

Official release cycle
The main release

We do "official" Puppy Linux releases every two years or so.

Official releases are the communities "best efforts" combined - all the
developers, designers, testers and users working together, with the aim of
building "the best Puppy Linux ever".
....
Other "flavours"

Official releases are the "main" or "flagship" Puppy Linux releases, and come
in various flavours, all released at the same time.
...
These "flavours" provide a choice of different desktop themes and environments:

default (JWM) - JWM desktop, ROX file manager
XFCE edition - Xfce4 desktop environment, Thunar file manager
LDXE edition - LXDE desktop environment, PC-Manfm file manager
Mate edition - Mate desktop environement, Gnome file manager
...
"GuardDog Edition" releases

About one year after an official release, there will be a "GuardDog edition"
of that release:

more secure, privacy-focused releases
no need to install to anything - run from CD
optionally save sessions to an encrypted "save file", or not at all!
leave almost no trace of your activity between reboots

GuardDog Editions differ from official releases in these ways:

asks before saving settings/session between reboots
uses encrypted save files by default
fewer packages installed by default
additional security fixes and bug fixes
Tor browser installed by default, with privacy/security addons
lots of programs setup to use tor by default (using with-tor script)
some ad-blocking, anti-virus, privacy and VPN tools added

https://github.com/puppylinux-woof-CE/w ... -557260534

My idea of modularization goes a little further than various desktop layers because I'm interested in minimal systems for chroots, sandboxes, containers and virtual machines. That said the above suggestions by @sc0ttman provides the principle focus about the level of modularization that would have the widest appeal. If the modules at least have sufficient granularity to facilitate sc0ttman's suggestion then I think it could be an idea that gains traction. Remember modules can be a unit of smaller granularity than the final layers distributed in an iso.

[wanderer]

hi s234a

i cannot thank you enough for doing all of the actual work
im sure the entire puppy community feels the same
this is your creation

william

[wanderer]

does woof-ce download the binaries from the target distro and make them into pets
can the pets be then made into modules (sfs files)
eliminating any need for an intermediate step

the repositories are important because
people will be sharing their work by exchanging modules
as well as making it very fast to build an iso
and eliminating the need to download modules more than once

also the modules will not be merged just placed unchanged into a folder in the iso
and then linked either by unionfs or symlinks
so there is no processing other than simply copying them to the folder to make the iso

william