I just made a mirror out of two NVMes―they got cheap enough not to bother too much with the loss of capacity. Of course, that limits what I can put there, so I use a bit of a tiered storage between my NVMe and HDD pools.

Just think in terms of data loss: are you going to be ok if you lost the data between backups? If the answer is yes, one NVMe is enough.

Another alternative: https://pushover.net

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.

It’s reasonably doable, I migrated a while ago after logseq decided to destroy my data once again.

I’d say obsidian is not really any more a walled garden than logseq is―the storage is a rather common markdown. If anything, obsidian abuses commonmark less. It’s way better as a product, though and it’s experience is rock solid.

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.

It’d be hard to find an actual product because your use case is rather niche and all of those platforms have and expensive certification process. You can DIY a matter solution the easiest, though, there’s plenty of devkits for standalone matter devices.

You can (trivially) spin up a fake matter switch from one of their examples. It requires a service running on a Raspi.

Otherwise, what was wrong with a virtual switch in homebridge? I’ve been using one of those for years now to do a bunch of homekit automatons.

I have to agree with the commenter above, WSL2 is decent even if you run something uncanny like NixOS. I’ve had it as my primary dev environment for a number of years and it’s alright. I am comfortable with a terminal, though, and the only frontends into it I use are neovide and VSCode.

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.

This looks nice, but there’s plenty free alternatives in this space which warrants a section in the readme with the comparison to other products.

You mention ram usage, but it’s oftentimes a product of event size. Based on your numbers, your average event size is about 800 bytes. Let’s call it 1kb. That’s one million events per day. It’s surely sounds more promising than Elastic, but not reaching Loki numbers, or, if you focus on efficiency, is way behind Victoriametrics Logs (based on peeking at their benches).

I think the important bits you need to add is how you store the logs (i.e. which indices you build) and what are your trade-offs. Grep is an efficient logs processor which barely uses any ram but incurs dramatic I/O costs, after all.

Enterprises will be looking at different numbers and they have lots of SaaS products to choose from. Homelab users are absolutely your target audience and you can have it by making a better UI than the alternative (victoriametrics logs aren’t that comfortable to work with) or making resource usage lower (people run k8s clusters on RPis, they sure wonder about every megabyte of ram lost) or making the deployment easier (fire and forget, and when you come to it, it works).

It sounds like lots of things and I don’t want to be discouraging. What you started there is really nice-looking. Good job!

You can enforce an always-on VPN (for at least ipsec) via an MDM profile. This kind of features isn’t found in the casual user setup options, but there’s plenty of knobs to tune in the enterprise profile configurator.

And yes, you can easily install that profile on your phone after.