zstd has a built-in benchmark mode to compare different compression levels, e.g. `zstd -b1 -e9 [FILE]` to test levels 1 to 9 (try up to 22 if you have enough spare time)
Note that the dictionary options are only needed to improve compression ratios when compressing lots of small messages. If you have a bigger file (eg a tar file of Usenet messages) the regular Zstd compression will build a good dictionary without additional options.
This also adds a lot of moving parts and failure modes. For self-hosting I’d rather have downtime on a simple system that’s easy to fix rather than a complex setup that stays up but needs more maintenance when some component fails.
It's containerized. It's an easy enough problem to solve, if you don't want it complicated.
Here's what I did with my own setup: Stop the containers at night, copy the files to a second system that's configured with the same containers and that can become the primary as needed.
I already monitor my systems for health and backup states, so these would be added to that. But all that does take a few hours to set up.
You want your backups regardless and you want to have some certainty they're working/good. It's a problem that needs to be addressed, even you are going to agree with me on that.
My home server is an ASUS NUC 14 Essential which idles at 5W with a bunch of services running. Its peak performance is probably less than the Mac Mini, but the hardware is cheap (at least it was before RAM/storage got expensive) and it’s a great platform to run Linux on.
Claude Code also doesn't make it easy to make _efficient_ use of the different models to reduce overall cost. There are many tokenmaxxing features (e.g. ultracode that spawns dozens of subagents) to burn through the 5-hour limit in minutes, but if you want to let an Opus planning agent use Sonnet for implementing you have to orchestrate your own workflow. I'm pretty sure that's because the Anthropic employees working on Claude Code have unlimited token budgets so they're mostly on tokenmaxxing workflows themselves.
cargo-deny can audit build scripts, but unfortunately not prevent execution of malicious build scripts exactly for the reason you gave. It could still help if you only ever use cargo add and update in a sandbox.
So? Runtime code requires actually executing the malicious code path which isn’t an immediate 100% hit rate for everyone that includes it in the dependency chain. For build.rs it’s a 100% compromise of everyone it’s in the dependency chain for. Additionally, at runtime you may not have access to secrets whereas at build time you most certainly do.
reply