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.

A small ultrasonic cleaner does wonders for getting glasses clean. Just use a couple drops of dish soap in the water and they’ll come out like new.

Nope, not at all. Silverblue here (GNOME), and the upgrade went smooth, nvidia drivers and all.

Yeah, I’ve always found terms like “content” (and by extension “content creator”) to be degrading and corporate-focused. It’s weird to me that it’s such a common way to refer to the work of artists and entertainers online. I don’t do anything of the sort, but it’s got to be rough being pushed so hard into chasing the algorithms to stay relevant.

I’ve yet to be disappointed in anything TWRP’s put out.

I think they got the nvidia driver accumulation thing straightened out. On Fedora 40, I had it automatically remove a bunch of older versions and now it only lists the 64 and 32 bit versions I expect it to.

$ flatpak list | grep nvidia
nvidia-550-76	org.freedesktop.Platform.GL.nvidia-550-76		1.4	system
nvidia-550-76	org.freedesktop.Platform.GL32.nvidia-550-76		1.4	system

Edit: looks like it’s fixed by this.

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.

See Here for more info

/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

If you’re using universal blue images, that comes built into the image (at least on nvidia images for sure). To get rid of it, you’d have to use rpm-ostree override remove to get rid of it.

As far as I’m aware, CloudLinux is based on CentOS for older versions, and Alma Linux for newer versions, so it would be in the RHEL sphere of things.

They’re also the company that launched and continues to sponsor Alma Linux, a community run RHEL compatible distribution.

I’m not sure about using xml files, but there’s also a ‘picture-uri-dark’ key you need to set instead if you’re using dark mode. I have a similar setup with a systemd user timer that runs every 5 minutes.

Edit: I just tried it out in the terminal and it works ok for xml files, too. Also, I try to avoid parsing the output of ls in scripts. You can use find instead, something like

find $wallpath -name '*.xml'

should work.

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.

You might like King Diamond – Sleepless Nights. Really anything King Diamond or Mercyful Fate, especially off the Songs for the Dead Live tour.

Oh yeah, these guys have some crazy energy they give off. Their live performances are very much like this video, really. Not many bands give you a nunchaku solo.

Not quite the same issue, but similar in the sense that it was caused by a UEFI that didn't conform to spec.

I have an HP laptop that I installed Debian on, and it would never actually boot to grub even though I checked the boot entries several times over. You could open the settings and choose the boot entry manually, so it's not like it was a problem with the OS or with grub. Turned out, this model was hard coded to only allow a boot entry named "Windows Boot Manager" to be loaded by default. I used efibootmgr to rename the debian entry and it booted into grub straight away.

I think you have to put them in your display name, alongside your actual display name.

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.

It definitely takes a bit to get used to that, especially on the exhale. I found that it became better over time, especially once I was able to stop focusing on the mask and my breathing. I don’t use the ramp up personally, as I find it more comfortable for me. Definitely keep at it, and you should be able to talk to your provider if you keep having issues. I had to go through a few settings/mask types to find the right one.