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.
I needed to redo partitions, but didn’t want to reboot.
Mounting a Samba share and moving my LVM pvolumes of / onto a losetup’ed file on it, while running the system. Bass ackwards.
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
It’s not compulsory, so I get not to do it.
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.
Sorry for the cliffhanger. That’s ILIFE. I didn’t have the opportunity to check, and I didn’t remember it by heart.
My robot vacuum doesn’t do WiFi, so unless it has an expensive GSM modem, it can’t send anything.
OTOH, it just sweeps floors, and lacks built-in voice assistant, freemium subscription with a paid option to also sweep the hallway, smart speaker mode, companion/pet mode, built-in games, or all the rest that the modern equivalent of a broom ought to be capable of…
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.
Why not just running hostapd, and dispensing with qemu/OpenWRT?
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”.
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.