praseodym

According to her Wikipedia page she wanted to go for Solaris and was against acquiring NeXT: https://en.wikipedia.org/wiki/Ellen_Hancock#:~:text=was%20ag...

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.

Is it just a coincidence that the image for this release is the same as for Omarchy Quattro? https://youtu.be/F7fe9pa8OeE

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.

They announced something one day after Slack Code: https://github.blog/changelog/2026-08-21-shared-agentic-work...

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.

See https://embarkstudios.github.io/cargo-deny/checks/bans/cfg.h...

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

As mentioned by others it’s just as easy for an attacker to modify a crate’s runtime code.

Post on the Rust blog: https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on...

Discussion: https://news.ycombinator.com/item?id=49372853

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).

There is an open issue for this: https://github.com/rust-lang/cargo/issues/13681

Don’t forget that SpaceX has 3.884 billion outstanding shares!

Just wait for the hyperscalers to follow suit

The screenshot of the Facebook post says they purchased the sets for approximately $20,000.

Note that many Rust libraries consist of multiple crates, which all end up in the dependency graph. This makes the number of dependencies seem higher than it actually is: the separate crates have the same maintainers and are often part of the same upstream git repo.

I agree with the general sentiment though. Rust also has a lot of crates that are stuck semi-unmaintained at some 0.x version, often with no better alternative.

> since Apple saved money on not participating in the AI data-center fiasco

They have unused custom built AI servers sitting in warehouses: https://news.ycombinator.com/item?id=47221264

Forgejo also has a roadmap for federation but it looks like development is progressing rather slowly: https://codeberg.org/forgejo-contrib/federation/src/branch/m...

ZFS on Linux has had many bugs over the years, notably with ZFS-native encryption and especially sending/receiving encrypted volumes. Another issue is that using swap on ZFS is still guaranteed to hang the kernel in low memory scenarios, because ZFS needs to allocate memory to write to swap.

I'm seeing 4-4.5 Watt idle. I've disabled WiFi in the BIOS (using wired Ethernet) and ran `powertop --auto-tune`, but not much else.

I’m using an ASUS NUC 14 Essential Kit N355. It’s a bit more expensive than the Pi 5, but also more powerful (8 cores and decent GPU). There is also a more affordable N150 model. And even lower budget are the N150 mini PCs from Chinese manufacturers, but they often mess up things like cooling in a hardware revision (compared to the favorable review that you’d read).

And forgot to mention this before: Intel CPUs with built-in GPUs have very performant and energy efficient hardware video codecs, whereas the Raspberry Pi 5 is limited and lacks software support.

This is exactly why I’ve to replaced my home server by a low-power x86 NUC instead. No custom build needed to run NixOS and idle power consumption turns out to be slightly lower than the Raspberry Pi 5.

They sent out an email to clarify that there will be no age verification and that the '18 or older' rule was introduced to avoid that:

> You must be at least 18 years old to use the Service (Zed’s AI-enabled software-as-a-service offering, including features like account creation/sign in, Zed Free and Zed Pro, and collaboration). See https://zed.dev/terms#21-eligibility. We set the threshold at 18 due to children's data privacy obligations under COPPA, equivalent international frameworks, and an increasing number of state and regional laws that extend protections to anyone under 18. Those regulations require parental consent verification, age-gated data handling, and separate retention policies for minors. Building and maintaining that infrastructure is a real cost for a small team, and getting it wrong carries regulatory risk. Setting the line at 18 lets us maintain a single privacy framework for all account holders without carve-outs.

The hardware is great, but the software is lacking. macOS only supports resolution-based scaling which makes anything but the default 200% pixel scaling mode look bad. For example, with a 27" 4K display many users will want to use 150% or 175% scaling to get enough real estate, but the image will look blurry because macOS renders at a higher resolution and then downscales to the 4K resolution of the screen.

Both Windows and Linux (Wayland) support scaling the UI itself, and with their support for sub-pixel anti-aliasing (that macOS also lacks) this makes text look a lot more crisp.

Microsoft MS-DOS and Windows supported this in the 90s with DriveSpace, and modern file systems like btrfs and zfs also support transparent compression.