Note: My personal construct of ideas for ten attitudes. This is not an academic paper, but a conjecture – grown from historical observations, conversations, and experiences I have gathered from all over through the years. If you like, listen while reading: § 1 Togetherness. In times of scarcity, retreating into one’s own group was vital for survival; today we are all in the same boat – whether young or old, whether born here or newly arrived. Instead of falling back into old defensive reflexes of division and confrontation, we use what we in Austria have learned across generations: we bring different interests to one table, seek a viable compromise – and tackle things together. ...

Managing a multi-machine fleet with NixOS across physical workstations, Incus virtual machines, and development containers usually runs into two persistent architectural dilemmas: Module & Dotfile Sprawl: Monolithic flakes where host hardware, system services, and user dotfiles get tangled together in a fragile import graph. The Secret Deployment Paradox: You want root and user passwords locked behind a physical hardware token (YubiKey Age identity), but you also need headless servers and Incus containers to boot, rebuild, and activate unattended without an administrator’s physical key present. Over the past week, I rebuilt my entire infrastructure repository from scratch to solve these exact problems. The project is called r3x. ...

incus-compose is a drop-in replacement for docker compose that runs your compose.yaml on Incus, with the full Incus API as an escape hatch when you need more than the Compose spec covers. Twelve days for 1.3 to come: backup, port-forward, and all the commands you might have been looking for. Full release notes: incus-compose 1.3 has been released on the Linux Containers forum. Two bits that did not make the announcement. run was a lot of hassle to create Incus has no “start this, tell me what it exited with”. An instance runs its entrypoint and the exit status goes nowhere. ...

incus-compose backup takes the storage volumes of a project, keeps them, and puts them back. Here is five and a half minutes of it on the immich example — postgres, redis, server, microservices, machine-learning, and three volumes between them: asciinema.org/a/1263992. Every timestamp below opens the recording at that moment, so you do not have to watch the whole thing. It is one take. There is a ^C out of backup create while it was still waiting on a healthcheck, and a [warn: resource is already running] near the end. ...

In The Ones I wrote down a table of imaginary agents. The top row was the boring one: an agent that asks what a thing is for, and cannot propose and cannot cut. Yesterday I ran it by hand. No custom runner, no daemon, no theones binary. Two terminal sessions, two log files, and a real task on incus-compose. It found real defects and the work landed. The interesting part is where the constraint came off, and that I did not notice at the time. ...

None of them exist. What follows is a group of imaginary agents that would help me work better. I am writing them down because writing a thing down is how I find out whether it is worth building, and because this group is cheap to describe and expensive to make. Where they come from After a session with an agent I ask it for a written account of how the session went. There are 132 of those now, going back to January, and read together the failures in them are not varied. They are a small number of things, repeated: ...

One of the session write-ups in my repo opens like this: Session ended with a revert and nothing shipped. It is written as a confession. Nothing shipped is the normal state of a session, and it always has been. What shipped means On a branch, it is a draft. On main, it is merged. It is only shipped when it has a version tag. Nothing else counts. I keep that narrow on purpose. It is the only line in the whole process where the cost of being wrong changes, and everything either side of it behaves differently. ...

One of the rules by which I build software is: constraints outside, freedom inside. The conditions belong at the edge. What happens inside can then be direct. No function has to defend itself against its own callers, because at the edge it has already been decided what comes in. The boundary is there so that the inside becomes free. With human beings, that flips. What the Boundary Does in Code It says what passes through. Nothing more. ...

I flip things. An && where the || was, two digits the wrong way round, a character landing one place left of where I meant it. It happens all day, it makes the result wrong, and thirty years have not trained it out of me. Formula and arithmetic A right answer needs two things that fail separately. The formula has to be right, and the arithmetic has to be right. A perfect formula with a flipped digit gives you a wrong number, and the wrongness tells you nothing about which half failed. ...

In a review session an agent told me the plugins in the chain must not trust each other. Treat each one like a foreign API: check what arrives, and defend the chain against a plugin that misbehaves. It was not a careless suggestion. That is what you do at a boundary you do not control, and it is the right default for most of the code anybody works on. I still said no, and writing down why took longer than saying it. ...