Storage box networking can be hit and miss. It’s ok for incremental uploads, but I went through hell and back to get the initial backup finish, which makes me wonder what it would take to download it in case I have to.

Scp breaks off once in a while, and WebDAV terminates the session. I didn’t try smb as I feel it’s a rather weird protocol for the public internet. In the end, I figured it’s not the networking per se, it’s something with the timeouts on the remote, and I was able to finish the backup using a Hetzner-hosted server as a jumpbox.

But it’s cheap, yeah.

Voyager pulls /.well-known/nodeinfo now, if you don’t proxy that to your backend (I didn’t), it will fail.

Isn’t kagi’s point that they store very little about you to the point there no search history and you have to pay for the service provided?

That’s not exactly true, synology doesn’t do anything you can’t access from an off the shelf linux (it’s your usual mdraid and btrfs). But you better know what you’re doing if you go that route.

What’s going to pay for the search part, then?

Conduit is in no way compact either. I tuned its caches because two gigs of ram seemed ridiculous for a single-user instance but I only got the mobile client sync lag as a result.

XMPP used to be so much nicer…

This is the best answer. Your router protects you from the outside, but a local firewall can protect you from someone prodding your lan from a hacked camera or some other IoT device. By having a firewall locally you just minimize the attack surface further.

Unfortunately, matrix doesn’t have a viable plan for federation, meaning that you’d better onboard on matrix.org or else.

People saying self-hosting mastodon is hard never had to touch matrix. It’s not hard, the protocol is literally broken to the point where starting again is not an option.

I’m all in for ditching discord, but matrix is at most mediocre in almost every aspect. It’s wild how much easier it used to be with xmpp.

the issues related to that macro still exist, but the author seemed to call it out and link to an article about it (which doesn’t seem disingenuous at all to me).

That’s fair, I stand corrected and I overreacted a bit.

I stumbled on the unintended cancellation a few times, but I’m used to select! paradigm from the other languages (and not used to how differently it behaves). I suppose I just expect the examples of its usage to be explicit and actually show what it takes to make select! behave in a way that doesn’t abruptly drop your async function after only going though half of it.

What I find slightly dishonest is bits like

This way of using select in a loop could potentially cause issues regarding cancellation of futures (although in this case it’s fine)

The select example is pretty straightforward and comparable to such in other languages, even to Go’s switching on channels. But rust hides an extra bit of complexity with the cancellation concerns that people don’t want to talk about unless absolutely necessary, and it is necessary in so many cases!

You don’t need -it because you don’t run an interactive session in docker. It might be failing because you ask for a pseudoterminal in an environment where it doesn’t make sense.

Seq is expecting structured logs which yours aren’t. So you want to either convert your app’s logs into a structured format (which is generally hard for a random third-party application) or use a log collector that’s fine with non-structured logs (e.g. Loki+grafana don’t care about the shape is your logs and you can format the output while querying).

How does it compare to archivebox in regards to specifically saving content that’s a mix of websites and YT videos?

I’ve been using FreshRSS and Reeder (now Reeder Classic) since google reader stopped being a thing. It’s pretty great.

There were quite a few games using the same formula (and improving on it), to the point where I feel Desperados would be my favorite in that genre, not Commandos itself.

I still remember having to reparation my drive and reinstall windows, upgrading from fat16, because commandos wouldn’t fit on either partition.

I have a dedicated vm for things that are crucial to the home network, either latency-critical or network related.

That’d be my dns resolver (I enforce it over VLANs by hijacking anyone trying to do DNS to other resolvers, like random IoT devices), homebridge for less important home automaton and my own matter controller for most important home automaton (controlling the lights).

My router of choice is RouterOS in another VM. I tried opnsense, pfsense, vyatta, and a bunch of others (even a containerized Cisco route), and I settled on ROS, because it was the only one who could do IPv6 properly (apart from Cisco, but that has other issues).

For the less important things I run them on k8s and really, there are only two bits worth mentioning as essential: ArgoCD and nixhelm. Together, they provide effortless and mostly automated software updates with very easy rollbacks. I don’t have to go and manually update every single bit of software and that saves huge amounts of time.

I wonder if NixOS is a vacuum coffee maker for how confusing nix looks when you see it for the first time or instant coffee for how reproducible it is…

That’s just Slackware.

That’s a good point. Mind that in most production environments you’d be firewalled rather hard (especailly when it comes to logs processing which oftentimes ends up having PII). I wouldn’t trust any service that tries to use DoT or DoH in there that I couldn’t snoop on. Many deployments nowadays allow you to “punch” firewall holes based on the outgoing dns requests to an allowlisted domain, so chances are you actually want to use the glibc resolver and not try to be fancy.

That said, smaller images are always good in my book!

You’re nailing your goal then!

I would still steer you slightly towards documenting your architectural decisions more. It’s a good skill to have and will help you in a long run.

You have dozens of crate dependencies and only you know why they are in there. A high-level document on how your system interconnects and how the algorithms under the hood work will be a huge help to anyone who comes looking through your source code. We become better programmers not by reading the source code, but by understanding what it actually does.

Here’s a random trivia: your server depends on trust-dns-resolver. Why? Why wasn’t the stock resolver enough? Is that a design choice or you just wanted to have fun? There is no wrong answer but without the design notes it’s hard to figure your intent.