Connect with us

Entwicklung & Code

Fedora plant KI-Linux-Desktop | heise online


close notice

This article is also available in
English.

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

.

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)



Source link

Verwandte Themen:
Weiterlesen

Entwicklung & Code

Red Hat OpenShift: Souveräne KI, Migration und Virtualisierung


Weiterlesen nach der Anzeige

Red Hat hat mehrere neue Funktionen für OpenShift angekündigt. Ein Schwerpunkt liegt auf souveränen KI- und Cloud-Diensten. Dafür setzt Red Hat auf einen Service-Provisioning-Ansatz, über den Partner und Kunden unter anderem virtuelle Maschinen, Cluster, GPU-Ressourcen und Inferenzdienste innerhalb kontrollierter Betriebsgrenzen bereitstellen können.

Im Vordergrund steht das Betriebsmodell: Wer betreibt die Plattform, wo verbleiben Daten und Telemetrie, und wie entstehen Compliance-Nachweise? Damit Code, Betriebsdaten und Workloads innerhalb definierter Grenzen bleiben, verweist Red Hat unter anderem auf hardwaregestützte Confidential Containers, vertrauliche Hosts, Trusted-Supply-Chain-Funktionen sowie OpenShift Dev Spaces.

Darüber hinaus plant Red Hat für Europa eine regionale Bereitstellung von RHEL-Software- und Update-Streams, damit Kunden und Partner Red Hat Enterprise Linux lokal beziehen können. Das soll die Resilienz kritischer Softwarelieferketten erhöhen und überregionale Abhängigkeiten reduzieren. Zudem verweist Red Hat auf seinen Confirmed Sovereign Support in der EU, also ein Supportmodell mit regional kontrollierten Eskalations- und Betriebsprozessen.

Bare Metal as a Service, Entwickler-Support und Trusted Environments

Mit Bare Metal as a Service will Red Hat künftig auch physische Server über OpenShift verwalten. Damit entwickelt sich OpenShift weiter in Richtung einer allgemeinen Infrastrukturplattform – nicht nur für Cloud-native Anwendungen, sondern auch für klassische Workloads und Hardware in einem einheitlichen Betriebsmodell.

Für Entwickler wurde der Red Hat Desktop angekündigt. Die Umgebung soll Linux-, Windows- und Mac-Clients mit Red-Hat-Plattformen verbinden und sichere Entwicklungsprozesse vom lokalen Rechner bis in produktive OpenShift- und KI-Umgebungen unterstützen. Als Grundlage dient Podman Desktop, ergänzt um einen Katalog gehärteter Images. Entwickler sollen geprüfte Images damit leichter lokal nutzen und anschließend auf OpenShift bereitstellen können.

Hinzu kommen eine Trusted Software Factory und Trusted Libraries. Die Factory basiert auf CNCF-Technologien und Red-Hat-Best-Practices für Software-Lieferketten. Sie soll Unternehmen helfen, Build-Prozesse mit Provenance, Attestierung und nachvollziehbaren Artefakten aufzubauen. Trusted Libraries liefern kuratierte und kontinuierlich gepflegte Bibliotheken. Diese werden laut Red Hat in einer SLSA-Level-3-Infrastruktur gebaut und enthalten vollständige Provenance- und Attestation-Informationen.

Weiterlesen nach der Anzeige

Dauerthema: Migration und Virtualisierung

Der neue Migration Advisor soll dabei helfen, vorhandene Virtualisierungsumgebungen zu bewerten, bevor die Workloads auf OpenShift verschoben werden. Das Werkzeug basiert auf den Erfahrungen aus dem Virtualization Migration Assessment. Kunden können damit ihre Umgebung passiv analysieren und erhalten frühzeitig Hinweise zu Aufwand, Risiken und Migrationspfaden.

Die OpenShift Virtualization wird um eine Funktion zur Live-Migration virtueller Maschinen zwischen Kubernetes-Clustern ergänzt. Außerdem sollen neue Right-Sizing-Funktionen helfen, Speicher- und Rechenressourcen besser auszunutzen. „Die meisten Kunden wollen die vorhandene Infrastruktur dichter auslasten, statt sofort neue Systeme zu beschaffen, OpenShift soll deshalb künftig stärker anzeigen, wo virtuelle Maschinen überdimensioniert sind und wo sich Clusterkapazitäten effizienter nutzen lassen“, sagt Mike Barrett, Vice President and General Manager of Red Hat Hybrid Platforms, über die Hintergründe der neuen Features.

Virtualisierung ist für Red Hat inzwischen ein wichtiger Geschäftsbereich. Auf dem Summit wurde ein Wachstum von 417 Prozent bei virtuellen Maschinen mit OpenShift Virtualization im Zeitraum 2025/2026 genannt. Barrett sprach zudem von 70 Prozent mehr Kundenkonten in diesem Bereich. Diese Zahlen zeigen, dass das Angebot im Markt gut ankommt – besonders dort, wo Unternehmen nach Alternativen oder Ergänzungen zur klassischen Virtualisierung suchen.


(fo)



Source link

Weiterlesen

Entwicklung & Code

Software Testing: Der Blaue Engel für Software


In diesem Interview sprechen Richard Seidl und Anita Schüttler über den Blauen Engel für Software. Das Umweltlabel, bekannt von Papierprodukten, gibt es jetzt auch für Software und soll Ressourceneffizienz fördern. Wie Unternehmen an die begehrte Auszeichnung kommen, warum sie mehr ist als ein grüner Stempel und welche Herausforderungen hinter dem Zertifizierungsprozess stecken, wird offen diskutiert. Anita Schüttler teilt mit, wie ihre eigene Software zertifiziert wurde, welche Kosten und Aufwände damit verbunden sind und warum das Umweltzeichen sogar Marketingvorteile bringt.

Weiterlesen nach der Anzeige

Anita Schüttler ist Informatikerin und Expertin für digitale Nachhaltigkeit, Green Software und Circular Economy. Als Head of IT Sustainability bei neuland, Bremen, berät und unterstützt sie Unternehmen dabei, die Umweltauswirkungen ihrer digitalen Produkte zu verstehen und zu reduzieren. Sie ist zudem Co-Vorsitzende des Bundesverband Green Software, Auditorin für den Blauen Engel für Software und ein Champion der Green Software Foundation.

Software-Testing im Gespräch

Bei diesem Format dreht sich alles um Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste schauen sich Dinge an, die mehr Qualität in die Softwareentwicklung bringen.

Die aktuelle Ausgabe ist auch auf Richard Seidls Blog verfügbar: „Der Blaue Engel für Software erklärt – Anita Schüttler“.


(mai)



Source link

Weiterlesen

Entwicklung & Code

C++-Entwickler nutzen KI häufiger, bleiben aber skeptisch


C++-Programmiererinnen und -Programmierer setzen immer häufiger KI-Assistenten für ihre Projekte ein. Das hat die Standard C++ Foundation in ihrer jüngsten Umfrage festgestellt. Deutlich wurde aber auch: Das Misstrauen gegenüber künstlicher Intelligenz ist immer noch hoch.

Weiterlesen nach der Anzeige

Als Grund dafür geben 77,5 Prozent der Befragten an, dass KI fehlerhaften Output liefert, während knapp 70 Prozent den von künstlicher Intelligenz generierten Antworten generell kein Vertrauen entgegenbringen. Für rund 51 Prozent der Teilnehmenden leistet KI hinsichtlich Kontextverständnis zu wenig. Bedenken bezüglich Datensicherheit melden 49,5 Prozent an und für 37,4 Prozent ist der Einsatz von KI vor allem eine Kostenfrage.

Mehr KI, vor allem mit Copilot und ChatGPT

Dennoch werden KI-Assistenten im C++-Umfeld deutlich häufiger eingesetzt als letztes Jahr, auch wenn in sämtlichen von der Umfrage berücksichtigten Programmier-Aufgabenbereichen weiterhin die „Nein“-Sager dominieren.


Umfrage: Der Einsatz von KI im C++-Programmierumfeld

Umfrage: Der Einsatz von KI im C++-Programmierumfeld

Die meisten Umfrage-Teilnehmer sprechen sich gegen den Einsatz von KI im C++-Umfeld aus.

(Bild: Standard C++ Foundation)

Beim Schreiben von Code greifen nun jedoch 39,1 Prozent der Befragten ein- bis mehrmals pro Woche zum KI-Tool, während es 2025 noch 30,9 Prozent waren. Beim Schreiben von Tests sind es 32,2 statt vormals 20 Prozent, beim Debugging steigt der Anteil auf 23,2 Prozent (2025: 11,5 %) und beim Ermitteln von Performance-Problemen hat sich der Anteil mit etwa 14 Prozent ebenfalls mehr als verdoppelt (2025: 6,0 %).

Mit 53,4 Prozent der Nennungen landet GitHub Copilot auf Platz eins der am häufigsten verwendeten codespezifischen KI-Assistenten. Es folgen Claude Code mit 44,2 Prozent und OpenAI Codex mit 14,3 Prozent. Unter den nicht-codespezifischen KI-Tools führen ChatGPT mit 53,4 Prozent und Google Gemini mit 39 Prozent. Kaum genutzt werden dort Grok (6,3 %) und Perplexity (4,2 %).

Weiterlesen nach der Anzeige

Beliebteste C++-Werkzeuge: VS Code und GCC

Laut Umfrage ordnen sich die meisten C++-Projekte den Kategorien Entwicklertools (26,1 %), Hardware/IoT (24,7 %), Gaming (23,5 %) sowie Utility-Apps (21,6 %) zu. Umgesetzt werden sie überwiegend mit CMake, das 81,9 Prozent der Befragten als bevorzugtes Build-Tool nennen. Ebenfalls hoch im Kurs stehen Ninja mit 46,2 Prozent, MSBuild mit 33,5 Prozent und Make/nmake mit 30,7 Prozent.

Bei den IDEs greifen rund 40 Prozent der Befragten zu Visual Studio Code, das mit dem Februar-Update neue Features für die KI-Agenten-Konfiguration erhielt. Als Compiler kommt überwiegend GCC zum Einsatz (53,1 %).

Danach gefragt, was sie an C++ ändern würden, nennen viele Teilnehmer unter anderem ein standardisiertes Paket- und Abhängigkeitsmanagement, kürzere Build-Zeiten, die Unterstützung von ABI- und Kompatibilitätsbrüchen sowie mehr Sicherheit durch strengere Defaults.

Die Umfrage der Standard C++ Foundation startete am 21. April dieses Jahres. Sie lief eine Woche lang und sammelte Feedback von 1434 Teilnehmerinnen und Teilnehmern, was einem Anstieg von 38 Prozent gegenüber 2025 entspricht (1036 Personen). Davon attestieren sich 80,6 Prozent eine C++-Programmiererfahrung von mindestens sechs Jahren. Mehr als zehn Jahre Erfahrung geben 60,5 Prozent an und bei fast 33 Prozent der Teilnehmer sind es mehr als 20 Jahre. Auf der Webseite der gemeinnützigen Stiftung steht die vollständige Umfrage mit vielen weiteren Details zum Download bereit.


(mro)



Source link

Weiterlesen

Beliebt