INSPIRANT BLOG

Das Ende der Blitzer-Attrappe

2026-07-25T18:27:17+02:00

In 2016 habe ich, zusammen mit meinem Cousin, eine Blitzer-Attrappe an unserer Straße gebaut. Letztes Wochenende, nach fast genau 10 Jahren, habe ich Sie wieder abgebaut.

Gleich vorne weg: Nein, ich musste sie nicht abbauen! Es geschah völlig freiwillig und auf eigene Entscheidung.

Nachdem in 2025 eine größere Welle an Verdächtigungen und Spekulationen durch die deutsche Presse geisterten, wurde ich tatsächlich, 9 Jahre nach Aufstellung der Attrappe, wegen Amtsanmaßung angezeigt. Nachdem ich nachweisen konnte, dass ich die Attrappe vor der Aufstellung schriftlich durch die Polizei, die Bußgeldstelle und das Regierungspräsidium (Verkehrsamt) genehmigen lies, wurde die Anklage zurückgenommen und fallen gelassen. Deshalb blieb der Blitzer auch an Ort uns Stelle stehen.

Weiter lesen? Klicke die Headline um den ganzen Artikel zu sehen!

Jetzt ist es aber so, dass die Attrappe inzwischen sehr gelitten hat. 10 Jahre am Straßenrand, Sommer und Winter, Salz und brutalen Attacken ausgesetzt, hat sie jetzt deutliche Abnutzungserscheinungen. Ich muss also entweder renovieren oder abbauen. Die Entscheidung viel uns nicht leicht, denn neben einer verkehrsberuhigenden Wirkung hat die Blitzer-Attrappe auch handfeste Nachteile. Ich habe darüber im Oktober 2022 einen Blog-Artikel verfasst.

Für uns wurden inzwischen drei Punkte zum Problem:

Die Huperei rund um die Uhr. Ständig fährt irgendeiner nur 25Km/h und ein anderer hintendran hupt dann (zu Recht, weil 50Km/h erlaubt). Oder es wird mit lautem aufheulen des Motors überholt und der überholte hupt weil er das so schlimm findet...
Immer mehr Vollidioten finden es spannend, wegen der Attrappe extra schnell und laut zu fahren.
Sobald vor allem Motorräder und Sportwagen den Blitzer passiert haben, geben sie erst recht Gas (Bergauf).

Da der Hauptgrund für die Blitzer-Attrappe der Verkehrs-Lärm war, hat sich der Nutzen ganz langsam in einen Nachteil verwandelt.

Daher letztlich die Entscheidung, nicht mehr zu renovieren sondern abzubauen.

Es war spannend! Braucht jemand die Teile und will das haben? Mit Schwingschleifer und neuer Farbe ist der Blitzer mit wenig Aufwand wieder einsatzbereit. Ich würde es gerne verschenken, aber nur an Selbstabholer!

Wichtig: Traktor mit Frontlader oder Minibagger sind extrem Hilfreich. Ohne solches Werkzeug lässt sich der Sockel vermutlich kaum stellen.

Unabhängigkeit von US-IT-Produkten ist eine Unmöglichkeit

2026-05-11T21:25:05+02:00

So sehr ich diesen Wunsch auch verstehe und auch selbst teile, eine Unabhängigkeit von US-IT-Produkten ist illusorisch. Wir können ein halbes Jahrhundert mit systematischem Aufbau von Abhängigkeiten nicht mal eben schnell korrigieren. Ich finde es ebenfalls gut und auch wichtig, eine Souveränität herzustellen, aber der Weg ist viel weiter, als uns Politiker, Datenschützer, Blogger und Influencer weißmachen möchten. Wie komme ich zu so einer Einschätzung?

Weiter lesen? Klicke die Headline um den ganzen Artikel zu sehen!

Infrastruktur und Internet

Die Hardware, mit der europäische Netzwerke heute betrieben werden, stammt vor allem von Cisco, Juniper Networks, Ciena oder Nokia (US-Tochter). Es sind sicher noch weitere US-Anbeiter beteiligt. Ohne deren Hardware und Software würde hier gar nichts funktionieren.

Der DNS-Service (Domain Name Service) ist heute unter voller US-Kontrolle. Die ICANN (Internet Corporation for Assigned Names and Numbers) koordiniert die globale Verwaltung der DNS-Root-Zone (die oberste Ebene des DNS) und die Vergabe von Top-Level-Domains (TLDs) wie .com, .org, .de etc. Die ICANN verwaltet auch das Root-Zone-File (die Liste aller TLDs und ihrer zugehörigen Nameserver) und entscheidet über Änderungen oder neue TLDs. Sie untersteht einem Vertrag mit der US-Regierung (über das NTIA, National Telecommunications and Information Administration). Formal hat die US-Regierung aber weiterhin Aufsicht über ICANN (z. B. durch den "IANA-Funktionsvertrag").

Die (Internet Assigned Numbers Authority) IANA ist eine Abteilung von ICANN und verwaltet die technischen Parameter des DNS, wie die Zuweisung von IP-Adressblöcken und die Pflege der Root-Zone. Der aktuelle Stand der Root-Zone wird von IANA gepflegt und an die 13 Root-Nameserver weltweit verteilt. Sie untersteht ebenfalls der US-Regierung und der US-Rechtssprechung.

Von den 13 logischen Root-Nameservern (A bis M) werden 10 direkt von US-amerikanischen Organisationen kontrolliert. Nur RIPE NCC (Niederlande) und das WIDE Project (Japan) sind nicht in US-Kontrolle. ABER: Selbst wenn ein Root-Server außerhalb der USA steht (z. B. K in Amsterdam oder M in Tokyo), folgen alle Root-Server den offiziellen Daten der IANA/Verisign-Root-Zone. Eine Abweichung wäre ein Bruch des DNS-Standards und würde zu globalen Konnektivitätsproblemen führen.

In der Praxis liegt die Kontrolle über die eingesetzte Hardware, die DNS-Infrastruktur, die IP-Adressenvergabe und die Root-Zone damit fast vollständig in US-amerikanischer Hand. Sich hier zu lösen, ist ein unglaublich weiter Weg, über den kaum gesprochen wird.

SSL-Zertifikate und sicheres Internet

Die meisten Webseiten sind heute mit SSL/TLS geschützt (https://). Dafür müssen vom Betreiber der Seite SSL-Zertifikate genutzt werden. Diese werden heute entweder gekauft (diese Nutzung nimmt stark ab) oder man nutzt den kostenlosen Dienst von LetsEncrypt. Die Abdeckung durch LetsEncrypt übersteigt inzwischen die Marke von 80% der Webseiten (Quelle). Let’s Encrypt wird von der ISRG (Internet Security Research Group) betrieben, einer US-amerikanischen Non-Profit-Organisation mit Sitz in Kalifornien. Die ISRG unterliegt US-Recht (z. B. kalifornischem Gesellschaftsrecht und Bundesgesetzen wie dem CLOUD Act). Damit haben wir nicht nur eine massive Dominanz von LetsEncrypt. Die Wahrscheinlichkeit, dass diese Verschlüsselung auf Anordnung der US-Regierung ausgesetzt wird oder umgangen wird, ist vorhanden. Wenn LetsEncrypt morgen die Erneuerung von SSL-Zertifikaten an EU-Webseiten verweigert, ist in wenigen Wochen keine Webseite aus der EU mehr im Internet erreichbar.

Alternativen wären zum Beispiel Actalis aus Italien oder Buypass aus Norwegen. Aber diese sind bisher kaum in Erscheinung getreten und führen eher ein Nischendasein. Weiterhin wurde Buypass erst vor kurzem durch ein kanadisches Unternehmen gekauft (Quelle). Die Zusammenhänge sind undurchsichtig.

Handys und mobile Nutzung

Für Apple-Geräte stehen aktuell keine nennenswerten Alternativen zur Verfügung. Mit GrapheneOS, e/OS, LineageOS und anderen gibt es zumindest alternative Android-Forks. Meist aber eingeschränkt auf wenige unterstützte Geräte. So unterstützt das am weitesten verbreitete Alternativ-Betriebssystem GrapheneOS aktuell nur amerikanische Google-Pixel-Geräte. Und die Nutzer von diesen Betriebssystemen sind meist deutlich eintgeschränkt: Apps der Hausbank funktionieren möglicherweise nicht, die Funktion für kontaktloses Bezahlen geht in den wenigsten Fällen und auch an anderen Stellen lauern Probleme.

Fakt ist, dass es nur sehr wenige europäische Anbieter für Mobilgeräte gibt. Angeblich bauen Gigaset (Deutschland), HMD Global (Finnland) und Punkt. (Schweiz) Mobilgeräte, aber mit Komponenten aus Japan, China und den USA. Ein rein europäisches Produkt gibt es nicht. Fairphone entwickelt zwar in der EU (Niederlande), aber die Geräte werden in China gebaut. Ebenfalls mit Komponenten aus Japan, China und den USA.

Bei der Nutzung von mobilem Internet gibt es also an den USA und anderen Ländern wie China, Japan und Südkorea keinen Weg vorbei. Das lässt sich auch so schnell nicht ändern. Das Know-how ist in Europa meist nicht mehr vorhanden oder es fehlt das Investitionsgeld, um in Europa zu produzieren.

Software für Softwareentwickler

Softwareentwickler erstellen die Apps und Programme für die Geräte, die wir nutzen. Jede Handy-App ist durch einen Entwickler programmiert. Und dafür nutzt er Werkzeuge. So stellt Google für die Erstellung von Android-Apps beispielsweise die Werkzeuge "Android Studio" und die Programmiersprache "Kotlin" zur Verfügung. Auch die Apps, die am Ende auf GrapheneOS oder /e/OS laufen sollen, werden durch diese Werkzeuge erzeugt. Und diese Werkzeuge sind zu einem großen Teil unter voller US-Kontrolle. Sogar die Auslieferung von Android Studio an EU-Nutzer könnte die US-Regierung auf Grundlage der Export Administration Regulations (EAR) unterbinden. Das selbe gilt für den Zugriff auf Entwickler-Bibliotheken auf GitHub (ein Microsoft-Unternehmen, auf dem ein Großteil des benötigten Quellcodes gehostet wird). Von den nötigen Treibern für die Hardware mal abgesehen, die häufig gar nicht als Quellcode zur Verfügung steht.

In Kurz: Ohne Software-Tools und Bibliotheken aus den USA ist kein europäischer Entwickler in der Lage, neue Software für ein eventuelles europäisches Handy zu programmieren oder bestehende Software zu aktualisieren.

Software für Unternehmen und Endnutzer

Windows ist ein zu 100% amerikanisches Produkt. Es untersteht ebenfalls dem Willen der US-Regierung. Wenn diese eine Order an Microsoft gibt, nicht mehr an EU-Unternehmen zu liefern oder Updates zu verteilen, dann haben wir alle ein Problem. Und ja, mit Linux steht ein alternatives Betriebssystem zur Verfügung. Als langjähriger Nutzer von Linux bin ich inzwischen überzeugt, dass Windows ersetzbar ist. Auch für Office und Teams stehen passende Alternativen zur Verfügung. Hier ist ein gewisser Grad an Unabhängigkeit durchaus machbar (hurra!).

Das Problem ist aber mehr die verfügbare Software. Die in den meisten Unternehmen eingesetzte Software für CAD, Warenwirtschaft, Steuer und Buchhaltung etc. ist zumeist nur für Windows erhältlich. Was nützt mir der tolle Linux-Arbeitsplatz, wenn es die nötige Software nicht für Linux gibt? Man liest immer wieder von möglichen Alternativen. Ja, die gibt es manchmal. Aber nicht immer mit dem benötigten Funktionsumfang, der nötigen Anbindung und Kompatibilität oder schlicht nicht der nötigen Professionalität.

Und dann kommen noch Lieschen Müller und Hans Schmidt. Wir haben einen unglaublich hohen Anteil Nutzer die zu keiner Änderung mehr bereit sind. Ein Umlernen von Outlook auf Thunderbird oder Microsoft Word auf LibreOffice Writer sind teilweise unüberwindbare Hürden. Egal wie gut und toll die neue Software ist. Es fehlt in ganz vielen Fällen auch schlicht der Wille. Dagegen kommt man nur ganz schwer an...

Tatsächlich sind wir heute zu einem großen Teil von US-Software abhängig. Ein Wechsel von Windows und Office zu Alternativen ist eine gute Sache. Aber so lange die Hersteller von Standard-Software nicht mitziehen, sehe ich da nur wenig kurzfristigen Erfolg. Der Druck muss durch die Kunden (Nutzer) entstehen. Erst dann wird sich etwas verändern. Vielleicht hilft es tatsächlich, wenn Regierungen wie in Frankreich die Abkehr von Microsoft als offiziellen Weg propagieren. Ich hoffe es sehr!

Fazit

Eine kurzfristige Abkehr von den USA in der IT ist eine Unmöglichkeit. Selbst mittel- und langfristig ist es sehr unwahrscheinlich, dass wir eine Souveränität schaffen, die man so nennen kann. Der oft zitierte Wechsel von Office oder Windows ist nur ein kleiner Schritt. Die echten Risiken liegen tatsächlich in den anderen oben genannten Punkten. Ständig wird das übersehen und wegignoriert.

Eine Gigafactory für das KI-Training oder ein dezenter Wechsel zu Linux auf ein paar Servern bringt uns dem Ziel nicht wirklich näher. Es fehlt der EU-weite Masterplan, der alle Punkte deutlich nennt und klare Ziele vorgibt. Was wollen wir durch EU-Technologie ersetzen? Bis zu welchem Grad (Lieferkette)? Bis wann und welche Schritte sind dafür nötig? Und dann müssen sich am Ende alle darüber einig sein und das beschliessen. Wie wahrscheinlich das ist, darüber werde ich mich hier nicht auslassen.

Mein erstes Vibe-Coding-Projekt und was ich daraus gelernt habe

2026-02-25T20:10:45+01:00

Schon seit mehreren Jahren nutzen wir auf der Arbeit KI-Tools. Aber meist für kleine oder spezifische Aufgaben. Also eine spezielle Funktion erstellen lassen, ein kurzes Bash-Script oder auch zu Recherche-Zwecken. Meist war es aber frustrierend, denn die KI hat sich ständig Funktionen ausgedacht, die es gar nicht gab (Halluzinationen) und nicht selten wurden wir durch die KI auch auf die falsche Spur geschickt. Erkennbar war aber auch, dass die Qualität von Code besser wird, je mehr Code es davon im Internet gibt. Bei der Hilfe zu einem WebExtension Add-On für Thunderbird, hat die KI extrem viel Halluziniert und war kaum zu gebrauchen. Es hat eher Zeit gekostet. Wenn man aber C, C++, JAVA oder go Code generieren lässt, ist es deutlich besser.

Dennoch ist es eine interessante und faszinierende Technologie. Aus passendem Anlass heraus, weil die Projekte klein und die Sprache go sein sollte, habe ich soeben mein erstes kleines Software-Projekt vollkommen mit KI-Unterstützung erstellt. Ich habe dabei viel über die Arbeit mit der KI gelernt und auch einen noch tieferen Einblick in die Materie erhalten.

Hier die Randbedingungen:

Ich nutze Visual Studio Code mit dem Blackbox AI Coding-Assistenten.
Das Projekt wurde in go (oder auch golang) geschrieben.
Es verwendet die Cassandra-Datenbank.
Es ist im Prinzip ein einfacher REST API Endpunkt, der im Netz verfügbar sein soll und dessen Verbindungen durch LetsEncrypt gesichert sein sollen (https).
Ich kenne go bereits und habe bereits damit programmiert.

Weiter lesen? Klicke die Headline um den ganzen Artikel zu sehen!

Der initiale Prompt

Die Ausarbeitung des initialen Prompts war durchaus anspruchsvoll. Ich musste mir ja klar darüber werden, was ich haben möchte, welche Technologievorgaben ich mache und in welcher Sprache, an welchem Ort das Projekt abgelegt werden soll, ob und welche Konfig-Dateien verwendet werden sollen etc. Als besonders schwierig empfand ich, das so schreiben zu müssen als wenn ein Anfänger vor mir sitzt. Ich darf von kaum einer Sache erwarten, dass sie bereits bekannt ist. Also muss man sich gut sortieren und auch kleine Gedanken zum Aufbau oder der Struktur erfassen.

Mir fiel währenddessen sofort auf, dass ich diesen Prompt nur so schreiben konnte, weil ich bereits Ahnung von Softwareentwicklung habe und durch geschickte Vorgaben bereits viele Anfängerfehler vermeiden konnte.

Ich habe klare Vorgaben gemacht: Zur Struktur der API, der Konfig-Dateien und deren Werte, zur Verschlüsselung und dem Encoding, zu Prüfungen und Rückgabecodes und auch zu den Frameworks die in go verwendet werden sollen (zB echo als web framework und router). Ohne Erfahrung in diesem Gebiet wäre der erste Schuss deutlich wahrscheinlicher nach hinten los gegangen…

Nacharbeit

Nachdem der Prompt abgegeben wurde, hat die KI in wenigen Minuten das Projekt erstellt und auch gleich getestet. Aber einiges hat mir nicht gefallen und ich habe durch viele Prompts Dinge am Code korrigiert (Auszug):

Es wurden viele Parameter einzeln an Funktionen übergeben, statt einfach die Konfigurations-Struktur zu übergeben.
Verschlüsselungs-Keys wurden unnötig komplex und verbose gespeichert.
Die Software hatte keinen sauberen Shutdown und damit beim Beenden der Software (SIGKILL oder Ctrl+d) die Datenbank potentiell beschädigt oder Verbindungen verwaisen lassen.
Entscheidungen zur API und den Rückmeldungen nahmen keine Rücksicht auf die anderen Komponenten, die später darauf zugreifen sollen.
Funktionen waren teilweise sehr Lang und Umfangreich, statt diese in leichter zu wartende Teilfunktionen zu unterteilen.
Es wurde keinerlei Debugging-Log Funktion eingebaut. Die Suche nach Problemen ohne Debugging-Logs würde sich unnötig schwierig erweisen und sehr lange dauern.
Ständig hat mir die KI neue Abhängigkeiten erzeugt. Mal eben ein anderes Framework für Logs, ein Framework für Stringverarbeitung etc. Ich musste das über mehrere Chats aus dem Projekt entfernen um ein möglichst wartbares Projekt zu erhalten.

Fazit

Die benötigte Entwicklungs-Zeit bis zum lauffähigen Produkt war unschlagbar kurz. In nur wenigen Stunden wurde das Projekt lauffähig erzeugt und auch dokumentiert. Das wäre mir, durch traditionelles Programmieren, völlig unmöglich gewesen. Keine Chance. Das kann also durchaus eine echte Hilfe im Alltag von Programmierern sein. Vor allem Routineaufgaben wie Validierung von API- und Nutzer-Eingaben oder die Errichtung eines Grundgerüstes und der Datenbank-Verbindung hat mir sehr gut gefallen und wirkliche Erleichterung gebracht.

Aber auch die Schattenseiten sind deutlich: Nur weil ich bereits programmieren kann und auch Erfahrung mit solchen Projekten habe, konnte ein brauchbares Konstrukt entstehen. Ohne mein Eingreifen und die bereits im Prompt, und dann später im Chat, erfolgten Korrekturen und Detailanweisungen, wäre es definitiv kein produktionsfähiges Softwareprodukt geworden. Also, es hätte schon irgendwie funktioniert, aber im Nachgang im Setup, im Betrieb, in der Weiterentwicklung und in der Wartung viele Probleme verursacht. Diese hätten die Zeitersparnis dann sicher zunichtegemacht und über lange Zeit für Probleme gesorgt.

Wir müssen in der nahen Zukunft wohl mit viel Software rechnen, die "irgendwie funktioniert".
Aber eben nicht gut, sicher oder performant arbeitet.

Es braucht also einen Senior-Entwickler, der Erfahrung hat und die Programmiersprache und die Tücken kennt. Aber woher lernt man das, wenn man nur Vibe-Coding macht? Ein Entwickler, der von Anfang an nur Vibe-Coding macht, wird diese Fertigkeiten und Erfahrung niemals aufbauen. Das bedeutet, wir bilden aus finanziellen Gründen, aber auch Bequemlichkeit, vermutlich bald keine Programmierer mehr aus. Solange es noch Senior-Programmierer gibt, welche die KI sinnvoll bedienen können, ist das eine nachvollziehbare Sache. Aber was ist in 10 bis 20 Jahren? Wenn die Entwickler mit Erfahrung in Rente gehen oder wegfallen? Hoffen wir mal, dass bis dahin diese Probleme keine Probleme mehr sind und die KI auch die Nebenschauplätze abdecken kann. Also den Kundenwunsch verstehen, in eine klare Definition und Anforderungs-Spezifikation umwandeln und dann auch Entwickeln und in Betrieb nehmen.

Auf Dauer wird demnach der Job des Entwicklers oder Programmierers wegfallen. Bisher habe ich das bezweifelt, aber mit der Zeit wird das wohl so kommen.

Für junge Leute mit Interesse am Programmieren gibt es, meines Erachtens, nur zwei mögliche Entscheidungen:

1) Lerne das Programmieren mit konsequentem Verzicht auf KI, um ein guter Programmierer zu werden. Das geht nur so! Dann, später, kann man die größeren Software-Projekte verstehen und mit KI-Einsatz gutes ermöglichen. Das wird auch in Zukunft ein guter Job sein, und auch gefragt sein.

oder

2) Verzichte auf eine Karriere als Programmierer und mach das allenfalls zu deinem Hobby für private Projekte. Nutze KI und akzeptiere, dass du es möglicherweise nicht richten kannst, wenn die KI versagt.

Externe Software-Quellen machen dein Linux unsicher

2026-02-16T21:36:16+01:00

Ich nutze Linux schon seit vielen Jahren. Zuerst Kubuntu, Lubuntu. Dann später KDE Neon. Und seit ich bei OpenSUSE LEAP gelandet bin, habe ich die für mich ideale Distribution gefunden. Aber obwohl ich jetzt seit Jahren Linux nutze, ist mir erst jetzt bewusst gewesen, dass mein Linux-System von zB Microsoft jederzeit übernommen oder gekillt werden kann. Warum? Weil ich für dauernde Teams-Meeting-Einladungen gezwungen war, Microsoft Edge in der Linux-Version zu nutzen. Auch nutze ich gerne Visual Studio Code für die Entwicklung. Und beide Tools habe ich über die offiziellen Linux-Repositories von Microsoft in mein System eingebunden. Warum ich das so tat? Weil ich so immer die neuesten Updates bekomme.

Ich war der Meinung, dass mich mein Linux auf angemessene Weise vor Missbrauch durch externe Repository-Maintainer schützt. Das ist aber nicht so!

Weiter lesen? Klicke die Headline um den ganzen Artikel zu sehen!

Hinweis: Ich habe mir beim formulieren dieses Artikels von Le Chat helfen lassen. Die Erkenntnisse und der gesamte Text wurden aber von mir überarbeitet und geprüft.

Das Problem

Linux gilt als sicher – doch diese Sicherheit hat einen blinden Fleck: externe Repositories. Sobald du ein Repository eines Drittanbieters (z. B. für Microsoft Edge, Visual Studio Code, NVIDIA-Treiber oder Codecs) einbindest, gibst du de facto Administratorrechte an den Repository-Maintainer ab. Warum? Weil dieser beim nächsten Update folgende Dinge tun könnte:

Systemkomponenten überschreiben
Ein Repository kann beliebige Pakete anbieten – auch solche, die Systembibliotheken oder Kernel-Module ersetzen.

Beispiel:
Ein bösartiges Repository könnte eine manipulierte Version von glibc, openssl oder sogar dem Kernel anbieten.

Folge:
Dein System wird kompromittiert, sobald du zypper up oder apt upgrade ausführst.

Du fragst wie? Der Maintainer veröffentlicht ein Update für ein scheinbar harmloses Paket (z. B. codecs), das Abhängigkeiten zu Systempaketen hat. Dein apt upgrade (oder zypper up in OpenSUSE) schlägt vor, diese Abhängigkeiten zu installieren. Du sagst wie immer "ja" – und schon ist dein System infiziert.
Automatische Updates als Einfallstor
Viele Nutzer aktivieren automatische Updates – was praktisch ist, aber gefährlich, wenn externe Repositories eingebunden sind.

Szenario:
1. Du bindest ein Repository für eine tolle externe Software ein.
2. Der Repository-Maintainer oder ein Angreifer, der das Repository kompromittiert, veröffentlicht ein bösartiges Update für libc6.
3. Dein System installiert es automatisch, ohne dass du es merkst.
Social Engineering: Vertrauensmissbrauch
Repository-Maintainer können Pakete mit vertrauenswürdigen Namen anbieten (zB "openssl-security-patch"), die in Wahrheit Backdoors, Trojaner, Viren oder Spyware enthalten.

Beispiel:
Ein Repository bietet ein Paket namens "nvidia-driver-fix" an, das tatsächlich einen Rootkit installiert.
Da der Name seriös klingt, installieren Nutzer es ohne Misstrauen.

Warum ist das ein strukturelles Problem?

Linux vertraut dem Nutzer. Paketmanager wie zypper, apt oder dnf gehen davon aus, dass der Nutzer weiß, was er tut. In der Realität wählen die meisten Nutzer aber einfach "Installieren", ohne die Quelle zu prüfen. Geschweige denn, dass jemand wüsste wie man eine Quelle prüft…

Es gibt auch keine Standard-Warnungen. Auch wenn diese in der Wirkung zweifelhaft sind; im Gegensatz zu Windows un MacOS warnt Linux nicht aktiv vor den Risiken externer Repositories.

Auch erzwingen manche Hersteller externe Repositories, wenn man immer aktuell sein möchte. Viele Programme (zB Microsoft Edge, NVIDIA-Treiber, Steam, Visual Studio Code) sind nur über externe Repositories verfügbar – Nutzer müssen sie einbinden oder mit Nachteilen leben (siehe später weiter unten).

"Linux ist nur so sicher wie die Repositories, denen du vertraust.
Sobald du ein externes Repository einbindest, öffnest du die Tür
für potenzielle Angriffe durch diesen Anbieter – und
die meisten Nutzer wissen das nicht."

Lösungsansätze

Es gibt mehrere Wege, das Problem zu entschärfen – aber keine perfekte Lösung. Hier sind die wichtigsten Ansätze mit ihren Vor- und Nachteilen:

Flatpak: Sandboxing für Anwendungen

Wie es funktioniert:

Anwendungen laufen in einer isolierten Umgebung (Sandbox) und haben keinen Zugriff auf das System (außer auf explizit von Dir freigegebene Bereiche). Pakete kommen aus zentralen Stores (z. B. Flathub), die Signaturen und Reviews erzwingen.

Vorteile:

Hohe Sicherheit (keine Systemänderungen).
Automatische Updates (über den Store).
Keine externen Repositories nötig.

Nachteile:

Nicht alle Programme verfügbar (zB VS Code, Edge nur als Community-Versionen).
Langsamer Start (durch Sandboxing).
Ressourcenintensiv (jede App läuft in einem Container).

Für wen?

Nutzer, die Sicherheit über Komfort stellen und auf offizielle Flatpaks setzen können. Aber Du musst darauf verztrauen, dass der Abbieter des Flatpaks dir nichts böses möchte und dass Du auch regelmässig wichtige Sicherheits-Updates bekommst. bei Community-Versionen sind zumindest Updates nicht selten nie oder nur sehr spät verfügbar.

AppImage: Portable Anwendungen ohne Installation

Wie es funktioniert:

Anwendungen werden als einzelne ausführbare Datei heruntergeladen und ohne Installation gestartet. Keine Repository-Einbindung nötig.

Vorteile:

Keine Systemänderungen (läuft im User-Space).
Keine Abhängigkeiten oder Repos nötig.
Einfach zu nutzen (herunterladen, ausführbar machen, starten).

Nachteile:

Keine automatischen Updates (Nutzer muss manuell neue Versionen herunterladen).
Keine Sandbox (AppImages können beliebigen Code ausführen).
Nicht alle Programme verfügbar (z. B. Treiber, Systemtools).

Für wen?

Nutzer, die keine Repositories einbinden wollen und manuelle Updates in Kauf nehmen.

Manuelle Installation von .rpm/.deb-Paketen

Wie es funktioniert:

Statt ein Repository einzubinden, lädst du die offiziellen Pakete (zB .rpm von Microsoft) manuell herunter und installierst sie. Zum Beispiel so:

sudo dpkg -i /pfad/zur/datei.deb # Debian/Ubuntu
sudo zypper in /pfad/zur/datei.rpm # openSUSE

Vorteile:

Keine externen Repositories nötig.
Offizielle Quelle → vertrauenswürdig.
Volle Kontrolle über installierte Pakete.

Nachteile:

Keine automatischen Updates (muss manuell geprüft und gemacht werden).
Umständlich (Nutzer muss selbst auf neue Versionen achten).

Für wen?

Nutzer, die maximale Kontrolle wollen und keine externen Repositories einbinden möchten.

Immutable OS: Unveränderliche Systeme

Wie es funktioniert:

Das gesamte Linux-System ist unveränderlich (Solche Linux-Distributionen sind zB Fedora Silverblue, openSUSE MicroOS). Änderungen werden nur über atomare Updates eingespielt (keine klassischen apt, dnf oder zypper Installations-Befehle). Anwendungen werden als Flatpaks oder Container installiert.

Vorteile:

Maximale Sicherheit (keine externen Repositories nötig).
Atomare Updates (keine "kaputten" Systeme nach Updates).
Isolation (Anwendungen laufen in Containern).

Nachteile:

Radikale Umstellung (kein klassisches Paketmanagement mehr).
Nicht alle Programme verfügbar (z. B. proprietäre Treiber).
Komplex für Einsteiger.

Für wen?

Sicherheitsbewusste Nutzer, die bereit sind, neue Workflows zu lernen.

Distrobox/Toolbx: Containerisierte Distributionen

Wie es funktioniert:

Du erstellst einen Container mit einer vollständigen Distribution (z. B. Ubuntu, Arch) und installierst dort die Software. Die Anwendungen werden im Host-System integriert, laufen aber isoliert im Container.

Vorteile:

Volle Isolation (externe Repositories bleiben im Container).
Keine Änderungen am Host-System.
Volle Kompatibilität (alle Pakete verfügbar).

Nachteile:

Komplex einzurichten (X11-Weiterleitung, Berechtigungen).
Ressourcenintensiv (jeder Container ist eine Mini-Distribution).

Für wen?

Fortgeschrittene Nutzer, die externe Software sicher testen wollen.

SIGStore & Cosign: Signaturprüfung für Pakete

Wie es funktioniert:

SIGStore ermöglicht kryptografische Signaturprüfung für Software-Artefakte (inkl. RPM/DEB-Pakete). Cosign prüft Signaturen vor der Installation.

Vorteile:

Zukunftssicher (wird von der Linux Foundation gepusht).
Automatisierte Signaturprüfung.

Nachteile:

Noch nicht flächendeckend eingesetzt.
Nutzt nichts, wenn Nutzer Signaturen ignorieren.

Für wen?

Zukunftsorientierte Nutzer, die auf neue Sicherheitsstandards setzen wollen.

Die harte Wahrheit ist:
"Es gibt keine perfekte Lösung. Du musst Kompromisse eingehen – entweder
bei der Sicherheit, beim Komfort oder beim Aufwand."

Zusammenfassung: Was kannst du heute tun?

Wenn ein externes Repository für Dich jetzt nicht mehr in Frage kommt, hast Du diese Optionen:

Flatpak/Snap nutzen, wo möglich (z. B. TeamViewer, Spotify).
Offizielle .rpm/.deb-Pakete manuell installieren (z. B. VS Code, Edge).
Externe Repositories strikt beschränken (nur bestimmte Pakete erlauben).
Immutable OS testen (z. B. Fedora Silverblue), falls du experimentierfreudig bist.
Distrobox für unsichere Software nutzen (z. B. AnyDesk in einem Container).

Die bittere Wahrheit

Linux ist nicht unsicher – aber es erfordert Wissen und Disziplin. Sobald du externe Repositories einbindest, gibst du Sicherheit für Komfort auf. Es gibt aktuell keine Lösung, die beides vereint: Maximale Sicherheit und automatische Updates ohne manuellen Aufwand.

Natürlich gibt es die Vision der optimalen Lösung. Vor allem, wenn Linux jetzt durch mehr Leute genutzt wird, weil Microsoft sich ja größte Mühe gibt den Leuten Windows auszutreiben. Also, was wäre die ideale Lösung?

Vielleicht eine Kombination aus:

Strikten Sandboxing-Standards (wie Flatpak) für alle Anwendungen.
Signaturprüfung per Default (wie SIGStore) für alle Pakete.
Bessere Nutzeraufklärung (Warnungen bei externen Repositories).
Hersteller-Unterstützung für sichere Distribution (z. B. offizielle Flatpaks von Microsoft, NVIDIA etc.).

Bis dahin bleibt es dabei:

Entweder du verzichtest auf automatische Updates (manuelle .rpm-Installation).
Oder du akzeptierst ein Sicherheitsrisiko (externe Repositories).
Oder du gehst den häufig unbequemen Weg (Flatpak, Immutable OS, Container).