Puppy Linux Discussion Forum

im not tying to define puppy
we already have a ton of working puppies

im just talking about the direction i am going
and what i think we should consider down the road

i use upup32 - a woof-ce build
now i use debiandog - a mklive build
and i use corepup/tinycore/dcore - a core-sfs-symlinked system

they all behave like puppy to me

personally right now
i think we should all help fredx181 develop his debiandog
it seems like the best puppy-like distro to me

but who am i
im just a caveman
my primitive brain can't grasp such concepts

wanderer

It always seems to me like all the 'future of Puppy' threads miss at least one of
1. A detailed but clear vision - what Puppy should be like, what current features can be retired and what new things should be worked on (usually it's unclear or super general and vague - 'modular', 'light' ...)
2. Consensus about this vision or at least the majority of it (the discussion becomes 'what is Puppy' debate or a 'how KL differs from Puppy' monologue)
3. The resources to implement this vision: enough skilled people with enough time and willingness (the vision is not grounded in technical details because the one of the vision is asking skilled volunteers to implement it, and those with the skill are busy 'investing' their talent on their own pet project)

hi dimkr

it seems to me you are one of the ones best placed to address these questions
after all you do the work

im sure everyone would like to know what you think the answers should be

wanderer

hi all

here is my answer to dimkrs 3 questions

i think that what attracts people to our distro is

1. small size
the one i use is 400 megs

2. full function
has all the basic apps

3. flexible deployment
can be set up in a myriad of ways

4. easy modifiablity
things can be added or removed by many means
rebuilding sfs files etc

5. easy build system
a new unique version can be made easily by anyone

6. support
fredx181 and others are actively involved
it is based on debian which gives it the best overall and long term support

debiandog meets all these criteria right now
we should all just get involved helping fredx181 continue to develop it

wanderer

wanderer wrote: ↑Tue May 21, 2024 9:04 am

after all you do the work

This was never true, and now that I left the woof-CE organization, I don't have the permissions to touch woof-CE: I can only open pull requests and hope that somebody merges them. And I have no control of other people's decisions whether or not to make contributions of their own.

wanderer wrote: ↑Tue May 21, 2024 9:04 am

im sure everyone would like to know what you think the answers should be

viewtopic.php?p=120400#p120400 and https://github.com/vanilla-dpup/woof-CE ... woof-CE.md summarize my vision and my (probably unpopular) opinions.

wanderer wrote: ↑Tue May 21, 2024 11:18 am

1. small size
[...]
2. full function

If you want good hardware support (including WiFi 6, Bluetooth, AMD GPUs, Vulkan drivers and VA-API) there's no way you can fit that in 400 MB, unless this is a super barebones distro with very little features and narrow hardware support. The recent Puppy releases that fit in 400 MB or less don't have Bluetooth audio support, don't support GPU-accelerated video decoding (so fall back to slow CPU decoding), don't have emoji fonts and have a browser based on a Firefox release from 2016 (!!!).

You can't have a full-featured distro that's also small. Choose one or zero of these requirements.

hi dimkr

could we not solve the small size vs full feature problem

by having the initial iso small

and having add ons to give you all the functions you may want eventually

wanderer

hi dimkr

read your presentation

sounds great to me

a very big concern to me is the load on the primary developer
and in turn the ones that follow

but sticking to debian and devuan

and having a reproducible build system

i think would solve this issue

wanderer

hi dimkr

i also think that having an easy build system is essential

that has always been a major selling point both for users and developers

build and/or remaster

to attract as many developers as we can
we want to make the entry level for potential new developers a low as possible

fredx181s build system is very user friendly

and it could be placed on github for development

and downloaded and run by anyone to produce a new iso

edit
woof-ce is obsolete
and is not a viable build system for our distro

wanderer

wanderer wrote: ↑Tue May 21, 2024 11:18 am

hi all

here is my answer to dimkrs 3 questions

i think that what attracts people to our distro is

1. small size
the one i use is 400 megs

2. full function
has all the basic apps

3. flexible deployment
can be set up in a myriad of ways

4. easy modifiablity
things can be added or removed by many means
rebuilding sfs files etc

5. easy build system
a new unique version can be made easily by anyone

6. support
fredx181 and others are actively involved
it is based on debian which gives it the best overall and long term support

debiandog meets all these criteria right now
we should all just get involved helping fredx181 continue to develop it

wanderer

1. Impossible on today's standard. multimedia players, browsers for web modern standards, application frameworks consumes huge disk space. Moving to the filesize to 800MB to 1GB is needed.

5. The build system must be desktop environment agnostic. woof-CE was tightly bound on JWM+Rox-Filer

@dimkr :-

Reading your musings at Github has kinda left me "hanging in the wind" a bit!

Whilst I agree with some of your proposed - and already implemented - ideas, it seems to me that the general idea is for the future of Puppy to be based around Debian, yes? Not that this is a bad thing in itself, but this insistence on maintaining maximum compatibility with the parent distro inevitably means returning to "apt-get" and the use of Synaptic for everything.....which were two of the major reasons for my moving to Puppy in the first place. To get AWAY from them..!

I believe that it's also going to mean that many of the uniquely Puppy methods of implementing software will cease to work, since Puppy will henceforth be set-up to function exactly - and ONLY - like a 'mini-Debian' instead. Is this also going to mean that installing Debian-specific packages will be the ONLY available route going forward?

(I accept that apt is a mature, and well-established, highly thought-of package-management system, but I never liked Synaptic when I first moved to Linux more than a decade ago. I still don't like it. I don't think anything will change my mind about that.)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I still think this route is eventually going to turn Puppy into simply a 'clone' of every other distro out there. May I ask you a question? Is it your personal view that the RedHat "way of doing things", where everybody standardises on one, and ONLY one method of implementing functionality - a la Windows! - is the best long-term route for Linux (and by extension, Puppy itself) to take? (I can't help feeling that, this being the case, it's also going to make the "bad actor's" job much easier, since one single exploit will automatically affect every distro extant, in one fell swoop).

Just curious, really, since you have more of a background in this stuff than pretty well all the rest of us put together...and you seem to understand the nuances & implications of NOT changing better than anyone.

Mike.

hi all

i must once again strongly advocate

for us using fredx181s mklive script as our build system

it is without peer

it could be put on github for development

and then downloaded and ran by anyone to make a new distro

in my opinion woof-ce is obsolete
it can only be used by a select few
is very awkward to use ( multiple scripts )
and apparently is bloated ( slackware ) and tied to jwm and rox

wanderer

mikewalsh wrote: ↑Tue May 21, 2024 2:30 pm

inevitably means returning to "apt-get" and the use of Synaptic for everything.....

Wrong, .pet packages work, SFSs work and even Flatpak works.

mikewalsh wrote: ↑Tue May 21, 2024 2:30 pm

I believe that it's also going to mean that many of the uniquely Puppy methods of implementing software will cease to work

Wrong, you'd be surprised to see how many old Puppy packages still work despite the big underlying changes. gtkdialog is still there, and there are compatibility shims to compensate for ROX-Filer's absence.

My goal is to build something with core features of Puppy and good backward compatibility (imperfect but good) but at the same time make it more compatible with Debian (so more things that work on Debian 'just work') and less weird in the family of Linux distros (modern multimedia/graphics/drivers stack).

Does the switch from plain ALSA in BookwormPup64 make it less of a 'Puppy' release or it still feels like Puppy? It's an under-the-hood change (applications that use plain ALSA are routed to PipeWire transparently through pipewire-alsa), and Puppy's tradition of sticking to plain ALSA is nothing but a source of issues (multiple audio streams, playback issues, no Bluetooth support, etc'). I see nothing wrong with changes like this, which only reduce the number of problems unique to Puppy due to (sometimes arbitrary) architecture decisions made years ago.

hi all

i must also once again address the issue of iso size vs available functions

the solution to this problem

is to make a small iso

and to symlink sfs files to it

tinycore does this

and has 100s of symlinked sfs files if needed

thus our distro will have the basics in the iso
and as many additional functions as the usr is interested in

this will have the advantages of making the iso easier to build and maintain ( small and simple )

and placing the responsibility of making the additions on whoever wishes to develop them

it will also allow the usr to customize his distro without rebuilding or remastering it

wanderer

A symlink can be used to cut size by half when you have two identical files. But I don't see how symlinks can (loslessly) shrink a 1 GB sized Puppy (= unique files with total size of 1 GB) to 400 MB.

And if your 400 MB distro doesn't have drivers and firmware to connect to the internet, you can't download must-have addons to make this barebones distro usable.

hi dimkr

the iso will have all that is needed to get set up
who knows what its eventual size will need to be

however i doubt that just to get on the internet
and run a shell and sfs downloader
will require 1 GB of applications

large applications
desktops
extra drivers
extra firmware
browsers
media players
development tools
office suites
extra fonts icons documentation etc

can all be made into sfs files
and loaded as desired

since most people will not need the full complement of functions
they will only load what they want

either way
both the iso
and the iso and the chosen added sfs files
will still be smaller ( and more manageable )
then automatically putting everything in the iso

the only real difference between this system
and the one we use now
is that symlinks don't require the overhead of a layered filesystem
and so more can be added if needed

wanderer

I see things a bit like this, trying to summarize:
@dimkr says something like: let's be prepared now already for what's going on in the future with Linux development.
@others may say: is it really needed ?, I like my old Puppy, it's small and does everything I want e.g. I'm still running TahrPup and it's fine, I don't need all the new stuff. Or: I like to run the newest Puppy developed, but it should contain the same software as I'm used to with TahrPup.

@dimkr may say, OK, say you buy a new computer within the next years, let's see if "the old stuff" still runs as you expect? Probably not !
@others may say: I'm from the "old school", and don't like the new stuff, period !

Perhaps best not to go into extreme opinions, seek for the golden middle, not polarize, compromise where possible ?

Just some thoughts

yes fredx181

lets just use your system

its already developed

and it can be developed further
to deal with things as they come along in the future

maybe even with symlinked sfs files

you could put your ideas into it dimkr
it would save you a lot of work

wanderer

wanderer wrote: ↑Tue May 21, 2024 5:02 pm

yes fredx181

lets just use your system

its already developed

and it can be developed further
to deal with things as they come along in the future

you could put your ideas into it dimkr
it would save you a lot of work

wanderer

Don't know why you keep saying things like that, this thread is about "Whats up in Puppy World" and as far as I'm concerned, you made your point more than enough by mentioning my name and debiandog many many times.
Use my build system, OK, enjoy, test, report bugs and/or shortcomings or .... in the appropriate topic(s), but stop pushing it here as possibly being some sort of replacement for Puppy development, please.
Really, too much "just talk" from you about it here, help if you want or can (or ask for help) is ok of course.

Re: load SFS's using symlinks, your comparing with TinyCore makes not much sense, (old) TinyCore's package management is based on that, whole different story with Puppy or DebianDog.

mikewalsh wrote: ↑Tue May 21, 2024 2:30 pm

- is the best long-term route for Linux (and by extension, Puppy itself) to take? (I can't help feeling that, this being the case, it's also going to make the "bad actor's" job much easier, since one single exploit will automatically affect every distro extant, in one fell swoop).

Mike, I cant speak for linux as a whole, but only to puppy. two thoughts......

1. any benifits of "security by obscurity" may be obsolete

2. I believe a "thin layer" design is well suited to an OS whos user group is aging and with declining numbers of devs participating

dimkr wrote: ↑Tue May 21, 2024 3:43 pm

mikewalsh wrote: ↑Tue May 21, 2024 2:30 pm

inevitably means returning to "apt-get" and the use of Synaptic for everything.....

Wrong, .pet packages work, SFSs work and even Flatpak works.

mikewalsh wrote: ↑Tue May 21, 2024 2:30 pm

I believe that it's also going to mean that many of the uniquely Puppy methods of implementing software will cease to work

Wrong, you'd be surprised to see how many old Puppy packages still work despite the big underlying changes. gtkdialog is still there, and there are compatibility shims to compensate for ROX-Filer's absence.

.....and AppImages work, too.....AND every 'portable' I've tried so far. Even the AppImage-based WINE-portables work, flawlessly. I'm trying out VanillaDPup 10.0.53 ATM. Posting right now from Opera-portable.

Everything just "works". I'm impressed.

(I'll have a go at pairing my VicTsing "MX Master 'clone'" mouse later this evening. I'm curious to see if it's as easy as pairing BlueTooth is under ChromeOS-Flex. That one is SO simple it's ridiculous.)

Mike.

mikewalsh wrote: ↑Tue May 21, 2024 6:14 pm

I'm trying out VanillaDPup 10.0.53 ATM.

But I was talking about 11.0.x, which is still in early development

10.0.x is very similar to BookwormPup64 because the latter is based on it.

@dimkr :-

Nice one! Bluetooth pairing works perfectly. Connection works as easily as it does on ChromeOS-Flex.

After making sure it WAS connected under BlueTooth - by the simple expedient of removing the USB dongle, so I knew it wasn't connected on 2.4 GHz - I'm using it now.

Excellent work, young sir..! And very much appreciated. (BTW, VanillaDPup is now fully-stocked with my usual complement of portables, and is - as far as I'm concerned - fully-functional).

Mike.

400mb is not achievable in VanillaDpup. Is 700mb (CD size) possible? I experimented with 9.x (which may have a short future).

With Bookwormpup64, I made a CD version via higher compression. I've tried it with VanillaDpup-9.3.40 & come up with 698mb,
using -b 1M -comp xz -Xdict-size 75% . Will fit on a CD. Would need at least 2Gb ram & a reasonable cpu to ensure loading.
I could release it if dimkr approves.

It is also possible to make 10.x smaller by removing some iwlwifi firmware files & some obscure locales. But then it's not the same.

The 'retro' variant is currently at 314 MB, but you pay a big price for this small size: decompression is CPU-intensive, hardware support is limited, online videos drain the battery unless you add VA-API drivers, websites look funny or even broken due to limited font selection ... Anyone who uses the 'retro' flavor and claims that everything works the same but performance is somehow better is just human

Small size is definitely attractive, anyone would naively prefer the same thing at 1/2 the size, if the tin doesn't say that the smaller option has a long list of cons.

hi all

to belabor the point

you will never get everything you want into the primary iso
no matter what compression you use

just break things up

the base iso
which will be small (and thus attractive )

and to which you can add whatever you want ( as sfs files or whatever )

otherwise our distro will just look like every other big blob distro

i know this will work
because i have seen it work

wanderer

also i would like to remind everyone
what the purpose of this thread is

the title is not what is up with puppy
its what is up in puppy world

this thread is to include all systems on the puppy forum and beyond

if we do not consider all ideas and systems
we will stagnate
which we are doing

wanderer

one of the primary reasons our distro is stagnating
is that it is tied to a build system
that is not usable for the majority of our members

in my opinion woof-ce is obsolete
it can only be used by a select few
is very awkward to use ( multiple scripts )
and apparently is bloated ( slackware ) and tied to jwm and rox

an easy build system
is an essential component of our distro
it makes it stand out
and encourages development

from the beginning
the ability to build and/or remaster the iso
has always been a major selling point both for users and developers

to attract as many developers as we can
we want to make the entry level for potential new developers a low as possible

the build system i suggest we use

consists of a single script to build the iso
and 1 template for each specific build

i know this will work
because i have seen it work

the build script and templates could be put on github for development

and then downloaded and ran by anyone to make a new distro

wanderer

If you are genuinely concerned about Puppy not stagnating, you should remove the most stagnant project on the forum - Dog Incubator.

i agree rcrsn51

dog incubator should be deleted
it does not meet the requirements of a legitimate project

i have asked rockedge to delete it

wanderer

wanderer wrote: ↑Wed May 22, 2024 1:12 pm

one of the primary reasons our distro is stagnating
is that it is tied to a build system
that is not usable for the majority of our members

The primary reason is lack of skilled and motivated developers (see https://github.com/puppylinux-woof-CE/w ... ntributors and https://github.com/puppylinux-woof-CE/w ... ts/testing). All other explanations are not backed by any evidence as far as I'm aware, and they're part of "why Puppy should stop doing x and do y instead" arguments.

To use woof-CE, one needs to run only 4 scripts and edit ~5 configuration files. Everything is wrapped nicely with browser-based UIs if you don't want to install anything locally, and you don't even need to know how to use git to modify woof-CE. If you don't want to set up a GitHub account you can fork woof-CE to a repo in some other hosting provider like GitLab or Codeberg. If you don't want to use any git hosting provider and don't want to clone the repo, you can download a tarball and run woof-CE locally.

It's not that people fail to run woof-CE because it's "unusable" (fact: woof-CE has automated periodic runs and all of them pass), people just don't try.

If you have a vision and you can accomplish it, show us a working proof-of-concept and don't discourage potential contributors by spreading FUD around other projects.