In general, I would like to note that a rolling distribution does not necessarily always have to offer the latest packages as soon as possible. Rolling primarily only means that updates are offered gradually via the same package sources.

But this is just a general remark. :-)

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.

• ZSH (Shell)
• Ripgrep (alternative for grep)
• Bat (alternative for cat)
• Exa (alternative for ls)
• Fd (alternative for find)
• Fzf (fuzzy finder)
• Micro (editor)
• VS Code (editor)
• Jq (sed for JSON data)
• Mercurial (version control system)
• TortoiseHG (graphical interface for Mercurial)
• Terminator (terminal emulator)
• KeepassXC (password manager)
• CopyQ (clipboard manager)
• Vivaldi (browser)
• SchildiChat (matrix client)
• RSS Guard (feed reader)
• FileZilla (FTP / FTPS / SFTP client)
• Double Commander (file manager)
• Hugo (generator for static websites)
• DBeaver (database tool)
• And maybe a few others that I can't think of right now.

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.

You can follow the submissions via an RSS feed.

For example, if you use the link Https://lemm.ee/feeds/u/Corr.xml?sort=New, all your previous posts will be displayed.

Instead of lemm.ee you need to specify the instance where the user in question is registered. And instead of Corr you have to enter the username. For example https://discuss.tchncs.de/feeds/u/fryboyter.xml?sort=New. That would be in this case my contributions.

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.

• Virus scanners only detect a fraction of the harmful programmes.
• Virus scanners can often be tricked.
• Virus scanners often have security vulnerabilities themselves, which are usually quite serious, since such programmes embed themselves quite deeply in the operating system.
• Virus scanners cause many users to become careless because they rely too much on such tools.

Therefore, from my point of view, the disadvantages outweigh the advantages. Therefore, I do not have such a tool permanently installed, neither under Linux nor under Windows. However, every 6 months I scan my Windows installation with a USB-bootable virus scanner. No actually harmful programme has been found for years.

In my opinion, the following things are much more important than any security software.

• Install updates as soon as possible. Under Windows, you can use tools like Chocolatey for this.
• Only install software from trustworthy sources.
• Only install software that you really need.
• Only use root or administrator rights if you have to. For everything else, the rights of the user account are sufficient.
• Create backups regularly.
• Think before you act.

Especially the last point is a problem for many users. I can't tell you how many times I've witnessed someone receiving an alleged invoice from mobile provider A by email and opening it, even though they had a contract with provider B.

Nowadays, servers that are not connected to a monitor, keyboard or mouse are often referred to as headless. Regardless of whether they have a graphical user interface (which can be used with tools such as Guacamole, for example).

I'm not trying to say that this is correct, but simply to point out that the term "headless" is now often interpreted differently.

When it comes to SBC, the choice has always been a Raspberry Pi. Why? A Raspberry Pi may not have the best performance. But in return you can be sure that it will still be supported after a kernel update. And that is exactly the problem with many alternatives. They support a certain, mostly old, kernel. And that's it. Furthermore, the community around the Raspberry Pi is simply huge.

It's more than just a simple tool with which you can tweak audio. Some features are listed at https://valvesoftware.github.io/steam-audio/. The tool is mainly intended for the development of games (also under Linux).

And yes, it's basically just about the fact that Steam Audio is now completely open source.

Ran sudo pacman -Syu; sudo pacman -Syy like I do every few days

Syy forces the package database to be updated even if no updates are available.

In my opinion, this makes no sense, especially after you have already run pacman -Syu before. Basically, you only generate additional, unnecessary traffic on the mirror you are using. Pacman -Syu is normally always sufficient.

The journal was really long so I moved past it

The display of the systemd journal can be easily filtered. For example, with journalctl -p err -b -1, all entries of the last boot process that are marked as error, critical, alarm or emergency are displayed.

Has anyone else ran into this issue when updating?

Not me. But other users do. Some of them also use a distribution other than Arch (or a distribution based on it). When I look at the problems, the current kernel is probably quite a minefield as far as problems are concerned.

Any advice for preventing future crashes or issues like this so I don’t fear updating?

As other users have already recommended, you could additionally install the LTS kernel. And if you use BTRFS as a file system, create snapshots before an update (https://wiki.archlinux.org/title/snapper#Wrapping_pacman_transactions_in_snapshots).

And it should be obvious that important data should be backed up on a regular basis.

according to StatCounter's data

Our tracking code is installed on more than 1.5 million sites globally.

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

Such statistics are always to be taken with a grain of salt.

There are more than 1.5 billion websites worldwide. Statcounter therefore covers only a small fraction of them. So chances are good that you as a Linux user do not use any of these 1.5 million websites that Statcounter uses to create their statistics.

Furthermore, I suspect that many Linux users use tools like uBlock Origin or Pi-Hole, so that the things that are used to track users are blocked.

Apart from that, I have several Linux installations with which I never access a website. Sometimes they have no direct connection to the Internet. Thus, they are also not recorded.

But now to the most important. 3 percent of what? Percentage numbers don't tell anything if you don't know the number of users behind them. Let's assume that there were 2.8 percent Linux users in May. In June, only 2.6 percent. Nevertheless, it is possible that there were more actual users in June if the total number of all users increased accordingly.

To go x86_64-only was a mistake for Arch.

• The development team of Arch is comparatively small compared to other distributions.

• To support platforms other than x86_64 one should have access to appropriate hardware to test the packages. I for one have not had i686 hardware for a while. This is probably true for many other users as well.

Therefore, from my point of view, they have done everything right. Just like other, non-Arch based distributions, which are also now only offered for x86_64.

Distros like Fedora or Debian, or openSUSE have universal building systems and infrastructure for building packages for different architectures.

Right. And all have more collaborators and more money. For example, according to https://nm.debian.org/members/, nearly 1000 people participate in Debian.

Arch's core development team, on the other hand, consists of just 28 people without being paid for it. In addition, there are some "trusted users" (a bit more than 60 iirc) and some people responsible for support (wiki and IRC moderators etc.).

Arch just creates unnecessary fragmentation for the GNU/Linux landscape: software need to be packaged for the distro and for the same time PKGBUILDs cannot be reused in general for anything to go full Arch Linux.

Fragementation has always existed. Before Arch I had used Mandrake / Mandriva. With it I often could not use Redhat packages although they technically used the same format (RPM).

By the way, in the case of Arch or distributions based on it, you can in many cases use PKBUILD files for other platforms as well. Often it is sufficient to modify the line arch=('x86_64') accordingly. I have done this in some cases where a software for Alarm (Arch Linux ARM) was not officially offered. I simply took the PKBGUILD file from Arch Linux and changed it accordingly. And yes, this does not always work.

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.

I have several virtual machines here with Arch that I often don't use for months. And when I do use them, I proceed as I do with every update. So before an update, I check if something has been published at https://archlinux.org/news/ that affects the installation in question. This is done automatically with the help of the tool informant. If something has been published that affects my installations, I take that into account. Otherwise I run pacman -Syu as usual. And that's it.

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

Is the current SystemD rant derived from years ago (while they’ve improved a lot)?

In my experience, the same arguments against systemd (not systemD) are still used. No matter how often they have been disproved or whether the problem has been fixed in the meantime. With many users I am sure that it is only about making the project systemd bad.

Should Linux community rant about bigger problems such as Wayland related things not ready for current needs of normies?

I would prefer it if there were no rants at all. No matter what the topic. Because that doesn't help in any way. It would make more sense to invest the energy in the projects in question or in alternative projects to improve them.

If I understood it right, the author of the proposal even writes that that opt-in is useless, because nobody is going to enable it, which kinda makes it sound like they know that they’re trying to push something on users that they don’t want.

The question is, why don't users want it? I have already had a few discussions on the subject of telemetry and telemetry has almost always been portrayed as evil. Even when, for example, the transmission is encrypted and only the most necessary data is transmitted in such a way that no conclusion can be drawn about a specific user.

Is opt-out therefore a good solution? Not in my opinion. But I can understand the developers who use opt-out, for the reasons I mentioned. Because yes, telemetry can help to improve a program.

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.

How does pacman work compared to apt-get ?

Roughly speaking, pacman is faster, but offers fewer functions. And the parameters take some time getting used to. For example, you can update the system with pacman -Syu.

and how to find in which package an command lies.

You can either use the command pacman -F or the tool pkgfile.

• https://wiki.archlinux.org/title/pacman
• https://wiki.archlinux.org/title/Pacman/Rosetta
• https://wiki.archlinux.org/title/pkgfile

I am struggling a bit with Zsh, like I ended up starting bash to configure an environment variable, any ressources on-it.

Without a more detailed description of the problem, it is difficult to help you. As I have been using ZSH for many years (also under Arch), I can only say that you have done something wrong. But if you don't want to work much with the shell anyway, Bash is perfectly adequate.

But do yourself a favour and stay away from Manjaro. The team responsible for this distribution has already made so many avoidable mistakes and strange decisions that I don't trust this distribution. And I'm not alone in this opinion. If you want a distribution based on Arch, there are better alternatives. Like EndeavourOS, for example.

TIL SDDM hasn’t gotten to 1.0 yet.

Many projects also deliberately avoid publishing a version 1.0. For example, the static website generator Hugo continued with 0.100.0 after version 0.99.1. The current version is 0.123.3.

This is mostly due to the fact that some users have the wrong expectations. For example, that version 1.0 is as good as error-free and fully developed.

How long has it been the de facto default greeter for KDE Plasma?

Since Plasma 5 if I'm not mistaken. Before that, KDM was the standard.

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?

when it’s the main reason why so many people use Arch Linux?

AUR is one reason why I use Arch. But not the reason. Besides AUR, Arch has many other advantages from my point of view. Like for example the wiki that also users of other distributions use. Or the many vanilla packages. Or that you can easily create your own packages through the PKGBUILD files. Or that, based on my own experience, Arch is quite problem-free to use despite the current packages.

One reason why other distributions don't have something like AUR could be that AUR is not an official offering, so no verification is done in advance either. Somit ist es mindestens schon einmal passiert, dass jemand PKGBUILD-Dateien in böser Absicht manipuliert hat (https://lists.archlinux.org/pipermail/aur-general/2018-July/034151.html). The Wiki does not warn against the use for nothing.

However, it is much easier for the user to check the files in the AUR in advance than it is, for example, with ready-made packages in an unofficial PPA.

With https://build.opensuse.org and https://mpr.makedeb.org there are also at least two offers that are somewhat similar to AUR.

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.

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.

In my opinion, users who already use vim are not the primary target audience of Helix. I see the target group more among users who want to switch from a "normal" editor to a modal editor. The selection → action model and the easier shortcuts probably make the switch easier for many. I personally don't like vim at all because of the handling (purely subjective view). Helix will definitely not be my default editor but I get along much better with it than with vim or neovim.

I am using Borg for years. So far, the tool has not let me down. I store the backups on external hard drives that are only used for backups. In addition, I save really important data at rsync.net and at Hetzer in a storage box. Which is not a problem because Borg automatically encrypts locally and for decryption in my case you need a password and a key file.

Generally speaking, you should always test whether you can restore data from a backup. No matter which tool you use. Only then you have a real backup. And an up-to-date backup should always additionally be stored off-site (cloud, at a friend's or relative's house, etc.). Because if the house burns down, the external hard drive with the backups next to the computer is not much use.

By the way, I would advise against using just rsync because, as the name suggests, rsync only synchronizes, so you don't have multiple versions of a file. Which can be useful if you only notice later that a file has become defective at some point.

At https://blog.frehi.be/2023/04/23/the-security-risks-of-flathub/ someone has published an article about Flathub in which he addresses a few problems.

Therefore, the answer is that Flathub is not always safe to use. However, I do not know of any package source that is always safe to use. Is Flathub more insecure than other package sources? I can't answer that because I don't use solutions like Flatpak, AppImage etc. myself.

You basically have to decide for yourself what you want to use or not. In my opinion, there is no objective right or wrong.

For my part, I cannot and will not rule out that I will continue to use Reddit in some form. Just like I can't rule out that I might not use Reddit anymore. And no matter what I decide, it's my decision to make and I don't have to justify it.

I'm only referring to Arch now because I have no idea about NixOS.

Arch and NixOS Those two are in the “pain” category. I would never recommend them to anyone starting with Linux, for example because they’re fed up with Windows

In my opinion, you are making the mistake of equating all Windows users. But not every Windows user is the same.

An acquaintance of mine, who works full-time as a Windows administrator, was able to install and configure Arch manually on his first attempt, for example. But yes, other Windows users would despair.

But that's exactly why you shouldn't make blanket recommendations, but rather recommendations based on the wishes and knowledge of the person who wants to use Linux.

high demanding

Basically, you should be able to read and willing use a search engine. That's all you really need.

hard to set up and use

If you use archinstall, which has long been an official part of the Arch iso file, you can install Arch within a short time. But I don't think manual installation is very difficult either. Because if you follow the official instructions, you can simply execute many of the commands mentioned therein without having to change them beforehand.

And what do you mean by hard to use?

I've been using Arch for over 10 years, almost like any other distribution. Apart from only 3 things, 2 of which can be automated.

• Before an update, I check whether something has been published at https://archlinux.org/news/ that affects my installations. If so, that has to be taken into account. The check itself can be automated with https://aur.archlinux.org/packages/informant, for example.
• The cache of pacman must be cleaned regularly. This can also be automated with a hook (https://wiki.archlinux.org/title/Pacman#Cleaning_the_package_cache).
• From time to time, I synchronise my configuration files with the pacnew files. There are tools for this (https://wiki.archlinux.org/title/pacman/Pacnew_and_Pacsave#Managing_.pac*_files)

requiring the user to be skilled and to know what he’s doing

Not necessarily. The most important thing is that the user is willing to read, that he is willing to use a search engine and that he is willing to learn something new. And that is often the problem these days.

And shall I tell you something? Even after several decades with Linux, I often have no idea what I'm doing. But I'm still trying to acquire new knowledge.

don’t hold the users’ hand

I agree with you here. Arch is, among other things, intended for users who want to solve their problems themselves. But that doesn't mean that you can't get help. However, it is expected that you first try to solve your problems yourself. And if that doesn't work, you should ask smart questions. However, this guide does not only help with Arch. Basically, it is (even if it is now partly outdated) still one of the most important pieces of knowledge you can have.

and don’t tolerate user error well.

I have been using Linux for over 20 years and have therefore already used several distributions. Basically none of them tolerate errors. If I make a mistake when configuring Alacritty under Ubuntu, for example, basically the same thing happens as under Arch.

Edit: Please don't take this post the wrong way. My point is not to claim that Arch is like Ubuntu, for example. But these myths that have formed around Arch (e.g. that you can only learn Linux properly with Arch (which is complete nonsense)) are a bit annoying.

There is no such thing as the objectively best solution. Each tool has advantages and disadvantages. And every user has different preferences and requirements.

Personally, I am using Borg for years. And I have had to restore data several times, which has worked every time.

In addition to Borg, you can also look at Borgmatic. This wrapper extends the functionality and makes some things easier.

And if you want to use a graphical user interface, you can have a look at Vorta or Pika.

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.

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.

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.

FOSS is all about giving some things for free, and thats it.

I would disagree with that. Free as in freedom, not as in free beer. The GPL as an example even encourages to charge as much as you want or can for the software.

https://www.gnu.org/philosophy/selling.en.html

https://www.gnu.org/philosophy/free-sw.html.en

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.

That would be my recommendation as well. I've been using a Zowie mouse on Linux for years now.

However, the switches with which you can make the changes are at the bottom of the mouse. Changing the DPI, for example, with one click is therefore not possible. For some users, this is apparently a problem, for whatever reason.

Issues on Github consist not only of bug reports, for example, but also of feature requests. If, for example, you only display issues with the label "Enhancement" at https://github.com/Eugeny/tabby, there are already over 300 of them. In addition, I have made the experience that often reported issues arise from Layer 8 problems. And that some issues, unfortunately, are not closed when they are outdated. Generally speaking and not related to this terminal emulator.

By the way, according to https://github.com/vim/vim/issues, the editor vim has over 1,300 issues. Also in this case, not all of them are actual problems that need to be fixed.

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.

Unbound can be configured to make requests directly to the DNS "root server" . These should not be censored. The guide linked by surfbum explains this accordingly.