BobsAccountant

I LUKS encrypted my boot partition of my last install. It would take an extra 1-1:30 secs to boot when I got the password correct on the first attempt. Much longer if I got it wrong and had to reboot to try again.

I finally did it correctly this last build, but now I am using NixOS and refuse to add anything to the config or a flake if I just need it once a week or so. So I am constantly digging through my history to find the shell I created to do a specific task.

I like Self-hosted Show, as well. Sometimes it feels like they talk about a subject immediately after I start looking into it. The home lab zeitgeist can be eerie, I guess.

A little rough, to be honest. It's a docker-compose deployment, but it requires you to run make to deploy it. The makefile does extra configuration and such to allow the containers to come up healthy. It works, but it's overcomplicated and styled after their own deployments, so probably way more compute than what is needed for one household.

Oh and because of this protracted topology, it's tough to hide behind a reverse proxy.

It might be the camera angle, but those faces might be throwing off the miters. If you're aiming for perfect miters, starting with planed reference surfaces is a must. The alternative is what was mentioned above: cut proud and sneak up on it.

I've been using this, as well. They default to hosting your "vault." It does peer-to-peer syncing, if you don't want to have a server involved at all. I'm running their self-hosted server, but that's only after I decided that AnyType was what I was looking for. I really like that it's object based, so you can create templates for things like meetings that are their own type, separate from a bog-standard page.

You said you added the Tailscale network, but how wide did you go? By default when you load the plugin and activate the interface, it just gives its own IP as the network (/32). If you added that, then only traffic with that specific origin will hit your route. It's crazy, but for my firewall rules (not routing) to work, I had to define the network as a 100.0.0.0/8, which is gigantic. You may have to do that with the route as you can't otherwise set the gateway on the interface as it's not hosting the DHCP server.

Thank you. I do try and take it that way. I was mostly joking and dovetailing it with our trope to overthink social situations.

Yeah, I need to do this. I wonder if it matters.

I am still trying to figure out if calling me {my name}-ipedia was purely in jest or if they secretly hate my voice, face and presence. You know, just a tuesday.

Damn no reason for you to get on here and call me out so directly. Also I still have wobbly windows and the modern version of desklets. No shame.

My family and I really like it. I invested in a small, physical scanner capable of network file sharing that we have plugged in and always ready to scan. When we get documents or receipts, we scan them and they're immediately added to the database. I also have it checking an email address (mine is custom, but you could really have it check any address) and any time a PDF or such is sent, it gets consumed and that email them gets sorted.

There are a few downsides, however. As mentioned in other posts, turning your physical stack of documents into a digital stack of documents is just trading one pile for another. At least with a digital pile, you can sort a little quicker, but you still have to sort the consumed documents and check them to make sure the engine, which is supposed to be learning, has elected to sort the documents correctly.

The compose stack is pretty easy to use, but it does benefit from a little knowledge in Docker/containers. Especially when the main container decides it's not healthy. I wouldn't recommend it to a first time Docker user, is all.

Additionally and also previously mentioned, if you're keeping important documents in it, encrypted storage with encrypted back up is important.

Adding on to this:

These are all great points, but I wanted to share something that I wish I'd known before I spun up my array... The configuration of your array matters a lot. I had originally chosen to use RAIDZ1 as it's the most efficient with capacity while still offering a little fault tolerance. This was a mistake, but in my defense, the hard data on this really wasn't distributed until long after I had moved my large (for me) dataset to the array. I really wish I had gone with a Striped Mirror configuration. The benefits are pretty overwhelming:

• Performance is better than even RAIDZ2, especially as individual disk size increases.
• Fault tolerance is better as you could have up to 50% of the disks fail, so long as one disk in a mirrored set remains functional.
• Fault recovery is better. With traditional arrays with distributed chunks, you have to resilver (rebuild) the entire array, requiring more time, costing performance and shortening the life of the unaffected drives.
• You can stripe mismatched sets of mirrored drives, so long as the mirrored set is identical, without having the array default to the size of the smallest member. This allows you to grow your array more organically, rather than having to replace every drive, one at a time, resilvering after each change.

Yes, you pay for these gains with less usable space, but platter drives are getting cheaper and cheaper, the trade seems more worth it than ever. Oh and I realize that it wasn't obvious, but I am still using ZFS to manage the array, just not in a RAIDZn configuration.