KLV-Spectrwm-CE-2.0 Using PipeWire

[Sofiya]

KLV-Spectrwm-CE-2.0 stable.
Kernel 6.1.38-rt13

ISO: 714 ( Mib ) Kernel -6.1.38
https://mega.nz/file/ylsH3QCT#41OZrO2gg ... xljKbOza2g

SHA1-MD5:
https://mega.nz/file/OpVUnB4Y#HbRMiQjoM ... SjPgzkKB5Q

note:
Uses Pipewire as a sound server

-----------------------------*****************---------------------------------------
The assembly is performed using the script "FR_minimal_void_spectrwm_CE_2.sh"

Code: Select all

/mnt/sda2/2-QEMU/QEMU-2.5.0-ubu16.04.AppImage qemu-system-x86_64 -enable-kvm -m 2G -vga std -smp 2 -device AC97 -name 'KLV-SpectrwmCE' -boot d -hda /mnt/sda2/2-QEMU/VirtualHDD.img -cdrom /root/Downloads/KLV-SpectrwmCE-2.0.iso

[rockedge]

using sClock

2023-10-20_1280x1024.png (97.71 KiB) Viewed 1443 times

[geo_c]

using sClock
2023-10-20_1280x1024.png

Funny you should do that when I just figured out how to use my gtkdialog clock and get it to float automatically: viewtopic.php?p=101561#p101561

[geo_c]

So, I just combed through my keybindings and smoothed them out even more. Took out the unecessary shift keys.

Here's my thoughts:

I have probably the more complete set of bindings documented for manipulating the workspace, and at some point it would seem to make sense to standardize these bindings.

The other thing is I have many bindings listed in the splash that are default bindings not explicity defined in our custom spectrwm.conf.

I'm wondering if we should define them in the spectrwm.conf just so that they are all visible and not assumed to be there as defaults, even though they mostly are. It seems confusing for someone who might look at the KLV-spectrwm bindings and try to reconcile them with the ubuntu-man page bindings listed. Whereas if they were all defined, then they could be seen and tested just by looking at the config.

[Sofiya]

using sClock - The only drawback is they are always on top

/root/Startup/

Code: Select all

#!/bin/bash

sclock --color=#90AEC2 --center --stick &

rename /usr/local/bin/ sClock to sclock
--------------------------------------------------------------------------------
/root/.spectrwm.conf

Code: Select all

quirk[Sclock]                               = FLOAT

[Clarity]

Where is this distro's ISO file that is mentioned in the opening post?

[geo_c]

Where is this distro's ISO file that is mentioned in the opening post?

I just see a build script in the OP, no iso.

You should try it sometime!

Basically create an install directory, copy the script into it, run the script (from a terminal), it will build the install, then run wd_grubconfig to get a stanza. I think that's all that's necessary.

I did it with bspwm and even modified the plugfile to add a whole other set of preferred applications.

I'll be jumping on @wiak's Sway build script at some point.

[Clarity]

Hello @geo_c . I'm spending the week testing ISO files. That was the reason for that request, as the OP indicates such.

I expect that I will be testing build scripts at some point in upcoming future after all of the boot launch issues for users are 'put to bed'. There is still a bit of work that will go into completed documentation for forum users.

I look forward to your reviews as time goes forward.

Thanks, as that idea you offer is already on my list in my in-plan: for KLs/DOGs and others as time will permit.

[Sofiya]

KLV-Spectrwm-CE-2.0

[Sofiya]

I thought for a long time about where to attach the calendar, by clicking on the date and time, it is necessary to separate the date and time module and write a script for the time to open the calendar by clicking, I don’t want to separate it because I like the way it looks now. In general, I attached it to a hotkey

Code: Select all

 program[gsimplecal]            = gsimplecal
 bind[gsimplecal]               = MOD1+k
 

[Sofiya]

Code: Select all

xbps-install -y xorg spectrwm rofi polybar
xbps-install -y dmenu xlockmore tzutils
xbps-install -y gvfs-smb gvfs-mtp gvfs-cdda
xbps-install -y yad gxmessage xmessage acpi lua fox xdotool

# Optional packages
xbps-install -y geany gftp rox lxterminal
xbps-install -y e2fsprogs yelp gparted
xbps-install -y dosfstools mtools cpupower lm_sensors
xbps-install -y squashfs-tools wget octoxbps 7zip
xbps-install -y pcmanfm htop gpick gufw gettext

# Desktop configuration
xbps-install -y arandr mtpaint mpv
xbps-install -y epdfview scrot sxiv gsimplecal-gtk3 gdmap
xbps-install -y lxtask gzip python-requests lxappearance viewnior
xbps-install -y elogind xtools i3lock wmctrl nitrogen leafpad galculator
xbps-install -y xsettingsd brightnessctl dunst xcompmgr 
xbps-install -y hsetroot slop xdo xsel xtitle zsh fzf fd sed 
xbps-install -y zsh-autosuggestions zsh-syntax-highlighting source-highlight 


xbps-install -y cups cups-filters cups-pdf samba-cups

xbps-install -y NetworkManager network-manager-applet

[Sofiya]

You can also add a configuration file for "gsimplecal"
which will display UTC/Local time
/root/.config/gsimplecal/config

[rockedge]

@Sofiya I just finished a build of KLV-Spectr-CE-2 using the latest script.

Looks good so far, except MOD+MOD1+k does not do anything, so no navigation command list. Fonts needed adjustment in Rox, could not see any text because it was too dark. I changes the color scheme a little bit so it's easier for me to see.

Using the logout window, MOD+SHIFT+x if no "y" or "n" is entered and the query field is empty then rofi throws an error.

2023-10-26_420x334.png (70.74 KiB) Viewed 1068 times

[geo_c]

Looks good so far, except MOD+MOD1+k does not do anything, so no navigation command list. Fonts needed adjustment in Rox, could not see any text because it was too dark. I changes the color scheme a little bit so it's easier for me to see.

Last iteration of splash screen binding is MOD+z

I began just unchecking the text color box in Rox Options so I wouldn't have to redo all the colors when changing gtk themes. With the box unchecked it will use the gtk theme colors and the text will be visible. Otherwise they need to be tweaked for dark themes.

[geo_c]

Looks good so far, except MOD+MOD1+k does not do anything, so no navigation command list.

Last iteration of splash screen binding is MOD+z

And I'm thinking of re-working that splash, because the list is so tall that it doesn't quite vertically fit on some display resolutions. I could simply make the text smaller, but I thought it might be a better idea to break the list into two side by side columns, which allow to add headings and descriptors.

[rockedge]

@geo_c my MOD+z isn't working either.......has to do with gtkdialog-splash for some reason......

[geo_c]

@geo_c my MOD+z isn't working either.......has to do with gtkdialog-splash for some reason......

hmm, interesting.

I'll have to build CE-2 to check it out. That's not gonna happen for awhile though. I'm leaving in the morning.

I'm playing with my net book and I had to change battery=BAT0 to battery=BAT1 on line 178 of polybar config to get the battery icon displaying. As well as changing the hwmon-path = /sys/class/hwmon/hwmon0/temp1_input to /temp2_input to get the temperature in the polybar.

I'm just guessing, but the guesses are working, so it's giving me a little more confidence with the polybar config.

This is on a very old Toshiba Satellite netbook.

[Sofiya]

@Sofiya I just finished a build of KLV-Spectr-CE-2 using the latest script.

Looks good so far, except MOD+MOD1+k does not do anything, so no navigation command list. Fonts needed adjustment in Rox, could not see any text because it was too dark. I changes the color scheme a little bit so it's easier for me to see.

Using the logout window, MOD+SHIFT+x if no "y" or "n" is entered and the query field is empty then rofi throws an error.
2023-10-26_420x334.png

Using the logout window, MOD+SHIFT+x if no "y" or "n" is entered and the query field is empty then rofi throws an error.
2023-10-26_420x334.png

The session exit menu works on this principle until “y” or “n” is entered, if nothing is entered, a warning pops up - yes my mistake, there is no script "message.rasi" . Thank you very much ! I'll fix it

Looks good so far, except MOD+MOD1+k does not do anything, so no navigation command list. Fonts needed adjustment in Rox, could not see any text because it was too dark. I changes the color scheme a little bit so it's easier for me to see.

Some hotkeys are not in my assembly, since they are not exactly solved and there is no exact final list

[geo_c]

Some hotkeys are not in my assembly, since they are not exactly solved and there is no exact final list

In a few days when I get a chance to run the build I'll see what keys you have setup, and I'll compile a new list.

My bindings found here works well: viewtopic.php?p=101773#p101773

So if you added keys that conflict with that config, and things need to be changed that's the config I'll be working with.

[Sofiya]

How do you like the translucent session menu?

[rockedge]

How do you like the translucent session menu?

I like it, but then 30 minutes later not so much....more time goes by and I like it again....so hard to say until we use it with transparency for a while.

[wiak]

How do you like the translucent session menu?

I like it, but then 30 minutes later not so much....more time goes by and I like it again....so hard to say until we use it with transparency for a while.

In my view, it is great to have someone amongst us who is an active desktop facility/appearance enthusiasm, and no-more than that could be asked of them.

However, what pretty much every distro being produced/touted on this forum lacks is more actual development going on in terms of local and global connectivity between the devices in our homes and those out of it. We could play about with desktop types endlessly but ultimately not really get anywhere in terms of producing something better than mainstream distros provide out of the box anyway. You just need to look at the forums and websites of the likes of tiny core linux and slitaz to realize that the hobby is in danger of dying with fewer and fewer people willing to do more than talk, or request, or provide feedback reports on the few but incomplete pieces of work that still gets published.

Back in early Puppy Linux days, all that people wanted/needed was a full-featured enough single desktop in front of them that consumed as few resources as possible on their low-powered computers. That was a long time ago!

Today it is all about connectivity to our local devices and global devices elsewhere, but still we just trying out alternative desktop managers, but little in the way of active development work to meet that global connectivity demand. The only forum distro that seems to be at least trying to address such matters is FatDog, though I don't myself use that distro since I want to benefit from mainstream repos and also I have my own FirstRib build system hobby.

Yes, I think it is great to have a distro polishing enthusiast; not so much because we all need or want transparency or other fancy effects (for example the first thing I always disable as a waste of resources on any distro is Conky - I hate it - I prefer using appropriate console commands on the somewhat rare occasions I need general resource statistics, which I then need in more detail anyway...). So a lot of taste is involved, but good when someone provides a lot of such work, which we can of course then pick and choose from.

But who among us is developing all these forum distro missing matters related to connectivity? Really there is not much being done (and that includes the wealth of connectivity matters that equally involve those of us using containers or virtual machines - such work is simply being neglected.

Don't get me wrong. I'm exaggerating some points on purpose to draw attention to other matters. Reports are useful and feedback, of course, but only if there is sufficient active work actually going on. Involving ourselves in both is optimal. We need something that focuses our attention on the kinds of work really needing done, but we also need HANDS doing the work actively and not just suggesting it needs done.

I was an electronic engineer who was trained so long ago it involved very little indeed about computing. Yes, I ended up in a TCP/IP related research group for a while, but even there it was self-driven research (albeit in a group of like-minded individuals so we learn from each other), but the point is we learned by DOING. This forum is full of those who become experts at advising others where to find new utilities or code that solves problems, but the same people say that they themselves don't have the ability to write such utilities or do such dev work themselves. Well, that attitude will bring this forum to its knees eventually - after ten years or more using the likes of Puppy Linux and advising others, what excuse does anyone have for not simple PRODUCING solutions instead of REQUESTING (and sometimes sounding like DEMANDING) items of facilities to be included in releases. Well, isn't the person who thus asks the first person who should be providing the answer - how do you learn without trying - I too knew nothing once upon a time, but learned by TRYING and DOING despite thousands of hours of effort wasted at times. On a hobby site such as this, there is no such thing as experts and those incapable of doing development - that's such a pain of an excuse. If we all took that attitude the forum would have no-one doing anything except talking, asking, requesting, reporting on the active work of others. And nowadays, aging becomes an excuse - well, yes, we all age - time was available to all of us. Anyway, mainstream distros all pretty nice user experience nowadays - small distros such as those still developed on this forum cannot compete on look and feel issues alone (the likes of XFCE made some of that universally easy in fact).

Whilst we dabble and play with new builds that use alterative window managers (which is fine up to a certain extent) we fail to actively work on matters that most all of our distros lack and that are needed to give them point. We can no longer make tiny distros that provide enough of any facility, but really the distros are becoming irrelevant (like tiny core linux and slitaz already have basically become). We need active development by anyone and everyone willing to try new techniques. We don't actually need REQUESTS since it is not as if we do not already all know what is missing - we simply do not have enough people working on developing what is missing - and really it isn't desktop matters or types - it is matters of local and global connectivity to all our devices at home and elsewhere. We all know that is the world - none of us need anyone else telling us that (not me, not you). We don't need feedback, we need activity and development and less general talk and more actual activity. Fact is, there is so little development, there is NO NEED for feedback or general discussion - the place becomes dead. Excuses about lack of technical ability (after more than ten years of using some kind of Linux!) are just junk - I knew next to nothing once upon a time too - but I TRIED and learned. Yes, we get old and that is an excuse, but we weren't always old so not a very good excuse overall actually.

This is no longer 2005, when the whole hobby was driven by the need of a small distro, that could do most general single desktop activities to some extent (text processing, spreadsheet, browser, some graphics apps and so on) for our rubbish resourced computers. This is eighteen long years later!!! Nowadays our smart phones are best for simple browsing and watching videos and viewing images and that's all most people do! But really the modern world is all about CONNECTIVITY to all our devices local and global - too much general talk - requests - feedback reports on the tiny amount of dev work still done here. Too many pictures of desktop graphics actually. Who is working on the actual work needing to make our no longer so small-sized forum distros (impossible to make smaller almost, and pretty much irrelevant too) still meaningful against the likes of upstream offerings. Actually there is still plenty of scope - but it is not in desktop look and feel - it is in terms of connectivity issues with the world of devices, including our containers and virtual machines.

A bit off-topic, I know, and truly I'm glad we at KL have someone who puts in considerable useful time on desktop improvement matters, but I recognise that we need more people here, on the forum as a whole, who stop stop talking, requesting, reporting, providing feedback, but simply try making something that we all need to keep this place active as a hobby site of relevance. Sorry, I don't have more time either - so I just concentrate on my own interest, which is build system core, and everything I do I taught myself - nothing was from some computer science type formal training; I just wish people would start DOING and making this hobby site more active and interesting, or maybe we should all just give up and use Linux Mint and our super smart phones?!

[wiak]

Don't get me wrong. I am exaggerating some points on purpose to focus on what is missing.

We do need feedback and reports and ideas, but without activity there is nothing to report on, and most of all we need HANDS doing active work.

It is good that all of us involve ourselves in both - simply reporting is LAME.

One day will come when I too become so old that I can't usefully produce ANYTHING, but at least I once tried and did. When that old age day reaches that stage, I hope not to report or provide feedback at all; then I will just read what others are doing - though mainly only the active work being done by others since that is what matters in terms of feeling that this hobby site is alive and well.

[williwaw]

@wiak any specific examples of what these connectivity needs are?

[wiak]

@wiak any specific examples of what these connectivity needs are?

I think we should work on making a detailed list with some specifications.

I'm not suggesting even that is easy, but now and again some posts concern that matter. Rufwoof was good at this sort of thing, but alas he went more than a bit renegade and also his examples tended to be a bit spartan/unusual/over-the-top for the understanding like alone implementation by most people.

But a list and discussion on use and applicability would be helpful to indicate the sort of development that is basically not being done or not in consistent enough manner. Like I said, I have nothing per se against desktop wm experimentation, but there comes a time when major facility development should dominate since that's what provides revolutionary advantage in line with technological developments and availability. Obviously I'm talking about 'remote' accessibility and connectivity is an all-encompassing word. I can't without a lot of thought give much in the way of specific examples off the top of my head. Of course, this is off-topic KLV-Spectrwm, but does involve all distros. Admittedly I wish more people would appear that are into dev work since the less people developing such matters the less active the forum is likely to be, and certainly no-one on a hobby-type forum can or should be forced into any kind of endeavour. However, I just feel sometimes that the current predominant focus on desktop specifically is limiting overall.

Actually I think its great that Sofiya stepped up to the plate to polish some very-unpolished early distro build work, and continues to provide stunning work. My issue is that I am concerned that little if anything is being done to move the goal posts on other aspects of what our distros provide that potentially could help us produce distros that are special in terms of their provision. It used to be that making as small/efficient a distro as technically possible was a challenge that kept the forum active, but nowadays really small distros can only be produced for limited purposes without much likely usage. Connectivity (including security) is a (maybe 'the') major aspect of life today, which is fertile ground for forum creativity and activity more generally - we don't need yet another medium-sized distro, though that's fine, but a bolt on system that makes connectivity in any and every way a breeze would be something special. Technology isn't about which OS or even Linux distro you prefer to use, or even what it looks like, it is about what facilities it provides, but much of the forum's activity remains concerned with repetitive explanations of howto boot whatever distro or get some app or other working - not exactly revolutionary or inspiring longterm surely? There has to be some kind of overall aim in development to inspire and invite involvement, but small size and renovation of very old distro versions, is surely not a good longterm focus, and yes we can churn out tons of distro varieties, which is great, but only up to a certain extent.

A caveat on my comment: repetition is boring even when the ideas are good and not well enough implemented. That's why I use the word 'focus'; once a specification is debated and technologies of interest identified, the last thing we need is continual propaganda about any particular technology.

[rockedge]

I use KLV for remote work everyday (SSH). I use QEMU everyday.

That is why I included Dropbear in KLV-Airedale. Super solid SSH server easy to implement.

Today I will add it KLV-Spectr-RT and check it on KLV-Spectrwm-CE-2.0 which should be rather easy to do.

Everyday I use a combination of FTP, SAMBA and SSH to do stuff.

[wiak]

I use KLV for remote work everyday (SSH). I use QEMU everyday.

That is why I included Dropbear in KLV-Airedale. Super solid SSH server easy to implement.

Today I will add it KLV-Spectr-RT and check it on KLV-Spectrwm-CE-2.0 which should be rather easy to do.

Everyday I use a combination of FTP, SAMBA and SSH to do stuff.

Yes, I understand that rockedge. I'm not saying there is no work in that kind of direction, but I'm talking about devising a "system" that can become a universal focus that needs development work. Samba is very old, but yes, that is a good example of work done in the past that made it easy/convenient and part of Puppy Linux system.

But the key part of your comment seems to me to be: "which should be rather easy to do". Basically it should become natural as a part of our system operation, rather than some 'tricks and techniques' we can detail in howto do it (often repetitively provided year after year), or simply do it ourselves on our own systems. But that takes a lot of development and effort and lots of hands to do the work actively. As you know, samba, ftp, ssh, X, even vnc, rtp - these are very old technologies, but still we have not implemented any system that just makes all such matters of connectivity (and there is so much more nowadays) an inherent part of what we produce and in such a way that it feels as natural as moving the mouse (and that integration should include not just remote access of multimedia, but include containers and virtual machines and cloud instances in the mix)! That lack is with good reason - there is a lot of technology and so much that a lot of people need to be willing to do the dev work required - not just tell us about what is out there... we already most of us know that!

My concern is that we concentrate for months on look and feel (at a superficial in front of us only desktop level) but real polish is to do with actual functionality (read global/local connectivity included), which needs many hands to make light work... Maybe there are not enough people around with interest such that we just look at each others' pretty desktops (well mine is usually ugly so no point me posting that - or its just bog standard XFCE and even Linux Mint much of the time anyway). We get old for sure. Where are the new devs (for want of a better word)? Repetition is a killer of enthusiasm - be that repeated desktops, or Ventoy, or same old remaster sfs tricks. I enjoyed playing with tiling window managers, but I'm tired of that now too. Maybe it is just me, but what are we all trying to achieve overall on this forum nowadays when Puppy Linux small distro look and feel size is all but irrelevant overall now?

Some probably think we should all just focus on Puppy Linux itself. But to what purpose I wonder - how would that improve the forum aside from potentially there being more developers for one distro. You still need to identify what you are trying to develop and why that would make it a better distro than any other that already exists, and why therefore this forum is the focus of a continuing great hobby.

[wiak]

My only wish really is. No more repetitive requests from anyone - not for my ears anyway - no reports, even though some prove useful. Fact is I disagree with anyone saying they can't or shouldn't be involving themselves in actual creative work - development as some call it. Why flipping not? is all I can say about that. Without development - focus - aim - this forum will become like tiny core linux and slitaz forums and distros. Still got lots of scope and potential here at least - we survive, but I really hope some new people will appear with active attitudes and immediately be welcomed and more importantly listened to and encouraged to do something productive. We need people who have exciting new ideas who will also actively help develop them. Helping so-called 'new-comers' is all very fine and well, but after decades of same old stories it all becomes BORING and any type of repetition in life more generally naturally has the same effect on our brains! What are we doing guys? Where are we heading? What is the point? Has anyone got anything new they want or intend adding to our systems that can be provided in a way that is usable on distros forum-wide? If not, that might imply that 'our work is done'.

Pity rufwoof was such a pain, because lots of what he used to talk about isn't done well here, but he never provided any usable solutions either. Anyone who thinks any of these forum distros are better than the plenty of outside-forum alternatives is imagining things - but the potential and scope is there, but I do sometimes get the daily impression that the lights of enthusiasm and innovation are becoming gradually dimmer and involving less people, who are still present, spending countless hours 'helping' the one or two new faces that ask questions a quick Psearch would likely quickly answer many times over. Perhaps I am imagining it. Maybe woof-CE is super-active and I certainly myself wouldn't know. Maybe FatDog team have huge parties out there in the multi-verse that I know nothing about. And of course BarryK still has a few EasyOS followers, in that world I know nothing about.

Perhaps I should take up knitting - which I tried once actually - well... not the slow two knitting needle way, but when I was late teenage someone gave my family a rusty old knitting machine and I spent a month making it kind of work and somehow knitted a jersey that turned out three times smaller than it was supposed to, but used the same amount of wool detailed in the recipe (the stitches ended up so tight that you could hardly bend the sleeves like alone get a child to pull it over their head - it was supposed to be adult size jersey...).

[rockedge]

@Sofiya I recommend we install cpupower for the CPU performance tuning utility.

I feel this should be done across all KLV variants

[geo_c]

@wiak

Just a few thoughts from my perspctive as avid user and sometimes contributor of non-essential tidbits, and sometimes useful observations about missing pieces or configs:

The KL system has allowed for rapid experimentation. So at some point, artistically speaking as musician, the experimentation which is an indispensible part of the creation of useful and elegant systems, has to be focused and prioritized. It's like a table full of pieces to be assembled.

A lot of KL systems have been cranked out in a two or three year period. What's the take-away?

1) Virtually any distro can serve as the "sub-system" for a KL build.
2) Virtually any window-manager/desktop environment can be installed.
3) Numerous instances and boot managers can be utilized.
4) Persistance can be managed and manipulated.
5) Modern frameworks can be utilized (wayland, pipewire, etc)
6) Connectivity can be implemented, (bluetooth, samba, qmenu, etc)

Those are successes, but these successes somewhat "widen the war." They provide endless possibilities that blur the focus. So what's missing on a basic level?

1) Which distro sub-system should a team devote their energies at given time?
2) What desktop development should get priority?
3) How can multi-instance and boot facilities be simplified from within the running system itself?
4) How can persistance folders be simplified and managed from within the running system?
5) How can wayland and pipewire be integrated while it gains traction in the wider distro world (just heard mintOS is coming out with a wayland version)
6) What's the list of missing connectivity/functionality capabilities?

With those questions in my mind, what I see is a simple organization strategy. Maybe thinking more in a modular sense.

1) Seems to me the subsystem/distro development is the bottom modular layer to the desktop environment. And what I see happening in recent months, is both the functional subsystem being developed simultaneously with the desktop polish.

Not that both of those can't happen at the same time, but at the moment it seems to confuse the issue, as it's difficult to track what versions contain what changes, some are desktop/visual, others underlying services/funtions. So maybe while desktop polish is being done, it shouldn't necessarily be published as an iso, or build script until the subsystem is complete, functional, and tested. At that point the final functional distro can have the polished elements integrated as the LATEST and GREATEST.

2) There are a many really really nice looking desktops now available on top of KLV. Thanks @Sofiya, as that is what people experience as "their computer." It's not a trivial thing. For instance, how much interest is there in Spectr with it's basic text-based status bar, as opposed to Spectr with a polished poly-bar?

But, the challenge now I think is to "finish one off" that contains everything, or as near to everything we would like to see in a cutting edge KL distro.

So perhaps it's as simple as agreeing to choose one, KLV-airedale being the most obvious to me, though I prefer to use Spectrwm now. Airedale using Xfce being the most obvious as it's a universally friendly desktop environment. However, it's not wayland ready yet. So perhaps kicking that can a few months down the road to a new subsystem distro capable of wayland, like Swayland or another.

3&4) Starting with the most developed KL, assuming it's Airedale, the boot utilities would benefit from a user utility, or I could perhaps create splash documentation explaining the process, making installation more digestible. But what I see as the final nut to crack is the ability to backup upper_changes while running live. Though I believe this may be easy enough running w_changes=RAM2, even that approach could be facilitated for the user making it more of no-brainer, like a pupsave, though even that concept tends to confuse newcomers. The ability is there already, though maybe not obvious to a new user.

I think of Fatdog, which right out of the box explains why it's not "puppy" and your puppy assumptions won't work here. So codifying and documenting the KL structure in a quickly accessible way might be a good thing for me to tackle.

I probably have the ability to think through some of the logic involved in persistance management, just because I've been doing it manually for so long, though my scripting ability is woefully simplistic, I would still give it a shot if pointed in the right direction.

5) Migrating to wayland and pipewire is already on track, so to speed up that process, deciding on one distro base/desktop to implement it, and working that until ready to polish is another way to modularize the approach. That may mean my example of Airedale being the focus is off base, and one more suited to moving forward with wayland is appropriate.

6) I don't use a lot of capabilities many people view as necessities, screencasting, win/linux networking, bluetooth (those are always turned off on my phone, including the mic and camera) but nonetheless they are the things desired in a modern operating system. So defining and refining that list is probably the best approach. If one us, like myself, is not able to adequately implement a technology, it doesn't mean they couldn't "do some work on it" even it's just attempting and failing and asking questions.