After 12 thousand years.

That’s interesting. But man, the project name is not very memorable.

It is not irrelevant to me and I made it multiple times clear. Its a suggestion by me, regardless of what terminology you use or the team uses. The desktop edit change is a big change which I suggest not to do for a year. Only bug fixes and small changes that enhance and improve usability. The desktop edit change is a huge change for the developers and for the end user, with lot of background changes to make it work correctly, with lot of fixes after it.

Something that complex is not a small change and is not irrelevant for the topic I brought up. I made it multiple times clear now, I don’t know why you are still act like this. It’s not a definition of a term we are trying to agree, I don’t care the term.

I don’t agree with you and explicitly listed it in my first reply as an example of what I consider a big change.

You misunderstand me. They can write new code and be ready when the bug hunting phase is over. The end user only gets bug fixes. Later they can backport any new feature after the phase.

https://wiki.archlinux.org/title/Installation_guide

I guess you meant this as a joke, but for clarification, I meant no big changes such as new desktop edit mode. I wish the team would just focus of bug fixes and enhancements without introducing new elements or changing things up in a big way like this.

deleted by creator

deleted by creator

I wish the team would just spent an entire year of bug fixing and refining user experience without adding new features or making big changes such as the new desktop edit mode. Don’t get me wrong, this is super exciting too, but for the complex nature of KDE it would be good if they keep a bit of focus after a major release.

It just came to my mind, that WINE not only stands for Wine Is Not an Emulator, but also could be interpreted as: WINdows Emulator.

The image does not doing a particularly good job in explaining whats wrong with X. It just shows how it functions and why a rewrite in Wayland is needed.

By that description, Ubuntu does the same, matching the release cycle of non LTS Ubunu versions; every 6 months with breaking changes (just like Fedora). The difference to Fedora is, that Ubuntu users do not need to upgrade to the next major version, while Fedora have to, because there is only one version.

Tiling: Add fallback path for the first Polonium tile. Commit. Fixes bug #488898

I’m a little bit surprised or confused here. Polonium is an external script. KDE/Kwin specifically addresses scripts? That’s actually wonderful, totally the opposite of what Gnome does (yes, I had to bring it up).

I stopped using Polonium, as it does not work perfectly fine for me. I’ll let them cook a bit more, its otherwise an excellent script/addon.

There is no single Bash standard to follow, only a few guidelines. One way you can check for some basic errors and formatting would be using an editor with support for Bash (in best case with a builtin LSP). At the end, you have to find your style and coding standards or adapt what others do if you want work with them or edit their files.

• Otherwise there is a well known tool for checking Bash files: https://www.shellcheck.net/ You can use it online and as a downloaded program on your local machine. After using shellcheck for a bit I got used to some of its conventions and recommendations, such as always wrapping variables like in ${variable} and some other things.
• Google has a coding style guide, but not everyone likes it: https://google.github.io/styleguide/shellguide.html
• Related is the Bash Reference Manual from GNU: https://www.gnu.org/software/bash/manual/bash.html Off course this is not a guide on how to style or program, but it helps in understanding how GNU does things.

BTW the mk-blog link is 404 for me.

How are the packages more tested than on Arch? Both systems have multiple testing stages in place, doesn’t it? In Archlinux there are 2 more stages before it lands on the actual end user. Sometimes one has to wait long time, in example for me RetroArch was updated after 6 weeks after official release. That’s not bleeding edge at all. Only the system core files get updated extremely quick. But that’s only about updating new packages.

The “leading edge” term of Fedora is about a total different aspect. It’s leading, because Fedora adopts certain technologies first, before even Archlinux adopts it. In example Pipewire. Archlinux waits a bit before the technology is adopted widespread, while Fedora is leading and adopting it early. And that has nothing to do about how often the packages itself get updated. People often mixup these two things (and so I did probably).

I wouldn’t be confident in recommending Fedora to noobs, because its a distribution that is on the bleeding edge side. But it depends on what type of noob we are talking about. There are noobs in Linux, who are technically well versed in Windows and have no problem in adapting to a new system. If someone wants to have the newest software, then Fedora might be it.

Also not many people have experience with Fedora, therefore less likely to be recommended. Most people use or used Ubuntu, maybe even started with Ubuntu. You or me may not like it, but its proven that Ubuntu is generally a good choice for newcomers to get into Linux. And that also plays into how many people know and are able to help. In contrast, Fedora is too much of a niche.

Nintendo should get sued for trolling. And if we are at it, sue Nintendo for using ideas and art styles from other games as well.

What’s been a bit disappointing is DEs getting on the wayland train so late. A lot of the kinks could have been worked out way earlier if they had given their 2ct of feedback right from the start, instead of waiting 10 years to even start thinking about migrating.

That’s the real issue. And its worse with Gnome, as Gnome doesn’t want support “all of” Wayland and its protocols. That means Wayland will be broken on Gnome, despite Gnome being the most used DE (at the moment). People complain about the problems in Wayland, but not all problems are caused by Wayland itself.

However there were or are two big reasons I can think of why Wayland wasn’t adopted early and for some may never: a) its much harder to be Wayland conform, because the window manager/DE has to do much more work, b) Wayland was just not ready before, as many important aspects were missing (in example some basic protocols, Nvidia) or broken. I don’t blame them. For the record, I am not a Wayland chill, just talking about this, because there are many misconceptions (me included, I’m not perfect) and switched to Wayland just end of last year. Before that Wayland did just not work for me. I even switched from Qtile to KDE, because KDE has probably the best Wayland support (I hate manual window management).

Edit: I just remembered another reason why Wayland wasn’t probably adopted early. Canonical/Ubuntu started a Wayland alternative called Mir (that was before Mir transformed into a Wayland compositor). And devs probably didn’t want set on Wayland or Mir before knowing what will be around in the future.

Wayland kinda is an x.org project in the first place.

Not really. Wayland is fundamentally different from Xorg. Otherwise we would not need Wayland and create X12. It’s like saying mechanical hard drives are kind of Solid State Drives, just because they allow to do something similar. Even if the developers are the same, does not mean the technology is.

AFAIK it’s officially organised under freedesktop but the core devs are x.org people.

I’m not sure if this is correct. But let’s assume this is correct. Why does it matter? If Wayland was developed by different people than those who maintain Xorg at the moment, would not change the fact that we need Wayland, because it is different and solves issues that cannot be solved with Xorg without rewriting it. And nobody wants to rewrite Xorg or understand the code (other than very basic security maintenance).