Puppy Linux Discussion Forum

fredx181 wrote: ↑Mon Aug 05, 2024 9:43 am

wanderer wrote: ↑Mon Aug 05, 2024 9:06 am

thanks fredx181

thats the answer i was looking for

"Just one main module (and kernel module and perhaps firmware module ) is the best IMO,
as the package manager then "knows" exactly about what packages (and which versions) are inside."

wanderer

To get back about Slax, question could be "How come that Slax works ok with it's 5 separate modules ?"
Well, my guess is that an average user can break Slax's package management easily when modifying that modular setup, by exchanging modules and/or add extra modules.
(so, in other words, the multi-module setup looks nicer than it is !)
Fine of course if you use it as it's prepared, and use save file or folder for the changes.

edit: with very early versions of Slax (based on slackware) it was different, but nowadays Slax is based on Debian and dpkg/apt is very strict.

Just an FYI...you can also get Slax based on Slackware, AGAIN!!! In addition to the Debian version.
Slax, both variants as much as I am aware, uses an internal packaging system, you can create "sb"s
(Slax bundles) with tools included in the ISO. I used to do that many years ago, and the directory
structure of Slax allows you to include all your sbs at boot time, OR you can optionally load them
when wanted by placing them in /slax/opt directory (or is it named slax/optional...can't recall right
off the top of my head). Not sure if there is a limit to number of slax bundles you can load, probably
not, only to the limits of your RAM.
Wiz

hi wiz57

i will continue to play with slax debian 64
its a very interesting and polished system
and i think the puppy community should take a look at it
and see if there is anything we can learn from it
and if it can be useful to us

in fact the more i look at slax debian 64
the more i like it
the fact that it has only 6 basic modules
and the fact that they are very well organized
makes it what i am proposing we consider adopting as an option

the only thing missing is fredx181s build script

so i am going to try to make an absolutely minimal bookworm debiandog iso
that still has the ability to run the apt package manager

this way i will be able to use fredx181s build script
which is the best build system i have ever seen
and i will be able to use the debian repositories and the apt package manager
i also like the fact that it is actually debian since i think this will give it better support long term

it will start out with 1 minimized module ( command line only )
and further modularity will be controlled by the package manager and fredx181s build script

one idea is that the apps are downloaded by apt
and built into a module by a script
that way they will always be automatically compatible with the entire system

wanderer

hi greengeek

did you say you had something that compared to slax debian 64

wanderer

i agree with dimkr

that reducing cpu and ram use is very important ( maybe the most important factor )
since on most old computers this is the limiting factor

if you have a newer computer that has plenty of ram and cpu it doesnt matter either way and its just gravy

wanderer

wanderer wrote: ↑Wed Aug 07, 2024 11:06 am

hi greengeek

did you say you had something that compared to slax debian 64

wanderer

No - I have got the download link for Slax but have gone no further with it yet.

I currently use the various Fossa64 9.5 cutdown puppies from Ozsouth.

He builds them on top of a somewhat modularized puppy from PhilB & Peebee I believe.

He is doing great work with building different fdrvs for firmware. Possibly the area of firmware is where I see the greatest option for making things modular.

He also uses adrv for browser so that is another easy module (although I would rather see bdrv for that)

Then there is ydrv for "Your" personalizations. (Although I would rather see the personalization .drv at top of the module list rather than under adrv)

Anyway these cut down Fossa's are the closest I have seen to very useful modularity. Love them.

hi greengeek

thanks for your reply

if you have the time
please download and play with slax debian64

i think you will be very impressed

as i said before it is exactly what i have been talking about

it is complete and polished so no more needs to be done
but i am going tweak it and make it into our minimal modular option

the solution to fredx181 dimkrs wiaks and rockedges concerns about the downsides of modularity
can be solved by having the package manager download the app
and then package it into an sfs file with a script
so that everything is automatically compatible

but i have only just begun to explore all of the utilities included
and that function may already be available

i am very interested in your opinion and input
so please post on this thread

wanderer

wanderer wrote: ↑Wed Aug 07, 2024 8:43 pm

the solution to fredx181 dimkrs wiaks and rockedges concerns about the downsides of modularity
can be solved by having the package manager download the app
and then package it into an sfs file with a script
so that everything is automatically compatible

Yes that does work and is indeed pretty much what tinycore linux does albeit using symlinking load rather than layers. In fact firstribit includes tinycore linux as an example distro (probably the most complicated of those features to drive via FirstRib initrd). The result of that is using tinycore tcz (squashed filesystems) as normal sfs files in a FirstRib overlay boot. So yes, each time someone wanted to install a new app via say debian apt you make an sfs out of the save persistence result and so on and so forth - we've done this kind of thing in FR/KL; geo_c in particular uses upper_changes rollbacks all the time, which is a more general case example of doing the same whilst not breaking the package manager database.

Each layer mounted sfs does consume some resources, so that could be a concern to some people, but really if they are concerned about that they would be better just using a traditional full install in practice.

It is particularly easy to do the above if using FirstRib-based/KL distros because with FR you don't even need to compress the result of apt download to current upper_changes. You can simply rename the new loaded app upper_changes as NNupper_changes, where NN is a unique (highest in order) 2-digit number. You can turn that into an sfs if you want to, but the only advantage of doing so would be to save disk storage space (and making sfs files is a time-consuming operation). Each time such a 'rollback' layer filesystem is made, a new and empty upper_changes save persistence folder is automatically used. That has a significant advantage, by the way, in that save2flash > snapmergepuppy save on demand works much faster thereafter, since will then be working with new empty upper_changes and not so much to check/modify via rsync involved therefore. My son recently moving to FR multi-instance use of his ridiculously large 87GB upper_changes KLV_Sway installation noted the huge speed increase on saving; in multi-instance the old upper_changes is automatically turned into a rollback (which is actually just an NN-prefixed symlink back to the original upper_changes, which also shows how easy to manipulate add-on modules like that is for FR-based distros since no sfs is actually required though can be optionally used).

hi wiak

im only talking about a small number of modules
just the base components divided logically
things most people want to customize
desktop etc
slax debian64 does it with 5 modules
6 if you include the browser
then they add what you download with the package manager in bigger pieces

tinycore did it with symlinks which have little overhead
so you can have a large number of extensions
and i actually prefer the tinycore symlinks to a layered filesystem
but the problem is maintaining and polishing the extensions
and setting them up which can be a total pain
they also lack an up to date debian version
so you dont have access to the debian repositories

the real problem however is that even though there has been a lot of discussion about it
no one was actually willing to do it
so i had to find something that was already built
luckily i was able to find slax debian64
which checks all the boxes
and is very well done

so thats what im going with

since it is complete and polished
nothing else is really needed for me to do but learn and tweak the system
which i am able to do without help

this will give the community ( and me ) a minimal modular option to play with
that actually exists and works ( and is not just vaporware )

wanderer

With all this talk about Slax I decided to give it a spin. So I downloaded the Debian based 64 bit version, and put it on my Ventoy USB stick. Next I booted it up, and it booted with no problems and quite quickly. That's where the compliments begin. And end.

As with any Linux distro first thing I do is to look at what it comes with. Oh, very little. So how do I install additional software? Hmm, not sure, better have a look at the clear, concise, easy to follow instructions. Ah, there aren't any. I guess they've left them on their website and haven't bothered to put them in the actual distro. Better have a look at the website then. Oh, that's going to be awkward, the damn thing hasn't recognised my wifi card. In the few years I've been using Linux I've only ever had that happen on one previous occasion, so it's not that I've got a particularly troublesome wifi chip. Certainly never had that happen with any Puppy.

Next thing to do is shut it down, delete it and forget about it. Later on I did have another look at the Slax website, mainly to see if I'd missed anything, appears not. Looks like it requires quite a bit of command line use.

So to sum up, not exactly what I would call "beginner friendly". Based on my brief experience it's unlikely that I will go anywhere near Slax ever again.

Seriously thought what I propose is to stop putting effort in rediscovering the flat tire (that may indeed take effort) and build something relevant today.
There is already AntiX/MXLinux linux (for the most solid debian frugal installs out there), Tinycore Linux (for the most modular system if anyone wants this), Porteus for a small and modular system for removables, EasyOS for a puppy-with-containers system and FatDog for a modern infrastructure puppy with the yesteryears look and feel.

Distro x that is basically distro y but with a "frugal installation" feature, preinstalled Xfce and a different name/logo is basically ... x with Xfce plus "frugal installation", no? Features are not emergent properties that just "happen" when a build system spits something, somebody needs to develop features for them to exist. Now you're not only denying the need for actual distro development, but also denying the need for software development in general.

Distros vary in many ways, not just different DEs and frugal/not. But distros with Xfce (especially those derived from Debian) are not THAT different...

Oh well, what to do.

Been working on an early slimmish KLU_NobleNumbat release; well, not XFCE... sigh... rather, Wayland-pipewire-based KDE Plasma frontend. Using zstd 19 compression on the internal sfs files results in target iso size of maybe a wee bit less than 1GB with FR initrd frugal install and so on.

Anyway, I read the crying posts and have to think what my 'moral' best course of action is. Greatest good for the greatest(?) number, I suppose. So I guess forum members can use NoblePup64 of around same size albeit not I think a nice KDE Plasma DE, something else no doubt wonderful, but this is Puppy World afterall so maybe it is some unique DE and not a repainted flat tyre? Or can just full install Kubuntu latest, with whatever DE that provides in its non-frugal 3.5GB iso. I don't know. Don't want to be accused of publishing any 'flat tyre' to threaten future of any of these so-unique wee Pups or V Dpups. Best to not use the resources upstream provides (easier to produce a fully working reliable system being a sin apparently despite Puppy fans, most of them, not having a clue how to get anything workable out of old woof-CE), but instead to be required to bolt it all together with handmade nuts and bolts since result is apparently Puppy-superior in being so very different and non-standard in its final assembly (despite relying on getting exact same under-the-hood main application packages to work (if lucky...) - all resourced from upstream flat tyre app land, but oh well... really let's not offend the fearful and I will keep this one to myself to avoid further upsetting old guys and the associated uproar.

Most everything works - actually works... and wifi connected first time, but I will stop there and not bother downloading a browser or wf-recorder, grim,slurp,grimshot or whatever (that I did include in my old KLV_Swayland release). Just a photo of my plaything flat tyre attached in all its early 1GB size glory. Just use NoblePup and rest easy (or use Easy...) or simply firstribit KDE Neon, which is, to be honest, rather nice (whether firstribbed or not).

Just don't say I couldn't make a small KLU_NobleNumbat (even if choosing zstd compression and KDE Plasma big DE frontend for the flat tyres, or whatever)... Can't remember what solid tyres NoblePup64 uses instead.

Sorry Guys, to those who might have used this KLU, but you will just have to argue with the moaners or go along with what they provide you (maybe some remastered Puppy with xfce stuck on it more uniquely).

I'm told I contribute too much anyway. More than Narnia and the Lord of the Rings. High moral texts in themselves of course, but I suspect I was not actually being praised for my overall output.

@wiak too bad I guess, I would have tried and used it. I build lots of stuff, most of which does not even get a mention by me because it's never going to be polished and published or even in some cases debugged enough to work.

Really like the NoblePup64-FRI (FirstRibIt'ed) I am running right now. Blew up in size because all kinds of stuff runs great on it and I can use @geo_c's methods of numbered upper_changes for rollbacks when I inevitably break the system completely. Has APT going pretty well.

But suddenly KLV-Boxer is there again.....Void Linux based, and has the most of the KLV-Airedale features but runs a JWM-Rox pin-board desktop environment with Cortile installed by default. Tiling away, and not going crazy on JWM customization I can stack and tile. Using a a huge high frequency full real time kernel 6.6.0-rt15 the system is fast and very responsive. Using 186 M of RAM right after system start according the htop.

I'm using it on a QEMU virtual machine using a frugal installed instance1 of a wd_multi set up of F96-CE_4

I also see Vanilla dpup as a solid foundation system for assembling a good, purpose specific setup.

wiak wrote: ↑Thu Aug 08, 2024 12:41 pm

Best to not use the resources upstream provides

If you take a distro, add some prebuilt binaries and your kernel, the thing you're building is no longer the upstream distro. It has some binaries the package manager can't update or verify. The package manager can't update the kernel (= the most security-sensitive part) and you probably don't have Secure Boot like the upstream distro. If you really believe that using "upstream components" is the way, then you shouldn't build distros at all. What's more "upstream" then the upstream distro itself?

@dimkr I have it so the entire KLV is built by the package manager XBPS.
All modifications and any binaries I add are managed by XBPS from the build script onward.

Kernels I have a choice...and this just a size decision, use a Void Linux kernel or use a huge Puppy kernel. But I am more into Fuzzy logic and details like whether or not something is pure doesn't matter much to me.

I made this KLV-Boxer to experiment in that sense, can I go back and use xbps-remove or xbps-install to update these custom packages? Well yes I can it turns out. No mods or customization done manually, all performed by creating .xbps packages and meeting the requirements so XBPS can install them. Almost as good as just using upstream. And if I was going to do that I'd just use Void Linux. Same with any Puppy Linux really....if I didn't need or want the advantages that Puppy provides specifically I'd be using some "real" Linux distro and be part of the big machine.

rockedge wrote: ↑Thu Aug 08, 2024 3:16 pm

@dimkr I have it so the entire KLV is built by the package manager XBPS.
All modifications and any binaries I add are managed by XBPS from the build script onward.

And the kernel is the Void kernel? The package manager updates it in the ESP, etc'?

@dimkr When I instruct the build script recipe to use the stock Void Linux kernel yes, the kernel gets it's updates from upstream Void Linux repo's

This works really well when using a Pseudo Full Install to the changes written directly to the uncompressed rootfs and persistence save folders merged together, then the kernel updates and old kernel purges work exactly like a stock Void Linux would.

At this time for size considerations I made KLV-Boxer using a self-made (Kernel-Kit) full RT huge kernel 6.6.0-rt15. This of course does not update at all in this form.

Of course my home-based KLU_NobleNumbat doesn't start at KDE_Plasma DE. Actually it starts as core commandline KLV_NobleNumbat only (consider that the smallest version) so depends what desktop choice what happens thereafter. Mind you I can't bring myself to bother using X in anything new at this stage: has to be Wayland/Pipewire or seems like wasted future effort. Certainly KLV_NobleNumbat is pure Ubuntu (unpolluted with foreign or unique binaries) aside from very slim and the layering boot component FR initrd and a hugekernel/modules/firmware if I go that route, which I did in this instance. I don't know why, but I reached the conclusion long long ago that there was nothing clever about re-making as somehow 'unique' what is already provided by a skilled upstream development team.

I can understand some seeing the outcome of all this 'problematic' since it does make one wonder why spend so much effort via the likes of woof-CE and its skeleton of mixed binary parts that are not themselves official in terms of the upstream package manager the distro chooses to use. After all these years of insulting those who used official package managers, suddenly Puppy relies on dpkg/apt provided by debootstrap initial build - really just like DebianDog, which did all that back in early 2013. Okay so the JWM or IceWM plus Rox preference designs of Saintless (Tony) were lost in time with his departure so DebianDog aim of looking almost exactly like Puppy Linux vanished with him. But is Puppy turning into a DebianDog lookalike; have the tables turned that far. But DebianDog is surely superior since it is pretty much trully Debian apt/dpkg compatible providing all the advantages that gives it, and what disadvantages compared to Puppy??! aside from somehow being a flat tyre to Puppy's fully inflated (what does that even mean?).

I was reading something else that caught my eye earlier today:

CrunchBang was a Debian GNU/Linux based distribution offering a great blend of speed, style and substance. Using the nimble Openbox window manager, it was highly customisable and provided a modern, full-featured GNU/Linux system without sacrificing performance.

Development of CrunchBang has ended, but it inspired the creation of some excellent spin-off projects by community members.

CrunchBang++
BunsenLabs
...
Arguably, CrunchBang wasn't a Linux distro, it was a community. Out of respect for the community the project's forums continue to be hosted on this site.
...
“I've used #!++ as my daily driver for coding for about a year now. It has never failed me as far as stability, and its small footprint makes it an absolute breeze to use on older hardware. The community is super-friendly, and is always welcome to discussions or questions...”

Distrowatch user

Actually I've tried all these distros and never quite liked them enough (not even AntiX excited me despite some excellent utilities included with it). Regarding KLV_Boxer; well, truth is, if someone examined the recent Puppy start menu, then they could include the exact same apps/utilities and start menu in KLV_Boxer (and Rox pinboard/panel layout). A user wouldn't care what init system was invisibly controlling the whole exact lookalike underneath unless they wanted to add some other system users, which would work perfectly in KLV_Boxer (being a full/standard/Void Linux multi-user system) and pretty much not at all in Puppy. The non-technical user would not know for a second they were not actually using Puppy Linux but rather KLV_Boxer - despite the latter being somehow a flat tyre...

But back to the above regarding Crunchbang and so on - it all sounds so similar to Puppy forum and even the point and style of the deceased original CrunchBang distro makes the likes of Puppy not sound so fascinatingly 'unique' - a somehow important (yet imagined) characteristic some keep boasting about despite failing to be able to answer my replying-to-insults question: why being put together in a unique non-standard way makes anything better or less of a 'flat tyre'. So maybe we should abandon ship if only too many flat tyred flowers inhabit these otherwise tired and dead shores and adopt some successor to CrunchBang, such as BunsenLabs, so the other thing I read is that labwc/Wayland repo is now available on there (maybe Vanilla Dpup could use that???), but guess who made and looks after that github stored repo for Bunsenlabs and indeed is now very much a BunsenLabs man (how could he) ??????????!!!

Oh no, I hope that jumping ship to BunsenLabs isn't my fault too - burn in Hell over the Bunsen I suppose. I should check it out. We all should. Sorry rockedge - would really not be your fault, but look at the expertise that is assembling over there and what if dimkr starts using that BunsenLabs labwc/Wayland repo as major part of how Vanilla Dpup operates and manages to somehow convince some rare visitor to woof-CE to push that into there too???! If Puppy morphed into BunsenLabs would anyone then notice??? We surely can't have two BunsenLab forums or almost identical distros can we?

dimkr wrote: ↑Thu Aug 08, 2024 3:19 pm

rockedge wrote: ↑Thu Aug 08, 2024 3:16 pm

@dimkr I have it so the entire KLV is built by the package manager XBPS.
All modifications and any binaries I add are managed by XBPS from the build script onward.

And the kernel is the Void kernel? The package manager updates it in the ESP, etc'?

But surely you know you can pin kernels - why do they always need upgraded, and a quick FR rebuild is enough when you do want latest (if security worries are your concern); overall the upgrading of the root filesystem is perfecto in KLV distros. Sure, some rebuild mechanism needs employed if you want to use upstream new kernel versions - same like all frugal install distros. Some use Github Actions to rebuild, but I doubt this means much at all to most any users of any distro on this forum...

Mind you I rather like the huge kernel alternative way of updating that part of the system; easy and why hate simplicity of approach, which is what FR-based building was always intended to be about??

But yes, I sometimes consider working on an initramfs auto-rebuild on kernel/modules upgrade utility - have not bothered doing it though; Debian full install does that sort of thing of course - everything like that is so easy with full installed distros as it happens.

wiak wrote: ↑Thu Aug 08, 2024 3:44 pm

but look at the expertise that is assembling over there and what if dimkr starts using that BunsenLabs labwc/Wayland repo

There's lots of healthy and constructive collaboration going on. Guess where the labwc support in BunsenLabs comes from

This work started in 2021:

https://github.com/puppylinux-woof-CE/woof-CE/pull/2660
https://github.com/puppylinux-woof-CE/woof-CE/pull/2628
https://github.com/puppylinux-woof-CE/woof-CE/pull/2615

https://github.com/puppylinux-woof-CE/woof-CE/pull/4200
https://github.com/puppylinux-woof-CE/woof-CE/pull/3477
https://github.com/puppylinux-woof-CE/woof-CE/pull/4031

hi stevie pup

thanks for your review

slax debian64 definitely needs tweaking

it worked on all my stuff
and was easy for me to set up
so i didnt have the same experience as you

however
i like the way its laid out
and i think its a good base for our minimal modular option

like i said i would prefer the tinycore system
but at this time its not developed enough

slax debian64 gives me something to play with
and at least it stops my endless whining about someone making a minimal modular system

so i will continue to play with it
and i encourage everyone to at least take a look
and hopefully post their ideas about it on this thread

just more ideas and options for the forum

wanderer

dimkr wrote: ↑Thu Aug 08, 2024 4:05 pm

Guess where the labwc support in BunsenLabs comes from

My goodness. It must be a language problem or inability to read between the lines... Yes, I know and knew... how could he jump ship, I said, whilst asking if that meant we should all move to BunsenLabs since the Puupy Linux captain had deserted this ship to go there. I'm not sureI would call jumping overboard a case of collaboration.

wiak wrote: ↑Thu Aug 08, 2024 2:42 am

wanderer wrote: ↑Wed Aug 07, 2024 8:43 pm

the solution to fredx181 dimkrs wiaks and rockedges concerns about the downsides of modularity
can be solved by having the package manager download the app
and then package it into an sfs file with a script
so that everything is automatically compatible

Yes that does work ....
...

Ok, it can work but is there a real advantage compared to a 'single' SFS module ?
I think it's only useful that way for very advanced users, not for the average user or beginners.
So, in other words, not user friendly at all IMO, unless there's a easy way included in the system to accomplish that . Big challenge to make that foul proof (not saying it's impossible though).

hi fredx181

thanks so much for your input

the whole point is to separate the distro into a few base modules

core - with internet and apt
xorg
i would like to see a sound module
desktop
utilities - editor - file manager - xterm - image viewer - etc
browser
media player

this just makes it easier to locate and modify things
and allows you to minimize it as much as you want easily

the other applications do not need to have their own modules
and can be handled by apt in a single extension module

having apt download the apps
and then having a script make them into a module
can be made automatic
and this will allow someone who wants to
to update the base modules ( and extension modules ) efficiently

most users will never play with this structure at all
they just want something that works for them

but if you want to to modify things
you will need to know a little bit about how things work
but the next steps will be logical and straightforward

wanderer

wiak wrote: ↑Thu Aug 08, 2024 4:43 pm

My goodness. It must be a language problem or inability to read between the lines...

There's a lot I can learn and my English language skills are not as good as yours. But you can work on your ability to give *my software* some constructive criticism instead of pointing at *my* flaws.

wiak wrote: ↑Thu Aug 08, 2024 4:43 pm

I'm not sureI would call jumping overboard a case of collaboration.

Why not? He's writing good code, it's all open source and maintainable. Should I ignore this work and duplicate the effort just because you think he's some kind of traitor? It's you who says that distro developers should use whatever is available instead of writing their own.

hey pp4mnklinux

post on this thread
you cant get accused of hijacking it
its about everything

wanderer

dimkr wrote: ↑Thu Aug 08, 2024 6:11 pm

Why not? He's writing good code, it's all open source and maintainable. Should I ignore this work and duplicate the effort just because you think he's some kind of traitor? It's you who says that distro developers should use whatever is available instead of writing their own.

Who said I consider 01micko some sort of traitor? Personally, I don't think that way at all. He needed a venue to work on labwc and really the stick in the mud attitude of some traditional Puppy Linux fans ensured that Puppy was not the place for that. I would move venue in exactly the same way if that worked better for me. I havent, not because I need Puppy Linux at all, but because rockedge is also a longtime FirstRib enthusiast, pretty much from its beginning, so I support his forum via FirstRib as long as he wants to also use that.

I have nothing against 01micko; never have had. Bunsenlabs, being openbox focussed is a good venue for labwc, but of course means labwc forum activity is not here so this forum lost out on that. As Ive said, my opinion is that individual distros are not all that important longterm any more. It is the forum activity that is important and Puppy protectionism not only inevitably fails, it actually stifles development and threatens to kill this meeting place. Collaboration with Bunsenlabs may be somewhat possible, but any work not Puppy-based here was also met by insulting aggression and still is from some quarters, who show great ignorance of reality but cannot stop progress.

What I dont like about you, and not only this, is that you used often used these old Puppy fan boys in gang attack behaviour (somewhat decrepit old gangs mind you) to support your own self-centred ends despite knowing all too well that much of what these guys supported was nostalgic old technology that needed cleaned out and replaced. It served your own interests, it seems, to have them join in with you to cconstantly attack what you saw as dangerous alternatives to what you work on, but funnily enough you ended up basically ditching actual woof-CE too, because it was full of unmaintainable code crap that is actually a burden not worth struggling with. But you cant hold back others with their perfectly fine alternative approaches no matter how much you try to paint them as just clones of something else. Their success rubbishes much of what you and your flat tyre friends grumble about in practice. To a great extend you chase the tail (aside from the inevitability of using Wayland/pipewire these days) and for some time now pretend it was your idea to use overlay in preference to aufs and apt in preference to PPM, but you still have problems with a limited initrd based on adrv, bdrv, sfs-bounded old Puppy Linux modelled initrd shape and form. Keep trying.

hi all

i continue to play with slax debian64

im very pleased with this
definitely fits the bill
i will adopt this as our minimal modular option

very easy to modify
very easy to minimize
very easy to find stuff

i encourage everyone to look into it
i will write a howto of the stuff i learn

wanderer

wiak wrote: ↑Thu Aug 08, 2024 10:51 pm

you ended up basically ditching actual woof-CE too, because it was full of unmaintainable code crap that is actually a burden not worth struggling with.

This is factually wrong. I added Wayland support, overlay support, apt support, package building from source and many things to the "unmaintainable" woof-CE. PPM and many things are horrible, but it's a codebase you can work on: me being able to fork it (after I upstreamed all these things) as a single developer provides more evidence for my claim that woof-CE can be developed further, given a vision and at least one skilled developer. I forked so I can remove the stuff I don't want to maintain, like JWM-related things.

Regarding ideas - I never said I wrote overlay, apt or whatever, or was the first to use them in Puppy context. But the way my builds integrate apt has some reliability advantages over other integrations, and my save2flash is faster with fewer writes, etc'. You ignore important implementation details so you can portray others as 'cloners' of ideas you consider to be yours.

Oh, and my fork doesn't have this SFS naming limitations you bring up so often.

*while eats popcorn*

Been a while.

Privileged information to a few is that I had a family tragedy in 2021. That's the main reason I fell off the boat. I'm not sorry for that as it was out of my control.

I did digress and tried to recover but not to be, so left.

This post doesn't mean anything more than a post. You probably won't see me around too often.

I will address some things.

1. I started as a member of the labwc team in early 2022 (log into github required to see).

2. My biggest achievement there is introducing NLS support to the project at an early stage, which I believe helped promote the project.

3. Johan Malm, the creator and lead developer of labwc is also a Bunsenlabs developer.

4. I still HATE systemd!

5. I still have a slackware-current based puppy slacko that I use daily on my laptop

6. I still love slackware, and follow development daily, but it's not a good base for noobs to puppy

7. I still keep in contact with @dimkr , @jamesbond and occasionally @BarryK

@wiak some nice research there, good on you you blew my cover

Seriously though, I'm not hiding. Anyone can search what I'm up to and if it can get past the AI cancer that infects the web these days all is clear as to what I'm up to.

provides more evidence for my claim that woof-CE can be developed further, given a vision and at least one skilled developer.

Looks bleak.

Seems that as a Puppy Linux forum, the clock is winding down. Despite the best efforts, we've got water in the holds, rudder is unresponsive but we still have some engine power and the lights are on.

My sister-in-law's dog and cat boarding kennel was closed and the owner's of the property had the building torn down.....so no more kennels, we gave all of the equipment away that we could...it was all rush rush rush to develop a different retail space but here we are...the property is overgrown and totally empty except for the illegal dumping of construction waste on it. My sister-in-law and her husband moved far away.

dimkr wrote: ↑Fri Aug 09, 2024 7:17 am

Regarding ideas - I never said I wrote overlay, apt or whatever, or was the first to use them in Puppy context. But the way my builds integrate apt has some reliability advantages over other integrations, and my save2flash is faster with fewer writes, etc'. You ignore important implementation details so you can portray others as 'cloners' of ideas you consider to be yours.

Oh, and my fork doesn't have this SFS naming limitations you bring up so often.

The weird thing is that no matter what I say regarding Puppy Linux, you seem to think (wrongly) that I am attacking you personally. Sometimes I defend myself against personal comments by attacking back; they say attack is the best form of defence, but generally speaking I just watch all developments going on and think good of most of the work that does happen, but like everyone on this forum, if I think there is a flaw badly needing addressed for the good of all, I say so. But I am never saying who has responsibility for fixing any flaws, because no one does have that as a responsibility.

From my own past actions regarding dpkg/apt addon for Fossapup, it should be obvious that I think Puppy needed a real package manager (and for Debian-based Pups that would be dpkg/apt), I think it is best to move to overlayfs (I did that in FR certainly). I think if you adopt the likes of apt of course there are security issues and problems relating to systemd expectations so that needed to be addressed eventually in any Puppy implementations, and well done for that... I didn't invent overlayfs (I simply use it); I didn't invent dpkg/apt (I hardly know how to use it, but install it anyway; I didn't invent any union layered filesystem (they have been around for several decades in various shades and forms).

If someone takes over woof-CE and it becomes brilliant, well thank goodness for that (but I don't hold my breath).

As for yourself dimkr; none of these above comments (aside for the "well done for that") are anything to do with you. I don't like a lot about your general attitude and trolling against myself and FirstRib nature, but really your comments are irrelevant at the end of the day to me. What you do with your Vanilla Dpup fork is entirely up to yourself and I am not paying much attention sorry.

Oh, good to hear you removed these awful SFS naming limitations; I have complained about these as a negative feature of traditional Puppy Linux for years (over a decade in fact) - unfortunately the fans of Puppy seems adamant that they needed their adrv, bdrv, ydrvs and so on - as if it would be not Puppy not to have them, or would somehow make Puppy less unique and too much like other distros that avoided such limitations (and limitation it was and is). I suppose the Puppy crazy-faithful (an odd behaviour in my view) don't want to follow the leads EVER of DebianDog or FirstRIb-based distros and hate to give credit when some might be due - but fine... such are some developers in open source world - we see that.

Maybe the problem was (in the Puppy Linux world I mean) that there was too much individual investment into shell script remaster type utilities that were writing with such drives as adrv, bdrv and so on in mind. Maybe it was never really a problem to Puppy users (definitely an unnecessary technical limitation however). Who knows? Does any of that matter? Not to me, though why you have to keep quoting my comments about Puppy Linux beats me. You are not Puppy Linux and all you are to me is someone who once beavered away on woof-CE github site and later forked that and beavers away on your own Vanilla Dpup, but... who keeps trolling me that I have to reply to or appear to accept the nonsense you throw at me regarding what I believe or do not believe, and so often you claim thoughts I'm supposed to have that never in fact crossed my own mind. Actually, I don't 'believe' very much, which is another fault about me apparently, but that is not anyone else's concern either; wow, there are certainly some nutcases on here, which was a big surprise to me. Okay, so I'm the nutcase for not believing what they believe, but such nonsense is no requirement of Linux development anyway.