Several people here have suggested the gearbox be in 1st gear, while starting. Dunno why.

I always shift to neutral, while starting, for safety (to avoid having the starter lurch), depress the clutch (as a 2nd layer of defense for the same) and still sometimes it happens that I forget both.

As for how to actually start moving: press clutch, put in 1st gear, release any brakes assuming you’re on level ground, slowly release clutch until you feel that the clutch starts engaging. Then hold it there for a moment, to allow the car to get a tiny bit of speed, until finally releasing it completely. If you release clutch too fast, it’ll overload the engine and it’ll stall. If too slowly, it wears the clutch, which is expensive to replace. Older gasoline-fueled cars with low torque at low RPM might need a bit of accelerator (say 2000RPM) to get moving without stalling.

OP didn’t want to delete anything, but to compress them all, exploiting the fact they’re similar to gain efficiency.

Indeed! Interesting! I made an experiment now with a non-compressible file (strings < /dev/urandom | head -n something) and it shows you’re right. 2nd commit, where I added a tiny line to that file, increased repo size by almost the size of the whole file.

Thanks for this bit.

Highly unlikely to succeed. The tiny differences are spread out all over the image.

You could store one “average” image, and deltas on it. Like Git stores your previous version + a bunch of branches on top.

Cool idea. If this doesn’t exist, and it probably doesn’t, it sounds like a worthy project to get one’s MSc or perhaps even PhD.

FS permissions are the main thing, yes. One can build more systems around it (don’t mount the socket into a Flatpak container, if you don’t want the Flatpak to talk to DBus) or (implement some sort of auth protocol like TLS does).

1. Make a snapshot with LVM2 or BTRFS to ensure consistency, delete the snapshot after backing up.
2. You can back up files as root (I do) or a dedicated user that has perms to all the relevant data via groups.
3. Rsync can preserve users either numerically or by name.
4. Rsync can do incremental backups via hardlinks (you’ll have a complete view of all files in each snapshot, but only pay the storage when files actually change).

What’s an rpc port anyway? Do you mean DBus? Then FS perms of the socket. Perhaps also something in the protocol itself.

If your Windows partition is encrypted with BitLocker (which it probably ought to be, for security), and you disable Secure Boot, Windows will get angry at you.

You can set up Linux to do Secure Boot (I think I saw Fedora do it for you automatically), but it’s extra hassle.

You might be able to decrypt BitLocker in Linux: https://github.com/Aorimn/dislocker/

Tried, but it didn’t support my disk encryption, LUKS2. I intended to stick Guix in a BTRFS subvolume, but didn’t succeed.

I use it whenever possible, for its easy sandboxing. I’ve also been bui lding my own sandboxing solution based on Bubblewrap, for things not on Flathub. Maybe I should learn how to build flatpaks locally, instead…

I feel like I couldn’t live without my bathroom. I probably could, but it’dn’t be great.

What’s a tactical shooter anyway? Here’s a shooter, tactical or not: https://flathub.org/apps/com.realm667.Wolfenstein_Blade_of_Agony … oops, it’s “source available”, but not libre.

I’m using NixOS in Azure - Azure allows creating a VM out of a disk image, and NixOS has tools to create preconfigured disk images. You inject your SSH keys and stuff straight into the image, then upload and create a VM. A bit fiddly, but I got it to work.

192.168.0.00? 'Shopped.

Congrats, you’re now ready for https://en.wikipedia.org/wiki/Lojban

It didn’t, but due to unrelated reasons. The root FS was mounted r/w, so the regular IO eventually overwhelmed the network’s ability to copy stuff.

But no worries, a reboot later, with unmounted FS, I finished the same thing.

Copying the disk of a running system appears to be fine in LVM. Copying is done block-by-block, and the only thing it has to do to make it atomic is: in case of a conflict (writing into a block that’s being copied right now), postpone writing to a block until it’s copied, then finish the write in the new location. Or else, abort the copy, finish the write, then copy again.

BZ2-ing up a terabyte of zeroes (back when a TB was more than people commonly had, then zipping that file up together with another file, to bypass virus scanners in emails that prevent emailing .exe files.

I’ve also seen a self-referential .zip file somewhere that contains itself.

I use rsync with a custom shell script to manage the number of incremental copies. You’ll probably prefer something less janky.