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.

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.

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.

I'm happy with how my Lugia turned out. I got a small Pikachu snuck in there as well.

It's looking good so far! There's lots of pretty cool projects going on there, too.

I think they'll still be compliant as long as they offer their source to customers. The GPL doesn't require that you make source available to anyone, but to anyone that you distribute binaries to. From the GNU website:

One of the fundamental requirements of the GPL is that when you distribute object code to users, you must also provide them with a way to get the source.

Source: Quick GPLv3 Guide under the More Ways for Developers to Provide Source section.

Of course the GPL also allows redistribution of source code, and Red Hat seems to want to threaten customers who do so.

When I say we abide by the various open source licenses that apply to our code, I mean it.

So he's saying that Red Hat intends to abide by licenses such as the GNU GPL, and yet...

Simply rebuilding code, without adding value or changing it in any way, represents a real threat to open source companies everywhere. This is a real threat to open source...

Red Hat is claiming that redistribution (which is explicitly allowed and encouraged by the GPL) is a threat to open source. They are also threatening to penalize customers who do exercise the rights granted to them by the licenses that Red Hat claims that they will "abide by".

According to Red Hat the GNU GPL is a threat to open source. And they think this won't make people angry?