#Meta — Seconds to Midnight

Post: AI Stance

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

Inspired by Armin Ronacher's AI Transparency Statement

I use coding agents every day, but never use LLMs for writing or anything that's meant to be read by humans. I occasionally make a throwaway picture (like an avatar).

I do use them to fix idiotic ESL mistakes I sometimes make. I use … and — via the Compose key in Linux since the 2010s. I have a background in traditional publishing and believe that three dots (...) are not an ellipsis (…) and never will be.

Ground rules

Disclose for humans

Every human deserves to know the source of your information, and has the right to ignore an LLM answer without reading it. It's a good rule even for non-AI applications; I am not reading your "russia today" quote, mate.

So, an LLM response should be marked with the same effort as "trigger warnings" or at least use some quoting standard like APA.

I make an exception for code, because the clanker that did some menial task doesn't deserve a "Co-Authored" byline. Also, no one reads your code anyway (sad, but true).

Accepting full responsibility

An agent/model didn't fuck up. You did.

Never give up control

Don't trust them fully; always have a deterministic pipeline to check their work.

More personally

I dislike the misleading "AI" term and people who are really into it.

Although, I believe any technology can produce obnoxious zealots. Just look at crypto.

Maybe people should look into who raised all of those assholes, instead of screaming at a chain of hashes or matrix multipliers.

I accept LLMs as a genie that can't be put back into the bottle. Holy wars about LLMs are boring.

I do believe that companies behind so-called "SOTA models" are not to be trusted and LLMs should be self-hosted and sovereign.

At the same time, the whole "they drink all our water" trope is a good way to detect virtue-signalling idiots. Most of them can't distinguish an artesian well from an Abyssinian one and have zero interest in the state of local aquifers.

Projectfile

I use the "org.projectfile.ai" extension in my projectfile schema, which generates an "AI POLICY.md" document in all my projects.

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: About maintenance

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

This post sets some clear expectations regarding projects I develop and maintain.

Let's call it Commitment Pledge.

In short, I don't abandon shit easily and appreciate people's trust.

Lifecycle & Exit Policy

Transparent Status

The repository will clearly display its maintenance state via standard badges (e.g., "Maintained", "Archived", "Open For Adoption", "Sundown").

Graceful Exit

If I reach burnout, lose interest, or can no longer maintain the codebase, the project will not be silently abandoned. I will update the project's lifecycle badge to "Sundown" or "Open For Adoption" and post instructions about forking or hand-off with at least a month of advance warning.

Deadman Switch

If a man or an animal or a huge meteor gets the best of me and I become dead, designated person will deal with inheritance and hand-offs.

Integrity, security, privacy

No Protestware or Sabotage

Code updates will strictly serve the project's stated technical function. I will never intentionally inject malware, protestware, console activism, political popups, or code designed to break environments. Although, I will openly and transparently make your life harder if you support evil shit.

No Unsolicited Telemetry

I will not include tracking, phone-home features, user profiling, or analytics without explicit, transparent, opt-in consent. Not sure if I do it even with consent.

No Relicensing Rug-Pulls

Published releases will remain open source. Future releases will not be retroactively switched to restrictive, commercial, or non-OSI-approved source-available licenses.

No Package Deletions

Published releases or package registry artifacts will not be arbitrarily deleted or yanked, preventing broken downstream builds, except when required for critical security or legal reasons.

Transparent Stewardship Transfers

Administrative control, repo ownership, and package-publishing keys will never be sold or handed off to unverified third parties. Any transfer of maintainership will be publicly announced and verified.

Obvious

Right to Refuse

I reserve the right to decline features, code contributions, or pull requests that do not align with the project’s scope, design philosophy, or maintenance bandwidth.

No Obligation of Service

Maintenance is conducted on a best-effort basis; I am not an on-call support team or corporate service desk (but we can discuss it)

I do it because I like making and sharing stuff I find useful.

Post: Hello world