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.
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.
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.
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.
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.
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.
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.
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.
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.
To go x86_64-only was a mistake for Arch.
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.