semi-interactively explains how TLS works, very cool

Slowly booting full Linux on the intel 4004 for fun, art, and absolutely no profit

a really fun (albeit somewhat impractical) way to compress webpages when all you have is browser APIs

Lix is an independent variant of the Nix package manager, developed by a team of open-source volunteers, and maintained by and for a passionate community of users.

I kind of assumed that Lix is a purely political fork, but they seem to write actual code, so that’s nice. Changelog promises faster evaluation, better errors and REPL improvements.

microforum in DNS TXT records

Looks useful if I ever install DAP.

Has some interesting features like “View HIR”, grouped code actions and failed test diagnostics.

With some partial evaluation and specialization hints, it is possible to get pretty decent speedups on interpreters by turning them into compilers.

git clone --recursive --remote-submodules https://github.com/asyncmeow/git-infinite-recursion.git

A nice explanation of async that’s not about “threads slow”, but rather about how async as an abstraction emerges from sensible design decisions.

A nice post about SIMD algorithms using Rust’s portable SIMD as an example.

Because spin locks are so simple and fast, it seems to be a good idea to use them for short-lived critical sections. For example, if you only need to increment a couple of integers, should you really bother with complicated syscalls? In the worst case, the other thread will spin just for a couple of iterations…
Unfortunately, this logic is flawed! A thread can be preempted at any time, including during a short critical section. If it is preempted, that means that all other threads will need to spin until the original thread gets its share of CPU again. And, because a spinning thread looks like a good, busy thread to the OS, the other threads will spin until they exhaust their quants, preventing the unlucky thread from getting back on the processor!

This blog post is one of those things that just blew up. From a tiny observation at work about odd behaviors of spinlocks I spent months trying to find good benchmarks, (still not entirely successful) writing my own spinlocks, mutexes and condition variables and even contributing a patch to the Linux kernel. The main thing I’ll try to answer is to give some more informed guidance on the endless discussion of mutex vs spinlock. Besides that I found that most mutex implementations are really good, that most spinlock implementations are pretty bad, and that the Linux scheduler is OK but far from ideal. The most popular replacement, the MuQSS scheduler has other problems instead. (the Windows scheduler is pretty good though)

What if all software suddenly disappeared? What's the minimum you'd need to bootstrap a practical system? I decided to start with a one sector (512-byte) seed and find out how far I can get.

Simple, fast, and green CI and caching for nix projects

A free book about atomics and locks that also serves as a nice cheatsheet for x86_64, aarch64 and futexes.