KLV-Airedale-alpha Released for Experimentation and Improvement by the Puppy community

[mikewalsh]

Okay.

I've turned the final iteration of ScreenControl - v1.4 - into an SFS for 'Airedale'.

This was the last, 'manually-operated' version Fred & I produced between us before he eventually built his marvellous rshift-portable; a tiny little self-extracting script that sits in /root/Startup, and autochecks where you live via geolocation. This one makes use of the minute sct binary, and lets you manually adjust both brightness & colour temperature 'on-the-fly', accessible from an icon in the notification area.

It's another one that makes use of /root/Startup.....for which we have Fred to thank for its re-implementation in 'Airedale'. Cheers, buddy!

I haven't yet tried 'rshift-portable'; that one lives in /root/Startup anyway. I'll give it a go later on, and report back; I understand Fred makes use of it in the Dogs, so I can't see it being an issue with 'Airedale'.... I like rshift-portable, but being able to manually adjust stuff 'on-the-fly' without needing to keep turning the automatic feature on & off does have its advantages, I feel. If rshift-portable also works, that'll give us twice as many options!

The ScreenControl SFS is attached to this post. Yes, it'll load from anywhere, but like I said a few posts back, it makes more sense to put it with everything else in the KLV directory to start with.....that way, it'll get picked up & auto-loaded at the next boot. Hope it's useful for some of you.

Mike.

[rockedge]

@mikewalsh really nice work ! Now that you are on a roll with desktop design I have made
KLV-Boxer-alpha1.

Which is built fresh from a PLUG file recipe that does the same core build as KLV-Airedale, but is using JWM - ROX as the desktop. Totally surprised that running the build script ended in success and the system booted into the desktop on the first try.

This is really alpha1 and there are no JWM customization tools onboard but I am going as fast as I can to add all the pieces that are now going into KLV-Airedale into KLV-Boxer. (Boxer uses a fixmenu script for xdgmenumaker to generate the menus)

another hour or 2 I will make a new topic and upload an ISO to try out. KLV-Boxer-alpha1 is missing tray icons/controls and lots of other stuff.

Sort of what it looks like ->

2021-12-27-232307_1024x768_scrot.png (144.97 KiB) Viewed 1366 times

[mikewalsh]

As I promised above, I've tried out Fred's rshift 'lite' portable.

Works OOTB. Pretty much as expected, really. Had to do my usual trick of editing the geolocation info - it always seems to place me between 60 & 100 miles from my real location - but then that's down to how accurately your real location is reported by all the IP stuff. Never has been that accurate where we are! Certainly nothing to do with the utility Fred uses.

Aside from that wee issue, rshift-portable works as well as ever, and is a welcome addition for those who, like me, can't stick bright light for too long.

I mirrored these for Fred a long while ago. You'll find them at the Drive, here:-

https://drive.google.com/drive/folders/ ... sp=sharing

There's a generic 32-bit, a generic 64-bit, and a special one for Wary/Racy. The 'generic' 64-bit is fine for Airedale. D/l it; unzip it, and stick it in /root/Startup (if you haven't got /root/Startup there's instructions further back in the thread on how to set it up and get it functional). No need for an SFS with this.

Mike.

[fredx181]

Create .xbps package, for testing:

For some time I was thinking that it would be nice to create our own .xbps package (to be not dependent only on SFS's)
Here's simple basic way with GUI (yad based), feedback appreciated (makes use of "xbps-create" which has more options than this script provides, e.g. specify: Maintainer, Long description, Licence etc...)
Sort of equivalent to "dir2pet", BTW, dir2xbps can be used with directory from e.g. extracted .sfs or .pet
Some notes: xbps is rather picky (similar to apt-get):
- how a package is constructed, e.g. version number must end in "_nr" (with _ ) e.g. 1.0_1
- the name must be constructed <pkgname>-<version>.<architecture>.xbps e.g. mypackage-0.0_1.x86_64.xbps
- packages must not contain files that are also in other packages, for example, at first qiv-slideshow (see also below) refused to install because it had image qiv.png in /usr/share/pixmaps, which is also in package "qiv", so I renamed to qiv-slide.png and went ok.
So that can be a disadvantage compared to installing pets on Puppy IMO
EDIT: I see now there's option for xbps-install: -I --ignore-file-conflicts Ignore detected file conflicts perhaps that will solve conflicts, didn't test yet. edit: tested now and indeed solves that "problem", see my next post for the script inst-xbps with added the -I --ignore-file-conflicts option.

Usage of dir2xbps (in terminal): dir2xbps /path/to/packagedir
EDIT2: Re-attached with small fix (some error checking was wrong).

dir2xbps.gz

dir2xbps , remove fake .gz and make executable

(2.63 KiB) Downloaded 42 times

EDIT: New dir2xbps here: viewtopic.php?p=45927#p45927
Also here's a script inst-xbps to install a local .xbps package, usage: inst-xbps /path/to/mypackage.xbps
A bit disappointing to me is that the installed package doesn't appear in octoxbps, it can be removed though with xbps-remove
Installing a local .xbps is rather complicated, AFAIK it needs to be indexed first before actually installing.
(in the script a variable is set on top INDEXDIR="/var/cache/xbps" change the path as preferred.

inst-xbps.gz

inst-xbps , remove fake .gz and make executable

(640 Bytes) Downloaded 40 times

Screenshots below: dir2xbps creating xbps for "qiv-slideshow" by the Magnificent Mike , that he once shared as .pet in the old forum.
And here's qiv-slideshow-0.0_1.noarch.xbps (remove fake .gz):

qiv-slideshow-0.0_1.noarch.xbps.gz

(24.83 KiB) Downloaded 42 times

Screenshot_2021-12-28_19-14-50.png (78.34 KiB) Viewed 1315 times

Screenshot_2021-12-28_19-14-60.png (63.92 KiB) Viewed 1315 times

[mikewalsh]

@fredx181 :-

Coo, what a palaver.....

Takes a bit of getting used to, and it *seems* rather long-winded at this very early stage, but.....it does work. Yes, indeedy!

I feel I must take exception to the description you gave to your QIV package, y'know. "Slideshow app by Mike Walsh..." Alright, I started the ball rolling after musher0 and a couple of others started playing around with it, but most of the coding - certainly the stuff that made it functional! - was all yours, as I recall.....

"Slideshow app by fredx181 & Mike Walsh..." would have been more appropriate, I feel.

Same for this package I've built here, if I'm honest. I've turned the ScreenControl v1.4 SFS into an .xbps package. Again, it MAY have been my idea, after discovering the way johnywhy had built his brightness slider didn't work on AMD machines, but let's be honest; the functioning mechanism was all yours, if I remember correctly..! Credit where credit's due, mate. (Amply mentioned in the right-click 'About' splash-screen).

I know my scripting skills are steadily improving these days, but this was three long years ago...

Ne'm mind. I digress.

I'd manually installed ScreenControl initially, so I never actually tried the SFS of it, though the others I constructed seem to be working nicely. So, I removed everything, built the package, and installed it. Works fine.....after I found out one of the scripts hadn't been made executable, and the package had to be re-built again. (*Grrr....*)

Obviously, after some more of the basics have been hammered out we shall have to automate this stuff a bit more; make it easier for the "great unwashed" to use, as it were. All in good time, all in good time.

----------------------------------

I've attached ScreenControl-1.4_0.x86_64.xbps to this post. Have a play around with it, and see how y'all get on with it, guys. The 'fake' .gz is needed for the thing to show up when uploading, 'cos otherwise the forum doesn't even see it..... Make sure you remember to remove it.

Basically, copying it to /var/cache/xbps is essentially 'adding it to the repository pool'.....without which, xbps can't "see" it, and tells you it doesn't exist! We'll streamline all this eventually (I hope!)

And before I forget; thanks, Fred!

Mike.

[fredx181]

As I suspected, the -I --ignore-file-conflicts (see EDIT in my previous post) solves a possible problem of conflict where packages have the same file(s) inside, this inst-xbps has added that option.

inst-xbps.gz

remove fake .gz and make executable

(643 Bytes) Downloaded 41 times

EDIT: @mikewalsh

"Slideshow app by fredx181 & Mike Walsh..." would have been more appropriate, I feel.

No.. you are the "founder" of it

Basically, copying it to /var/cache/xbps is essentially 'adding it to the repository pool'.....without which, xbps can't "see"

Well, yes (although not automatically, even /var/cache/xbps needs to be specified) but doesn't need to be /var/cache/xbps , can be any folder (containing .xbps file(s) ) as long as it's specified at install (xbps-rindex ...).

EDIT: dir2xbps re-attached with small fix (see at EDIT2 in my previous post)

Forgot to say earlier: IMO working with .xbps packages is better than SFS's. For example because you can specify dependencies (these will be auto-installed then), with SFS's you can include them of course but that's not always practical.

[rockedge]

#### Note

The .xbps extension is now a valid attachment in posts. Upload limits apply.

[bigpup]

@fredx181

Thanks for giving us a way to produce .xbps packages

Any chance you could do some coding magic, to get SFS-Load-On-The-Fly, to work in KLV-Airedale?

We have SFS Load
But it does not have:
Display of what is or is not loaded.
No list of available SFS packages.
Does not seem to retain loaded SFSs between boots. (this may not be SFS Load problem)

[mikewalsh]

@bigpup :-

I mentioned a few posts back that it makes more sense to place the SFS package in KLV's equivalent of "/mnt/home" (alongside all the other SFS components) BEFORE you even try to do anything with it. Don't forget, most of the time - when you want to load an SFS in Puppy - if you haven't already placed it in /mnt/home, Puppy will ask if you want to move your SFS package before loading it.

Where is your Palemoon SFS situated?

Where are you trying to run pFind from?
Did you remember to add those all-important numbers in front of the SFS package name?

I have to assume that the only reason you want Puppy's "SFS Load-on-the-fly" ported across is because

a) You're used to it
b) You know what you're doing with it
c) It's "better" simply because it remembers if an SFS is loaded or not, AND gives you more information!

Think on this; Puppy already has many years of development behind it. KLV is being built from scratch.....from the ground up, moreover, in a format/layout most of us are still unused to.

I appreciate that most folks are comfortable with what they know, and many see no reason why they should have to learn new ways of doing things......and many of us are either already at, or fast approaching, the time of life when 'learning' no longer comes as easily as it once did. I also appreciate that it's important to make things work as easily as possible so that more people can try it out and not feel too "lost" with it.....but that invariably means GUIs for the "point-and-click" guys. And that's a LOT of work.

Rome wasn't built in a day, mate. We'll get there!

Be patient.

Mike.

[bigpup]

Forget about what I posted about the PaleMoon SFS.
Somehow I also installed Pale Moon.
I have to look back at my old stuff.
I think, I actually found, an already made xbps package, of it.
Maybe, with each new version of KLV-Airedale, I need to be starting from scratch, with a clean fresh install, and no previous save.

I like SFS-load-on-the fly because it is a better program.
It gives a list of available SFSs
It gives list of what SFSs are loaded
Whatever it is doing. The loaded SFSs are remembered between boots.
One specific location to store SFSs is a good thing.
If KLV-Airedale is not going to have the Puppy /mnt/home than have a SFS storage directory someplace.

Are you saying you have no problem with SFSs loaded being remembered between boots?

If I put a number on the beginning of the SFS name and place it with the other KLV-Airedale SFSs.
Doesn't it just make it another KLV-Airedale SFS?

Note:
Tried it with your 65UExtract+PackIt.sfs.
Yes it loads whatever the numbered SFS is. so it is like it is installed.

SFS load will do nothing with it if loaded this way.
SFS load will not see it as loaded.
I tried SFS load to deactivate it.
It told me it was not activated.

I want to be able to load or unload SFSs on the fly.

[fredx181]

@bigpup
I see there's some confusion, I'll try to clear up some things (as far as I know, anyone correct me if I'm wrong)
KLV Airedale doesn't have "aufs" in the kernel, instead "overlay" is used for the layered system.
(why rockedge chose to not include aufs and use overlay instead could be many reasons but is another discussion)

Unfortunately overlay has it's limitations, so there's no way that you can expect that SFS support is the same as in Puppy (that uses aufs)
So to sum up a few things:
- Loading an SFS at boot (when the .sfs is next to the main sfs's) should survive a reboot (as long as it stays in place)
- Loading an SFS 'on the fly' will NOT survive a reboot (only for the current session)
- Unloading an SFS that's been loaded 'on the fly' CAN be unloaded 'on the fly'
(run loadmodulegui, choose deactivate and select the sfs or run from terminal e.g: loadmodule -d /path/to/mysfs.sfs to unload)
- Unloading an SFS that has been loaded at boot CANNOT be unloaded (not on the fly, only by removing it from the folder booted from and it will be unloaded at next boot).

Not saying that things cannot be improved, e.g. I will look at what you (sort of) suggested, a GUI that shows which sfs's are loaded (at boot and on the fly) and possibly with option to unload the ones that are loaded on the fly.

Hopefully things are more clear now, just say if not.

[mikewalsh]

A-ha. Thanks for the explanation, Fred.....that's cleared a couple of things up for me, too.

Mike.

[wiak]

Yes, does seem to be some confusion, though, sorry, I haven't been keeping up with thread because of that no water to house situation I am currently trying to finally fix...

Main way to load sfs files is the default method using numbered sfs name. Actually, that is how the system loads gtkdialog; that is provided by an sfs file numbered 10gtkdialog... Any numbered sfs file gets loaded automatically always and each time on boot into the overlay layer position given by the number (so gtkdialog sfs gets autoloaded as a filesystem layer to layer position 10). Really this is just like the adrv, fdrv, ydrv, zdrv of Puppy except that numbers are used instead of alphabetic names, and you can use any numbers up to 99 (which would be the topmost readonly layer of the overall merged filesystem).

As for load on the fly sfs_load, or whatever it is being called here. I understand that KLV-airedale is using fredx181 symlink way of doing that; I haven't myself been using it so didn't know if it was somehow allowing an sfs to be remounted, though doubted that. Only thing is, I believe sfs files loaded in that manner DO NOT normally get a number put in front of their filename: if they had a 2-digit number in front of their filename they would be getting loaded at boottime anyway per my previous paragraph (assuming in same folder as the vmlinuz and so on). So talk about the sfs_load on the fly sfs having a number in front seemed wrong to me; however, if you simply always want a particular such sfs loaded each boot automatically then don't load it with sfs-load on the fly, simply rename it so it does have a 2-digit in front filename (that's actually what I do - I don't use load on the fly, though I will experiment with that later once I have time again.

Very easy indeed to modify the boot to use aufs instead, but personally I think that would be a retrograde step despite that pretty much singular easy sfs_load_to_aufs_layer advantage aufs provides. Since Linux kernel team chose not to support aufs but instead to support overlayfs I think it makes sense to improve any alternative sfs loading mechanisms for overlayfs, which is what is happening here.

wiak

[rockedge]

KLV Airedale doesn't have "aufs" in the kernel, instead "overlay" is used for the layered system.

Not entirely correct! KLV-Airedale is using a huge Puppy Linux kernel provided by @ozsouth . That means the kernel will have the AUFS patches applied.

Both AUFS and overlay are built into huge kernels for Puppy Linux. At the present in KLV-Airedale it is actually the modules and kernel 5.15.6 and the firmware from 5.4.70-rt40.

In theory one should be able to use either AUFS or overlay on the same system. (NOT sure about this though)

I have not directly tried out using AUFS on Airedale

[wiak]

Sorry, my post crossed with yours rockedge. Yes, indeed, KLV-airedale is using a huge Puppy kernel so the kernel in this case does include possibility of supporting aufs - like I suggest, it's pretty trivial to modify the initrd/init to use aufs (afterall, overlay and aufs do pretty much the same thing, via a pretty similar mount command line - pity they order the layers in the mount command the opposite way round though, but that's just a minor annoyance that slightly complicates switching over to the other method) - however, nowadays, I prefer developing for overlayfs since that is the official kernel method and most alternative kernels (such as those from Void Linux repos) do not include aufs, so improving overlayfs use makes more sense longterm to me.

I really hope you stick with overlay, however - doing so helps develop these alternative sfs-load utilities rather than just sticking with older solutions. There are also some capabilites in overlayfs that haven't been investigated or developed at all for yet. Overlayfs allows the nesting of other overlays, which actually opens up a lot of possibilities for future developments (and possibly sfs-load-on-the-fly alternatives to symlink method - though I haven't thought that through further myself as yet) - I don't think aufs can do that layers within layers nesting in such a powerful way at all, but I may be wrong (though I do understand the aufs advantage at inserting new layers in an already built layer-system, which overlayfs cannot do).

[fredx181]

KLV Airedale doesn't have "aufs" in the kernel, instead "overlay" is used for the layered system.

Not entirely correct! KLV-Airedale is using a huge Puppy Linux kernel provided by @ozsouth . That means the kernel will have the AUFS patches applied.

Both AUFS and overlay are built into huge kernels for Puppy Linux. At the present in KLV-Airedale it is actually the modules and kernel 5.15.6 and the firmware from 5.4.70-rt40.

In theory one should be able to use either AUFS or overlay on the same system. (NOT sure about this though)

I have not directly tried out using AUFS on Airedale

Ah, didn't know it has aufs included, still you apparently chose for using overlay (but as wiak wrote in last post, with good reason, I think).

[rockedge]

@wiak I agree overlay being the chosen method in the kernel, it should be the direction we're following. But since we have so many AUFS patched huge Puppy Linux kernels and the skeleton initrd can boot and use them it was a twist I could not resist.

The current system using overlay and the numbered layers of squash files is the right direction I believe as well.

Basically it's about being really cool and doing something I don't see being done anywhere else.

Plus if it works like we think..........

p.s. I have a working KLV-Boxer-alpha2 about ready to upload. It's outfitted similar to Airdale but all JWM - ROX

[fredx181]

... There are also some capabilites in overlayfs that haven't been investigated or developed at all for yet. Overlayfs allows the nesting of other overlays, which actually opens up a lot of possibilities for future developments (and possibly sfs-load-on-the-fly alternatives to symlink method ...

Would be nice, but I've been investigating something like that (nesting of other overlays) before I worked on the symlink method (which I don't really like, to be honest) but couldn't find it, adding another layer to overlayfs "online" (or call it on-the-fly) seems not possible to me, but perhaps I didn't investigate enough...

[wiak]

... There are also some capabilites in overlayfs that haven't been investigated or developed at all for yet. Overlayfs allows the nesting of other overlays, which actually opens up a lot of possibilities for future developments (and possibly sfs-load-on-the-fly alternatives to symlink method ...

Would be nice, but I've been investigating something like that (nesting of other overlays) before I worked on the symlink method (which I don't really like, to be honest) but couldn't find it, adding another layer to overlayfs "online" (or call it on-the-fly) seems not possible to me, but perhaps I didn't investigate enough...

Yes, I'm not overly fond of the symlink loading either, though I gather it is similar to what tinycorelinux does and seems to have worked fine with their distro longtime and for all packages at once (?) so maybe it is fine. Certainly I think overlayfs can't add extra layer once built but I just wonder about idea of rebuilding complete layer and switching for a second time later?... maybe not (though I did do some nesting experiments long long ago but can't remember result details now). Choice is a great thing of course - so I do sometimes contemplate aufs as option, but I just feel too many directions dilutes focus (which can effect whole system developments) so just haven't done it despite thinking about it...

[fredx181]

Certainly I think overlayfs can't add extra layer once built but I just wonder about idea of rebuilding complete layer and switching for a second time later?

Remounting / with added extra layer you mean perhaps ? I tried that, but overlay is stubborn (without showing any error it stays exactly how it is)

[fredx181]

A few more .xbps packages:

xlunch, graphical app launcher
Just sharing, but need to say that some applications won't show the correct icon ("ghost" icon instead), specially the xfce applications, weird..., don't know yet how to solve that.
xlunch-4.1_1.x86_64.xbps:
https://dl.dropboxusercontent.com/s/54r ... .xbps?dl=0
Shows some entries in Menu category "System'

And trans-tray, a translation program I once made (with much help from other people, e.g. stemsee, vovchick, misko)

trans-tray-1.0_1.noarch.xbps

(66.6 KiB) Downloaded 30 times

Shows in Menu category "Office', after running, an icon should appear in the system-tray
Depends on gawk, yad (which are already installed on KLV) and xclip (which should be auto installed when installing this package).
Recently tried it and found that "Google" translate works ok, but Bing and Yandex not always.

[dimkr]

I think that the overlayfs vs. aufs debate, the discussion about SFS loading mechanisms, and everything related to boot (Ventoy, UEFI, etc'), receive way too much attention.

If the kernel is old or cannot be updated, Bluetooth audio doesn't work well, the user can't change the system language, video playback is not hardware accelerated, RAM consumption is the same as in other distros, etc', it doesn't matter if the user has to reboot to load a SFS, or if SFS loading is a bit slower. People won't use this distro if it doesn't support their hardware, or if it doesn't run reasonably well, because most users don't buy a computer so they can load and unload SFSs or install packages of a particular format.

[fredx181]

I think that the overlayfs vs. aufs debate, the discussion about SFS loading mechanisms, and everything related to boot (Ventoy, UEFI, etc'), receive way too much attention.

If the kernel is old or cannot be updated, Bluetooth audio doesn't work well, the user can't change the system language, video playback is not hardware accelerated, RAM consumption is the same as in other distros, etc', it doesn't matter if the user has to reboot to load a SFS, or if SFS loading is a bit slower. People won't use this distro if it doesn't support their hardware, or if it doesn't run reasonably well, because most users don't buy a computer so they can load and unload SFSs or install packages of a particular format.

Not sure that I understand your comment, KLV Airedale has kernel 5.15, which isn't old.

[dimkr]

Not sure that I understand your comment, KLV Airedale has kernel 5.15, which isn't old.

Not 5.15.12, and it doesn't have an update mechanism for the day 5.15.6 (or whatever version it uses) has a critical security issue.

What I'm trying to say is, the file system used to layer SFSs on top of each other or the package format are just uninteresting implementation details for the user. But privacy, security, performance and usability are important.

[rockedge]

People won't use this distro if it doesn't support their hardware, or if it doesn't run reasonably well, because most users don't buy a computer so they can load and unload SFSs or install packages of a particular format.

Also security wise, you tell me a more secure system then Puppy or KLV or WDL or DebianDog when they are loading the main OS components from read only squash files. Hard to beat when using limited persistence.

So a real security aficionado should gravitate strongly to these OS's that load from read-only squash files

Show me a huge Puppy kernel 5.15.12 and I'll swap it in. Changing the kernel in KLV is easy.

I might just borrow change_kernels from a Puppy and adapt it to operate on KLV. or something similar

[rockedge]

KLV isn't for the faint of heart.

It is a great place for a "newbie" to jump in and try stuff though or for the experienced to advance it and their skills.

Never intended it to compete with WinDoz or the "Big" Linux's in that sense. It's more of a box of parts that can be turned into something.

Could try to churn out a 5.15+ with the woof-CE kernel-kit...... OR just switch out to the Void Linux kernel in the next builds and use Void's rolling updates....be stable right on the edge that way EVERYDAY and skip this entire discussion.

@dimkr Kind of picky in an alpha stage or no? Which kernel would you recommend for now?

[mikewalsh]

I think that the overlayfs vs. aufs debate, the discussion about SFS loading mechanisms, and everything related to boot (Ventoy, UEFI, etc'), receive way too much attention.

If the kernel is old or cannot be updated, Bluetooth audio doesn't work well, the user can't change the system language, video playback is not hardware accelerated, RAM consumption is the same as in other distros, etc', it doesn't matter if the user has to reboot to load a SFS, or if SFS loading is a bit slower. People won't use this distro if it doesn't support their hardware, or if it doesn't run reasonably well, because most users don't buy a computer so they can load and unload SFSs or install packages of a particular format.

.....or in other words, at the end of the day, if it doesn't do everything an end user wants - and expects - OOTB, there & then, they'll drop it like a hot poker.....and look elsewhere.

So; are we "wasting our time" here then? I mean, lets be honest; at the current point in time, we're experimenting, and playing around with possibilities. I don't see there's that much "urgency" to have to get on and make it a generic, mass-appeal distro as quickly as possible.....or is that your own approach? To "get on" and make something usable by the great unwashed as soon as is humanly possible?

(I'm NOT being "sarky" when I ask that; I'm genuinely interested in the different approaches by individual developers, 'cos it's all "grist for the mill", and gives me an insight into how different people see this kind of thing.)

Rockedge's remark about likening KLV to a big box of parts sounds about right to me.

(*shrug*)

Mike.

[dimkr]

Which kernel would you recommend for now?

Either 5.10.x or 5.15.x from https://github.com/puppylinux-woof-CE/w ... el-kit.yml.

These builds run once a week, and the configuration files get better over time, as users find issues (for example, boot from NVMe drivers works thanks to https://github.com/puppylinux-woof-CE/woof-CE/pull/2650, and this problem won't return). In addition, every build is accompanied by matching firmware, and the "firmware picker" logic gets improved over time.

So; are we "wasting our time" here then?

That's exactly what I'm thinking about. Nobody needs a distro that suffers from the same issues as Puppy, or a distro similar to Puppy with big compromises (like high RAM consumption). IMHO, the focus should be learning from Puppy's mistakes, not small implementation details like aufs vs. overlayfs.

[rockedge]

(like high RAM consumption)

???

I don't see any wasted RAM in Void systems. Seem more efficient then just about anything else.

I'll test out installing all the packages that are now being loaded as SFS, thereby removing the SFS loads and putting it all in the main file system SFS, to test out what advantages there are.

[wiak]

So; are we "wasting our time" here then?

That's exactly what I'm thinking about. Nobody needs a distro that suffers from the same issues as Puppy, or a distro similar to Puppy with big compromise...

KLV-airedale a compromise with same issues as Puppy? Actually, KLV-airedale doesn't have any major set-in-concrete-by-build-system limitations, it is fully multi-user capable (like the DebianDogs) so no pseudo-user 'spot' issues, and no PPM to worry about; since it uses official upstream Void Linux package manager (xbps) there is no limit to what it can be made to include, no restrictions at all, so can be tailored to provide containers, Wayland, or whatever by simple recipe changes (or once installed by the user). I only know one (very new and different) Puppy that uses xbps package manager, which gives KLV-airedale the full power of whatever Void Linux has to offer. You must be criticising Void Linux too then, which doesn't seem to be the opinion of the majority of the Linux community. And certainly, via overlayfs frugal install functionality KLV-airedale can handle all the usual cases aside from one exception being a difficulty with sfs-load-on-the-fly since not using aufs - that is all that discussion was about and it was worth having since nice to find alternative mechanisms for what people here are used to.

XFCE-based distros use more RAM than JWM/Rox of course, but so what - it isn't a significant amount on even quite old machines nowadays, and rockedge is also making a KLV that uses JWM/Rox for those that need or want or are interested in that. We are all surely a bit tired of 'fake news' involving 'fake or irrelevant statistics' after all the covid nonsense for the past year or two surely?

Why the accusation of KLV-airedale interest being a case of anyone 'wasting their time'. No-one is wasting their time when they are doing something that interests them. May not interest you at all, but why comment then(?), what does it matter to you??

If you have nothing positive to say, why post in a thread that doesn't interest you, unless you feel it is stealing some of your work without acknowledgement (?) Are you afraid of other distro build efforts, which are not in any case trying to compete with anyone else's efforts?