#Continuous Integration — Seconds to Midnight

Post: Released Ignorelint

damian.buho@proton.me (Damián Búho) — Thu, 17 Sep 2026 02:59:00 GMT

I promised myself to not joke about how ignorefiles were ignored by linters.

Project: Ignorelint is a linter for 20+ kinds of ignore files

damian.buho@proton.me (Damián Búho) — Wed, 02 Sep 2026 00:15:20 GMT

I believe that every file should be covered by some kind of static validator, and when I checked for any existing linter for ignore files, I didn't find any.

And I was in need of real Crystal project to test my base Crystal image.

So I made one.

Post: Released fork of repolinter

damian.buho@proton.me (Damián Búho) — Thu, 09 Jul 2026 02:59:00 GMT

Released a fork of todogroup/repolinter. Migrated it to TypeScript, updated the tests and dependencies, and cleaned up the workflows. Majority of the issues of the original were fixed.

My first experience with such necromancy. I'm sure there are good reasons they dropped it, but it costs little to maintain, and I think the "facts/rules" scheme is actually very neat.

Details on the project page.

Project: M6E Makefile Framework

damian.buho@proton.me (Damián Búho) — Wed, 01 Jul 2026 22:41:53 GMT

This project started as a personal collection of familiar tools, gained declarative fleur, became a make-implementation of Projectfile CI and currently transforming into fully declarative library

Post: Why You Should Care About RISC-V

damian.buho@proton.me (Damián Búho) — Tue, 30 Jun 2026 02:59:00 GMT

I try to support RISC-V everywhere I can, and you should too.

Chances are (around 60%, actually) that you live in a country without an independent CPU/MCU industry. The consequences of the russian invasion in 2022 showed us that you can't really stop high-tech imports into a country that went batshit crazy, but you can make chips somewhat harder to get.

I obviously don't have a problem with sanctions against the axis of evil. But one of these days, some orange clown (or clowns of any color) could decide that Uruguay, Chile, or New Zealand are as bad as North Korea or Iran—because they are too friendly to China, too gay, or something like that. And your country could be next.

One Jacob Feldgoise already whines about RISC-V hindering good old world policing.

RISC-V is not the simplest, but it is the most logical way to get closer to an "Uruguayan Xeon" or a "Nigerian STM32." And it doesn't have to be an entirely national project: regional alliances could help lower costs and achieve scale faster. Getting an ARM license is probably easier, but it's another compliance leash from a country that loves exiting things without thinking them through.

Without a stable supply of chips, you will have issues with everything from ATMs to train networks. It won't be immediate—modern silicon is quite durable—but things will break down and require replacement. If you don't have the benefit of a "death cult of living in squalor and constantly overcoming unnecessary self-imposed problems" in your population (like Russia has), it will become an issue very fast. An issue that both internal and external malevolent actors will exploit. Be less gay, have a chip.

Sovereign RISC-V production is something that feels unnecessary, expensive, and alarmist now. But when it becomes "today's problem," it will be too late.

And even if you have 30+ CPU suppliers, you can still be enough of an asshole that all of them refuse to sell to you (though things won't change much for the real bad actors).

What Can You Do About It?

RISC-V is on the rise, but it still suffers from low adoption across both software and hardware — a classic chicken-and-egg issue.

If You Are a Developer

You can add cross-compilation to your project. It's very easy to do with C, Go, and Rust. In the case of platforms with less support, your interest and pressure can help speed up the process (e.g., Node, Crystal, PHP).
There is a project called RISE that offers RISC-V runners for GitHub CI. Although they use hardware without vector extensions, which makes running some distros (like Ubuntu 26.04) impossible, they can still be useful.
Also consider Cloud-V, they provide CI runners.

If You Are a User (Especially Corporate)

Ask maintainers of your favorite software to add RISC-V support. Vote for existing issues in issue trackers, or create new ones if they don't exist.
Get yourself some hardware or cloud units and research how ready your infrastructure is for a potential migration.

If You Are an Activist Type

Check if local universities have RISC-V programs; support them if you can.
Check if your jurisdiction has digital/semiconductor sovereignty programs. If not, ask your authorities why not.
Spread the word: go door-to-door and ask people if they want to hear the good news about RISC-V. Dress appropriately; don't be weird.

Having a strong alternative architecture will, in the end, benefit all of us.

// And after the end too, when we scavenge for RISC-V chips in the wasteland.

Where to Get One

This is very dynamic market with some supply chain issues, links will go stale faster than I hit publish.

Good keywords to start your search are SiFive and SpacemiT. Or look at the Geekbench

Post: What is B19 images and how I wrap things in containers

damian.buho@proton.me (Damián Búho) — Tue, 09 Jun 2026 02:59:00 GMT

A big part of my portfolio consists of so-called b19-style images.
(b19 means nothing—you just can't get a proper namespace these days.)

It started as an internal effort for my personal and commercial projects, but ended up as a set of conventions unified across 100+ various images (both wrappers and originals). I wanted every container to behave in a predictable way, agnostic of the tech stack, whether it's a source-based or upstream-based project.

I'm not urging anyone to adopt this directly yet—I need some time in public to polish everything—but if you're tasked with a similar unification job or manage a fleet, feel free to steal the conventions.

The conventions are anchored in B19/Ubuntu and flow organically into all downstream projects.
The conventions are unopinionated (though the defaults can be).

What's inside?

Basic container decency

Follows 12-factor app guidelines
Reasonable, secure, and safe defaults with minimal user input required
Images should be immutable; all state lives in volumes
Support for XDG and other industry standards
Proper telemetry everywhere
File operations use locks, always keeping concurrency in mind

The Dockerfile orchestrates

No shell sagas
No mile-long RUN commands—one RUN per stage
Minimal layers

Switches, toggles, handles

B19-style images expose switches for all kinds of behavior: there's no such thing as "too many switches." Where possible, switches are set via environment variables (relying on various mounts and binds is messy).
Configuration files are generated via Jinja2 templates driven by environment variables.

Everything is `.d`

Numbered hooks everywhere. Everything can be extended or overridden via simple drop-in shell scripts in downstream projects. Hooks can be inherited:

Build is build.d
Healthcheck is healthcheck.d
Entrypoint is entrypoint.d

Designed with off-grid in mind

Do not assume connectivity is guaranteed
Do not assume fast or stable connectivity
Timeouts, backoffs, and retries everywhere

In other words, a b19 distribution comes with all the things you would end up adding to an official image anyway—right out of the box.

Post: Released textlint-rule-ukraine

damian.buho@proton.me (Damián Búho) — Sun, 17 May 2026 02:59:00 GMT

I am a big fan of textlint, correct quotes, long dashes, and seeing "0 errors" in my logs.

And I noticed how often Western media mess up correct transliterations of Ukrainian identifiers, using russian-to-English transliterations instead of proper Ukrainian-to-English ones.

There is a nice web app with bots tackling this topic — check it out. I used their vocabulary to make a ruleset for Textlint — pretty sure they are not interested in doing it themselves.

Published as my first npm package. Nothing complex or particularly cool — just wanted to experience npm from the other side.

Excited to become another supply chain attack vector in the future!