@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.
