Whats up in Puppy World

[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

i have edited this
because i actually have no idea what you will do with tinycore and firstribit
but am looking forward to it

wanderer

[dimkr]

I must say I'm really worried about this discussion about build system and building distros by modifying/remastering other distros. This can lead to 'dilation' of Puppy and even larger variety of similar distros without a clear 'winner' when users need to choose one to use or recommend.

If a Puppy-like distro uses systemd, a kernel from another distro, a proper DE (like Xfce or KDE) and its main advantage is frugal install with PUPMODE 13 (or something equivalent), but it can't be updated (including kernel, boot loader and firmware), resource consumption is higher and it has other disadvantages, then for many users, it's just a worse variant of the distro it's based on.

We don't have enough developers to build a single Puppy release we all like, and we're all building distro factories that produce shelf items that won't appeal to many Puppy users and don't bring much unique value or advantages over Puppy as it is today.

[wanderer]

hi dimkr

aren't our distrowatch candidates the distros everyone is supposed to be supporting ?

wanderer

[dimkr]

everyone is supposed to

Nobody is supposed to do anything, it's a do-ocracy. People choose what to work on, if they do, when they do. But it seems to me like the motivations of the developers we currently have (like the enjoyment of building something of your own or the challenge of building as many distros as possible) don't align with your idea of building a distro that looks like a natural upgrade path from the current offering on distrowatch and giving it some special recognition.

[wanderer]

hi dimkr

we clearly should promote the distrowatch candidates more to the entire puppy forum community

and i think this thread is a good place to do that

they each have their threads
and that is good for development
but not for promotion

so the question is what is going on with bookwormpup32 and bookwormpup64
and how can the community get involved and help

wanderer

[rockedge]

@dimkr you've got to relax

What about Vanilla Dpup as "the one"? What is it again why we can't use it as the future Puppy?

really worried about discussion about build system and building distros by modifying/remastering other distros.

FirstRibIt is a side gig. A powerful tool though....make just about any distro into a frugal, can live in a sub-directory system.

[williwaw]

...worried....... This can lead to 'dilation' of Puppy and even larger variety of similar.........

I can understand that concern, spreading out community development efforts amongst too many projects

We don't have enough developers to build a single Puppy release we all like, and we're all building distro factories......

yes we need more people to get interested in working on the brand with the priorities you often reccomend
reproducibility
efficient codeing
security
update ability

Perhaps the ease of hobbyist distro building will attract some folks that will stickaround for longer term growth into the priorities you cite.

Are there less and less people who code for a living volunteering for OS development in the pig picture, or just with puppy?

as the say in the cults.....
if you cant convert them, then grow your own

[wiak]

yes we need more people to get interested in working on the brand with the priorities you often reccomend
reproducibility
efficient codeing
security
update ability

We can say the above for every distro featured/provided-somehow on this forum. i.e. KL needs more people. Which distro people choose to contribute to is and should be entirely up to them.

My favourite distro is actually (currently) a full normal install of Linux Mint XFCE, BUT... with a KL_full2frugal separate folder sitting alongside it, which gives me the best of both worlds. The frugal part does not have any underneath core sfs root filesystem of its own; it uses the full Linux Mint as the under-layer root filesystem, and can use KL_multi-instances to have hundreds of such frugals at a couple of thousand bytes installation size only each. I then run my Linux Mint frugal instances rather than my underneath full Linux Mint - though I can boot into that instead if and when I wish.

Since it is trivial to upgrade a full installed distro, it becomes trivial to start a new pristine KL_full2frugal instance with updated/upgraded full Linux Mint underneath.

The likes of firstribit, is a different matter - I use that to test out interesting new releases of mainstream distros in a frugal install environment without having to full install them to their own big partition.

I do still use smaller frugal installed distros; mainly a KL distro, but occasionally a new Puppy. I do that generally when I want to use a wee distro I know always has certain dev tools built into it when I want to do some quick development or hacks, whilst able to browse and so on pretty much normally. Also of course I often boot a small KL distro because I am working to improve FR/KL functionality, the results of which also can be used with firstribit-made/converted most any distro, and also with a KL_full2frugal style distro. Why need limitations of approach in Linux world (well, that would be one way to force use of any single distro I suppose)?

[dimkr]

FirstRibIt is a side gig. A powerful tool though....make just about any distro into a frugal, can live in a sub-directory system.

It's OK to have side gigs, but everything here looks like side gigs to me, while @wanderer is asking who's doing the main show.

What about Vanilla Dpup as "the one"? What is it again why we can't use it as the future Puppy?

I don't want it to be designated 'official' because I think it's a really bad idea. I don't mind it if somebody else takes my work, rebrands it with or without changes, takes full ownership of this derivative (describes it as a derivative of my work rather than as my own creation, promotes it on distrowatch or whatever) but leaves me out of this.

as the say in the cults.....
if you cant convert them, then grow your own

Yes, that's why people who like an idea but don't like the implementation or the people who implemented it just implement the idea themselves. Then, when the opportunity to merge with other projects and gain more developers and resources arrives, they refuse to merge because they don't want to lose freedom and prefer solo development to collaboration that produces conflicts and coordination, the things that are simply 'not fun' for developers. The result is huge variety of distros, some come from the same factory with very little attention to detail or quality, have a similar feature set, have similar disadvantages and suffer from the same issues.

Which distro people choose to contribute to is and should be entirely up to them.

Exactly, this is why I'm saying it's unrealistic to expect developers here to build the 'one official Puppy' 1y from now, when everybody seems to work on their project.

Why need limitations of approach in Linux world (well, that would be one way to force use of any single distro I suppose)?

I think that very few actual problems can be solved by creating more distros. For example, PPM has many bugs, and we won't fix them by creating yet another Puppy or by creating a Puppy without PPM. Somebody needs to do the hard work of actually fixing them, if we want to keep shipping Puppy releases with PPM and want PPM to be better. Same with build systems and things like save2flash, building more and more (similar) distros won't improve these things and increase the unique value we produce in this forum, while improving the 'secret sauce' and producing distros with better 'secret sauce' will.

@dimkr you've got to relax

lol, don't worry, I'm relaxed despite the war situation going on here. Development is proceeding at a slow but steady pace, and I have the time to look at annoying little details that can be optimized or removed

[RSH]

3. sfs extensions for other applications

I dare to say that I have become somehow an expert for .sfs files during the years.
Some may recall that I named them SFS-Modules in the early days.

So, there's a lot of useful stuff I could offer to use .sfs files as easy as installed programs.
Running its programs by menu entry, desktop icon and also keyboard shortcut.

Even when running completely without save file and/or save folder.

Interested in some details, anyone?

[wanderer]

hi RSH

i am very interested

i remember what you did in the old days

i think sfs files to make things modular are the key

wanderer

[wanderer]

hi all

just to start a conversation going about this

here is a puppy-puppylike distro i would like to see

i would like to see a modular puppy

1. bootloader module

2. kernel

3. core (command line only) module

4. basic x module

5. sfs modules ( extensions for other applications )

i think it would be a useful base for further development

and fun for everyone to play with and tweak

wanderer

[dimkr]

This idea of a "modular" Puppy is vaporware and it's not super different from what we already have.

[rockedge]

This idea of a "modular" Puppy is vaporware and it's not super different from what we already have.

All of the different distro types featured on this forum can be considered as "modular" so I am agreement with the statement.

[Grey]

idea of a "modular" Puppy is vaporware

One of the vaporware sub-variants.
A picture from an old (1930) magazine about the future. Indeed, they almost guessed right:

future.jpg (105.71 KiB) Viewed 2728 times

[wanderer]

hi sonny

the only time that there actually was a main branch of puppy
was when barry k was creating puppies

barry constantly changed his system to suit his whims
so there was never any static system

and even from the very first there were innumerable variants and remasters
because it was easy to do and was encouraged

its only when barry left to work on other systems
that all this nonsense began
the people that started woof-ce insisted that only woof-ce was puppy
so any other variant was not puppy
and the argument began
and went on and on
ad inifinitum ad nauseam

at this time we have 2 active candidates on distrowatch
which ( i assume ) everyone agrees are an acceptable representation of puppy linux
if someone wants to work on the "official" puppy
help with bookwormpup

everyone else can work on what they want
and their work can create a synergistic effect for everyone ( including the distrowatch candidates )

so whats the problem

wanderer

[Gnimmelf]

I would like to se F96-CE 4 evolve in to new. on my lenovo ideapad gaming 3 its by far the fastest and most responsive system - both regarding small ram use 330 mb or so at running desktop, and bench test on the Google chrome portable browser, compared to other systems like f.eks bookworm etc (nothing bad about Bookworm - i like it too!) . I know speed isnt everything, and i think that f.eks Sofia`s KLV-HyprlandCE has something nice in layout and visuals, but F96-CE 4 works really well, and i can (as a newbie) customize it too something barebone, while it still looks nice, and as i said, really fast and responsive. So its a winner for me! hope to see a sequel soon

[Governor]

It's OK to have side gigs, but everything here looks like side gigs to me, while @wanderer is asking who's doing the main show.

8<------snipped-------

as the say in the cults.....
if you cant convert them, then grow your own

Yes, that's why people who like an idea but don't like the implementation or the people who implemented it just implement the idea themselves. Then, when the opportunity to merge with other projects and gain more developers and resources arrives, they refuse to merge because they don't want to lose freedom and prefer solo development to collaboration that produces conflicts and coordination, the things that are simply 'not fun' for developers. The result is huge variety of distros, some come from the same factory with very little attention to detail or quality, have a similar feature set, have similar disadvantages and suffer from the same issues.

Which distro people choose to contribute to is and should be entirely up to them.

Exactly, this is why I'm saying it's unrealistic to expect developers here to build the 'one official Puppy' 1y from now, when everybody seems to work on their project.

Why need limitations of approach in Linux world (well, that would be one way to force use of any single distro I suppose)?

I think that very few actual problems can be solved by creating more distros. For example, PPM has many bugs, and we won't fix them by creating yet another Puppy or by creating a Puppy without PPM. Somebody needs to do the hard work of actually fixing them, if we want to keep shipping Puppy releases with PPM and want PPM to be better. Same with build systems and things like save2flash, building more and more (similar) distros won't improve these things and increase the unique value we produce in this forum, while improving the 'secret sauce' and producing distros with better 'secret sauce' will.

8<------- snipped-------
Development is proceeding at a slow but steady pace, and I have the time to look at annoying little details that can be optimized or removed

Naturally, no matter what the endeavor, people tend to do their best work when they are inspired.

A VP (volunteer programmer) has no boss and no deadline. There is no boss to tell the programmer what to work on, that a project is missing something, or is incomplete, or must be done over from scratch. I could be wrong on this one: but it seems to me that VPs are often not that keen on correcting a ‘deficiency’ in another programmer's work.

It has been my experience and observation that programmers doing non-commercial or volunteer programming typically do whatever they feel like doing at the time. This could be what they are inspired to do, or what they decide themselves that they must do even if they don’t particular like it, fixing something that was not completely successful, or doing something mundane like adding a help function (because Linux users should already know that).

I have noticed several issues that no one pays any attention to or cares about. IMO, the real reason why Linux will never be mainstream is not due to the Microsoft monopoly, but to the general lack of user-friendliness in the OS/software. I think many, if not most computer users, would jump at the chance of leaving Microsoft, saving money, and ditching the surveillance/telemetry.