I was reading this thread thinking, “this isn’t the time to recommend NixOS that’s not what OP asked about.” But if you’re using Ansible this way NixOS might be a good fit for you. It’s got the advantages of the other immutable distros with the added feature of managing everything through a declarative configuration.

Nice! Thanks!

When I researched this previously I concluded that there are two very good options for regular backups: Borg and Restic. These are especially efficient at backing up a diff of what has changed since the last backup. So you get snapshots of your filesystem state at each backup point without using a huge amount of space. You can mount any snapshot as a virtual directory. After the initial backup, incremental backups take a minute or two.

I use Borg, and I back up to cloud storage on Borgbase. I use Vorta as a GUI for Borg. I have Vorta start automatically when I start my window manager, and I have it set up for daily backups. I set up the same thing on my kid’s computer.

I back up my home directory. I have some excluded directories like ~/.cache, and Steam’s data directory. I use Baobab to find large directories that I don’t want backed up.

I use the “exclude caches” option in the Borg “create archive” settings. That automatically excludes Rust target/ directories because they follow the Cache Directory Tagging Specification. Not all programming languages’ tooling follows that spec so I also use directory name pattern excludes. For example I have an exclude pattern for .*/node_modules/.*

I use NixOS, and I keep my system config in a git repo so I don’t need backups for anything outside my home directory.

Probably not very similar, but Git Butler is very interesting. It adds its own layer of management so that you can have multiple branches “applied” to your working tree simultaneously. It’s helpful when you have multiple changes that should go into different branches, and some that shouldn’t be committed - it has a system of lanes that help keep track of all that. Or you can test how changes from two branches interact.

Last time I used it, maybe 6 months ago, it was rough around the edges so I didn’t stick with it. But they’ve done lots of work since then so I’m thinking of giving it another go. It is (last I checked) an all-in tool. When you’re using Butler on a project you probably won’t be able to use other git tools.

I think it depends. Lua is great for scripting - like when X happens do Y. I agree that makes sense for a case like Home Assistant. Sometimes you really want the result to be a data structure, not an interactive program, in which case I think more sophisticated configuration (as opposed to scripting) languages might be better.

Yes, there’s a good example. Ansible would make more sense if its configuration language was Nix…

Oh, thanks for calling that out. I think I may have mixed up some of the frustrations I experienced at an old job.

I agree - YAML is not suitable for complex cases that people use it in, like Terraform and Home Assistant. My pet peeve is a YAML config in a situation that really calls for more abstraction, like functions and variables. I’d like to see more use of the class of configuration languages that support that stuff, like Dhall, Cue, and Nickel.

There is another gotcha which is that YAML has more room for ambiguity than, say, JSON. YAML has a lot of ways to say true and false, and it’s implicit quoting is a bit complex. So some values that you expect to be strings might be interpreted as something els.

NixOS and Home Manager config both ways to get rid of the same thing

Zed invented tree-sitter which is a great feature. But since tree-sitter is open source it’s also available in neovim and helix.

It seems like only one side of the ancient rivalry is represented in the comments here. No worries, I’m right there with you.

It would make sense for the terminal to handle syntax highlighting since that would match how editors work. But the convention is that the shell handles highlighting, not the terminal. You can check which shell you are running with the command,

$ echo $SHELL

It’s done that way because the shell is a running program that is capable of telling the terminal which colors to show (by mixing color escape sequences into text). Compare that to code in an editor which is text, not a running program so the only option is for the editor to handle highlighting[1]. Editors need syntax files to configure highlighting for all the different programming languages, while terminals don’t need this because the shell tells them what colors to show.

[1] setting aside the “semantic highlighting” LSP capability - that was invented long after syntax highlighting conventions were established

Specifically programs.steam.enable = true sets up the direct rendering and 32-bit libraries that you generally need.

I was confused at first about how to install wine runners in Lutris or in Bottles. It turns out you do it the same way as in any other distro, through the app.

Seems like a matter of preference, and I see the logic in it. I’ll mention that Nushell makes it easy to create custom shell functions that are invoked as sub-commands in this manner. https://www.nushell.sh/book/custom_commands.html#command-names

Are there other relevant standards? The XDG base directory specification has been around for a long time, and is well established.

Maybe your comment wooshed over my head; if so I apologize.

Are you saying that you don’t want to write your software according to the XDG spec, or that you don’t want to set the XDG env vars on your system? If it’s the second that’s fine - apps using XDG work just fine if you ignore it. If it’s the first I’d suggest reconsidering because XDG can make things much easier for users of your software who have system setups or preferences that are different from yours; and using XDG doesn’t cause problems for users who ignore it.

OP’s recommendation is aimed mostly at software authors.

So yes, “XDG” stands for “Cross-Desktop Group” - but I don’t agree that using the spec assumes a windowing system. The base directory spec involves checking for certain environment variables for guidance on where to put files, and falling back to certain defaults if those variables are not set. It works fine on headless systems, and on systems that are not XDG-aware (I suppose that means systems that don’t set the relevant env vars).

OTOH as another commenter pointed out the base directory spec can make software work when it otherwise wouldn’t on a system that doesn’t have a typical home directory layout or permissions.

I guess it’s not relevant for your setup, but I like rofi because there is a fork that works in Wayland, and it’s the only Wayland window switcher I have found that isn’t tied to a specific window manager.

To start the firewall after you stopped it:

sudo systemctl start firewalld

systemctl is part of systemd - it starts and stops various services, shows statuses, lists available services, etc.

There is documentation on opening ports here, plus more details on enabling & disabling the firewall: https://docs.fedoraproject.org/en-US/quick-docs/firewalld/#_controlling_ports_using_firewalld

Probably not directly helpful, but Nix packages for Chromium and Electron apps are set up so that you can switch to native Wayland mode globally by setting an environment variable, NIXOS_OZONE_WL=1

I don’t know of any global setting that isn’t distro-specific.