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.
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.
Unfortunately Cargo doesn’t have security controls in place to prevent these kinds of attacks. For example pnpm has controls to allowlist install scripts for dependencies and will warn about new install scripts (without executing them).
Compromising the code that is then most likely run in a test instead of compromising a build script is just a very slight inconvenience for the attacker.
I share the dislike for arbitrary build scripts but restricting them will not help the supply chain issue in a significant way.
Also there are several ways to control build.rs execution in the Cargo ecosystem as well, for example with cargo-deny.
Disallow lists are ineffective - better to disallow by default and require opt in.
Also, crates.io can defer serving up newly uploaded scripts that have a new build.rs / proc-macro dependency and warn publicly that a version introduces it.
Restricting build scripts 100% will help mitigate the impact, just not if you only deny it once. And they can develop other things like sandboxing for build scripts by default and escaping that to be the exception that has to be explicitly allowed.
You’re right about attackers being able to change runtime code.
pnpm does have some other features to prevent supply chain attacks, so there is still something to learn from other ecosystems. For example pnpm has a cooldown period for new dependencies and can prevent trust policy downgrades (eg new version published without build provenance where older versions did have it). See https://pnpm.io/supply-chain-security
This comment is both true and entirely irrelevant. The context of this subthread is not running a Cargo command in a checkout of a malicious git repo, it's alleging that `cargo add foo` runs the build script of the crate `foo`, which is false.
reply