Let’s face it, managing secrets in software projects can be as thrilling as being stabbed in the eye. Yet, it’s a necessary evil that we all have to deal with.

Problem: we have a set of a developers and set of infrastructure that all needs to share secrets. Would like to minimize infrastructure and keep cognitive load to a minimum so we can focus on writing code. Sure you’ve got AWS Secrets Manager and Hashicorp Vault for the heavy lifting, but that’s like using a tractor to crack a nut. And then there’s the keep-all-your-secrets-in-github-action-ENVs which leads to “push-and-pray” mentality (https://dagger.io/ talks on CI/CD are awesome). Not exactly the pinnacle of security or convenience, right?

Enter SOPS , the cool kid on the block that encrypts your files without the bullshit (You know it’s cool cos it’s the latest in a long line of tech abandoned by Mozilla). But setting it up? Still sucks. This post is about how github-to-sops helps.

libkrun + krunvm

Github randomly recommended me libkrun which is a library backing krunvm . It’s something similar to firecracker, but even simpler.

I have been working with Python a lot more recently, and it feels like I spend more time fighting packaging than writing code.

Python’s primary package manager, pip, is roughly equivalent to the best 1990s had to offer(Perl CPAN), it makes it depressingly easy to end up with a broken environment.

Pixi: A modern packaging system for Python

pixi is a modern package manager along the lines of deno/pnpm, but for Python. It’s a single binary that you can download and run. It will install Python + native packages within a single subdirectory. It will use pixi.toml file to track dependencies + pixi.lock to track exact versions of transitive dependencies.

13 GiB/s per core!

Sneller posted a blog on HN on how they use AVX-512 to decompress data at 13 gigabytes per second per core.

This a fantastic ad for their “lets turn logs on S3 into cheap database” product. This is a solution I wanted multiple times, will definitely consider them next time the need comes up.

Faster than RAM

Now this post did not get overlooked, but what did get overlooked is that the post engaged the clickhouse CTO. He posted a link to a presentation on how Clickhouse uses compression to process in-memory data faster than RAM bandwidth .

As a result of discussion in these comments, clickhouse might get even faster.

I’m gonna start a column on cool blog posts I found, that got 0 or minimal traction. I suspect I will also have no traction doing that 🤦‍♂️.

The Problem

I really enjoy thoughtful writing on deep technical problems. It’s even better when one sees thoughtful comments, that further contribute new directions to throughts presented. HackerNews is where most of that writing tends to land. Unfortunately it tends to not do well vs trendy, click-baity, etc content. Twitter is even worse.

First, a blog post on my tooling for reading HN.

The Problem

Ukraine had a lot of power outages due to Putin’s bombing of our power infrastructure, I needed to switch to fiber + battery-backup to continue able to able to work.

I’m at a rental apartment and I’m not allowed to drill walls. The idiot that layed the internet into the apartment used a 4-wire cat5 cable to save a few pennies, then cemented it in.