Whats up in Puppy World

[wanderer]

hi wiak and everyone

at least to me it seems that the puppy community has generally agreed
that all the distros on the forum have equal value

in about 1 year we will need to present a new candidate to distrowatch
and i think that we should start thinking about that now

no rush
just discuss things

wiak i am very pleased to see you continuing your work with firstrib
and i think that it will be of great value to the puppy community
i am hoping to eventually see a user friendly build system for puppy come out of it

and when we see puppies ( or puppy-like distros )
no matter how they are built
that we all feel represent the ideals of puppy world
i see no reason why they should not be considered for our distrowatch candidate

wanderer

[wanderer]

i agree with williwaw

that we should use the puppy homepage

to showcase the diversity of puppy

as well as list our present distrowatch candidate

its where people will go to find out what is going on with puppy

before they go to the forum

wanderer

[geo_c]

The new firstribit code which contains all the functions showing how it is done will be released soon. Hopefully illustrates a lot of 'tricks' other aspiring devs can use in their own experiments.

I'm curious as to how the Bookworm firstrib gets constructed, because I was having thoughts about the value of firstribbing puppies, in that in one sense it gives us the best of both build methods. In that woof developers can create barebones pups, and firstrib scripts can build the pup up from there with a plug file.

This would potentially expand the number of people who can delve into building pups without doing remasters, but rather download the packages from a build script.

But I'm not clear on the method you're employing. Is the script grabbing the components from the woof repository and essentially building from the ground up, or instead does it incorporate the existing pup.sfs rootfs from an iso or download, and then layer from there?

The advantage once constructed, is the ability to add layers up to 99, multi-install, and all the other versatile abilities of a first rib frugal.

[rockedge]

@geo_c the FirstRibit script(s) takes the target distro's components and constructs a sub-directory frugal installation of that diistro, then adds in the FirstRib skeleton initrd.img (initrd.gz) that is then modified to boot the distro's included kernel. Or there about...........

So the kernel is invoked by the FirstRib initrd.gz which gives the user the same 0-99 layers of SFS that can be loaded during the system startup that we see in the KLV's

To sum it up...with a script we're taking a distro, stuffing the components into a frugal install directory......then integrating the FirstRib initrd.gz (.img) to pull it all together. Uses the same exact capabilities as the other KLV's with /upper_changes and manipulating those for rollback or system customization.

Also booting using the RAM0 and RAM2 modes is fully compatible.

[wiak]

The new firstribit code which contains all the functions showing how it is done will be released soon. Hopefully illustrates a lot of 'tricks' other aspiring devs can use in their own experiments.

I'm curious as to how the Bookworm firstrib gets constructed, because I was having thoughts about the value of firstribbing puppies, in that in one sense it gives us the best of both build methods. In that woof developers can create barebones pups, and firstrib scripts can build the pup up from there with a plug file.

This would potentially expand the number of people who can delve into building pups without doing remasters, but rather download the packages from a build script.

But I'm not clear on the method you're employing. Is the script grabbing the components from the woof repository and essentially building from the ground up, or instead does it incorporate the existing pup.sfs rootfs from an iso or download, and then layer from there?

The advantage once constructed, is the ability to add layers up to 99, multi-install, and all the other versatile abilities of a first rib frugal.

Firstribit (like old weedogit) works as @rockedge describes above. As far as using it with a Puppy distro like BookwormPup, the disadvantage is that FirstRib knows nothing about Distrospecs and anything using Pparameters in any Puppy script simply don't mean anything to FRinitrd. The way round that is to make workarounds in an addon sfs file. I am only doing that in the most basic of ways, but can be improved and probably made to work near perfectly.

Regarding the use of a plug file. Of course, everything to do with FirstRib revolves around the ability to use plug files so 'normal' users can not only become involved, but gain lots of expertise, be creative, and take over most of the final build. The first release of new firstribit utility will NOT contain plug file capability - it could, but really that is more useful for a final build target (and that can include via remastering of the main sfs files).

A plugin variant of firstribit is planned to come next though - that will be slow to finish its job because it will be unsquashing the main root filesystem being converted prior to a chroot into it followed finally by squashing the final result up again... so that will definitely be a go and drink several coffees prior to trying final result... Not sure how that will work with the FR/KL_BookwormPup since I imagine would have to concentrate only on the main pup_xxx.sfs. However, for many upstream distros there is only one rootfilesystem sfs so the plug file should work fine. Funnily enough my main reason for wanting that is not to ADD extras to the upstream distro but rather to REMOVE stuff and end up being able to make the likes of a Puppy-sized FR_LinuxMint (for example).

Regarding Puppy Linux itself, I also have that other idea to add a plug file to work with woof-CE itself; that FR mechanism would improve it greatly. That isn't anything to do with firstribit utility though; it would involve either a fork of woof-CE itself or something like my old MakePup with added plugfile capability.

By the way, I expected/intended to release new firstribit utility yesterday, but on reflection I decided it would be nice to refactor the code first so in better state for the plugfile addon I want for the other planned version. I'm in final testing of the refactored code; to give you an idea of the difference that make - prior to refactoring the code was a script of around 1400 lines - the refactored version is less than half of that. Reason is that old weedogit had lots of reused/repeated code, but I did keep separate functions for each distro type in new firstribit, despite still considerable code duplication, because that makes it easier to add new distros and to make special-purpose mods to individual distro-type conversions.

All in all, KL/FR overall work on the forum remains I feel in a very healthy state (despite no Distrowatch presence ) in terms of scope, new stuff to experiment with, and continuing improvements overall. Of course it would be nice to have more people playing with it because then new ideas and new build types and styles would accelerate even faster. But even a few people experimenting with KL/FR prove able to create lots of nice distros and really interesting multi-instance-install/rollback ideas to experiment with further.

[wanderer]

hi wiak

very happy to see you pursuing this

downloaded and booted the firstrib tinycore iso
booted to desktop
seems to work well
will keep playing with it since it is up my alley

thank you very much

keep up the great work

wanderer

[wiak]

downloaded and booted the firstrib tinycore iso
booted to desktop
seems to work well
will keep playing with it since it is up my alley

Of course the initial result is rudimentary. It has the advantage over actual tinycorelinux in that all the FR initrd frugal install 'tricks' work as normal out-of-the-box and that includes normal FR save2flash/snapmergepuppy (similar to Pupmode 13) save on demand persistence from RAM. Also FR multi-instance installs will work.

But... you will quickly discover the tinycorelinux provided apps for downloading and installing new apps won't work; well they can't since FR does not use symlinked tcz (sfs) mechanics or other parts of TCL system organisation. Is there a way round that? Well, yes, why not - but an interested user/dev would have to write a different app installer that took apps from TCL repos and turned them into numbered sfs files (which is basically what firstribit does to the boot tcz files) and also checks the dep file and resolves these dependencies into numbered sfs files as well. Frontend to that could be a bash script or say something written in yad (or using fltk - I guess - per TCL programmers...). Even if minimum of that done, it remains quite an interesting form of TCL distro because of save2flash and easy enough to simply add apps via normal directories (or sfs files), with a 2-digit layer position numbered name, containing the app+dependencies - i.e. build a customised fully working FR/KL_tinycorelinux64, which is super small and extremely fast...

Make no mistake, the scope possible via KL/FR has hardly had its surface scratched thus far - perhaps simply because of lack of public exposure and thus uptake.

Anyway, firstribit is certainly part of "What's up" in this forum world right now; shows we can KL almost 'anything'...! and make all such distros capable of all the usual frugal install tricks. Its predecessor "weedogit" was very popular in terms of downloads (though unlike firstribit, didn't have save2flash integrated), but I'm not bothering about download stats for firstribit - if it is useful it is useful, if not, it is not, but it is useful to me.

[wanderer]

hi wiak

yes some things dont work
but it is a great learning tool for me
because i understand tinycore
and can now study how firstrib works

wanderer

[wiak]

hi wiak

yes some things dont work
but it is a great learning tool for me
because i understand tinycore
and can now study how firstrib works

wanderer

Yes, understanding is always the key to creating new projects. Once you understand the way firstrib works it becomes possible to create alternative utilities than those provided by original TCL such that the whole distro works smoothly. I'm not saying doing so is easy, but final result would be wonderful to have. Nevertheless even as is with simple added numbered sfs (or uncompressed directory) layer addons could make a great wee fast distro, and truly a FR-based KL distro (yet relying on TCL repos basically).

The result of that firstribit menu choice is not a TCL distro made to look and feel like Puppy; rather it is a FR-based KL distro (using various layer utility apps from around this forum) that uses TCL for its repos (and pre-built core root filesystem) - it looks like TCL (not Puppy), but behaves like all FR-based KL distros. Nothing at all wrong with relying on some other distro's repos - that's exactly what most other distros do (including Puppy). The look can be changed to whatever builder/creator wants it to be - the overall feel is "KL/FR". Firstribit blurs the artificial boundaries and KL_full2frugal (my personal favourite since I also use full install of Linux Mint) probably does that even more so.

[mistfire]

I was thinking a new kind of Puppy that boots like Puppy (all odd-numbered PUPMODES are removed and savefile upgrade process removed), but still aligned with upstream distro. Yep it almost looks like a TazPuppy with extreme minimal modifications and uses all upstream distro components.

[wiak]

downloaded and booted the firstrib tinycore iso
booted to desktop
seems to work well
will keep playing with it since it is up my alley

Of course the initial result is rudimentary. It has the advantage over actual tinycorelinux in that all the FR initrd frugal install 'tricks' work as normal out-of-the-box and that includes normal FR save2flash/snapmergepuppy (similar to Pupmode 13) save on demand persistence from RAM. Also FR multi-instance installs will work.

Oops, since I wrote that post in this thread I better correct it here. I forgot to include save2flash capability with firstribit of TinyCoreLinux. Fixing that for next release.

[wanderer]

hi wiak

your tinycore firstrib has been a great learning tool for me
i now generally understand firstrib
but in my opinion the systems are too different to make a useful hybrid
the main reason is that
it can be done
but the repositories of tinycore are too limited and lack polish

i think you should make a minimal debian based firstrib
so you can use the debian repositories
i think this would be useful to everyone in puppy world
and could be a great base for a standard long term support puppy-like distro
others could build on it as desired

with firstribs multiple sfs files
you could have all the advantages of tinycore puppy and firstrib

one could make

1 core command line only
2. basic x with window manager and basic apps
3. sfs extensions for other applications

firstrib is perfectly suited for this

wanderer

[wiak]

it can be done
but the repositories of tinycore are too limited and lack polish

i think you should make a minimal debian based firstrib

Can already do that, and has been done as a scripted frugal install (no iso made of that). The build system of FR simply uses debootstrap for such builds - so you just run the build script to make minimum core Debian distro... and add huge kernel/modules/firmware per common KL designs. Also a simple tweaked DebianDog mklive script can do the same and produce an iso of that. However, Debian is a 'beast' like most distros nowadays - the reason TCL remains interesting is it is tiny and super-fast like no other distro around really. Yes, its repos are small, but if someone wants a more full on distro there is tons of choice (including KL distros) for that. No, I think a FR'd TCL would be nice to have as long as TCL doesn't go down the tubes and vanish altogether.

[wanderer]

hi wiak

well tinycore has only 4 parts

the bootloader ( syslinux )
the kernel
the ramdrive ( command line and basic apps only busybox dhcp )
sfs extensions (which are called tcz ) which are symlinked to the ramdrive

there is also a deb to tcz utility which will allow you to access debian repositories

if you ignore the symlinked package manager
which could work independently of firstrib

and make your firstrib ramdrive load the tinycore ramdrive core (a cpio archive ) as a filesystem sfs

then the other tcz (sfs) extensions could just be linked to that
either symlinked with the tinycore package manager
or with a layered filesystem with firstrib
symlinks and layered filesystems dont interfere with each other

id love to see that

but you are doing the work

which i thank you for

wanderer