Puppy Linux Discussion Forum

Grey wrote: ↑Sat May 18, 2024 7:36 pm

Deleted (violated terms of this forum)

By the way, a certain percentage of my acquaintances and friends do not trust developers who themselves do not use (all the time) the OS they develop or support. OK, let's soften the term a bit ... It's not that they don't trust, but rather they are... wary.

It's a complicated feeling. Rather, it is a complex of sensations on an intuitive level

I am sad for all your 'acquaintances and friends'. They are doomed to spend eternity beside themselves because the ARE NO serious devs who use nothing but their own OS's.

That's like saying you would only trust a mechanic who only drove cars that were built by himself.

On a separate note, it's nice to hear you have 'acquaintances and friends'.

Jafadmin wrote:

That's like saying you would only trust a mechanic who only drove cars that were built by himself.

Just lying about that is often considered the best "promotion", by saying "Of course I use it myself too !!"

wanderer wrote: ↑Sun May 19, 2024 12:30 pm

we mere mortals need something that we can use
that is why the single script approach works so well for us

I think that a fully automated solution where you fill a form and get a newly built Puppy that's built in a clean build environment in the cloud, on a fast machine, is much easier than running a script on your computer. It's more likely to work, and you don't have to install anything: you only need a browser.

(If you want a script you can run locally, you can run the entire build procedure locally, but you'll need a suitable OS, enough disk space, enough time, etc'.)

wanderer wrote: ↑Sun May 19, 2024 12:30 pm

we can run it and it magically does what we want

Same here, but it's a different degree of magic. There is a script behind the scenes, but you don't download and run it: you ask it to run on a fast machine and only get the build output.

wanderer wrote: ↑Sun May 19, 2024 12:30 pm

only people of your rank can navigate the maze of woof-ce

This "maze" is not that hard to understand, it's summarized in one short list (https://github.com/puppylinux-woof-CE/w ... -structure).

Did you read the woof-CE README before you described woof-CE as complicated or messy? We don't have many contributors, and this kind of statements can demotivate the (few) potential contributors we have, and that's not good for Puppy. If you have constructive criticism of this README, go ahead and share it so we can improve the documentation.

dimkr wrote:

Did you read the woof-CE README before you described woof-CE as complicated or messy?

Messy ? Can't judge, probably not. Complicated ? Yes IMHO. I can easily understand that someone gives up already (to even start trying) while reading it, anyway, I personally do too, sorry.
But of course, as with any advanced stuff, it's about how much knowledge you have already (edit: e.g. about usage of git / github) and how much time you want to spent (and possibly frustration) in learning it.

Jafadmin wrote: ↑Sun May 19, 2024 1:16 pm

I am sad for all your 'acquaintances and friends'. They are doomed to spend eternity beside themselves because the ARE NO serious devs who use nothing but their own OS's.

That's like saying you would only trust a mechanic who only drove cars that were built by himself.

On a separate note, it's nice to hear you have 'acquaintances and friends'.

If you wanted to "tease", then it's better to use a story about a chef who doesn't taste his dishes.

This is not about commercial activity. In an open environment, it's OK to use what you've done yourself. If you don't need it yourself, then who else does?

And yes, I have some acquaintances. I'm a pretty likeable, honest and open person. Sometimes immodest, but these are small things.

wanderer wrote: ↑Sun May 19, 2024 11:45 am

could the FirstRib developers
make a script to produce a base iso
that is usable as a working distro

just

jwm -rox
xterm
text editor - geany
firefox
media player
image viewer - viewnior
internet access

so anyone could just run the script
and build the iso
and use it for basic tasks

This could be done, but for quick info to anyone interested for the moment (this should be better documented better elsewhere later):

Developers tend to have no time to build what we don't want or need. Whilst there are some old builds of KLV with JWM plus Rox, these were rudimentary and never polished up further since KL devs tended to want to try new technologies.

A good exemplar of a single KL build script, following on from some exemplars I gave of similar script for some builds of my own, is provided by Sofiya for KLV-Hyprland-CE:

viewtopic.php?t=11566

Okay, so running the provided single build script (KLbuild_Void_hyprland_0.40_swayBASE.sh) will not result in a Puppy-like JWM/Rox distro... In fact it doesn't even use Xorg. Instead it builds a Wayland plus Hyperland desktop compositor distro. To use it, you simply run that single executable bash script in the empty directory where you want to frugal installation to be automatically made for you.

Note that KL build scripts that have been produced thus far tend to be intended to only directly produce frugal install into empty directory creations. If you later want to make an iso of the working result you'd need to make sure you computer contains iso maker software such as xorriso or mkisofs and the likes of EFI/grub boot components and get some help from KL devs on how to do that...

All that single KLbuild script really does is to download the FirstRib/KL build components required, which then get used automatically to create the complete and working frugal installation. The script automatically also prints out a correct/working grub configuration you can immediately use.

If you like the produced distro and would like to later modify the build to include other apps and utilities you want to have, that is easy. One of the components KLbuild fetched (using wget command to Sofiya's own repo) is a simple text file of bash commands, that controls what packages to add and configure. After building KLV-Hyperland-CE you will find that text file in the frugal install directory; in this case it is the file f_00_Void_wayland_hyprland_0.40_no-kernelBASE.plug

To really understand how the build was done, truly all you need to do is read that f_XXX.plug text file in your favourite text editor. To modify the build and use different apps and configuration just edit it and repeat the build.

Actually you don't need to make an initial build to get a copy of that f_XXX.plug file. You can simply, for this KLV Hyperland creation, download it directly from Sofiya's repo (she uses git to organise that, but you don't need to understand or use git at all to use FR/KL build system):

wget -c https://gitlab.com/sofija.p2018/kla-ot2/-/raw/main/KLA-Hyprland/plugin-0.40/f_00_Void_wayland_hyprland_0.40_no-kernelBASE.plug

If you modify that to include whatever new stuff you want (or remove stuff you don't want) you can build the new version according to your modifications simply by then running the simple single build script via command:

./KLbuild_Void_hyprland_0.40_swayBASE.sh

The f_XXX.plug file doesn't get re-downloaded if already there on your system.

So if you truly want to learn or understand how to build a distro using FirstRib build system, just read that KLbuild script and the f_XXX.plug file whilst you are at it.

Of course the f_XXX.plug file becomes as complex as the creator needs to polish the distro, but general principle is simplicity itself; the all important f_XXX.plug distro build recipe is just a list of simple bash commands.

Once you have done the above, there is no reason you couldn't modify the f_XXX.plug file to use xorg with jwm and rox instead of Wayland with Hyperland, but of course you will have a lot of work to do since the f_XXX.plug commands need to provide the recipe you desire... so you do need to understand Linux and learn typical config commands for the likes of JWM, adding new users, and whatever you want your distro to be able to do. I tended to consult Arch Wiki to help me with such matters; such is how you end up being called a 'developer'.

Let me know when you've created your KLV JWM/Rox variant! Rockedge has made a few rudimentary versions of these in the past few years, but concentrated on KLV-Airedale since the XFCE desktop environment used comes well-configured out of the box (i.e. the Void repo) so is easier to make since upstream Void devs already do a lot of XFCE configuration work for you... Many hands make lighter work and no time wasted re-inventing that particular wheel.

fredx181 wrote: ↑Sun May 19, 2024 3:02 pm

advanced stuff, it's about how much knowledge you have already (edit: e.g. about usage of git / github)

In this particular case, you only need to create a GitHub account. No git knowledge is needed if you only want to run woof-CE!

If you want to modify woof-CE, you can do this without knowing how to use git, too, by following https://github.com/puppylinux-woof-CE/w ... ibutor-101 or using an IDE that wraps git with GUI and a tutorial (like VS Code).

A build system that churns out clones of the same build have limited usefulness whether auto-done by github or run on local host system. Not many forum members I feel have the ability, or at least the knowledge, to alter the result produced by woof-CE.

More important is how easy the build can be changed and simple script with linux package management commands works well in practice. A lot of people know quite a bit about linux commands and basic shell scripting here (and how to use a package manager).

hi dimkr

i certainly dont want to demotivate anyone

and i have used woof-ce to make a distro or two

and i would like to give some constructive criticism

thats one of the questions i asked earlier on this thread

"should we try to make woof-ce more usr friendly"

i actually think we can by doing a few things

1. we need to have one basic build
that runs flawlessly to completion
and makes an error free complete working system

lets call it a basic standard puppy

this would allow someone trying to learn woof-ce
to be successful in their first build

when i ran it
it ran fine and gave me an iso ( relatively easy )
but the iso was incomplete and buggy
so then i had to troubleshoot the iso ( very difficult )

what is the use of running an automated process if after you run it
you have to correct things manually

2. we must remove the need to deal with github
by producing snapshot build tarballs that can be run the old way
on a local computer

the tarballs should have all of the packages in them
so people dont have to deal with the download process
most things dont change from build to build
so the original builder can download everything
and just pass the tarball to people who want to work on it
so they dont have to download everything all over again
this saves on repository server load too

github can still be used for development
but many people dont want to deal with github
and that is a great demotivator

3. the basic standard puppy build
should be well

very basic - that is only the minimal apps to make it a working system

and very standard -

a. no trick modifications to the build process that developers like to try
just the standard repeatable process

b. just the apps you need to do basic tasks
proven stuff not cutting edge

people can then download the tarball
untar it in a directory on their hard drive
read the instructions
run the build
use the iso
figure things out
and try their modifications

these modifications can then be passed back to other developers
and incorporated into the main woof-ce branch on github

4. we should also work on making a single file template system

that consists of a single file with all the instructions the build needs

the modifications that the local developer makes can then be
recorded in this template file

and this new template can be the method to transmit the modifications
either back to github or to other developers

when i receive my first tarball
and run it
i will give you more suggestions

this should be relatively easy to make for the woof-ce gurus
you are building something basic
not trying to reverse engineer a distro
as you are trying to do with radky's bookworm pup

this basic standard puppy
can then be used as our

well

standard puppy
that can be the base of further development

i look forward to downloading my standard puppy tarball

wanderer

wiak wrote: ↑Sun May 19, 2024 4:29 pm

Not many forum members I feel have the ability, or at least the knowledge, to alter the result produced by woof-CE.

Not many actually tried, some just echo the statement that woof-CE doesn't work or woof-CE is too complicated to use, without doing some fact checking on their own and actually trying to use woof-CE.

wanderer wrote: ↑Sun May 19, 2024 4:37 pm

1. we need to have one basic build
that runs flawlessly to completion
and makes an error free complete working system

This table shows which build configurations run to completion: https://github.com/puppylinux-woof-CE/w ... py-builder

It also gives you download links of the latest builds.

The Debian 12 configuration is very close to BookwormPup64. If you consider it to be an "error free complete working system", then these development builds should be, too.

wanderer wrote: ↑Sun May 19, 2024 4:37 pm

what is the use of running an automated process if after you run it
you have to correct things manually

Software doesn't grow like mushrooms, developers need to develop it to make it happen. Bugs don't fix themselves, developers do. And software is imperfect like every human creation, expecting everything to 100% stable with 0 bugs is unrealistic.

wanderer wrote: ↑Sun May 19, 2024 4:37 pm

2. we must remove the need to deal with github
by producing snapshot build tarballs that can be run the old way
on a local computer

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

Go to Code -> Download ZIP, and there you have your tarball.

https://github.com/puppylinux-woof-CE/w ... esting.zip

wanderer wrote: ↑Sun May 19, 2024 4:37 pm

github can still be used for development
but many people dont want to deal with github
and that is a great demotivator

Discussion forums are good for discussions, development tools are good for development. Without tools like git, it's nearly impossible to be productive as a software developer (especially as a volunteer who tries to make good use of limited free time) or collaborate with others. Sharing source code in forums works only in small, amateur projects that don't change much and have mostly one developer.

wanderer wrote: ↑Sun May 19, 2024 4:37 pm

this should be relatively easy to make for the woof-ce gurus

There are no gurus, just ordinary people like you and me. The basic instructions for running woof-CE are written in the README, which you probably didn't read, and editing configuration files like DISTRO_SPECS doesn't require too much knowledge (DISTRO_NAME is, unsurprisingly, the name of the distro).

wanderer wrote: ↑Sun May 19, 2024 4:37 pm

i look forward to downloading my standard puppy tarball

https://github.com/puppylinux-woof-CE/w ... esting.zip

./merge2out ./woof-distro/x86_64/debian/bookworm64
cd ../woof_out-*
./0setup
./1download
./2createpackages
./3builddistro

If something is missing on your computer and the build fails, you can follow https://github.com/puppylinux-woof-CE/w ... -on-GitHub instead. It will run the same series of commands in a clean Ubuntu machine that has all required packages. You only need a browser and a (free) GitHub account.

If you're very impatient, just go to https://github.com/puppylinux-woof-CE/w ... okworm.yml, select a line, go to Artifacts, and there you have a .zip of a previous build.

In review of this thread this morn, I come away with several thougths.

• An idea of what is used

• An idea of what builders are used

• An idea of what is felt to be directional

• An idea of what is comfortable, IMHO

In no particular order, i share a view.

An idea of what is comfortable
I, over the year, am one who lacks the kind of skills that I feel @dimkr wants members to have. I emphasize "feel" to assert I am probably NOT entirely accurate. So, soon after WoofCE started, I have resigned my efforts of the forum as a mere evaluator and helper to find simple ways that new/unskilled users can easily get to a desktop to developer a feeling of comfort as well as useful in helping others by there staying with the forum.

I feel that by doing so, it is one of the best methods of keeping membership, once here. Further, it has the ability to help developers with a new level of productivity that they dont need, but may see value in supporting efforts that make it easy new-unskilled to want to remain, gain skills, and grow into contributors.

What I do to contribute is what I find as comfortable and helpful. I do recognize that older seasoned skilled members may find this unnecessary, but others, including developers have found some value in the productivity found in what I do.

An idea of what builders are used
Firstly, a 'Builder' is a running system generator. It 'builds' an OS or a distro. The builder's production (aka a generation) is one of the 3 followings:

1. ISO

2. IMG

3. running installed system

One of the problems is how some developers view a generation, which differs from my own. Having been in the industry for about 70 years, a generated OS is delivered in some sort of package. That package is one (or more) of those 3. Thus my finding and knowledge when I see something is to merely understand if I have the tools necessary to get the generation operational on my platform(s). I have no preference to either production delivered and COULD CARE LESS. I dont use a distro/OS because it was delivered in some developer's idea of which format he forces his users to adopt. I use a distro in production because of what it contains to make my life easy and what is present to adapt the OS to my needs when things need to added or upgraded.This merely means that a developer should NOT be spending much time in forcing a productions format down user's throats, rather on those things that will be attractive to gaining as many people as possible to evaluate and find useful what they produce versus any nonsense on a format's deliverable, IMHO.

Secondly, there are 8 unique 'builders' on this Puppy forum for Linux distro generations. The most well-knowns are:

• @BarryK's builders

• WoofCE's builder

• @fredx181's and @rcrsn51's builders

• @wiak's FirstRIB and the KL's builder used by @rockedge and @Sofiya

• @kirk's and @jamesbond's builder

The best thing ANY of these 'should' strive for is to envision how easy can any be made so that the most un-skilled, un-intelligent of us can easily achieve something useful. This might mean having an all-in-one feature as well as an advance feature where necessary.

Each subcommunity on the forum, when a user desires, can use the available generation the developer provides or use the genertion tool that is available.

WoofCE has an advantage in that its generation can be done on GIT rather than on the local PC.

In any event, these are tools with the intent to replicate the developer's production(s).

An idea of what is used
Personally, I have found enormous benefit using a Bootmanager. In a way, when I think of booting any PC, today, since 2019, it is grabbing my Bootmanager USB, booting it, then selecting the ISO that meets the need i have.

This has eliminated any considerations to change or modify my boot system every time I add a distro or OS (the bootmanager USB has eliminated this need for all current known distros/OSes I want to run). I no longer do this for ANY reasons for all OSes I have tested or use in production over the past few years. And within moments with little to no thought, I am on a particular desktop fully operational.

An idea of what is felt to be directional
I have desires like the many members here. If I suggest any, there will be those who agree and those who disagree.

MY personal perceptions since my days of development is that each and every developer or development group sees a beneficial approach of creating and presenting what they find and deem useful Some development is extraordinary while others re-directional upgrading enhancements. Personally, I support all and will evaluate when opportunity presents.

In Summary
I hope some of what is share provides some helpful insights. It intends to stay within the confines provided by the OP of this thread.

So I ask, please, no one take a single sentence of this post on the thread and make your comments about the post centered around a single sentence. It would be disingenuous and unfulfilling. This post in NOT about a single sentence.

Remember: Its just a view.

hi dimkr

thanks for your reply

and for all your hard work over many years
everyone in the puppy community really appreciates all you have done

you gurus have made and are making many fantastic distros with woof-ce
i assume you will continue your endeavors as long as it pleases you

i know you feel gihub is needed for professional development
i know it is difficult to make an ( essentially ) error free build
and i know there is a lot of stuff somewhere i can access if i try

but you asked for suggestions on how to make woof-ce more usr friendly
and i have given them

i dont see any issue with the woof-ce gurus
continuing to do what they want to do using github and woof-ce

but i prefer fredx181s debiandog system
it is very user friendly

you use woof-ce
i will use debiandog-live
and we will both be happy

wanderer

wanderer wrote: ↑Sun May 19, 2024 5:57 pm

you use woof-ce
i will use debiandog-live

Fine with me, as long as nobody spreads what may be perceived as FUD about the projects they don't use and discourages potential contributors.

you are right dimkr

we need to be more positive about woof-ce
we are needlessly bashing it

if you take the time to learn it
it is a great system
as proven by the great work you all do

i think that if we had a short set of instructions
on how someone could get started using woof-ce

we could publish it on this thread
and people could read it
and comment on it

it might encourage more people to learn it
and get involved

ignorance breeds fear

if you have the time
could you find a short set of instructions
and post them on this thread

and once again thanks for all that you are doing
and all that you have done

and that goes for all the puppy gurus

by the way i use a woof-ce puppy as my main distro

wanderer

and thats another important question for the puppy world thread

how can we all help the developers with their tasks

maybe they can tell us

wanderer

Not being familer with how the different build scripts work, I wish to ask if building the initrd is scripted or needs special expertise and attention by the dev.
for
debian dog?
Puppy?
Easy?
KL's?

hi all and dimkr

i have been thinking about what dimkr has said
about the negative attitude that has developed about woof-ce

puppy needs every developer it can get
since very few people are doing all the heavy lifting

we want to encourage not discourage participation

and woof-ce is the system that creates puppies

so it behooves us to try to help people get involved and contribute to woof-ce

the things i suggested to help sound fine to me
but clearly have drawbacks that dimkr sees

so i am asking for ideas on how to make woof-ce more usr friendly
and attractive to potential developers

i did make a few isos with woof before it was on github
so i am going to try to go through the process again using github
and see if i can see some ways to make it more usr friendly

i am no developer
but i may be able to make
(with help and advice)
the standard base iso i have talked about

the iso may even be useful to the puppy community

there is nothing to lose by trying

i think if we have a simple set of instructions
on how to get involved with woof-ce development

and we keep the focus on trying to make woof-ce on github usr friendly
more people will get involved

i am learning and using debiandog-live
which is a masterpiece

but i can fail at both
as easily as i can fail at one

this is what i intend to do if i can
take a simple debian 12 build
and strip everything except the essentials out of it
so i have just a core sfs

everything else will be added later as sfs files

so wish me luck

the next step is for dimkr
to point me to the entry point for woof-ce on github

wanderer

hi williwaw

debiandog-live
has a single build script that you run to build the iso
go to the bookworm mklive thread under bookworm debiandog
its very straightforward

puppy woof-ce
has a sequence of scripts
that you run to download the debs
and then run another to build the iso etc
dont remember exactly how many
2 or 3

the ramdrive is usually prebuilt
but you can open and close it

if you want you can help me build my debian 12 standard base iso in github
just follow along on this thread
as i go through the motions

i am going to have to wait for dimkr to start us out
since github is totally alien territory to me

wanderer

williwaw wrote: ↑Mon May 20, 2024 12:28 am

Not being familer with how the different build scripts work, I wish to ask if building the initrd is scripted or needs special expertise and attention by the dev.
for
debian dog?
Puppy?
Easy?
KL's?

For FirstRib, yes, there is a build script for building the whole FR initrd. In practice that particular build script is no longer used much, but it remains usable for development purposes if ever wanted or found useful for some new purpose, or simply to build new FR initrd overall structure from scratch.

The reason it isn't used much is simply that most of initrd is simply a non-changing skeleton; the bit that gets modified to change the overall working of the initrd is simply a shell script called 'init'. FR initrd actually splits that init file into two separate code files, one of which necessarily hides inside the usually compressed initrd in order to find and mount needed boot partitions, and the other part, we call w_init, which can instead reside outside of the compressed initrd and thus be easily modified and edited simply via the likes of geany text editor.

The bulk of FirstRib initrd-related boot code has actually been put into that externally usable and thus easily accessible w_init file. For example, all the code concerning overlayfs layer tricks, which makes adding or changing FR frugal install layer features particularly convenient from a development perspective or quick experiments. For example, modifying FirstRib initrd to use other layer techniques instead of overlayfs, or temporarily or permanently mounting a new filesystem (in uncompressed directory form or as an sfs) for use as one of the active layers.

Clarity wrote: ↑Sun May 19, 2024 5:23 pm

WoofCE has an advantage in that its generation can be done on GIT rather than on the local PC.

Indeed, though I believe that could be done (arranged) for any of the other scripted build systems.

dimkr wrote: ↑Sun May 19, 2024 5:19 pm

Sharing source code in forums works only in small, amateur projects that don't change much and have mostly one developer.

Well, that depends on the overall build mechanism and strategy employed.

For example, the FirstRib-based distro development method revolves around the creation of a single text file of commands, which we refer to as the f_XXX.plug file (which can source other similar files if it needs or wants to, or employ the likes of wget to download pre-made skeleton distro parts). One of the main things that file does is simply to use package management commands to add whatever apps or utilities an individual builder prefers and code to configure these and any part of the distro operation in any way that distro builder wants. There are no weird distro-specific spec files a user first has to learn or understand and comply with in terms of any special format; rather it is straight bash/Linux commands, which many people on this forum already understand quite well (even though they may need to refer to the likes of Arch Wiki or Void documentation for info they may require to change things). As below says, an f_XXX.plug file acts, in actual practice, as a user build template:

A result of that simplicity is that collaboration in terms of how KL/FR distros are built is not forced at all. The likes of myself, rockedge and Sofiya, for example are free to construct the system in any way they wish via our own independent f_XXX.plug files, but actually we tend to copy bits and pieces of these from each other and learn from each other as that ongoing f_plug file new distro development proceeds.

The above does not imply that no collaboration happens. In fact the opposite is true. Being usually simply a single script of bash commands, the f_XXX.plug file absolutely acts as a template system that others can copy and modify for their own design. Examining any KLV-related f_plug, for example, shows that much the same code commands are used by everyone involved for basically setting the distro up, since a Void Linux based system always uses its specially designed runit main root filesystem init system and FR/KL distro builders constantly learn from each other how to, for example, script how to autologin as root, add new users, and whatever else. Collaboration is easy with this system as the many now developed KL distros evidences anyway.

Of course git CAN be used to collaborate on any or all f_XXX.plug files being developed to produce alternative KL distros (including for other upstream distro types such as Arch Linux, Ubuntu, Fedora and so on), but being so simple in concept and so easily modified per user needs or wishes in terms of different desktops, apps, or utiliities and so on, git is certainly not required. Call that 'amateur' if you wish, but actually it is just a powerful feature of the methodology that encourages new development and build involvement.

Anyway, it is not as if there has been more than one developer doing much development for Puppy on woof-CE for a long time and there must be reasons for that lack of contribution surely?

Package Managers?

Linux seems to never want to settle on one specific way to package software.

So what does Puppy do?

Have a package manger that only supports pet packaging?

Only one that supports deb packaging?

Only the package manager that is used with the Linux OS, it is using core Linux files and programs from?

Maybe just have in the Puppy version, what package manager(s) that will provide the most options to install new software.

If it needs to be more than one single package manager, so simply have more than one.

Puppy Package Managers (PPM) big problem is the Puppy official repository http://distro.ibiblio.org/puppylinux/ is not being updated with pet packages, specifically compiled for a specific Puppy version.
So, it has no repository of pet packages, for a specific new or newer Puppy version.
Each Puppy version needs it's own repository of pet packages, compiled or known to work in it.
Only repositories it can use, is the common and noarch ones.
Those have pet packages, that are as much as can be, universal to any Puppy version.

hi all

i have begun my journey
to build a debian12-64 bit woof-ce puppy standard base iso on github

followed a link to the woof-ce github page and located everything
pretty much everything is laid out
looks like if i just keep reading and asking questions
i will eventually figure things out

i will try to ask dimkr some questions if he pops back up

wanderer

hi all
dimkr has provided a zip file of the woof-ce bookworm tarball

opened it and looking at it now
looks a lot like the old days

we will read things and see if i can run it

wanderer

hi dimkr

thanks for the tarball

i know you think i never read any of this

but i did and actually built a few of these before in the old days

looks very familiar

will keep moving on

wanderer

dimkr wrote: ↑Sun May 19, 2024 12:15 pm

Is this a real problem? Is this the primary reason for Puppy's stagnation, and not the lack of skilled contributors?

Has puppy stagnated? Or has it matured to the point where users can fairly easily hit the sweet spot for their particular hardware and get on with their computing without drama.

Yes, there are some users who constantly scream for devs to make Puppy more of a clone of windows (Captain Blarity for example). But I think there are many others who have plenty of Puppy choices and lots of success. It would be hard to think of a distro that allows more individuality than Puppy does. (And by "puppy" I include all of the dogs and ribs that "once were Puppians" have spawned)

greengeek wrote: ↑Mon May 20, 2024 6:31 am

puppy stagnated? Or has it matured

It's the same thing, mature software without a skilled maintainer begins to rot, especially if 99% of its components are third-party and the third parties release new versions, make breaking changes and have their own goals and priorities. Stagnation happens when nobody is doing the dirty maintenance work and technical debt piles up to the point nobody wants to step in and become the maintainer.

woof-CE still works, but many Puppy releases built by it ship with dead stuff like X.Org, GTK+ 2 and ROX-Filer, almost-dead stuff like aufs, misconfigured kernels with bad hardware support, and other problems. The low rate of change means stagnation that some describe as maturity ('it ain't broken', etc'), and one day it won't be possible to build Puppy like this because these components will be gone or too broken.

dimkr wrote: ↑Mon May 20, 2024 6:58 am

many Puppy releases built by it ship with dead stuff like X.Org, GTK+ 2 and ROX-Filer, almost-dead stuff like aufs, misconfigured kernels with bad hardware support, and other problems. The low rate of change means stagnation that some describe as maturity ('it ain't broken', etc'), and one day it won't be possible to build Puppy like this because these components will be gone or too broken.

Well, I think there is a place for gtk2 and all of it's associated utilities. And I think there is a place for an OS that is capable in it's own way without constantly trying to keep pace with the modern web. In my view an old PC can be very very useful even if the web shuns it. Anyone who wants to keep pace with a Googified web can always use Win 11, or Apple, or Android. There will always be some form of Linux that can run a capable browser. Why shackle Puppy with that requirement?

It's pretty obvious that those who lead browser design and web design fully intend to stay ahead of the pack just as Microsoft always has done with word processing. To lead us by the nose. But hey, I still use Vista era hardware so my perspective is out of date. The day will come where the available hardware DOES in fact force operating systems like Puppy to effectively be a clone of Windows - or at least to be a transparent slave of the ruling class. (32bits was always sufficient to have a functional web - 64bits was always about monitoring and control). Puppy has other purposes in life than just chasing web currency.

What is the point of doing exactly what every other OS does?

I think that creativity has taken a back seat in favour of keeping up with the rest of the multitude of operating systems, and the web in general.

Some say that the original Puppy mantra of being lean and mean - is outdated. That modern hardware has alleviated the need for a stripped OS. No more need for an efficient way of doing things. No need to seek the road less travelled. But I disagree. There are so many projects on this forum that offer new directions for puppy.

wanderer wrote: ↑Mon May 20, 2024 12:45 am

this is what i intend to do if i can
take a simple debian 12 build
and strip everything except the essentials out of it
so i have just a core sfs

everything else will be added later as sfs files

Oh how I miss RSH / Taersh etc. This is exactly the sort of thing Puppy should be doing (already did). Sometimes creativity gets driven underground when it is too advanced. Chasing the web does not necessarily require cloning a windows core. There are other ways...
(Love the work you did with Tinycore wanderer... Be nice to see a new Puppycore supplant Tinycore). Actually - I would say that Ozsouth's work with Fossa 95 stripped pups is a great example of such work. Worthy of a trial I would suggest.

greengeek wrote: ↑Mon May 20, 2024 7:34 am

Why shackle Puppy with that requirement?

An OS that can't run a full-featured modern browser is not super useful.

Modern multimedia tools for Linux do this through PipeWire, modern browsers are starting to depend on GTK+ 4 ... once PipeWire is the only supported screen capture or audio playback backend and X11 support is dropped (two perfectly possible scenarios, even within <1y I'd say), you can't run a modern browser (with all features working) anymore in a Puppy with X.Org that uses plain ALSA for audio.

The 'it worked until now so why change' argument sounds like a logical fallacy to me, just like 'I haven't died at age 20 or 40, so I'm more likely to live at 80'. It worked until now because some applications still fall back to ALSA, still support X11, etc', and this is subject to change because Puppy is among the last distros that haven't switched already.

greengeek wrote: ↑Mon May 20, 2024 7:34 am

What is the point of doing exactly what every other OS does?

Things "just work" on other distors because other distros do what everybody does and not a weird Puppy-specific thing.

For example, most Puppy releases don't support Bluetooth audio at all because they stick to plain ALSA without PulseAudio or PipeWire. That's a big price to pay for a negligible reduction in RAM usage and disk space. This 'creativity' also has downsides.

---

With all that said, I don't think a 'modern Puppy' must be bigger and heavier than an outdated, 'classic Puppy'. On the same machine, my latest dpup development builds (pure Wayland environment, with PipeWire, no X.Org, no GTK+ 2, etc') consume about 25% less RAM compared to today's releases with X.Org, ROX-Filer and everything. There are ways to modernize while staying lean or even getting leaner than before. Modernizing Puppy is not guaranteed to turn it into 'yet another distro'.