Seconded. Both work great.

I made a honest effort, but in the end went back to Git for my personal projects. The advantages Fossil has over Git (wiki, bug tracker) are trivial to emulate with versioned plaintext files, and everything about Git’s version control system just clicks with my head. Having years of experience breaking and unbreaking things helps too.

Tho one thing Fossil taught me is to merge by default, not rebase. Rebase when there’s good justification for it, and the rest of the time, have an alias for git log --oneline --graph --first-parent (or whatever that was). --first-parent collapses a horrible branchy-mergy history into a linear overview thereof, with details available when needed.

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’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.

Does your FS support online resizing? EXT4 doesn’t, so you’d have to use an installer stick.

Be super careful about partition sizes. I once tried to shrink my FS to an exact size, then shrink the LV to the same size - it ended up corrupting my FS. After that time, I started undersizing the FS, then resizing LV, finally expanding the FS again.

Have backups.

I’d recommend a Linux installer on a memory stick, instead. It’s bound to have less network lag.