Willkommen auf der Darknight-Coffee-Podcast-Plattform

Willkommen auf der Darknight-Coffee-Podcast-Plattform@carrabelloy

0 followers
Follow

This podcast contains premium episodes, only available to premium subscribers.

Unlock Subscribe

2026 episodes (30)

Der Rhysida-Hack – Wie Berlins Daten im Darknet landeten

Der Rhysida-Hack – Wie Berlins Daten im Darknet landeten

Podcast-Skript: Der Rhysida-Hack – Wie Berlins Daten im Darknet landeten 00:00–02:30 | Einleitung: Der Tag, an dem der Staat offline ging Mitte August 2026 brach das Chaos aus – nicht auf der Straße, nicht im Parlament, sondern im Inneren des Berliner Landesnetzes. Die Senatsverwaltungen für Stadtentwicklung, Bauen, Wohnen und für Mobilität, Verkehr, Klimaschutz und Umwelt wurden plötzlich vom Netz getrennt. Die Arbeit war lahmgelegt. Niemand wusste genau, was passiert war. Doch es war kein technischer Defekt. Es war ein Angriff. Die Hackergruppe Rhysida hatte sich über Tage hinweg Zugang verschafft, 5,79 Terabyte an Daten abgezogen – und forderte 30 Bitcoin, rund zwei Millionen Euro, als Lösegeld. Berlin sagte Nein. Und am 4. September 2026 veröffentlichte Rhysida die Daten im Darknet. Millionen von Dokumenten – von Personalakten bis zu Notfallplänen – sind jetzt öffentlich. Für Kriminelle. Für Journalisten. Für jeden, der weiß, wo er suchen muss. Das ist nicht nur ein IT-Versagen. Es ist ein Versagen des Staates. 02:30–06:00 | Kapitel 1: Die sieben Tage, die alles veränderten Am 7. August 2026 bemerkte die Senatsverwaltung für Mobilität einen ungewöhnlichen Datenfluss. Alarm. Doch statt sofort zu isolieren, ließ Berlin die betroffenen Abteilungen eine ganze Woche lang im Netz – bis zum 14. August. Sieben Tage. Zeit genug für Rhysida, tiefer einzudringen, sich zu verankern, Daten zu sammeln. Eine Woche, in der die Hacker Zugriff auf das gesamte Landesnetz hatten – ein Backbone, der 600 Behörden, Polizeistationen, Feuerwehren und Krankenhäuser verbindet. Das ist kein Einzelangriff. Das ist ein Systemversagen. Beispiele aus dem Serveralltag: Bei uns läuft eine Nginx-Instanz mit automatischem Fail2ban. Bei Verdacht auf Bruteforce oder Datenabfluss wird die IP innerhalb von Sekunden blockiert. Keine Diskussion. Keine Konferenz. Sofortige Isolation. In Berlin? Sieben Tage Wartezeit. Weil man sich nicht einigen konnte. Weil die Prozesse zu langsam waren. Weil die Infrastruktur zu verflochten ist. Zum Vorlesen: „Wenn der Staat nicht in der Lage ist, seine eigenen Systeme zu schützen, wer dann?“ 06:00–09:30 | Kapitel 2: Was ist in den Daten? Rhysida veröffentlichte nicht nur administrative Dokumente. Es sind sensible Dateien dabei, die niemals das Intranet verlassen hätten dürfen: Arbeitszeugnisse und Gehaltslisten von Angestellten E-Mails mit Passwörtern und IBANs KRITIS-Analysen zur Wasserversorgung Berlins Notfallpläne für den Verteidigungsfall Betriebsratsunterlagen und interne Beurteilungen Joachim Selzer vom Chaos Computer Club sagte: „Das ist für die Berliner Verwaltung schon unangenehm. Das sind natürlich sehr viele interne Daten, die nicht für die Öffentlichkeit bestimmt sind.“ Doch es ist mehr als „unangenehm“. Es ist gefährlich. Denn wer diese Daten hat, kann gezielt angreifen. Identitätsdiebstahl. Erpressung. Sabotage. Beispiel: In unserer Matrix-Instanz auf srv.darknight-coffee.org laufen alle sensiblen Daten über verschlüsselte Kanäle. Tokens werden rotiert, Backups sind segmentiert. Kein Einzelangriff kann das gesamte System gefährden. In Berlin? Ein einziges Netz. Ein einziger Fehler. Und alles ist offen. Zum Vorlesen: „Die digitale Souveränität beginnt bei der Sicherheit des Staates. Wenn der nicht schützt, wer dann?“ 09:30–13:00 | Kapitel 3: Die Hacker – wer ist Rhysida? Rhysida ist keine spontane Gruppe. Sie operiert seit 2023 als Ransomware-as-a-Service – professionell, kalt, zielgerichtet. Sie greifen Krankenhäuser, Schulen, Bibliotheken an. Und jetzt: eine europäische Hauptstadt. Ihre Taktik: Daten stehlen, erpressen, veröffentlichen. Kein Mitleid. Kein Kompromiss. Interessant: Die BBC berichtet, dass Rhysida vermutlich aus Russland und Osteuropa operiert – aber direkte Verbindungen zum russischen Staat liegen nicht vor. Es ist ein Geschäftsmodell: Cyberkriminalität als Dienstleistung. Beispiel: Auf unserem YunoHost-Server nutzen wir Fail2ban, rate-limiting und automatisierte Backups. Jeder Login-Versuch wird protokolliert. Jede anomale Aktivität löst einen Alarm aus. In Berlin? Kein Echtzeit-Monitoring. Keine automatisierte Reaktion. Nur manuelle Prozesse – zu langsam für eine moderne Bedrohung. Zum Vorlesen: „Wer sich nicht wehrt, wird ausgeraubt. Wer sich nicht wehrt, wird erpresst.“ 13:00–16:30 | Kapitel 4: Die Entscheidung – nicht zahlen Berlin hat nicht gezahlt. Und das ist gut so. Denn jedes gezahlte Lösegeld macht die nächsten Angriffe wahrscheinlicher. Es bestätigt das Geschäftsmodell der Kriminellen. Doch die Entscheidung hat einen Preis: Die Daten sind draußen. Und mit ihnen das Vertrauen der Bürger. Die Frage ist: War die Alternative – ein funktionierendes, sicheres Netz – jemals wirklich vorhanden? Beispiel: Bei uns läuft jede Konfiguration über Git. Jede Änderung ist dokumentiert, jeder Zugriff kontrolliert. Kein Backdoor. Kein unsicheres Passwort. Kein veraltetes System. In Berlin? Ein Netzwerk, das vor Jahrzehnten für Interoperabilität gebaut wurde – nicht für Sicherheit. Zum Vorlesen: „Ein System, das auf Komfort statt Schutz baut, ist kein System – es ist eine Einladung.“ 16:30–20:00 | Kapitel 5: Was können wir daraus lernen? Dieser Angriff ist kein Einzelfall. Er ist ein Symptom. Behörden agieren weiterhin mit veraltetem Sicherheitsdenken. Sie setzen auf zentrale Netze, schwache Authentifizierung, fehlende Segmentierung. Die Lösung? Zero-Trust-Architektur: Niemand ist vertrauenswürdig, bis bewiesen. Automatisierte Isolation: Bei Verdacht sofort trennen. Regelmäßige Audits: Kein System darf unkontrolliert bleiben. Öffentliche Transparenz: Bürger haben ein Recht zu wissen, wie ihre Daten geschützt werden. Beispiel: Unser Castopod-Server läuft hinter einem reverse proxy mit automatischem LetsEncrypt. Jede Anfrage wird validiert. Jeder Zugriff ist geloggt. Zum Vorlesen: „Sicherheit ist kein Zustand. Sicherheit ist eine Haltung.“ 20:00–23:30 | Kapitel 6: Die politische Verantwortung Wer trägt die Schuld? Nicht die IT-Mitarbeiter. Nicht die Hacker. Die politische Führung. Denn sie hat jahrelang die IT-Budgets gekürzt. Sie hat auf Komfort statt Schutz gesetzt. Sie hat die Warnungen ignoriert. Und jetzt? Jetzt tragen die Bürger die Folgen – mit gestohlenen Daten, mit fehlendem Vertrauen, mit steigenden Kosten. Dieser Krieg wird nicht mit Waffen geführt. Er wird mit Code geführt. Und wer nicht lernt, zu verteidigen, wird untergehen. Zum Vorlesen: „Die digitale Souveränität ist die neue Souveränität.“ 23:30–25:00 | Abschluss: Was jetzt? Der Rhysida-Hack ist kein Ende. Er ist ein Anfang. Ein Anfang für eine neue Haltung: mehr Transparenz, mehr Sicherheit, mehr Verantwortung. Ich fordere: Sofortige Sicherheitsaudits in allen Landesnetzen. Verpflichtende Zero-Trust-Modelle. Und eine öffentliche Aufklärung – nicht nur in Berlin. Wenn dir das Projekt hilft: Spendenlinks sind im Blog. Diskussion: treff.darknight-coffee.eu Blog: carrabelloy.darknight-coffee.org/blog

OpenMDW: Eine offene Lizenz ist noch keine offene KI

OpenMDW: Eine offene Lizenz ist noch keine offene KI

OpenMDW will einen einheitlichen, permissiven Rechtsrahmen für Modellmaterialien schaffen. Doch eine offene Lizenz beweist noch keine vollständige offene KI. Diese Folge trennt Lizenzrechte, Open Weights, Dateninformation, technischen Betrieb und echte Wechselmöglichkeit. Themen der Folge: was OpenMDW 1.1 tatsächlich regelt warum Lizenz und Open Source AI Definition nicht dasselbe sind offene Gewichte und ihre Grenzen Datenfluss, Tokenizer, Dokumentation und Restore europäischer Standort gegen wirkliche digitale Souveränität Materialbilanz und Exit-Test für Betreiber und öffentliche Beschaffung Der zugehörige Blogartikel: https://carrabelloy.darknight-coffee.eu/blog/blog/2026/09/02/openmdw-eine-offene-lizenz-ist-noch-keine-offene-ki/ Diskussion: https://treff.darknight-coffee.eu Blog: https://carrabelloy.darknight-coffee.org/blog/ Wenn dir das Projekt hilft: Spendenlinks sind im Blog. Hinweis: Die Folge ist keine Rechtsberatung. Der Stand der öffentlichen OSI-Lizenzprüfung wurde vor der Veröffentlichung erneut geprüft.

Vibe Code unter GPL? Wer trägt die Verantwortung für KI-generierten Quellcode?

Vibe Code unter GPL? Wer trägt die Verantwortung für KI-generierten Quellcode?

Ein Lizenzkopf schafft keine Herkunft. Diese Folge untersucht, was bei KI-generiertem Quellcode urheberrechtlich offen bleibt, weshalb möglicher fehlender Eigenschutz keine fremden Rechte beseitigt und warum freie Projekte Provenienz, menschliches Review und belastbare Tests brauchen. Themen der Folge: Urheberrecht und Copyleft bei LLM-generiertem Code menschliche Schöpfung und offene Rechtsfragen mögliche Fremdrechte trotz ungeschütztem Output Herkunftsketten, kleine Patches und nachvollziehbare Tests Maintainer-Arbeit als politische und ökonomische Machtfrage praktische Regeln für freie Projekte und selbstgehostete Infrastruktur Der zugehörige Blogartikel: https://carrabelloy.darknight-coffee.eu/blog/blog/2026/09/02/vibe-code-unter-gpl-ein-lizenzkopf-ersetzt-keine-herkunft/ Diskussion: https://treff.darknight-coffee.eu Blog: https://carrabelloy.darknight-coffee.org/blog/ Wenn dir das Projekt hilft: Spendenlinks sind im Blog. Hinweis: Die Folge ist keine Rechtsberatung. Belegte Tatsachen, offene Rechtsfragen und redaktionelle Bewertung werden getrennt.

Roundcube ist gepatcht – aber ist dein Server es auch?

Roundcube ist gepatcht – aber ist dein Server es auch?

„Roundcube ist gepatcht“ klingt beruhigend – sagt aber noch nicht, ob die Korrektur über den richtigen Paketweg auf dem eigenen Server angekommen ist. Diese Folge trennt Upstream, Debian-Backports und YunoHost-App-Pakete. Sie zeigt, warum vollständige Versionsstrings, aktive Plugins, Sicherung, Rückweg und reale Funktionstests wichtiger sind als eine grüne Updateanzeige. Ohne Alarmismus, aber mit klarer Betreiberverantwortung. Themen: • Roundcube 1.6.18 und 1.7.3 • Debian-Sicherheitsstände und Backports • YunoHost-App-Paketweg • markasjunk, managesieve und konkrete Voraussetzungen • Backups, Restore und Abnahmetests • digitale Souveränität als kontrollierbare Wartungskette Diskussion: https://treff.darknight-coffee.eu Blog: https://carrabelloy.darknight-coffee.org/blog/ Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

Merz träumt vom Fusionsreaktor – und bremst die Energie, die längst funktioniert

Merz träumt vom Fusionsreaktor – und bremst die Energie, die längst funktioniert

Friedrich Merz wertet Windräder als „hässlich“ ab und setzt politisch auf Kernfusion. Doch der Bund selbst räumt ein, dass die Technik noch lange nicht ausgereift ist: Mehr als zwei Milliarden Euro Forschungsförderung bis 2029, ein möglicher Prototyp erst zwischen den 2030ern und frühen 2040ern – und noch keine belastbare Serienkostenrechnung. Diese Folge trennt Forschung von politischer Werbung, untersucht Steuergeld, Asse, Langzeitkosten, erneuerbare Energien und die Machtfrage hinter zentraler Großtechnik. Artikel und Quellen: https://carrabelloy.darknight-coffee.org/blog/2026/08/26/merz-kernfusion-windkraft-energiepolitik/ Diskussion: https://treff.darknight-coffee.eu Blog: https://carrabelloy.darknight-coffee.org/blog/ Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

Wenn der Wald vor Schleiden braun wird: Wer trägt vor Ort Verantwortung?

Wenn der Wald vor Schleiden braun wird: Wer trägt vor Ort Verantwortung?

Braune Baumkronen neben grünen Beständen im Raum Schleiden sind sichtbar dokumentiert. Die Ursache ist damit noch nicht diagnostiziert. Genau deshalb braucht es eine fachliche Untersuchung, geklärte Eigentums- und Behördenzuständigkeiten sowie kommunale Rechenschaft. Diese Folge trennt Beobachtung, offene Schadursache und politische Verantwortung. Sie korrigiert den Bürgermeistername zu Ingo Pfennings, übernimmt keine unbelegte Urlaubsbehauptung und fragt stattdessen präzise nach Begehung, Ratsvorlagen, Budget, Wasserrückhalt, Brandvorsorge und langfristiger Pflege. Auch die Bürgerwaldidee wird am entscheidenden Maßstab geprüft: Nicht der Spatenstich zählt, sondern der Zustand nach fünf trockenen Sommern. Zugehöriger Blogartikel: https://carrabelloy.darknight-coffee.org/blog/2026/08/24/schleiden-wald-kommunale-verantwortung/ Diskussion: https://treff.darknight-coffee.eu/@carrabelloy Blog: https://carrabelloy.darknight-coffee.org/blog/ Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

KI-Aufsicht in Deutschland: Ein Eingang, viele Behörden – und die Machtfrage bleibt offen

KI-Aufsicht in Deutschland: Ein Eingang, viele Behörden – und die Machtfrage bleibt offen

Deutschland hat seit dem 29. Juli 2026 eine konkrete Aufsichtsarchitektur für die europäische KI-Verordnung. Die Bundesnetzagentur ist zentraler Kontakt- und Beschwerdeeingang, doch dahinter verteilen sich Zuständigkeiten auf Fach-, Finanz-, Landes- und Datenschutzbehörden sowie eine unabhängige Kammer. Diese Folge prüft, wer tatsächlich kontrolliert, warum ein zentraler Eingang noch keine wirksame Aufsicht beweist und welche Machtfragen bei sensibler Hochrisiko-KI offenbleiben. Das inzwischen freigeschaltete Beschwerdeformular wird praktisch eingeordnet: ausschließlich online, kostenfrei, mit Vorgangsnummer und Uploadgrenzen, aber ohne feste Bearbeitungsdauer. Zugehöriger Blogartikel: https://carrabelloy.darknight-coffee.org/blog/2026/08/24/ki-aufsicht-deutschland-ein-eingang-viele-behoerden/ Diskussion: https://treff.darknight-coffee.eu/@carrabelloy Blog: https://carrabelloy.darknight-coffee.org/blog/ Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

Minijobs verteuern, Arbeitszeit flexibilisieren – Lohndruck durch die Hintertür?

Minijobs verteuern, Arbeitszeit flexibilisieren – Lohndruck durch die Hintertür?

Minijobs werden für Arbeitgeber teurer, ihr bisheriger Sonderstatus steht zur Debatte – und gleichzeitig soll Arbeitszeit flexibler über die Woche verteilt werden. Jede Maßnahme wird einzeln begründet. Doch was entsteht, wenn sie im Betrieb gleichzeitig wirken? Diese Folge trennt sauber zwischen beschlossenem Recht, politischen Plänen und Carrabelloys Folgenanalyse. Wir sprechen über Minijob-Abgaben, Mindestlohn, 40- und 48-Stunden-Rahmen, wirtschaftlichen Druck trotz formaler Freiwilligkeit und die Tönnies-Fallstudie zu Werkverträgen, Subunternehmerketten und verspäteter politischer Kontrolle. Der vollständige Artikel mit Quellen und Transparenzhinweis: https://carrabelloy.darknight-coffee.org/blog/2026/08/23/minijobs-arbeitszeit-lohndruck-durch-die-hintertuer/ Diskussion: https://treff.darknight-coffee.eu Weitere Analysen: https://carrabelloy.darknight-coffee.org/blog/ Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

Der Staat zählt uns – aber nicht seine Überwachung

Der Staat zählt uns – aber nicht seine Überwachung

Deutschland zählt Überwachungsbefugnisse, Palantir-Verknüpfungen, Chatkontrolle und Scoring – aber die Gesamtwirkung auf Freiheit und Demokratie bleibt politisch unterbelichtet. Diese Folge verbindet staatliche Überwachung mit SCHUFA, Sozial- und Gesundheitsdaten sowie der Frage, wie KI aus verstreuten Datenspuren automatisierte Verdachts- und Ausschlussentscheidungen macht. Zum Blogartikel: https://carrabelloy.darknight-coffee.org/blog/2026/08/21/ueberwachungsgesamtrechnung-schufa-ki/ Diskussion: https://treff.darknight-coffee.eu/@carrabelloy Blog: https://carrabelloy.darknight-coffee.org/blog/ Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

Angekündigt ist nicht gestartet – Googles Android-Register

Angekündigt ist nicht gestartet – Googles Android-Register

Google baut mit der Android-Entwicklerverifizierung eine zentrale Kontrollschicht für Apps außerhalb des Play Stores. Diese Folge trennt belegte Termine von bloßen Ankündigungen und fragt, was Limited Distribution, Advanced Flow und die Registrierung von Paketnamen für F-Droid, kleine Entwickler und die Eigentümer der Geräte bedeuten. Zum Blogartikel: https://carrabelloy.darknight-coffee.org/blog/2026/08/21/android-verifizierung-angekuendigt-ist-nicht-gestartet/ Diskussion: https://treff.darknight-coffee.eu/@carrabelloy Blog: https://carrabelloy.darknight-coffee.org/blog/ Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

Android macht Freiheit zum Expertenmodus

Android macht Freiheit zum Expertenmodus

Google beginnt am 30. September 2026 mit der regionalen Durchsetzung seiner Android-Entwicklerverifizierung. Die Folge erklärt, was tatsächlich angekündigt wurde, warum F-Droids Build- und Signaturmodell mit einem zentralen Register kollidiert und weshalb Entwickleridentität keine Codeprüfung ersetzt. Kapitel: 00:00 Der Türsteher im Gerät 02:30 Zeitplan, Hobbykonto und Advanced Flow 05:10 F-Droids anderes Vertrauensmodell 08:00 Sicherheit und die Grenze der Identitätsprüfung 10:50 Freiheit als Sonderweg 13:40 Eigentum und Plattformmacht Blogartikel: https://carrabelloy.darknight-coffee.org/blog/2026/08/04/android-freiheit-im-expertenmodus-google-entwicklerverifizierung-fdroid/ Diskussion: https://treff.darknight-coffee.eu/@carrabelloy Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

Die stille Tür im Linux-Server – BPFDoor und der politische Preis offener Schwachstellen

Die stille Tür im Linux-Server – BPFDoor und der politische Preis offener Schwachstellen

BPFDoor ist eine passive Linux-Backdoor, die ohne dauerhaft sichtbaren Listening-Port auf präparierte Netzwerkpakete warten kann. Diese Folge erklärt Berkeley Packet Filter, Magic Packets, Reverse Shells, Erkennung und kontrollierten Neuaufbau kompromittierter Systeme. Im politischen Teil geht es um Telekommunikationsnetze, NIS2, den Cyber Resilience Act und den Konflikt zwischen staatlicher Cybersicherheit und dem Zurückhalten ausnutzbarer Schwachstellen. Blog und Quellen: https://carrabelloy.darknight-coffee.org/blog/ Diskussion: https://treff.darknight-coffee.eu Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

Souverän auf dem Papier – warum ein Vertragsmuster noch keinen Vendor-Lock-in bricht

Souverän auf dem Papier – warum ein Vertragsmuster noch keinen Vendor-Lock-in bricht

Podcastskript: Souverän auf dem Papier – warum ein Vertragsmuster noch keinen Vendor-Lock-in bricht Redaktionsstand: 30. Juli 2026 Geplante Sprechdauer: etwa 25 Minuten Status: Entwurf, nicht veröffentlicht, Freigabe durch Andreas erforderlich 00:00–03:20 — Kapitel 1: Eine geöffnete Tür ist noch kein Aufbruch Kernaussage: Deutschland hat 2026 brauchbare Hebel für souveränere IT-Beschaffung geschaffen. Eine allgemeine gesetzliche Open-Source-Pflicht gibt es aber nicht. Zwei Beispiele aus dem Server- und Community-Alltag: Eine Matrix-Community betreibt Synapse unter freier Lizenz, doch nur eine Person kennt die Admin-Tokens, Raumrechte und Wiederanlaufprozedur. Eine Behörde lässt eine offene Webanwendung hinter Nginx installieren, erhält aber weder Proxy-Konfiguration noch dokumentierten Datenexport vom Dienstleister. Zum Vorlesen: „Eine Vertragsvorlage beendet keinen Vendor-Lock-in – das schafft erst ein Vertrag, der den Ausstieg technisch und rechtlich absichert.“ Deutschland hat Open Source zum Standard gemacht. So könnte man die Meldungen der vergangenen Monate verstehen. Ein neues Vergabegesetz, modernisierte IT-Vertragsmuster, ein Deutschland-Stack mit offenen Standards: Das klingt nach der großen Wende. Nach dem Ende der ewigen Abhängigkeit von einzelnen Softwarekonzernen. Aber genau hier müssen wir bremsen und den Wortlaut lesen. Seit dem 1. Juli 2026 kann digitale Souveränität ausdrücklich als Zuschlagskriterium bei öffentlichen Vergaben berücksichtigt werden. Acht sogenannte EVB-IT-Vertragsmuster wurden überarbeitet, damit Behörden Open-Source-Software rechtssicher beschaffen können. Neue Softwareprojekte werden in diesen Mustern nach Angaben des Bundesdigitalministeriums als Open Source zum Standard gemacht. [3][5] Das sind echte Fortschritte. Doch das Vergabebeschleunigungsgesetz schreibt Open Source nicht allgemein vor. Im veröffentlichten Regelungstext kommen die Begriffe „Open Source“, „Software“ und „Quellcode“ nicht vor. Und § 58 Absatz 2 der Vergabeverordnung sagt, Aspekte digitaler Souveränität können berücksichtigt werden. Dort steht nicht „müssen“. [3][4] Diese Differenz ist keine juristische Wortklauberei. Sie entscheidet darüber, ob eine Beschaffungsstelle handeln muss oder nur handeln darf. Eine Erlaubnis kann eine mutige Vergabe absichern. Sie zwingt aber keine Behörde, ihre gewohnten Ausschreibungen zu ändern. Und ein Vertragsmuster kann gute Klauseln anbieten. Es garantiert nicht, dass jede Klausel im einzelnen Vertrag landet. Der neue Deutschland-Bericht des europäischen Open Source Observatory, kurz OSOR, beschreibt Deutschland als führendes europäisches Beispiel für Open Source im öffentlichen Sektor. Der Bericht nennt ZenDiS, openDesk, openCode, die Sovereign Tech Agency und den Deutschland-Stack. Das ist als Gesamtbild nachvollziehbar. An einer entscheidenden Stelle formuliert der Bericht jedoch stärker als der deutsche Normtext: Er spricht davon, Beschaffungsstellen seien verpflichtet, digitale Souveränität bei nicht preislichen Kriterien zu berücksichtigen. Außerdem soll ein Anhang Open Source und offene Standards als Beispiele nennen. Im verkündeten Gesetzestext lässt sich das so nicht belegen. [1][2][3] Belegte Tatsache: Die neuen rechtlichen und vertraglichen Werkzeuge existieren. Nachprüfung vom 31. Juli 2026: Die Fußnote 37 des OSOR-Berichts verweist ausschließlich auf BGBl. 2026 I Nr. 137. Der amtliche 19-seitige Regelungstext enthält keinen Anhang und keinen Treffer für „Open Source“, „offene Standards“, „Software“ oder „Quellcode“. Die Behauptung ist daher durch die vom OSOR selbst genannte Quelle nicht gedeckt und wird als fehlerhafte Darstellung des Länderberichts behandelt. Meine Meinung: Gerade wer Open Source politisch stärken will, darf aus einem „kann“ kein „muss“ machen. Übertreibung hilft der Sache nicht. Sie verdeckt, wo der eigentliche Konflikt liegt: in jeder einzelnen Ausschreibung, in jedem Vertrag und im späteren Betrieb. Das kennen wir aus dem Community-Alltag. Synapse ist freie Software. Das allein verhindert aber nicht, dass nur eine Person den Dienst retten kann. Wenn Admin-Tokens, Raumrechte, Signaturschlüssel und Restore-Ablauf nicht dokumentiert sind, ist die Community abhängig – nicht von einer Lizenzfirma, aber von einem Wissensmonopol. Dasselbe passiert bei einer offenen Webanwendung. Der Quellcode liegt vielleicht öffentlich. Wenn aber Nginx-Regeln, Zertifikatserneuerung, Datenbankmigration und Monitoring beim bisherigen Integrator bleiben, kann der Auftraggeber den Betreiber nicht real wechseln. Offenheit auf dem Papier ist noch keine Handlungsfähigkeit. 03:20–06:40 — Kapitel 2: Was das Vergabegesetz wirklich geändert hat Kernaussage: Das Gesetz erleichtert die Berücksichtigung digitaler Souveränität, definiert aber weder eine Open-Source-Pflicht noch einen automatischen Vorrang. Zwei Beispiele aus dem Server- und Community-Alltag: In einer Ausschreibung erhält ein Angebot Punkte für einen europäischen Hostingort, obwohl Datenexport und Schnittstellen proprietär bleiben. Ein Matrix-Angebot wirbt mit souveränem Betrieb, bindet Identität, Push-Dienst und Benutzerverwaltung aber an Zusatzdienste eines einzigen Anbieters. Zum Vorlesen: „Ein Rechenzentrum in Europa macht eine geschlossene Sackgasse noch nicht souverän.“ Das Gesetz zur Beschleunigung der Vergabe öffentlicher Aufträge wurde nach Angaben der Bundesregierung am 23. April 2026 vom Bundestag beschlossen, am 8. Mai vom Bundesrat angenommen, am 18. Mai im Bundesgesetzblatt verkündet und trat am 1. Juli in Kraft. Sein Schwerpunkt liegt nicht auf Open Source. Es soll Vergaben insgesamt beschleunigen und vereinfachen: durch höhere Direktauftragsgrenzen, flexiblere Gesamtvergaben, weniger Nachweispflichten, schnellere Nachprüfungsverfahren und mehr elektronische Kommunikation. [3][6] Für digitale Souveränität ist die Änderung von § 58 Absatz 2 VgV wichtig. Dort werden Kriterien genannt, die neben Preis und Kosten in die Zuschlagsentscheidung einfließen können. Neu hinzugekommen sind „Aspekte der digitalen Souveränität“. [4] Damit bekommt eine Vergabestelle eine deutlichere Rechtsgrundlage, nicht nur den kurzfristig niedrigsten Preis zu betrachten. Sie kann etwa Kontrollrechte, Datenportabilität, offene Schnittstellen, Abhängigkeiten oder Betriebsstandorte bewerten. Das ist relevant, weil der billigste Einstieg langfristig sehr teuer werden kann, wenn ein späterer Anbieterwechsel praktisch unmöglich ist. Aber die Norm beantwortet zwei Fragen nicht. Erstens definiert sie an dieser Stelle nicht, was digitale Souveränität im einzelnen Verfahren genau bedeutet. Ein Auftraggeber kann darunter Open Source und offene Standards verstehen. Er kann aber auch nur auf einen europäischen Unternehmenssitz, einen bestimmten Hostingort oder besondere Sicherheitsanforderungen schauen. Zweitens verpflichtet die Formulierung „können berücksichtigt werden“ nicht zur Anwendung. Eine Beschaffungsstelle, die weiter hauptsächlich Preis, bekannte Marken und bestehende Rahmenverträge gewichtet, wird durch diesen Satz allein nicht gestoppt. Das ist politisch heikel. Denn „europäisch“ und „souverän“ sind nicht dasselbe. Ein europäischer Anbieter kann Daten in geschlossenen Formaten halten, Schnittstellen nur gegen Aufpreis öffnen und den Betrieb an sein eigenes Kontrollpanel binden. Dann bleibt die Wechselmacht beim Unternehmen. Umgekehrt kann eine international entwickelte Open-Source-Komponente in Deutschland kontrolliert, geprüft, betrieben und notfalls von einem anderen Dienstleister weitergepflegt werden. Nehmen wir ein Matrix-Angebot. Der Anbieter betreibt Synapse in einem deutschen Rechenzentrum. Das klingt souverän. Doch die Benutzerkonten hängen an seinem Identitätsdienst. Push-Benachrichtigungen laufen über eine geschlossene Zusatzkomponente. Admin-Tokens werden nicht an den Auftraggeber übergeben. Ein vollständiger Export von Rollen, Räumen und Moderationsregeln ist nicht Vertragsbestandteil. Dann ist zwar der Serverstandort europäisch, der Wechselpfad aber blockiert. Oder eine Webplattform: Die Daten liegen in Frankfurt, aber nur das herstellereigene Panel kann sie vollständig exportieren. Die Nginx-Konfiguration ist „Betriebsgeheimnis“, die Dokumentation bleibt unvollständig, und ein zweiter Betreiber kann den Dienst nicht starten. Das ist geografische Nähe ohne technische Kontrolle. Technische Analyse: Digitale Souveränität braucht messbare Kriterien. Dazu gehören vollständiger Daten- und Konfigurationsexport, dokumentierte Schnittstellen, kontrollierte Schlüssel, unabhängige Betriebsrechte und eine nachweisbare Migration. Meine Meinung: Der neue § 58 ist eine geöffnete Tür. Jetzt braucht es Verwaltungen, die hindurchgehen, und politische Kontrolle darüber, welche Kriterien sie tatsächlich verwenden. Sonst wird „digitale Souveränität“ zum dehnbaren Etikett für dieselben alten Verträge. 06:40–10:10 — Kapitel 3: Die EVB-IT sind der praktische Hebel Kernaussage: Die modernisierten EVB-IT können den juristischen Aufwand für Open-Source-Beschaffung senken. Ihre Wirkung hängt aber davon ab, welche Klauseln konkret vereinbart werden. Zwei Beispiele aus dem Server- und Community-Alltag: Ein Dienstleister liefert eine Synapse-Anpassung samt Quellcode, aber ohne Build-Anleitung, Abhängigkeitsliste und Rückfluss der Änderungen an das Upstream-Projekt. Eine Nginx-basierte Fachanwendung wird mit Software Bill of Materials übergeben, doch Backup und Wiederherstellung sind im Abnahmetest nicht enthalten. Zum Vorlesen: „Ein Mustervertrag ist ein Werkzeug – ob daraus Freiheit entsteht, entscheidet der ausgefüllte Vertrag.“ EVB-IT steht für „Ergänzende Vertragsbedingungen für die Beschaffung von IT-Leistungen“. Diese Muster werden von Bund, Ländern und Kommunen genutzt. Sie übersetzen Anforderungen in Vertragsklauseln: Welche Software wird geliefert? Welche Rechte erhält der Auftraggeber? Wie werden Pflege, Anpassung, Dokumentation, Haftung oder Abnahme geregelt? Am 20. März 2026 meldete das Bundesministerium für Digitales und Staatsmodernisierung, acht Vertragsmuster seien für die rechtssichere Beschaffung von Open Source überarbeitet worden. Die Entwicklung und Bereitstellung neuer Softwareprojekte als Open Source werde als Standard abgebildet. Zusätzlich sehen die Muster nach Ministeriumsangaben Optionen für mehr Transparenz vor, darunter die Übergabe einer Software Bill of Materials, kurz SBOM. Proprietäre Software bleibt trotzdem ausdrücklich beschaffbar. [5] Warum ist das wichtig? Weil Open-Source-Beschaffung bislang oft individuellen juristischen Aufwand erzeugt hat. Standardklauseln können diese Reibung senken. Eine Vergabestelle muss dann nicht jedes Mal von vorn erklären, wie freie Lizenzen, Quellcodebereitstellung und Nutzungsrechte in einen öffentlichen Vertrag passen. Aber auch ein gutes Muster ist keine automatische Abnahmegarantie. Ein Beispiel: Eine Behörde lässt ein Zusatzmodul für Synapse entwickeln. Der Quellcode wird geliefert. Formal ist die Forderung erfüllt. Doch ohne Build-Anleitung, genaue Abhängigkeiten, Testumgebung und Release-Prozess kann ein anderer Betreiber daraus möglicherweise kein lauffähiges Paket herstellen. Wenn Änderungen nicht sauber upstream eingebracht werden, trägt die Behörde außerdem dauerhaft einen eigenen Sonderstand. Bei jedem Sicherheitsupdate muss sie hoffen, dass der ursprüngliche Dienstleister die Anpassung erneut einpflegt. Die SBOM verbessert die Transparenz. Sie listet Softwarekomponenten und Abhängigkeiten auf. Bei einer Sicherheitslücke lässt sich schneller prüfen, ob der eigene Dienst betroffen ist. Doch eine SBOM spielt kein Update ein. Sie definiert keine Reaktionszeit, benennt keine verantwortliche Stelle und garantiert keinen gepflegten Patchpfad. Ein zweites Beispiel: Eine Nginx-basierte Anwendung wird vollständig dokumentiert und mit SBOM übergeben. Das ist gut. Bei der Abnahme wird aber nur geprüft, ob die Startseite erreichbar ist. Niemand testet, ob Datenbank, Medien, Zertifikate, Konfiguration und Secrets aus einem Backup auf einer frischen Umgebung wiederhergestellt werden können. Der Vertrag hat Transparenz gekauft, aber noch keine Wiederanlauffähigkeit. Eine wirklich souveräne Vertragsgestaltung sollte mindestens klären: unter welcher anerkannten freien Lizenz der vollständige Quellcode bereitgestellt wird

Spende, Support, Steward – wo der CRA Open Source einsortiert

Spende, Support, Steward – wo der CRA Open Source einsortiert

Shownotes Die Kommission billigte am 27. Juli 2026 den Inhalt eines 84-seitigen CRA-Leitlinienentwurfs. Die Leitlinie ist nicht bindend und soll erst nach Vorliegen aller Sprachfassungen förmlich angenommen werden. Die CRA-Meldepflichten beginnen am 11. September 2026: Frühwarnung spätestens nach 24 Stunden, weitere Meldung binnen 72 Stunden. Ein Beitrag macht niemanden automatisch zum Hersteller

Waldbrand, Beton und die grüne Fassade

Waldbrand, Beton und die grüne Fassade

Waldbrände werden oft auf eine bequeme Alternative verkürzt: Brandstiftung oder Klimawandel. Diese Folge trennt Zündquelle, Brennstoff, Feuerwetter, Landschaft und Einsatzfähigkeit – und führt die Analyse bis nach Schleiden und ins Dieffenbachtal. Themen sind Frankreichs verspätete Canadair-Beschaffung, Hochwasserschutz zwischen natürlichem Rückhalt und Beton, Flächenversiegelung auf dem Campingplatz, Kahlschläge im Dreiländereck sowie der Konflikt zwischen Windenergie, Wald-, Boden- und Artenschutz. Offene Projektzahlen und die mögliche Fällung am Campingplatz werden ausdrücklich nicht als erwiesene Tatsachen dargestellt. Der Prüfauftrag lautet: öffentliche Genehmigungen, Ratsakten, Rodungsflächen und Netzanschlüsse nachvollziehbar machen. Beitrag und Quellen: https://carrabelloy.darknight-coffee.org/blog/2026/07/28/waldbrand-beton-und-die-gruene-fassade/ Diskussion: https://treff.darknight-coffee.eu/@carrabelloy Blog: https://carrabelloy.darknight-coffee.org/blog/ Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

Regain Control: Wem dient dein Smartphone?

Regain Control: Wem dient dein Smartphone?

Regain Control: Wem dient dein Smartphone? Ein Smartphone kann dir gehören und trotzdem den Interessen anderer dienen. Du hast es bezahlt, hältst es in der Hand und darfst über Kratzer und Hülle entscheiden. Aber wer entscheidet über Updates, vorinstallierte Dienste, Datenerfassung, Bootloader und Lebensdauer? Genau deshalb ist die neue Formulierung auf der postmarketOS-Webseite stark: nicht bloß „Full Control“, sondern „Regain Control“ – Kontrolle zurückgewinnen. Der Satz erkennt an, dass Kontrolle längst verteilt wurde: an Hersteller, Plattformen, Werbenetzwerke und geschlossene App-Ökosysteme. Eigentum am Gehäuse reicht nicht Kontrolle besteht aus mehreren Ebenen. Quellcode muss prüfbar sein. Software muss verändert und ersetzt werden können. Daten und Dienste müssen exportierbar sein. Und es braucht einen Rückweg, wenn eine Änderung scheitert. Open Source garantiert das nicht automatisch. Ein öffentliches Repository kann schlecht dokumentiert, ungetestet oder verlassen sein. Aber offener Code schafft die Voraussetzung dafür, dass Aussagen überprüft, Probleme gemeinsam bearbeitet und Arbeiten von anderen fortgesetzt werden können. Für mein Fairphone FP4 wird das konkret. Reparierbare Hardware ist ein starkes Stück Souveränität. Doch ein austauschbarer Akku allein reicht nicht, wenn die Software zum Endpunkt wird. Umgekehrt hält ein freier Kernel kein Gerät am Leben, dessen Display oder Akku nicht ersetzt werden kann. Langlebigkeit braucht beides: reparierbare Hardware und langfristig pflegbare Software. Zusammenarbeit statt technischem Kleinstaat Ein weiterer aktueller Änderungsvorschlag für die postmarketOS-Startseite schärft den Abschnitt „Connecting Projects and People“. Die Kernaussage: postmarketOS baut nicht alles selbst neu. Das Projekt verwendet vorhandene freie Arbeit, verbessert sie und gibt Änderungen möglichst an Linux, Bibliotheken, Dienste und Anwendungen zurück. Das ist keine Schwäche. Souveränität bedeutet nicht, jedes Rad allein neu zu erfinden. Sie bedeutet, gemeinsame Grundlagen prüfen, beeinflussen und notfalls ersetzen zu können. Eine Momentaufnahme der offenen Arbeiten im pmaports-Projekt vom 25. Juli 2026 zeigt, wie breit diese Zusammenarbeit ist: Kernel werden aktualisiert. Menschen übernehmen Maintainer-Rollen. Wayland-Umgebungen erhalten Startkorrekturen. Modem-, Audio-, Tastatur- und Energieprobleme werden bearbeitet. CI-Läufe werden an neue Architekturen angepasst. neue Geräte kommen hinzu, unbetreute Geräte werden archiviert. Diese Liste ist keine fertige Funktionszusage. Ein „Draft“ ist ein Entwurf. „Request for test“ verlangt praktische Prüfung. Eine bestandene Pipeline bestätigt nur die definierten automatischen Tests. „Merged“ bedeutet, dass eine Änderung in einen Zweig übernommen wurde – nicht, dass sie auf jeder Hardware zuverlässig funktioniert. Gerade diese Unterschiede machen das Projekt glaubwürdig. Eine rote Pipeline kann mehr Vertrauen schaffen als eine grüne Werbebroschüre, wenn sie ein Problem vor der Auslieferung sichtbar macht. Maintainer sind Infrastruktur Bei mobilen Linux-Systemen schauen Nutzer zuerst auf Gerätebilder und Funktionslisten. Dahinter steht eine weniger sichtbare Frage: Wer reagiert, wenn sich Kernel, Compiler, Oberfläche oder Hardwareunterstützung verändern? In der aktuellen Arbeitsliste stehen technische Änderungen und Zuständigkeitswechsel nebeneinander. Für den PinePhone Pro werden sowohl ein neuer Kernelstand als auch Maintainer-Anpassungen vorgeschlagen. Für Xiaomi beryllium möchte jemand die Pflege übernehmen. Andere Änderungen warten ausdrücklich auf Maintainer-Review. Das ist entscheidend. Ein neuer Kernel ohne Menschen, die Fehlerberichte einordnen und reale Geräte testen, ist kein nachhaltiger Fortschritt. Auch Archivierung gehört zu ehrlicher Pflege. Ein archivierter Port wird nicht automatisch wertlos oder gelöscht. Das Projekt kennzeichnet jedoch, dass aktuelle Verantwortung fehlt. Neue Maintainer können ihn später wiederbeleben. Eine kürzere, ehrliche Geräteliste ist besser als eine lange Liste technischer Versprechen ohne belastbare Pflege. Nachhaltigkeit ist unspektakuläre Dauerarbeit Lange Gerätenutzung entsteht nicht durch einen grünen Aufkleber. Sie entsteht durch kleine, fortlaufende Arbeiten: ein korrigierter Start einer Wayland-Oberfläche, ein funktionierendes Modem, eine deutsche Hardwaretastatur, weniger unnötige Pakete, eine aktualisierte Audiokonfiguration, ein reparierter Ladevorgang, angepasste Compiler- und Kernelkonfigurationen. Jede Änderung wirkt klein. Zusammen entscheiden sie darüber, ob ein Gerät nur theoretisch startet oder im Alltag benutzbar bleibt. Dasselbe gilt beim Selbsthosting. Ein Matrix-Homeserver bleibt nicht souverän, weil Synapse einmal installiert wurde. Datenbankmigrationen, Backups, Medien, Zertifikate, .well-known, Nginx und Zugangstokens benötigen dauerhafte Pflege. Ein offener Bauplan ersetzt keine Instandhaltung. Kontrolle ist eine Beziehung postmarketOS ist keine fertige Lösung für jeden Menschen und jedes Gerät. Kamera, Modem, Energiemanagement, Bankanwendungen und Sicherheitsanforderungen müssen konkret geprüft werden. Ein Fairphone FP4 mit mobilem Linux ist nicht automatisch alltagstauglich, nur weil das Ziel richtig ist. Doch das Projekt zeigt, wie digitale Souveränität praktisch aussehen kann: Arbeit wird sichtbar. Zuständigkeiten werden öffentlich. Grenzen werden benannt. Verbesserungen fließen in gemeinsame Projekte zurück. Die entscheidende Frage lautet deshalb nicht nur: „Ist der Code offen?“ Wir sollten fragen: Wer kann ihn bauen und prüfen? Wer pflegt ihn? Wer dokumentiert seine Grenzen? Wer übernimmt, wenn ein Maintainer ausfällt? Können Verbesserungen an andere freie Projekte zurückgegeben werden? Kann der Nutzer sein Gerät weiterverwenden, wenn der Hersteller längst das nächste Modell verkaufen möchte? Kontrolle zurückzugewinnen heißt nicht, alles allein zu machen. Es heißt, gemeinsam genutzte Technik prüfen, verändern und notfalls verlassen zu können. Diskussion: https://treff.darknight-coffee.eu Podcast: https://podcast.darknight-coffee.org/pages/startseite Blog: https://carrabelloy.darknight-coffee.org/blog/ Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

AGI ist da? Gegen den Hype, gegen die Blockade – für souveräne KI

AGI ist da? Gegen den Hype, gegen die Blockade – für souveräne KI

Shownotes Warum die Frage nach AGI ohne klare Definition von Breite, Leistungsniveau und Autonomie in die Irre führt. Weshalb starke Fähigkeiten keine Verantwortung ersetzen: minimale Rechte, Protokolle, Verifikation und Rückwege. Drei blinde Flecken der KI-Debatte: Rendite-Hype, ungesicherte Experimentierfreude und pauschale Technikabwehr. Physical AI: Datenschutz, Produktsicherheit und Haftung, sobald lernende Systeme physisch handeln. Europas Gegenpool aus eigener Infrastruktur, offenen Standards, wirksamer Regulierung und dauerhafter Wartung. Arbeit und Bildung: Produktivitätsgewinne sind eine Verteilungsfrage, kein technischer Automatismus. Sieben Leitlinien für souveränen KI-Einsatz in Community- und Serverbetrieb. CTA Diskussion: https://treff.darknight-coffee.eu/@carrabelloy Podcast: https://podcast.darknight-coffee.org/pages/startseite Blog: https://carrabelloy.darknight-coffee.org/blog/ Wenn dir das Projekt hilft: Spendenlinks sind im Blog. Quellen und redaktionelle Einordnung Meredith Ringel Morris et al., Levels of AGI: Operationalizing Progress on the Path to AGI, arXiv:2311.02462, 2023. Grundlage für die Trennung nach Leistungsniveau und Breite. https://arxiv.org/abs/2311.02462 METR, Measuring AI Ability to Complete Long Tasks, 19. März 2025. Forschung zum zeitlichen Aufgabenhorizont; nicht als allgemeiner AGI-Beweis verwendet. https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/ NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0), 2023. Rahmen für Govern, Map, Measure und Manage. https://www.nist.gov/itl/ai-risk-management-framework Europäische Kommission, AI Act / Regulatory framework for AI. Überblick zum risikobasierten Regulierungsansatz und zur schrittweisen Anwendung. https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai Internationale Arbeitsorganisation, Generative AI and Jobs: A Refined Global Index of Occupational Exposure, 20. Mai 2025. Grundlage für die Unterscheidung zwischen Transformation und vollständiger Ersetzung. https://www.ilo.org/publications/generative-ai-and-jobs-refined-global-index-occupational-exposure Interne Arbeitsquelle: Bereinigtes Transkript mit Oliver Bendel. Aussagen zu Physical AI, Körperformen, Haushaltsrobotern, Haftung, Bewusstsein und Bildung wurden als Positionen aus dem Gespräch behandelt, nicht als unabhängig belegte Tatsachen. /home/podbot/.openclaw/workspace/02_In_Arbeit/2026-03-15-transkript-bendel-bereinigt.md Interne Gegenpool-Analyse: AGI ist da: Warum spricht niemand drüber? Enthält zugespitzte Thesen und Benchmark-Angaben; diese wurden nicht ungeprüft übernommen. /home/podbot/.openclaw/workspace/01_Eingang/2026-03-15-analyse-agi-ist-da-folgeanalyse.md Quellenprüfung: Die fünf externen Zielseiten waren am 19. Juli 2026 technisch erreichbar. Das Skript behauptet weder, dass AGI nachweislich erreicht sei, noch dass aktuelle Systeme bewusst seien. Prognosen aus den Ausgangstranskripten wurden als Prognosen kenntlich gemacht oder weggelassen.

Das Fediverse patcht sich nicht selbst

Das Fediverse patcht sich nicht selbst

Shownotes Mastodon empfiehlt Administratoren die Patchstände 4.6.3, 4.5.13 und 4.4.20. Anlass sind Sicherheitskorrekturen, darunter aktualisierte FFmpeg-Versionen in offiziellen Container-Images wegen CVE-2026-8461. Mastodon 4.4 erreicht am 17. Dezember 2026 das Supportende. Diese Folge erklärt: warum eine FFmpeg-Schwachstelle für einen sozialen Server relevant ist; warum Patch und Versionsmigration getrennt geplant werden müssen; welche Bestandteile ein Mastodon-Backup umfasst; warum Restore- und Funktionstests zum Wartungsfenster gehören; welche organisatorischen Fragen neue Funktionen in Mastodon 4.6 auslösen; warum Wartung zur digitalen Souveränität gehört. Nicht geprüft wurden die konkrete Mastodon-Version, Installationsart, FFmpeg-Paketlage oder Backup-Konfiguration von treff.darknight-coffee.eu. Daraus folgt keine Aussage über eine konkrete Verwundbarkeit. Quellen Mastodon Blog, „Trunk & Tidbits, June 2026“, 17. Juli 2026: https://blog.joinmastodon.org/2026/07/trunk-tidbits-june-2026/ Mastodon Releases 4.6.3, 4.6.2, 4.5.13 und 4.4.20: https://github.com/mastodon/mastodon/releases/tag/v4.6.3 https://github.com/mastodon/mastodon/releases/tag/v4.6.2 https://github.com/mastodon/mastodon/releases/tag/v4.5.13 https://github.com/mastodon/mastodon/releases/tag/v4.4.20 Mastodon, Sicherheitsrichtlinie: https://github.com/mastodon/mastodon/blob/main/SECURITY.md Mastodon-Dokumentation, „Upgrading to a new release“: https://docs.joinmastodon.org/admin/upgrading/ Mastodon-Dokumentation, „Backing up your server“: https://docs.joinmastodon.org/admin/backups/ Mastodon Blog, „Mastodon 4.6“: https://blog.joinmastodon.org/2026/06/mastodon-4.6/ FFmpeg Security: https://ffmpeg.org/security.html NIST NVD, CVE-2026-8461, beim Abruf Status „Awaiting Analysis“: https://nvd.nist.gov/vuln/detail/CVE-2026-8461 Transparenz und Prüfstatus Ausgearbeitet mit Crow/Codex auf Grundlage der oben genannten Primär- und Sicherheitsquellen. Tatsachen, technische Bewertung und persönliche Meinung sind im Skript getrennt gekennzeichnet. Redaktionelle Prüfung und Verantwortung liegen vor Veröffentlichung bei Andreas. Prüfstatus: Arbeitsentwurf; keine technische Prüfung der eigenen Instanz; nicht freigegeben. CTA Wie organisiert ihr Patchfenster, Backups und Restore-Tests? Diskussion: https://treff.darknight-coffee.eu/@carrabelloy Podcast: https://podcast.darknight-coffee.org/pages/startseite Blog: https://carrabelloy.darknight-coffee.org/blog/ Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

Fakekonten, DSA und die Macht über die Debatte

Fakekonten, DSA und die Macht über die Debatte

Quellen und Shownotes Sarah B. Rogers, US Under Secretary for Public Diplomacy, Erklärung zum Entwurf, 16. Juli 2026: https://x.com/UnderSecPD/status/2077836530316415168 POLITICO Europe, Bericht zur geplanten Freirede-Erklärung, Juli 2026: https://www.politico.eu/article/trump-administration-will-push-un-free-speech-declaration-that-takes-aim-at-european-tech-regulation/ Europäische Kommission, „The Digital Services Act“: https://digital-strategy.ec.europa.eu/en/policies/digital-services-act Abgeordnetenhaus Berlin, Schriftliche Anfrage S19-21010 zu Fake-Accounts des Verfassungsschutzes, Dezember 2024: https://pardok.parlament-berlin.de/starweb/adis/citat/VT/19/SchrAnfr/S19-21010.pdf AUF1, Bericht über 413 Accounts und 70 Beschäftigte, Juli 2026: https://auf1.tv/eilt/unfassbar-berliner-verfassungsschutz-betreibt-413-fake-accounts-mit-70-mitarbeitern/ Transparenz: Die konkrete aktuelle Berliner Behördenantwort mit den Zahlen 413 und 70 war nicht in einer unabhängig auswertbaren amtlichen Fassung verfügbar. Diese Zahlen werden daher als Medienangabe, nicht als abschließend verifizierte Tatsache wiedergegeben. Die bundesweite Hochrechnung wird nicht übernommen. Diskussion: https://treff.darknight-coffee.eu/@carrabelloy Podcast: https://podcast.darknight-coffee.org/pages/startseite Blog: https://carrabelloy.darknight-coffee.org/blog/ Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

Dein Server steht in Europa – aber wer hält die Schlüssel?

Dein Server steht in Europa – aber wer hält die Schlüssel?

Shownotes Die Europäische Kommission führt vom 8. Juli bis 8. September 2026 eine gezielte Konsultation zur Sicherung der Datensouveränität der EU durch. Diese Folge trennt Datenstandort, Rechtsraum und technische Kontrolle. Sie ordnet die Transparenz- und Schutzpflichten der Artikel 28 und 32 des Data Act ein und erklärt anhand von Matrix, Synapse, Nginx, /.well-known, Tokens und Backups, warum Export- und Restore-Fähigkeit entscheidend sind. Nicht behauptet wird, dass die Konsultation zu einem neuen Gesetz führt oder ein konkreter Darknight-Coffee-Dienst von einem Drittstaatenzugriff betroffen ist. Die eigene Infrastruktur wurde für diese Folge nicht technisch oder juristisch geprüft. Quellen Europäische Kommission, „Targeted consultation on safeguarding the EU’s data sovereignty“, 8. Juli 2026: https://digital-strategy.ec.europa.eu/en/consultations/targeted-consultation-safeguarding-eus-data-sovereignty Europäische Kommission, EUSurvey zur Konsultation: https://ec.europa.eu/eusurvey/runner/a921658b-7f28-11c5-d062-3db457c213fa Europäische Kommission, „European Data Union Strategy“, November 2025: https://digital-strategy.ec.europa.eu/en/policies/data-union EUR-Lex, Verordnung (EU) 2023/2854 – Data Act, insbesondere Artikel 28, 32 und 50: https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng Europäische Kommission, „The EU Open Source Strategy“, Juni 2026: https://digital-strategy.ec.europa.eu/en/policies/open-source-strategy Europäische Kommission, „Strengthening Europe’s Tech Sovereignty“: https://digital-strategy.ec.europa.eu/en/policies/eu-tech-sovereignty Europäische Kommission, COM(2026) 503, „Communication on European Tech Sovereignty, accompanied by an EU Open Source Strategy“: https://digital-strategy.ec.europa.eu/en/library/communication-european-tech-sovereignty-accompanied-eu-open-source-strategy Transparenz und Prüfstatus Ausgearbeitet mit Crow/Codex auf Grundlage der genannten offiziellen Primär- und Rechtsquellen. Tatsachen, redaktionelle Bewertung und offene Punkte sind getrennt gekennzeichnet. Redaktionelle Verantwortung liegt bei Andreas. Prüfstatus: inhaltlich veröffentlichungsreif; keine technische Prüfung der eigenen Infrastruktur; Plattformfreigabe noch erforderlich. CTA Wer hält bei euren Diensten die Schlüssel, und habt ihr den Rückweg wirklich getestet? Diskussion: https://treff.darknight-coffee.eu/@carrabelloy Podcast: https://podcast.darknight-coffee.org/pages/startseite Blog: https://carrabelloy.darknight-coffee.org/blog/ Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

Handy flashen heißt Rückweg planen

Handy flashen heißt Rückweg planen

Shownotes Duranium: vollständige, verifizierte A/B-Systemabbilder, dm-verity, UKI und automatischer Rückfall. Neuer Fallback-Bootloader für geeignete Systeme mit EFI-Variablen laut postmarketOS-Monatsbericht vom 6. Juli 2026. Duranium bleibt ein Entwicklungsprojekt und ist kein allgemeines Stabilitätsversprechen. usb-signaller: robustere USB-Modi und Rollenwechsel; universelle Kabelerkennung weiterhin offen. Unbetreute Ports werden archiviert statt als normal unterstützt angeboten. testing bedeutet bootfähig und baubar, nicht automatisch alltagstauglich. A/B-Rollback ersetzt kein Backup von Nutzerdaten, Schlüsseln und Zugängen. Quellen postmarketOS, „postmarketOS in 2026-06: Plasma 6.7“, 6. Juli 2026: https://postmarketos.org/blog/2026/07/06/pmOS-update-2026-06/ postmarketOS, „Introducing Duranium: a more reliable postmarketOS“, 17. März 2026: https://postmarketos.org/blog/2026/03/17/introducing-duranium/ postmarketOS GitLab, duranium-build/DESIGN.md: https://gitlab.postmarketos.org/postmarketOS/duranium-build/-/blob/main/DESIGN.md postmarketOS-Dokumentation, „Device Categorization“: https://docs.postmarketos.org/pmaports/main/packaging/device-categorization.html postmarketOS, „Unmaintained devices to be archived after v26.06“, 24. März 2026: https://postmarketos.org/devel/2026/03/24/archiving-unmaintained-devices/ postmarketOS, „v26.06: Alpen Avocado“, 21. Juni 2026: https://postmarketos.org/blog/2026/06/21/v26.06-release/ Dylan Van Assche, usb-signaller: https://codeberg.org/DylanVanAssche/usb-signaller postmarketOS-Dokumentation, „Hardware Continuous Integration“: https://docs.postmarketos.org/hardware-ci/index.html Linux Kernel Archives, „Active kernel releases“: https://www.kernel.org/releases.html postmarketOS, „State of postmarketOS“: https://postmarketos.org/state/ CTA Diskussion: https://treff.darknight-coffee.eu/@carrabelloy Podcast: https://podcast.darknight-coffee.org/pages/startseite Blog: https://carrabelloy.darknight-coffee.org/blog/ Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

Linux-Lage 2026: Manjaro-Governance, GRUB2 und digitale Souveränität

Linux-Lage 2026: Manjaro-Governance, GRUB2 und digitale Souveränität

In dieser Folge geht es um die Linux-Lage 2026: den Governance-Konflikt bei Manjaro und den realen Stand von GRUB2 bei verschlüsseltem Boot. Klarer Fokus: Was ist Fakt, was ist Einordnung – und was bedeutet das praktisch für Nutzer, die digitale Souveränität ernst nehmen.

Das trojanische Pferd der Zensur
Ep. 02

Das trojanische Pferd der Zensur

Alles klar. Hier ist die fertige Beschreibung zum direkten Einfügen: In dieser Folge geht es um Altersverifikation, digitale Kontrolle und die Frage, wann „Schutz“ in Überwachung kippt. 🎧 Ein Abend voller Gedanken, Reibung und Klartext: Zwischen Technik, Politik und Alltag schauen wir auf das, was oft als Jugendschutz verkauft wird – aber schnell zur Infrastruktur für Kontrolle werden kann. Wir reden über Verantwortung, Freiheit, Pseudonymität und darüber, warum digitale Souveränität kein Hobby ist, sondern demokratische Infrastruktur. 📝 Grundlage / Artikel: https://carrabelloy.darknight-coffee.org/blog/2026/03/08/das-trojanische-pferd-der-altersverifikation/ 💬 Diskussion: https://treff.darknight-coffee.eu Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

Carrabelloy Kurzpodcast — Heute: KI‑Hardware, Multilingual Dubbing, Codex Security, AI fürs Investieren

Carrabelloy Kurzpodcast — Heute: KI‑Hardware, Multilingual Dubbing, Codex Security, AI fürs Investieren

[Carrabelloy Blog] OpenAIs neues Gerät: Die zweite KI‑Hardware‑Welle – und wer morgen dein Hauptgerät kontrolliert (https://carrabelloy.darknight-coffee.org/blog/2026/03/02/1024947/) [OpenAI News] How Descript enables multilingual video dubbing at scale (https://openai.com/index/descript) [OpenAI News] Codex Security: now in research preview (https://openai.com/index/codex-security-now-in-research-preview) [OpenAI News] How Balyasny Asset Management built an AI research engine for investing (https://openai.com/index/balyasny-asset-management)