docToolchain ist das Referenz-Werkzeug für arc42/req42-Dokumentation. Es baut HTML und PDF aus AsciiDoc-Quellen — zuverlässig, erprobt, gut integriert.

Was es nicht tut: bei kaputtem AsciiDoc abbrechen. Fehlende Includes, aufgelöste Cross-Referenzen, Syntaxfehler — docToolchain meldet sie als Warnung und baut trotzdem weiter. Am Ende hat man ein PDF mit Platzhaltern, wo eigentlich Inhalte stehen sollten.

In einer CI-Pipeline ist das fatal. Der Build ist „grün", das Artefakt ist kaputt.

Der ghcr.io/tpo42/adoc-Container (der aus dem Jekyll-Post bekannte) enthält nicht nur die AsciiDoc-Toolchain, sondern auch ein validate-Kommando. Dahinter steckt ein asciidoctor-Aufruf im Strict-Modus: fehlende Dateien, kaputte Referenzen, Syntaxfehler — alles wird zum Fehler, nicht zur Warnung.

Die Idee: Validierung vor dem Build. Erst wenn die Quellen sauber sind, darf docToolchain bauen.

Statt alles in einen Container zu packen, trennen wir die Concerns:

Das Bindeglied ist eine docker-compose.yml:

Beide Container laufen dauerhaft (sleep infinity). Befehle gehen per docker compose exec rein — kein Container-Start-Overhead pro Aufruf.

Die .devcontainer/devcontainer.json referenziert dieselbe Compose-Datei:

devcontainer up startet beide Container. Der adoc-Container ist der Primary — dort editiert und validiert man. Der doctoolchain-Container läuft als Sidecar für Builds.

Oder mit der devcontainer-CLI — zumindest für den adoc-Container:

Für den doctoolchain-Container geht das (noch) nicht: devcontainer exec kennt nur den Primary-Service, kein --service-Flag. Für den Build bleibt docker compose exec.

docToolchain basiert auf Gradle. Jeder docker run startet eine neue JVM, initialisiert den Gradle-Daemon, lädt Plugins — rund 40 Sekunden, bevor überhaupt etwas gebaut wird.

Der dtcw-Wrapper setzt bewusst --no-daemon, weil der Daemon bei Einmal-Containern sowieso stirbt. Wenn der Container aber lebt (sleep infinity + docker compose exec), bleibt der Daemon warm:

Der Gradle-Cache liegt in einem Named Volume (dtc-gradle-cache) und überlebt docker compose down / up-Zyklen. Nur docker compose down -v räumt ihn ab.

Das ist kein Trick — es ist schlicht die Arbeitsweise, für die Gradle entworfen wurde. docker run erzwingt den Cold-Start, den Gradle eigentlich vermeiden will.

In der CI-Pipeline (Jenkins, GitLab CI, …​) laufen die Container als Einmal-Aufrufe. Der warme Daemon bringt dort nichts — dafür ist die Validierung als Gate entscheidend:

Wenn Validate fehlschlägt, laufen die Build-Stages nicht. Kein kaputtes PDF in den Artefakten.

Dieses Setup dokumentiert nur Anforderungen und Architektur — es gibt keinen Quellcode zu kompilieren. In einem Firmware-Projekt kommt mindestens ein dritter Container dazu: der Cross-Compiler. Und bei Projekten mit herstellerspezifischer Code-Generierung (STM32CubeMX) ein vierter, der Artefakte über ein Shared Volume an den Compile-Container weitergibt.

Die docker-compose.yml skaliert dafür linear — ein Service pro Concern, dieselbe Compose-Datei für Devcontainer und CI.

Aber dazu mehr, wenn es soweit ist.

Nehmen wir an, der Cross-Compiler ist ein GCC 15 mit newlib. Die Unit-Tests laufen auf dem CI-Host, also brauchen wir dort ebenfalls einen GCC 15 — nicht den GCC 14, den Fedora 43 mitbringt, und schon gar nicht den GCC 13 aus dem Ubuntu-LTS der CI-Runner.

Dazu kommen ABI-gekoppelte Werkzeuge:

Wenn man das manuell pflegt, landen Target- und Host-Toolchain schnell in getrennten Beschaffungsketten. Das muss nicht sein.

Vor einigen Jahren bei einem Telekommunikationsausrüster: Ein SoM mit Netzwerk-Beschleunigern, dazu ein Binary-SDK vom Chip-Hersteller. 32-Bit, eine uralte GCC-Version, gelinkt gegen eine Linux-Distribution, die es nur noch auf dem Schwarzmarkt gegen Kamele gab. Lange bevor LLVM/Clang als ernstzunehmende GCC-Konkurrenz die Stagnation aufmischte.

Die IT betrieb dafür einen Multiprozessor-Knoten mit rund 64 VMs — je 2 VCPUs, 2 GB RAM, komplett überbucht, kaum wartbar. Das SDK ließ sich nicht reproduzieren, nicht aktualisieren und nicht auf eine andere Host-Plattform portieren. Dabei war der Chip sogar Linux-fähig — da wäre deutlich mehr gegangen.

Das Muster habe ich seitdem mehrfach gesehen: Chip-Hersteller wollen Chips verkaufen, keine Entwicklungsumgebungen. Das SDK ist Beiwerk — es erleichtert den Einstieg, soll aber nicht langfristig tragen. Ein Hersteller-BSP auf LTS-Basis, jahrelang gut genug — und wenn der LTS-Zyklus ausläuft, heißt es: Updaten, in sechs Wochen liefern, nichts darf kosten.

Das hat mich motiviert, einen anderen Weg zu gehen.

Das Yocto Project ist primär als Build-System für Embedded-Linux-Distributionen bekannt. Aber sein Rezept-System kann mehr: Es baut beliebige Toolchains aus den Quellen — und zwar für verschiedene Zielarchitekturen aus denselben Rezepten.

Der Schlüssel ist die MACHINE-Variable. Dieselben Rezepte für GCC, newlib, Google Test und gcov erzeugen je nach Target:

Die Liste ließe sich fortsetzen. Der Punkt ist: Ob ARM Cortex-M, RISC-V oder Host-nativ — die Rezepte sind dieselben. Nur MACHINE und die zugehörige Tune-Konfiguration unterscheiden sich.

Eine Quelle, eine GCC-Version, eine ABI-Kopplung — DRY und SSOT statt n getrennt gepflegte Toolchains.

Yocto baut dabei nicht nur den Compiler: Auch ein QEMU für das jeweilige Target lässt sich aus denselben Rezepten erzeugen. Damit kann man Firmware-Binaries auf dem CI-Host emulieren — ohne echte Hardware, aber mit der richtigen CPU-Emulation. Für Integrationstests auf einem Cortex-M oder RISC-V ist das Gold wert.

Die erste Intuition ist: Nur der Compiler und seine unmittelbaren Abhängigkeiten. In der Praxis zieht man die Grenze weiter.

Aus Yocto — eingefroren und versioniert:

Der gemeinsame Nenner: Alles, was das Build-Ergebnis oder die Analyse des Build-Ergebnisses beeinflusst, muss einfrierbar und reproduzierbar sein. clang-tidy klingt zunächst orthogonal — bis man merkt, dass es die Target-Header parsen muss, nicht die des Host-Systems.

Aus der Distribution — unabhängig aktualisierbar:

Diese Werkzeuge beeinflussen weder das Binary noch die Analyse und können unabhängig aktualisiert werden — ohne Firmware-Requalifizierung.

Ein Nebeneffekt der Yocto-basierten Toolchain: Man hat volle Kontrolle über die Compiler-Flags, und zwar in sauberen Schichten.

Auf Bare-Metal fehlen die üblichen OS-Schutzmechanismen (_stack_chk_fail ohne libc, kein ASLR ohne Loader, kein PIE ohne MMU). Aber GCC 13+ bietet Hardening-Flags, die _ohne OS funktionieren:

Diese Flags landen nicht in der Toolchain selbst (sonst würde newlib nicht mehr bauen), sondern in einem SDK-Environment-Hook — einer dünnen Shell-Datei, die beim Aktivieren der Toolchain die CFLAGS/CXXFLAGS setzt. Drei Schichten:

In regulierten Branchen liefert man Firmware-Fixes für Produkte, die vor 10 oder 15 Jahren ausgeliefert wurden. Mit einer Yocto-basierten Toolchain ist das ein git checkout auf den Release-Stand und ein bitbake meta-toolchain — fertig.

Yocto liefert dafür zwei Mechanismen, die oft als Implementierungs- detail abgetan werden, aber für das Release-Management essentiell sind:

Beide Verzeichnisse zusammen bilden das Rückgrat für langfristige Nachlieferbarkeit: Quellen gesichert, Build-Ergebnisse nachvollziehbar, Rebuild-Zeiten beherrschbar.

Mit dem Cyber Resilience Act wird die Frage „Was steckt in meiner Toolchain?" regulatorisch relevant. Ein SBOM (Software Bill of Materials) mit voller Provenance ist keine Kür mehr — es wird Pflicht für Produkte mit digitalen Elementen.

Yocto erzeugt SPDX-SBOMs als Nebenprodukt des Builds — für jede Komponente, die aus den Quellen gebaut wurde. DL_DIR liefert die Quellenarchivierung, die Rezepte liefern die Abhängigkeitskette, und INHERIT += "create-spdx" bindet beides zu einem maschinenlesbaren SBOM zusammen.

Aus Yocto gebaut heißt: Die Provenance stimmt per Konstruktion, nicht per Vertrauen. Das ist ein echtes Pfund, wenn der Auditor vor der Tür steht.

Cross-Compiler für Bare-Metal gibt es an jeder Ecke. Der Mehrwert von Yocto liegt nicht im Cross-Compiler selbst, sondern darin, dass Target-Toolchain, Host-CI-Toolchain und alle Werkzeuge drumherum aus derselben Quelle kommen — reproduzierbar, einfrierbar, CRA-ready.

Die Einstiegshürde ist real: Yocto hat eine steile Lernkurve. Aber wer den Schritt wagt, bekommt eine Toolchain-Infrastruktur, die mit jedem neuen Target und jedem neuen Projekt mitträgt — statt jedes Mal bei null anzufangen.

Der Container ghcr.io/tpo42/adoc bringt Ruby 3.x, Bundler 4.x und die komplette Asciidoctor-Toolchain mit (asciidoctor, asciidoctor-pdf, asciidoctor-diagram, …). Jekyll und seine Plugins sind nur ein bundle install entfernt — kein Grund, das Host-System zuzumüllen.

Images wie bretfisher/jekyll-serve funktionieren, bringen aber ihr eigenes Ruby und Gem-Set mit. Wenn der Content AsciiDoc ist, braucht man die Asciidoctor-Toolchain und Jekyll — zwei getrennte Container oder ein aufgeblähtes Custom-Image.

Mit ghcr.io/tpo42/adoc als Basis bekommt man Asciidoctor für die Dokumentenverarbeitung (flatten, validate, Diagramme extrahieren via adcw) und Jekyll zum Servieren — aus einem einzigen Image, gesteuert über das Gemfile des Projekts.

Der adcw-Wrapper braucht keinen Devcontainer. .adoc-Dateien lassen sich jederzeit validieren:

Das startet einen kurzen docker run --rm — kein langlebiger Container nötig.

Die zentrale Unterscheidung ist nicht die Höhe des Vermögens, sondern seine Funktion. Die Frage lautet nicht “Wie viel besitzt jemand?”, sondern “Trägt dieses Vermögen zum Allgemeinwohl bei — oder nicht?”

Vermögen gilt als gemeinwohldienlich, wenn es mindestens eines der folgenden Kriterien erfüllt:

Was besteuert wird: Ausschließlich Vermögen, das durch keine bestehende Steuer erfasst wird und keinen messbaren gesellschaftlichen Nutzen erzeugt.

Was nicht besteuert wird: Jedes Vermögen, das bereits über Kapitalertragsteuer, Einkommensteuer, Gewerbesteuer oder andere Abgaben zum Gemeinwohl beiträgt. Ebenso Vermögen, das gemeinnützig gewidmet ist oder durch aktive Inhaberführung Arbeitsplätze schafft.

Steuersatz: 1–2 % jährlich auf das nicht-gemeinwohldienliche Vermögen.

Freibetrag: Eine großzügig bemessene Lebensbedarfsgrenze, die Wohnen, Bildung, Vorsorge und einen substanziellen Sicherheitspuffer abdeckt. Alles darunter ist grundsätzlich von der Vermögenssteuer befreit.

Bewertungszeitraum: Die Gemeinwohldienlichkeit wird über einen rollierenden 3- bis 5-Jahreszeitraum bewertet, um konjunkturelle Schwankungen und Wirtschaftskrisen nicht sinnlos zu verschärfen.

Kernmerkmal: Es gibt per Design keine Doppelbesteuerung, da die Vermögenssteuer nur in der Lücke greift, die bestehende Steuern nicht abdecken.

Die Erbschaftssteuer folgt derselben Logik: Wer beiträgt, trägt bei. Wer noch nicht beiträgt, hat jetzt die Chance.

Vererbung eines operativen Unternehmens: Wer ein Unternehmen erbt und es mindestens 10 Jahre in direkter Inhaberschaft fortführt, zahlt keine Erbschaftssteuer. Der gesellschaftliche Beitrag wird durch den Betrieb erbracht. Bei Verkauf nach Ablauf der Frist wird der Verkaufserlös als reguläres Einkommen versteuert.

Vererbung von passivem Vermögen: Wer ein Aktiendepot, Sachwerte oder andere passive Vermögenswerte erbt, versteuert diese bei Veräußerung als Einkommen. Es gibt keinen Anspruch auf steuerfreie Weitergabe von Vermögen, das keinen aktiven Beitrag zum Allgemeinwohl leistet.

Entscheidende Unterscheidung: Direkte, persönlich verantwortete Inhaberschaft wird privilegiert. Anonyme Anteilseignerschaft — also die bloße Vererbung von Kapitalbeteiligungen ohne operative Verantwortung — wird behandelt wie jedes andere passive Vermögen.

Keine Neidsteuer. Das Modell richtet sich nicht gegen Reichtum, sondern gegen brachliegendes Vermögen. Wer mit seinem Vermögen wirtschaftet, Arbeitsplätze schafft oder Erträge versteuert, wird nicht zusätzlich belastet.

Keine Leistungsfeindlichkeit. Im Gegenteil: Das Modell privilegiert aktives, produktives Eigentum gegenüber passivem Besitz. Es belohnt den Unternehmer und besteuert den Rentier.

Keine Umverteilungsideologie. Der Ausgangspunkt ist das Grundgesetz, nicht ein politisches Programm. Art. 14 Abs. 2 GG formuliert eine Pflicht — dieses Modell operationalisiert sie.

Administrierbarkeit: Die Bewertung von “Gemeinwohldienlichkeit” erfordert klare, einfache Kriterien. Je komplexer das System, desto mehr profitieren diejenigen mit den besten Steuerberatern. Die Kriterien müssen so formuliert sein, dass sie regelbasiert und nicht ermessensbasiert angewendet werden können.

Konkrete Lebensbedarfsgrenze: Die genaue Höhe des Freibetrags muss politisch verhandelt werden. Ob 25 oder 40 Millionen Euro — die Zielgruppe beginnt mindestens bei Faktor 10 darüber.

Deklarationspflicht: Um Umgehung zu verhindern (das “Rembrandt-auf-dem-Dachboden”-Problem), braucht es eine jährliche Deklarationspflicht für Vermögen oberhalb der Lebensbedarfsgrenze, inklusive Sachwerte. Nichtdeklaration wird sanktioniert.

Rechtsstaatliche Ausgestaltung: Die konkrete juristische Umsetzung — insbesondere Fragen der Rückwirkung und der Vereinbarkeit mit europäischem Recht — erfordert fachliche Expertise und ist in diesem Konzeptpapier bewusst nicht abschließend behandelt.

"`Eigentum verpflichtet`" — wer dieser Verpflichtung nachkommt, ist steuerlich bedient; wer nicht, zahlt Vermögenssteuer.

Dieses Konzept entstand aus einer strukturierten Debatte, in der die Annahmen bewusst und systematisch stressgetestet wurden. Es erhebt keinen Anspruch auf juristische Vollständigkeit, sondern versteht sich als Denkrahmen für die politische Diskussion.

2018 schrieb ich WDR-Redaktionen anlässlich des 20. Deutschen Perl-Workshops in Köln. Internationale Konferenz, 200+ Teilnehmer, direkt vor der WDR-Haustür. Die Antwort der Lokalzeit-Redaktion:

Aktuelle Stunde? Keine Antwort. Wissenschaftsredaktion? Schweigen. Weitere Redaktionen? Totenstille.

Gerade diese Woche: External Secrets Operator für Kubernetes vor dem Aus — nur noch ein Maintainer, völlig überarbeitet. Gernot Starke (arc42, 20 Jahre!) berichtet: “Eine Million Downloads jährlich, hunderte Unternehmen nutzen es täglich — aber Contributions? Nahe Null.”

Das ist die Realität unsichtbarer Communities: Genutzt von allen, unterstützt von wenigen, berichtet von niemandem.

Während Millionen für Fußball-Übertragungen fließen, kostet ein Bericht über deutsche Tech-Communities offenbar zu viel Aufwand für eine Antwort.

Und das sind nur die, die mir in 30 Sekunden einfallen. Was würde echte Recherche zutage fördern?

Aber Sie zeigen lieber die nächste Influencer-Doku.

Dazu gehört zu zeigen, wer unsere digitale Zukunft gestaltet. Das sind nicht nur die üblichen Verdächtigen aus dem Silicon Valley — das sind auch Menschen aus Köln, Düsseldorf, Essen.

Und diese Menschen gehören in die Prime-Formate, nicht nur in Bildungs-Nischen.

Stellen Sie sich vor: “Austausch in der TH Köln: Coocook-Begründer auf Konferenz” — das wäre in der Lokalzeit eingeschlagen wie eine Bombe. Echter lokaler Bezug, echte Innovation, echte Menschen. Hintergrund-Recherchen gern in Bildungsformaten — aber die Stories müssen raus aus der Nische!

Beauftragen Sie eine Redaktion mit einer Serie über deutsche Tech-Communities. Zeigen Sie die FrOSCon, die Chemnitzer Linux-Tage, den German Perl Workshop. Zeigen Sie die Menschen dahinter.

Nicht als “Nerd-Spektakel”, sondern als das, was es ist: Die Arbeit an unserer gemeinsamen digitalen Zukunft.

Werden Sie die Intendantin, die den Unterschied macht?

Mit freundlichen Grüßen und konkreten Erwartungen,
Jens Rehsack