Entwicklung & Code
Fedora plant KI-Linux-Desktop | heise online
Fedora arbeitet an einer neuen Initiative für einen KI-optimierten Linux-Desktop. Mit dem Fedora AI Developer Desktop soll ein System für lokale KI- und Machine-Learning-Workloads entstehen. Es soll auf Fedora Atomic Desktops aufsetzen und vorkonfigurierte Werkzeuge, Container-Images sowie GPU-Beschleunigung umfassen. Ziel ist laut Proposal eine reproduzierbare und einfacher nutzbare Entwicklungsumgebung für KI-Anwendungen.
Weiterlesen nach der Anzeige
Die Initiatoren betonen gleichzeitig, dass sie keine KI-Funktionen in bestehende Fedora-Editionen integrieren wollen. Stattdessen sind separate Images und Fedora-Remixes geplant. Der Fedora Council hat die Initiative am 6. Mai 2026 einstimmig zur Annahme empfohlen. Die offizielle Bestätigung erfolgte nach einer lazy-consensus-Phase, die am 8. Mai endete. Fedora-Projektleiter Jef Spaleta fungiert dabei als Executive Sponsor.
Atomic Desktops für KI
Die Pläne knüpfen an bestehende Fedora-Desktopvarianten wie Silverblue oder Kinoite an. Diese sogenannten Atomic Desktops nutzen unveränderliche Systemabbilder statt einer klassischen Paketverwaltung als primären Update-Mechanismus. Aktualisierungen lassen sich so transaktional einspielen und bei Problemen leichter zurücksetzen. Gerade für KI-Workloads ist das wichtig, weil lokale KI-Stacks häufig empfindlich auf Änderungen an Kernel-, Treiber- oder CUDA-Versionen reagieren.
Einen ähnlichen Ansatz verfolgt das Community-Projekt Universal Blue, das Fedora-Atomic-Varianten mit zusätzlicher Hardwareunterstützung und vorkonfigurierten Entwicklerumgebungen ausliefert. Auch Canonical treibt mit Ubuntu die Integration von KI-Werkzeugen in Linux-Systemen voran.
Reproduzierbare Basis statt manueller Nacharbeit
Ziel der Fedora-Initiative ist, die bislang oft komplexe Einrichtung lokaler KI-Umgebungen stärker in die Distribution selbst zu verlagern. Entwickler Gordon Messmer beschreibt im Proposal vor allem die heterogene Treiber- und Toolchain-Situation als Problem. Viele KI-Frameworks erfordern derzeit manuelle Nacharbeiten, etwa beim Zusammenspiel von Kernel, Nvidia-Treiber, CUDA-Toolkit und Container-Laufzeiten. Das Projekt will daher getestete und reproduzierbare Basissysteme bereitstellen, statt Nutzer mit distributions- und hardwareabhängigen Anleitungen zu konfrontieren.
Geplant sind dafür mehrere technische Bausteine: ein langfristig gepflegter LTS-Kernel innerhalb Fedora, signierte Nvidia-OpenRM-Kernelmodule, Atomic-Systemabbilder für beschleunigte KI-Workloads sowie Fedora-Remixes mit CUDA-Runtime oder CUDA-Toolkit. Hinzu kommen vorkonfigurierte Werkzeuge wie Podman Desktop oder Goose CLI sowie optimierte Container-Images für Machine-Learning-Anwendungen.
Weiterlesen nach der Anzeige
Die Umsetzung soll in drei Schritten erfolgen: Mit Fedora 45 stehen Plattformarbeiten und die ersten fünf Deliverables im Fokus, Fedora 46 bringt den Community-Aufbau samt Beitragsleitfaden, Fedora 47 schließlich die Entwicklerwerkzeuge und optimierten Container-Images. Eine Vorschau auf den Atomic-Desktop-Remix sowie der zugehörige Long-Term-Kernel mit Nvidia-Modul sind bereits verfügbar.
Streitpunkt LTS-Kernel
Ein zentraler Streitpunkt in der Diskussion ist der vorgeschlagene LTS-Kernel. Fedora verwendet bislang ein Rolling-Release-Modell und integriert neue Kernelversionen vergleichsweise schnell. Die Befürworter argumentieren, dass ein stabiler Kernelzweig vor allem bei KI-Workloads mit GPU-Beschleunigung Vorteile bringe. Viele KI-Umgebungen setzen auf sogenannte Out-of-tree-Kernelmodule, also Module außerhalb des offiziellen Kernel-Quellcodes. Dazu zählen auch die Nvidia-Treiber. Ändern sich interne Kernel-Schnittstellen, müssen Entwickler solche Module anpassen, und sie können zeitweise inkompatibel werden.
Die Autoren des Proposals sehen darin ein strukturelles Problem für reproduzierbare KI-Umgebungen. Ein über längere Zeit stabil gehaltener Kernel soll dagegen eine konsistente Plattform für KI-Stacks schaffen. Kritiker innerhalb der Fedora-Community bezweifeln, dass Fedora die zusätzlichen Wartungsaufgaben für einen LTS-Kernel und Out-of-tree-Module langfristig stemmen kann. Andere verweisen darauf, dass sich ein Teil der Probleme bereits heute über bestehende Atomic-Mechanismen oder externe Build-Infrastrukturen lösen lässt.
Proprietäre Komponenten und Datenschutz
Diskutiert wird zudem die Rolle proprietärer Nvidia-Software. Das Proposal sieht unter anderem Fedora-Remixes mit CUDA-Unterstützung vor. CUDA ist zwar der De-facto-Standard vieler KI-Frameworks, basiert jedoch weiterhin teilweise auf proprietären Komponenten. Zwar stellt Nvidia inzwischen offene Kernelmodule unter dem Namen OpenRM bereit, die eigentliche CUDA-Laufzeitumgebung und Teile des Userspace bleiben jedoch geschlossen. Entsprechend kontrovers diskutiert die Community, wie eng Fedora diese Software offiziell unterstützen sollte.
Die Initiatoren betonen mehrfach, dass die geplanten Images weder Cloud-Anbindung noch Telemetrie vorsehen. KI-Werkzeuge sollen sich standardmäßig nicht mit externen KI-Diensten verbinden. Stattdessen liegt der Schwerpunkt auf lokal ausgeführten Modellen und Entwicklerwerkzeugen. Auch Anwendungen zur Überwachung oder automatischen Analyse des Nutzerverhaltens schließt das Proposal ausdrücklich aus.
Neben technischen Fragen löste die Initiative auch grundsätzliche Debatten innerhalb der Fedora-Community aus. Einzelne Entwickler äußerten deutliche Kritik; ein Beteiligter kündigte im Verlauf der Diskussion seinen Rückzug aus Fedora-Aktivitäten an. Andere Nutzer verweisen dagegen auf mögliche Kooperationen mit Universal Blue oder den bereits aktiven KI- und ML-Gruppen im Fedora-Umfeld.
Lesen Sie auch
(fo)
Entwicklung & Code
KI-Hype vs. Realität: Warum Technologie allein nicht reicht
In seiner Keynote auf der data2day 2025 stellt Dr. Michael Zimmer den Menschen ins Zentrum der KI-Transformation – nicht die Technologie. Unter dem Leitgedanken „V³ – Verständnis, Vertrauen und Verantwortung“ zeigt er auf, dass KI in der Unternehmenspraxis weit mehr erfordert als technische Implementierung. Am Beispiel Klarna illustriert er, wie Unternehmen zunächst massiv auf KI-gestützte Automatisierung setzten und Personal abbauten, nur um später festzustellen, dass menschlicher Kundenkontakt unersetzlich ist. Eine MIT-Sloan-Studie untermauert zwar Produktivitätssteigerungen von bis zu 42 % bei Einzelaufgaben – in der Gesamtbetrachtung sei jedoch keine signifikante Veränderung messbar. Zimmer warnt vor dem Reflex, KI als Universallösung für strukturelle Probleme wie unübersichtliche Dokumentenablagen oder fehlerhafte Prozesse einzusetzen, und bringt es auf den Punkt: „Shit in, shit out“ – ohne saubere Daten und Prozesse liefert auch KI keine brauchbaren Ergebnisse.
Weiterlesen nach der Anzeige
Befähigung statt Angstmache: Der Mensch als Erfolgsfaktor
Für Data Teams besonders relevant ist Zimmers Analyse der unterschiedlichen Mitarbeitertypen im KI-Kontext: von der erfahrenen Fachkraft, die KI-Trainings konzipiert, über das „Spielkind“, das ohne Governance eigene Lösungen baut, bis zum ängstlichen Kollegen, der erst „abgeholt“ werden muss. Die W&W-Gruppe begegnet dem mit einem breit angelegten Enablement-Programm: 500 Mitarbeitende wurden in Präsenz geschult, eine Konzernbetriebsvereinbarung (KBV) erarbeitet, und Betriebsrat und Vorstand ziehen bewusst an einem Strang. Das konkrete Praxisbeispiel „Reggi“ – ein KI-Assistent zur Regresserkennung in der Kfz-Schadenbearbeitung – zeigt, wie ein gelungenes Zusammenspiel aussieht: Die KI übernimmt die zeitaufwendige Dokumentenprüfung, die finale Bewertung bleibt beim Menschen.
Governance, Regulierung und die Rolle von Data Teams
Zimmer betont in seinem Vortrag, dass erfolgreiche KI-Einführung Domänenwissen, Nähe zwischen IT und Fachbereich, klare Standards für Plattformen und Integrationsmuster sowie eingespielte Entwicklungs- und Deployment-Prozesse benötigt. Hinzu kommen die regulatorischen Anforderungen: Der EU AI Act (in Kraft seit August 2024, für die meisten Regelungen gültig ab August 2026, für bestimmte Hochrisiko-KI-Bereiche erst ab August 2027) verlangt von Finanzkonzernen einen risikobasierten Ansatz mit konkreten Prüfschemata. Sein Fazit für Data Scientists und Engineers: „Wir übernehmen das Denken, die KI erledigt die Ausführung, wir kümmern uns um die Validierung und Interpretation.“ Im aktuellen LLM-Hype sei Expertenwissen wichtiger denn je – und duale/integrierte Studienmodelle bekämen eine entscheidende Rolle, um diese Kompetenzbrücke zwischen Fachlichkeit und Technologie zu schlagen.
Empfohlener redaktioneller Inhalt
Mit Ihrer Zustimmung wird hier eine Vimeo-Video (Vimeo LLC) geladen.
data2day 2025: „Auf den Menschen kommt es an“ (Dr. Michael Zimmer)

Dr. Michael Zimmer ist Chief Data & AI Officer und Leiter des Kompetenzzentrums für KI in der W&W-Gruppe. Er hat über Agilität von Datenarchitekturen promoviert und war unter anderem als CDO der Zurich Gruppe Deutschland und mehr als 13 Jahre in der Beratung tätig. Er ist Herausgeber und Autor diverser Bücher und unter anderem TDWI Fellow, männlicher Alliierter der Women Leaders in Data and AI (WLDA) sowie Mitglied der Arbeitsgruppe Ethical AI der deutschen Aktuarsvereinigung.
Weiterlesen nach der Anzeige

Vom 7. bis 8. Oktober 2026 bietet die data2day in Köln ein umfassendes Programm zu Data Science, Data Engineering und Data Analytics. Ein besonderer Fokus liegt auf Agentic AI und Analytics, modernen Datenarchitekturen, rechtlichen Aspekten und Einblicken in die Unternehmenspraxis.
Ab sofort sind Tickets zum Frühbucherpreis verfügbar.
(map)
Entwicklung & Code
Databricks will ETL zwischen Datenbanken und Analytics überflüssig machen
Mit LTAP (Lake Transactional/Analytical Processing) stellt Databricks eine Architektur vor, die operative Datenbanken und analytische Systeme enger zusammenführen soll. Statt Daten per ETL- oder CDC-Prozessen zwischen beiden Welten zu kopieren, sollen künftig beide auf derselben Datenbasis arbeiten. Databricks sieht darin eine Antwort auf den zunehmenden Einsatz von KI-Agenten, die jederzeit auf aktuelle Unternehmensdaten zugreifen müssen.
Weiterlesen nach der Anzeige
In vielen Unternehmen existieren heute zwei getrennte Datenwelten. Operative Anwendungen speichern ihre Daten für den laufenden Geschäftsbetrieb in Transaktionsdatenbanken wie PostgreSQL oder Oracle. Für Berichte, Analysen oder KI-Anwendungen werden diese Daten anschließend in ein Data Warehouse oder Lakehouse kopiert. Dazwischen liegen ETL-Prozesse oder sogenannte Change-Data-Capture-Pipelines (CDC), die Änderungen laufend zwischen beiden Systemen synchronisieren. Diese Architektur gilt seit Jahren als Standard, verursacht jedoch zusätzlichen Betriebsaufwand, Datenkopien und zeitliche Verzögerungen.
Nach Ansicht von Databricks stößt dieses Modell zunehmend an seine Grenzen. KI-Agenten und moderne Anwendungen benötigten aktuelle operative Daten und könnten nicht mit Minuten oder Stunden alten Replikaten arbeiten. Mit LTAP will der Hersteller deshalb transaktionale und analytische Workloads enger zusammenführen.
Zwei Engines statt einer
Neu ist die Idee allerdings nicht. Bereits vor rund 15 Jahren versuchten HTAP-Systeme (Hybrid Transactional/Analytical Processing), Transaktionen und Analysen in einer gemeinsamen Datenbank-Engine auszuführen. Der Nachteil: Dieselbe Engine musste gleichzeitig schnelle Schreibzugriffe und komplexe analytische Abfragen bewältigen, was häufig zulasten der jeweiligen Optimierung ging.
Genau darin sieht Databricks den entscheidenden Unterschied zu früheren HTAP-Ansätzen. Eine einzelne Engine sei für beide Aufgaben zwangsläufig kompromissbehaftet, erläutert Rich Radley, Vice President Field Engineering EMEA bei Databricks. LTAP setzt stattdessen auf zwei spezialisierte Engines: Lakebase übernimmt die transaktionale Verarbeitung auf Basis von PostgreSQL, das Lakehouse die analytischen Abfragen. Beide greifen jedoch auf dieselbe Datenbasis zu.
Grundlage dafür ist Lakebase, ein serverloses PostgreSQL-System, das Daten direkt im Objektspeicher des Lakehouse ablegt. Nach Angaben des Herstellers werden die für Transaktionsdaten typischen zeilenorientierten Daten beim Schreiben automatisch in ein für analytische Abfragen optimiertes spaltenorientiertes Format überführt.
Weiterlesen nach der Anzeige
Erst dadurch können beide Engines dieselbe Datenbasis nutzen, obwohl sie unterschiedliche Anforderungen an die Datenorganisation stellen. Radley bezeichnet diese Echtzeit-Transcodierung als eigentlichen technischen Durchbruch der Architektur. Dadurch können zwei spezialisierte Engines parallel auf denselben Daten arbeiten, ohne dass Daten zwischen operativen und analytischen Systemen repliziert werden müssen.
Gemeinsame Datenbasis statt Datenkopien
Lakebase legt die Daten auf derselben Speicherschicht wie das Lakehouse in offenen Tabellenformaten wie Delta oder Iceberg ab. Über den Unity Catalog werden sie gemeinsam verwaltet; dieser übernimmt Berechtigungen, Metadaten und Governance. Dadurch können sowohl die transaktionale Datenbank als auch das Lakehouse auf dieselbe Datenbasis zugreifen, ohne dass zusätzliche Datenkopien entstehen.
Lakebase ergänzt Databricks zudem um cloud- und regionenübergreifende Disaster Recovery, Git-ähnliche Branches und Snapshots sowie autonome Datenbankfunktionen, bei denen Agenten den Zustand überwachen und Optimierungsvorschläge liefern.
Architektur statt Revolution
Mit seinem Ansatz, transaktionale und analytische Workloads enger zusammenzuführen, will sich Databricks sowohl von den HTAP-Systemen (Hybrid Transactional/Analytical Processing) als auch von den neueren Zero-ETL-Konzepten absetzen. Während HTAP beide Workloads in einer gemeinsamen Engine vereinen wollte, argumentiert Databricks, dass Zero ETL vor allem den Integrationsaufwand zwischen bestehenden Systemen reduziere, die zugrunde liegenden Datenkopien jedoch bestehen blieben. LTAP setzt dagegen auf zwei spezialisierte Engines, die auf einer gemeinsamen Datenbasis arbeiten und Datenkopien vollständig vermeiden sollen.
Ob dieser Architekturansatz ETL- und Replikationsprozesse tatsächlich in größerem Umfang ersetzen kann, muss sich allerdings erst im produktiven Einsatz zeigen. LTAP ist bislang nicht allgemein verfügbar, unabhängige Benchmarks oder belastbare Erfahrungen aus Produktivumgebungen liegen ebenfalls nicht vor.
Zusammen mit Lakehouse//RT zeigt LTAP die strategische Richtung von Databricks: Analyse-, Transaktions- und KI-Workloads sollen künftig nicht mehr über zahlreiche Datenkopien und spezialisierte Zwischensysteme verbunden werden, sondern auf einer gemeinsamen Datenbasis zusammenlaufen. Sollte sich dieser Architekturansatz im produktiven Einsatz bewähren, könnte er den Aufbau datenintensiver KI-Anwendungen und Agentensysteme vereinfachen.
(axk)
Entwicklung & Code
0,7 Nanometer: IBM zeigt die ersten Chips mit CFET-Transistoren
IBMs Forschungsabteilung hat einen neuartigen Fertigungsprozess entworfen, den die Firma der 0,7-Nanometer-Generation alias 7 Ångström (7A) zuordnet. Die Versprechen sind enorm: Verglichen mit dem selbst entworfenen 2-nm-Prozess von 2021 soll sich die Transistordichte verdoppeln. Die Performance bei gleicher elektrischer Leistungsaufnahme steigt um bis zu 50 Prozent, alternativ sinkt der Energiebedarf bei gleicher Performance um bis zu 70 Prozent.
Weiterlesen nach der Anzeige
Damit ist nicht Schluss: Laut Mitteilung soll sich auch der in Prozessoren, Grafikchips und anderen Chiptypen integrierte SRAM-Cache um 40 Prozent verkleinern lassen. Das wäre ein enormer Sprung, nachdem sich die SRAM-Skalierung in den vergangenen Fertigungsgenerationen einer Wand genähert hatte.
Wie üblich haben Nanometer- beziehungsweise Ångström-Namen nichts mit den tatsächlichen Dimensionen zu tun. Ein einzelner Chip hat zahlreiche Metriken, anhand derer sich die Größen messen lassen. Die Mitten zweier Transistoren etwa sollen bei IBMs 7A 42 bis 45 nm voneinander entfernt sein (Contacted Poly Pitch, CPP).
Nanostacks: Gestapelte Transistorpaare
Verglichen mit der 2-nm-Generation entsprächen bis zu 42 nm CPP nur einem kleinen Fortschritt. Der Clou liegt beim Aufbau der Transistorpaare für die entgegengesetzten Stromfluss-Richtungen: In jedem Chip sitzt ein Paar aus PMOS- und NMOS-Transistor, die sich bisher immer nebeneinander befanden. IBM stapelt sie jedoch übereinander, um den Platz in der Breite effektiv zu verdoppeln.

Elektronenmikroskopbilder von IBMs 7A-Chip. Im Querschnitt sind die übereinanderliegenden Transistorpaare und die Dielektrikum-Schicht in der Mitte sichtbar.
(Bild: IBM)
Die Firma nimmt damit den Wechsel auf komplementäre Feldeffekttransistoren (CFETs) vorweg. Die weltweit führenden Chipauftragsfertiger TSMC, Samsung und Intel betrachten CFETs für die frühen 2030er-Jahre als wahrscheinlichste Nachfolger der aktuellen Gate-All-Around-Transistoren (GAA-FETs).
Weiterlesen nach der Anzeige
Derzeitige CFET-Konzepte stellen prinzipiell zwei übereinander angeordnete GAA-FETs dar, so auch bei IBM. Die Firma wechselt den Markennamen daher von Nanosheets auf Nanostacks.
Wafer-Bonding
IBM setzt dafür zwei separat belichtete und stark ausgedünnte Silizium-Wafer übereinander (Bonding). Nach jahrelanger Forschung soll sich dieser Ansatz gegenüber monolithischen Wafern als vorteilhaft herausgestellt haben.
Der Hersteller kann so die Atomanordnung einzeln für die NMOS- und PMOS-Richtungen optimieren. Dafür steigt die Fertigungskomplexität, was wiederum die Kosten hochtreibt. IBMs Ansatz könnte daher primär für High-End-Chips wie KI-Beschleuniger interessant sein.

Ein fertiger 7A-Wafer sieht aus wie jeder andere. Tatsächlich handelt es sich jedoch um gestapelte Wafer.
(Bild: IBM)
Eine Analyse von More Than Moore liefert Details zu IBMs „Secret Sauce“ beim Wafer-Bonding. Nur äußerlich ähnelt die Vorgehensweise AMDs und TSMCs 3D-V-Cache, bei dem zusätzliche Cache-Dies über den Compute-Dies mit den Rechenkernen liegen, etwa beim Ryzen 9 9950X3D2 Dual Edition.
Unter der Haube ätzt IBM jedoch keine Durchkontaktierungen (Through-Silicon Vias, TSVs) in die Chips, um Verbindungen für den Daten- und Stromfluss herzustellen. Stattdessen sind die Transistorpaare über ein Dielektrikum direkt miteinander verbunden. More Than Moore schätzt, dass IBM je nach Chipspezifikation auf 382 Millionen bis 548 Millionen Transistoren pro Quadratmillimeter Fläche kommt. Zum Vergleich: TSMCs N2-Prozess schafft etwa 236 Millionen.
Ab 2031 serienreif
IBM produziert seit der Übergabe der eigenen Halbleiterwerke an Globalfoundries zwar keine Chips mehr selbst in Serie, ist bei der Forschung aber weiterhin ein wichtiger Spieler. Der junge japanische Chipauftragsfertiger Rapidus lizenziert etwa IBM-Technik. So überrascht es auch nicht, dass Tokyo Electron (TEL) an der 7A-Entwicklung beteiligt war. Ebenfalls dabei: Lam Research und Screen Semiconductor Solutions. Alle drei Partner entwerfen Maschinen und Verfahren zur Wafer-Verarbeitung.
Laut eigenen Angaben könnte sich der Nanostack-Ansatz in fünf Jahren für die Serienfertigung bewähren. Damit läge IBM im industrieweiten Zeitplan. TSMC, Intel und Samsung bringen bis dahin Übergangsschritte zur Marktreife.
(mma)
-
Künstliche Intelligenzvor 3 MonatenEmpfehlungsalgorithmen bei TikTok erklärt: Die Maschine hinter dem Endlos‑Feed
-
Künstliche Intelligenzvor 3 MonateniX-Workshop Angriffsziel lokales AD − Schwachstellen finden und beheben
-
Künstliche Intelligenzvor 3 Monaten„Don’t Starve Elsewhere“: Survival‑Hit kehrt nach zehn Jahren zurück
-
Künstliche Intelligenzvor 3 MonatenKine‑Exakta: Die erste Spiegelreflexkamera fürs Kleinbild
-
Künstliche Intelligenzvor 2 MonatenWeitere Entlassungswelle bei Disney: Bis zu 1000 Mitarbeiter betroffen
-
Künstliche Intelligenzvor 2 Monaten
xTool P3 im Test: CO₂-Laser mit 80 Watt schneidet und graviert auch Acryl
-
Social Mediavor 2 MonatenMetas neuer Creative Setup Workflow: Was sich wirklich ändert – und warum das nicht nur eine UI-Frage ist!
-
Apps & Mobile Entwicklungvor 2 MonatenMega-GPUs für Nvidia, AMD & Co: TSMC zeigt CoWoS-Package mit >11.600 mm² & 24 × HBM5E
