Connect with us

Entwicklung & Code

Wie Gödel und Turing die Grenzen von KI vorgezeichnet haben


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

.

Im Studium begegnen einem Namen wie Kurt Gödel und Alan Turing meist mit derselben Mischung aus Respekt und leichter Resignation. Man liest, was sie bewiesen haben, akzeptiert es als beeindruckend und legt das Wissen anschließend in jenes mentale Archiv, das man irgendwo zwischen „interessant“ und „werde ich nie wieder brauchen“ verortet. Dass die Unvollständigkeit der Arithmetik oder die Unentscheidbarkeit des Halteproblems eines Tages mit der Frage zusammenfallen könnten, warum mir ein Chatbot gerade einen Buchtitel halluziniert hat, hätte ich vor einigen Jahren niemandem geglaubt.

Weiterlesen nach der Anzeige

Genau das ist aber passiert. Mehrere wissenschaftliche Arbeiten der letzten drei Jahre zeigen, dass die Halluzinationen von Sprachmodellen kein Implementierungsfehler sind, den man mit mehr Daten oder besserer Architektur wegtrainieren könnte. Sie folgen aus denselben theoretischen Grenzen, an denen einmal das ehrgeizigste Projekt der modernen Mathematik zerbrochen ist. Wer diese Verbindung einmal gesehen hat, liest die aktuelle Debatte um die Zukunft der KI mit deutlich nüchternerem Blick.


the next big thing – Golo Roden

the next big thing – Golo Roden

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Das Versprechen von 1928

Um zu verstehen, warum die Forschungslandschaft der KI heute so ist, wie sie ist, lohnt sich ein Umweg über den Internationalen Mathematikerkongress in Bologna im Jahr 1928. Dort formulierte David Hilbert, einer der einflussreichsten Mathematiker seiner Zeit, gemeinsam mit Wilhelm Ackermann ein Forschungsprogramm, das die gesamte Mathematik auf eine vollkommen neue Grundlage stellen sollte. Drei Eigenschaften sollten dieses Fundament tragen:

  1. Konsistenz, also die Gewissheit, dass aus den Axiomen keine widersprüchlichen Aussagen abgeleitet werden können.
  2. Vollständigkeit, also die Garantie, dass jede wahre Aussage innerhalb des Systems auch bewiesen werden kann.
  3. Und Entscheidbarkeit, also die Existenz eines Verfahrens, mit dem sich für jede beliebige Aussage in endlich vielen Schritten entscheiden lässt, ob sie aus den Axiomen folgt.

Die dritte Forderung ist als Entscheidungsproblem in die Geschichte eingegangen. Hinter ihr stand eine konkrete Vision. Mathematik sollte mechanisierbar werden. Eine Maschine, die endlich viele Regeln auf endlich vielen Zeichen anwendet, müsste jede mathematische Frage prinzipiell beantworten können. Wer in dieser Vision den Schatten dessen erkennt, was wir heute Computer nennen, liegt nicht falsch. Hilbert dachte den Computer mit, lange bevor es ihn gab.

Sein Optimismus war ungebrochen. Im September 1930 hielt er in Königsberg eine berühmt gewordene Radioansprache, die er mit dem Satz beendete: „Wir müssen wissen, wir werden wissen.“ Es war die letzte große Verkündigung einer Mathematik, die sich selbst noch alles zutraute. Wenige Tage zuvor hatte am selben Ort, auf einer parallel laufenden erkenntnistheoretischen Tagung, ein junger Mann namens Kurt Gödel in einer beiläufigen Bemerkung erstmals jene Ergebnisse skizziert, die Hilberts Programm in den Grundfesten erschüttern sollten. Dass die beiden Ereignisse so dicht beieinander lagen, ist eine historische Pointe, der man nicht zu viel symbolisches Gewicht aufladen sollte. Aber interessant ist sie allemal.

Weiterlesen nach der Anzeige

Gödel ohne Formeln

Was Gödel 1930 vorgestellt und 1931 ausführlich publiziert hat, lässt sich erstaunlich gut ohne mathematische Notation erklären. Sein Trick beruht auf einem Verfahren, das jeder verständlich findet, der einmal eine sich selbst aufrufende Funktion gesehen hat: Selbstreferenz. Stellen Sie sich ein hinreichend mächtiges formales System vor, in dem sich arithmetische Aussagen formulieren lassen. Gödel hat gezeigt, wie sich innerhalb eines solchen Systems eine Aussage konstruieren lässt, die in etwa besagt: „Diese Aussage ist im vorliegenden System nicht beweisbar.“

An diesem Punkt sollte man kurz innehalten, weil die Konsequenz unausweichlich ist. Ist die Aussage wahr, dann gibt es eine wahre arithmetische Aussage, die das System nicht beweisen kann. Damit ist das System unvollständig. Ist die Aussage falsch, dann beweist das System eine Aussage, die behauptet, nicht beweisbar zu sein, obwohl sie es offenbar doch ist. Damit ist das System inkonsistent. Es gibt keinen dritten Weg.

Wer den Lügner aus der antiken Philosophie kennt, der sich selbst der Lüge bezichtigt, erkennt das Muster wieder. Was Gödel jedoch geleistet hat, war keine philosophische Spielerei, sondern ein streng formaler Beweis innerhalb der Arithmetik selbst. Er zeigte, dass die Selbstreferenz nicht auf gemeinsprachliche Aussagen beschränkt bleibt, sondern in jedem hinreichend ausdrucksstarken formalen System auftaucht.

Gödel hat damit nicht gezeigt, dass die Mathematik kaputt ist. Er hat gezeigt, dass es prinzipielle Grenzen gibt, an denen jede ausreichend mächtige Theorie auf sich selbst zurückgeworfen wird. Hilberts Vision einer mechanisierbaren, in sich abgeschlossenen Mathematik bekam damit einen Riss, den niemand mehr kitten konnte. Die Konsequenz wurde später so formuliert: Jedes System, das genug Ausdrucksstärke hat, um über sich selbst zu sprechen, hat blinde Flecken, die sich nicht wegoptimieren lassen.

Besonders bemerkenswert an Gödels Ergebnis ist, dass es nicht von einer bestimmten Theorie abhängt. Es gilt für die Arithmetik, für die Mengenlehre, für jede formale Theorie, die ausreichend Ausdrucksstärke besitzt, um die natürlichen Zahlen mitsamt Addition und Multiplikation zu beschreiben. Wer das System tauscht, tauscht nur das Gewand der Grenze, nicht die Grenze selbst. In den Jahrzehnten nach Gödel wurden zahlreiche weitere Sätze bewiesen, die zeigen, dass die Selbstreferenz an erstaunlich (oder erschreckend) vielen Stellen ihren Tribut fordert. Das Halteproblem ist nur das bekannteste Beispiel dafür.

Turing macht Gödel praktisch

Sechs Jahre nach Gödels Beweis erschien in den Proceedings of the London Mathematical Society eine Arbeit, die heute zu den Gründungsdokumenten der Informatik zählt: Alan Turings Aufsatz „On Computable Numbers, with an Application to the Entscheidungsproblem“. Turing hatte sich gefragt, was es eigentlich heißt, dass ein Verfahren mechanisch ausführbar ist. Er entwarf dafür ein gedankliches Konstrukt, das wir heute Turing-Maschine nennen, und nutzte es, um Hilberts dritter Forderung den Garaus zu machen. Im selben Jahr und unabhängig von Turing kam Alonzo Church zu einem entsprechenden Ergebnis auf dem Weg über den Lambda-Kalkül.

Turings Resultat ist als Halteproblem bekannt. Es lässt sich in einem Satz zusammenfassen: Es gibt kein allgemeines Verfahren, das für ein beliebiges Programm und eine beliebige Eingabe entscheiden kann, ob das Programm jemals zum Ende kommt. Diese Aussage klingt zunächst harmlos, ist aber von erheblicher Tragweite. Sie sagt nicht, dass wir bisher kein solches Verfahren gefunden haben. Sie sagt, dass es ein solches Verfahren niemals geben kann.

Wer heute in der Softwareentwicklung arbeitet, lebt mit den Konsequenzen dieses Beweises, ohne sich dessen jeden Tag bewusst zu sein. Statische Codeanalyse stößt bei substanziellen Fragen über das Programmverhalten auf prinzipielle Grenzen. Compiler-Optimierer müssen Heuristiken einsetzen, weil eine vollständige Analyse mancher Codepfade unentscheidbar bleibt. Formale Verifikation funktioniert nur dort wirklich gut, wo man das untersuchte Problem auf entscheidbare Fragmente einschränkt. Wir haben uns daran gewöhnt, mit den Folgen einer mathematischen Grenze umzugehen, ohne sie noch jedes Mal benennen zu müssen.

Verschärft wird die Lage durch ein Ergebnis, das Henry Gordon Rice 1953 bewiesen hat. Sein Satz besagt, dass jede nicht-triviale semantische Eigenschaft eines Programms unentscheidbar ist. Damit ist nicht nur die Frage nach dem Terminieren prinzipiell offen, sondern praktisch jede interessante Frage über das Verhalten von Programmen. Ob ein bestimmter Codepfad jemals durchlaufen wird, ob zwei Programme funktional äquivalent sind, ob ein Programm eine bestimmte Ausgabe niemals produziert: Für all das gibt es kein allgemeines Entscheidungsverfahren. Was dem Berufsalltag in der Softwareentwicklung als zähe Heuristik begegnet, ist im Kern dieselbe Grenze, an die Hilbert 1928 gehofft hatte, nicht zu stoßen.

Mit Turings Arbeit war Hilberts Programm in seiner ursprünglichen Form endgültig erledigt. Konsistenz und Vollständigkeit hatte Gödel zerlegt, die Entscheidbarkeit nahmen Turing und Church mit nach Hause. Das ehrgeizigste mathematische Forschungsprogramm des frühen 20. Jahrhunderts war an seinen eigenen Voraussetzungen gescheitert. Was übrig blieb, war die nüchterne Einsicht, dass auch die Mathematik mit Grenzen leben muss, die sie nicht selbst aufgehoben hat, sondern an denen sie sich vorfindet.

Dieselbe Mauer, neuer Anstrich

Damit kehre ich zu der Frage zurück, die diesen Text ausgelöst hat. Was hat das alles mit Sprachmodellen zu tun?

Im Januar 2024 reichten Ziwei Xu, Sanjay Jain und Mohan Kankanhalli von der National University of Singapore eine Arbeit mit dem Titel „Hallucination is Inevitable: An Innate Limitation of Large Language Models“ ein. Sie formalisieren das Problem in einer formalen Welt, in der Halluzination als Inkonsistenz zwischen einem berechenbaren Sprachmodell und einer berechenbaren Wahrheitsfunktion definiert ist. Ihr zentrales Ergebnis stützt sich auf die Lerntheorie und auf ein Argument, das in seiner Struktur direkt mit den Diagonalisierungsverfahren Cantors und Turings verwandt ist: Sprachmodelle können nicht alle berechenbaren Funktionen lernen. Sobald sie ein breites Spektrum an Problemen lösen sollen, werden sie zwangsläufig halluzinieren. Es gibt keine Trainingsmethode, keine Architekturvariante und keinen Datenumfang, der diese Grenze verschiebt.

Wenige Monate später, im September 2024, legten Sourav Banerjee, Ayushi Agarwal und Saloni Singla mit „LLMs Will Always Hallucinate, and We Need to Live With This“ eine zweite, unabhängige Argumentationslinie vor. Sie gehen direkter zur Sache und stützen sich ausdrücklich auf Gödels ersten Unvollständigkeitssatz sowie auf die Unentscheidbarkeit von Halteproblem, Emptiness-Problem und Acceptance-Problem. Ihre Schlussfolgerung ist noch entschiedener formuliert: Halluzinationen lassen sich nicht durch architektonische Verbesserungen, Datenanreicherung oder Fact-Checking eliminieren, weil sie aus der fundamentalen mathematischen und logischen Struktur dieser Modelle folgen. Sie führen dafür den Begriff der Structural Hallucination ein, der das Phänomen nicht als Fehler, sondern als strukturelle Eigenschaft beschreibt.

An dieser Stelle ist Vorsicht geboten, denn beide Arbeiten verwenden den Begriff der Halluzination in einer formal definierten Weise, die sich nicht vollständig mit dem alltagssprachlichen Gebrauch deckt. Die Aussagen bedeuten nicht, dass jeder zweite Satz eines Sprachmodells falsch sein muss. Sie bedeuten, dass eine perfekte Wahrheitsmaschine, die in beliebigen Domänen zuverlässig korrekte Antworten liefert, mathematisch unmöglich ist. Was die alltägliche Halluzinationsrate angeht, ist mit weiteren Verbesserungen zu rechnen. Was die prinzipielle Eliminierbarkeit angeht, ist mit nichts dergleichen zu rechnen.

Konkret heißt das Folgendes: Selbst wenn ein Sprachmodell auf einer perfekten Datenbasis trainiert würde und über beliebig viele Parameter verfügte, gäbe es immer Fragen, auf die es plausibel klingende, aber falsche Antworten liefern würde. Banerjee, Agarwal und Singla zeigen darüber hinaus, dass jede Stufe des Verarbeitungsprozesses, von der Zusammenstellung der Trainingsdaten über die Faktenwiederherstellung bis zur eigentlichen Textgenerierung, eine von Null verschiedene Fehlerwahrscheinlichkeit aufweist. Diese Fehler summieren sich auf, lassen sich aber an keiner Stelle vollständig vermeiden. Das ist keine empirische Beobachtung, die sich durch bessere Verfahren widerlegen ließe. Es ist ein Ergebnis derselben Art wie die Unmöglichkeit, einen allgemeinen Halteprüfer zu bauen.

Bemerkenswert ist, dass beide Arbeiten unabhängig voneinander zu demselben Schluss gelangen, allerdings über unterschiedliche Wege. Xu, Jain und Kankanhalli argumentieren über die Lerntheorie. Banerjee, Agarwal und Singla argumentieren über die klassische Berechenbarkeitstheorie. Es ist dieselbe Mauer, an die beide Gruppen laufen. Wer mit den Ergebnissen Gödels und Turings vertraut ist, erkennt sie sofort wieder.

Damit gewinnt auch die populäre Forderung, das Problem der Halluzinationen einfach durch mehr Trainingsdaten oder größere Modelle zu lösen, einen anderen Beiklang. Sie ist nicht falsch in dem Sinne, dass größere Modelle nicht besser werden würden. Sie übersieht nur, dass eine Skalierung an dieser Stelle nicht das Problem berührt, das die zitierten Arbeiten beschreiben. Eine Funktion, die nicht lernbar ist, wird nicht durch mehr Parameter lernbar. Eine Frage, die unentscheidbar ist, wird nicht durch mehr Daten entscheidbar. Die Grenze ist keine Frage des Maßstabs, sondern eine Frage der Natur des Verfahrens.

Eine alte Erkenntnis in neuem Gewand

Hilbert hat sein Programm bis zum Lebensende nicht völlig aufgegeben. Auch nachdem Gödel und Turing seine Voraussetzungen widerlegt hatten, hielt er an dem Glauben fest, dass der wissenschaftliche Geist letztlich jede Frage werde beantworten können. Heute klingt diese Haltung beinahe rührend, gewiss aber als historische Anekdote. Man kann sich darin gefallen, sie etwas belustigt zu betrachten und nachsichtig zu schmunzeln über einen großen Geist, der eine bewiesene Grenze nicht akzeptieren wollte.

Bei aller Belustigung sollte man sich dabei aber fragen, was die Forschungslandschaft der nächsten Jahre über uns selbst erzählen wird. Wir bauen mit erheblichem Aufwand Systeme, die immer mehr Sprache aus der Welt aufsaugen und auf immer mehr Parameter verteilen, in der erkennbaren Hoffnung, dass irgendwann die Halluzinationen verschwinden, wenn man nur lange genug skaliert. Die Mathematik der letzten 90 Jahre legt nahe, dass dieser Weg an genau jene Wand stoßen wird, an die Hilbert gestoßen ist. Nicht weil die Modelle zu klein wären, sondern weil das, was wir uns von ihnen erhoffen, in der gewählten Form nicht zu haben ist.

Vielleicht stellt sich in einigen Jahren heraus, dass der heutige Ansatz für KI nicht der richtige war. Vielleicht auch nicht. Aber dass es sich lohnt, die Frage zu stellen, ob wir gerade ein zweites Mal dabei sind, eine bewiesene Grenze zu ignorieren, kann ich nur empfehlen. Die alten Studieninhalte sind vielleicht doch nicht so trocken, wie sie damals schienen.


(mro)



Source link

Verwandte Themen:
Weiterlesen

Entwicklung & Code

Linux App Summit 2026: Treffen der Linux-Desktop-Avantgarde


Weiterlesen nach der Anzeige

Klein, aber fein war das Treffen der Linux-Desktop-Community. Auf dem Linux App Summit (LAS 2026) Mitte Mai in Berlin trafen sich rund 110 Personen, darunter war projektübergreifend die Avantgarde der Entwickler für moderne Linux-Systeme vor Ort. Dabei ging es weniger um das Aussehen der Desktopoberfläche, als um grundlegende Konzepte, um die Installation einfacher, das System sicherer und robuster sowie die Benutzung komfortabler zu machen. Statt um Desktop-Themes, Distributionen und Pakete drehten sich die Gespräche um Images, Apps und wie das teils veraltete Linux-Ökosystem wieder zu modernen Betriebssystemen wie Android/ChromeOS, macOS und ja, auch Windows, aufschließen kann.

Die etwas mehr als ein Dutzend Vorträge waren sinnbildlich eingerahmt zwischen der Eröffnungs-Keynote von systemd-Erfinder Lennart Poettering und dem Schlussvortrag von Jorge Castro, Initiator des Projektes Universal Blue, aus dem die modernen Linux-Systeme Bluefin und Bazzite hervorgegangen sind. Beide, Castro und Poettering, fordern ein grundlegendes Umdenken, wie Linux-Betriebssysteme bereitgestellt werden, verfolgen aber unterschiedliche Ansätze.

Unveränderliche Images

Lennart Poettering plädierte in seiner Keynote für eine strikte Trennung von Betriebssystem und lokalen Daten (Inhalt der Benutzerverzeichnisse, lokale Konfigurationen et cetera), wo ersteres über ein unveränderliches, für alle gleiches Image verteilt wird. Das erlaubt, die Authentizität des Betriebssystems kryptografisch sicherzustellen, indem vereinfacht gesagt Prüfsummen der Images, aber auch anderer Komponenten wie Kernel und Bootloader, über den TPM-Chip abgesichert sind. Weitere Komponenten kann man als Erweiterungen einklinken, die ebenfalls als verifizierbare Images vorliegen. Manipuliert jemand einen Teil des Systems, ändern sich Hashwerte und führen dazu, dass das TPM-Modul den weiteren Bootvorgang und die Entschlüsselung der Partition mit den lokalen Daten verweigert. Gleichzeitig erlaubt das Design, mithilfe eines korrekten Images den Werkzustand wiederherzustellen.



Systemd-Erfinder Lennart Poettering hielt auf dem LAS 2026 die Eröffnungs-Keynote.

(Bild: Linux App Summit)

Poetterings Ziel ist es, die Zustandsräume (State Spaces) zu verkleinern, also die Unterschiede zwischen verschiedenen Installationen, um die Prüfung und Absicherung der Systeme zu erleichtern. Ihm schwebt vor, das aus dem Speichermanagement bekannte Sicherheitskonzept „Schreiben oder Ausführen“ (W^X) auch auf das Dateisystem auszuweiten. Code solle nur dann ausgeführt werden, wenn dieser von einem überprüften, unveränderlichen Image komme. Er betont aber: „Sicherheit ist nie binär, sondern eine graduelle Angelegenheit.“ So könne etwa innerhalb von Containern was anderes gelten, wenn alles im Userspace läuft und voneinander abgeschottet ist.

Um das zu realisieren, kommen viele unterschiedliche Komponenten von systemd zum Einsatz, etwa systemd-sysupdate, systemd-repart, oder Standards aus dessen Umfeld, wie Discoverable Disk Images. Poettering hat gemeinsam mit anderen Entwicklern die Firma Amutable gegründet, die ein verifizierbares Linux-System anbieten wollen, was aber eher auf Server und Rechenzentren abzielt.

Weiterlesen nach der Anzeige

Für den Desktop setzt neben ParticleOS aus dem systemd-Projekt insbesondere Gnome OS Poetterings Ideen um. An dessen Umbau war maßgeblich der Gnome-Entwickler Adrian Vovk beteiligt, der auch auf der LAS 2026 anwesend war.

Container auf dem Desktop

Auch Kubernetes-Spezialist Jorge Castro fordert ein radikales Umdenken und will ein robustes Linux-System, geht aber mit seinem Projekt Universal Blue einen anderen Weg, indem er Erfolgskonzepte von Containern, etwa Docker, auf den Linux-Desktop übertragen will. „Es gibt 20 Millionen Entwickler in der Cloud-Native-Community“, betont Castro im Gespräch mit c’t. „Ich sehe es als meinen Job an, die wieder für Betriebssystem zu begeistern, damit Gnome und KDE Bestand haben.“ Die Cloud-Entwickler will er mit dem Projekt Universal Blue erreichen, das auf dem von Red Hat entwickelten, aber stiefmütterlich behandelten, Fedora Silverblue basiert. Das System startet aus einem bootbaren Container; Updates holt das Tool bootc ähnlich, wie man es von Docker gewohnt ist. Die Images, also OCI-Container, bauen Castro und seine Mitstreiter automatisiert auf GitHub. Mit Universal Blue hat Castro eine ganze Reihe moderner Linux-Systeme losgetreten.


Jorge Castro Portraitfoto beim Interview

Jorge Castro Portraitfoto beim Interview

Bluefin-Initiator Jorge Castro erläuterte seine Vision eines Linux-Desktops im Gespräch mit c’t.

(Bild: Keywan Tonekaboni / heise medien)

Bluefin nutzt ein aufgehübschtes Gnome, setzt komplett auf Apps aus Flathub sowie Kommandozeilentools aus Homebrew und soll eine Nutzererfahrung wie ChromeOS bieten. „Chromebooks sind super, ich will diese Power mit einem normalen Linux“, sagte Castro in Berlin. Von Bluefin inspiriert entstand Bazzite mit KDE Plasma, was SteamOS des Gaming-Handhelds Steam Deck nachempfunden ist, Steams Gaming Mode unterstützt und so abseits typischer Linux-Zielgruppen auf Resonanz stieß. Auf mobilen Konsolen, wie dem Asus ROG Ally, laufen Spiele mit Bazzite teils schneller, als mit dem vorinstallierten Windows. „Gamer Nerds retten möglicherweise den Linux Desktop“, meint Castro. Im projekteigenen Discord würden 33.000 „Kids“, so Castro, abhängen: „Neue User ganz ohne schlechte Gewohnheiten.“

Den anwesenden Gnome- und KDE-Entwicklern empfahl er, das Schicksal in die eigene Hand zu nehmen und ein eigenes Desktop-Produkt auszuliefern, das Out-of-the-Box funktioniert. Bei klassischen Distributionen gäbe es zu viele Altlasten. „Die Leute gehen mit X11 nach Hause, was eure Arbeit erschwert“, klagte Castro. „It hurts me!“

Castro kritisierte aber auch, dass trotz mehrfacher Ankündigung im de-facto Linux-App-Store Flathub es nicht möglich ist, für Apps zu bezahlen oder auch nur zu spenden.

Apps in VMs einsperren

Was mit modernen Linux-Komponenten möglich ist und wo die Grenzen liegen, zeigte Spectrums Projektleiterin Alyssa Ross. Spectrum priorisiert Sicherheit und ähnelt Qubes OS, welches Umgebungen wie „Arbeit“ oder „Privat“ mittels virtueller Maschine (VM) abschottet. Spectrum setzt das radikaler um, weil jede App in einer eigenen VM startet. Apps interagieren mit dem Betriebssystem zusätzlich zu den VM-Schnittstellen wie virtio-gpu und virtio-fs auch über Desktop Portals, wie sie bei Flatpak und Snap eingesetzt werden. Dank Wayland verhalten sich die Anwendungen wie normale Fenster, ein virtuelles Display gibt es nicht, und trotz der Abschottung klappt auch die Zwischenablage.


Alyssa Ross hält ihren Vortrag zu Spectrum

Alyssa Ross hält ihren Vortrag zu Spectrum

Wie Spectrum konsequent einzelne Apps untereinander isoliert, zeigte Alyssa Ross auf dem LAS 2026 in Berlin.

(Bild: Keywan Tonekaboni / heise medien)

Spectrum blockiert per Vorgabe alle Berechtigungen, was manchmal nicht so einfach ist. Ross beklagte etwa, dass es bei den Desktop Portals keine Audio-Schnittstelle gibt, das den Zugriff auf das Mikrofon regelt. Sobald eine App Zugang zu der Audioschnittstelle von Pipewire hat, kann sie alle verfügbaren Audio-Geräte nutzen, inklusive aller Mikros.

Als Herausforderung bei der Entwicklung von Spectrum bezeichnete die Projektleiterin den Spagat zwischen der Desktop-Arbeit und der Hypervisor-Arbeit. Das Projekt will mit dem Linux-Desktop-Ökosystem zusammenarbeiten und verfolgt eine Upstream-First-Philosophie, weshalb Spectrum keine eigenen Apps entwickelt.

Über den Status von Flatpak und dessen Zukunftspläne berichteten Adrian Vovk und Sebastian Wick, welcher seit vergangenem Jahr neuer Maintainer ist. Die Stagnation bei der Entwicklung von Flatpak sei überwunden, so Wick. Ein Security-Audit hatte einige Sicherheitslücken offenbart, darunter ein Ausbruch aus der Sandbox mittels „path traversal“ (Manipulation eines geöffneten Dateipfades, um Zugriff auf andere Dateien zu erlangen), der schwer zu korrigieren war, weil er sich durch den gesamten Flatpak-Stack zog. Ein erster Fix legte Steam und alle Chrome-basierten Browser lahm, und eine kompatible Lösung zu finden, kostete viel Arbeit.

Neu sind bedingte Berechtigungen. Apps können prüfen, ob es Portals wie das neue USB-Portal gibt, sonst auf veraltete Berechtigungen wie „Alle Geräte“ zurückfallen. Das soll der Verbreitung von Portals helfen, ohne die Apps auf älteren Systemen unbrauchbar zu machen.

Derzeit experimentiert das Flatpak-Team damit, Apps, die noch das veraltete X11-Anzeigesystem verwenden, keinen Zugriff mehr auf das systemweite Xwayland zu geben, sondern für jede solche Anwendung mit Xwayland-satellite eine eigene X11-Umgebung zu starten. Das würde einerseits auch X11-Apps untereinander abschotten, wie es bereits bei Wayland der Fall ist, und andererseits perspektivisch erlauben, aus Wayland-Compositor wie Gnome-Shell den X-Window-Manager-Code herauszuwerfen.

Allgemein machen sich die rund elf Jahre, die Flatpak auf dem Buckel hat, schon bemerkbar. Es fehle teilweise an Abstraktionen, und die notwendige Rückwärtskompatibilität verhindert größere Änderungen. Daher planen Wick und Vovk im Rahmen von Flatpak Next alles neu zu programmieren. Dass dies in Rust geschehen soll, sorgte im Saal für Begeisterung. Dabei soll von Anfang an eine bessere Abstraktion stattfinden, die etwa den Austausch des Speichermechanismus ermöglicht. Flatpaks wären dann denkbar als OSTree, OCI-Container oder DDI.

Statische Berechtigungen, die Löcher in die Sandbox bohren, will das Team künftig nicht mehr ohne Weiteres erlauben. Für Apps soll es künftig zwei Modi geben. Im „confined mode“ sind statische Berechtigungen nicht erlaubt, weshalb sie komplett in der Sandbox laufen und Portals verwenden müssen. Der laxere „unconfined mode“ läuft auf dem Host und nutzt nur die Flatpak-Laufzeitumgebung. Man wolle, so Wick, Vertrieb von Apps und den Einsatz der Sandbox voneinander trennen. Der „unconfined mode“ soll nur mit Flatpak-Quellen („remotes“) möglich sein, denen der User vertraut. Flatpak Next soll für die Sandbox kein bubblewrap verwenden, da selbst ältere Distributionen die Trennung mittels unprivilegierter User-Namespaces unterstützen.

Neue Portals sind ebenfalls geplant, etwa für Rechtschreibprüfung, Passwort-Manager oder für Credentials wie FIDO2-Sicherheitsschlüssel und Passkeys, aber auch um den von Ross vermissten Mikrofon-Zugriff zu regeln. Auch die Portals sollen eine neue Architektur bekommen und Varlink statt D-Bus verwenden. Authentifizierung der Apps und Rechtemanagement soll die von Vovk und Wick neu angedachte systemd-Komponente systemd-appd übernehmen.

Flatpak Next und das bisherige Flatpak sollen parallel installierbar sein und sich nicht ins Gehege kommen; gleiches gilt für die Portals. Gegenüber c’t sagte Wick, es sei einfacher anhand der Erfahrungen Flatpak sauber neu zu entwickeln, als um die Altlasten herumzumanövrieren.

Interessanterweise wies Collabora-Entwickler Thorsten Behrens in seinem Vortrag darauf hin, dass ein Rewrite immer den Nutzen für die User im Fokus haben sollte und kein Selbstzweck sein sollte. So manches trendige Framework sei nach kurzer Zeit schon wieder eingestampft worden.



Tony Wasserka arbeitet an FEX mit und erläuterte, wie der Emulator unveränderten x86-Code auf ARM64-Systemen ausführt und welche Klimmzüge dafür nötig sind.

(Bild: Linux App Summit)

Wie man eine Brücke zwischen zwei Welten schlägt, zeigte Tony Wasserka, der am Emulator FEX mitarbeitet, welcher unveränderten x86-Code auf ARM-Systemen ausführt. Valve plant FEX auf dem angekündigten VR-Headset Steam Frame einzusetzen. Die Schwierigkeit bestehe darin, den x86-Binärcode zur Laufzeit für ARM64 zu rekompilieren und ihn gleichzeitig zu optimieren, um den Code auch schnell genug auszuführen. Wasserka gab Einblicke, wie sie das erreichen. So rekompiliert FEX-Emu den x86-Maschinencode zunächst in eine Zwischensprache um, die dann optimiert wird und woraus dann ARM64-Maschinencode kompiliert wird. Bereits rekompilierte Codestücke speichert FEX-Emu in einem Cache zwischen.

Probleme entstehen etwa dadurch, dass sich das Speichermodell zwischen x86 und ARM64 unterscheidet. Bei Multithreading tauchen Variablen teilweise in einer anderen Reihenfolge auf, als es bei x86 der Fall ist. Das konsequent abzufangen erzeugt einen Overhead, der die Performance massiv drückt. Wasserka und seine Mitstreiter entwickelten daher Heuristiken, um den Overhead nur dort zu erzeugen, wo er zwingend notwendig sei. So habe es bei Unity-Spielen schon gereicht, nach einem bestimmten Memory load offset Ausschau zu halten, sonst sei die Reihenfolge vernachlässigbar. „Es ist erschreckend, wie gut der Trick funktioniert“, resümierte Wasserka.

Ein weiterer Schritt bestand darin, Wrapper für Syscalls zu schreiben. Das sei zwar oft einfach, aber da es Hunderte von ihnen gibt, in der Summe aufwendig. Diese Arbeit sei aber jetzt fast komplett abgeschlossen. Bei Windows-Programmen profitiert das FEX-Emu-Team von den ARM64EC-Windows-Bibliotheken, die Microsoft öffentlich bereitstellt. Der Code der Windows-Programme wird für die ARM64EC-Schnittstelle rekompiliert. Dadurch fallen viele Zwischenschichten weg, wie x86-Wine, x86-Windows- und Linux-Bibliotheken sowie Kernel-Kompatibilitätsschichten. Stattdessen reichen der Rekompilierer, ein WINE für ARM sowie die ARM64EC-Bibliotheken, die direkt mit dem ARM-Kernel interagieren können. Wasserka demonstrierte dem LAS-2026-Publikum FEX live, indem er ein x86-Steam auf seinem ARM64-Notebook öffnete und das Spiel Tunic startete, welches weitgehend flüssig lief.

c’t Open Source Spotlight abonnieren

Innovative Software, spannende Projekte: Erweitern Sie Ihre Möglichkeiten und werden Sie Teil der Open Source Community.

E-Mail-Adresse

Ausführliche Informationen zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten erhalten Sie in unserer Datenschutzerklärung.

Linux auf dem Desktop hat es derzeit nicht einfach, da aktuell kaum Geld in den Linux-Desktop fließt. Das zeigt auch ein Blick auf die Sponsoren des LAS 2026, die nicht mehr so zahlreich sind wie noch vor einigen Jahren. Umso engagierter ist die Community, die innovative Ideen ersinnt und umsetzt, wie Bluefin, Bazzite oder Gnome OS zeigen. Die Aufzeichnungen der Vorträge des Linux App Summit sind auf YouTube verfügbar.

Lesen Sie auch


(ktn)



Source link

Weiterlesen

Entwicklung & Code

Trump gibt sich exklusiven Zugriff auf neue KI vor allen anderen


Nach einigem Hin und Her hat US-Präsident Donald Trump am Dienstag doch einen Erlass zum Thema Künstliche Intelligenz veröffentlicht. Er richtet eine ganze Latte neuer Arbeitskreise ein, die sich Themen rund um KI und IT-Sicherheit widmen sollen. Klaffende Lücke bleibt Sicherheit der KI selbst – eine entsprechende Vereinbarung der US-Regierung mit der KI-Branche hat Trump am ersten Amtstag seiner zweiten Amtszeit aufgekündigt.

Weiterlesen nach der Anzeige

Zwar erklärt er die Förderung von KI-Innovation und Sicherheit zum offiziellen Ziel, ordnet dann aber keine konkreten zur Stärkung der KI-Sicherheit an. Erreicht werden soll das durch „Zusammenarbeit mit der Privatwirtschaft zwecks Modernisierung von IT-Systemen in Verwaltung und Privatwirtschaft und deren Härtung gegen Bedrohung von außen”. Tatsächlich stellen Insider grundsätzlich die größere Bedrohung, neuerdings kommen noch Risiken durch intern aufgesetzte KI-Agenten hinzu.

Trump belässt es bei allgemeinen Befehlen zur „Priorisierung” von IT-Abwehr bei Militär, Geheimdiensten, zivilen Behörden und deren Dienstleistern – binnen 30 Tagen. Nicht näher bezeichnete Bundesprogramme zur „Verbesserung KI-fähiger Abwehrwerkzeuge” sollen ausgeweitet oder gegründet werden. Nebenbei soll der Justizminister verstärkt gegen Straftäter vorgehen, die KI für ihre Machenschaften einsetzen.

Einkaufstour ohne Budget

Und Trump hält Behörden dazu an Geld auszugeben: Einerseits sollen IT-Sicherheitswerkzeuge und -dienstleistungen beschafft werden, für Behörden des Bundes, der US-Staaten und lokaler Körperschaften, sowie für Betreiber Kritischer Infrastruktur „wie ländliche Spitäler, lokale Banken und lokale Versorgungsunternehmen”. Wer sich darum kümmern soll und aus welchem Budget das zu bedecken wäre, lässt Trump offen. Insofern handelt es sich eher um einen Wunschbrief ans Parlament, das über das Bundesbudget bestimmt.

Andererseits soll sich die Budgetabteilung des Weißen Hauses auf die Suche nach bereits bestehenden Förderprogrammen machen, deren Mittel gewidmet werden können zur Subvention von KI-Entwicklung: konkret fortschrittlicher KI zur Entdeckung von Sicherheitslücken. Die eine oder andere Umwidmung dürfte auch ohne Parlamentsbeschluss zulässig sein, in Summe aber nicht viel bringen.

Geheimdienste und Militär sollen Sicherheitslücken finden

Parallel dazu soll das Finanzministerium gemeinsam mit dem Verteidigungsminister vertreten durch den Geheimdienst NSA, sowie dem Minister für Heimatsicherheit vertreten durch CISA (Cybersecurity and Infrastructure Security Agency), ein KI Clearinghouse einrichten. Dieses soll in „freiwilliger Zusammenarbeit” mit der KI-Branche und Betreibern Kritischer Infrastruktur das Scannen nach Software-Sicherheitslücken koordinieren und deeskalieren.

Weiterlesen nach der Anzeige

Das Clearinghouse soll auch selbst solche Lücken finden und bestätigen, sowie deren Schließung koordinieren und priorisieren, samt Verteilung von Sicherheitsupdates. Information der Öffentlichkeit schreibt der Erlass nicht vor. Im Endeffekt bedeutet dies, dass NSA und Co Sicherheitslücken suchen, finden, und dann steuern, ob und wann sie bei wem gefixt werden. Von Unterstützung für die darbende Schwachstellendatenbank NVD des NIST ist keine Rede.

Da die KI nicht alles alleine kann, und Elon Musks Doge zahlreiche IT-Experten grundlos gefeuert hat, muss neues Fachpersonal her. Dazu hat die US-Regierung Ende 2025 die „US Tech Force” ausgerufen. Dieses auf Dauer angelegte Programm erlaubt knapp 30 KI-Konzernen, insgesamt zirka 1.000 eigene Mitarbeiter für jeweils zwei Jahre in US-Ministerien zu platzieren, die dafür ausnehmend hohe Gehälter bezahlen. Die meisten der beteiligten Konzerne haben direkt oder indirekt für Donald Trump gespendet. Sein aktueller Erlass sieht vor, die US Tech Force auszuweiten: Die Behörden brauchen mehr Experten für IT-Sicherheit.

Exklusiver Zugriff auf neueste KI

Abschnitt 3 des Erlasses zielt auf exklusiven Vorrang der US-Regierung bei sogenannten „frontier models” ab. Gemeint sind die fortschrittlichsten großen KI-Modelle, also der jeweils neueste Schrei. Sie sollen möglichst nicht mehr direkt auf den Markt kommen, sondern zunächst 30 Tage lang exklusiv der Regierung zur Verfügung gestellt werden.

Auch danach ist kein freier Marktzugang gewünscht: Vielmehr sollen Betreiber und Regierung gemeinsam festlegen, welche vertrauenswürdigen Partner das frontier model verwenden dürfen, „um sichere Innovation zu fördern und die IT-Sicherheit Kritischer Infrastruktur zu stärken”. Der Präsident kann diese Einschränkungen nicht erzwingen, weshalb er ein freiwilliges Framework für KI-Entwickler aufstellen lässt. Sie werden also voluntold, zu Freiwilligen ernannt.

Zuständig ist wieder der vom Clearinghouse bekannte Arbeitskreis aus NSA, CISA und Finanzministerium. Um feststellen zu können, was überhaupt als frontier model gilt, sollen sie einen geheimen Vergleichsmaßstab (Benchmark) ausarbeiten. Daran soll die NSA neue KI-Modelle bewerten. Stuft sie eines als frontier model ein, soll die NSA KI-Entwickler und Forscher, „soweit angemessen”, informieren.

Teilnehmer des Frameworks dürfen zudem fragen, ob ein KI-Modell, an dem sie gerade arbeiten, voraussichtlich als frontier model gelten wird. Sonst könnte passieren, dass ein Konzern, seine technische Errungenschaft unterschätzend, seine freiwillige Verpflichtung verletzt und die Super-KI kurzerhand veröffentlicht.


(ds)



Source link

Weiterlesen

Entwicklung & Code

Microsoft Build 2026: KI-Entwicklung mit, unter und für Windows


Weiterlesen nach der Anzeige

Microsoft veranstaltet am 2. und 3. Juni 2026 die Entwicklerkonferenz MS Build 2026. Das Unternehmen wendet sich damit insbesondere an Entwickler, die ihre Software für das Windows-Ökosystem entwickeln. Wie in den vergangenen Jahren steht auch dieses Jahr wieder ganz viel Künstliche Intelligenz auf der Agenda. Konkrete Windows-Weiterentwicklung findet sich jedoch kaum.

Erneut steht die Entwicklung mit Hilfe von KI und von KI-basierten Helfern ganz oben auf der Liste. Insgesamt sieben neue KI-Modelle entlässt das „Microsoft AI Superintelligence Team“ in die Welt. Darunter ist das erste Reasoning-Modell MAI-Thinking-1 von Microsoft. MAI-Image-2.5 und eine Flash-Variante davon beherrschen Text-to-Image, sie sollen Google Nano Banana Pro überholen. MAI-Transcribe-1.5 verschriftlicht Ton in 43 Sprachen, Streaming soll aber erst demnächst dazukommen. MAI-Voice-2 und eine Flash-Variante davon bedienen 15 Sprachen und haben neue Stimmen-Optionen bekommen. Beim Programmieren auf GitHub hilft MAI-Code-1. Microsoft erwähnt OpenAI in dem Zuge nicht.

Vorträge behandeln etwa das Bauen, Verteilen und Skalieren von KI-Agenten mit dem Cloud-PC Windows 365. Ein Vortrag zum Windows Subsystem for Linux verspricht Neuigkeiten. Eigentlich befassen sich bislang alle der wenigen Windows-spezifischen Vorträge mit dem Einsatz von KI-Tools zur Entwicklung unter Windows sowie mit dem Betreiben von KI-Bots wie OpenClaw. Ein Vortrag fällt etwas heraus: Er beschreibt, wie Developer mit dem Windows Terminal ihre Produktivität steigern können sollen.

Plattformen, Tools, Vertrauen

Mächtig blumig umschreibt Microsofts Marketingabteilung, was Entwickler denn so bräuchten, um die Lösungen gleich mit anzubieten. Am Ende destilliert sich daraus zusammen, dass sie Sicherheit von Infrastrukturen und Apps sowie beschleunigte und vereinfachte Entwicklung benötigten. Und das nicht nur für Teilprobleme, sondern Full-Stack, mit Tools, Modellen und Prozessen nach den Vorstellungen der Developer.

Windows soll dafür selbstverständlich die ideale Plattform sein – man bekommt bei den ganzen schwerpunktmäßigen Beiträgen zu Entwicklung von und mit KI fast das Gefühl, dass das Betriebssystem komplett entkoppelt und irrelevant geworden ist. Microsoft kündigt dafür jedoch eine neue Entwickler-Konfiguration an: Die soll flexiblere und reibungslosere Shell- und Terminal-Erfahrungen liefern. Außerdem lassen sich Agents in lokale Sandboxen verfrachten: Microsoft spricht davon, Windows zu einer nativen Agent-Runtime zu machen. Als Vorschauversion gibt es die Microsoft Execution Containers (MXC) genannten Sandboxen, die bis Enterprise-tauglich sein sollen – etwa, um OpenClaw mit „Sicherheitsbeschränkungen“ auszuführen.

Die Vorschau der GitHub-Copilot-App soll agentische Entwicklung zur nativen Desktop-Erfahrung für eine viel weiterreichende Zielgruppe machen: Interessierte sollen einfach eine Idee oder ein existierendes Problem beschreiben, und schon legt die App los und lässt mehrere Agentensitzungen parallel laufen und behält die Änderungen im Blick. Jede Session setzt dabei auf git-Trees, sodass die Teile getrennt bleiben. Die Entwickler behalten die Kontrolle, während Copilot sich um die Ausführung kümmert. Entwickler sollen Apps so in Sekunden erstellen können.

Weiterlesen nach der Anzeige

Auch für Zugriff auf Datenbanken und Dienste hat Microsoft ein Backend-as-a-Service im Angebot, die Vorschau auf die Plattform Project Rayfin. Das soll die Entwicklung vom Prototypen bis zum Produktionslevel ermöglichen, ohne dass Entwickler sich um die Verwaltung von Infrastruktur kümmern müssten.

Neue KI-Hardware hat Microsoft ebenfalls zu bieten: Das Surface RTX Spark ist eine Developer-Box für dauerhafte Workloads. Training, agentische KI-Pipelines und lokales Finetuning von Modellen, all das soll sie mit einer Last von 100 Watt erledigen. Darin werkelt dem Namen entsprechend eine Nvidia RTX Spark mit bis zu einem Petaflop KI-Rechenleistung (ungenannte Präzision) und 128 GByte an RAM (unified, also mit Prozessor geteilt). Die Maschine soll Modelle mit bis zu 120 Milliarden Parameter lokal laufen lassen können.

Windows Subsystem for Linux 2 (WSL2) mit nativem GPU-Passthrough sowie vollem CUDA-Support liefert Microsoft vorkonfiguriert mit. Zudem sollen Visual Studio Code, GitHub Copilot und zahlreiche weitere beliebte Dev-Tools vorinstalliert sein. Kleiner Haken: Diese Entwicklerkiste soll erst später im Jahr verfügbar werden – und vorerst auch nur in den Vereinigten Staaten.


(dmk)



Source link

Weiterlesen

Beliebt