2 Tage vor
Die meisten Anfänger tippen los und wundern sich über langsame Builds. Dabei ist ein Dockerfile ein Rezept mit fester Anweisungsreihenfolge.
Ein Dockerfile beschreibt Schritt für Schritt, wie ein Container-Image entsteht. Das Image ist die unveränderliche Vorlage, aus der Container gestartet werden.
Zuerst steht die FROM-Anweisung: Sie legt ein Basis-Image fest, etwa eine schlanke Linux-Distribution mit Python. Jede Anweisung erzeugt dabei eine Schicht, und die Reihenfolge entscheidet über den Build-Cache. Selten geänderte Schritte wie Abhängigkeiten gehören deshalb vor häufig geänderten wie dem Quellcode.
Dann folgt COPY. Es kopiert Dateien aus dem Build-Kontext in das Image, also aus dem Verzeichnis, das dem Build mitgegeben wird. Ein häufiger Irrtum: Dateien außerhalb dieses Kontexts sind schlicht nicht verfügbar. Bewährt hat sich, zuerst nur die Datei mit den Abhängigkeiten zu kopieren und zu installieren, dann erst den Quellcode.
Danach kommen RUN für Installationsbefehle sowie USER. Ohne USER läuft der Prozess im Container als root, also mit vollen Rechten. Die Anweisung USER setzt einen unprivilegierten Benutzer und senkt das Risiko, falls der Container kompromittiert wird.
Zuletzt legen CMD den Startbefehl und EXPOSE den Port fest. EXPOSE dokumentiert nur, welchen Port die Anwendung im Container erreicht; geöffnet wird er erst beim Start mit docker run. Der Befehl docker build arbeitet das Dockerfile ab und erzeugt das Image, versehen mit einem Tag wie 1.2. Solche Tags sind beweglich; ein Digest wie sha256:… identifiziert dagegen genau einen Inhalt.
Ein Dockerfile ist also kein Skript, sondern ein Rezept: Jede Anweisung baut eine Schicht, und deren Reihenfolge bestimmt Tempo und Sicherheit des Images.
📌 Schichten und Build-Cache · COPY und Build-Kontext · USER statt root
📚 Cloud von Grund auf · Tag 3 von 30
#docker #devops #CloudSecurity
Ein Dockerfile beschreibt Schritt für Schritt, wie ein Container-Image entsteht. Das Image ist die unveränderliche Vorlage, aus der Container gestartet werden.
Zuerst steht die FROM-Anweisung: Sie legt ein Basis-Image fest, etwa eine schlanke Linux-Distribution mit Python. Jede Anweisung erzeugt dabei eine Schicht, und die Reihenfolge entscheidet über den Build-Cache. Selten geänderte Schritte wie Abhängigkeiten gehören deshalb vor häufig geänderten wie dem Quellcode.
Dann folgt COPY. Es kopiert Dateien aus dem Build-Kontext in das Image, also aus dem Verzeichnis, das dem Build mitgegeben wird. Ein häufiger Irrtum: Dateien außerhalb dieses Kontexts sind schlicht nicht verfügbar. Bewährt hat sich, zuerst nur die Datei mit den Abhängigkeiten zu kopieren und zu installieren, dann erst den Quellcode.
Danach kommen RUN für Installationsbefehle sowie USER. Ohne USER läuft der Prozess im Container als root, also mit vollen Rechten. Die Anweisung USER setzt einen unprivilegierten Benutzer und senkt das Risiko, falls der Container kompromittiert wird.
Zuletzt legen CMD den Startbefehl und EXPOSE den Port fest. EXPOSE dokumentiert nur, welchen Port die Anwendung im Container erreicht; geöffnet wird er erst beim Start mit docker run. Der Befehl docker build arbeitet das Dockerfile ab und erzeugt das Image, versehen mit einem Tag wie 1.2. Solche Tags sind beweglich; ein Digest wie sha256:… identifiziert dagegen genau einen Inhalt.
Ein Dockerfile ist also kein Skript, sondern ein Rezept: Jede Anweisung baut eine Schicht, und deren Reihenfolge bestimmt Tempo und Sicherheit des Images.
📌 Schichten und Build-Cache · COPY und Build-Kontext · USER statt root
📚 Cloud von Grund auf · Tag 3 von 30
#docker #devops #CloudSecurity
3 Tage vor
Ein Container ist ein Mieter im Mehrfamilienhaus: Das Fundament gehört allen, die Einrichtung ist privat. Eine virtuelle Maschine baut dagegen ein eigenes Haus mit eigenem Keller. Genauer: mit einem kompletten Betriebssystem.
Alle Mieter teilen sich dasselbe Gebäude, dieselbe Heizung und Wasserleitung. Jede Wohnung ist trotzdem abgeschlossen; der Nachbar sieht nichts hinein. Zieht ein Mieter aus, hinterlässt er nur seine Möbel, kein ganzes Haus.
Das gemeinsame Gebäude ist der Kernel, also der Kern des Betriebssystems, der Prozesse, Speicher und Hardwarezugriff verwaltet. Die abgeschlossene Wohnung ist der Prozessraum: Jeder Container sieht nur eigene Prozesse, eigenes Dateisystem und eigenes Netzwerk. Die privaten Möbel sind das Container-Image, die unveränderliche Vorlage mit Anwendung, Laufzeitbibliotheken und Konfigurationsdateien.
Ein Dockerfile beschreibt Schritt für Schritt, wie ein Image gebaut wird. Solch ein Image ist meist nur wenige Megabytes bis wenige hundert Megabytes groß, während ein VM-Abbild mit vollem Betriebssystem mehrere Gigabyte umfasst. Deshalb startet ein Container in Sekunden, während eine virtuelle Maschine erst ihr eigenes Betriebssystem bootet – bei AWS heißt dieser Dienst EC2.
Das Bild hat eine Grenze: Ein Mieter kann fast beliebig wirtschaften, ein Container braucht den passenden Kernel. Container setzen auf Linux auf und teilen sich dessen Kernel-Funktionen. Ein Linux-Container läuft deshalb nicht direkt auf einem Windows-Host ohne Linux-Kernel.
Container sind also keine „leichteren VMs“: Eine VM kapselt Hardware, ein Container kapselt nur die Anwendung.
📌 Kernel · Container-Image · Prozessraum
📚 Cloud von Grund auf · Tag 3 von 30
#docker #CloudHosting #Linux
Alle Mieter teilen sich dasselbe Gebäude, dieselbe Heizung und Wasserleitung. Jede Wohnung ist trotzdem abgeschlossen; der Nachbar sieht nichts hinein. Zieht ein Mieter aus, hinterlässt er nur seine Möbel, kein ganzes Haus.
Das gemeinsame Gebäude ist der Kernel, also der Kern des Betriebssystems, der Prozesse, Speicher und Hardwarezugriff verwaltet. Die abgeschlossene Wohnung ist der Prozessraum: Jeder Container sieht nur eigene Prozesse, eigenes Dateisystem und eigenes Netzwerk. Die privaten Möbel sind das Container-Image, die unveränderliche Vorlage mit Anwendung, Laufzeitbibliotheken und Konfigurationsdateien.
Ein Dockerfile beschreibt Schritt für Schritt, wie ein Image gebaut wird. Solch ein Image ist meist nur wenige Megabytes bis wenige hundert Megabytes groß, während ein VM-Abbild mit vollem Betriebssystem mehrere Gigabyte umfasst. Deshalb startet ein Container in Sekunden, während eine virtuelle Maschine erst ihr eigenes Betriebssystem bootet – bei AWS heißt dieser Dienst EC2.
Das Bild hat eine Grenze: Ein Mieter kann fast beliebig wirtschaften, ein Container braucht den passenden Kernel. Container setzen auf Linux auf und teilen sich dessen Kernel-Funktionen. Ein Linux-Container läuft deshalb nicht direkt auf einem Windows-Host ohne Linux-Kernel.
Container sind also keine „leichteren VMs“: Eine VM kapselt Hardware, ein Container kapselt nur die Anwendung.
📌 Kernel · Container-Image · Prozessraum
📚 Cloud von Grund auf · Tag 3 von 30
#docker #CloudHosting #Linux
4 Tage vor
Die meisten Dateien landen in der Cloud auf einem von zwei ganz verschiedenen Wegen. Dabei entscheidet die Wahl des Wegs, wie schnell eine Anwendung läuft und wie teuer das Speichern wird.
Wer eine virtuelle Maschine startet, also einen nachgebildeten Rechner mit eigenem Betriebssystem wie Linux oder Windows, trifft die Entscheidung sofort: Das System braucht ein Laufwerk. Wer den Unterschied nicht kennt, mountet den Objektspeicher wie ein Netzlaufwerk und wundert sich, warum zeichenweises Bearbeiten nicht funktioniert.
Objektspeicher wie S3 legt Daten als Objekte mit Schlüssel und Metadaten in Buckets ab. Jede Datei wird als abgeschlossenes Ganzes unter einem eindeutigen Schlüssel gespeichert, etwa einem langen Dateinamen; einzelne Bytes lassen sich nicht ändern, sondern nur das ganze Objekt neu schreiben. Blockspeicher wie EBS zerlegt Daten in gleich große Blöcke und blendet sie der virtuellen Maschine als Festplatte ein, auf der das Betriebssystem ein Dateisystem anlegt und Dateien beliebig ändert.
Konkret: Eine EC2-Instanz, so heißt die virtuelle Maschine bei AWS, bootet von ihrem EBS-Laufwerk; dort liegen Betriebssystem und installierte Software, weil viele kleine Dateien schnelle Lese- und Schreibzugriffe brauchen. Ein Upload-Verzeichnis mit Bildern und Videos gehört dagegen in einen S3-Bucket, weil dort unbegrenzt viele Objekte dauerhaft ohne Laufwerksgröße abgelegt werden. Auch Backups und Protokolldateien gehören dorthin. Speicherkosten fallen dabei auch ohne laufende Anwendung an, solange die Daten existieren.
Verwechselt wird der Objektspeicher oft mit einem Netzlaufwerk oder einer Datenbank. Er ist für das Speichern und Abrufen ganzer Dateien gebaut, nicht für zeichenweises Bearbeiten.
📌 Objektspeicher · Blockspeicher · Zuordnung der Daten
📚 Cloud von Grund auf · Tag 2 von 30
#aws #CloudHosting #Backup
Wer eine virtuelle Maschine startet, also einen nachgebildeten Rechner mit eigenem Betriebssystem wie Linux oder Windows, trifft die Entscheidung sofort: Das System braucht ein Laufwerk. Wer den Unterschied nicht kennt, mountet den Objektspeicher wie ein Netzlaufwerk und wundert sich, warum zeichenweises Bearbeiten nicht funktioniert.
Objektspeicher wie S3 legt Daten als Objekte mit Schlüssel und Metadaten in Buckets ab. Jede Datei wird als abgeschlossenes Ganzes unter einem eindeutigen Schlüssel gespeichert, etwa einem langen Dateinamen; einzelne Bytes lassen sich nicht ändern, sondern nur das ganze Objekt neu schreiben. Blockspeicher wie EBS zerlegt Daten in gleich große Blöcke und blendet sie der virtuellen Maschine als Festplatte ein, auf der das Betriebssystem ein Dateisystem anlegt und Dateien beliebig ändert.
Konkret: Eine EC2-Instanz, so heißt die virtuelle Maschine bei AWS, bootet von ihrem EBS-Laufwerk; dort liegen Betriebssystem und installierte Software, weil viele kleine Dateien schnelle Lese- und Schreibzugriffe brauchen. Ein Upload-Verzeichnis mit Bildern und Videos gehört dagegen in einen S3-Bucket, weil dort unbegrenzt viele Objekte dauerhaft ohne Laufwerksgröße abgelegt werden. Auch Backups und Protokolldateien gehören dorthin. Speicherkosten fallen dabei auch ohne laufende Anwendung an, solange die Daten existieren.
Verwechselt wird der Objektspeicher oft mit einem Netzlaufwerk oder einer Datenbank. Er ist für das Speichern und Abrufen ganzer Dateien gebaut, nicht für zeichenweises Bearbeiten.
📌 Objektspeicher · Blockspeicher · Zuordnung der Daten
📚 Cloud von Grund auf · Tag 2 von 30
#aws #CloudHosting #Backup
4 Tage vor
Viele halten eine virtuelle Maschine für ein Programm wie jedes andere. Dabei bootet sie wie ein eigener Rechner – mit eigenem Betriebssystem.
Viele stellen sich eine VM als Anwendung im Betriebssystem des Hosts vor, so wie ein Browser oder ein Spiel. Das klingt plausibel, weil sie doch irgendwo als Datei auf einem Server liegt.
Tatsächlich ist eine virtuelle Maschine ein abgeschlossener Rechner im Rechner. Sie startet von ihrem zugewiesenen virtuellen Laufwerk ein eigenes Betriebssystem, etwa Linux oder Windows, das die geteilte Hardware nicht sieht. Ein Hypervisor, also eine Software-Schicht, die die physische Hardware verwaltet, teilt CPU, Speicher und Netzwerk auf viele VMs auf. Dabei gibt er ihnen keine vorgetäuschte fremde Hardware wie eine Emulation, sondern leitet deren Befehle weitgehend direkt auf die echte CPU um, was deutlich schneller ist.
Der Irrtum entsteht, weil man von außen nur eine Konsole oder ein Fenster sieht. Wie ein Programm aussieht, ist es aber nicht: Innen läuft ein vollständiger Rechner mit eigenem Kernel, also dem Kern des Betriebssystems.
Auf einem einzigen physischen Server laufen so Dutzende VMs nebeneinander, jede mit eigenem Betriebssystem, das unabhängig bootet, gepatcht und neu gestartet wird. Genau das macht die Cloud möglich: Viele Kunden nutzen dieselben physischen Rechner und Netze, getrennt nur durch Virtualisierung. Bei AWS heißt der Dienst für VMs EC2 – startet man eine Instanz, bezahlt man deren Laufzeit nach Nutzung.
Woran man es erkennt: Eine VM hat ein eigenes Betriebssystem mit eigenem Kernel und eigenen Festplatten. Ein Container dagegen teilt sich den Kernel des Hosts und startet deshalb schneller und kleiner.
Eine VM heißt nicht Programm im gemeinsamen Betriebssystem, sondern eigenständiger Rechner auf geteilter Hardware.
📌 Hypervisor teilt Hardware · VM bootet eigenes OS · EC2 als VM-Dienst
📚 Cloud von Grund auf · Tag 2 von 30
#aws #CloudHosting
Viele stellen sich eine VM als Anwendung im Betriebssystem des Hosts vor, so wie ein Browser oder ein Spiel. Das klingt plausibel, weil sie doch irgendwo als Datei auf einem Server liegt.
Tatsächlich ist eine virtuelle Maschine ein abgeschlossener Rechner im Rechner. Sie startet von ihrem zugewiesenen virtuellen Laufwerk ein eigenes Betriebssystem, etwa Linux oder Windows, das die geteilte Hardware nicht sieht. Ein Hypervisor, also eine Software-Schicht, die die physische Hardware verwaltet, teilt CPU, Speicher und Netzwerk auf viele VMs auf. Dabei gibt er ihnen keine vorgetäuschte fremde Hardware wie eine Emulation, sondern leitet deren Befehle weitgehend direkt auf die echte CPU um, was deutlich schneller ist.
Der Irrtum entsteht, weil man von außen nur eine Konsole oder ein Fenster sieht. Wie ein Programm aussieht, ist es aber nicht: Innen läuft ein vollständiger Rechner mit eigenem Kernel, also dem Kern des Betriebssystems.
Auf einem einzigen physischen Server laufen so Dutzende VMs nebeneinander, jede mit eigenem Betriebssystem, das unabhängig bootet, gepatcht und neu gestartet wird. Genau das macht die Cloud möglich: Viele Kunden nutzen dieselben physischen Rechner und Netze, getrennt nur durch Virtualisierung. Bei AWS heißt der Dienst für VMs EC2 – startet man eine Instanz, bezahlt man deren Laufzeit nach Nutzung.
Woran man es erkennt: Eine VM hat ein eigenes Betriebssystem mit eigenem Kernel und eigenen Festplatten. Ein Container dagegen teilt sich den Kernel des Hosts und startet deshalb schneller und kleiner.
Eine VM heißt nicht Programm im gemeinsamen Betriebssystem, sondern eigenständiger Rechner auf geteilter Hardware.
📌 Hypervisor teilt Hardware · VM bootet eigenes OS · EC2 als VM-Dienst
📚 Cloud von Grund auf · Tag 2 von 30
#aws #CloudHosting
4 Tage vor
Die meisten Unternehmen nutzen Cloud, ohne die Verantwortungsgrenze zu kennen. Dabei entscheidet genau diese Grenze, was das eigene Team nachts um drei Uhr repariert.
Wer eine Anwendung plant, legt zuerst fest, welche Schichten das eigene Team betreiben kann. Die Antwort bestimmt Kosten, Personalbedarf und Abhängigkeit vom Anbieter.
🔭 IaaS bedeutet, alles ab der virtuellen Maschine selbst zu verantworten. Der Anbieter stellt gemietete Rechenleistung, Speicher und Netz bereit, betreibt Rechenzentrum, Hardware und Virtualisierung, also die Software, die Hardware aufteilt. Betriebssystem, Patches und Anwendung liegen beim Kunden. Wer eine Linux-VM selbst konfiguriert, wählt IaaS.
🧪 PaaS nimmt dem Team Betriebssystem und Laufzeitumgebung ab, also die Software, in der der Code läuft. Entwickelt wird nur noch die Anwendung selbst. NIST SP 800-145, der US-Standard zur Cloud-Definition, nennt genau diese drei Modelle: IaaS, PaaS und SaaS. Wer Code deployt, ohne je einen Server zu patchen, nutzt PaaS.
📐 SaaS verschiebt die Grenze ganz nach oben: Der Anbieter verantwortet alle Schichten bis zur Anwendung. Der Kunde verwaltet nur Nutzerkonten, Rollen und Daten. Ein klassischer Irrtum ist, SaaS als „mietbare Software ohne Verantwortung“ zu lesen. Zugänge, Rollenvergabe und Datensicherung bleiben Kundenaufgabe. Beim Wechsel hilft der Data Act (Verordnung (EU) 2023/2854) mit Regeln zu Übergangsfristen.
Woran man es erkennt: Für jede Schicht von Rechenzentrum bis Anwendung gilt die Prüfrage, wer sie betreibt. IaaS heißt nicht weniger Arbeit, sondern mehr Kontrolle. SaaS heißt nicht keine Verantwortung, sondern Verantwortung für Daten statt Technik.
📌 Schichtenmodell · Verantwortungsgrenze · Kompetenz
📚 Zukunftstechnologien verstehen · Tag 2 von 30
#architektur #DigitaleTransformation #strategie
Wer eine Anwendung plant, legt zuerst fest, welche Schichten das eigene Team betreiben kann. Die Antwort bestimmt Kosten, Personalbedarf und Abhängigkeit vom Anbieter.
🔭 IaaS bedeutet, alles ab der virtuellen Maschine selbst zu verantworten. Der Anbieter stellt gemietete Rechenleistung, Speicher und Netz bereit, betreibt Rechenzentrum, Hardware und Virtualisierung, also die Software, die Hardware aufteilt. Betriebssystem, Patches und Anwendung liegen beim Kunden. Wer eine Linux-VM selbst konfiguriert, wählt IaaS.
🧪 PaaS nimmt dem Team Betriebssystem und Laufzeitumgebung ab, also die Software, in der der Code läuft. Entwickelt wird nur noch die Anwendung selbst. NIST SP 800-145, der US-Standard zur Cloud-Definition, nennt genau diese drei Modelle: IaaS, PaaS und SaaS. Wer Code deployt, ohne je einen Server zu patchen, nutzt PaaS.
📐 SaaS verschiebt die Grenze ganz nach oben: Der Anbieter verantwortet alle Schichten bis zur Anwendung. Der Kunde verwaltet nur Nutzerkonten, Rollen und Daten. Ein klassischer Irrtum ist, SaaS als „mietbare Software ohne Verantwortung“ zu lesen. Zugänge, Rollenvergabe und Datensicherung bleiben Kundenaufgabe. Beim Wechsel hilft der Data Act (Verordnung (EU) 2023/2854) mit Regeln zu Übergangsfristen.
Woran man es erkennt: Für jede Schicht von Rechenzentrum bis Anwendung gilt die Prüfrage, wer sie betreibt. IaaS heißt nicht weniger Arbeit, sondern mehr Kontrolle. SaaS heißt nicht keine Verantwortung, sondern Verantwortung für Daten statt Technik.
📌 Schichtenmodell · Verantwortungsgrenze · Kompetenz
📚 Zukunftstechnologien verstehen · Tag 2 von 30
#architektur #DigitaleTransformation #strategie
5 Tage vor
Ein Rechner bootet erst ein Betriebssystem, bevor irgendetwas läuft. Ein Mikrocontroller startet direkt sein einziges Programm – und das ist ein Vorteil.
Das ist die Firmware, also das eine Programm, das fest im Flash-Speicher des Chips abgelegt ist. Sie steckt in jedem IoT-Sensor, jeder smarten Steckdose und jedem Werkzeug mit Knopf und Elektronik.
Zuerst kommt der Strom. Der Mikrocontroller, ein Chip mit Prozessor, Arbeitsspeicher, Flash und Ein- und Ausgängen, lädt die Firmware direkt aus dem Flash. Flash ist ein nichtflüchtiger Speicher, der seinen Inhalt auch ohne Strom behält. Ein Betriebssystem wird nicht zuerst geladen, deshalb bleibt der Startvorgang kurz und vorhersagbar.
Dann läuft setup(). In einem Arduino-Programm ruft die Firmware einmal am Anfang die Funktion setup() auf, die die angeschlossene Hardware initialisiert. Danach folgt loop(), eine Endlosschleife, die immer wieder durchlaufen wird.
Danach verrichtet loop() die eigentliche Arbeit. Sie liest Sensorsignale an den Eingängen, verrechnet sie und schaltet Ausgänge – ganz ohne Benutzer. Ein Temperatur-Sensorknoten misst die Temperatur, sendet sie über ein Funkmodul und schläft anschließend bis zur nächsten Messung. Das schont den Akku.
Zuletzt macht Schlankheit das Gerät zuverlässig. Ein Betriebssystem wie Windows oder Linux verwaltet viele Programme, Dateien und Geräte; ein Mikrocontroller braucht das nicht, weil genau eine Aufgabe festgelegt ist. Weniger Software heißt weniger Fehlerquellen – das Verhalten bleibt bei jedem Durchlauf gleich.
Firmware heißt also nicht „ein Programm von vielen“, sondern „das einzige Programm“ – direkt, schlank und nach jedem Einschalten sofort da.
📌 Firmware · Flash · Endlosschleife
📚 IoT von Grund auf · Tag 1 von 30
#Mikrocontroller #firmware #iot #embedded
Das ist die Firmware, also das eine Programm, das fest im Flash-Speicher des Chips abgelegt ist. Sie steckt in jedem IoT-Sensor, jeder smarten Steckdose und jedem Werkzeug mit Knopf und Elektronik.
Zuerst kommt der Strom. Der Mikrocontroller, ein Chip mit Prozessor, Arbeitsspeicher, Flash und Ein- und Ausgängen, lädt die Firmware direkt aus dem Flash. Flash ist ein nichtflüchtiger Speicher, der seinen Inhalt auch ohne Strom behält. Ein Betriebssystem wird nicht zuerst geladen, deshalb bleibt der Startvorgang kurz und vorhersagbar.
Dann läuft setup(). In einem Arduino-Programm ruft die Firmware einmal am Anfang die Funktion setup() auf, die die angeschlossene Hardware initialisiert. Danach folgt loop(), eine Endlosschleife, die immer wieder durchlaufen wird.
Danach verrichtet loop() die eigentliche Arbeit. Sie liest Sensorsignale an den Eingängen, verrechnet sie und schaltet Ausgänge – ganz ohne Benutzer. Ein Temperatur-Sensorknoten misst die Temperatur, sendet sie über ein Funkmodul und schläft anschließend bis zur nächsten Messung. Das schont den Akku.
Zuletzt macht Schlankheit das Gerät zuverlässig. Ein Betriebssystem wie Windows oder Linux verwaltet viele Programme, Dateien und Geräte; ein Mikrocontroller braucht das nicht, weil genau eine Aufgabe festgelegt ist. Weniger Software heißt weniger Fehlerquellen – das Verhalten bleibt bei jedem Durchlauf gleich.
Firmware heißt also nicht „ein Programm von vielen“, sondern „das einzige Programm“ – direkt, schlank und nach jedem Einschalten sofort da.
📌 Firmware · Flash · Endlosschleife
📚 IoT von Grund auf · Tag 1 von 30
#Mikrocontroller #firmware #iot #embedded
10 Tage vor
Die meisten KI-Assistenten fragen um Vertrauen. Unserer fragt um Erlaubnis.
Neue Version von sepp mini dem KI-Assistenten, der in einer einzigen Datei steckt. 19 MB. Kein Konto, kein Cloud-Zwang, keine node_modules. Kopieren, ausführbar machen, starten. Auf Linux, macOS, Windows, Embedded oder vom USB-Stick, ohne Admin-Rechte.
🛡 Sepp Guard - erlaubt ist nur, was freigegeben wurde. Der Assistent sieht das laufende Projekt, sonst nichts vom Rechner. Kein Internet, kein Zugriff auf sensible Daten ohne Erlaubnis. Und entscheidend: Die Grenze zieht das Betriebssystem, nicht das Programm. Eine Zusage im Prompt ist keine Sicherheitsarchitektur.
📋 Audit Nachweis - jeder Schritt bleibt nachlesbar. Wer wann was getan hat. Und was abgelehnt wurde. Auch das Erlaubte steht in der Spur, Teilaufgaben eingerückt unter ihrem Auftrag, maschinell auswertbar. Kein Gedächtnisprotokoll, sondern eine prüfbare Aufzeichnung verwertbar für Revision, ISO-Audit und Datenschutzprüfung.
🔑 Ihr Modell, Ihre Entscheidung. Großer Anbieter, eigener Server im Firmennetz oder lokal am Arbeitsplatz. Umgestellt wird mit einer Angabe beim Start. Vertrauliches bleibt drin, Aufwendiges darf raus. Kein Anbieter bindet Sie.
Souveränität heißt nicht, auf KI zu verzichten. Sie heißt, die Bedingungen selbst zu setzen.
Eine Binary. Eine Haltung. Souveränität. Entwickelt und gebaut in Deutschland.
👉 https://sepp.kionova.de/
🦀 Rust · 🔒 Sandboxed · 🌐 Made in Germany
Welcher Prozess bei Ihnen läuft heute noch von Hand?
#ki #Souveränität #MadeInGermany #compliance #Rust #DigitaleSouveränität
Neue Version von sepp mini dem KI-Assistenten, der in einer einzigen Datei steckt. 19 MB. Kein Konto, kein Cloud-Zwang, keine node_modules. Kopieren, ausführbar machen, starten. Auf Linux, macOS, Windows, Embedded oder vom USB-Stick, ohne Admin-Rechte.
🛡 Sepp Guard - erlaubt ist nur, was freigegeben wurde. Der Assistent sieht das laufende Projekt, sonst nichts vom Rechner. Kein Internet, kein Zugriff auf sensible Daten ohne Erlaubnis. Und entscheidend: Die Grenze zieht das Betriebssystem, nicht das Programm. Eine Zusage im Prompt ist keine Sicherheitsarchitektur.
📋 Audit Nachweis - jeder Schritt bleibt nachlesbar. Wer wann was getan hat. Und was abgelehnt wurde. Auch das Erlaubte steht in der Spur, Teilaufgaben eingerückt unter ihrem Auftrag, maschinell auswertbar. Kein Gedächtnisprotokoll, sondern eine prüfbare Aufzeichnung verwertbar für Revision, ISO-Audit und Datenschutzprüfung.
🔑 Ihr Modell, Ihre Entscheidung. Großer Anbieter, eigener Server im Firmennetz oder lokal am Arbeitsplatz. Umgestellt wird mit einer Angabe beim Start. Vertrauliches bleibt drin, Aufwendiges darf raus. Kein Anbieter bindet Sie.
Souveränität heißt nicht, auf KI zu verzichten. Sie heißt, die Bedingungen selbst zu setzen.
Eine Binary. Eine Haltung. Souveränität. Entwickelt und gebaut in Deutschland.
👉 https://sepp.kionova.de/
🦀 Rust · 🔒 Sandboxed · 🌐 Made in Germany
Welcher Prozess bei Ihnen läuft heute noch von Hand?
#ki #Souveränität #MadeInGermany #compliance #Rust #DigitaleSouveränität
sepp mini — KI-Assistent in einer Datei. Souverän. Made in Germany | KIONOVA®
KI-Assistent in einer Datei: läuft in Ihrem Netz, darf nur, was Sie freigeben, protokolliert jeden Schritt. Ohne Cloud-Zwang, ohne Konto. Made in Germany.
https://sepp.kionova.de/
3 Monate vor
WebAssembly ist die Antwort auf die unangenehmste Frage im Agenten-Bau: Wem gibst du eigentlich exec?
Jeder, der ein Plugin-System für einen LLM-Agenten baut, landet irgendwann an derselben Stelle. Der Kern funktioniert, der Tool-Loop läuft, und dann sollen Erweiterungen dazukommen – von Nutzern, von Kollegen, aus dem Netz. Und plötzlich steht die Frage im Raum, über die in Demos nie gesprochen wird:
Was darf dieser fremde Code auf meinem Rechner eigentlich?
Die ehrliche Antwort lautet bei den meisten Setups: alles. Ein Plugin ist ein Skript, das Skript läuft im selben Prozess wie der Agent, der Agent hat deine API-Keys in der Umgebung, dein Dateisystem unter sich und eine offene Netzverbindung. Zwischen "nützliche Erweiterung" und "Exfiltration deiner Secrets" liegt genau nichts – außer Vertrauen.
Das ist der Punkt, an dem WebAssembly aufhört, ein Browser-Thema zu sein.
WASM IST KEIN SCHNELLERES JAVASCRIPT. ES IST EIN SICHERHEITSMODELL.
Die meiste Aufmerksamkeit für WebAssembly dreht sich um Performance. Interessanter ist aber die Eigenschaft, die WASM von Anfang an mitbringt und die andere Plugin-Formate mühsam nachrüsten müssen: Ein WASM-Modul kann per Konstruktion nichts.
Kein Dateisystem. Kein Netz. Keine Uhr, keine Umgebungsvariablen, keine Syscalls. Ein WASM-Modul sitzt in einem linearen Speicherbereich und hat exakt die Fähigkeiten, die der Host ihm als Funktionen hineinreicht – nicht eine mehr. Der Default ist nicht "großzügig". Der Default ist leer.
Damit dreht sich die Beweislast um. Bei einem nativen Plugin muss man einschränken, was es kann. Bei einem WASM-Plugin muss man erlauben, was es können soll. Ein kleiner Unterschied in der Formulierung – ein sehr großer in der Praxis.
WIE WIR DAS IN SEPP MINI NUTZEN
Ich baue sepp mini: einen leichtgewichtigen, erweiterbaren Agent-Harness in Rust. Eine statische Binary, kein Node, kein Ballast. Ein Agenten-Loop mit Streaming, parallelem Tool-Dispatch und Compaction – nutzbar als TUI, als One-shot-Kommando oder als JSONL-RPC zum Einbetten in andere Programme.
Erweiterbarkeit ist dort in vier Tiers geschichtet, gestuft nach Macht und Isolation:
Tier 1 – Resources: Skills, Prompt-Templates, Themes. Reine Daten, kein Code.
Tier 2 – Hooks: In-process Rhai-Skripte, die den Agent-Loop steuern. Sprach-Sandbox.
Tier 3 – WASM: Plugins aus jeder Sprache, memory-sandboxed via wasmi.
Tier 4 – MCP: Out-of-process-Server als Tool-Quelle, OS-sandboxed.
Je mehr eine Erweiterung darf, desto härter isoliert sie der Kern.
Tier 3 ist die Stelle, an der WebAssembly genau das liefert, was sonst teuer ist: echter Fremdcode ohne echtes Risiko. Ein Plugin deklariert im Manifest seine Capabilities – FsRead, FsWrite, Net, Env, Exec. Der Kern parst das zu einer Policy, der Mensch bestätigt sie, und dann registriert der Host nur die Funktionen, die die Policy erlaubt.
Der entscheidende Satz daran: Ein Plugin ohne Net-Capability bekommt keine Netz-Host-Funktion. Es ist damit nicht "gebeten, nicht ins Netz zu gehen" – es ist nachweislich offline. Es gibt keinen Syscall, den es aufrufen könnte. Der Default ist deny, und deny ist hier keine Konfiguration, sondern eine Abwesenheit.
Dazu kommt: Ein .wasm-Modul ist sprachagnostisch. Rust, Go, TinyGo, C, Zig, AssemblyScript – wer ein Plugin schreiben will, muss nicht meine Sprache lernen, sondern nur mein Interface treffen. Für ein Open-Source-Projekt ist das der Unterschied zwischen einem Ökosystem und einem Monolog.
WAS WASM NICHT LÖST – UND WOFÜR WIR DAS BETRIEBSSYSTEM BRAUCHEN
Ehrlichkeit gehört dazu, sonst wird es Marketing: WASM ist keine Universallösung.
Ein WASM-Modul kann keinen git-Prozess starten, keinen Language-Server sprechen, keine bestehende CLI wrappen. Sobald eine Erweiterung wirklich Prozesse ausführen muss, hilft keine Memory-Sandbox – dann muss die Grenze dorthin, wo sie hart ist: ins Betriebssystem. Genau dafür existiert Tier 4. MCP-Server laufen out-of-process, OS-sandboxed über Landlock unter Linux und Seatbelt (sandbox_init) unter macOS, beides fail-closed, plus Environment-Scrubbing – damit ein Subprozess keine API-Keys erbt, die ihm niemand geben wollte.
Die Architektur-Aussage ist also nicht "WASM für alles". Sie lautet: Die Isolationsmethode folgt der geforderten Macht. Daten brauchen keine Sandbox. Logik braucht eine Memory-Sandbox. Prozesse brauchen das OS. WebAssembly besetzt in dieser Staffelung die mittlere – und aus meiner Sicht wertvollste – Stufe: mächtig genug für echte Logik, isoliert genug, um Fremdcode ohne Bauchschmerzen laufen zu lassen.
WARUM DAS JETZT ZÄHLT
Agenten schreiben Code, führen ihn aus, rufen Tools auf. Das Ökosystem drumherum wächst schneller, als die Sicherheitsmodelle nachgezogen werden. Wir werden in den nächsten Jahren sehr viele Agent-Erweiterungen aus sehr unterschiedlichen Quellen installieren – und die Frage "was darf das eigentlich?" wird von einer Detailfrage zur zentralen Frage.
WebAssembly beantwortet sie mit dem einzigen Default, der skaliert: nichts, bis jemand etwas anderes sagt.
sepp mini ist Open Source, Rust, eine statische Binary, Linux und macOS inklusive Apple Silicon.
https://sepp.kionova.de
Wer selbst an Plugin- oder Sandbox-Architekturen für Agenten arbeitet: Ich bin ernsthaft an Gegenargumenten interessiert. Wo seht ihr die Grenzen des Capability-Ansatzes?
#WebAssembly #WASM #Rust #aiagents #opensource #SoftwareArchitecture
Jeder, der ein Plugin-System für einen LLM-Agenten baut, landet irgendwann an derselben Stelle. Der Kern funktioniert, der Tool-Loop läuft, und dann sollen Erweiterungen dazukommen – von Nutzern, von Kollegen, aus dem Netz. Und plötzlich steht die Frage im Raum, über die in Demos nie gesprochen wird:
Was darf dieser fremde Code auf meinem Rechner eigentlich?
Die ehrliche Antwort lautet bei den meisten Setups: alles. Ein Plugin ist ein Skript, das Skript läuft im selben Prozess wie der Agent, der Agent hat deine API-Keys in der Umgebung, dein Dateisystem unter sich und eine offene Netzverbindung. Zwischen "nützliche Erweiterung" und "Exfiltration deiner Secrets" liegt genau nichts – außer Vertrauen.
Das ist der Punkt, an dem WebAssembly aufhört, ein Browser-Thema zu sein.
WASM IST KEIN SCHNELLERES JAVASCRIPT. ES IST EIN SICHERHEITSMODELL.
Die meiste Aufmerksamkeit für WebAssembly dreht sich um Performance. Interessanter ist aber die Eigenschaft, die WASM von Anfang an mitbringt und die andere Plugin-Formate mühsam nachrüsten müssen: Ein WASM-Modul kann per Konstruktion nichts.
Kein Dateisystem. Kein Netz. Keine Uhr, keine Umgebungsvariablen, keine Syscalls. Ein WASM-Modul sitzt in einem linearen Speicherbereich und hat exakt die Fähigkeiten, die der Host ihm als Funktionen hineinreicht – nicht eine mehr. Der Default ist nicht "großzügig". Der Default ist leer.
Damit dreht sich die Beweislast um. Bei einem nativen Plugin muss man einschränken, was es kann. Bei einem WASM-Plugin muss man erlauben, was es können soll. Ein kleiner Unterschied in der Formulierung – ein sehr großer in der Praxis.
WIE WIR DAS IN SEPP MINI NUTZEN
Ich baue sepp mini: einen leichtgewichtigen, erweiterbaren Agent-Harness in Rust. Eine statische Binary, kein Node, kein Ballast. Ein Agenten-Loop mit Streaming, parallelem Tool-Dispatch und Compaction – nutzbar als TUI, als One-shot-Kommando oder als JSONL-RPC zum Einbetten in andere Programme.
Erweiterbarkeit ist dort in vier Tiers geschichtet, gestuft nach Macht und Isolation:
Tier 1 – Resources: Skills, Prompt-Templates, Themes. Reine Daten, kein Code.
Tier 2 – Hooks: In-process Rhai-Skripte, die den Agent-Loop steuern. Sprach-Sandbox.
Tier 3 – WASM: Plugins aus jeder Sprache, memory-sandboxed via wasmi.
Tier 4 – MCP: Out-of-process-Server als Tool-Quelle, OS-sandboxed.
Je mehr eine Erweiterung darf, desto härter isoliert sie der Kern.
Tier 3 ist die Stelle, an der WebAssembly genau das liefert, was sonst teuer ist: echter Fremdcode ohne echtes Risiko. Ein Plugin deklariert im Manifest seine Capabilities – FsRead, FsWrite, Net, Env, Exec. Der Kern parst das zu einer Policy, der Mensch bestätigt sie, und dann registriert der Host nur die Funktionen, die die Policy erlaubt.
Der entscheidende Satz daran: Ein Plugin ohne Net-Capability bekommt keine Netz-Host-Funktion. Es ist damit nicht "gebeten, nicht ins Netz zu gehen" – es ist nachweislich offline. Es gibt keinen Syscall, den es aufrufen könnte. Der Default ist deny, und deny ist hier keine Konfiguration, sondern eine Abwesenheit.
Dazu kommt: Ein .wasm-Modul ist sprachagnostisch. Rust, Go, TinyGo, C, Zig, AssemblyScript – wer ein Plugin schreiben will, muss nicht meine Sprache lernen, sondern nur mein Interface treffen. Für ein Open-Source-Projekt ist das der Unterschied zwischen einem Ökosystem und einem Monolog.
WAS WASM NICHT LÖST – UND WOFÜR WIR DAS BETRIEBSSYSTEM BRAUCHEN
Ehrlichkeit gehört dazu, sonst wird es Marketing: WASM ist keine Universallösung.
Ein WASM-Modul kann keinen git-Prozess starten, keinen Language-Server sprechen, keine bestehende CLI wrappen. Sobald eine Erweiterung wirklich Prozesse ausführen muss, hilft keine Memory-Sandbox – dann muss die Grenze dorthin, wo sie hart ist: ins Betriebssystem. Genau dafür existiert Tier 4. MCP-Server laufen out-of-process, OS-sandboxed über Landlock unter Linux und Seatbelt (sandbox_init) unter macOS, beides fail-closed, plus Environment-Scrubbing – damit ein Subprozess keine API-Keys erbt, die ihm niemand geben wollte.
Die Architektur-Aussage ist also nicht "WASM für alles". Sie lautet: Die Isolationsmethode folgt der geforderten Macht. Daten brauchen keine Sandbox. Logik braucht eine Memory-Sandbox. Prozesse brauchen das OS. WebAssembly besetzt in dieser Staffelung die mittlere – und aus meiner Sicht wertvollste – Stufe: mächtig genug für echte Logik, isoliert genug, um Fremdcode ohne Bauchschmerzen laufen zu lassen.
WARUM DAS JETZT ZÄHLT
Agenten schreiben Code, führen ihn aus, rufen Tools auf. Das Ökosystem drumherum wächst schneller, als die Sicherheitsmodelle nachgezogen werden. Wir werden in den nächsten Jahren sehr viele Agent-Erweiterungen aus sehr unterschiedlichen Quellen installieren – und die Frage "was darf das eigentlich?" wird von einer Detailfrage zur zentralen Frage.
WebAssembly beantwortet sie mit dem einzigen Default, der skaliert: nichts, bis jemand etwas anderes sagt.
sepp mini ist Open Source, Rust, eine statische Binary, Linux und macOS inklusive Apple Silicon.
https://sepp.kionova.de
Wer selbst an Plugin- oder Sandbox-Architekturen für Agenten arbeitet: Ich bin ernsthaft an Gegenargumenten interessiert. Wo seht ihr die Grenzen des Capability-Ansatzes?
#WebAssembly #WASM #Rust #aiagents #opensource #SoftwareArchitecture
8 Monate vor
Digitale Souveränität: Ein Bundesland zeigt, wie es geht
Die Abhängigkeit der deutschen Wirtschaft von US-Technologiefirmen ist kein neues Thema – aber eines, das gerade mit voller Wucht in der Realität ankommt. 9 von 10 deutschen Unternehmen, die digitale Güter importieren, sehen sich davon abhängig. Das Vertrauen in die USA als Technologiepartner ist innerhalb eines Jahres von 51 auf 38 Prozent gefallen. Und die durchschnittliche Überlebensfähigkeit ohne US-Technologie? Gerade einmal 12 Monate.
Viele diskutieren. Eines handelt.
Schleswig-Holstein macht es vor
Das nördlichste Bundesland vollzieht gerade den radikalsten IT-Wandel in der deutschen Verwaltungsgeschichte – und beweist dabei, dass digitale Souveränität nicht nur möglich, sondern auch wirtschaftlich ist.
Die Zahlen sprechen für sich: Microsoft Office wurde auf nahezu 80 Prozent aller Arbeitsplätze bereits deinstalliert und durch LibreOffice ersetzt. 44.000 E-Mail-Postfächer wurden erfolgreich migriert. 30.000 Verwaltungsrechner werden auf Linux umgestellt. Die Neu-Lizenzierungsrate liegt bereits bei unter 10 Prozent.
Und das Beste daran? 9 Millionen Euro einmalige Investitionen stehen mehr als 15 Millionen Euro jährlichen Einsparungen gegenüber. Die Migration finanziert sich im ersten Jahr selbst.
Digitalisierungsminister Dirk Schrödter bringt es auf den Punkt: „Wir reduzieren unsere technische und damit wirtschaftliche Abhängigkeit von einzelnen Herstellern und stärken die digitale Souveränität des Landes."
Der Wandel ist möglich – auch für dein Unternehmen
Natürlich war der Weg nicht ohne Hindernisse. Gewohnte Arbeitsabläufe, tiefverwurzelter Lock-in in Microsoft-Ökosysteme, fehlende Open-Source-Kompetenz – das alles sind reale Herausforderungen. Aber Schleswig-Holstein hat gezeigt: Sie sind lösbar.
Du musst nicht von heute auf morgen alles umstellen. Aber du kannst anfangen:
Mach eine Bestandsaufnahme. Welche US-Technologien sind bei dir wirklich geschäftskritisch? Lokalisiere deine Daten. Sensible Daten gehören auf Infrastruktur, die deutschem oder europäischem Recht unterliegt – nicht nur aus Überzeugung, sondern aus DSGVO-Pflicht.
Baue Open-Source-Kompetenz auf. Pilotprojekte mit LibreOffice, Nextcloud oder Matrix kosten wenig und liefern wertvolle Erfahrungen.
Europa bewegt sich Schleswig-Holstein ist kein Einzelfall. Baden-Württemberg stellt eine eigene KI-Assistenz als Open Source bereit. Frankreich ersetzt Microsoft Teams in Behörden durch eine eigene Lösung. Deutschland und Frankreich haben gemeinsam den Gipfel für europäische digitale Souveränität initiiert.
Die Richtung ist klar. Die Frage ist nur: Wann machst du mit?
Die Abhängigkeit der deutschen Wirtschaft von US-Technologiefirmen ist kein neues Thema – aber eines, das gerade mit voller Wucht in der Realität ankommt. 9 von 10 deutschen Unternehmen, die digitale Güter importieren, sehen sich davon abhängig. Das Vertrauen in die USA als Technologiepartner ist innerhalb eines Jahres von 51 auf 38 Prozent gefallen. Und die durchschnittliche Überlebensfähigkeit ohne US-Technologie? Gerade einmal 12 Monate.
Viele diskutieren. Eines handelt.
Schleswig-Holstein macht es vor
Das nördlichste Bundesland vollzieht gerade den radikalsten IT-Wandel in der deutschen Verwaltungsgeschichte – und beweist dabei, dass digitale Souveränität nicht nur möglich, sondern auch wirtschaftlich ist.
Die Zahlen sprechen für sich: Microsoft Office wurde auf nahezu 80 Prozent aller Arbeitsplätze bereits deinstalliert und durch LibreOffice ersetzt. 44.000 E-Mail-Postfächer wurden erfolgreich migriert. 30.000 Verwaltungsrechner werden auf Linux umgestellt. Die Neu-Lizenzierungsrate liegt bereits bei unter 10 Prozent.
Und das Beste daran? 9 Millionen Euro einmalige Investitionen stehen mehr als 15 Millionen Euro jährlichen Einsparungen gegenüber. Die Migration finanziert sich im ersten Jahr selbst.
Digitalisierungsminister Dirk Schrödter bringt es auf den Punkt: „Wir reduzieren unsere technische und damit wirtschaftliche Abhängigkeit von einzelnen Herstellern und stärken die digitale Souveränität des Landes."
Der Wandel ist möglich – auch für dein Unternehmen
Natürlich war der Weg nicht ohne Hindernisse. Gewohnte Arbeitsabläufe, tiefverwurzelter Lock-in in Microsoft-Ökosysteme, fehlende Open-Source-Kompetenz – das alles sind reale Herausforderungen. Aber Schleswig-Holstein hat gezeigt: Sie sind lösbar.
Du musst nicht von heute auf morgen alles umstellen. Aber du kannst anfangen:
Mach eine Bestandsaufnahme. Welche US-Technologien sind bei dir wirklich geschäftskritisch? Lokalisiere deine Daten. Sensible Daten gehören auf Infrastruktur, die deutschem oder europäischem Recht unterliegt – nicht nur aus Überzeugung, sondern aus DSGVO-Pflicht.
Baue Open-Source-Kompetenz auf. Pilotprojekte mit LibreOffice, Nextcloud oder Matrix kosten wenig und liefern wertvolle Erfahrungen.
Europa bewegt sich Schleswig-Holstein ist kein Einzelfall. Baden-Württemberg stellt eine eigene KI-Assistenz als Open Source bereit. Frankreich ersetzt Microsoft Teams in Behörden durch eine eigene Lösung. Deutschland und Frankreich haben gemeinsam den Gipfel für europäische digitale Souveränität initiiert.
Die Richtung ist klar. Die Frage ist nur: Wann machst du mit?
Abonnieren zum Entsperren
Für 10€ / Monatlich
