Not as badly as you’d expect, modern compression is pretty quick using the lz*'s and you’re only expending cycles when you’re hitting swap

We joke but zram swap works wonders on low resource systems sometimes

Ah, gotcha. It’s just difficult to figure out what this does if you’re not already neck deep in configuring status bar JSON

Screenshots showing what this does in action would help a lot

I miss windows eating my work when it chooses to install updates and reboot automatically while I’m asleep

Edit: even after I’ve set registry flags and policies to “never automatically reboot” - it’s always fun losing 4 days of work because windows randomly says “fuck you”

Write a couple of your own toy services as practice. Write a one-shot that fires at a particular time during boot, a normal service that would run a daemon and a mount service that fires after its dependencies are loaded (like, say, a bind mount that sets up a directory under /run/foo after the backing filesystem is mounted - I do this to make fast ext4 storage available in some parts of the VFS tree while using a btrfs filesystem for everything else.) You can also write file watcher services that fire after changes to a file or directory, I use one of those to mirror /boot/ to /.boot/ on another filesystem so it’s captured by my system snapshots.

I’d start by reading the docs so you have some ideas about what services can do, then you’ll find uses that you wouldn’t have thought of before.

+1, I used EndeavourOS

I had to set one of these up for my SO a couple of years ago. I dropped EndeavourOS on it, installed btrbk and configured automatic snapshots on a schedule and before package installation/update in case she managed to bork things by pip installing things into system python.

Fedora would probably work well too if you want a lower maintenance burden. I hesitate to suggest Ubuntu or Debian or their derivatives since you’ll probably want to be somewhat current with your Nvidia drivers.

I wrote simple hooks for my package manager to fire system snapshots before I install or update any package. It’s a nice safety belt that I’ve never actually needed to use, but if I do need it it’s there.

We usually find solutions or workarounds to Nvidia driver issues within a day or two in the Arch community. The absolute worst case handling I’ve had to do was fork the Nvidia dkms package at the prior version (think nvidia-dkms-550) and run that until Nvidia themselves released a fixed version. Still pretty straightforward.

The most helpful advice I can give to anyone running a distro maintained by folks with day jobs is “take system snapshots before updates” - do that and the worst case fix to any update problem like this is still really easy to handle, even if you’re 10 minutes out from a work call and an update just went wrong.

Compliance with sanctions from the US and EU IIRC

I moved my elderly mother to ChromeOS and I no longer have to deal with the IT burden of supporting whatever she installed or broke this week. Move your parents to Linux if you truly enjoy being an on call unpaid helpdesk

I leverage btrfs or ZFS snapshots. I take rolling system level snapshots on a schedule (daily, weekly, monthly and separately before any package upgrades or installs) and user data snapshots every couple of hours. Then I use btrbk to sync those snapshots to an external drive at least once a week. When I have all of my networking gear and home services setup I also sync all of this to storage on my NAS. Any hosts on the network keep rolling snapshots stored on the NAS as well.

Important data also gets shoveled into a B2 bucket and/or Google drive if I need to be able to access it from a phone.

I keep snapshots small by splitting data up into well defined subvolumes, anything that can be reacquired from the cloud (downloads, package caches, steam libraries, movies, music, etc) isn’t included in the backup strategy. If I download something and it’s hard to find or important I move it out of downloads and into a location that is covered by my backups.

More secure legally. You generally can’t be compelled to disclose a password that incriminates you (unless it’s already apparent that you’re guilty of wrong-doing) but a thing (physical key, fingerprint, etc) isn’t protected in the same way and can be demanded by the court.

Whether biometric are secure or not is another question, they can be stolen like any other data or a motivated attacker could just take you or your fingers.

Is the 16gb partition the first partition? If so I’d just dd the 128gb drive at the 32gb drive then fix the partition table and remove the others.

If it’s not the first partition use gparted to copy it to the new drive.

It’s mostly fine on my phone, just go landscape to see the broken bit

I wrote snapshot hooks for Arch that fire before installing or upgrading packages and I have a simple shell alias that I can use to fire off a manual snapshot any time I need one. If a package breaks in an inconvenient way and can’t just be dowgraded back to function or I have some other time pressure I can just point my root partition at a clone of my most recent snapshot and reboot to roll back. I don’t usually bother rebooting into a cloned snapshot to test changes as I can just perform the same steps to roll back and the automated rolling snapshots mean I don’t need to baby anything to have the same protection.

Gimp 4.0 is on schedule for a 2040 release at this point

I routinely do 1-4TB images of SSDs before making major changes to the disk. Run fstrim on all partitions and pipe dd output through zstd before writing to disk and they shrink to actually used size or a bit smaller. Largest ever backup was probably ~20T cloned from one array to another over 40/56GbE, the deltas after that were tiny by comparison.

Because you’re relying on compatibility between older Debian software (systemd, etc) and newer versions installed in the chroot. Things get weird quickly.

Consider a nested privileged container instead (LXC or similar) and cross your fingers that Debian systemd and Arch systemd play nice.

If the above fails just make a VM and pass through the GPU with GVT-g (otherwise pass through the entire GPU.)

If all of that fails install Arch to a USB attached SSD or something.