Blitsbom, browser-only SBOM viewer

I had to scratch one of my itches. I have to work with SBOMs and I couldn’t find something, so I’m announcing blitsbom — a browser-only SBOM viewer. Software Bills of Materials are everywhere now. Procurement asks for one. Compliance wants one filed. A regulator’s auditor will, at some point, want to look at one. The trouble is that the moment you actually want to read an SBOM — to skim what’s in a build, see which components are copyleft — your options are oddly bad. You either ship the file off to a SaaS scanner, install a heavyweight platform, or squint at 280,000 lines of JSON in your editor.

CoolModFiles, but not just random

I’ve been a quiet user of CoolModFiles.com for years. It’s a tiny web player that grabs a random MOD file from modarchive.org and plays it. No login, no library, no algorithm — just a play button and a wave of nostalgia from the Amiga and PC tracker scene. The README says “no black magic involved” and that’s exactly the appeal: a digital amplifier for a corner of the demoscene most people never knew existed.

Using Two Claude Accounts Side by Side

Just something a few might be interested in. I’m in a fortunate situation where I have a private Claude account and also signed in to a corporate Claude team account.

I would like to make sure I spent the tokens from the work subscription only on work-related items and the tokens from my private account on my own stuff. What works for me pretty well is having two Claude config dirs and a shell alias like this:

Why You Should Care About Your Release Notes

When you’re someone like me, who has operated and maintained software for yourself or others, the Release Notes are pretty important. Pure software developers or stakeholders often overlook the importance of this topic, as they simply have to deal with Release Notes when building or generating them. They are often an afterthought and just another box to check on a release procedure list. Here are some reasons why spending some time on your Release Note is worth it.

How Docker Broke the Internet for Me

We have seen two major outages in the last weeks caused by AWS and Azure networking issues. Both outages had a significant impact on services running in the cloud and affected a large number of users. The self-hosting people were laughing about it, but some got struck with the recent Docker 29.0.0 release. It simply increased the minimal API version from 1.24 to 1.44.

This change broke Traefik and some tooling, like the testcontainers-java. The maintainers of Traefik already released a fix, and probably created some stress for them. A lot of issues poped up in their GitHub repository, like this one https://github.com/traefik/traefik/pull/12256. I felt sorry for them, many users use their stuff - including me - to drive HTTP/HTTPS traffic to their websites. It was great to see how quickly shared workarounds. The Traefik maintainers were able to provide and ship a fix in a new release very quickly. All you need to do is upgrade to 3.6.1, and you are good to go again.

macOS with Apple Silicon and x86-64-v3 support

I’m maintaining container images in the OpenNMS ecosystem. My local machine is a Mac with Apple Silicon. While I was upgrading some base images using RHEL UBI 10 / CentOS 10 images, I noticed the following error message.

0.112 Fatal glibc error: CPU does not support x86-64-v3

That happens if you try to run on an emulated x86 architecture running on ARM. After some investigation, I’ve found an article in the Red Hat developer forum talking about upgrading the Microarchitecture level from v2 to v3. The problem introduced is that v3 isn’t supported. I’m using Orbstack and you can reproduce this problem simply running the following docker command.

Streaming telemetry with gNMI

This document describes how you can set up a lab environment for testing gNMI using a virtual HPE Juniper router running Junos 24.2 R1-S2.5. It shows how you can collect metrics for interfaces and CPU utilization collected with OpenNMS. This isn’t something I do every day, so I just preserve this here for my future self and the ones who want to get up to speed a bit quicker.

What you will learn

• Enable gNMI over gRPC with sensors on a HPE Juniper router
• Verify the gRPC connections and configuration
• Enable OpenNMS Horizon to subscribe to gRPC streams for sensor data
• Set up TLS on gRPC using a self-signed certificate authority
• Visualize the collected data in Grafana

Limitations

• Streaming telemetry can only be configured from the OpenNMS Core instance, see enhancement NMS-18064
• Metric labels for network interfaces are right now just resource id strings

Before you begin

You need the following environment to get a lab running:

Go away or I replace you with a Makefile

I remember the first time I tried to get an open-source project compiled and deployed. The distribution of Linux at this point was Slackware. Build or installation instructions didn’t exist, and without handholding on IRC, it would not have been possible for me. That was 30 years ago, people in IRC were very self-selected, patient, and helpful. When you have skilled patient people in IRC and you can communicate what you did, what exactly failed, and what you would have expected - your learning experience is pretty impressive. Nevertheless, it does not scale well. People nowadays expect things to work with a click of a button. They are even not keen on reading clear instructions.

SNMP Proxy ... wait what?

Working with SNMP in 2025 is still a thing. Most hate it, but it’s sometimes the only thing you can use to get insights into the box you are working with. I want to shed some light on the SNMP proxy capability in Net-SNMP, it might be possible some people haven’t heard of it and might find it useful. In a nutshell, you can use Net-SNMP as a proxy to query information from another SNMP agent over an IP connection you can’t or do not want to query directly.