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.
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.
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.
How do you notice that you are not really awake yet? By thinking for several minutes about what LXD has to do with containers and then realising that you yourself had LXDE in mind.
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.
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.
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.