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.

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.

So true. Sway forever.

If you have a place to host Forgejo/Gitea, you have a place to store a Git server. Set it up like this:

$ git clone --bare myrepo myrepo.bare
$ scp -r myrepo.bare srv:
$ cd myrepo
$ git remote add origin srv:myrepo.bare
# or
$ git remote set-url origin srv:myrepo.bare

Now git push etc work similar to GitHub, but you’re using your server (named srv in SSH config, as shown in my previous post) as the remote storage.

Selfhosted Gitea is a way to get a wiki, bug tracker or whatnot - collaborate, for example, but it’s not necessary to have a Git server for your personal use.

I started running my own Gitea instance because I wanted a private place to host my Obsidian notes.

I don’t have the time to read the article now, but permit a question: what do you use Gitea for?

I’m holding my dotfiles on a SSH server, clone/push over SSH, and it’s enough to do Git. I don’t need a ticket system, or wiki or anything (I use plaintext notes).

$ cat ~/.ssh/config
Host srv
  Hostname srv.mywhatever.com

$ git clone srv:/path/to/repo
$ cd repo
$ git push

Cool, thanks. Didn’t realize you can use this neat trick :)

What’s the Slackware way of managing package dependencies, then?

Declarative system configuration is the killer feature of NiOS. Atomic rollbacks too. Versioning the whole mess in Git, too.

We’re at Linux@lemmy.ml, hon. The average user uses a package manager. The majority of software is open-source and compiles for ARM just fine. Games excepted, but they won’t run on the low specs anyway.

Yep. I found I don’t have much use for a full-blown VM, whereas there’s plenty of argument for isolating my browser from ~/.ssh/id_*.

I’m using systemd-nspawn or Bubblewrap, depending on the scenario.

Inside a particular text file, you can use a modern text editor - (Neo)Vim, Helix, probably others let you to copy/paste via named “registers” (places to store copied stuff). Select something, then "ay to copy into “a”, then "bp to paste from “b”.

Once I a very sleepy adult human happened to accidentally stand smack in the middle of my ThinkPad P50, with plastic everything. It’s 7 years old now, and still works fine.

If your local machine is not reachable from the internet, you could set up the cheapest VPS - you can get a free one for 12 months at https://azure.microsoft.com/en-us/free/#all-free-services Connect from your destination machine (the firewalled one) to the VPS, and set up a reverse tunnel. For example, drop this into your ~/.ssh/config on the destination machine:

Host rtun
        Hostname something
        RemoteForward 1234 localhost:22

tmux new-ses 'while sleep 1; do ssh rtun; done'

Then configure your local machine to connect to destination via the jumpbox:

Host vps
        Hostname something

Host destination
        Hostname localhost
        Port 1234
        ProxyJump vps

ssh destination should work now.

Make sure to use SSH key auth, not passwords, and never transport secret keys off-machine. It’s easier to wipe and recreate a VPS, if you lose keys, than to explain to Security folks how you were the donkey that enabled the breach.

Lovely. Thanks! Now to figure out how to redirect that YubiKey USB device, so I could use Passkey auth…