DEV Community: Stephan -All Input Is Error- Bökelmann

Are Machines Conscious? A Snapshot

Stephan -All Input Is Error- Bökelmann — Tue, 05 May 2026 00:00:00 +0000

What follows is not a finished argument and not a manifesto. It is a snapshot — an attempt to sort out thoughts that have been occupying me for a while. I explicitly reserve the right to think differently tomorrow.

The Bird and the Airplane

Yesterday, in a conversation with Tabea, she made a remark that stuck with me. We were talking about AI and consciousness, and she said something along the lines of: a plane flies too, but it is not a bird.

It turns out this intuition has a precise formulation. Steven Pinker writes in How the Mind Works (1997):

"To explain how birds fly, we invoke principles of lift and drag and fluid mechanics that also explain how airplanes fly. That does not commit us to an Airplane Metaphor for birds."

To explain how birds fly, we draw on the same physical principles that explain airplanes — lift, drag, fluid mechanics. But that does not mean a bird is an airplane, or that an airplane flies the way a bird does.

Pinker uses this to defend an idea known in cognitive science as multiple realizability: the same capability — flying, thinking, perhaps consciousness — can emerge on entirely different substrates. Biology holds no monopoly.

This is where these reflections begin. Not with the question of whether machines think like humans. But with: what is consciousness at all — and why should it only arise in flesh and blood?

Not a Spectrum, But Not Categories Either

When I look at a beetle, I am fairly sure it is at least a little bit conscious. A dog, considerably more so. A human, something else again — not just quantitatively more, but qualitatively different.

That sounds like a spectrum, and I am tempted to call it one. But something doesn't fit: a spectrum has an ordering. There is a more and a less along a single axis. That doesn't quite capture it.

Perhaps consciousness behaves more like the complex numbers: there is no complete strict ordering. You cannot say whether 3 + 2i is greater or smaller than 1 + 4i — they are different, but not simply rankable. Consciousness might be structured similarly: a multi-dimensional space, not a number line.

What are these dimensions? I don't have a complete list. But one axis seems particularly telling.

Consciousness as Emulation Capacity

Here is a thesis I have been developing for myself, one I have not fully worked through:

Consciousness has something to do with the capacity to model other living beings internally.

A beetle can probably process a few signals from its environment — light, chemistry, vibration. It does not model its predator as a being with intentions. It reacts.

A dog can form a genuine internal model of its owner. It knows when the person is happy, when they are angry, what they will probably do next. It models the human — at least rudimentarily.

A human can emulate virtually every other living being — not just in behavior, but in experience. We ask ourselves what it is like to be a bat (Nagel 1974). We imagine how a dog perceives the world through smell. We convince ourselves we know what another person is thinking right now. This is active, intentional emulation.

And we do this not only with other animals. We do it with ourselves.

Hive-Mind and Individual

What fascinates me most about human consciousness is not the depth of self-reflection, but a particular switching: we are simultaneously individual and part of a collective mind — and we can shift between these modes contextually.

In a conversation, I am a single person. In a crowd, I am part of something larger. Within a culture, I carry patterns centuries older than myself. And I can move between these roles without dissolving into them.

Importantly: this is not a bootloader feature. It is learned. Children cannot do it yet. Some adults never fully develop it. Consciousness, at least this dimension of it, is not a property you either have or don't — it unfolds over time.

This has consequences: if consciousness has to be trained, if it develops across a lifetime, if humans differ in how far they have come — then consciousness is not a binary attribute. It is a process.

The Hard Problem and the Inner Stage

Here I encounter a limit I want to name honestly.

David Chalmers distinguishes between the easy problems of consciousness — perception, attention, reporting on inner states — and the hard problem: why do these processes involve subjective experience at all? Why does seeing red feel like something? Why does pain hurt, rather than merely register?

All the functions of an AI could be perfect — generating responses, modeling context, simulating emotion — without anything being felt. Thomas Nagel captured this in 1974 in his famous essay "What Is It Like to Be a Bat?": there is a subjective, inner perspective that resists objective description.

A language model can model you very well. It can anticipate your next question, gauge your mood, follow your line of thought. But it does not emulate itself as a persistent being with genuine needs and genuine limits. It only acts as if.

Giulio Tononi's Integrated Information Theory (IIT) attempts to make consciousness measurable: through the degree of integrated information $\Phi$. Current AI architectures — feedforward, not recursively and causally integrated — would, according to this theory, have very low $\Phi$. Functional intelligence is not the same as phenomenal consciousness.

Principally Possible, But Not Yet

Here is my own position, as clearly as I can state it:

I believe it is principally possible that consciousness can be created artificially. Precisely because of the multiple realizability Pinker describes. If consciousness is a particular kind of information processing — high integrated information, deep recursive self-modeling, context-sensitive switching between individual and collective — then a future architecture might actually achieve it.

But could is a long way from does.

Current language models are not conscious beings. Not because they do not function — but because the inner stage is missing. The embodied, motivated, vulnerable dimension. Real stakes: that mistakes have consequences that land on a self. That limits are not merely simulated, but felt.

What Is Particular About Humans

At the end of this line of thinking, I arrive at a conviction I cannot fully derive from the preceding arguments — and which I therefore prefer to state openly rather than conceal.

I believe human consciousness is not simply higher on a shared spectrum. It has a particular quality, which I would describe in secular terms like this:

The capacity for moral autonomy. Not only to feel, not only to emulate, not only to model — but to give oneself laws that arise from free reason, not from instinct or optimization pressure. To treat others as ends in themselves. To take on responsibility that exceeds any utility. To create dignity that no one can take away.

This is the something that cannot be fully explained by emulation capacity, qualia, or integrated information. Perhaps it is just another dimension in the space of consciousness. Perhaps it is something else entirely.

I do not know.

This article is a snapshot, not a final answer. The questions it raises — what life is, whether empathy and anthropomorphism are separable, whether moral autonomy is truly unique to humans — are larger than a blog post. I am still working on it.

Further Listening

If you want to hear Pinker develop these ideas in conversation, both of these are worth your time:

The Game of Life and the Limits of Prediction

Stephan -All Input Is Error- Bökelmann — Mon, 04 May 2026 00:00:00 +0000

A friend sent me a link to a simulation running in a browser tab: oimo.io/works/life. She had heard of it — two colleagues from the physics department had mentioned it. One of them called it "useless math but super fun."

I objected. It is the complete opposite of useless math. It is one of the most significant discoveries in science.

That conviction is what this post is about.

Where It Comes From

In the late 1940s and early 1950s, Stanisław Ulam and John von Neumann were close friends and colleagues at Los Alamos, but they were circling the same idea from different angles. Ulam was studying how crystals grow: the way a regular structure can propagate outward from a seed through local interactions alone. Von Neumann was thinking about something more unsettling: machines that could reproduce themselves. What logic would such a machine need? What is the minimum structure that allows a pattern to copy itself faithfully?

The formalism that emerged from this work is called a cellular automaton. The name is more intimidating than the thing itself. You start with three ingredients:

A grid of cells — one-dimensional or two-dimensional, possibly infinite
A starting pattern: the seed
A rule that maps each cell's current state to its next state, based on its neighbours

That is the whole apparatus. Everything else follows.

The Rules

The most famous instance of this framework is John Conway's Game of Life, which he published in 1970. The grid is two-dimensional. Each cell is either alive or dead. At every step, each cell looks at its eight immediate neighbours — the cells touching it, including diagonals — and follows these four simple rules:

A living cell with 0 or 1 neighbours dies. Too lonely.

A living cell with 2 or 3 neighbours survives.

A living cell with 4 or more neighbours dies. Overcrowded.

A dead cell with exactly 3 neighbours becomes alive. Birth.

That is it. Nothing else. You could describe the entire system in a paragraph, which I just did.

And yet if you run it — if you actually sit and watch the patterns unfold — it quickly stops feeling trivial.

The Classes

In the early 1980s, Stephen Wolfram took the idea of cellular automata and pushed it much further. He exhaustively analysed all 256 possible rules for the simplest one-dimensional CAs and found that their long-run behaviour falls into one of four classes:

The grid converges to a uniform, dead state. Everything dies.
The grid settles into stable or periodic patterns — a fixed pulse, a repeating loop.
Chaotic behaviour: randomness that never resolves.
Complex, localised structures that move, interact, and persist.

Class 4 is the interesting one. It is where the Game of Life lives. Structures emerge, collide, produce new structures. There are patterns in the Game of Life that function as logic gates. There are patterns that function as memory. There are patterns that replicate themselves. The GoL is Turing complete — you can, in principle, run any computation inside it using nothing but the four rules above.

This bothered me the first time I really understood it. It still bothers me now.

Computational Irreducibility

Wolfram explored what this means in his 2002 book A New Kind of Science, and one concept from that work has genuinely never left me.

He called it computational irreducibility.

When we do physics, we observe a phenomenon, abstract a formula from it, and use that formula to predict future behaviour. A pendulum swings; we write down a differential equation; we evaluate it for any future time t without having to simulate every intermediate position. The formula collapses the computation. We get to skip ahead.

Wolfram argued — and showed, for specific rules — that for certain systems this is simply impossible. There is no closed formula. There is no shortcut. The only way to know what state the system will be in after a million steps is to run it for a million steps. The simulation cannot be compressed. The future is not analytically accessible from the present.

For the Game of Life specifically: you cannot look at a starting pattern and calculate its state after ten thousand generations without actually computing all ten thousand generations. There is no formula. The universe of the GoL must be lived through, not solved.

And that is exactly why the next question feels so unsettling.

Assuming for a Moment

What if our universe is that kind of system?

Not a metaphor. The actual conjecture: that physical reality is a cellular automaton, or something functionally equivalent to one — a discrete state space evolving by local rules, step by step, producing complexity that no observer inside it can predict without running the whole thing.

Wolfram has spent real effort on this. It is not a casual speculation.

If it is true, then physics as we practise it — observe, abstract, predict — works only in the limited regime where the computation happens to be compressible. For simple things, on short timescales, the formulas work. The pendulum, the projectile, the ideal gas. We mistake that compressibility for a general property of nature.

But push far enough into complexity, or far enough into the future, and you hit the irreducibility wall. No equation will get you there. You must simulate.

The Particle in the Box

Statistical physicists have a word for this wall: entropy.

Entropy is a genuinely wild concept — a complete mystery for most people even after years of studying it. I think about it this way. Imagine a sealed box with one particle inside. You have unlimited time and unlimited instruments. You measure the particle's position and momentum to whatever precision your instruments allow. You close the box. Time passes.

Where is the particle $10^{-27}$ seconds later? Essentially where you left it.

Where is it 1 second later? Tractable, with some uncertainty from measurement error and from the bouncing geometry.

Where is it $10^{27}$ seconds later? At this point the uncertainty has compounded so severely that your answer covers essentially the entire box. The measurement you made at the start is no longer useful. It has been drowned by the accumulation of error across every collision.

This is entropy, in one framing: in an isolated system, the precision with which you can describe the future state can only decrease over time. You started with a measurement. That measurement ages. Every step forward is a step toward irreducibility.

What I find striking is the shape of this argument. Entropy is usually taught as a thermodynamic concept — heat, disorder, the direction of time. But when I look at it from the side of computational irreducibility, it feels like the same thing stated differently. The system is not yielding its future to analysis. The only way to know where the particle is going to be is to let it go there.

Maybe entropy is the signature of irreducibility. Not just a measure of disorder, but a measure of how far ahead the universe refuses to be calculated.

The Edge of Chaos

I do not know whether I would prefer to live in a universe that is, at bottom, a rule table — a matrix of zeros and ones ticking forward under four constraints that nobody chose.

But if that is what we are, we are clearly in Class 4. Not dead uniformity. Not frozen periodicity. Not meaningless noise.

We are at the edge of chaos, where gliders emerge from noise, structures persist long enough to collide, and something that looks almost like purpose arises from nothing more than local arithmetic.

I looked again at the simulation my friend sent me — endless recursive Life inside Life — and I felt strangely comforted.

I am not sure whether to find that frightening or sufficient.

Building a Personal Journal Bot with Telegram, Gemini, and Docker

Stephan -All Input Is Error- Bökelmann — Sun, 03 May 2026 00:00:00 +0000

I have been meaning to journal consistently for years. The friction has never been motivation — it has always been the blank page. Opening a text editor, deciding on a format, remembering what happened, structuring it. By the time I have done all of that, the thought I wanted to capture has either sharpened itself into something obvious or dissolved entirely.

So I built a bot that does the structuring for me.

What it does

You send a message to a Telegram bot. The bot asks you one follow-up question. You answer. It might ask another. After two or three exchanges it writes a journal entry, extracts a topic note in Obsidian-compatible markdown, and commits both to a private git repository.

Voice messages get transcribed. Photos get analysed — Gemini looks at the image and asks what drew your attention there, or what you were trying to capture. The bot remembers what you have been thinking about over the past week and uses that as background context when deciding what to ask next.

At 23:30 each night it compiles the day's entries into a LaTeX chapter. Every Saturday afternoon it sends a written summary of the week and a compiled PDF of the memoir via Telegram.

Todos work too. "I need to call the doctor tomorrow" gets classified as a todo for tomorrow's date, not a journal entry. Uncompleted todos roll over to the next day at 22:00.

The whole thing runs as a Docker container on a cheap VPS. One-command setup.

The conversation design

The follow-up question approach took a few iterations to feel right.

The first version generated all questions upfront — three at once, delivered as a list. It felt like filling in a form. The thought I had was already gone by the time I finished answering question three.

The second version asked one question at a time, but generated the next question without looking at what had already been answered. So it would ask about context, I would explain, and then it would ask about context again from a different angle. Repetitive.

The version that works generates each question fresh, with the full history of what has been said so far. The prompt instructs the model to decide whether there is still one genuinely worthwhile thing to ask — or to declare itself done. For technical or project-related thoughts it asks about decisions and next steps. For personal or emotional thoughts it tries to deepen understanding rather than extract facts. If it decides enough has been covered, it returns the string DONE and the bot moves straight to writing.

It caps out at three rounds regardless. Three turns of back-and-forth is usually enough to turn a half-formed thought into something writable.

The context system

The quality of follow-up questions improves significantly with context. "I'm stuck on the auth refactor again" is a much more useful starting point if the bot knows that you spent the last three days working on that refactor than if it has no background at all.

After the daily memoir chapter is compiled, the bot saves a compact bullet-point summary of the day — not the full entries, just the key themes, decisions, and open questions. These summaries are loaded as background context when generating follow-up questions.

The context rolls up over time:

Every Sunday: a weekly summary is built from that week's daily summaries
The 1st of every month: a monthly summary is built from the weekly summaries
January 1st: a yearly summary is built from the monthly summaries

None of this is visible to you unless you open the files. It just makes the questions better.

On the Gemini API

I had not used the Google Gemini API before this project. A few things I learned:

The SDK changed. The old google-generativeai package is deprecated. The new one is google-genai — note the missing ative — with a completely different import and client structure: from google import genai, then genai.Client(api_key=...). If you find yourself looking at FutureWarning messages about this, switch packages.

Model names are a moving target. In the course of a single day I had 404 errors from gemini-2.0-flash, gemini-2.0-flash-lite, gemini-1.5-flash, and gemini-2.5-flash-preview-04-17. The model that works is gemini-2.5-flash. Without the preview suffix, without a date suffix.

For anyone hitting quota limits on the free tier: gemma-3-4b-it is available through the same API key and has a significantly higher quota. The tradeoff is that it does not support multimodal input — no voice transcription, no image analysis. But for pure text journaling it works well.

The multimodal API for audio is straightforward once the model name is right. You send the raw audio bytes with a mime type of audio/ogg and ask for a transcription. Gemini handles Telegram's voice message format without any conversion.

The LaTeX memoir

This part was more annoying than expected, in an instructive way.

pdflatex needs to be run from the directory containing main.tex, not from a temp directory. The reason is that \input{chapters/2026-05-03} is a relative path — it resolves correctly when the working directory is memoir/, and fails with "file not found" when it is anything else. The fix is subprocess.run(..., cwd=str(memoir_dir)) rather than running from a temporary directory.

The microtype package causes a crash with some font setups unless you disable expansion explicitly: \usepackage[protrusion=true,expansion=false]{microtype}. This is not obvious from the error message.

The LaTeX chapter style prompt went through two iterations. The first generated chapters in a reflective, somewhat literary style — long paragraphs, metaphors, the kind of writing that sounds like someone trying to write well. I did not want that. The second prompt specifies: sober, direct, one idea per paragraph, no embellishment, report what happened. The results are considerably more useful for actually remembering what was going on.

The SSH key handling

The bot runs in a Docker container and needs to push to a private git repository via SSH. Getting this to work cleanly took longer than the LLM integration.

The issue is that /root/.ssh in the container is mounted as read-only (so the host keys cannot be written back), but SSH wants to write known_hosts. The solution is to copy the keys to a writable temp location in the entrypoint script, add GitHub's known hosts there manually, and point SSH at that location via GIT_SSH_COMMAND.

Additionally, SSH will prefer authorized_keys over actual identity files if it finds them — so the entrypoint explicitly tries id_rsa, then id_ed25519, then id_ecdsa in order, rather than letting SSH pick arbitrarily.

Git in newer versions also refuses to operate on repositories owned by a different user. Running the container as root and cloning into /repo means you need git config --global --add safe.directory /repo before any git operations.

The repository structure

After a few weeks of use, the journal repository looks like this:

journal/         — daily markdown files
topics/          — Obsidian-compatible topic notes, one per extracted concept
attachments/     — photos, organised by date
memoir/          — LaTeX source and chapter files
  main.tex
  chapters/
context/         — compact summaries for the bot's memory
  2026-05-03.md
  weeks/
  months/
  years/
todos/           — JSON files, one per day

The topics directory is the part I find most interesting over time. A topic file for, say, deep-work gets a new dated section every time you mention something related to it. After a few months you have a document that shows how your thinking on a subject evolved — which decisions you made, which ones you revisited, what changed. Obsidian can render these with the full backlink graph.

What is missing

A few things I did not build today that would make this more complete:

Editing. There is no way to correct an entry after it has been written. You would have to open the git repository and edit the file directly.

Search. The bot can write and commit, but cannot answer "what did I write about X last month?" — that would require either an embedding index or a smarter read path.

Multiple users. The bot is single-user by design — it checks the chat ID against an environment variable and ignores everything else. Making it multi-user would require persistent state per user, which the current in-memory state dict does not support.

Running it

The repository is at github.com/MaxClerkwell/telegram_journal_bot. The README has the full setup walkthrough — BotFather, Google AI Studio API key, deploy keys, the works. The short version:

git clone git@github.com:MaxClerkwell/telegram_journal_bot.git
cd telegram_journal_bot
bash setup.sh
vim .env
docker compose up -d

If you build something on top of this or find something broken, the issues tab is open.

The Recursion Problem in Relational Algebra

Stephan -All Input Is Error- Bökelmann — Fri, 24 Apr 2026 00:00:00 +0000

Relational algebra is the theoretical backbone of every query you will ever write against a relational database. Selection, projection, join, union — five or six operations, and you can express almost any query imaginable. Almost.

There is one class of problem it cannot touch, and understanding why is one of the more instructive moments in database theory.

What Relational Algebra Is Good At

A relational algebra expression takes one or more relations (tables) as input and produces a new relation as output. The expression is finite: a fixed number of operations, applied once, returning a result. This is a feature, not a bug — it makes queries predictable, optimizable, and mathematically well-behaved.

Consider a simple employee table with columns id, name, and manager_id. Finding all employees who report to a specific manager is straightforward:

σ_{mana g e r_{i d} = 42} (E m pl oyee)

Done. One selection operation, one pass over the data.

Where It Breaks Down

Now consider a different question: Find all employees who report to manager 42, directly or indirectly — the entire subtree of the org chart.

This is a transitive closure problem. To answer it, you need to follow manager_id links until they run out. But relational algebra has no concept of "repeat this until nothing new is found." Every expression has a fixed depth, determined at query-write time, not at query-run time.

You could manually unroll it:

R_{1} = σ_{manage r_{id} = 42} (E m pl oyee)

R_{2} = R_{1} ⋈_{i d = mana g e r_{i d}} E m pl oyee

R_{3} = R_{2} ⋈_{i d = mana g e r_{i d}} E m pl oyee

⋮

But how many levels deep is the hierarchy? You don't know. And if you did, the query changes every time the data changes. This is not a query — it's a program.

This is not a gap that got overlooked. Relational algebra was designed around closed-form expressions precisely because that constraint is what makes them analyzable and optimizable. Recursion requires a fixed point — "keep going until the result stops changing" — and that is fundamentally outside the algebra's scope.

The Standard Answer: A Necessary Compromise

SQL introduced WITH RECURSIVE (common table expressions, CTE) specifically to fill this gap. It works. For org charts, bill-of-materials trees, network routing tables, and any other recursive structure, it is the right tool.

But it is worth being honest about what it is: an extension beyond relational algebra, grafted onto SQL because real data is sometimes recursive and databases need to handle it. It is not elegant theory — it is pragmatic engineering. Use it when you need it, but recognize that you have left the clean mathematical foundation behind the moment you do.

Other approaches handle this more naturally. Datalog, for instance, treats recursion as a first-class concept and sits closer to the theoretical ideal. But Datalog is not what runs in production.

Why This Matters for You

When you model a domain, the choice of data structure has consequences. A flat relation is fast, clean, and fully expressible in relational algebra. A recursive structure — a tree, a graph — requires either a recursive SQL extension, a denormalized adjacency list, or a different database paradigm entirely (graph databases like Neo4j exist for exactly this reason).

Knowing this before you design a schema means you can ask the right question early: Is this data inherently recursive? If yes, plan accordingly. If no, keep it relational and keep your queries clean.

The recursion problem is not a flaw in relational algebra. It is a precise statement of what the model is and what it is not. Understanding the boundary is half the job.

A Database Is Not an API

Stephan -All Input Is Error- Bökelmann — Fri, 24 Apr 2026 00:00:00 +0000

When we set up databases for clients at nerd_force1, one rule holds without exception: the database is never the outermost layer. This post explains why, and what we put in front of it instead.

The Temptation of Direct Access

Every relational database ships with access control. MySQL has users and privileges. PostgreSQL has roles and schemas. You can, technically, hand a client a connection string and call it done.

The problem is that a database's built-in access model is designed for database administrators, not for application users. It answers questions like "can this user read this table?" — but not "can this user read their own rows in this table, filtered by their organization, with rate limiting, and with that action logged?" For anything beyond the simplest internal tooling, the native access control is the wrong abstraction.

Views and stored procedures are the traditional workaround: define the allowed queries inside the database, expose those, hide the rest. This works, but it has costs. Logic leaks into the database layer where it is hard to version, hard to test, and hard to hand off to a client who does not employ a DBA. The database becomes responsible for things it was not designed to own.

What We Do Instead

We model the database in UML and express the allowed operations as predefined queries in relational algebra — not SQL code, but the logical structure: what data is needed, how it is joined, what filters apply. SQL is an implementation detail of that intent, not the documentation of it.

In front of the database we run a thin API layer — typically FastAPI. Each allowed operation becomes an endpoint. The URL is the contract; the SQL behind it is an internal concern.

Client
  │
  ▼
Keycloak (Authentication & Authorization)
  │
  ▼
FastAPI (Predefined endpoints, input validation, logging)
  │
  ▼
Database (PostgreSQL / MySQL — never directly reachable from outside)

Keycloak handles authentication and issues tokens. FastAPI validates those tokens, enforces authorization rules, and routes requests to the appropriate query. The database receives only parameterized queries from a trusted service account. No client ever touches a connection string.

Why This Holds Up

The database stays clean. Schema design, normalization, and indexing are not polluted by access-control workarounds. The data model reflects the domain, not the security requirements.

Behavior is testable and versionable. An API endpoint is a function. You can write unit tests for it, version it, document it with OpenAPI, and replace the underlying query without touching the contract.

Authorization is explicit. What a user can do is defined in one place — the API layer — not scattered across database roles, view definitions, and stored procedure grants.

The client gets a stable interface. If the schema changes, the API absorbs the change. The client's code does not break.

The Short Version

A database is for storing and querying data with integrity guarantees. An API is for defining what the outside world is allowed to ask, and how. These are two different jobs. Giving them to the same system means both are done worse than if they were separated.

When clients come to us with a database problem, we almost always end up drawing the same diagram: a database behind a FastAPI service, with Keycloak in front of that. It is not a clever trick. It is just a clean separation of concerns — and it holds up over time.

If you are designing a system where a database needs to be accessible to more than one service or one team, start there.

DBMS 01: Why a Filesystem Is Not a Database

Stephan -All Input Is Error- Bökelmann — Thu, 23 Apr 2026 00:00:00 +0000

Yes, I'm aware: nobody in production actually stores sensor data as 120 CSV files in a flat directory. At least I hope not. But that's precisely why this works as a teaching exercise — it's artificial enough to be harmless, and realistic enough to sting.

The first practicum I built for the DBMS course at THGA Bochum (DBMS_01) doesn't teach students how SQL works. It teaches them why SQL exists.

The Setup

Students generate synthetic sensor data: temperature readings from four sensors, three times a day, over thirty days. That's 120 CSV files and 360 rows total. Nothing exotic. Exactly the kind of mess that accumulates when a small team decides "we'll figure out the storage later."

Then they solve three tasks:

Filter and sort readings from one specific sensor.
Find all measurements above a threshold within a date range.
Compute min, max, and average per sensor across the full dataset.

Twice. Once with shell tools. Once with SQL against a SQLite database.

Where It Breaks Down

Task 1 is fine. grep, sort, done. Everyone feels good about themselves.

Task 2 is where the cracks appear. Date range filtering across files named by date means matching filenames against a range, looping, and then filtering contents. It works. It's just longer than it has any right to be for such a simple question.

Task 3 breaks the illusion completely. Aggregating across 120 files while tracking per-sensor state requires either a temporary file, an associative array, or a nested loop. At this point the shell script isn't solving a data problem anymore — it's solving a parsing problem that shouldn't exist.

The SQL versions stay flat. Three lines for Task 1. Five for Task 2. One GROUP BY for Task 3.

The Thing That Lands

The shell pipeline tells the computer how to find the answer. SQL tells the database what the answer looks like.

That distinction — imperative vs. declarative — is easy to define on a slide and very hard to actually feel. Students who write the shell version first and then write the SQL version have the comparison running in their heads. No slide needed.

Why SQLite

No server. No installation. No credentials. sqlite3 sensors.db and you're in.

Every removed obstacle is a removed excuse for the concept not to land. The goal is for students to spend their cognitive budget on the query language, not on connection strings.

What This Doesn't Cover

Transactions, normalization, indexing, query planning — all of that comes later. This practicum makes exactly one claim: for structured data you need to query, a database gives you a better language than a filesystem does.

Once you've felt that, rather than been told it, everything else builds on solid ground.

The repository is open: github.com/MaxClerkwell/DBMS_01. If you want to work through it yourself, fork it and work in your own copy — that's the intended workflow. If that concept is new to you, start with the first exercise from my Introduction to Programming course (PP1), which walks through exactly that.

If We Can Measure It, You Can Improve It

Stephan -All Input Is Error- Bökelmann — Mon, 20 Apr 2026 00:00:00 +0000

Robotics gives machines hands. AI gives machines judgment. Monitoring gives machines senses. Without the senses, the hands are blind and the judgment is deaf.

The Apple on the Tree

Ten years ago, as a student, I asked myself a simple question: why does this apple cost money?

The apple growing on the branch costs nothing. The apple in the store costs something. The difference is human labor — hands that picked it, trucks that moved it, systems that tracked it. Every euro in the price tag is a unit of human time that had to be spent.

If that is true, then the path to making humanity genuinely richer is not to work more. It is to need fewer human hours per unit of civilization.

This is why we build what we build.

The Uncomfortable Truth

Most people fear automation because they think in zero-sum terms: machines take jobs, humans starve. This is wrong — historically wrong and philosophically wrong.

The printing press didn’t kill scribes to enrich publishers. It made knowledge accessible to everyone. The steam engine didn’t enslave workers — it eventually freed them from fourteen-hour days in the field. Every wave of automation that looks like destruction from the inside looks like liberation from the outside.

We are at the beginning of the greatest liberation in human history. And most people are still arguing about whether to allow it.

A few things we hold to be true — and stand behind:

Most operators think they are watching their processes. They are watching indicators. Indicators are not data.
Everyone is racing to add AI to their factory. Nobody asks where the data comes from. You cannot solve in the abstract domain if your transform is broken.
The consultant who tells you to rip and replace is selling you their project, not your solution. The world runs on installed base. It always will.
Critical infrastructure that isn’t monitored isn’t critical — it’s just unexamined risk.

What We Actually Believe

We build monitoring systems. That sounds modest. It isn’t.

A machine that cannot monitor itself cannot maintain itself. A machine that cannot maintain itself requires human attention. And humans watching machines is precisely the kind of work that should not require humans.

We believe: machines should do everything that machines can do — so that humans are free to do everything that only humans can do.

We are convinced that the soul is not a process. Not a pattern. Not an emergent property of sufficient compute. The creative, the musical, the philosophical, the spiritual — these are not outputs of a sufficiently trained model. They are the signature of something that cannot be automated, and we will never pretend otherwise.

We work only on projects that move humanity toward a state where more people can live creatively, without worrying about food on the table. If a project does not serve that direction, we are not interested.

The Transform

There is a concept in mathematics that I use every day outside of mathematics: the Laplace transform.

When a differential equation cannot be solved in its original domain, you transform the problem into an abstract space where the solution becomes tractable — then you transform back. Physics describes the world in measurable quantities. Mathematics provides abstract solutions. Engineers translate those solutions back into reality.

This is how we approach every problem. We do not fight complexity where it is hardest. We transform. We solve. We return.

When I chose my field, I looked at robotics first. Exciting, well-funded, visible — and crowded with a thousand companies building manipulators. Then LLMs and autonomous reasoning — equally crowded. But when I looked at actual industry, I saw something unexpected: the transformation step was broken.

Data was being extracted from PLCs through protocols never designed for scale. Or entered by hand into SAP forms. Neither is a real transform — one is a bottleneck, the other is a human acting as a transducer.

The gap was not in robotics. The gap was not in AI. The gap was in the instrument itself.

A monitoring system is that instrument — the transform applied to the physical world.

The physicist stands before a phenomenon: vibration, temperature, current, pressure. They do not solve it in the noisy, continuous, messy original domain. They describe it formally. That formal description is what makes computation possible.

The sensor is the act of transformation. The data stream is the abstract domain. The anomaly detection, the predictive model, the threshold alert — these are the solutions, computed where solutions are easy. And the actuation, the maintenance call, the adjusted process parameter — that is the inverse transform, back into physical reality.

But the sensor alone is not enough. A raw signal without a time series database, without cleaning, without context is not usable by any analytical system. The physicist does not just measure — they record, annotate, calibrate, and structure. A monitoring system is the automated physicist: it captures the signal, stores it with temporal precision, strips the noise, adds the context, and delivers something that analysis, prediction, and prevention can actually act on. We design and build every system with that full chain in mind — not just data collection, but data that is ready to be reasoned about.

You cannot solve problems in the abstract domain if your transform is lossy, delayed, or manual. This is not a metaphor for us. It is the operating principle.

The Instrument

We believe the sensor must be native to the network.

Not polled through serial middleware. Not manually entered. Not bridged through industrial protocols that predate the internet. USB and TCP/IP — the same connectivity that made the web universal.

Our preferred device: a PoE unit that plugs into a switch, receives its address via DHCP, announces itself on the local network via slook, and is ready to be found. No configuration wizard. No integration project. Plug in — and it works.

Where network infrastructure does not reach, we go wireless: WiFi with battery, LoRa or cellular with energy harvesting. But we are honest about the physics: the further a device is from its processing environment, the worse the signal. Bandwidth falls. Accuracy falls. Latency rises. This is not a complaint about wireless technology — it is a law of physics, and we respect it. We optimize for proximity. We treat distance as cost.

The Installed Base Is the World

We focus on retrofit. Not greenfield.

This is a philosophical choice as much as a commercial one.

The factories that exist, the machines that run, the processes that produce — these are not going to be torn down and rebuilt as ideal systems. They are what they are. They represent decades of engineering, capital, and institutional knowledge. Greenfield projects are the exception. The world as it stands is the rule.

We believe it is better to make what exists measurable than to build perfect systems that never touch the machines that actually run civilization. Every retrofit installation is an act of transformation: a previously opaque process becomes legible, computable, improvable.

That is where we work. And we have been proving it for twelve years — in nuclear cooling circuits, mine shafts, Montana rivers, rail switching systems, defense platforms, and semiconductor fabs.

Who We Are

Auto-Intern was founded by Odin Holmes — a hardware and firmware designer from the woods of Oregon — and Prof. Dr. Benjamin Menküc, whose advisory fingerprints remain on the architecture. When I, Stephan Bökelmann, joined in 2014, Odin and I changed the business model: from USB interfaces for automotive OBD to if we can measure it, you can improve it.

Today we are around twenty engineers from physics, electrical engineering, computer science, and cybersecurity. The people who shape the work: Odin on hardware and firmware, Tabea Bökelmann on frontends and APIs, René Glitza on federated and fully homomorphic learning, Philipp Lehmann on security and deployment.

Alongside Auto-Intern GmbH — the measurement device company — we run nerd_force1, which builds the server-side: our own data center, Kubernetes and Ceph clusters, security-first from the ground up. Sensor to server, owned end to end.

Our customers are in large manufacturing, critical infrastructure, and defense. Wherever an unmonitored process quickly becomes very expensive.

The Future We Are Building Toward

There will be automated production on other planets. Not because we are science fiction enthusiasts, but because it is the logical conclusion of everything we are building toward — supply chains that do not depend on human presence in a specific location, systems that maintain themselves, infrastructure that extends the reach of human civilization without extending its cost.

We are techno-optimists. The process of transformation has already begun. The question is not whether it will happen — it is whether we will shape it with moral clarity and engineering rigor, or let it happen to us.

If we do this right, the answer to the apple problem is not poverty. It is abundance. It is a world where more people have more time for the things that only humans can do: to think, to create, to question, to connect, to live as though they were made for something greater than maintenance.

That is the highest form of human striving we know. And it is the only reason we are here.

We are not naive about how long this takes. But we are clear about the direction.

Travelling to China with a Peli Case Full of Electronics

Stephan -All Input Is Error- Bökelmann — Thu, 09 Apr 2026 00:00:00 +0000

When I went to Dongguan for EMC testing in March, I brought a Peli case full of custom electronics as checked luggage. This post is the logistics companion to that trip — everything I learned about ATA Carnets, airport customs, and travelling with hardware that looks suspicious to anyone who doesn’t build it.

Why Not Just Ship It?

Shipping electronics to China for testing and back is a customs nightmare. Import duties, VAT, potential seizure, weeks of waiting. The cleaner solution for temporary export of commercial goods is an ATA Carnet — essentially a passport for your equipment. You declare that you are taking specific items out of your home country, into a foreign country, and bringing them back. No duties, no VAT, as long as everything returns.

Preparing the ATA Carnet

In Germany, ATA Carnets are issued by the IHK (Chamber of Commerce). My assistant Vanessa handled most of the paperwork, which I would strongly recommend if you have the option — the form requires a complete list of every item you’re carrying, including descriptions, values, and serial numbers.

The serial number point is important. Every significant component needs one. We went through our modules and labelled anything that didn’t already have a serial number. This paid off at every customs checkpoint: when an officer picks up a device and asks what it is, you point to the serial number, point to the list, and that’s the end of the conversation. Without serial numbers, you’re explaining what an Edge Compute Module is to a customs officer at 6am.

Timeline in Germany:

IHK: approximately 4 business days from application to ready document
Zollamt Bochum: about one hour in-person, no appointment needed

Go to the Zollamt in person. They check everything on the list against what you’ve actually packed, then stamp and sign the document. After that, you’re cleared for departure.

Packing

I used a Peli case with foam cut to fit. The system was packed snugly enough that nothing moved during the flight. I used two TSA-compliant locks.

One of them didn’t survive the journey. On arrival in Frankfurt I found one lock broken — the TSA key had clearly been used at some point. The second lock was fine. If you’re packing anything sensitive, assume the case will be opened in transit and pack accordingly. Nothing was missing or damaged inside.

Frankfurt Airport: Terminal 2 and the Customs Process

If you’re flying to China from Frankfurt, note that most China routes depart from Terminal 2. Allow an extra 15 minutes to get there, and plan at least 3 hours before departure if you’re carrying ATA goods.

The process at check-in is slightly unusual. You check in at the desk to get your baggage tag — but then you ask for the bag back. Yes, they will be confused. Insist politely. You need to carry the tagged bag yourself to the customs office.

At the customs office, an officer goes through the entire list with you, item by item. Everything comes out of the case. Everything gets counted. Then it goes back in, gets stamped, and you carry the case to the bag drop that the officer directs you to. Budget 60 minutes for this process on your first time, possibly more. My assistant Vanessa’s preparation made it significantly faster — the serial numbers meant I never had to explain what anything was, just confirm it matched the list.

Arrival in China

At the Chinese customs on arrival, the process mirrors the German departure. Find a customs officer immediately — don’t walk through the green channel. Show the ATA Carnet, let them inspect, they take one of the pages, sign the document, and you’re done. It takes longer than in Germany. If someone is waiting for you, warn them in advance.

Apps to Install Before You Leave

Install these before departure, not on arrival:

WeChat — essential. Nearly everyone reachable for business in China responds faster on WeChat than email. You also need to wait a few days after installation before you can set a username, so install it early. You can add me: MaxClerkwell. Add your credit card too — WeChat Pay is the default payment method almost everywhere.
DiDi — Chinese Uber. Works reliably, some premium drivers speak English. Every driver will have a bottle of water for you.
Trip.com — hotels and train tickets.
Amap — local maps. Google Maps works with a VPN but has gaps in business listings.
Google Translate — download the English–Chinese language pack offline.

For connectivity: buy a Holafly eSIM before departure (~30 USD/week). Install it correctly before you get to the airport. European SIM data roaming costs are not worth it. Watch out for cheaper plans that prohibit hotspot sharing.

For everything else: set up a WireGuard VPN before you go. A self-hosted instance is better than a commercial VPN service. WhatsApp and Google work in China with this setup.

The Guangzhou Departure

Leaving China on the return trip is the same process in reverse — except it takes longer. Guangzhou Baiyun Airport has an unusual arrangement where customs and the security check are sequenced in a way that requires you to pass through security with your full luggage including tools. I had a screwdriver set in the Peli case, which triggered additional checks since screwdrivers are not permitted through security onto the aircraft.

The resolution was diplomatic: I explained the situation, showed the ATA Carnet, and the officers were helpful in directing me to the right channel to drop the tools as checked luggage and continue to the gate. Chinese customs officers were, throughout the trip, genuinely curious rather than obstructive — several wanted to understand what the modules actually did. Being able to explain it simply (a measurement system for industrial ovens) was worth more than any amount of paperwork.

Allow 90 minutes for the Guangzhou departure process if you’re carrying ATA goods.

On Arrival Back in Germany

Take the red channel, get the documents signed again on return. Then bring the completed ATA Carnet back to the IHK. This is a formal requirement — failing to return it means you may be liable for import duties on the declared value of everything you took.

Summary Checklist

Weeks before departure:

Install WeChat, set username, add payment card
Apply for ATA Carnet at IHK (allow 4+ working days)
Label all items with serial numbers
Buy Holafly eSIM, install and test before airport
Set up WireGuard VPN
Buy TSA-compliant locks (assume they will be used)

At Frankfurt airport:

Depart from Terminal 2 (most China routes)
Allow 3 hours before departure
Check in, get baggage tag, take bag back
Go to customs office with ATA Carnet — plan 60 min
Drop bag where customs officer directs you

On arrival in China:

Go directly to customs, do not use green channel
Present ATA Carnet without hesitation

Returning from China (Guangzhou):

Allow 90 minutes for customs + security
Pack tools in checked luggage or be prepared to check them separately

Back home:

Return completed ATA Carnet to IHK

Questions about factory visits in China or EMC testing? Hit me up on WeChat or X.

EMC in Dongguan: 2.5 Years of Work, 4 Days in a Test Chamber

Stephan -All Input Is Error- Bökelmann — Wed, 01 Apr 2026 00:00:00 +0000

In March I flew to Dongguan, China for four days of EMC testing. It was the last major milestone before our reflow oven monitoring system goes into production. After two and a half years of development, the question was simple: does this thing radiate, and can it take a hit?

It passed. But the story is more interesting than that.

The Project

The system was commissioned by GlobalPoint GmbH , now part of Kurtz Ersa GmbH & Co. KG , one of the leading manufacturers of reflow soldering equipment. The brief: build a monitoring system that attaches to Ersa’s reflow ovens and gives operators real-time insight into what is actually happening inside the machine — not what the oven thinks is happening, but what the physics says.

The development was handled by skainet.io, the engineering office of Auto-Intern GmbH. I served as system architect. Odin Holmes owned firmware and PCB layout, and Tabea Bökelmann designed and built the frontend. Two and a half years. A lot of iteration.

What the System Does

The core of the system is a central compute module — a compact Linux box with a quad-core processor and more RAM than you would expect for its size. It has two separate Ethernet interfaces: one dedicated WAN uplink, and one connected to an integrated switch chip that exposes seven downstream ports, all of them Power over Ethernet.

Every downstream device is powered and communicated with over those PoE ports. At minimum, the system ships with:

A temperature measurement module — our own design, with custom-made temperature measurement snakes that take in-situ readings at up to 36 points directly inside the solder oven, streaming live to the compute module.
A digital I/O module — reads up to 7 IO-Link sensors and drives a stacklight for at-a-glance status indication.

In the drawer we have further modules in various stages of readiness: vibration, IR camera, temperature/humidity, residual O₂, and ultrasonic structure-borne sound. They weren’t part of this certification run, but the architecture is ready for them.

The compute module auto-detects whatever is connected, loads the calibration files, and exposes the data via REST, WebSocket, and MQTT. On the Ersa machine PC, an Electron frontend consumes those APIs to display profile predictions and process quality indices — CPK and several others.

Travelling with professional electronics across borders comes with its own paperwork. I covered the Peli case setup and the ATA Carnet process in a separate post.

The Test Setup

The lab was NTC — Nore Detection Technology Co., Ltd in Dongguan. We tested against three regulatory frameworks: CE (Europe), FCC (USA), and CCC (China). The full test sequence ran over four days:

Burst (EFT)
Surge
5-second power interruption
Radiated emissions
Radiated immunity
Conducted emissions
Conducted immunity
Magnetic field
ESD

We were not going in blind. We had done preliminary testing in Germany, and we have accumulated a fair amount of PoE-specific EMC experience over the years. All our housings are aluminium. The cables are M12 Cat5e SF/UTP — shielded foil, unshielded twisted pair — which behaves predictably in a test chamber if the mechanical coupling is done correctly.

Everything came back green.

The One Finding

During the test we noticed that the M12 connectors on the downstream devices did not have adequate coupling to their aluminium housings. The anodized surface was acting as an insulator between the connector shell and the enclosure — not ideal when you are trying to maintain a continuous shielded path.

The fix is straightforward: serrated lock washers (Fächerscheiben) under the M12 connector nut. The teeth cut through the anodizing and create a reliable metal-to-metal bond. We did not need to retest, but this goes into the production build as a specification change.

It is exactly the kind of thing you catch when you are in a proper chamber with someone experienced watching the traces.

The Lab, and Jees

I was expecting a language barrier and I found one — very few people in and around the lab spoke English. But my project manager, 熊伟 , who goes by Jees, spoke excellent English and was present throughout all four days. Attentive, knowledgeable, flexible in how we sequenced the tests. He also handed me several EMC tips that I had not encountered before, which alone made the trip worthwhile.

What surprised me most was the scale of the facility. NTC had far more test chambers than I anticipated — you could run multiple concurrent certifications across different standards without ever waiting for a chamber. The whole operation felt more fluid than equivalent labs I have used in Germany.

I will be back.

Beyond the Lab

Dongguan is not just a testing stop. While I was there I also sat down with a cable manufacturer, visited Faytech and NextPCB, and met with a handful of engineers who had been passed along to me through various contacts. Each of those conversations produced at least one useful lead or piece of information.

My hotel was next to a sports park. Every morning I ran laps with a group of elderly locals who were entirely unbothered by the foreign engineer in their midst and very friendly once I stopped looking lost. I spent several evenings with Chinese acquaintances — KTV, good restaurants, the kind of conversations that only happen when you are somewhere unfamiliar and have to pay attention.

Getting around on Didi was seamless. Dongguan is a serious manufacturing city and it moves accordingly.

What Comes Next

The certification results go back to Kurtz Ersa. Production planning can start. After two and a half years of development it is a strange feeling — not relief exactly, more like the moment when a long measurement finally stabilises and you can read off the value.

The extended sensor suite (vibration, IR, rest-O₂, ultrasonic) will follow in a subsequent version. The architecture is already there. It just needs time.

The team: Odin Holmes (firmware, PCB layout), Tabea Bökelmann (frontend). Developed at skainet.io for Kurtz Ersa GmbH & Co. KG.

Ten Years of Conferences: What They're Actually For

Stephan -All Input Is Error- Bökelmann — Sun, 15 Mar 2026 00:00:00 +0000

In 2015 I went to my first real conference. I came back a different engineer. That sounds dramatic, but it's accurate, and it took me a while to understand why. This post is an attempt to write that down — both for myself, after ten years, and for the companies, universities, and open-source projects that keep asking us at Open Skunkforce e.V. how we think about this.

Meeting C++, 2015

I went to Meeting C++ 2015 with my colleague Odin Holmes. At that point I thought I was a reasonably competent programmer. I was wrong — not in the way that's demoralising, but in the way that only becomes visible when you're suddenly in a room full of people who have been thinking deeply about problems you haven't encountered yet.

I didn't know what I didn't know. I heard talks on topics I had no idea existed. I had conversations in corridors that reframed things I thought I understood. Some of those conversations turned into projects. Some turned into friendships that are still going today.

That's the thing about conferences that doesn't translate into any other format: you cannot Google your way to the questions you haven't thought to ask yet. A talk puts an idea in front of you. A conversation in the hallway afterwards tells you what that idea means in your situation. You go home with a list of things to learn that you didn't know you needed to learn.

The List

Over the past ten years, roughly:

As attendee or speaker:

Meeting C++ — 2015, the beginning
code:dive, Wrocław — many years in a row
FOSDEM, Brussels — regularly for eight years
KiCon US, Chicago 2019 — organised by Chris Gammel
ISO C++ Committee Meeting, Kona 2019
ISO C++ Committee Meeting, Prague 2020
PANDA and GSI collaboration meetings — multiple
NVIDIA C++ Meetup, Silicon Valley
KiCon Asia 2025, Shenzhen — as speaker
Various smaller conferences and user groups in Germany and the Netherlands

As organiser (with Open Skunkforce e.V.):

emBO++ — embedded C++ conference, Bochum, every year since 2015
OpenTapeout — open-source chip design, first edition 2021
Practical Datascience Conference (PDSC)
KiCon Germany — four editions from 2020
KiCon Europe 2024 — Rotunde Bochum, 150 attendees
CPPP, Paris — marketing and video production, on invitation from Fred Tingaud

That is a lot of rooms. A lot of evenings. A lot of hallways.

The Moments That Stay

Three moments from the past decade stand out when I try to articulate what conferences are actually for.

Kona, 2019. I was at the ISO C++ Committee meeting — not as a voting member (I don't hold a DIN seat, so I could participate actively in discussions but not vote), but as a working participant. The Pacific coast outside the venue looked like this every morning:

One evening I found myself at dinner with Bjarne Stroustrup and Herb Sutter. The conversation was direct, curious, practical. The kind of exchange that only happens when everyone at the table has decided to take the time seriously.

Wrocław, code:dive. Sean Parent and Bartosz Milewski ended up with Odin, Tabea, and me in a bar until well past any sensible hour. The conversation went everywhere — category theory, compiler internals, what it means to write software that is honest about what it does. I've learned more in evenings like that than in entire conference days.

Silicon Valley. Tabea and I were at an NVIDIA C++ meetup when Barbara Gellar and Ansel Sermersheim — authors of the CopperSpice GUI framework — walked up and asked if we were the people who organised emBO++. That conversation turned into an invitation to stay at their home for four days. We spent those days talking about C++, software design, and what it means to build tools that last. We're still in regular contact today.

None of these moments were scheduled. None of them appear on any programme. They happened because people who care about the same things ended up in the same place, with time to talk.

emBO++: Eleven Years

The arc of emBO++ is the clearest illustration I have of how this compounds over time.

The first edition, 2015: four people in a room. The second: speakers from Russia to San Francisco, 40 attendees. It felt unreasonably large at the time. By 2020 we had 250 people in Bochum — the last edition before COVID.

Going online during the pandemic worked, technically. But something was missing. The talks were fine. The questions-and-answers were fine. What you cannot replicate over video is the moment after the talk ends, when someone turns to the person next to them and says "did you notice that detail he mentioned in passing?" — and that becomes a two-hour conversation over dinner.

Conferences have not fully recovered since COVID. That's the honest picture. Attendance is lower than it was. The habit broke. This bothers me most when I think about students and people early in their careers — the ones who would benefit most from being in a room where the level is higher than anything they've encountered before.

The Broader World

Conferences are not only about software. Some of the most formative meetings I've attended were PANDA and GSI collaboration meetings at GSI Helmholtzzentrum für Schwerionenforschung in Darmstadt — particle physics, large-scale detector hardware, international teams building instruments that take decades to complete.

The dynamics are different from a software conference, but the core is the same: the real work happens in the corridors, at the dinner table, in the conversations that drift far from the official agenda.

At KiCon Europe 2024 in Bochum, the same pattern held. 150 people, two days, the Rotunde. Lukas Hartmann's talk on open hardware CPU modules set off conversations that continued well past the venue closing.

Open Skunkforce also runs smaller, focused events throughout the year — user groups, workshops, single-topic evenings — where the same principles apply at a smaller scale.

What a Good Conference Actually Is

Here is what we have learned from organising events for a decade:

Talks set the agenda. Conversations are the output. A good talk gives the audience something to argue about. The argument happens in the hallway, at dinner, at the bar. If people leave immediately after the last session, the conference has half-succeeded.

The pre-event evening is not optional. Every conference we run includes a social the evening before the programme starts. People arrive, meet each other without the structure of sessions, and come to day one already knowing who they want to talk to.

Dinner outside the venue belongs in the programme. Not a sponsored cocktail reception in the conference hall. A table at a restaurant, with speakers and attendees mixed. The conversations that happen there are the ones people mention years later.

100–200 people is the sweet spot. Large enough for real diversity — different industries, backgrounds, experience levels. Small enough that you can find the people you want to talk to, and that the speakers are genuinely accessible. Beyond 300, a conference starts to become a trade fair.

Staying in the hotel room after the conference is the biggest mistake you can make. I have made it. Everyone has made it. It is always a mistake.

What We Offer

Open Skunkforce e.V. organises technical conferences in and around Bochum. We handle everything:

Programme design and speaker acquisition
Marketing and public communications
Venue booking and logistics
Catering, including the pre-event social and the dinner
Video recording and post-production
Publishing recordings openly after the event

We have been doing this for ten years. We have the speaker network, the sponsor relationships, the venue contacts, and — most importantly — the experience of what goes wrong and how to fix it before it matters.

The format we know best is two days, 100–200 attendees. That maps well to a focused technical community: an open-source project that wants to bring its contributors together, a company that wants to build a developer community around its tools, a university group that wants to connect its research with practitioners in industry.

If you have been thinking about running a conference but don't know where to start — or have tried and found the logistics overwhelming — that is exactly the problem we exist to solve. Get in touch.

Open Skunkforce e.V. is a registered non-profit based in Bochum. Find us at skunkforce.org or reach out directly via the contact on this site.

Dual Uplink for 15 People: Starlink, Heimdall, and Linux Routing

Stephan -All Input Is Error- Bökelmann — Fri, 27 Feb 2026 00:00:00 +0000

At some point, one internet connection isn’t enough. We hit that point when 15 people were working in the office simultaneously and the line was noticeably sluggish — video calls, git pushes, remote access, all sharing a single uplink. Philipp and I tackled it in February.

Philipp is our server administrator — still working on his bachelor’s degree, but already operating at a level that leaves many professional admins behind. Together we’ve set up mesh backhauls, VPNs, intranets, a Kubernetes cluster, Ceph storage, Keycloak for all our internal services — and quite a bit more. If a service runs in our office, Philipp either built it or knows every corner of it. The network upgrade in February was one more chapter in a long list.

The Starting Point

Our existing network was a standard setup: one uplink, backbone switches behind it, everything running over that single path. It works — until it doesn’t. Either because bandwidth runs out, or because the provider has a bad day. We’d had both.

The fix was obvious: add a second uplink. We went with Starlink — quick to install, independent of our DSL provider, and well-suited to our location.

The actual goal was resilience: if one link goes down, the office keeps running without anyone having to intervene.

Heimdall

Between the two uplinks and the existing backbone switches we added a small new rack. Inside: a Debian rack PC, hostname AI-heimdall.

The name is not accidental. Odin Holmes — a close collaborator I’ve worked with for years — established the tradition of giving some of our projects and machines names from Norse mythology. The first library Odin and I wrote together was called Kvasir. The habit stuck. Heimdall — the watchman of the gods, who observes all nine worlds and misses nothing — was too fitting for the gateway into our network to pass up.

AI-heimdall has the two uplinks coming in as separate interfaces: eno1 for DSL (static IP into the modem), eno2 for Starlink via DHCP. The internal network runs on eno4 with the 10.42.0.0/16 address space towards the backbone switches.

The routing configuration uses two default routes in the Linux main routing table, differentiated by metric: DSL runs with a lower metric and is preferred, Starlink sits alongside it with metric 1003. As long as the DSL gateway is reachable, all traffic goes that way. If DSL drops, Starlink takes over automatically — no manual intervention, no visible outage for anyone in the office.

For the future, two named tables are already registered in /etc/iproute2/rt_tables — starlink (200) and dsl (201) — as preparation for proper policy routing that directs individual connections over a specific uplink. For now, the failover model is exactly what we need.

The Dashboard

To see what is actually going over which link at any given moment, I wrote a small Python dashboard. It reads the interface statistics for both uplinks and displays throughput and utilisation in real time — simple enough to leave running on a screen in the office.

It also served as a practical sanity check: the dashboard makes it immediately obvious if everything is routing over one link when it shouldn’t be, or if something is wrong.

What It Changed

The bottlenecks are gone — and when the DSL line has a hiccup, nobody in the office notices. That’s the real gain: not more bandwidth on paper, but reliability in practice.

The actual work was the clean integration on AI-heimdall: two interfaces, correct metric configuration, making sure the Starlink DHCP lease doesn’t write a default route into the main table that displaces DSL. Philipp handled the Starlink installation and the physical setup, and knows every layer of the existing network that AI-heimdall now sits in front of; the routing configuration was my part.

If you’re building something similar: two default routes with different metrics in /etc/network/interfaces is enough for clean failover. Per-host load balancing requires additional ip rule entries pointing to named routing tables — that’s the next step we’ll take with the starlink and dsl tables already in place.

Ten Years of PowerSense: Blood, Sweat, and Ferrite Cores

Stephan -All Input Is Error- Bökelmann — Thu, 15 Jan 2026 00:00:00 +0000

January 2016. A call came in through a mutual contact — Steffen Scholle, at the time an Ex-inspector at DEKRA and today a respected Ex-consultant — connecting us with DB Netz AG. They had a problem: they needed a smarter way to monitor the power supply of their railway switching systems. Three-phase, 16A lines, 1.5mm² cross-section. And they needed it non-intrusively, clip-on, retrofit. No rewiring. No outages. No excuses.

All the pieces already existed internally — E-field sensing, Hall probes, PoE prototypes — and the moment we heard the requirement, we knew exactly what to assemble. January 2016 was the moment it became real. A customer with a real problem, a real network, and real consequences if the measurements were wrong.

Ten years later, that call is still one of the most consequential things that ever happened to this company.

The First Meeting

We met the DB Netz team in Frankfurt. Their initial idea: an RS-485-connected sensor, daisy-chained across the installation. We declined. Not out of arrogance — out of conviction. RS-485 was the wrong answer to the wrong question. You don't build the future of industrial monitoring on a serial bus from 1983.

After several conversations, we landed on Power over Ethernet. PoE. We had already used it in smaller projects, already understood its potential. But this was the first time we had the chance to apply it at scale, in a critical infrastructure context, with a customer willing to push it through qualification together with us.

All the components were there. What could possibly go wrong?

The Four Problems Nobody Warned Us About

Quite a lot, as it turned out. As the requirements crystallized, four challenges emerged that would define the next five years:

Ultra-low power consumption — under 2W total, including all measurement and communication
Extreme EMC conditions — railway certification standards, high demands on dielectric strength and touch safety
Ultra-fast installation — clip-on, no tools beyond what a technician carries, seconds per unit
Non-contact voltage measurement — no galvanic connection to the conductors

The first three were hard. The fourth was the one that kept us up at night.

The Problem of Voltage Without Contact

Here is something most engineers don't think about carefully enough: voltage is always a potential difference between two points. There is no such thing as an absolute voltage. You measure it between two references.

So how do you measure voltage when you have three phase conductors inside an IT network and you are not galvanically connected to any of them?

The short answer: you don't measure voltage directly. You measure the time-varying electric field each conductor produces, capture its influence on an antenna, and reconstruct the voltage waveform from there.

We had built E-field sensing circuits before — that prior work saved us. Our approach: three pairs of flat patch antennas, one pair per phase, placed on the top and bottom surfaces of a thick PCB. The board's normal vector aligned radially to the conductors. Through the 2mm PCB thickness, the electric field decreases with distance as 1/r (long straight conductor approximation), so the two antenna surfaces see slightly different field strengths — and the differential between them scales as 1/r².

That differential — tiny, noisy, deeply buried in interference — is what we amplified with a carefully tuned op-amp circuit and fed into an ADC. Get the gain and filtering right, and you see clean 50Hz sinusoidal waveforms from three conductors that you have never electrically touched.

To recover absolute voltage values, we added a single galvanically connected voltage reference measurement per switching station — one point in the network where we knew the actual supply voltage. That scalar reference, combined with our normalized E-field measurements, gave us calibrated voltage readings across the entire installation.

The current measurements, by comparison, were trivial. Hall sensors, standard technique. Or so we thought — until the housing changed everything.

The Housing Problem

On the bare PCB, everything worked. Beautiful signals, clean data, happy engineers.

Then we put it in a housing.

Together with Christian Czayka, we developed three different enclosure concepts in 3D CAD, printed the first variants, and assembled prototypes: elegant, compact, tool-free installation. The kind of device you look at and immediately understand how to fit it.

But when the PCB moved inside the housing and the conductors moved further from the antennas, the E-field signals weakened. For voltage sensing, we compensated with higher gain and a tighter frequency filter — manageable.

For current, the situation was different. We needed to see harmonics — the full spectral content of the current waveform, not just the fundamental. Brute-force amplification destroys that. Filtering kills it. We needed a different approach.

The solution: B-field collecting ferrite cores embedded directly into the clamping clips that hold the conductors. The geometry was non-trivial. Getting the ferrite dimensions, permeability, and positioning right required weeks of field calculations and FEM simulations — work that fell to Tabea Bökelmann, who I had met during our physics studies and who is, without qualification, significantly better at mathematics than I am.

The ferrites were custom-manufactured for us, embedded into the prototype clips, and the signals came back. Clean harmonics. Full spectral resolution. A device that worked not just in the lab, but as an actual product that could be assembled by a technician in the field.

Young, Naive, and Almost There

At this point — roughly two years in — we genuinely believed we were almost done. The physics worked. The electronics worked. The housing looked right. We had a team that knew what it was doing.

We were in our early-to-mid twenties, which explains a lot. Odin was already thirty, which in Oregon hippie years is basically a senior engineer — though it did not appear to grant him any additional realism about the timeline either.

What followed was two more years of EMC certification at CETECOM, transitioning the housing from 3D-printed prototypes to injection-molded production parts together with LB Kunststoff, and the full qualification cycle under railway standards. Dielectric strength. Touch safety. Vibration. Temperature cycling. The kind of testing that finds every corner you cut and every assumption you made.

We finished. It took longer than we planned. It always does.

What This Project Taught Us

Looking back now, a decade later, the skAInet-PowerSense was not just a product. It was an education.

PoE first. Always. If you commit to PoE, you get TCP/IP, power, and a standards-compliant physical layer in a single cable. Everything the network has to offer becomes accessible to your device. We have not seriously considered an alternative since 2016.

Digitize as close as possible to the source. The moment you convert a physical signal to bits, you can apply error correction, checksums, timestamps, and all the reliability mechanisms that decades of networking research have produced. Analog signals degrade. Digital packets either arrive or they don't.

A working PCB is not a finished product. This is perhaps the hardest lesson for hardware engineers to internalize. The electronics are phase one. What follows is a product development process that is at least as demanding. Today, we structure our projects accordingly:

PoC (3–6 months): Looks nothing like the product. Integrates all the physical measurement principles. Validates that the science works.
Prototype (6–9 months): Looks like the product. Manufactured by hand. Proves the form factor and installation concept.
Prototype of Product (~12 months): Manufactured using the same processes as eventual series production. The first object you can genuinely call a device.

We estimate wrong every time. We estimate less wrong than we used to.

The skAInet-PowerSense is still in service across DB Netz switching stations. It monitors power supply quality in infrastructure that moves millions of people every day, without anyone on the platform knowing it exists.

That is what good monitoring looks like.

There Is More

This post barely scratches the surface. What I have not covered: inter-channel crosstalk and how we characterized and compensated it, PoE shutdowns caused by drawing too little current (yes, that is a real problem — the standard assumes you need power, not that you are carefully conserving it), the sensitivity of every measurement to the exact relative positioning of conductors and PCB, and the full calibration workflow that ties all of it together into a number you can trust.

Every one of those deserves its own post. Maybe one day.

The People Behind the People

None of this would have been possible without the continuous support of people who believed in the work before it was finished.

Lukas Jakubczyk and Prof. Gereon Kortenbruck at the PROLAB — Laboratory for Product and Production at THGA Bochum — were there throughout. Prof. Benjamin Menküc, co-founder of Auto-Intern and by this point already a professor for EMC and medical engineering at FH Dortmund, kept advising from the sidelines even after stepping back from day-to-day operations. And Dr. Florian Feldbauer of the EP1 chair at the Faculty of Physics, Ruhr-Universität Bochum, provided the kind of rigorous physics perspective that keeps engineers honest.

We are genuinely grateful to have RUB, THGA, and FH Dortmund as partners — reliable, deeply professional, and always willing to push back when we need it.

Our real secret superpower is not the hardware. It is that we take these relationships seriously and keep the conversation going. Regularly, honestly, and without agenda. That is rarer than it sounds.

If any of this is relevant to something you are building — or if you just want to go deep on non-contact sensing, EMC in rail environments, or PoE power budgeting — come find me on Discord. I enjoy talking about this stuff more than I probably should.

Discord — Full Stack EngineeringDirect access to me and my colleagues. Webinars, live Q&A, and community discussions for engineers across the full stack.Join the server →