I’m running KDE Plasma with the revived Krohnkite for auto tiling. Plasma 6.2 seems to have fixed most of the bugs from 6.0 and 6.1, at least the ones I’ve noticed.

I was using Sway/SwayFX for a few months but was missing some KDE Gear apps like Dolphin and Okular which I couldn’t get to display correctly. KDE is afaik the only desktop with a working Qt theming engine right now, so I can’t really see myself switching (unless maybe if they break Krohnkite again).

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.

As a Home-Manager user I would argue it’s not really worth it. It has it’s moments for some applications but most of the time it’s the same experience as editing the config files directly. Except instead of INI or TOML it’s stringly typed Nix attrsets and you need to rebuild the entire system instead of restarting the app. Not exactly a huge improvement.

And that’s when you’re lucky enough that what you’re configuring can be mapped to attrsets. Styling Waybar via Home-Manager means writing CSS but it’s a multi line string in Nix with no appropriate editor support whatsoever, and writing custom actions for Nixvim means writing Neovim-Lua but… that’s right, in a multi line string.

On a more positive note, I will second the recommendation for the NixOS & Flakes Book, I found it to be much more useful for getting my head around flakes (and Nix in general since I started using them fairly early on in my Nix journey) than e.g. Vimjoyer’s videos, which are good but their repositories were really really cryptic to me at the beginning.

I agree.

You could say that about any kind of autocomplete. Why would people install snippet plugins into their vim/emacs? Sure you can just type everything by hand but it’s just more convenient.

Personally I find these kinds of inline AI suggestions make a more convincing use case than trying to prompt engineer a Chat based LLM and diverting your attention to phrasing specifics instead of the actual problem space.

If your build fails because you can’t track down the literal ≠ in the code I would recommend just looking at the compiler error. I understand the concerns about == vs = more but the vast majority of LSPs (and some compilers) will catch that too.

I have also yet to see any IDE enable ligatures by default, at least VS Code and the JetBrains suite both require opting into them even though their default fonts support them.

It doesn’t help that US diverging diamonds seem to insist on having pedestrians walk through the median.

But honestly all interchanges are varying degrees of horrible and if you want your city to be bearable to navigate as a pedestrian/cyclist you just really don’t want to do urban highways, or roads above a certain size in general.

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.

TimeoutStopSec applies to the ExecStop command, TimeoutStartSec would be the culprit here. I’m not sure why there would be a default timeout of specifically 1:39 minutes though.

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.

To be fair this also happened to Eagle Dynamics, developer of DCS, the other “realistic” flight sim that players take far too seriously. Except there it was a Dev that got arrested in Georgia and extradited to the US…