KLV-Spectrwm-CE-2.0 Using PipeWire

[Sofiya]

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

I feel this should be done across all KLV variants

this is all installed at the moment in the build plugin

viewtopic.php?p=102027#p102027

[Sofiya]

If you want to keep up with “fashion”, figuratively speaking, then you will never keep up with it. Since there are, let’s say, 15 people developing there and everyone doing their own thing... some with design, some with code, etc. Or 2 people trying to do something

[williwaw]

connetivity to arm based devices?
move to developing for arm based devices?

[Sofiya]

I will reduce the thickness of the colored lines of the lower part of the "Polybar ", I think it will be prettier

[geo_c]

I will reduce the thickness of the colored lines of the lower part of the "Polybar ", I think it will be prettier

Those colored lines are my favorite part of the system, it makes for complimentary colors in the rest of the themes I have going.

[wiak]

@wiak

Just a few thoughts from my perspective
...
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 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.
...
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.
...

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 created splash documentation explaining the process, making installation more digestible.
...
I think of Fatdog, which right out of the box explains why it's not "puppy" and you're puppy assumptions won't work here. So codifying and documenting the KL structure is a quickly accessible way might be a good thing for me to tackle.

Actually, I think such a good job been made polishing user interface side of Spectre, that's the best one to focus on in that sense right now

Yes, soonest, your items 4 and 6 seem priority matters. Difference there is that dev work done on these items usefully applies to all KLV distros and much of it to most any KL distro. It is a different kind of polish, which remains somewhat lacking at the moment. Wow, I'd love to see that more complete...

As for arm processor version. Yes, that would be a very nice addition. I don't myself have any suitable arm hardware or probably would have implemented the arm variant of core build system way back. Whether any issues there I don't know, but optimistic there shouldn't be too much difficulty.

I an truly getting on with packing house for big move right now, but I do imagine that by March next year I'll be more focused myself and sooner or later get myself a Raspberry device just so I can enjoy that experiment. But priority to me really would be your items 4 and 6 with, as I suggested, a powerful implementation for all KL on superior ease of use connectivity, which is certainly a huge almost vacuum involving virtual machines as an important constituent.

As you suggest xfce is likely to become wayland ready eventually, so that will likely just happen without us needing to worry about it.

[Sofiya]

---

[Clarity]

@williwaw

... for arm processor ...

I have never tested with an ARM in over a decade, but QEMU creates an ARM VM if that is instructed via a stanza for ARM versus x86_64.

Just an idea.

[dimkr]

@Clarity You're not really testing anything if the distro is rebuilt for ARM and you boot it in QEMU. GCC, binutils, etc' support ARM, no question about that. The main challenge with ARM support is not recompiling everything for ARM but supporting more than one board. Many boards require a custom kernel, custom drivers (proprietary or out-of-tree) or a custom boot loader with its own configuration files and expected file system layout. And it gets worse, because even if you tick all boxes, some boards have slightly broken drivers (so they can't use Wayland, or can't run game x or game y), or VA API doesn't work unless you tweak this or that, or have faulty USB hardware that causes the boot device to disconnect on suspend ... Raspberry Pi is ahead of the rest in terms of upstreamed kernel and graphics stack patches, and the situation is much better than it used to be (the manufacturer's OS, which carries all of its patches, is no longer the only option), but it still has some quirks like its own boot loader thing (rather than something standard like UEFI). And ... even if you invest the time in adding support for a board, every board adds more maintenance cost: I ported a distro to an ARM board where some GCC versions cause it to boot to a black screen, and stabilization work for it blocked work on other things.

[wiak]

It does seem that ARM support, aside from hobby Rasberry Pi stuff, isn't particular important in the Linux world. Indeed all the dreams of Linux on phones has never come across as particularly important. Fact is a smartphone is just too small and difficult to type on for Linux to even feel slightly comfortable on it. We crave Linux I suppose, but on a tiny phone?... really... just a novelty that isn't so nice once you try using it in on such a device seems to me.

Of course if the likes of Intel/AMD processors vanished and all future 'computers' used some more standardised version of some ARM processor all would change and Linux on ARM would become important. But I think it isn't. Who knows the future or what processors that future will bring (or perhaps just interfaces into our brains... help...)?

[williwaw]

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!

When I suggested supporting ARM devices, it was to this comment that the suggestion was addressed.

Indeed all the dreams of Linux on phones has never come across as particularly important. ... just a novelty that isn't so nice once you try using it in on such a device seems to me...........Of course if the likes of Intel/AMD processors vanished and all future 'computers' used some more standardised version of some ARM processor all would change and Linux on ARM would become important.

but that is whats happening, and if the market goes that way, then thats where the devlopment needs to go if more are to become involved.

[Clarity]

There is nothing wrong with ARM or any other of the RISC processors that are headed. But, there will be growing pains. There are a couple of ARMs distros on this forum. But as the numbers show, the interest is very small/absent for those forum distros. AS such, it appears that has to be sizable growth in member use, even their ARMs with the forum's offering for a growth in development to occur. Have you tried the current forum ARM distros @williwaw ? If so, what can you report?

This forum's bulk (more/less 100%) of all membership is using OLD x86 technologies even as ARMs have been around for a decade.

The issues are those stated in this thread and I have to agree. Having studied Android (on ARMs) development a decade ago, the problems surfaced during those times exist with ARMs today across the spectrum from TVs to mini-phones.

With X86, the technology has a 40 year head-start and is well understood, developed to/for, and utilized by users across the spectrum of operating systems.

I have an ARM pico that I cannot give away. It is just too slow and its OS is underdeveloped for my practical use. It has good hardware, but my x86s are better suited for my use cases.

[geo_c]

I'm in the process of getting up to date with a few things, namely installing and loading KLV-airedale-RT7, KLV-airedale-SR7, and KLV-Spectrwm-CE-2.0, which seems to need to be built from the script.

So I'm just checking on the status of this script. Is the one in the original post here the most up to date build script?

I'll be installing these multi-instance style so as to fine tune them incrementally.

[rockedge]

@geo_c I just built one to test out my new kernel 6.6.0-rock-rt15 which is full real time, has a few tweaks and added support for ASUS machines power management modules. Seems okay though I have an slightly different Spectr-RT I work on. Perhaps I could make an ISO of the CE-2 version with the new RT kernel or the latest Void kernel. Have to see how the day goes....

[geo_c]

@geo_c I just built one to test out my new kernel 6.6.0-rock-rt15 which is full real time, has a few tweaks and added support for ASUS machines power management modules. Seems okay though I have an slightly different Spectr-RT I work on. Perhaps I could make an ISO of the CE-2 version with the new RT kernel or the latest Void kernel. Have to see how the day goes....

No hurry, I won't be doing it today, but probably in the next week or so.

[Sofiya]

[Sofiya]

[elexzar]

Have you checked out the KLV-Spectrwm-CE-2.0? It’s a game-changer for anyone needing precise and efficient light measurement. It provides accurate readings for both lumens and lux, making it perfect for comparing throw vs. flood in lighting setups. I highly recommend it for clear visual understanding!

[geo_c]

Have you checked out the KLV-Spectrwm-CE-2.0? It’s a game-changer for anyone needing precise and efficient light measurement. It provides accurate readings for both lumens and lux, making it perfect for comparing throw vs. flood in lighting setups. I highly recommend it for clear visual understanding!

How do you mean it provides accurate readings? Do you mean if there is a light meter attached? Or do you mean how it displays?

I use KLV-spectr as a daily driver and I've said here many times that somehow it has the clearest and cleanest looking colors and display, but couldn't really put my finger on why that would be.