No, it’s a side effect of how everything’s handled by rpm-ostree currently, and it’s on the list of issues to be fixed.
No, it’s a side effect of how everything’s handled by rpm-ostree currently, and it’s on the list of issues to be fixed.
/etc is writable, so no reboots are required. That said, /etc is treated in a special way and each deployment will have its own /etc, based on the previous one.
So if you make changes to /etc then revert to a previous deployment, your changes will be reverted as well. But if you make changes and upgrade (or do whatever to create a new deployment), your changes will bu preserved.
Looks like you’re on Fedora Silverblue (or other Atomic version). This is happening because the system groups are in /usr/lib/group rather than /etc/group and this causes the issue you’re seeing here. You can work around it by getting into a root shell with something like
sudo -i
and then getting the group added to /etc/group with
grep -E '^dialout' /usr/lib/group >> /etc/group
after that, you’ll be able to add your user to the group with
usermod -aG dialout pipe
The Mineclone2 game for Minetest is pretty solid, and it’s got most of what Minecraft has, it seems. My son and I play it pretty often.
As far as I’m aware, the Truecrypt backdoor thing was speculation regarding the termination of the Truecrypt project, but it was not confirmed. You can see here that development of Truecrypt ceased in 2014. Veracrypt was forked around that time. As for whether or not you can trust it, you’ll want to evaluate the audits that have been performed and decide if you trust them. You can find a link to what seems like the latest audit here.
Truecrypt is abandoned, and has vulnerabilities that will not be fixed. Veracrypt is a fork of Truecrypt that is still actively maintained.
I always try to consult the man pages for these kind of questions (you can search by typing ‘/’ in the man page). Here’s what the systemctl manual has to say in the specifications for the
--force
option:Note that when --force is specified twice the selected operation is executed by systemctl itself, and the system manager is not contacted. This means the command should succeed even when the system manager has crashed.