Jekyll2026-04-22T19:59:17+00:00https://rehsack.de/feed.xmlJens RehsackPersönlicher Blog von Jens Rehsack — Technik, Meinung, LebenJens RehsackPARIS statt RACI: Verantwortlichkeiten für req42 und arc422026-04-22T00:00:00+00:002026-04-22T00:00:00+00:00https://rehsack.de/2026/04/22/paris-statt-raci

„In den letzten 30 Jahren hat das immer der Erwin gemacht."

So beginnen viele Gespräche, wenn ein Mittelständler feststellt, dass Verantwortlichkeiten unklar sind. Erwin wusste, wo seine Werkzeuge liegen. Erwins Chef sagte: „Mach das mal" — und dann lief das. Tradiertes Wissen, impliziter Regelkatalog, gewachsene Strukturen.

Dann geht Erwin in Rente. Und plötzlich wird klar: Die Verantwortlichkeiten waren nie dokumentiert. Sie waren in Erwins Kopf.

Die erste Antwort: RACI

Jemand sagt: „Wir brauchen eine RACI-Matrix." Das klingt professionell. RACI (Responsible, Accountable, Consulted, Informed) ist ein etabliertes Werkzeug. Es soll klären, wer für was zuständig ist, wer abnimmt, wer gefragt wird.

Das Problem ist nicht, dass RACI falsch wäre. Das Problem ist, dass RACI in bestimmten Kontexten zu grob ist.

Wo RACI an seine Grenzen stößt

RACI funktioniert gut, wenn Aufgaben klar abgrenzbar sind, die Rollen dahinter homogen, und wenn die Trennung zwischen Ausführung, Beratung und Abnahme nicht besonders fein sein muss. In operativen Bereichen — Produktion, Logistik, Support — ist das oft der Fall.

In Forschung und Entwicklung sieht es anders aus. Nicht weil F&E keine Prozesse hätte — Reviews, Freigaben, Tests, Architekturentscheidungen, Budgetsteuerung sind durchaus wiederkehrende Teilprozesse. Aber der Gesamtprozess ist nicht vollständig stabil oder vorhersagbar.

Und hier zeigt sich die Schwäche von RACI: Wenn „Responsible" mehrere fachlich unterschiedliche Beiträge gleichzeitig umfasst, wird die Matrix unlesbar.

Der Architekt ist „R" für die arc42-Dokumentation. Aber was heißt das? Schreibt er selbst? Reviewt er nur? Gibt er fachlich ab? Trainiert er das Team? Diese Fragen beantwortet ein einzelner Buchstabe nicht.

Was in F&E oft fehlt

RACI fragt im Kern: Wer arbeitet? Wer ist verantwortlich? Wer wird gefragt? Wer wird informiert?

In F&E braucht man oft mehr:

  • Wer berät die fachliche Richtung?

  • Wer prüft das Ergebnis?

  • Wer zeichnet fachlich verantwortlich ab?

„Consulted" ist dafür zu breit. Beratung ist nicht dasselbe wie fachliche Vorprüfung. Und „Accountable" vermischt oft zwei verschiedene Dinge: organisatorische Verantwortung (Budget, Zeit) und fachliche Abnahme.

Gerade in Architektur- und Entwicklungszusammenhängen ist diese Trennung wichtig. Nicht jede Person, die Budget oder Zeit verantwortet, kann auch fachlich entscheiden, ob eine Lösung tragfähig ist.

PARIS: Feinere semantische Auflösung

PARIS stammt aus dem PMBOK [1]. Es ist kein Ersatz für saubere Governance, sondern eine feinere Rollenbeschreibung dort, wo RACI zu viel in einer Spalte bündelt:

P — Participant

Arbeitet aktiv mit

A — Accountable

Trägt organisatorische Verantwortung (Budget, Zeit)

R — Review required

Prüft fachlich

I — Input required

Liefert fachlichen Input, berät die Richtung

S — Sign-off required

Zeichnet fachlich verantwortlich ab

Der Unterschied zu RACI ist nicht, dass PARIS „besser" wäre. Der Unterschied ist die Auflösung. PARIS trennt Verantwortungsdimensionen, die in F&E oft auseinanderfallen.

Warum A und S trennen?

In vielen Organisationen fallen Budget-Verantwortung und fachliche Abnahme bewusst zusammen. Das funktioniert, solange dieselbe Person beides kann.

Ein konkretes Szenario, wo es nicht funktioniert:

Der Product Owner (A) trägt die Budgetverantwortung für ein neues Feature. Wenn es länger dauert, muss er das erklären. Aber kann er auch fachlich beurteilen, ob die Architekturentscheidung tragfähig ist? Ob die Qualitätsszenarien erfüllt sind? Ob die Sicherheitsanforderungen stimmen?

In diesem Fall braucht es jemanden, der fachlich abzeichnet (S) — einen Architekten, einen QM-Beauftragten, einen Security-Experten. Die organisatorische Verantwortung bleibt beim PO. Die fachliche Abnahme liegt woanders.

PARIS macht diese Trennung explizit. RACI vermischt sie in „Accountable".

Warum R und I trennen?

RACI kennt „Consulted" — wird gefragt, gibt Input. Aber in F&E gibt es einen Unterschied zwischen:

  • Input (I): Der Fachbereich beschreibt Anforderungen. Der Kunde erklärt seinen Anwendungsfall. Ein Stakeholder liefert Randbedingungen. Das ist Beratung der fachlichen Richtung.

  • Review ®: Der QM-Beauftragte prüft, ob die Qualitätsanforderungen erfüllt sind. Der Security-Experte prüft das Bedrohungsmodell. Das ist fachliche Vorprüfung mit Ergebnis.

„Consulted" ist dafür zu breit und zu unverbindlich. PARIS unterscheidet.

Ergänzung: Konsent als Governance-Muster

PARIS selbst sagt nicht, was mit dem Ergebnis eines Reviews passiert. Hier kann Soziokratie 3.0 (S3) ergänzen:

  • Reviewer können einen begründeten Einwand erheben

  • Kein Einwand = Vorschlag gilt

  • Ein Einwand ist kein Veto, sondern ein Verbesserungsimpuls

Das ist ein zusätzliches Governance-Muster — nicht Teil von PARIS selbst. Es beantwortet die Frage: Was passiert, wenn der Reviewer Bedenken hat?

In der Praxis hängt viel davon ab, wer Einwände definiert, wann sie als schwerwiegend gelten, und wie Konflikte aufgelöst werden. Das muss jede Organisation für sich klären. S3 bietet einen Rahmen dafür.

PARIS in req42 und arc42

req42 und arc42 haben explizite Stakeholder-Kapitel. Sie fragen für jede Rolle: Warum diese Rolle? Was ist ihre Verantwortung? Welche Kompetenzen braucht sie?

PARIS liefert die Begrifflichkeit, um diese Fragen zu beantworten:

Für req42 Kapitel 2 lässt sich fragen: * Wer arbeitet mit (P)? * Wer trägt organisatorische Verantwortung (A)? * Wer prüft fachlich (R)? * Wer liefert Input (I)? * Wer zeichnet ab (S)?

Für req42 Kapitel 9 geht es dann um Rollen, Responsibilities und Skills. Genau hier wird aus einer abstrakten Matrix eine dokumentierbare Verantwortungsstruktur.

Auch arc42 profitiert davon, weil Architekturentscheidungen, Reviews und Freigaben klarer zugeordnet werden können. Wer reviewed ADRs? Wer gibt fachlichen Sign-off? Wer liefert die Anforderungen? PARIS macht diese Fragen sichtbarer als RACI.

Zusammenfassung

RACI ist nicht falsch. Es ist ein solides Werkzeug für Aufgaben- und Zuständigkeitsklärung. Aber wenn „Responsible" mehrere fachlich verschiedene Rollen zusammenzieht, wird die Matrix unlesbar.

PARIS bietet eine feinere Auflösung:

  • Trennung von organisatorischer (A) und fachlicher (S) Verantwortung

  • Trennung von Input (I) und Prüfung (R)

  • Explizite Benennung derer, die arbeiten (P)

Für F&E und Architekturarbeit — wo nicht nur gefragt wird, wer arbeitet, sondern auch wer fachlich berät, wer prüft und wer am Ende signiert — ist diese Auflösung oft notwendig.

Nächste Schritte

In einem Folgepost zeige ich, wie man eine bestehende RACI-Matrix nach PARIS übersetzt — und wo die typischen Stolpersteine liegen.

1. A Guide to the Project Management Body of Knowledge. Project Management Institute. 2000. p. 111. ISBN 1-880410-22-2.
]]>Jens RehsackResponsible Engineering Credo: Meine Antwort auf die KI-Debatte2026-04-21T00:00:00+00:002026-04-21T00:00:00+00:00https://rehsack.de/2026/04/21/responsible-engineering-credo

Seit Wochen geistert mir eine Frage durch den Kopf: Wie reden wir eigentlich über Verantwortung in der KI-gestützten Softwareentwicklung?

Manifeste und ihre Grenzen

Es entstehen gerade viele Manifeste zur KI-gestützten Entwicklung. Das AI Craftspeople Guild Manifesto ist eines davon. Gut gemeint, wichtige Themen. Aber beim Lesen habe ich gemerkt: Meine Situation kommt darin nicht vor. Mein berufliches Umfeld, meine Werkzeuge, mein Kontext — das Manifest spricht für alle Softwareprofis, aber nicht mit mir.

Das ist das Grundproblem vieler Manifeste: Sie setzen Standards, ohne die Vielfalt der Kontexte zu kennen. Semantic Anchors, Skills, Guardrails — wer täglich mit diesen Werkzeugen arbeitet, erkennt sich in pauschalen Forderungen oft nicht wieder.

Das Agile Manifesto hat das anders gemacht. „Individuals and interactions over processes and tools" ist keine Deklaration einer Gruppe, die für die Branche spricht. Es ist eine Einladung. Eine Haltung, die ich annehmen kann — oder nicht. Ich priorisiere Menschen über Prozesse. Ich entscheide mich dafür. Niemand spricht für mich.

Uncle Bob wird oft als Moralapostel missverstanden. Aber wenn man genau liest, sagt er nicht: „Ihr müsst alle Clean Code schreiben." Er sagt: „Hier sind Prinzipien, die — wenn du dich daran hältst — dir und deinem Team helfen, daran zu wachsen." Selbstwirksamkeit, nicht Fremdbestimmung.

Left over Right — für mich selbst

Also habe ich aufgeschrieben, woran ich mich halte. Kein Manifest, das anderen vorschreibt. Ein Credo — eine persönliche Verpflichtung.

Das Fundament ist einfach:

Wir übernehmen die volle Verantwortung für jede Zeile Code, die wir committen — unabhängig von ihrer Herkunft.

Die Werte folgen dem „X über Y"-Muster:

  • Verantwortbare Urheberschaft über anonyme Erzeugung

  • Durchgesetzte über versprochene Qualität

  • Vorhersagbares über angenommenes Verhalten

  • Gewährleistete über versprochene Datenintegrität

  • Persönliche Haftung über diffuse Verantwortung

  • Informierte Zustimmung über stillschweigende Annahme

Das vollständige Credo mit Erläuterungen gibt es auf GitHub: https://github.com/rehsack/Responsible-Engineering-Credo

Warum jetzt?

KI kann Code generieren. Aber Verantwortung kann nicht generiert werden — sie muss übernommen werden. Jede Zeile Code, die in Produktion geht, braucht jemanden, der sagt: „Ich stehe dahinter."

Das ist keine neue Idee. Signierte Commits gibt es seit Jahren. Code Reviews auch. Aber in einer Welt, in der ein Wochenend-Projekt plötzlich SaaS-Startup heißt und Kundendaten verarbeitet, wird die Frage drängender: Wer trägt die Verantwortung, wenn es schiefgeht?

Werkzeuge statt Vorschriften

Ein Credo ist schön. Aber wie setzt man es um? Nicht durch Regeln, die von oben kommen — sondern durch Werkzeuge, die jedes Team befähigen, seine eigenen Entscheidungen zu treffen.

Der Vibe Coding Risk Radar ist so ein Werkzeug. Fünf Dimensionen, vier Risikostufen, konkrete Mitigationen. Kein „ihr müsst diese Risiken beachten" — sondern ein interaktives Tool, mit dem du deine eigene Entscheidungsmatrix baust. Für dein Projekt, mit deinem Kontext, nach deiner Einschätzung.

Das ist der Unterschied zwischen einem Manifest, das für alle spricht, und einem Werkzeugkasten, der jeden einzelnen ermächtigt.

Die unbeantwortete Frage

Was die meisten Manifeste nicht adressieren: Wo endet meine Verantwortung in einer Welt voller Abhängigkeiten?

Ich nutze eine Government-API — die wurde mit KI entwickelt. Ich nutze npm-Pakete — irgendwer hat mit Copilot contributed. Mein Auftraggeber zahlt, dass ich keine KI nutze — muss ich dann die API der Bundesdruckerei ablehnen?

Das Credo zieht die Grenze klar: Ich übernehme Verantwortung für den Code, den ich committe. Nicht für die gesamte Lieferkette. Nicht für Government-APIs. Für meinen Beitrag.

Einladung

Das Credo ist ein Diskussionsentwurf. Ich erhebe keinen Anspruch auf Vollständigkeit oder Weisheit. Wenn es bei dir resoniert — nimm es, fork es, pass es an. Wenn du anderer Meinung bist — lass uns reden.

GitHub: https://github.com/rehsack/Responsible-Engineering-Credo

Die Zukunft der Softwareentwicklung wird nicht durch Tools entschieden, sondern durch die Menschen, die sie einsetzen. Und durch die Haltung, mit der sie das tun.

]]>Jens RehsackValidate-First: AsciiDoc-Projekte mit Devcontainer und docker-compose2026-04-12T00:00:00+00:002026-04-12T00:00:00+00:00https://rehsack.de/2026/04/12/validate-first-docker-compose-devcontainer

Im letzten Post ging es um einen einzelnen Container für Jekyll + AsciiDoc. Diesmal wird es spannender: zwei Container, die zusammenarbeiten — einer validiert, der andere baut.

Das Problem: doctoolchain schluckt Fehler

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.

Die Lösung: Validierung als Gate

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.

Zwei Container, ein Workflow

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

Container Aufgabe Image

adoc

AsciiDoc-Validierung, Toolchain für Entwicklung

ghcr.io/tpo42/adoc:latest

doctoolchain

PDF- und HTML-Build

doctoolchain/doctoolchain:v3.4.2

Das Bindeglied ist eine docker-compose.yml:

services:
  adoc:
    image: ghcr.io/tpo42/adoc:latest
    volumes:
      - .:/workspace
    command: ["sleep", "infinity"]

  doctoolchain:
    image: doctoolchain/doctoolchain:v3.4.2
    platform: linux/amd64
    volumes:
      - .:/project
      - dtc-gradle-cache:/home/dtcuser/.gradle
    entrypoint: ["sleep", "infinity"]
    environment:
      DTC_HEADLESS: "true"
      DTC_OPTS: >-
        -PmainConfigFile=docToolchainConfig.groovy
        --warning-mode=none -Dfile.encoding=UTF-8

volumes:
  dtc-gradle-cache:

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

Der Devcontainer

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

{
  "name": "mein-doku-projekt",
  "dockerComposeFile": "../docker-compose.yml",
  "service": "adoc",
  "workspaceFolder": "/workspace",
  "shutdownAction": "stopCompose"
}

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.

Der Workflow

# Container starten
docker compose up -d

# Validieren
docker compose exec adoc validate \
    -i Docs/req42-container-toolchain.adoc \
    -i Docs/arc42-container-toolchain.adoc \
    --strict --verbose

# Bauen
docker compose exec doctoolchain \
    bash -c 'doctoolchain . generatePDF $DTC_OPTS'
docker compose exec doctoolchain \
    bash -c 'doctoolchain . generateHTML $DTC_OPTS'

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

devcontainer exec --workspace-folder . validate -i Docs/*.adoc --strict

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.

Der Nebeneffekt: 40 Sekunden → 2 Sekunden

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:

Erster Aufruf Folgeaufrufe

docker run --no-daemon (klassisch)

~40s

~40s

docker compose exec (persistent)

~15s

~2s

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.

CI: Dieselben Images, anderer Ablauf

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:

Stage: Validate    →  Stage: Build PDF  →  Stage: Build HTML  →  Archive
(ghcr.io/tpo42/adoc) (doctoolchain)       (doctoolchain)

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

Was ich dabei gelernt habe

sleep infinity ist keine Krücke

Bei Task-Runner-Containern (validate, build) klingt ein dauerhaft laufender Container nach Verschwendung. Aber wenn der Container zustandsbehaftet ist (Gradle-Daemon, Gem-Cache), ist das persistente Setup die performante Variante.

DTC_OPTS als Environment-Variable

docToolchain erwartet diverse Flags (-PmainConfigFile=…​, --warning-mode=none, …​). In der docker-compose.yml als DTC_OPTS hinterlegt, spart man sich die Flags bei jedem Aufruf: bash -c 'doctoolchain . generatePDF $DTC_OPTS'.

devcontainer exec hat Grenzen

Die devcontainer-CLI kann nur in den Primary-Service execen. Für Sidecar-Container bleibt docker compose exec. Ein --service-Flag wäre ein sinnvolles Feature-Request an die devcontainers/cli.

Ausblick

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.

]]>Jens RehsackYocto für Bare-Metal: Cross-Compiler und CI-Toolchain aus einem Guss2026-04-09T00:00:00+00:002026-04-09T00:00:00+00:00https://rehsack.de/2026/04/09/yocto-bare-metal-sdk-aus-einem-guss

Wer Firmware für Mikrocontroller baut, braucht einen Cross-Compiler. Den bekommt man mit crosstool-ng, als ARM-Download oder aus dem Paketmanager der Distribution. Das funktioniert — und wenn man dann noch Unit-Tests in der CI haben will, wird es richtig spannend.

Denn dann braucht man zwei Toolchains: eine für das Target (arm-none-eabi-gcc mit newlib) und eine für den Host (x86_64 oder aarch64), mit der man denselben Code gegen ein Test-Framework kompiliert. Auf dem Host läuft natürlich eine andere libc — aber GCC-Generation, Google-Test-Version, gcov und die Analyse-Werkzeuge müssen auf Punkt und Komma zusammenpassen.

Bare-Metal klingt dabei nach wenig Aufwand: Wenn newlib schon das Maß der Dinge ist, ist der Horizont quasi anfassbar. Die Herausforderung steckt nicht in der Menge der Abhängigkeiten, sondern darin, dass die Werkzeuge drumherum für Target und Host aus einem Guss sein müssen. Genau das lässt sich elegant lösen.

Das Problem: Zwei Toolchains, eine Wahrheit

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:

  • Google Test / GMock — kompiliert gegen die jeweilige Toolchain

  • gcov / lcov — müssen zur GCC-Version passen, sonst stimmt die Coverage nicht

  • valgrind — muss die ABI der getesteten Binaries verstehen

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

Warum ich da heute anders rangehe

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.

Die Yocto-Lösung: MACHINE-Abstraktion als SSOT

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:

MACHINE Ergebnis Beispiel

aducm360

arm-none-eabi-gcc (Cortex-M3, soft-float)

Mess-MCU, ADC-Frontend

stm32h7a3

arm-none-eabi-gcc (Cortex-M7, hard-float, FPv5-D16)

Kommunikations-MCU, DCP-Stack

samd21

arm-none-eabi-gcc (Cortex-M0+, soft-float)

Kamera-Steuerung

esp32c6

riscv32-none-elf-gcc (RV32IMAC)

RISC-V IoT, Wi-Fi/BLE

gd32vf103

riscv32-none-elf-gcc (RV32IMAC)

RISC-V mit DSP-Erweiterungen, atomthreads

x86-64 / aarch64

Host-nativer GCC derselben Generation

CI: Unit-Tests, valgrind, Coverage

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.

Was gehört ins SDK — und was nicht?

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:

  • GCC + binutils + newlib (der Compiler-Kern)

  • Google Test / GMock (Test-Framework, gegen die Toolchain kompiliert)

  • gcov / lcov (Coverage — muss zur GCC-Version passen)

  • valgrind (Speicheranalyse — muss die ABI verstehen)

  • clang-tidy (statische Analyse — braucht die richtigen Header und Bibliotheken des Targets, nicht die des Host-Systems)

  • clang-format (eine eingefrorene Version verhindert Whitespace-Kriege zwischen Entwicklern)

  • CMake, Ninja (wenn das CMake der Host-Distribution plötzlich ein Major-Update bekommt, spuckt es unter Umständen in den Build)

  • QEMU (Target-Emulation für Integrationstests)

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:

  • Doxygen (API-Dokumentation)

  • srecord (ELF → HEX-Konvertierung)

  • doctoolchain, asciidoctor (Projektdokumentation)

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

Bare-Metal-Hardening: Was geht ohne OS?

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:

-fharden-compares
-fharden-conditional-branches
-fharden-control-flow-redundancy
-ftrivial-auto-var-init=zero

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:

  1. Distro-Config (Yocto): Flags, die auch newlib braucht (-ffunction-sections, -fdata-sections)

  2. SDK-Hook: Hardening und Warnungen für die Firmware-Entwicklung

  3. Firmware-Projekt (CMakeLists.txt): Projektspezifisches (-std=gnu23, Target-Defines)

Langzeitwirkung: 10 Jahre Firmware-Support

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:

DL_DIR

Das Verzeichnis, in das Yocto alle heruntergeladenen Quellen ablegt — Tarballs, Git-Snapshots, Patches. Das ist kein Nebenprodukt, das ist ein Quellenarchiv. Wer DL_DIR archiviert, kann die Toolchain auch dann noch bauen, wenn die Upstream-Server längst offline sind.

SSTATE_DIR

Der Shared-State-Cache. Yocto speichert hier die Zwischenergebnisse jedes Build-Schritts. Bei einem Release-Fix Jahre später muss nicht alles von Grund auf neu gebaut werden — der Cache beschleunigt den Rebuild auf die tatsächlich geänderten Komponenten.

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

CRA und SBOM: Vom Nice-to-have zur Pflicht

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.

Fazit

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.

]]>Jens RehsackJekyll + AsciiDoc im Devcontainer — null lokales Setup2026-04-05T00:00:00+00:002026-04-05T00:00:00+00:00https://rehsack.de/2026/04/05/devcontainer-asciidoc-jekyll

Eine Jekyll-Site mit AsciiDoc-Unterstützung aufzusetzen bedeutet normalerweise: Ruby installieren, Bundler, eine Handvoll Gems. Mit dem tpo42/adoc-Container und der Dev-Containers-Spezifikation kann man sich das alles sparen.

Die Idee

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.

Setup

1. Gemfile

Ein Standard-Jekyll-Gemfile — der Container liefert Ruby und Bundler, auf dem Host wird nichts weiter benötigt:

source "https://rubygems.org"

gem "jekyll", "~> 4.4"
gem "jekyll-remote-theme"
gem "jekyll-asciidoc"
gem "asciidoctor"
gem "jekyll-sitemap"
gem "jekyll-feed"
gem "jekyll-include-cache"
gem "webrick"

2. .devcontainer/devcontainer.json

{
  "name": "meine-site",
  "image": "ghcr.io/tpo42/adoc:latest",
  "workspaceFolder": "/workspace",
  "workspaceMount": "source=${localWorkspaceFolder},target=/workspace,type=bind",
  "postCreateCommand": "bundle config set --local path vendor/bundle && bundle install",
  "appPort": [4000, 35729],
  "forwardPorts": [4000, 35729],
  "portsAttributes": {
    "4000": { "label": "Jekyll", "onAutoForward": "notify" },
    "35729": { "label": "LiveReload", "onAutoForward": "silent" }
  }
}

Die wichtigsten Punkte:

image

Nutzt direkt ghcr.io/tpo42/adoc:latest (der "einfache Fall" aus ADR-005). Kein eigenes Dockerfile nötig.

postCreateCommand

Installiert Gems nach vendor/bundle (schreibbar für den Container-User, von .gitignore ignoriert).

appPort

Mappt Ports auf Docker-Ebene, damit jekyll serve auch ohne VS Code vom Host aus erreichbar ist.

forwardPorts

Dasselbe für VS Codes eingebautes Port-Forwarding.

3. Container starten

Mit der devcontainer-CLI:

devcontainer up --workspace-folder .

Dann die Site starten:

devcontainer exec --workspace-folder . \
  bundle exec jekyll serve --host 0.0.0.0 --livereload

http://localhost:4000 öffnen — fertig.

Warum kein eigenes Jekyll-Image?

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.

AsciiDoc-Validierung — geht auch ohne Devcontainer

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

adcw validate -i _pages/about.adoc

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

Was ich dabei gelernt habe

appPort vs forwardPorts

Die devcontainer-CLI leitet Ports nicht selbst weiter. forwardPorts ist ein VS-Code-Feature. Für reine CLI-Workflows braucht man appPort.

Gem-Berechtigungen

Der ghcr.io/tpo42/adoc-Container läuft als unprivilegierter User. bundle install ohne --path versucht in System-Gem-Verzeichnisse zu schreiben und scheitert. bundle config set --local path vendor/bundle löst das sauber.

Container-Wiederverwendung

devcontainer up nutzt bestehende Container wieder. Nach Änderungen an devcontainer.json muss der alte Container erst entfernt werden (docker rm -f <id>), bevor devcontainer up erneut funktioniert.

]]>Jens RehsackVermögens- und Erbschaftssteuer nach Art. 14 GG — ein Zwei-Säulen-Modell2026-03-12T00:00:00+00:002026-03-12T00:00:00+00:00https://rehsack.de/2026/03/12/vermoegens-erbschaftssteuer-grundgesetz

Die Macher von vergnügt (Vermögens- und Erbschaftsteuer retten Gemeinden in Not über gerechte Talerabgabe!) haben mich inspiriert, einen Gedanken, der mich über Jahre nicht losließ, im Gespräch herausfordern zu lassen und schließlich aufzuschreiben. Ich hoffe, es bereichert die Diskussion — und nun viel Vergnügen.

Eigentum verpflichtet. Sein Gebrauch soll zugleich dem Wohle der Allgemeinheit dienen.

— Art. 14 Abs. 2 GG

Dieses Modell nimmt diese Norm beim Wort und leitet daraus ein operatives Steuerprinzip ab: Vermögen, das dem Allgemeinwohl dient, ist steuerlich bedient. Vermögen, das dies nicht tut, wird besteuert.

Grundprinzip

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:

  • Es erzeugt Arbeitsplätze durch direkte, persönlich verantwortete Inhaberschaft (Beispiel: inhabergeführter Mittelständler wie Trigema).

  • Es generiert versteuerte Erträge — Dividenden, Mieteinnahmen, Betriebsgewinne — und wird damit bereits durch bestehende Steuern erfasst.

  • Es ist gemeinnützig gewidmet oder der Allgemeinheit zugänglich (Beispiel: Naturschutzgebiet, öffentlich zugängliches Kulturgut).

  • Es zeigt messbares Wachstum über einen Mehrjahreszeitraum (3–5 Jahre), was auf produktive Kapitalverwendung hindeutet.

Säule 1: Vermögenssteuer als Auffangnetz

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.

Säule 2: Erbschaftssteuer nach gleichem Prinzip

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.

Was dieses Modell nicht ist

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.

Offene Fragen (bewusst transparent gehalten)

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.

Zusammenfassung in einem Satz

"`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.

]]>Jens RehsackOffener Brief an Dr. Katrin Vernau — 7 Monate WDR-Intendantin, Zeit für Open Source?2025-08-18T00:00:00+00:002025-08-18T00:00:00+00:00https://rehsack.de/2025/08/18/offener-brief-wdr-open-source

Liebe Frau Dr. Vernau,

Sie sind seit Januar 2025 WDR-Intendantin — 7 Monate, um neue Akzente zu setzen. Haben Sie schon bemerkt, was Ihre Redaktionen seit Jahren übersehen?

Lassen Sie mich Ihnen eine Geschichte erzählen, die zeigt, warum dieser Neuanfang nötig ist:

2018: Deutscher Perl-Workshop in Köln

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:

Das Thema erscheint uns zu spezialisiert. Unsere Zuschauer sind nicht herausragend technisch interessiert.

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

2025: Die Ignoranz bleibt, aber die Probleme werden dramatischer

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.

Deutsche Entwickler sichern globale Standards ab

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.

  • Chris Badura aus Köln portiert jährlich ~4 ARM-Architekturen für NetBSD — weltweit genutzt

  • Gernot Starke feiert mit arc42 das 20-jährige Jubiläum — der Architektur-Standard in DACH

  • unByte GmbH entwickelt Self-Bootstrapping K8s — Kubernetes-Innovation aus NRW

  • Yocto Linux mit Contributoren aus Köln, NRW und ganz Deutschland steckt in Milliarden von Geräten

  • Coocook.org hilft tausenden Ferienlagern bei der Essensplanung

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.

Der WDR hat einen Bildungsauftrag

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!

Mein Vorschlag für Ihre verbleibende Amtszeit

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

Note

Falls Sie Inspiration brauchen — die New York Perl Mongers schauten 2018 nach Köln und sagten: “I had no idea how to celebrate our anniversary. Now I know.” Vielleicht sollte der WDR auch mal nach Köln schauen.
]]>Jens Rehsack