You could always swap out crons, syslog, init systems, and it would not affect Gnome.

That just isn't true. Both GNOME and KDE already have hard dependencies on systemd-logind. GNOME hasn't supported non-systemd Unixes since 2015! The only reason it works is that the elogind project provides a systemd-logind implementation decoupled from the rest of systemd. The GNOME team has elected to give users of elogind (despite not being officially supported) advance warning that they'll have to do some amount of extra work in the future if they want to ship GNOME 50. Honestly I think that's quite fair of them.

There are more GNOME features that don't work without systemd even if it launches, like application isolation using systemd scopes. Fundamentally this is about not having to reinvent the world. Why should every DE have bespoke implementations of user, login and service managers instead of just using the ones that 99% of user systems already have?

There's an argument to be made that system software like filesystems and kernels shouldn't get too smart about validating or transforming strings, because once you start caring about a strings meaning, you can no longer treat it as just a byte sequence and instead need to worry about all the complexities of Unicode code points. "Is this character printable" seems like a simple question but it really isn't.

Now if I were to develop a filesystem from scratch, would I go for the 80% solution of just banning the ASCII newline specifically? Honestly yes, I don't see a downside. But regardless of how much effort is put into it, there will always be edge cases – either filenames that break stuff, or filenames that aren't allowed even though they should be.

Pano perhaps? It doesn't show up at the cursor but you can search in it, the keyboard works the way you would expect and it auto inserts on selection.

To be fair showing the overview on startup makes perfect sense on vanilla gnome, it's only dumb if you install one of the two specific extensions that partly replace it.

Running poweroff is one of the correct ways on anything Systemd (details). If that doesn't work then something is broken.

If you haven't done so already try looking into the journal. sudo journalctl -b -1 -e will take you to the end of the log for the last boot.

Yeah some people seem to have this expectation that there should just magically be a button to unbreak the PC. They talk about their personal pain points when using Linux as if there's a conspiracy of devs to hide the unbreak buttons for the sake of elitism, but that... just isn't a thing? If it was that easy to fix an issue, you probably wouldn't need to fix it because the system would already come unbroken by default. I sympathize with everyone's Bluetooth configuration woes but mostly it's a pain in the ass because Bluetooth, in general, is a pain in the ass, not because of elitist devs (who I should mention are doing this in their free time for no pay. There's almost no money in desktop Linux, unlike in servers).

kwriteconfig6 is barely documented because you're not really supposed to use it. All of the settings that users are expected to change are in the nice settings app that Plasma ships with. Using kwriteconfig (or equivalently a dconf editor on GNOME) is like editing the registry on Windows; you are implicitly opting into more power, out of most guardrails and into potential breakage. The UX being a bit questionable (though honestly it's really not as bad as you're saying, it does exactly what it sounds like it will do?) is to a degree intentional, because you're not supposed to be using this unless you know what you are doing.

To be fair that's not the entire story, since you need to actually resolve the conflicts first, which is slightly scary since your worktree will be broken while you do it and your Linter will be shouting at you.

You may also want a dedicated merge tool that warns you before accidentally commiting a conflict and creating a broken commit.

Oh and non trivial resolutions may or may not create an evil merge which may or may not be desirable depending on which subset of git automation features you use.

Using git status often is definitely good advice though.

The matter of flakes is complicated. Yes they are experimental, but in reality most Nix users use them despite that. I'm a bit on the fence on whether you should start with flakes because they do add some complexity. You can copy paste a sample flake configuration from the Internet (there are many but they all do exactly the same things) and you'll probably be fine but telling people to just copy paste code they don't understand feels wrong as well.

Regarding documentation... I wouldn't go as far as saying you should avoid it entirely but it is in a very unfortunate state with a lot of wiki pages being outdated or just containing snippets that do things in very weird ways, or are over engineered to the point of being incomprehensible.

And that's if someone bothered to write up anything at all. It's a bit sad but reading from the nixpkgs GitHub (or other people's dotfiles) is sometimes the only way to get certain information, such as valid values for package overrides.

Indeed, that all looks fairly innocuous. Just in case, you are sure that you didn't just accidentially kill or killall rclone or bash?

Perhaps wrapping the script in strace might help debug where the offending signal is coming from.

Does your script fork at some point (and might exit before the rsync job is completed)? ~~Because then you need to use Type=forking instead of simple or oneshot, otherwise systemd will start trying to clean up child processes when the script exits.~~

Edit: Actually considering the time span involved Type=forking will not solve your issue because it will timeout, if this is the problem you need to change your script to not do that.

Depends on where one lived at the time I suppose, the Russian economy didn't exactly do great. It wasn't life ending for the majority of people, but then neither was Fukushima, or most of these really.