Michael Stapelberg, a Go and Linux developer and former Debian maintainer, writes about package managers, home networking, and hardware builds.
HN commenters find his posts on fiber networking, his 25 Gigabit router build, and his code search index well done and worth reading.
> More so than Debian? Debian's seems pretty thorough. More so than Red Hat's, with the amount of important customers that depend on their distro?
Yes and yes. openSUSE's automated testing builds each package not just in a chroot but a new barebones VM, to ensure that depdndency definitions are complete. I've seen Fedora devs remark about how they don't have that kind of budget to throw as, e.g., COPR builds, the implication being that they have to put more engineering into their testing infrastructure. (Sorry, it was years ago and I don't have the energy or time to source it.)
Those VMs are accompanied with screen scrapers that perform OCR in order to automatically test the pre-boot environment, before a display server comes up.
It is possible that other distros are catching up here (I know nixos-tests can include virtualized, multi-machine, networked integration tests, for some packages, for instance). But this testing infrastructure for openSUSE is quite mature. See, e.g., this presentation from nearly a decade ago: https://www.youtube.com/watch?v=2K6ZmvIOtPw
As for Debian, the greater centralization of openSUSE's package sources is perhaps worth emphasizing as a major difference here. For openSUSE, package sources are all checked into special VCS system that is part of the Open Build Service (which is capable of tracking and building external packages, including packages from other distros as well). With Debian, package sources are uploaded as binary artifacts by…
I think git is a good model for what would otherwise be "laggy async and mismatched" distributed systems.
It has a fast sync algorithm, and after you sync, everything works locally on a fast file system. You explicitly know when you're hitting the network, rather than hitting it ALL THE TIME.
-----
I would like to use something like git to store the source code to every piece of software I use, and the binaries. That is, most of a whole Linux distro.
I have been loosely following some "git for binary data" projects for a number of years. I looked at IPFS like 5 years ago but it seems to have gone off the rails. The dat project seems to have morphed into something else?
Are there any new storage projects in that vein? I think the OP is identifying a real problem -- distributed systems are unreliable, and you can get a lot done on a single machine. But we are missing some primitives that would enable that. Every application is littered with buggy and difficut network logic, rather than having a single tool like git (or rsync) which would handle the problem in a focused and fast way.
It would be like if Vim/Emacs and GCC/Clang all were "network-enabled"... that doesn't really make sense. Instead they all use the file system, and the file system can be sync'd as an orthogonal issue.
Sort of related is a fast distro here I'm looking at: https://michael.stapelberg.ch/posts/2019-08-17-introducing-distri/
He did have the Fractal Define 7 Compact case, and the pictures[1] only show a single 140mm case fan. From personal experience the Fractal Define cases are great at sound reduction due to the thermal padding, but those pads also insulates well.
Given the motherboard and RAM will also generate quite some heat, if the case fan profile was conservative (he does mention he likes low noise), could be the insides got quite toasty.
Back when I got my 2080 Ti, I had this issue when gaming. The internal temps would get so hot due to the blanket effect of the padding I couldn't touch the components after a gaming session. Had to significantly tweak my fan profiles. His CPU at peak would generate about the same amount of heat as my 2080 Ti + CPU I had then, and I had the non-Compact case with two case fans.
[1]: https://michael.stapelberg.ch/posts/2025-05-15-my-2025-high-end-linux-pc/
Funny, I wrote this the other day on HN:
I eventually wound up with Kinesis ergo keyboards and stopped being much "into" keyboards; they are a means to an end: https://jakeseliger.com/2011/07/17/further-thoughts-on-the-kinesis-advantage-unicomp-space-saver-and-das-keyboard-two-years-later
Now I have an Advantage 3 with Box White switches, after admittedly talking to an Upgrade Keyboards key switch sommelier, which I somewhat undercuts my first sentence in the preceding paragraph.
New hardware is fun but, simultaneously, keyboards are fundamentally means to an end, more than ends in themselves. Then there are people like Stapelberg, who produced the stapelberg for the Kinesis keyboards, and who I have to admire for their obsession with modding and their fortitude: https://michael.stapelberg.ch/posts/2020-07-09-kint-kinesis-keyboard-controller/
I was just looking into microvm (via microvm.nix) to isolate coding agents. While the machine starts quickly, as in the article, the userspace (nixos) takes much longer. I'd probably need to spend some time to strip the system of all non-essential services. I also briefly considered running the agent harness as PID 0. That would speed things up, but also mean a lot of responsibility on my end. My biggest struggle is how to imperatively manage agent microvms on nixos. microvm.nix isn't really well suited for that task. For longer-running VMs, that I can manage via my nixos config, I'm quite happy with microvm.nix. Related article by Michael Stapelberg: https://michael.stapelberg.ch/posts/2026-02-01-coding-agent-microvm-nix/
Ever ran a single mode bidi fibre in a conduit? Push a wire puller, cleave and terminate ends, done. Zero effort unlike pulling a jacketed CAT7 cable, zero worries from electrical interference too, future proofing up to 40GBps. I ran double strands in my house so in case one breaks, there's another.
The floors where native fibre is not needed have a cheap ethernet media converter from fs.com, everything else (3 floor switches) are interconnected with 10Gbps SFP+ modules and 2.5G ethernet for the hosts.
All done thanks to the great
https://michael.stapelberg.ch/posts/2020-08-09-fiber-link-home-network/
(if you are reading this, I owe you several beers)