I have no experience with this project. I have been using a mouse from Zowie for several years under Linux, where all settings can be made with switches on the mouse so that no software is necessary.

https://github.com/keepassxreboot/keepassxc/issues/7774

https://github.com/keepassxreboot/keepassxc/pull/10267

and if IIRC widgets and plasmoids work differently now.

https://develop.kde.org/docs/plasma/widget/porting_kf6/

https://develop.kde.org/docs/plasma/theme/theme-porting-to-plasma6/

So basically what KDE has done with Plasma 6 onwards. Wayland is standard, but you can still use X11 if required.

An understandable decision. At some point you have to start switching to Wayland.

Have you already checked whether xwayland is still installed? And have you tried to start the program using QT_QPA_PLATFORM=xcb your_program?

In the meantime, I have installed the update to Plasma 6.0.1 on my notebook. There were no problems and so far everything is working as it should.

On Arch Linux, Plasma 6.0.1 was released a few minutes ago in the testing package sources.

I am curious if this version will reach the official repositories or if there are still reasons to delay an official release.

Edit: That went faster than expected. Plasma 6.0.1 has been moved from Testing to Extra.

Earlier, the link to the changelog at https://kde.org/announcements/plasma/6/6.0.1/ did not work, but the one I used did. In the meantime, the link at https://kde.org/announcements/plasma/6/6.0.1/ works and the one I used does not. I assume that someone from KDE has adjusted the link in the meantime.

I have updated the link accordingly.

Here are the things I’ve gathered are non-cosmetic:

Based on https://kde.org/de/announcements/megarelease/6/, I think that many more things are not just purely cosmetic changes.

I must be missing something.

I would say you simply have the wrong expectation that with a so-called mega release a lot of big changes have to happen that the user has to notice immediately. However, many of the changes in Plasma 6 are probably not huge. But many smaller changes are also many changes.

And as others have already written, the changeover to QT 6 was probably not an easy task.

I also see Plasma 6.0 as a basis for things that are planned in Plasma 6.1 or later versions, for example, and are therefore not yet visible to the user. Articles on the development of Plasma are regularly published at https://pointieststick.com, which provide a more detailed insight into the development process.

As always, such statistics should be treated with caution.

What methodology is used to calculate Statcounter Global Stats?

Statcounter is a web analytics service. Our tracking code is installed on more than 1.5 million sites globally.

Source: https://gs.statcounter.com/faq#methodology

It is assumed that there are more than one billion websites worldwide. It is therefore not exactly unlikely that a Linux user will not access any of these 1.5 million websites.

Furthermore, it is quite common for Linux users to use tools such as Pi-Hole that simply block such statistics scripts. This means that these users would not be counted even if they accessed one of these 1.5 million websites. For my part, I also use computers with Linux that I don't use to access websites. Some of these computers don't even have access to the Internet. They are therefore not counted either.

Finally, let's come to the most important point. Percentage values say not much if you don't know the actual number of users behind them. Let's assume, for example, that 3.5 per cent Linux users were detected in December and only 3 per cent in January. However, if the total number of users was higher in January, it is therefore possible that more users were detected in January.

Having automatic updates as opt-in by default would be better to avoid supply chain attacks.

I guess the majority of users would prefer automatic data synchronization. The tool therefore offers the option of deactivating automatic synchronization (https://docs.atuin.sh/configuration/config/).

Also, if the original history file is still there it would be a good feature to be able to diff between the sqlite and the history file to see if commands have been deleted.

A solution can probably be created with https://docs.atuin.sh/reference/list/ in conjunction with a shell script.

Are there options to choose what encryption algo is used?

I suspect that this is not possible. Why do you want to change the type of encryption?

Based on https://docs.atuin.sh/configuration/config/#search_mode, "fuzzy search" is used as standard.

I don’t have any use-case for a tiling window manager, for example, but I have zero intention of shitting all over various TWM projects whenever they’re brought up.

I feel the same way. I think tiling is useless (for me). Except in the terminal emulator. Strangely enough, I use it there.

I understand that Gnome kinda goes against the traditional desktop paradigm

Which is not a bad thing at first. Just because something has been done for years doesn't necessarily mean it's better.

The Helix editor, for example, uses the selection → action model. With vim, it is exactly the opposite. That's why I prefer Helix. And yes, this is my own subjective opinion.

You can find idiots in every group. Usually, however, these are always just the loud minority. I bet the majority of users simply use what they want and stay completely out of any discussions.

For my part, I have always used KDE / Plasma and I will continue to do so. Gnome just doesn't appeal to me. Is Gnome therefore bad? No. I just prefer something else. Just like I use a different editor instead of vim, for example.

A dual boot system is not a big problem as long as you boot in EFI mode and use GPT partitions. I have been running a dual boot system (Windows 10 and Arch Linux) for years without any problems.

You should allocate around 500 MB for the EFI partition. This allows you to install Windows and a Linux distribution and still have reserves if you want to install additional Linux kernels, for example.

If you want to change partitions, first make a data backup on another data medium. Because something can always go wrong. Even if it's just a power failure.

While Arch does it too, they prefer to keep the packages as vanilla as possible - often requiring effort of the user’s side to make it work with the rest of the system

To be honest, I have hardly ever had this experience. In my opinion, the distribution works so well precisely because Arch releases everything vanilla wherever possible. And in cases where the vanilla version doesn't work, the Arch team patches it.

So the thing with Debian and any Debian based distro like Ubuntu or Linux Mint is there is no big centralized software repo like the AUR.

The platform for this would be available (https://mpr.makedeb.org).

Yes there is the apt repository but if you want something that’s not in there, get ready to read the documentation or follow random guides.

Not everything is available in the AUR either. It may therefore be necessary to create a own PKGBUILD file. And since anyone can publish something in the AUR, you should check the PKGBUILD file before installing or updating it. Both also require reading guides (https://wiki.archlinux.org/title/Arch_User_Repository, https://wiki.archlinux.org/title/PKGBUILD and so on).

On Arch, all I have to do is Paru -S Reaper,

This would give me the error message that the command was not found. Why do some people assume that everyone uses the same AUR helper as they do? I use aurutils, for example. This AUR helper offers more options but is more cumbersome to use in some cases.

Apart from that, the name of the package is reaper and not Reaper. So even if I would use paru, it would not work.

Now that Arch is so easy to install with the Archscript,

Easier? Yes. But archinstall had and still has some bugs. And archinstall, understandably, does not cover everything so that a manual installation is more flexible.

yeah yeah there’s flathub and stuff but that’s more of a last resort, optimally, you want to get it the correct way.

Appimages or flatpaks are often the correct way to go, as many projects only publish such packages.

If I had to guess, I would say that the updates to Plasma 6 will be offered at the end of the week or in the course of next week. But I'm not an Arch developer, so that's really a guess.

However, one should first read through https://wiki.archlinux.org/title/official_repositories#Testing_repositories and consider whether it is really worth the risk.

For my part, I will simply wait until Plasma 6 arrives in the official package sources.

and I’m glad that they took extra time to release rather than quickly shoving it out, a la Plasma 4 and early Plasma 5.

As far as I can remember, this was also the fault of some distributions that wanted to release Plasma 5 quickly, even though the developers of Plasma pointed out existing bugs.