These days, I often hear a lot about Wayland. And how much of effort is being put into it; not just by the Embedded world but also the usual Desktop systems, namely KDE and GNOME.
In recent past, I switched back to KDE and have been (very) happy about the switch. Even though the KDE 4 (and initial KDE 5) debacle had burnt many, coming back to a usable KDE desktop is always a delight. It makes me feel home with the elegance, while at the same time the flexibility, it provides. It feels so nice to draft this blog article from Kwrite + VI Input Mode
Thanks to the great work of the Debian KDE Team, but Norbert Preining in particular, who has helped bring very up-to-date KDE packages into Debian. Right now, I’m on a Plamsa 5.21.1 desktop, which is recent by all standards.
Almost all the places in the Linux world these days are busy with integrating Wayland as the primary display service. Not sure what the current status on the GNOME side is but I definitely keep trying KDE + Wayland with every release.
I keep trying with every release because it still is not prime for daily use. And it makes me get back to X11, no matter how dated some may call. Fact is, X11 still shines to me as an end-user.
Glitches with Wayland still are (Based on this week’s test on Plasma 5.21.1):
- Horrible performance compared to X11
- Very crashy, especially when hotplugging secondary display. Plasma would just crash. X11 is very resilient to such things, part of the reason I can think is the age of the codebase.
- Many many applications still need to be fixed for Wayland. Or Wayland needs to accomodate them in some way. XWayland does not really feel like the answer.
And while KDE keeps insisting users to switch to Wayland, as that’s where all the new enhancements and fixes are put in, someone like me still needs to stick to X11 for the time being. So to get my shiny new
LG 27" 4K Monitor (3840x2160 60.00*+) to work without too much glitch, I had to live with an alias:
$ alias | grep xrandr alias rrs_xrandr_lg='xrandr --output DP-1 --mode 3840x2160 --scale .75x.75' 18:31 ♒ ॐ ♅ ♄ ⛢ ☺ 😄
On the brighter side, the Plasma 5.21.1 release brings some nice enhancements in other areas.
- I’m now able to make use of tighter integration with systemd/cgroups, with better organization and management of processes overall.
- The new Plasma theme, Breeze Twilight, is a good blend of Light + Dark.
I also appreciate the work put in by Michail Vourlakos. The KDE project is lucky to have a developer/designer like him. His vision and work into the KDE desktop is well beyond a writing by me.
$ usystemctl status plasma-plasmashell.service ● plasma-plasmashell.service - KDE Plasma Workspace Loaded: loaded (/usr/lib/systemd/user/plasma-plasmashell.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2021-02-26 18:34:23 IST; 13s ago Main PID: 501806 (plasmashell) Tasks: 21 (limit: 18821) Memory: 759.8M CPU: 13.706s CGroup: /email@example.com/session.slice/plasma-plasmashell.service └─501806 /usr/bin/plasmashell --no-respawn Feb 26 18:35:00 priyasi plasmashell: qml: recreating buttons Feb 26 18:35:21 priyasi plasmashell: qml: recreating buttons Feb 26 18:35:49 priyasi plasmashell: qml: recreating buttons Feb 26 18:35:57 priyasi plasmashell: qml: recreating buttons 18:36 ♒ ॐ ♅ ♄ ⛢ ☺ 😄
OBS - Open Build Service
I should also thank the OpenSUSE folks for the OBS work. It has enabled the close equivalent (or better, in my experience) of PPAs for Debian. And that is what has enabled developers like Norbert to easily and quickly be able to deliver the entire KDE suite.
OBS - Some detail
Christian asked for some more details on the OBS side of things, of my view. I’m updating this article with it because the comment system may not always be reliable and I hate losing content.
Having been using OBS myself, and also others in the Debian community who are making use of it, I surely think we as project should consider making use of OBS.
Given that OBS is Free Software, it is a perfect fit for Debian. Gitlab is another example of what we’ve made available in Debian.
OBS is divided into multiple parts
- OBS Server
- OBS DoD service
- OBS Publisher
- OBS Workers
- OBS Warden
- OBS Rep Server
For every Debian release I care about, I add an OBS project per release. So I have OBS projects for: Sid, Bullseye, Buster, Jessie.
Now, say you have a package,
foo . You prep your package and enable all the releases that you want to build the package for. So the same package gets built, in separate clean environments, for every release I mentioned as an example above. You don’t have to manually trigger the build for every release/every architcture. You should add the release (as projects) in OBS, set their supported architectures, and then add those enabled release projets as bits to your package.
Every build involves:
- Creating a new chroot for each build
- Building the package
Builds can be scattered across multiple hosts, known as workers in OBS terminology. Your workers are independent machine entities, supporting different architectures. The machines can be Bare-Metal ones, VMs, even containers. So this allows for very nice scale-in and scale-out. There may be auto-scaling too but that is something worth investigating.
Think of things like cross architecture builds. Let’s assume the cloud vendors decide to donate resources to the Debian project. We could enable OBS worker instances on the respective clouds (different architectures) and plug them into the master OBS instance that Debian hosts. Fully distributed. Similarly, big hardware vendors willing to donate compute resources could house them in their premises and Debian could just easily establish a connection to them. All of this just a TCP connection away.
So when I look at the features of OBS, from the point of view of Debian, I like it more. Extensibility won’t be an issue. Supporting a new Debian release would just be a matter of bootstrapping the Debian release as a project in OBS, and then all done. The single effort of setting of the target release project is a one time job, and then all can leverage it.
The PPA was a long craved feature missing in Debian, in my opinion. OBS allows to not just fulfil that gap but also extend it in a very easy way.
Andrew Lee had put in a nice video presentation about the same @ Debconf 20