Puppy Linux Discussion Forum

I first joined the Puppy forum (under another name) about 19 years ago. Barry would make us a puppy and we'd discuss, troubleshoot & occasionally extend it. Over time, I began to contribute. I am still making some puppy things that folk enjoy, & being over 70, until those things hit the wall, it's the best I can offer. At the same time, I understand the need to not stand still, as the rate of change is increasing.

hi dimkr and everyone

the browser is the primary component

limited resources should be concentrated on supporting that

the rest is just a platform

i still use emelfm and gtkedit
gtk1 apps
they work fine and are fun

and why cant we simply " borrow "
the browser components
from one of the bigger distros
debian for instance

linux is all about sharing

wanderer

hi dimkr and everyone

this is what i think

puppy is a concept
not a particular piece of code

this religious worship of "the ancient sacred puppy system" is bizarre

people use applications not operating systems
no one cares whats under the hood
and besides whats under the hood is pretty similar in any linux system

our resources are limited

fredx181 has made a "puppy" out of debian
his build system is without equal

let us adopt debiandog as our "puppy"
and simply put puppy stuff in it

the large debian team will do most of the work
and keep things up to date
and we can then puppify things
and make it into a "puppy"

everyone else on the forum can continue to work on whatever crazy idea they like as usual
maybe even "the ancient sacred puppy system"
but we will not be constantly treading water

wanderer

now i will go back to playing with the "ancient sacred puppy system"

but only for fun

wanderer

wanderer wrote:

fredx181 has made a "puppy" out of debian
his build system is without equal

let us adopt debiandog as our "puppy"
and simply put puppy stuff in it

Let's try to avoid now and forever the question "what is a Puppy", instead let's define "what is NOT a Puppy ?". Answer: DebianDog is NOT and will probably never be, simply because it's totally different.
Besides that, you didn't ask me, but if you would ask me if I would agree to adopt debiandog as our "puppy" I would not.

And IMO you are sometimes thinking much too simple about things (e.g. technical solutions), what dimkr is trying to tell us (if I understand well) is that in the future some software will become obsolete, won't work anymore with modern computers (e.g. GTK2 Xorg etc...).

fredx181

i stand corrected

wanderer

wanderer wrote: ↑Mon May 20, 2024 9:39 am

and why cant we simply " borrow "
the browser components
from one of the bigger distros
debian for instance

You can borrow Debian's Chromium, but it needs Debian's PipeWire to do screen capture, access your camera and play audio, it needs Debian's GPU drivers for GPU-accelerated playback, it needs Debian's glibc ... you'll need to 'borrow' all the way down. It would be much cleaner to build a Debian-based distro and install your favorite applications on top (from Debian's repositories, from Flatpak, from AppImages, ... you decide).

This 'borrowing' concept doesn't scale because if you borrow incompatible package A and it works, maybe you got lucky. Then, when you borrow package B and it also works, then C [...], you eventually reach the false conclusion that you have a highly 'compatible' and stable distro. But you can't change or update anything because everything was 'borrowed' from the right place at the right time so everything happens to be binary compatible enough for it to work. Every little thing you change breaks the 'version equilibrium' you reached where all scavenged components are neither too old nor too new (for example, glibc is at version x and no application was built against glibc>x). A frankendistro built like this is just too fragile to maintain over time and development gets slower over time, as technical debt piles up.

The lack of 'borrowing' is exactly why the DebianDog model of development works so well - it's a thin layer on top of Debian, making it way more compatible with Debian compared to a Debian-based Puppy. Packages that work with Debian are more likely to work on DebianDog compared to a Debian-based Puppy, because it's a customized Debian and not a Puppy built from scavenged Debian parts plus .pet packages and re-assembled in a way that kinda resembles Debian.

hi dimkr

my point is you are going to kill yourself with overwork
trying to do all the jobs that a hugh team does at debian

why not just use a debian base
and make it into a "puppy"

ok ok i know i cant say puppy

why not make it into
a small full featured flexibly deployed easily modified distro
like puppy

in my opinion your talents would be better used creating than endlessly maintaining

wanderer

@wanderer This is exactly the direction I'm going for in my Vanilla Dpup 11.0.x development builds, and my plan is to have a polished distro by the time Debian 13 is out. It's much closer to Debian compared to today's Puppy, and it should be surprisingly light and snappy, although size is about the same.

(It's open for contributions)

It's built by https://github.com/vanilla-dpup/woof-CE, which is basically a wrapper around Debian's debootstrap that builds few Puppy packages from source and adds Puppy things like sfs_load, but that's about it. There are very few things to maintain, all legacy stuff like X.Org is gone, and everything is reproducible from source (no prebuilt gtkdialog, for example). I think the project scope is narrow enough for me to maintain this, and for a solo developer to fork this and build their own distro.

I left the woof-CE organization because I don't think it's realistic to maintain woof-CE with its current scope. There's too much variety there (Slackware-based Puppy is unpopular but requires extra code) and it's too tied to ROX-Filer, JWM, gtkdialog and other unmaintained things to justify the effort of maintaining woof-CE itself.

bless you dimkr

that is music to my ears

wanderer

and even though i annoyed fredx181

by not asking him first ( for which i humbly apologize )

i think you should take a look at his system

which i know you already have

it could be put on github too

wanderer

hi all

now that it appears everyone has thankfully finally come to their senses

i will not be playing with woof-ce ( it is a historically important and interesting exhibit in the museum )

i will be playing with fredx181s debiandog-live

trying to make
a minimal core
that can be added to with sfs files

not changing anything
his system is perfect
just using it to create a version of debiandog

wanderer

this also seems to solve the problem of the package manager

just use apt

wanderer

hi all

so now we can say that the puppy has grown up and become a dog

wanderer

wanderer wrote: ↑Mon May 20, 2024 3:24 pm

trying to make
a minimal core
that can be added to with sfs files

and why sfs files? what if sfs files were no longer the best way to do what puppy/dog has been using sfs's to acomplish anymore?

In all this discussion about what is and what is not "puppy", I have been trying to identify the functionality that attracted me to puppy years back. For me, it is rollback. The ability to easily revert to a previous configuration. I see immutable operating systems being developed? Is this close to what set puppy apart years back?

I second Dimkrs take "thin layers".

Perhaps others can share what functionality they have found most useful with Puppy.
Examine what puppy does before one decides how to best implement?

wanderer wrote: ↑Mon May 20, 2024 3:24 pm

trying to make
a minimal core
that can be added to with sfs files

???????
This already exists in the Dog House section of the forum. Did you not bother to look at it?

hi williwaw

in my opinion sfs files linked to a core are the way to go

i have played with sfs files and symlinks for a long time

you can symlink an sfs file to a root ramdrive
then when you want to remove it
delete the symlink
when you want to remount it
make a new symlink
ad infinitum

no need for a layered filesystem
though you can combine it with a layered filesystem
as i will do with debiandog ( thank you fredx181 )

sfs files are easy to open and close
and easy to move around
and a standard system understood by all
pretty much a perfect module

that way you can make the core very small so that its easily maintained
and just add and remove things as desired

very flexible system

wanderer

thanks rcrsn51

no i did not know
i will look
hopefully all this stuff is already done

thanks very much

wanderer

hi rcrsn51

do you know the name of the thread
i cant seem to find it

wanderer

@wanderer It's the Starter-Kit : viewforum.php?f=206

thank you so much fredx181 and rcrsn51

you made my day

reading it now

wanderer

wanderer wrote: ↑Mon May 20, 2024 4:59 pm

are the way to go

the way to go to do what? manage packages? define puppy?

wanderer wrote:

in my opinion sfs files linked to a core are the way to go

i have played with sfs files and symlinks for a long time

you can symlink an sfs file to a root ramdrive
...

no need for a layered filesystem
though you can combine it with a layered filesystem
as i will do with debiandog

I don't understand either, what exactly you do then ? Did you test on debiandog ? And what's the purpose exactly ?

the way to go to build

a small full featured flexibly deployed easily modified distro
like puppy

lets call it a puppy-dog

you know what everyone in puppy world has been using all these years

take a look at debiandog
and tell me
that you can tell if it was built by woof-ce or mklive

wanderer

hi fredx181

symlinks to sfs files
work just like a layered filesystem
just without the cpu overhead and white out files

and you can use both symlinks and layered filesystems together
so no need to change a system that is already set up for layered filesystems

anyway having a core with symlinked extensions
just makes everything easier to build and maintain

wanderer

Ok, but not an answer how you do exactly and if you tested on debiandog.
Sorry, but I think that you talk "easier than done", better come up with a real example that works.

tinycore is one example

of a core with symlinked extensions

but i was playing with this system in puppy long before i found tinycore

another neat trick is
that you can unsquash a sfs file on a hard drive
symlink it to the core
run it as though it was squashed
modify it while its running
then squash it up again

so in this way you can dev the squashfile
on the fly so to speak

hope that was clear

wanderer

wanderer

please take a step back. you seem to be defining what puppy should be by how it is done,
not what it does.

probably a good way to see it in action is to look at tinycore/corepup and they also have a dcore which is based on debian

my old rampup that i started with i have somewhere but i would have to search for it

wiak one time found it on the old forum

there is really not much to it
its just the nature of sfs files ( and uncompressed folders ) and symlinks

wanderer

Ok, you may have got some nice method. I'll wait till you tested that and explain more with details about what you did on a real live system to make it work, what you wrote seems just theory to me now
And comparing with TinyCore is dubious IMO.