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.

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

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.

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.

This seems like the right answer to me. Whether or not you decide to dual boot, make one of these USB keys so you can recover if something goes wrong.

When I was using Debian I found I could generally get the latest version of software I wanted from Nix if it wasn’t in the main Debian repos, or was outdated. Nix works quite well on any Linux distro - it doesn’t interfere with the rest of the system.

All I can tell you is that this is done differently for each shell. So decide whether you want completions for bash, zsh, fish, all of the above, or whatever, and look at the docs for the relevant shells.

This is why I switched to labelling USB sticks with two-character codes, and I keep a file that lists the current content of each stick.

Anyone else read these newsletter titles in Pixlriff’s voice? “This week, in Hermitcraft Gnome!”

There’s a relevant community post, NixOS is not dying, please don’t spread fear actively

iOS also supports third-party passkey managers so that’s an alternative to Android for helping to fill gaps creating passkeys.

Nice! I may take a look. I’ve been happy with Enpass except that I recently switched to a window manager that doesn’t implement xwayland, and Enpass is one of only two apps that I haven’t gotten working in native wayland mode, or found a substitute for. So I’ve been running Enpass in a rootful xwayland window running a nested i3 session. The IPC connection to the browser extension still works so it’s not too bad, but I’m a little tempted to try alternatives.

I forgot to mention that to use a passkey manager on Android in addition to setting that Chrome feature flag you also need to set the app as your passkey manager. That’s done at the system level in Settings > Passwords & accounts > Passwords, passkeys, and data services

FYI I’ve been running Steam and Wine games in Gamescope because I’m using a window manager that doesn’t implement XWayland. I don’t know if that would help with Nvidia, but might be worth a try. It works ok; Gamescope has a Steam integration switch that helps.

I think Electron apps mostly switch to native Wayland mode if you set an environment variable, ELECTRON_OZONE_PLATFORM_HINT=wayland. The one I don’t have working in Wayland mode is Discord. See https://wiki.archlinux.org/title/wayland#Electron

I read a few articles. I think Andres Freund’s announcement gave me the best context for the exploit itself. https://www.openwall.com/lists/oss-security/2024/03/29/4

The most helpful source I saw on which systems are affected was this Lemmy post, https://beehaw.org/post/12813772

I have a Ryzen 7 5800X and I’ve had no problems