first routing protocol draft

config.toml

@@ -218,7 +218,7 @@ enable_cards_tag_filtering = true
 invert_title_order = false
 
 # Full path after the base URL required. So if you were to place it in "static" it would be "/favicon.ico"
-favicon = "img/logov3.png"
+favicon = "img/favicon.png"
 
 # Add an emoji here to use it as favicon.
 # Compatibility: https://caniuse.com/link-icon-svg

content/_index.md

@@ -2,7 +2,7 @@
 title = "Neues"
 
 [extra]
-header = { title = "benji0x3c", img = "img/logov2-scaled.png", img_alt = "YOUR_NAME" }
+header = { title = "benji0x3c", img = "img/logov2-scaled.png", img_alt = "benji0x3c" }
 section_path = "blog/_index.md"
 max_posts = 5
 +++

content/blog/dystopische-zeiten/index.md

@@ -1,22 +0,0 @@
-+++
-title = "Dystopische Zeiten"
-date = "2026-04-23"
-description = "Wahrscheinlich die bisher schlimmste Kompromittierung des Jahres"
-
-[taxonomies]
-tags = ["security","meinung","news"]
-+++
-Aktuell habe ich das Gefühl, dass diverse Science-Fiction Voraussagen erfüllt werden. 
-Nur leider werden nur die dystopischsten Aspekte des fiktiven World-Buildings bedient.
-Ich möchte das an zwei Beispielen veranschaulichen:
-## Polymarket und Kalshi
-Du möchtest darauf wetten, dass das israelische Militär bis zum 31 Mai den Jemen angreift? 
-Dann bist du nicht nur ein schrecklicher Mensch ohne Moral sondern 27% Quote
-
-## JetBlue und die Beerdigung
-| *Twitterinteraktion der Airline JetBlue* |
-|:--:| 
-| ![XZ Logo](jetblue-x.png) | 
-
-
-

content/blog/project-glasswing/index.md

@@ -0,0 +1,77 @@
++++
+title = "Project Glasswing"
+date = "2026-06-03"
+description = "Wie sind die Meinungen zu Anthropics Mythos Preview?"
+
+[taxonomies]
+tags = ["ki","meinung"]
++++
+**Metaanalyse zu Project Glasswing**
+## Was ist Glasswing?
++ Das neue, unveröffentlichte Claude Mythos Preview Modell zeigt laut Anthropic 
+sehr fortgeschrittene Fähigkeiten zur Findung von Schwachstellen.
++ Deshalb wurde das Modell von Anthropic als zu gefährlich befunden.
++ Vorerst wird es nur 40 Unternehmen in einer geschlossenen Zusammenarbeit zugänglich gemacht: **Project Glasswing**.
++ Unter den Unternehmen sind AWS, Microsoft, die Linux Foundation und Cloudflare.
+
+## Was sagt Anthropic?
+| | Glasswing Blogpost | Red-Team Blogpost | System Card |
+|------|------|------|------|
+| Umfang | Ca. 15 Seiten | Ca. 30 Seiten | 245 Seiten | 
+| Inhalt | Verkündet die geschlossene Nutzung des Modells durch ausgewählte Unternehmen, wobei der Bericht des Red-Teams referenziert wird um die Fähigkeiten des Modells zu belegen. | Bericht von Anthropics Red-Team, in welchem Mythos als Werkzeug zur Sicherheitsforschung evaluiert wird. Erläutert einige Schwachstellen im Detail. | Allgemeiner Technischer Bericht zu dem neuen Modell, der sich "nur" über sieben Seiten den Cybersecurity-Aspekten widmet. |
+| Link | [hier](https://www.anthropic.com/glasswing) | [hier](https://red.anthropic.com/2026/mythos-preview/) | [hier](https://www-cdn.anthropic.com/8b8380204f74670be75e81c820ca8dda846ab289.pdf) | 
+
+## Welche Rückläufe gibt es nach der Veröffentlichung?
+### Überwiegend Positiv
+##### Firefox
+[Firefox Entwickler](https://hacks.mozilla.org/2026/05/behind-the-scenes-hardening-firefox/) berichten, dass sie im 150 Release, 271 bugs durch Mythos Preview beheben konnten. Laut ihrem Artikel war es ihnen möglich durch das neue Modell und ein neues Harnessing ihre Quote an gepatchten Bugs signifikant steigern.
+##### XBOW
+Die [IT-Security Firma XBOW](https://xbow.com/blog/mythos-offensive-security-xbow-evaluation) hat Mythos ebenfalls evaluiert und sieht das Modell als signifikanten 
+Schritt nach vorne. XBOW sieht die Stärken des Modells in der Analyse von Source Code und beim Reverse Engineering, 
+wobei das Modell auffällig gut in der Lage war False Positives zu identifizieren. XBOW sieht aber Limitierungen beim
+on-site Pentesting. Mythos allein reicht laut XBOW nicht aus um Sicherheitsdefizite in einer Softwareinfrastruktur 
+zu identifizieren. Hierbei gilt allerdings zu beachten, dass XBOW als Security Dienstleister auch Interesse daran hat weiterhin nachgefragt zu bleiben.
+##### Cloudflare
+[Cloudflare](https://blog.cloudflare.com/cyber-frontier-models/) erklärt in einem ausführlichen Artikel, dass Mythos für sie Stärken in der Code Analyse gezeigt 
+hat. Am beeindruckendsten waren dabei die Fähigkeiten zur Verkettung mehrerer Exploits und die Präzision beim
+Validieren von Schwachstellen. Besonders bemerkenswert ist hierbei der von Cloudflare verwendete Harness 
+(Geschirr oder Gurt). Einige der Agents laufen dabei in vielen parallelen Instanzen, die meisten Agents sind sogar in der Lage selbst weitere Agents zu starten. 
+##### Calif
+Sicherheitsforscher der [Firma Calif](https://blog.calif.io/p/first-public-kernel-memory-corruption) haben eine speicherbasierten Exploit für Apples M5 Chip gefunden. Die
+Implementation des Exploits enthält neben 2 Schwachstellen zahlreiche weitere Techniken und erlaubt einem
+Nutzer ohne Privilegien Root Rechte zu erlangen. Mythos Preview half dabei bei der Identifikation der Bugs und der Exploit-Entwicklung.
+##### AISI
+Das renommierte [AI Security Institute](https://www.aisi.gov.uk/blog/our-evaluation-of-claude-mythos-previews-cyber-capabilities) (Department for Science, Innovation & Technology UK) hat bei seiner Evaluation 
+in dem Modell einen sehr klaren Entwicklungsschritt erkannt. Bei Capture-The-Flag aufgaben zeigte Mythos durchweg sehr 
+gute Leistungen und brillierte besonders bei hohen Schwierigkeitsgraden. Außerdem ist Mythos Preview das erste Modell,
+welches "The Last Ones" erfolgreich abschließen konnte. Dabei handelt es sich um die Simulation eines Angriffs auf ein
+Unternehmensnetzwerk mit 32 Schritten. Bei einem komplexeren Parkour scheiterte Mythos Preview allerdings. Das AISI
+schließt daraus, dass Mythos Preview in der Lage ist Systeme mit schwachen/schlechten Security-Standarts kompromittieren
+kann.
+
+### Kritisch
+##### FlyingPenguin
+Der Information Security Experte [Davi Ottenheimer](https://www.flyingpenguin.com/the-boy-that-cried-mythos-verification-is-collapsing-trust-in-anthropic/) äußert sich in seinem Blog relativ kritisch zu dem Bericht. Seiner Meinung nach sind die Zahlen extrem aufgeblasen, so basieren beispielsweise die allermeisten der 250 gennanten Firefox Exploits auf zwei Bugs. Er findet die genutzen Benchmarks problematisch und zieht außerdem den Vergleich zu Fuzzing, da sehr viele Agents gleichzeitig den Code nach Lücken durchforsten. Hierbei wundert sich Ottenheimer warum keine Vergleich mit potentent Fuzzingsystemen gezogen wird. Er vermutet hinter der Kommunikation um Mythos Preview sehr viel Marketing.
+##### AISLE 
+[AISLE](https://aisle.com/blog/ai-cybersecurity-after-mythos-the-jagged-frontier) ein renommiertes Unternehmen, welches KI und IT-Security verbindet hat die Code-Abschnitte der von Anthropic genannten Schwachstellen isoliert und acht verschiedenen, kleinen Modellen zugeführt. Das Ergebnis: auch kleinere Modelle waren in der Lage die Schwachstellen zu identifizieren. Bei der FreeBSD Schwachstelle gelang das sogar jedem Modell. Natürlich wurde die Modelle hier schon auf die richtige Stelle im Code verwiesen, aber das Unterhnehmen wollte damit zeigen, dass Anthropic ihr Modell doch etwas aufgeblasen hatte. AISLE bestreitet aber nicht, dass Mythos Preview ein sehr fähiges neues Modell ist.
+##### cURL
+Der [curl Entwickler Daniel Sternberg](https://daniel.haxx.se/blog/2026/05/11/mythos-finds-a-curl-vulnerability/) hat seine Codebasis durch einen Dritten mit Mythos-Zugang analysieren lassen. Der resultierende Report enthielt fünf Schwachstellen, drei davon waren False Positives und eine weitere "nur" ein Bug. Damit blieb genau eine Schwachstelle, welche eine niedrige Kritikalität hat. Dabei gilt zu beachten, dass der Code von curl bereits sehr gut abgehangen ist. Die Entwickler nutzen statische Analyse, Fuzzer und KI-unterstützte Tools um Schwachstellen zu vermeiden. Sternberg hält die Art und Weise wie Mythos veröffentlicht wurde für einen großen Marketingstunt. Er findet KI zur Codeanalyse zwar sehr nützlich, aber seinen Beobachtungen nach werden nur bekannte Schwachstellen-Arten entdeckt.
+##### Harnessing?
+Unklar ist wieviel Unterschied die neuen Harnessing Infrastrukturen bei für die Effektivität der Modelle gebracht haben.
+
+### Was sagt Anthropic selbst?
+**In einem [Blogpost](https://www.anthropic.com/research/glasswing-initial-update) vom 22 Mai gibt Anthropic ein Update zu Glasswing. Der Inhalt lässt sich in drei Punkten zusammenfassen:**
+1. Die Glasswing Partnerunternehmen sollen insgesamt über 10 Tausend hohe und kritische Schwachstellen gefunden haben. Außerdem erwähnt Anthropic die positiven Testberichte des Modells von AISI, Mozilla und XBOW.
+2. In OpenSource Repositories sollen 6.200 mögliche Schwachstellen mit dem Schweregrad hoch und kritisch gefunden worden sein. Bisherige Auswertungen deuten an, dass 90.6% tatsächliche Schwachstellen sind und dass 62.4% tatsächlich dem Schweregrad hoch und kritisch entsprechen. Von ca. 1.451 Meldungen, die tatsächlich bei den betroffenen Maintainern angekommen sind, wurden bisher nur 97 gepatcht. 
+3. Anthropic führt dann noch aus welche Maßnahmen auch ihrer Sicht notwendig sind um auf diese neue Bedrohungslage zu reagieren.
+ 
+
+## Meine Einschätzung
+**Die Große Katastrophe dürfte ausbleiben:**
+
+- Natürlich werden durch leistungsstärkere Modelle und bessere Harnessing-Infrastruktur erstmal mehr Schwachstellen gefunden, auch einige Bugs die schon seit Jahren im Code existierten.
+- Dieses Meer an Lücken sollte jedoch irgendwann erschöpft sein und neuer Code kann vor der Inbetriebnahme mit ebendiesen Systemen untersucht werden. Demnach ähnelt die Einführung eines kompetenteren Modells der Einführung eines neuen, mächtigeren Fuzzing-Tools.
+- Bisher waren die Modelle nur in der Lage bekannte Schwachstellen-Gattungen zu reproduzieren, ob KI irgendwann einen völlig neuen Schwachstellentyp entdeckt ist unklar. 
+
+**Mythos Preview ist ein sehr potentes Modell, dass besonders bei der Schwachstellensuche in Quellcode glänzen kann. Obwohl die Aufregung rund um Project Glasswing meiner Meinung nach etwas übertrieben ist, werden KI-gestützte Systeme die Möglichkeiten zur Identifikation von Sicherheitslücken stark verändern.**
+

content/blog/revolution-oder-blase/index.md

@@ -1,78 +0,0 @@
-+++
-title = "Revolution oder Blase"
-date = "2026-03-12"
-description = "Was ich vom KI Hype halte"
-
-[taxonomies]
-tags = ["ki","meinung"]
-+++
-**Was ich vom KI Hype halte**
-
-Künstliche Intelligenz ist das Kernthema der meisten Diskurse die momentan im IT Kosmos geführt werden.
-Mir fällt auf, dass sich die meisten Talking Points unter zwei Erzählungen einordnen lassen:
-
-#### "Die jetzige KI ist nur Blendwerk"
-Eine relativ große Gruppe, darunter viele Akademiker, scheinen sich vor allem auf die Probleme und Schwächen
-der großen Sprachmodelle zu konzentrieren. Im Grunde ist dieser Ansatz wichtig, besonders da viele Benchmarks 
-und Metriken von der KI-Industrie erstellt werden und deshalb nicht ganz ohne Bias auskommen. Jedoch fällt mir auf, dass
-es einigen Kritikern eher darum geht KI gesamthaft zu diskreditieren. Persönlich glaube ich, dass diese Reaktion
-bei vielen Menschen mit Angst zu tun hat. Denn  anzuerkennen, dass wir der Modellierung von Intelligenz
-ein ganzes Stück näher gekommen sind, ist extrem besorgniserregend. 
-
-Diese Sorge ist meiner Meinung nach aber leider keinesfalls irrational. In unserer Gesellschaft sind Maschinen,
-die plötzlich eine deutlich größere Zahl an Aufgaben übernehmen können, eine ökonomische Bedrohung für Arbeitnehmer. Hinzu
-kommt die viel grundlegendere Frage ob eine Superintelligenz, also eine Intelligenz welche die kognitiven Fähigkeiten des
-klügsten Menschen bei weitem übersteigt, überhaupt erstrebenswert ist. Eines der meistzitierten Bücher zu KI, 
-*Superintelligence. Paths, Dangers, Strategies.* von Nick Bostrom, befasst sich auf mehreren hundert Seiten nur
-mit den Fragen wie uns die Superintelligenz zugrunde richten kann und wie schwierig es sein wird sie zu kontrollieren.
-Abgesehen davon, dass ich mit sehr vielen Ansichten von Nick Bostrom grundsätzliche Probleme habe (Transhumanismus, Longtermismus etc.),
-macht er in dem Buch durchaus gute Punkte. Die KI muss uns nichtmal feindlich gesinnt sein, damit ihre Existenz für den
-Menschen zur Katastrophe werden kann. Wir sind den anderen Tieren auf diesem Planeten auch nicht feindlich gesinnt,
-dennoch werden sie durch unsere Handeln massiv in Mitleidenschaft gezogen. Diese Dominanz entsteht nur durch den 
-Intelligenz-Gap zwischen uns und den Tieren, von denen uns viele ja sogar physisch überlegen sind.
-
-All das illustriert nur, dass die Bedenken gegenüber KI mehr als berechtigt sind. Diese ändern jedoch nichts am Fakt,
-dass auch aktuelle Sprachsysteme beeindruckende und nützliche Fähigkeiten haben, die über reines Googlen hinausgehen.
-Ich glaube nicht, dass die AGI bereits erreicht wurde, aber die neueren Entwicklungen der kognitiven Algorithmen sind
-trotzdem extrem disruptiv und die ersten Vorzeichen von einem neuen Zeitalter.
-#### "Die Revolution ist da"
-Der andere Standpunkt zu den aktuellen Entwicklungen im Feld der KI ist deutlich optimistischer. Zu optimistisch für
-meinen Geschmack. Alles ist jetzt KI oder KI-Assisted, für jede Aufgabe gibt es einen Agent und KI-Startupgründer
-unterbieten sich mit Prognosen für das Aussterben diverser Berufszweige. LLMs sind sehr praktisch und nützlich aber 
-haben immer noch sehr starke Limitierungen. Momentan kann niemand wirklich prognostizieren, ob Sprachmodelle irgendwann
-an eine gläserne Decke prallen werden. Denn aktuell werden Verbesserungen vor allem durch Skalierung erreicht, also mehr Daten
-mehr Hardware, mehr Daten, mehr Hardware etc. 
-
-Die Auswirkungen auf die Umwelt sind natürlich absolut Katastrophal. Abgesehen
-vom absurden Wasserverbrauch sind die riesigen Sprachmodelle extrem energieintensiv. Bei den Hyperscalern (Google, Amazon, Meta) 
-die sich vor kurzem noch auf C0² Neutralität committed haben, sieht die Welt durch den KI Hype mittlerweile ganz anders aus:
-* **Google** Steigerung von 48% der Treibhausgas-Emissionen in 2018-2023
-* **Microsoft** Steigerung von 29% der Treibhausgas-Emissionen in 2020-2023
-* **Meta** Steigerung von 49% der Treibhausgas-Emissionen nur in 2022
-
-![Meta Datacenter](1-datacenter.png)
-Meta plant den Bau eines Datacenters so groß wie Manhattan, ausschließlich im die eigene KI Infrastruktur zu verbessern. 
-Auch wenn sich beim Befragen von KI Modellen einiges optimieren lässt 
-(Stichwort: Speculative Decoding, Early Exciting etc.), ist aus einer ökologischen Sicht sehr davon abzuraten die Anzahl der KI Anfragen insgesamt zu steigern. 
-Genau das würde allerdings bei einer breiten Einbindung von Sprachmodellen in Arbeitsprozesse passieren. 
-
-Dabei sind, und das ist mir hier noch einmal wichtig zu betonen, diese Modelle nicht im klassischen Sinne intelligent. Sie erzeugen
-einfach eine Reihe von Sprachbausteinen(tokens) und wählen jeweils den nächst wahrscheinlichen Sprachbaustein (extrem vereinfacht). 
-Dabei wird auf Plausibilität optimiert, nicht auf Korrektheit, weshalb es zu den bekannten Halluzinationen kommt. Diese Fehler sind
-in der Praxis sehr gefährlich, weil sie plausibel aussehen und nur von Menschen mit Fachkenntnis im betroffenen Themengebiet enttarnt
-werden können. Woher soll der durchschnittliche Patient wissen, dass ihm der Gesundheits-Chatbot soeben eine tödliche Dosis eines 
-Medikamentes verschrieben hat. KI Modelle, modellieren Wahrscheinlichkeiten, auf eine sehr komplexe, einzigartige Weise, aber dennoch
-arbeiten sie auf Basis von Stochastik. Hier besteht natürlich eine extreme Gefahr für diverse Formen von Bias. Die KI ist mit Daten aus
-unserer Gesellschaft trainiert worden und wird somit all ihre diskriminierenden Defizite übernehmen. Hinzu kommt, dass die Modelle von
-Tech Bros mit fragwürdigem bis problematischem ideologischem Hintergrund kontrolliert werden. Zu diesem Thema kann ich das Büchlein
-*Künstliche Intelligenz und der neue Faschismus* von Rainer Mühlhoff empfehlen. 
-
-### Fazit
-Die Künstliche Intelligenz in ihrer aktuell verbreitetsten Form extrem nützlich, aber noch weit von einer Superintelligenz entfernt.
-Diese Nützlichkeit kommt jedoch zu einem sehr hohen ökologischen Preis und könnte bisher ungeahnte Folgen auf die Kognition der Menschen haben,
-die der KI große Teile des Denkens überlassen. Ich glaube die KI Revolution ist noch nicht gekommen, aber wir haben einen kleinen Vorgeschmack bekommen,
-wie disruptiv diese Revolution sein könnte. Die Technologie wird zugleich unter- und überschätzt und beide Lager haben ihre Gründe für ihre Standpunkte,
-aber die eigentlich zentrale Frage bleibt: wer entscheidet darüber wie diese Modelle eingesetzt werden. Ich finde es falsch, dass private Unternehmen 
-mit Profitinteressen entscheiden wie diese Modelle umgesetzt und eingesetzt werden. Das abgebildete Wissen in den Modellen wurde von der gesamten Gesellschaft
-produziert, weshalb ihr meiner Meinung ein Mitspracherecht zusteht. Außerdem ist die Technologie existenziell zu relevant, 
-um sie nur in die Obhut von ein paar Silicon Valley "Strategen" zu geben. 

content/blog/routing-protokolle/index.md

@@ -0,0 +1,107 @@
++++
+title = "Routing Protokolle"
+date = "2026-08-20"
+description = "Übersicht der gängigsten Routing Protokolle"
+
+[taxonomies]
+tags = ["networking", "routing"]
++++
+# Routing Protokolle
+Router sind dafür verantwortlich Pakete an die richtige Stelle im Netzwerk weiter zu leiten. Diese Routing-Entscheidungen basieren sie auf Regeln die in Routing-Tabellen definiert sind. Diese können entweder statisch definiert werden, oder mithilfe von Routing Protokollen befüllt werden. Diese Protokolle möchte ich heute vorstellen.
+Bei Routing Protokollen muss man zwischen zwei Hauptgattungen unterscheiden. Die **Interior Gateway Protocols (IGPs)** legen das Routing innerhalb eines **Autonomen Systems (AS)** fest, während **Exterior Gateway Protocols (EGPs)** das Routing zwischen Autonomen Systemne definiert. Das Internet ist ein Netzwerk aus Netzwerken. Ein Autonomes System steht hierbei für ein eigenständiges, unabhängiges Netzwerk. Beispiele dafür sind die Netwerke von Google (AS15169), Amazon (AS16509) oder der Deutschen Telekom (AS3320).
+```
+
+                                       
+                         Distance        _____RIPv1___RIPv2
+                         Vector         |
+                         Routing________|
+                         Protocols      |
+                            |           |_____IGRP
+             Interior       |
+             Gateway________|
+             Protocols      |
+                |           |
+                |           |             _____OSPF
+                |        Link-State      |
+                |        Routing_________|
+                |        Protocols       |
+Dynamic         |           |            |_____IS-IS
+Routing_________|           |  
+Protcols        |           |   
+                |           |
+                |        Hybrid_________EIGRP
+                |
+                |
+                |        
+            Exterior     Path-Vector
+            Gateway______Routing________BGP
+            Protocols    Protocols
+
+
+```
+## Interor Gateway Protcols
+### Distance Vector Routing
+Beim **Distance Vector Routing** Protokoll speichert jeder Router eine Tabelle, in welcher die Distanzen zu anderen Routern in hinterlegt sind. Diese Informationen teilen die Router mit ihren direkten Nachbarn. Danach wird kürzeste Distanz berechnet, mit der eine Ziel zu erreichen ist. In der Praxis könnte eine Tabelle für einen einzelnen Router z.B. so aussehen:
+
+| Destination | Cost | NextHop |
+|-------------|------|---------|
+|   A         | 1    | A       |
+|   B         | 1    | C       |
+|   C         | 2    | C       |
+|   D         | 2    | A       |
+|   E         | 2    | A       |
+|   F         | 3    | A       |
+
+Distance Vector Routing ist einfach zu Implementieren, braucht wenige Resourcen und ist in vielen Umgebungen einsetzbar. Allerdings konvergiert das System langsam, skaliert schlecht und führt unter Umständen zum "Count-to-Infinity" Problem.
+Verschiedene Protokolle stützen sich auf Distance Vector Routing:
+
+#### RIP
+Das **Routing Information Protocol** wurde 1988 im RFC 1058 definiert und basiert auf Distance Vector Routing. RIPv1 hat folgende Eigenschaften:
+
+- die Anzahl der Hops dienen als Distanz 
+- alle 30 Sekunden liefern die Router aktualisierte Tabellen per Broadcast aus
+- mehr als 15 Hops gelten als unendliche Distanz
+
+mit RIPv2 kamen 1993 einige Verbesserungen hinzu:
+
+- ein Authentifizierungsmechanismus für die Update-Kommunikation zwischen benachbarten Routern 
+- Ausliefern der Tabellen per Multicast statt per Broadcast
+- Tabelleneinträge können auf den einzelnen Routern zusammengefasst werden
+
+RIP lässt sich sehr leicht konfigurieren und eignet sich deshalb gut für kleinere Netzwerke. Allerdings ist RIP in größeren Netzwerken schlecht einsetzbar, weil die Reichweite praktisch auf 15 Hops limitiert ist.
+
+#### IGRP
+1984 entwickelt Cisco das **Interior Gateway Routing Protocol**, welches ebenfalls auf Distance Vector Routing basiert. Es benutzt diese Metriken um seine Routen zu berechnen:
+
+- Bandbreite des Pfades mit der geringsten Bandbriete
+- Topologisch bedingte Übetragungsdauer, also wie lange ein Paket in einem "leeren" Netzwerk brauchen würde
+- Zuverlässigkeit eines Pfades, also wieviele der verschickten Pakete tatsächlich ihr Ziel erreichen
+- Aktuelle Nutzung der Bandbreite
+
+IGRP adaptiert viel Funktionalitäten von RIP, ist aber für größere Netzwerke konzipiert worden. Dafür wurde maximale Hop-Anzahl auf 100 anghoben. Das Protokol ist darauf ausgelegt möglichst stabil zu sein und Loops zu vermeiden.
+
+### Link State Routing 
+Router die unter einem **Link State Routing Protokolle** teilen per Flooding ihre direkten Verbindunge mit allen anderen Routern im Netwerk. Dadurch kennt jeder Router die gesamte Netzwerktopologie und kann den schnellsten Pfad zu jedem Knoten mit dem Dijkstra Algorithmus berechnen. Update Nachrichten werden nur versendet wenn ein Router eine Änderung seiner verbundenen Links feststellt. Diese Methode führt zwar zu mehr Netzwerktraffic, weil jeder Router mit jedem Router kommunizieren muss, aber dafür konvergiert das System schneller. Außerdem gibt es keine persistenten Loops. Auch dieser Ansatz hat einige Protokolle begründet:
+
+#### OSPF
+Das **Open Shortest Path First Protokoll** wurde von der Internet Engineering Task Force entwickelt. Es zeichnet sich durch folgende Attribute aus:
+- Hierarchische Aufteilung des Netzes in Areas 
+- Area 0 eine besondere Stellung ein: alle anderen Areas müssen direkt (oder indirekt mit virtuellen Links) mit ihre verbunden sein
+- Designated Router (DR) verteilen Update-Informationen innerhalb eines Netzwerksegmentes 
+- Nutzung des Hello-Protokolls für das Erkennen und bestimmen von Nachbarn und um den DR zu bestimmen
+
+OSPF erfreut sich großer Beliebtheit in Unternehmensnetzen. Es ist auf IP Netzwerke ausgelegt, wird von allen Herstellern unterstützt und durch die weite Verbreitung sind viele Techniker mit dem Protokoll vertraut. Da allerdings jede Area mit der Kern Area 0 verbunden sein muss, bringt dieses Protokoll auch eine nenneswerte Limitierung mit.
+#### IS-IS
+Auch das **Intermediate System - Intermediate System** Protocoll nutzt den Dijkstra Algorithmus um den kürzesten Pfad zum Ziel zu berechnen. Von OSPF unterscheidet sich das Protokoll aber in mehreren Aspekten:
+- Unterscheidung zwischen Routern: Level 1 (Area), Level 1-2 (Intermediate) und Level 2 (Backbone)
+- Layer 2 Frames für seine Protokollnachrichten
+- Minimalistische Architektur
+
+Viele Internet Service Provider bevorzugen IS-IS, weil das Protokoll wegen der geringen Komplexität einfach zu implementieren ist. IS-IS kommt mit diversen Netzwerkinfrastrukture zurecht und wird gerne mit in Kombination mit MLPS genutzt. 
+
+### Hybrid
+#### EIGRP
+
+## Exterior Gateway Protocols
+### Path Vector Routing Protocols
+#### BGP

content/blog/systemd-vs-openrc/index.md

@@ -0,0 +1,71 @@
++++
+title = "Systemd vs OpenRC"
+date = "2026-07-17"
+description = "Vergleich zweier Design-Philosophien"
+
+[taxonomies]
+tags = ["linux"]
++++
+# Systemd vs. OpenRC
+Ich habe kürzlich einen Server mir Alpine Linux aufgesetzt. Die Distribution wurde mir von einem Kollegen empfohlen, der eher im BSD Kosmos heimisch ist und deshalb ein grundlegendes Problem mit Systemd hat. Da Alpine Linux den Ruf hat sehr schnell, stabil und schlank zu sein, habe ich mich dafür entschieden das Betriebssystem auszuprobieren. Alpine Linux benutzt nicht wie die meisten Linux-Disributionen Systemd als Initsystem, sondern verwendet OpenRC. Ich habe diese Gelegenheit als Aufhänger genommen um herauszufinden, warum Systemd in der Unix Community so umstritten ist und was OpenRC anders macht. 
+## Systemd
+Ein 2010 veröffentlichtes Init-System von Lennart Poettering(auch bekannt von **PulseAudio**) und Kay Sievers(auch bekannt von **udev**). Systemd setzt auf aggressive Parallelisierung um einen möglichst schnellen Bootprozes zu gewährleisten. Sofern die Abhängigkeiten es erlauben werden Prozesse so früh wie möglich und so parallel wie möglich gestartet. Neben dem Init-Daemon stellt Systemd auch noch ein Logging-System (**journald**), Login und Session-Management (**logind**), Netzwerkkonfiguration (**networkd**) und DNS Auflösung (**resolved**). Systemd wird standardmäßig von vielen gängigen Linux-Disributionen genutzt, darunter **Arch Linux**, **Debian** oder **RedHat**.
+### Technische Details
+#### Struktur
+Systemd abstrahiert das Betriebssystem in sogenannte **Units**. Zu den gängigsten Unit-Typen gehören:
+
+- **Service**: Daemons und Prozesse (z.B. nginx.service)
+- **Target**: Stellen einen Zustand des Systems dar und fassen mehrere Units zusammen (z.B. graphical.target)
+- **Socket**: Netzwerk- und Unix Domain Sockets (z.B. sshd.socket)
+- **Timer**: Regelmäßige Tasks als Alternative zu cron (z.B. backup.timer)
+- **Mount**: Mountpoints im Dateisystem (z.B. home.mount)
+- **Device**: Hardware Devices (z.B. dev-sda1.device)
+- **Path**: Monitoring von Dateien und Directories (z.B. config-watcher.path)
+
+Units werden in Konfigurationsdateien definiert. In sogenannten Unit-Files können Funktion und Art einer Unit beschrieben werden. Das Funktioniert vereinfacht gesagt in drei Abschnitten. Im **[Unit]** Abschnitt werden Metadaten und Beziehungen zu anderen Units definiert. Der zweite Abschnitt ist nach dem Unit-Typ benannt (z.B. **[Socket]**) und definiert was ausgeführt wird und wie es ausgeführt wird. Im **[Install]** Abschnitt wird das Verhalten beim Aktivieren und Deaktiveren der Unit definiert.
+
+#### Bootprozess
+
+1. Der Kernel startet systemd als PID 1
+2. Mounten des Dateisystems und Initialisieren der Hardware
+3. Bestimmen des zu erreichenden targets (normalerweise graphical.target oder multiuser.target)
+4. Bauen eines Trees basierend auf den Abhängigkeiten
+5. Paralleles Starten der Units basierend auf ihren Abhängigkeiten
+6. Erreichen des gewünschten Targets
+
+Damit soviele Services wie möglich gleichzeitig gestartet werden können, stellt Systemd D-Bus-Verbindungen und IPC-Sockets für einen Service bereit, bevor dieser überhaupt gestartet ist. Erhält ein Service auf diesem Weg Nachrichten, die er noch nicht annehmen kann, buffert der Kernel diese.
+
+## OpenRC
+Ein Init System des **NetBSD** Entwicklers Roy Marples für Unix-Systeme. OpenRC fokussiert sich dabei auf das Management der Abhängigkeiten. Das Programm ist dafür bekannt besonders schlank zu sein und einem einfachen und klaren Design zu folgen. Deshalb kommt OpenRC bei der performance-orientierten Distribution **Alpine Linux** zum Einsatz, welche sich vor allem durch ihre häufige Verwendung in Containern, immer größerer Beliebtheit erfreut. Auch **Gentoo Linux**, eine Distribution die sich an fortgeschrittene Nutzer, die nach viel Gestaltungsfreiheit suchen richtet, setzt auf das schlanke Init-System.
+### Technische Details
+#### Struktur
+In OpenRC werden Services in Runlevels unterteilt. Ein Runlevel stellt dabei einen bestimmten Zustand dar, für welchen die entsprechenden Services laufen müssen. Die folgenden Runlevel gibt es (unter anderem):
+
+- **default**: Standard Runlevel, welches normalerweise für das Hinzufügen neuer Services genutzt wird
+- **sysinit**: Startet Systemspezifische Prozesse wie /dev oder /sys und mounted das /lib/rc/init.d Verzeichnis, in welchem Runtime-Informationen über Services gespeichert werden  
+- **boot**: Mounten von Dateisystemen, Hardware-Initialisation und Logging
+- **single**: Terminiert alle Services die nicht ins sysinit Runlevel fallen
+- **reboot**: Wechselt in den shutdown Runlevel und startet den Host neu
+- **shutdown**: Wechselt in den shutdown Runlevel und stoppt den Host
+
+#### Bootprozess
+
+1. Der Init Prozess mit PID1 startet die OpenRC binary
+2. Bauen eines Abhängigkeitsgrafen basierend auf den Konfigurationsdateien der Runlevel und der Services 
+3. Starten der Service-Skripte (/etc/init.d) mit deren Konfigurationsdateien (/etc/init.d)
+4. Wenn alles Service-Skripte ausgeführt wurden terminiert OpenRC, es bleibt kein persistenter Daemon zurück
+
+OpenRC startet die Services standardmäßig serialisiert, also ein Service nach dem anderen, aber das Init System unterstützt auch einen parallelisierten Boot-Modus. Um die Services ohne persistenten Daemon-Prozess verwalten zu können, schreibt OpenRC Informationen über ihren Zustand in das Datesystem unter /lib/rc/init.d. 
+
+## Kontroverser Monolith gegen schlankes Einzwecksystem
+### Die großen Flame-Kriege
+Es gibt sehr wenige Themen in der Unix-Welt, die so kontrovers diskutiert werden wie Systemd. Um zu verstehen wie es dazu kommen konnte hilft ein Blick in die Historie. Die Software wurde 2010 von Pettering und Sievers programmiert. Beide Entwickler arbeiteten im Jahr der Veröffentlichung von Systemd für RedHat und das Init System wurde 2011 in **Fedora** standardmäßig aktiviert. Die Distribution setzte als erste per Default auf Systemd und wurde damit ihrem Ruf als Testballon für das RedHat Ökosystem gerecht. Je mehr Systemd an Popularität gewann, desto lauter wurden Stimmen sachlicher und unsachlicher Kritik. Diese richtete sich gegen das Design des Systems und gegen die Entwickler selbst.
+
+### Do many things and do them poorly
+Der Hauptkritikpunkt ist relativ einfach: Systemd verletzt die Unix Philosphie. Diese lautet: *do one thing and do it well*. Programme sollen im Unix-Universum möglichst einfach und schlank gestaltet werden, genau ein Problem lösen und für größere Aufgaben mit anderen Programmen zusammenarbeiten. **ls -l** zeigt den Verzeichnisinhalt an, möchte ich Infos über eine bestimmte Datei haben, kann ich den Output mit **grep "Dateiname"** verknüpfen etc. Systemd hingegen startet nicht nur Services beim booten, sondern implementiert ein Logging-System, Session Management, einen Netzwerk-Daemon und einen DNS-Resolver. Die hohe Komplexität von Systemd birgt automatisch ein gesteigertes Fehler- und Schwachstellenpotential, was viele besonders beim Init System sehr kritisch sehen. Auch dass die Logs nicht, wie für Unix üblich in Plaintext, sondern in Binär geschrieben werden, sorgt für Unmut.
+
+### Der Kernkonflikt: komplexe und einfache Software
+Systemd löst extrem viele Probleme. Es bootet durch die agressive Parallelisierung wahnsinnig schnell und verwaltet dabei Abhängigkeiten korrekt. Es vereinfacht die Konfiguration mithilfe der Unit Files und schafft mit seinen anderen Funktionalitäten ein kohärentes Ökosystem. Das Initsystem versucht die verschiedenen Distributionen zu vereinheitlichen, wodurch die Arbeit mit verschiedenen Linux Varianten erleichtert werden soll. Systemd soll eine umfangreiche Gesamtlösung darstellen und dabei mit guter Performance auftrumpfen. Software die so etwas leisten muss, wird automatisch komplex. 
+Das geht allerdings nicht unbedingt mit der ursprünglichen Unix Philosophie konform. OpenRC hingegen übernimmt nur die klassischen Aufgaben eines Init-Systems. Aber auch dieser Ansatz hat Nachteile. Bei OpenRC funktionieren weniger Dinge out of the box, um das Logging muss man sich auch selbst kümmern.
+Letztendlich stellt sich die Frage ob die Unix Philosophie den Anforderungen der heutigen Zeit Stand hält. Meine persönliche Antwort auf diese Frage ist ganz klar: ja. Einfache und schlanke Software vermeidet viele Probleme die wir mit IT-Systemen in der modernen Zeit haben. Das gilt für Schwachstellen, Administration, Ressourcenverbrauch und viele weitere Aspekte. Trotzdem ist die Entscheidung für Systemd in vielen Fällen sehr nachvollziehbar. Durch die weite Verbreitung ist man meistens schon mit dem Programm vertraut, außerdem arbeiten viele Entwickler am System mit. Man tauscht gestalterische Freiheit für mehrere fertige Features ein und das System ist sehr performant. Wie so oft gibt es kein richtig oder falsch. Beide Init-Systeme haben ihre Daseinsberechtigung.
+

content/projects/self_hosting/index.md

@@ -10,7 +10,7 @@ tags = ["selfhosting","linux"]
 [extra]
 local_image = "img/server_icon.svg"
 +++
-##### Stand 27.03.2026
+##### Stand 22.07.2026
 ## Einleitung
 Der folgende Artikel gibt einen Überblick zur aktuellen Architektur meiner privaten IT-Infrastruktur.
 Ich hatte mir am Anfang meines Studiums einen Raspberry Pi 4 gekauft und als ich mit dem Experimentieren
@@ -23,13 +23,14 @@ fertig war, suchte ich nach einem sinnvollen Verwendungszweck. So bin ich zum Se
 * **Datenschutz** - man entscheidet komplett selbst welche Daten wo vorliegen
 
 ## Infrastruktur
-Meine Self-Hosting Infrastruktur besteht aktuell aus sieben Maschinen. Fünf davon sind VPS 
+Meine Self-Hosting Infrastruktur besteht aktuell aus neun Maschinen. Sechs davon sind VPS 
 (**V**irtual**P**rivate**S**erver) die ich bei einem Cloud-Dienstleister anmiete. Bei den
-restlichen Servern handelt es sich um Raspberry Pis verschiedener Generationen. Die Pis sind
+restlichen Servern handelt es sich um zwei Raspberry Pis verschiedener Generationen, sowie 
+einem alten Desktop-PC den ich zum Server umfunktioniert habe. Die Pis und der Server sind
 über einen kleinen Netgear Switch per Ethernet verkabelt, da ich großen Wert auf stabile 
-Verbindungen und geringe Latenzen lege.
+Verbindungen und geringe Latenzen lege. 
 
-Auf den VMs läuft überall Debian, auf den Raspberries Arch. 
+Auf den VMs läuft überall Debian, auf den Raspberries Arch und auf dem Server Alpine Linux. 
 Ich komme eigentliche mit jedem Linux Distro gut zurecht, 
 aber ich nutze privat am liebsten Arch, weil mich das Rolling-Release Modell überzeugt und
 ich das Paketmanagement mit Arch (pacman, AUR usw.) mag.
@@ -37,31 +38,42 @@ ich das Paketmanagement mit Arch (pacman, AUR usw.) mag.
 ## Architektur 
 
 ```
-.......................... 
+                      CLOUD
-:    ____________   _____:______   ____________
+    ____________                  ____________  
-:   |  [ VM1 ]   | |  [ VM3 ]   | |  [ VM5 ]   |
+   |  [ VM1 ]   |  ____________  |  [ VM5 ]   |_______
-:   | PW-Manager | | Monitoring | |  jumphost  |
+   | PW-Manager | |  [ VM3 ]   | |  jumphost  |_____  |
-:   |____________| |____________| |____________|
+   |____________| | Monitoring | |____________|     | |
-:   :     ____________   :   ____________   |:| 
+         :        |____________|       :            | |
-:   :    |  [ VM2 ]   |  :  |  [ VM4 ]   |  |:|
+    ____________        :         ____________      | |      
-:   :    | benji0x3c  |  :  |  Git-Repo  |  |:|
+   |  [ VM2 ]   |  ____________  |  [ VM6 ]   |     | |      
-:   :    |____________|  :  |____________|  |:|
+   | benji0x3c  | |  [ VM4 ]   | |  jumphost  |     | |      
-:   :..........:.........:........:.....    |:|
+   |____________| |  Git-Repo  | |____________|     | |      
-:                                      : wg-Tunnel& 
+         :        |____________|       :            | |<- VPN-Tunnel
-:..SSH..........                       :    SSH     
+         :              :              :            | |
-               :                      SSH   |:|       
+         :..............:..............:            | |
-  Cloud        :                       :    |:|
+                        :                           | |
----------------:-----------------------:----|:|--------  
+                        :                           | |
-  On-Prem      :____________           :____|:|_____ 
+                       SSH                          | |
-               |  [ Pi2 ]   |          |  [ Pi1 ]   |
+                        :                           | |    
-               |  darkstat  |...SSH....|  Backups   |
+     ___________________:____________________       | |
-               | DiscordBot |          |  Ansible   |
+    |    ____________         ____________   |      | |
-               |____________|          |____________|
+    |   |  [ Pi2 ]   |       |  [ Pi1 ]   |_________| |
+    |   |  darkstat  |.......|   Soju     |___________|
+    |   | DiscordBot |       |  Ansible   |  |
+    |   |____________|       |____________|  |
+    |                              :         |
+    |                              :         |            
+    |                         _____:______   |
+    |                        |  [ PC1 ]   |  |
+    |                        | Automation |  |
+    |                        |  Backups   |  |
+    |   ON-PREMISE           |____________|  |
+    |________________________________________|
 ```
 Die Ascii-Grafik skizziert den groben Aufbau meiner Infrastruktur und ist relativ selbsterklärend. 
 Einige Details möchte ich dennoch hervorheben:
 + da Pi1 der die Maschine ist von der Ansible Automationen gestartet werden können, liegt sein public-key auf jedem anderen Server 
-+ da Pi1 und Pi2 nicht vom Monitoring Server erreicht werden können, pushen sie ihre Telemetrie-Daten selbstständig per SSH 
++ da Pi1, Pi2 und PC1 nicht vom Monitoring Server erreicht werden können, pushen sie ihre Telemetrie-Daten selbstständig per SSH 
 + um mein lokales Netz aus der Distanz warten habe ich eine externe VM per VPN Tunnel mit Pi1 verbunden
 
 ## Anwendungen
@@ -85,17 +97,20 @@ Ich hoste eine [Gitea](https://about.gitea.com/) Instanz für meine Repositories
 anderseits möchte weiß man bei Github mittlerweile nicht mehr wofür die eigenen Repositories genutzt werden.
 #### jumphost
 Ich habe eine sehr kleine VM die ich ausschließlich als Jumphost benutze, um aus dem WAN auf mein lokales Netzwerk zugreifen zu können.
-#### Backups: rsync
+#### Soju
-Auf einem der Raspberries läuft täglich ein Backupscript, welches die Backups von meinem Desktop-Rechner und den VPS Maschinen in der Cloud schreibt.
+Auf einem der Raspberries läuft Soju, ein IRC Bouncer, damit ich IRC Verläufe asynchron nachlesen kann. Ich halte mich nicht enorm viel in IRC Chats auf, aber finde diese reduzierte Art der Kommunikation sehr angenehm.
-Dafür nutze ich rsync um nur das Delta schreiben zu müssen und nicht bei jedem Durchlauf alles zu kopieren.
-Dabei werden aber nur für Daten mit sinnvollem Kosten-Nutzen Verhältnis Backups geschrieben, da ich Platz sparen möchte. Perspektivisch möchte ich regelmäßige
-Snapshots dieses Backups in ein Cloud schreiben, das ist aber aktuell aus Budget-Gründen noch nicht implementiert.
 #### Netzwerkanalyse: Darkstat
 Außerdem läuft auf einem der Pis [darkstat](https://unix4lyfe.org/darkstat/), ein Netzwerkanalyse-Tool, dass ich ausprobiert habe weil es extrem wenig Ressourcen benötigt und sehr praktisch ist,
 wenn man mehrere Geräte in einem Netzwerk verwaltet.
 #### DiscordBot
 Des weiteren läuft ein DiscordBot auf einem RaspberryPi, den ich selbst in Rust geschrieben habe. Der Bot wird nur von meinen Freunden und mir verwendet und braucht deshalb
 nicht viele Ressourcen.
+#### Backups: rsync
+Auf dem Server läuft täglich ein Backupscript, welches die Backups von meinem Desktop-Rechner und den VPS Maschinen in der Cloud schreibt.
+Dafür nutze ich rsync um nur das Delta schreiben zu müssen und nicht bei jedem Durchlauf alles zu kopieren.
+Dabei werden aber nur für Daten mit sinnvollem Kosten-Nutzen Verhältnis Backups geschrieben, da ich Platz sparen möchte. Perspektivisch möchte ich regelmäßige
+Snapshots dieses Backups in ein Cloud schreiben, das ist aber aktuell aus Budget-Gründen noch nicht implementiert.
+
 
 ## Fazit& Ausblick
 Es macht mir großen Spaß Anwendungen selbst zu hosten und die dafür benötigte Infrastruktur zu warten. An meinem aktuellen Setup gibt es aber noch vieles zu verbessern