Schon im Zuge der Ankündigung von Gemini Intelligence während der Android Show I/O Edition deutete Google mit dem Satz an „Das Beste von Gemini auf unseren modernsten Geräten“, dass die On-Device-KI hohe Anforderungen an die Geräte haben wird. Konkrete Details dazu hat Google in den Fußnoten hinterlassen: Denen zufolge sind die Pixel-9-Serie und selbst das Galaxy Z Fold 7 vom vergangenen Jahr aus dem Rennen – offenbar selbst das Xiaomi 17 Ultra.

„Höchste Leistungs- und Systemanforderungen“

„Die Funktionen von Gemini Intelligence sind nur auf Android-Geräten verfügbar, die die höchsten Leistungs- und Systemanforderungen erfüllen“, schreibt Google in der Fußnote und gibt beim Arbeitsspeicher an, dass Geräte mindestens 12 GByte RAM verbaut haben müssen. Damit sind schon die meisten Einsteiger- und Mittelklasse-Geräte raus; auch Googles eigene a-Serie, die mit 8 GByte RAM versehen ist, kann Gemini Intelligence nicht ausführen.

Eine weitere Hürde ist der Prozessor: Google schreibt hier nur „qualifiziertes SOC“ und in Klammern „Flaggschiff-Chip“. Hier dürfte der Hersteller letztlich Qualcomms und MediaTeks Topmodelle – sowie die hauseigenen Tensor-Chips der aktuellen und kommenden Generation – meinen.

Videos by heise

Das ist aber nicht alles: Denn auch hinsichtlich der erforderlichen On-Device-KI-Version legt Google die Messlatte hoch an: Es muss mindestens das Modell Gemini Nano v3 oder neuer unterstützt werden. Hier trennt sich dann auch bei den performanteren Modellen die Spreu vom Weizen: Auf der Entwicklerwebseite zu GenAI-APIs von ML Kit listet Google auf, welche Geräte mit v3 kompatibel sind und welche auf der älteren Version 2 verharren.

Lediglich Smartphones aus dem Jahr 2025 und neuer sind mit Gemini Nano v3 kompatibel – das heißt unter anderem, dass Googles Pixel-9-Serie, Honors Magic V5, Magic 7 und Magic 7 Pro sowie das OnePlus 13 und weitere raus sind. Aber auch Geräte des vergangenen Jahres und selbst topaktuelle Geräte sind der Liste zufolge nicht mit Gemini Intelligence kompatibel: So sind etwa Samsungs Galaxy Z Fold 7 als auch die 2026er-Geräte Xiaomi 17 und 17 Ultra und eine ganze Reihe weiterer Xiaomi-Modelle nicht in der Lage, Gemini Intelligence auszuführen.

Updategarantie, sichere Virtualisierung

Abseits der hard- und softwareseitigen Anforderungen macht Google für Gemini Intelligence klare Vorgaben hinsichtlich der Updates: Wenn Hersteller die neue KI auf ihren Geräten nutzen wollen, müssen diese mindestens 5 Jahre lang Android-Updates und sechs Jahre lang quartalsweise Sicherheitspatches garantieren.

Lesen Sie auch

Android-Sicherheit: Google führt KI-basierte Echtzeit-Überwachung ein

Google erweitert Android-Sicherheitsfunktionen gegen Gerätediebstahl

Galaxy S26 zuerst: Samsung öffnet One UI 9 Beta

Android Show: Google veranstaltet eigenes Event für Android 17

Xiaomi öffnet vier Topmodelle für Android-17-Testphase

Top 10: Die beste Sportuhr im Test

Top 10: Bester Android-Auto-Wireless-Adapter – Smartphone kabellos verbinden

Top 7: Die beste Kompressor-Kühlbox im Test

Kommentar: Das Ende der SaaS-Gelddruckmaschine

2026-05-16T08:30:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Top-Investor TCI stößt Microsoft-Aktien ab. Das ist weit mehr als ein Börsenmanöver: KI bedroht das Geschäftsmodell der gesamten Softwareindustrie.

221

(Bild: Moritz Förster / KI / iX)

16.05.2026, 10:30 Uhr

Lesezeit: 4 Min.

iX Magazin

Von

Moritz Förster

Als der Hedgefonds TCI jüngst seinen Microsoft-Anteil drastisch zusammenstrich, klang das erst einmal nach einer dieser Meldungen, die im Strom der Finanznachrichten untergehen. Doch diesmal lohnt der zweite Blick. TCI-Gründer Chris Hohn gehörte jahrelang zu den großen Profiteuren des Microsoft-Booms, fast 400 Prozent Kursgewinn seit 2017 sprechen eine deutliche Sprache. Wenn ausgerechnet so ein Investor kalte Füße bekommt, geht es nicht um schwache Quartalszahlen. Dann steht die ökonomische Grundlage der Softwareindustrie zur Debatte.

Moritz Förster schreibt seit 2012 für die iX und heise online. Er betreut neben dem iX-Channel den Bereich Arbeitsplatz.

Die Sprengkraft der KI-Revolution liegt nicht darin, dass sie eine bestimmte Software ersetzt. Sondern darin, dass sie das Geschäftsmodell dahinter pulverisiert. Willkommen in der SaaSpocalypse.

Das Geschäftsmodell hinter der Lizenzmaschine

Zwei Jahrzehnte lang funktionierte Unternehmenssoftware nach einem stabilen Prinzip. Jede Aufgabe bekam ihre eigene Anwendung: Texte in Word, Tabellen in Excel, Kundendaten in Salesforce, Bildbearbeitung in Photoshop. Unternehmen zahlen Lizenzen pro Nutzer, pro Arbeitsplatz, pro Monat. Je tiefer die Software in die Arbeitsabläufe einsickerte, desto verlässlicher sprudelten Umsatz und Margen. Der Wert lag dabei nie nur im Programmcode, sondern in einer schlichten Tatsache: Menschen mussten ihre Arbeit innerhalb dieser Anwendungen erledigen.

Genau diese Logik bröckelt nun. KI-Assistenten verändern nicht bloß einzelne Funktionen, sondern die Schnittstelle zur Arbeit selbst. Wer heute Copilot, Gemini oder ChatGPT nutzt, klickt sich nicht mehr durch klassische Menüs. Stattdessen formuliert der Nutzer Ziele: „Fasse die wichtigsten Punkte aus diesen Mails zusammen.“ „Bau eine Präsentation aus den Quartalszahlen.“ Die Arbeit wandert Schritt für Schritt vom Menschen zur Maschine. Und je besser diese Systeme werden, desto unwichtiger wird die Anwendung im Hintergrund.

Microsoft sägt am eigenen Ast

Das zeigt sich ausgerechnet bei Microsoft selbst. Seinen Copilot präsentiert der Konzern längst nicht mehr als Zusatzfunktion für Word oder Excel. Das Ziel ist ein Assistent, der quer über alle Anwendungen arbeitet. Der Nutzer redet mit dem Agenten – nicht mehr mit dem Programm. Wird die KI zur Bedienoberfläche der Wissensarbeit, verliert die klassische Anwendung ihre Rolle als zentraler Zugangspunkt. Sie wird zur Infrastruktur.

Aus Nutzersicht klingt das verlockend. Für die Softwareindustrie ist es eine Bedrohung. Denn Software-as-a-Service-Modelle leben davon, dass jeder Mitarbeiter Zugang zu einzelnen Anwendungen braucht. KI-Agenten lösen diese Kopplung auf. Warum Hunderte Vollzugänge bezahlen, wenn ein paar Agenten einen Großteil der Arbeit erledigen?

Videos by heise

Die Börse handelt bereits die nächste Ära

Die Nervosität an den Börsen kommt nicht von ungefähr. Microsoft, Salesforce, Adobe und Oracle verdienen weiterhin Milliarden. Aber die Zweifel wachsen, ob die fetten Margen der SaaS-Ära dauerhaft Bestand haben. Bemerkenswert dabei: Die Disruption entsteht innerhalb der Plattformen selbst. Microsoft demonstriert mit Copilot genau die Entwicklung, die das klassische Softwaremodell untergräbt. Der Konzern treibt die Entkopplung von Nutzer und Anwendung selbst voran.

Börsen handeln spekulative Erwartungen, keine Gegenwart. Für Investoren genügt die Aussicht auf sinkende Preissetzungsmacht, um Bewertungen neu zu sortieren. Die Machtfrage lautet deshalb nicht mehr, wer die beste Software baut. Sondern wer künftig die Bedienoberfläche der Arbeit kontrolliert.

Das erklärt, warum TCIs Teilverkauf mehr ist als ein gewöhnliches Börsensignal. Der Fonds stößt Microsoft-Aktien nicht ab, weil Office schwächelt oder Azure plötzlich Verluste schreibt. TCI reagiert auf eine tiefere Unsicherheit: KI löst eben nicht einfach Programme ab. Sie ersetzt die ökonomische Logik, auf der die Softwareindustrie aufgebaut wurde. Und genau deshalb droht die SaaSpocalypse.

Bei diesem Kommentar handelt es sich um das Editorial der iX 6/2026, die am 22. Mai erscheint.

(fo)

Top 10: Die beste Sportuhr im Test

Top 10: Bester Android-Auto-Wireless-Adapter – Smartphone kabellos verbinden

Top 7: Die beste Kompressor-Kühlbox im Test

Developer-Häppchen fürs Wochenende – kleinere News der Woche

2026-05-16T07:15:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Kleine, aber interessante Meldungshäppchen vom News-Buffet zu PSF, Python 3.15, GitHub, Wicket, Ditto, Hugging Face, GNUstep, MantisBT und Docker.

(Bild: Natalia Klenova / Shutterstock.com)

16.05.2026, 09:15 Uhr

Lesezeit: 3 Min.

Developer

Von

In unserem leckeren Häppchen-Überblick servieren wir alles, was es zwar nicht in die News geschafft hat, wir aber dennoch für spannend halten:

Mit einem neuen Strategieplan will die Python Software Foundation (PSF) die Ausrichtung der Stiftung für die nächsten fünf Jahre festlegen. Ein vollständiger Entwurf soll Anfang Juni erscheinen, um Community-Feedback zu sammeln. Darauf aufbauend möchte die PSF den finalen Strategieplan dann im Juli verabschieden.
Die Feature‑Freeze‑Phase für Python 3.15 ist mit Python 3.15.0 Beta 1 gestartet. Die erste von vier geplanten Beta-Versionen bringt unter anderem lazy imports für schnellere Starts, die neuen built-in-Datentypen frozendict und sentinel sowie einen performanteren JIT‑Compiler.
GitHub hat Enterprise Live Migrations (ELM) als Public Preview vorgestellt. Mit ELM lassen sich Repositories von GitHub Enterprise Server nahezu ohne Ausfallzeiten auf GitHub Enterprise Cloud mit Datenresidenz (GHE.com) umziehen. Der Cut-over soll innerhalb von Minuten abgeschlossen sein.

(Bild: joeycheung / Adobe Stock)

Die Online-Konferenz Mastering GitOps von iX und dpunkt.verlag am 25. Juni 2026 widmet sich in diesem Jahr praxisnah Schwerpunkten wie dem Einsatz von GitOps im Platform Engineering und dem Rendered-Manifests-Pattern mit OCI-Registries. Bis zum 3. Juni sind noch Frühbuchertickets verfügbar.

Das Webframework Wicket ist in Version 10 erschienen und basiert nun auf Java 17, ist aber auch mit Java 21 kompatibel. Darüber hinaus beteiligt sich Wicket am OpenJDK Quality Outreach, um die Kompatibilität sowohl mit der neuesten OpenJDK-Version als auch mit der Early-Access-Varianten zu verbessern. Für die Migration von Version 9 nutzt Wicket OpenRewrite.
Mit Version 3.9 verbessert Ditto die Mandantenfähigkeit der IoT-Plattform: Anwenderinnen und Anwender müssen Policies nun nicht mehr duplizieren, sondern sie lassen sich in Namespaces gruppieren. Auch Authentifizierungen lassen sich über die Namespaces organisieren.
Der Blog RedMonk hat die Verteilung von Lizenzen bei Hugging Face untersucht. Ganz vorne stehen die Permissive-Lizenzen Apache 2 und MIT. Bei den Creative Commons führt die nicht kommerzielle cc-by-nc-4.0.

Lesen Sie auch

C-Libraries in Java nutzen 2: Funktionen mit veränderlichen Parametern

Top 10: Die beste Sportuhr im Test

Top 10: Bester Android-Auto-Wireless-Adapter – Smartphone kabellos verbinden

Top 7: Die beste Kompressor-Kühlbox im Test

Code lesen statt Code schreiben: Die unterschätzte Senior-Disziplin

2026-05-16T07:00:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Joel Spolsky warnte schon 2000 davor, Code lieber neu zu schreiben als zu lesen. Mit LLMs wird seine Diagnose zur drängenden Frage für jedes Team.

179

(Bild: Gorodenkoff/Shutterstock.com)

16.05.2026, 09:00 Uhr

Lesezeit: 14 Min.

Developer

Von

Golo Roden

Im April 2000 veröffentlichte Stack-Overflow-Gründer Joel Spolsky einen Aufsatz mit dem Titel „Things You Should Never Do, Part I“. Anlass war die Entscheidung von Netscape, den Code des damaligen Browsers von Grund auf neu zu schreiben, statt den vorhandenen weiterzuentwickeln.

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.

Spolskys These: Diese Entscheidung sei der schlimmste strategische Fehler, den eine Softwarefirma machen könne. Sie beruhe auf einem fundamentalen Missverständnis darüber, was Programmierarbeit eigentlich ist. Programmiererinnen und Programmierer schrieben lieber neu, weil das Lesen fremden Codes mühsam sei und sich das Schreiben produktiv anfühle. Doch dieser Eindruck täusche. Die Verlockung, neu anzufangen, sei eine der teuersten Versuchungen der Branche.

Über 25 Jahre später hat dieser Text nichts von seiner Aktualität verloren. Im Gegenteil. Mit dem Auftauchen von Large Language Models (LLM) hat sich die Asymmetrie zwischen Schreiben und Lesen so verschoben, dass die Frage akut wird, ob wir die eigentliche Senior-Disziplin der Softwareentwicklung systematisch unterschätzen. Das Tippen ist nicht das, was Teams in den nächsten Jahren ihren Atem rauben wird. Das Lesen ist es. In diesem Beitrag möchte ich zeigen, warum das so ist, woher die Asymmetrie kommt, wie sie sich durch generative KI verschärft und wie aus einer beiläufigen Begleitfähigkeit eine eigenständige Disziplin werden müsste.

Der eigene Code wird nach drei Wochen zu fremdem Code

Beim Schreiben hat man alles gleichzeitig im Kopf: die Anforderung, das Datenmodell, die geplante Architektur, die Stelle, an der man gerade arbeitet, die Annahmen, die man trifft, die Trade-offs, die man eingeht. Diese mentale Gesamtsicht macht das Schreiben schnell. Sie ist gleichzeitig das, was beim Lesen fehlt.

Wer drei Wochen später denselben Code wieder vor sich hat, ohne den Kontext mitzubringen, muss diese Gesamtsicht rekonstruieren. Variablennamen geben Hinweise, Tests sagen mehr, ein Pull-Request-Kommentar liefert im Bestfall den fachlichen Anlass, eine Commit-Message mit Glück die letzte Begründung. Die eigentliche Intention, das gedachte Modell, die verworfenen Alternativen, all das ist verloren. Rekonstruieren kostet Zeit und Konzentration, und beides ist teurer als das Schreiben.

Videos by heise

Spolskys Anekdote ist deshalb so anschaulich, weil sie diese Asymmetrie auf Organisationsebene zeigt. Bei Netscape stand man vor einer alten Codebasis, die niemand mehr durchschauen wollte. Die Verlockung lag nahe, das Ganze einfach neu zu schreiben. Das Ergebnis ist bekannt: drei Jahre Stillstand, ein verlorener Browser-Markt, eine Firma im Niedergang. Der vermeintlich einfachere Weg war der teuerste.

Auf individueller Ebene zeigt sich dasselbe Muster täglich. Es zeigt sich in Stack-Overflow-Antworten, die statt der Frage einen anderen Lösungsansatz vorschlagen. Es zeigt sich in Kolleginnen und Kollegen, die Refactorings vorschlagen, ohne den vorhandenen Code wirklich verstanden zu haben. Es zeigt sich in der eigenen Versuchung, ein Modul lieber zu ersetzen als zu verbessern. Lesen ist und bleibt unbequem.

LLMs kippen die Bilanz endgültig

Ein modernes LLM erzeugt mehrere Hundert Zeilen Code in der Zeit, in der eine Person diese Zeilen einmal überfliegen kann. Generieren ist billig geworden. Token sind billig, Wartezeiten kurz, und das mentale Modell für die Aufgabe ist auf das Formulieren eines Prompts geschrumpft. Der Aufwand auf der Schreibseite ist faktisch zusammengebrochen.

Auf der Leseseite hat sich nichts geändert. Verstehen kostet noch immer das, was es immer gekostet hat: konzentrierte Aufmerksamkeit, Zeit, Geduld. Die menschliche Verarbeitungsgeschwindigkeit für Code liegt grob bei einigen Zeilen pro Minute, je nach Komplexität deutlich darunter. Diese Größenordnung lässt sich nicht durch Werkzeuge beschleunigen, weil sie an der menschlichen Kognition selbst hängt.

Das Resultat ist eine groteske Verschiebung. Wo früher eine Tagesarbeit etwa hundert Zeilen Code produzierte, die ein Reviewer in einer halben Stunde durchgehen konnte, kann heute eine Stunde Promptarbeit Tausende Zeilen erzeugen. Die zu verstehende Menge wächst dramatisch, die Geschwindigkeit des Verstehens bleibt konstant. Was früher ein Engpass beim Schreiben war, wird zum Engpass beim Verstehen.

Diese Verschiebung wird in vielen Diskussionen ignoriert. Man feiert die Produktivität auf der Generierungsseite und schweigt über die Bilanz, die sich auf der Leseseite auftut. Was nicht gelesen wird, wird nicht verstanden. Was nicht verstanden wird, wird nicht zuverlässig betrieben. Die Schulden verschieben sich nur in die Zukunft, sie verschwinden nicht.

Sichtbar wird das spätestens dort, wo Code-Review-Prozesse, die für die Geschwindigkeit der Vor-LLM-Ära konzipiert waren, plötzlich mit Pull-Requests konfrontiert sind, deren Umfang ein menschlicher Reviewer in einem ganzen Tag nicht durchdringen könnte. Die Reaktion ist meistens nicht eine vertiefte Auseinandersetzung, sondern ein verkürztes Daumen-hoch. Damit verlagert sich der Code-Review von einem inhaltlichen zu einem zeremoniellen Schritt, und genau in dieser Verlagerung entstehen die Probleme, die später teuer werden.

Die Abhängigkeitsspirale

Eine ambitionierte Schule propagiert, die Beschäftigung mit Code werde überflüssig: Mit genug Skills, Harness-Engineering und einer präzisen Markdown-Spezifikation lasse sich die Arbeit vollständig auf die Spec-Ebene verlagern. Der generierte Code sei eine Implementierungsfrage, die niemand mehr ansehen müsse. Diese Vorstellung wird mit Anlauf gegen eine Wand laufen.

Wer Code nur generiert, ohne ihn zu lesen, hat von Anfang an fremden Code vor sich. Reviewen geht nicht, Fehler suchen geht nicht, beides setzt Verstehen voraus. Mit jeder weiteren Generierung wächst die Codebasis schneller, als sie sich durchdringen lässt. Die Lücke zwischen „vorhanden“ und „verstanden“ öffnet sich in atemberaubender Geschwindigkeit, und mit ihr die Anzahl der Stellen, an denen man später fragen muss, was hier eigentlich passiert.

Die einzige verbliebene Instanz, die diesen Code noch erklären, prüfen oder reparieren kann, ist die KI selbst. Damit ist man ironischerweise auf genau das System angewiesen, das die Lage herbeigeführt hat. Aus einem Werkzeug wird eine Abhängigkeit, aus einer Beschleunigung eine Falle. Wer keine eigene Verstehenskompetenz aufbaut, hat nur noch eine externe und entscheidet über diese externe Kompetenz nicht mehr selbst.

Dieses Muster ist nicht neu, neu ist nur seine Geschwindigkeit. Ein Team besitzt eine unzugängliche Codebasis nicht mehr. Im klassischen Fall geschah die Unzugänglichkeit über Jahre, durch personelle Wechsel und unzureichende Dokumentation. Im KI-gestützten Fall kann das innerhalb weniger Monate geschehen, weil die Generierungsgeschwindigkeit die Aufnahmegeschwindigkeit hoffnungslos übersteigt.

Der typische Auslöser ist nicht spektakulär. Ein Bug taucht in Produktion auf, niemand im Team versteht den betroffenen Code, also befragt man die KI. Die KI liefert eine Erklärung und einen Fix, beides plausibel, beides ungeprüft. Im günstigen Fall stimmt es. Im weniger günstigen baut man neue Schulden auf alte und merkt es erst, wenn der nächste Bug genau in dieser Schicht entsteht. Aus Reparatur wird Übermalung.

Was zunächst wie eine Befreiung wirkt, ist also eine Verlagerung der Last. Statt selbst zu schreiben, formuliert man Prompts. Statt selbst zu verstehen, fragt man die KI. Beides scheint produktiv. Beides erodiert die Souveränität über die eigene Codebasis.

Top 10: Die beste Sportuhr im Test

Top 10: Bester Android-Auto-Wireless-Adapter – Smartphone kabellos verbinden

Top 7: Die beste Kompressor-Kühlbox im Test

Fedora Hummingbird Linux: Neue Container-basierte Distribution

2026-05-15T13:37:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Fedora Hummingbird Linux ist eine vollständig Container-basierte Distribution, die auf rpm-ostree und bootc aufbaut.

(Bild: Moritz Förster / KI / iX)

15:37 Uhr

Lesezeit: 2 Min.

iX Magazin

Von

Udo Seidel

Neben viel KI und Virtualisierung gab es auf dem Red Hat Summit auch Neuigkeiten im Bereich der Linux-Distribution: Fedora Hummingbird Linux – auch HummingbirdOS genannt – ist da. Hierbei handelt es sich um eine vollständig Container-basierte Distribution. Gleich mehrere bereits bekannte Projekte vereinen sich hier: Zum einen natürlich Software aus dem Fedora-Universum, aber auch rpm-ostree, das von Fedora CoreOS und auch Silverblue bekannt ist.

Statt über einen traditionellen Paketmanager kommen Software-Aktualisierungen über sogenannte Transaktionen in das System. Das ist vergleichbar mit einem Git-Commit mit zwei Zuständen: dem aktuellen und dem nächsten. HummingbirdOS greift ebenfalls auf das bootc-Projekt zurück. Dabei geht es um sogenannte „bootfähige“ Container, die mit einem Linux-Kernel und systemd ausgestattet sind. Sie können als normale Container laufen oder über bootc wie ein klassisches Linux starten.

Die letzte Zutat für das neue Fedora Linux ist das Hummingbird-Projekt. Es stellt minimalistische und gehärtete Container bereit. Letzteres bedeutet, dass es idealerweise keine bekannten ungepatchten Sicherheitslücken bezüglich der installierten Software gibt. Ziel ist, dass jeder Container nur eine Funktion hat.

Videos by heise

HummingbirdOS ausprobieren

Fedora Hummingbird Linux ist noch in einem frühen Stadium. Interessierte können sich aber schon ein Abbild aus der Container-Registry der Hummingbird-Community herunterladen. Ferner kann man das System auch als virtuelle Maschine betreiben. Dazu muss man das Container-Abbild per bootc-image-builder umwandeln. Das Resultat ist entweder eine virtuelle Festplatte oder Installations-CD. Erstere bindet der Anwender entweder in den Hypervisor oder Cloud-Account ein. Danach startet HummingbirdOS analog zu den anderen virtuellen Maschinen. Die Installations-CD benutzt das bekannte Werkzeug Anaconda.

Bei den von Red Hat angedachten Anwendungsfällen schließt sich der Bogen zurück zur KI. HummingbirdOS soll laut Ankündigung als Plattform für KI-Agenten dienen. Designbedingt bietet es aktuelle Software mit minimaler Angriffsfläche. Unterstützung für Nutzer ist über den „Cooperative Community Support“ geplant. Hier können zahlende Red-Hat-Kunden auch Hilfe für bestimmte Projekte außerhalb des Enterprise-Umfeldes bekommen.

Lesen Sie auch

Fedora plant KI-Linux-Desktop

Linux für Gamer: Bazzite 44 basiert auf Fedora 44

Linux-Distribution Fedora 44: KDE Plasma und Wayland im Fokus

Rust Coreutils 0.6 erreicht 96 Prozent GNU-Kompatibilität

Epochaler Wandel bei Textkonsolen von Linux im Werden

Top 10: Die beste Sportuhr im Test

Top 10: Bester Android-Auto-Wireless-Adapter – Smartphone kabellos verbinden

Top 7: Die beste Kompressor-Kühlbox im Test

.NET 11.0 Preview 4: Ein bunter Strauß von API-Erweiterungen

2026-05-15T12:20:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Die vierte Preview bringt neue Methoden in bestehenden Klassen der .NET-Basisklassenbibliothek sowie eine neue Konfigurationsdatei für Entity Framework Core.

(Bild: Pincasso / Shutterstock.com)

14:20 Uhr

Lesezeit: 13 Min.

Developer

Von

Dr. Holger Schwichtenberg

Die vierte Vorschauversion der kommenden .NET-Version 11.0 ist erschienen und steht zum Download bereit. Parallel dazu hat Microsoft auch die Version 11811.120 von Visual Studio 2026 Insiders veröffentlicht, die zum Entwickeln von .NET-11.0-Anwendungen benötigt wird. Alternativ ist eine Arbeit mit Visual Studio Code und dem im SDK mitgelieferten Kommandozeilencompiler möglich.

Dr. Holger Schwichtenberg hat Fachbücher zu .NET 10.0, C# 14.0, Blazor 10.0 und Entity Framework Core 10.0 veröffentlicht. Er arbeitet als Berater und Trainer bei www.IT-Visions.de.

Installation des .NET 11.0 SDK in der Version Preview 4

(Bild: King / stock.adobe.com)

Das ist neu in .NET 11.0: Dr. Holger Schwichtenberg und weitere Experten präsentieren am 17. November 2026 auf der Online-Konferenz betterCode() .NET 11.0 die Änderungen für Entwicklerinnen und Entwickler in .NET SDK, C# 15.0 und mehr. Bis zur Veröffentlichung des Programms sind vergünstigte Blind-Bird-Tickets verfügbar.

Viel Neues für den Prozessstart

Die Klasse System.Diagnostics.Process zur Verwaltung von Betriebssystemprozessen gibt es seit Version 1.0 des klassischen .NET Framework aus dem Jahr 2002. Prozesse startet man seitdem, indem man eine neue Instanz der Klasse erzeugt. Seit .NET Framework 2.0 (Jahr 2005) gibt es alternativ die statische Methode Process.Start(). 21 Jahre später ergänzt Microsoft nun weitere alternative statische Methoden zum Prozessstart: Process.Run() und Process.RunAsync() sowie Process.RunAndCaptureText() und Process.RunAndCaptureTextAsync(). Das letztgenannte Pärchen liefert ein ProcessTextOutput-Objekt, mit dem man direkt auf Standardausgabe (ProcessTextOutput), Standardfehlerausgabe (StandardError) und Rückgabewert (ExitStatus.ExitCode) zugreifen kann, mit deutlich weniger Programmcode als dies bei der alten Start()-Methode notwendig ist, siehe Listing.

Ein Abbruch des Kindprozesses ist über ein Cancellation-Token möglich. Anders als bei der Start()-Methode kehren alle neuen Methoden mit „Run“ im Namen erst zum Aufrufer zurück, wenn der Kindprozess beendet ist. Entwicklerinnen und Entwickler können dabei allerdings keine Ausgaben des Prozesses verarbeiten, während er läuft.

CancellationTokenSource cts = new CancellationTokenSource();
 
 ProcessTextOutput result = await Process.RunAndCaptureTextAsync(
     "robocopy.exe", [@"t:\Daten", @"t:\Daten_Backup", "/MIR", "/IS"], cts.Token);
 
 CUI.Print("Neuer Prozess mit ID #" + result.ProcessId + " ist beendet!");
 
 CUI.Line("StandardOutput");
 CUI.Print(result.StandardOutput);
 CUI.Line("StandardError");
 CUI.PrintError(result.StandardError);
 CUI.Line("ExitStatus");
 CUI.Print("Canceled? " + result.ExitStatus.Canceled);
 if (result.ExitStatus.HasValue && !result.ExitStatus.IsEmpty) PrintStatus(result.ExitStatus.ExitCode);

Listing 1: Einsatz der neuen Methode Process.RunAndCaptureTextAsync()

Lesen Sie auch

Union Types werden in .NET 11.0 Preview 3 endlich nutzbar

.NET 11.0 Preview 2 liefert asynchrone Runtime

Microsoft startet mit den Previews zu .NET 11.0

Top 10: Die beste Sportuhr im Test

Top 10: Bester Android-Auto-Wireless-Adapter

Top 7: Die beste Kompressor-Kühlbox im Test

GitHub stellt Copilot-Abrechnung auf Flex-Modelle um

2026-05-15T10:26:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Keine festen Token-Kontingente mehr und ein neuer Max-Tarif für Power-User: GitHub ändert sein Bezahlmodell für Copilot schon wieder.

(Bild: heise medien)

12:26 Uhr

Lesezeit: 3 Min.

Developer

Von

Manuel Masiero

GitHub stellt sein Abrechnungsmodell für Copilot abermals um. Ab dem 1. Juni setzen sich alle Bezahltarife, die für einzelne Entwicklerinnen und Entwickler konzipiert sind, aus zwei Bestandteilen zusammen: einer festen Menge an Token (den Base Credits) und einem Flex‑Kontingent. Letzteres will GitHub dynamisch an wirtschaftliche Faktoren wie die Modellkosten anpassen.

GitHub hatte bereits Ende April angekündigt, kostenlose Modelle aus den Copilot-Tarifen zu streichen. Jetzt folgt weitere Feinabstimmung, die als Reaktion auf das Feedback der Community zu verstehen ist, wie GitHub zu den Änderungen schreibt. Die Community fragte sich nämlich, ob das in den kostenpflichtigen Tarifen enthaltene Token-Kontingent ausreicht, wenn Anfang Juni die Umstellung auf verbrauchsbasierte Nutzung erfolgt.

Base Credits + Flex-Kontingent = AI Credits

Was es mit dem Flex‑Kontingent auf sich hat, beantwortet GitHub folgendermaßen: „Es passt sich an, wenn sich die wirtschaftlichen Rahmenbedingungen für KI verändern, einschließlich Modellpreisen, neuen Modellen und Effizienzverbesserungen.“ Die Base Credits, die sich 1:1 aus dem Abonnementpreis ergeben, bleiben dagegen immer gleich, so der Anbieter.

Das Flex‑Kontingent greift ab dem 1. Juni für die Tarife Pro und Pro+. Haben Entwicklerinnen und Entwickler die Base Credits ausgeschöpft, können sie aus dem Flex-Kontingent weitere Token beziehen. Beim Pro-Tarif summieren sich 1.000 Base Credits und ein derzeitiges Flex-Kontingent von 500 Credits zu einer monatlichen Gesamtmenge von 1.500 AI Credits. Für den Tarif Pro+ ergeben sich dementsprechend 7.000 AI Credits (3.900 Base + 3.100 Flex).

GitHub rechnet die Copilot-Tarife Pro und Pro+ ab dem 1. Juni nach einem Flex-Modell ab. Das gilt auch für den neuen Max-Tarif.

(Bild: Microsoft)

Das gleiche Abrechnungsschema wendet auch der neue Max-Tarif an, der ebenfalls ab Juni startet. Er richtet sich an diejenigen, die Copilot intensiv nutzen, schlägt mit 100 US-Dollar pro Monat zu Buche und umfasst 10.000 Base Credits sowie ein gleichwertiges Flex-Kontingent von weiteren 10.000 AI Credits.

Videos by heise

Fallback auf einfachere Modelle entfällt

Wurde der Credit-Rahmen ausgeschöpft, blockiert Copilot bis zum Start des nächsten Abrechnungszeitraums alle Anfragen, die Credits benötigen. Bislang konnte man automatisch auf ein günstigeres Modell zurückfallen, doch diese Möglichkeit entfällt mit dem neuen Tarifmodell. Immerhin lässt GitHub den Free-Tarif weiterhin unangetastet, mit derzeit 50 Premium-Anfragen und 2.000 Code-Vorschlägen pro Monat.

Nutzerinnen und Nutzer der bisherigen monatlichen Tarife müssen nichts weiter tun, die Umstellung erfolgt automatisch. Jährliche Verträge werden nicht auf das neue Modell umgestellt. Sie laufen bis zum Vertragsende noch nach dem bisherigen anfragenbasierten Preissystem, allerdings mit höheren Multiplikatoren für teurere Modelle.

(mro)

Top 10: Die beste Sportuhr im Test

Top 10: Bester Android-Auto-Wireless-Adapter

Top 7: Die beste Kompressor-Kühlbox im Test

Symphonia 0.6: Rust-Audioframework wird multimedial

2026-05-15T09:13:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Das Rust-Multimediaframework Symphonia 0.6 baut seine Architektur grundlegend um und bereitet sich auf künftige Video- und Untertitel-Unterstützung vor.

(Bild: Andrey VP/Shutterstock.com)

11:13 Uhr

Lesezeit: 4 Min.

iX Magazin

Von

Moritz Förster

Mit Version 0.6 baut das Rust-Multimediaframework Symphonia seine Architektur grundlegend um. Laut Maintainer steckt in der neuen Version Entwicklungsarbeit aus zwei Jahren. Sie soll das bislang primär auf Audio ausgelegte Framework auf künftige Video- und Untertitel-Unterstützung vorbereiten. Video- oder Subtitle-Decoder bringt Symphonia 0.6 zwar noch nicht offiziell mit – über die experimentellen Feature Flags exp-video-codecs und exp-subtitle-codecs sind allerdings bereits erste Prototypen möglich, die internen APIs und Datentypen wurden entsprechend erweitert. Auf Entwickler, die das Framework nutzen, kommen dadurch zahlreiche Breaking Changes zu.

Symphonia ist ein in Rust entwickeltes Multimedia-Framework mit Fokus auf Audio-Decoding, Container-Parsing und Metadatenverarbeitung. Das Open-Source-Projekt unterstützt unter anderem MP3, AAC, FLAC, MP4, Ogg/Vorbis sowie Matroska/WebM und versteht sich als speichersichere Alternative zu klassischen Multimedia-Bibliotheken für das Rust-Ökosystem. Zum Einsatz kommt Symphonia etwa in Audio-Playern, Medienwerkzeugen oder Streaming-Pipelines. Laut der offiziellen Symphonia-Dokumentation liegt ein Schwerpunkt auf „Safe Rust“ und modularen Komponenten.

Neue Architektur trennt Tracks und Codecs

Im Zentrum der neuen Version steht der Wechsel von einer audiozentrierten Architektur hin zu einem allgemeineren Multimedia-Modell. Dazu hat das Projekt zentrale Datentypen für Zeitstempel, Dauer und Zeitbasis neu entworfen. Außerdem trennt Symphonia Track-Informationen künftig sauberer von Codec-Parametern: Timing-Daten liegen nicht länger in den Codec-Strukturen, sondern in separaten Track-Metadaten. Das soll die Verarbeitung mehrerer Streams vereinfachen – etwa Audio, Video und Untertitel in einem Matroska-Container.

Neu ist außerdem ein Prioritätssystem für Decoder und Format-Reader. Anwendungen können damit bevorzugte Implementierungen registrieren und Fallbacks definieren. Das dürfte vor allem für modulare Medien-Stacks interessant sein, etwa wenn Hardware-Decoder Vorrang vor generischen Software-Decodern erhalten sollen.

Weniger Kopien, mehr Metadatenformate

Ein weiterer Schwerpunkt der neuen Version liegt auf effizienteren Datenpfaden. Decoder müssen die Paketdaten nicht mehr zwangsläufig kopieren, bevor sie sie verarbeiten. In Kombination mit externen Demuxern lassen sich so zusätzliche Speicheroperationen vermeiden – ein Zero-Copy-ähnlicher Ansatz, wie er in Hochleistungs-Medienpipelines verbreitet ist.

Bei den Metadaten verarbeitet Symphonia nun zusätzlich ID3v1-, APEv1- und APEv2-Tags und unterstützt Kapitelinformationen für Matroska, ID3v2 und Vorbis Comments. Bekannte Tags interpretiert das Framework dabei stärker typisiert: Eine Tracknummer liest es nicht mehr nur als Zeichenkette, sondern direkt als numerischen Wert (u64). Von dieser Typisierung profitieren etwa Medienbibliotheken oder automatische Sortierfunktionen.

Für Matroska-Container ergänzt Symphonia 0.6 außerdem Support für Attachments und Metadaten. Attachments kommen vor allem bei Untertiteln zum Einsatz, etwa um Schriftarten direkt in MKV-Dateien einzubetten. Solche Dateien finden sich häufig bei Anime-Releases oder bei aufwendig formatierten ASS-Untertiteln.

Videos by heise

Neu geschriebene Demuxer und SIMD ab Werk

Ferner listet das Projekt in den Release Notes zahlreiche Verbesserungen in den Bereichen Sicherheit und Stabilität auf. Den Matroska-Demuxer hat Maintainer Philip Deljanov vollständig neu geschrieben, Teile des MP4-Demuxers ebenfalls überarbeitet. Hinzu kommen zahlreiche Fehlerkorrekturen auf Basis von Fuzzing-Tests. Gerade Multimedia-Parser gelten traditionell als sicherheitskritisch, weil fehlerhafte Containerdateien Speicherfehler oder Abstürze auslösen können. Rust soll solche Risiken durch Speichersicherheit reduzieren.

Auch bei der Performance verspricht Symphonia Fortschritte. SSE-, AVX- und Neon-SIMD-Optimierungen sind nun standardmäßig aktiviert. SIMD (Single Instruction, Multiple Data) nutzt Vektorinstruktionen moderner CPUs, um mehrere Datenwerte parallel zu verarbeiten – ein typischer Ansatz bei Audio- und Video-Decodern. Laut Release Notes soll außerdem die Decoding-Leistung steigen und die Binärgröße sinken.

Genauere Formaterkennung und neue MSRV-Policy

Weitere Änderungen betreffen die Formaterkennung, die nun ein Punktesystem verwendet, um Fehlklassifizierungen zu vermeiden. Erkennt Symphonia ein Medienformat, reicht es die dabei gefundenen Metadaten künftig an den jeweiligen Format-Reader weiter. Auch die Implementierungen für AIFF und CAF haben die Entwickler überarbeitet.

Wegen der zahlreichen API-Änderungen verweist der Maintainer ausdrücklich auf den Guide für die Migration. Zudem führt das Projekt erstmals eine offizielle MSRV-Policy ein: Eine Anhebung der minimal unterstützten Rust-Version gilt künftig als Breaking Change. Eine vollständige Übersicht aller Neuerungen liefern die Release Notes zu Symphonia 0.6.0 auf GitHub.

Lesen Sie auch

Freitag: Ärztetag gegen Kassen-Kompetenzen, Inkognito-Chat mit KI bei WhatsApp

KI-Portierung: Claude schreibt Bun-Codebasis in Rust neu

Sourcecode-Editor Zed erreicht Version 1.0

Cross-Plattform-Applikationen mit Rust 3: Fachlichkeiten und Shell-Integration

KI-Automatisierung in Rust: OpenFang 0.6.0 ist da

Top 10: Die beste Sportuhr im Test

Top 10: Bester Android-Auto-Wireless-Adapter

Top 7: Die beste Kompressor-Kühlbox im Test

Neu in .NET 10.0 [23]: Neue LINQ-Operatoren LeftJoin() und RightJoin()

2026-05-15T07:47:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Ein Left (Outer) Join und ein Right (Outer) Join waren bisher schon in LINQ möglich. In .NET 10.0 gibt es dafür nun eigene Operatoren.

(Bild: Pincasso / Shutterstock.com)

09:47 Uhr

Lesezeit: 1 Min.

Developer

Von

Dr. Holger Schwichtenberg

Wie in den letzten .NET-Versionen auch, liefert Microsoft in .NET 10.0 wieder neue Operatoren für Language Integrated Query (LINQ), die bestehende Konstrukte vereinfachen. Dieses Mal sind es mit LeftJoin() und RightJoin() zwei elementare Operatoren, zum einen aus der Mengenlehre und zum anderen für relationale Datenbanken. Mehr dazu steht im zugehörigen Issue auf GitHub.

Dr. Holger Schwichtenberg ist technischer Leiter des Expertennetzwerks www.IT-Visions.de, das mit 53 renommierten Experten zahlreiche mittlere und große Unternehmen durch Beratungen und Schulungen sowie bei der Softwareentwicklung unterstützt. Durch seine Auftritte auf zahlreichen nationalen und internationalen Fachkonferenzen sowie mehr als 90 Fachbücher und mehr als 1500 Fachartikel gehört Holger Schwichtenberg zu den bekanntesten Experten für .NET und Webtechniken in Deutschland.

Tatsächlich waren diese Operationen bisher in LINQ bereits möglich, allerdings nur umständlich über eine Gruppierung mit GroupJoin() und SelectMany() sowie DefaultIfEmpty(). Die neuen Methoden LeftJoin() und RightJoin() vereinfachen den Einsatz, wie folgender Code am Beispiel eines Join zwischen den Klassen Company und Website zeigt:

public void LeftRightJoin()
{
 CUI.Demo();
 
 Company[] companies =
 [
   new Company{ ID = 1, Name = "www.IT-Visions.de" },
   new Company{ ID = 2, Name = "Software & Support" },
   new Company{ ID = 3, Name = "Heise Gruppe GmbH & Co. KG" },
   new Company{ ID = 4, Name = "Startup i.Gr." } // hat noch keine Website
 ];
 
 Website[] websites =
 [
   new Website{ CompanyID = 1, URL = "www.IT-Visions.de" },
   new Website{ CompanyID = 1, URL = "www.dotnet10.de" },
   new Website{ CompanyID = 2, URL = "www.entwickler.de" },
   new Website{ URL = "www.Microsoft.com" }, // Diese kleine ;-) Firma ist noch nicht angelegt...
   new Website{ CompanyID = 3, URL = "www.heise.de" },
 ];
 
 // ### LeftJOIN ALT ############################################################################
 
 CUI.H2("--- Alle Firmen mit ggf. vorhandenen Websites via LeftJoin ALT (GroupJoin+SelectMany) seit .NET Framework 3.5 ---");
 
 var AllCompaniesWithWebsitesSetOld = companies
     .GroupJoin(websites,
                c => c.ID,
                w => w.CompanyID,
                (c, websites) => new { Company = c, Websites = websites })
     .SelectMany(
         x => x.Websites.DefaultIfEmpty(),  // Falls keine Website existiert, wird `null` verwendet
         (c, w) => new WebsiteWithCompany
         {
          Name = c.Company.Name,
          URL = w.URL,   // Falls `w` null ist, bleibt URL null
          City = c.Company.City
         });
 
 foreach (var item in AllCompaniesWithWebsitesSetOld)
 {
  Console.WriteLine((item.Name != null ? item.Name + " " + item.City : "- keine Firma -").Trim() + " -> " + (item.URL ?? "- keine URL -"));
 }
 
 // ### LeftJOIN NEU ############################################################################
 
 CUI.H2("--- Alle Firmen mit ggf. vorhandenen Websites via LeftJoin NEU ab .NET 10.0 ---");
 var AllCompaniesWithWebsitesSet = companies.LeftJoin(websites,
  e => e.ID,
  e => e.CompanyID,
  (c, w) => new WebsiteWithCompany { Name = c.Name, City = c.City, URL = w.URL }
  );
 
 foreach (var item in AllCompaniesWithWebsitesSet)
 {
  Console.WriteLine((item.Name != null ? item.Name + " " + item.City : "- keine Firma -").Trim() + " -> " + (item.URL ?? "- keine URL -"));
 }
 
 // ### RightJoin ALT ############################################################################
 
 CUI.H2("--- Alle Websites mit ggf. vorhandenen Firmen via RightJoin ALT (GroupJoin+SelectMany) seit .NET Framework 3.5  ---");
 var WebsiteWithCompanySetOLD = websites
     .GroupJoin(companies,
                w => w.CompanyID,
                c => c.ID,
                (w, companies) => new { Website = w, Companies = companies })
     .SelectMany(
         x => x.Companies.DefaultIfEmpty(),  // Falls kein Unternehmen existiert -> null
         (w, c) => new WebsiteWithCompany
         {
          Name = c.Name,  // Falls `c` null ist, bleibt `Name` null
          City = c.City,   // Falls `c` null ist, bleibt `City` null
          URL = w.Website.URL
         });
 
 foreach (var item in WebsiteWithCompanySetOLD)
 {
  Console.WriteLine((item.Name != null ? item.Name + " " + item.City : "- keine Firma -").Trim() + " -> " + (item.URL ?? "- keine URL -"));
 }
 
 // ### RightJoin NEU ############################################################################
 
 CUI.H2("--- Alle Websites mit ggf. vorhandenen Firmen via RightJoin NEU ab .NET 10.0 ---");
 var WebsiteWithCompanySet = companies.RightJoin(websites,
     e => e.ID,
     e => e.CompanyID,
     (c, w) => new WebsiteWithCompany { Name = c.Name, City = c.City, URL = w.URL }
  );
 
 foreach (var item in WebsiteWithCompanySet)
 {
  Console.WriteLine((item.Name != null ? item.Name + " " + item.City : "- keine Firma -").Trim() + " -> " + (item.URL ?? "- keine URL -"));
 }
 
 // ### Zum Vergleich: Inner Join, den es seit .NET Framework 3.5 gibt
 CUI.H2("--- Alle Firmen, die Websites haben, via InnerJoin seit .NET Framework 3.5 ---");
 var CompaniesWithWebsitesSet = companies.Join(websites,
                                        c => c.ID,
                                        w => w.CompanyID,
                                        (c, w) => new WebsiteWithCompany
                                        {
                                         Name = c.Name,
                                         URL = w.URL,
                                         City = c.City
                                        });
 foreach (var item in CompaniesWithWebsitesSet)
 {
  Console.WriteLine((item.Name != null ? item.Name + " " + item.City : "- keine Firma -").Trim() + " -> " + (item.URL ?? "- keine URL -"));
 }
}

Der Code erzeugt diese Ausgabe (Abb. 1).

Videos by heise

Die neuen Operatoren sind laut Microsoft performanter als die bisherige Operatorkombination.

Performance von LeftJoin() im Vergleich zu der bisherigen Operatorkombination (Abb. 2)

(Bild: Microsoft)

(rme)

Top 10: Die beste Sportuhr im Test

Top 10: Bester Android-Auto-Wireless-Adapter

Top 7: Die beste Kompressor-Kühlbox im Test

software-architektur.tv: John Romeros Prinzipien – mit Tom Asel

2026-05-15T06:43:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

In der Episode diskutieren Eberhard Wolff und Tom Asel über einige fundamentale Prinzipien des Gaming-Pioniers John Romero für die Softwareentwicklung.

(Bild: software-architektur.tv)

08:43 Uhr

Lesezeit: 1 Min.

Developer

Von

Wolf Hosbach

John Romero ist bekannt als eine der treibenden Kräfte hinter id Software. Mit einer Gruppe von unter zehn Leuten hat id die Spiele-Welt mit „Doom“ und „Quake“ revolutioniert, Shareware als Vertriebsmodell etabliert, Spiele-Engines zu einem eigenständigen Produkt gemacht und viele seiner Innovationen später als Open Source veröffentlicht. In seinen aktuellen Vorträgen hat er einige fundamentale Prinzipien für die Softwareentwicklung diskutiert.

In dieser Episode sprechen Tom Asel und Eberhard Wolff darüber, was Developer daraus für die Entwicklung von Informationssystemen im Allgemeinen lernen können.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

YouTube-Video immer laden

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.

Livestream am 15. Mai

Die Ausstrahlung findet live am Freitag, dem 15. Mai 2026, um 13 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat oder anonym über das Formular auf der Videocast-Seite einbringen.

software-architektur.tv ist ein Videocast von Eberhard Wolff, iX-Blogger und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Zum Team gehören außerdem Lisa Maria Schäfer (Socreatory) und Ralf D. Müller (DB Systel). Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff, Schäfer oder Müller solo. Seit mittlerweile mehr als zwei Jahren berichtet heise developer über die Episoden.

(who)

Top 10: Die beste Sportuhr im Test

Top 10: Bester Android-Auto-Wireless-Adapter

Top 7: Die beste Kompressor-Kühlbox im Test

Von undefiniert zu definiert: Die Verwendung von std::launder in C++

2026-05-15T05:53:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Laundering in C++ hilft dabei, einen Pointer zu „waschen“ und so Compiler-Optimierungen für das Objekt dahinter zu deaktivieren.

(Bild: Fransizka Panter)

07:53 Uhr

Lesezeit: 5 Min.

Developer

Von

Andreas Fertig

Im heutigen Beitrag knüpfe ich an die übergreifenden Themen der letzten beiden Monate an. Heute geht es darum, wann und wo du std::launder aus C++17 einsetzen musst und worin der Unterschied zu reinterpret_cast oder std::start_lifetime_as besteht.

Andreas Fertig ist erfahrener C++-Trainer und Berater, der weltweit Präsenz- sowie Remote-Kurse anbietet. Er engagiert sich im C++-Standardisierungskomitee und spricht regelmäßig auf internationalen Konferenzen. Mit C++ Insights (https://cppinsights.io) hat er ein international anerkanntes Tool entwickelt, das C++-Programmierenden hilft, C++ noch besser zu verstehen.

Die Bereiche, in denen man das heute Gelernte anwenden kann, sind vielfältig. Im Embedded-Bereich wird std::launder in der Regel verwendet, aber auch beim Schreiben von Bibliothekscode kommt „Laundering“ (zu Deutsch waschen und bügeln, gerne im Zusammenhang mit „Money“ als Geldwäsche) vor.

Wann es zu Problemen kommen kann

Ich verwende das Beispiel aus dem Paper P0532R0:

struct X {
  const int n;  // #A
  double    d;
};

X* p = new X{7, 8.8};  // #B

new(p) X{42, 9.9};  // #C

int  i = p->n;  // #D
auto d = p->d;  // #E

Hier stehen mehrere Teile, die zusammenpassen müssen. Beachte, dass das struct X das Datenfeld n als const deklariert.

Als Nächstes wird mithilfe von new in #B ein Objekt erstellt und der resultierende Zeiger in p gespeichert. So weit, so gut.

Der interessante Teil beginnt als Nächstes in #C mit dem Platzierungs-new. Wer das noch nie gemacht hat, muss den eigenen C++-Code vielleicht nicht waschen und glatt bügeln.

Videos by heise

Das Platzierungs-new selbst ist auch in Ordnung. Das Problem tritt später in #D und #E auf. Hier wird auf die Werte des Zeigers p zugegriffen. Aber der Compiler darf davon ausgehen, dass nach #B der Inhalt von p unverändert ist, da p selbst nie dazu verwendet wurde, den Inhalt des Objekts zu ändern. Noch schlimmer: Eines der Datenelemente von X ist const. Das ist eine Freikarte für den Optimierer, zu Recht anzunehmen, dass sich der Wert von n nach der Konstruktion nie ändert.

Aber genau das habe ich in #C getan. Ich ändere einen const-Wert! Die Werte von i und d sind unbekannt. Das ist undefiniertes Verhalten.

Dieses lässt sich leicht vermeiden, sogar ohne std::launder, indem man den Zeiger aktualisiert und dem Compiler mitteilt, dass sich die Werte hinter p geändert haben:

X* p = new X{7, 8.8};  // #B

p = new(p) X{42, 9.9};  // #C

int  i = p->n;  // #D
auto d = p->d;  // #E

Die Frage ist also: Warum macht man das nicht einfach und vergisst std::launder? Nun, wann immer möglich, vergiss std::launder.

Leider gibt es Fälle, in denen das Aktualisieren des Zeigers wertvolle Ressourcen opfern würde.

Wenn es komplizierter wird

Angenommen, du implementierst einen benutzerdefinierten Allokator:

template<size_t SIZE, size_t ALIGNMENT>
class Buffer {
  alignas(ALIGNMENT) std::byte mBuffer[SIZE];

public:
  template<typename T, typename... Ts>
  T* Construct(Ts... vals)
  {
    new(mBuffer) T{std::forward<Ts>(vals)...};
    return reinterpret_cast<T*>(mBuffer);
  }

  template<typename T>
  [[nodiscard]] T* Get()
  {
    return reinterpret_cast<T*>(mBuffer);
  }
};

Du siehst hier zwei Funktionen, die der Allokator bereitstellt: Construct und Get. Das Konzept von Buffer besteht darin, dass die gespeicherten Daten typunabhängig sind. Eine mögliche vereinfachte Verwendung könnte folgendermaßen aussehen:

struct Point {  // #A
  int x;
  int y;
};

struct Point3D {
  int x;
  int y;
  int z;
};

std::array<Buffer<12, 8>, 2> storage{};  // #B

// #C
storage.at(0).Construct<Point>(2, 3);
storage.at(1).Construct<Point3D>(4, 5, 6);

// #D
storage.at(0).Get<Point>()->x = 7;

Die zwei Datentypen Point und Point3D in #A stehen als Beispiel für beliebige Typen. storage steht für den Stack-Speicher, der beliebige Daten speichern kann. Solange die Nutzer wissen, welcher Datentyp hinter einem Index steckt (und dieser Typ nicht zu groß ist), kann alles gespeichert werden.

Am ersten Element des Arrays #C konstruiere ich ein Point-Objekt, während ich am zweiten Element ein Point3D erstelle. Erst später im Programm #D werden die Objekte tatsächlich verwendet. Dennoch hat niemand aus gutem Grund einen Zeiger auf das frisch konstruierte Objekt gespeichert. Ein solcher Zeiger würde Speicherkapazität erfordern, und du weißt bereits, wohin dieser Zeiger zeigt.

Aus der Perspektive der abstrakten Maschine habe ich Löcher in das Typsystem gestochen. Der Compiler kann zu Recht davon ausgehen, dass sich die Daten hinter Get nicht ändern, es sei denn, er sieht etwa einen direkten Schreibzugriff #D. Ein solcher Zugriff bleibt vom Compiler unbemerkt (oder könnte es bleiben, da es sich um undefiniertes Verhalten handelt) im folgenden Code in #E, wenn ich an einer bestehenden Stelle ein neues Point-Objekt erstelle:

std::array<Buffer<12, 8>, 2> storage{};  // #B

// #C
storage.at(0).Construct<Point>(2, 3);

// #D
storage.at(0).Get<Point>()->x = 7;

// #E
storage.at(0).Construct<Point>(8, 9);

Offensichtlich lässt sich das Problem hier am einfachsten vermeiden, indem man den von jedem Construct-Aufruf zurückgegebenen Zeiger speichert. Wenn das, wie hier, nicht machbar ist, besteht die richtige Vorgehensweise darin, den Zeiger mit std::launder zu „waschen“. Dieses spezielle Hilfsmittel fungiert als Devirtualisierungsbarriere, die Compiler-Optimierungen und -Annahmen verhindert.

`std::launder` zur Rettung

So lässt sich die Buffer-Implementierung auf sichere Weise aktualisieren. Zunächst zu Construct: Meine ursprüngliche Implementierung sah so aus:

template<typename T, typename... Ts>
T* Construct(Ts... vals)
{
  new(mBuffer) T{std::forward<Ts>(vals)...};
  return reinterpret_cast<T*>(mBuffer);
}

Du kannst diesen Code auch ohne std::launder sicher machen, indem du den von new zurückgegebenen Zeiger zurückgibst:

template<typename T, typename... Ts>
T* Construct(Ts... vals)
{
  return new(mBuffer) T{std::forward<Ts>(vals)...};
}

Die zweite Funktion, die du korrigieren musst, ist Get, dieses Mal durch Hinzufügen von std::launder:

template<typename T>
[[nodiscard]] T* Get()
{
  return std::launder(reinterpret_cast<T*>(mBuffer));
}

Der Code geht nun davon aus, dass du Construct aufrufst, bevor du Get aufrufst. Dieser mBuffer enthält ein gültiges Objekt, das mit dem übereinstimmt, das mit Construct erstellt wurde.

Zusammenfassung

Mit std::launder kannst du einen Zeiger aktualisieren, der auf ein bereits vorhandenes Objekt an dieser Speicheradresse verweist. Die Lebensdauer des Objekts an dieser Stelle hat also bereits begonnen.

(rme)

Top 10: Die beste Sportuhr im Test

Top 10: Bester Android-Auto-Wireless-Adapter

Top 7: Die beste Kompressor-Kühlbox im Test

KI-Portierung: Claude schreibt Bun-Codebasis in Rust neu

2026-05-14T14:30:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Der JavaScript- und TypeScript-Server und -Bundler Bun besteht künftig aus Rust-Code. Innerhalb von Wochen hat Claude Code die Software portiert.

150

(Bild: iX)

14.05.2026, 16:30 Uhr

Lesezeit: 3 Min.

Developer

Von

Jan Mahn

Bun ist einst angetreten, um Node.js als JavaScript-Server, NPM als Paketmanager und Bundler wie esbuild mit einer Software zu ersetzen. Ende 2025 übernahm die KI-Firma Anthropic das Open-Source-Projekt und das Bun-Entwicklerteam. Die Begründung: Anthropic nutzt Bun bereits für Claude Code und das Claude Agent SDK.

Jetzt wird klar, dass die Übernahme des Projekts durch die KI-Firma Anthropic nicht folgenlos bleibt: Ende April erschien ein Branch, in dem das Sprachmodell Claude auf Anweisung die gesamte Codebasis von Zig auf Rust umzieht. Noch am 5. Mai ordnete Jarred Sumner, Gründer von Bun, diese Entwicklung ein und versuchte damit, eine Diskussion zu beruhigen: „I work on Bun and this is my branch. This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.“

Videos by heise

Doch es kam anders und die Ansätze wurden nicht verworfen: Am 14 Mai wurden die Änderungen vielmehr in den Main-Branch übernommen – 2188 Dateien geändert, eine Million Zeilen neu geschrieben, 4000 Zeilen gelöscht. Bun ist damit komplett in Rust geschrieben.

Fragen offen

Dieses Vorgehen stößt nicht nur auf Begeisterung. Während Jarred Sumner auf GitHub ankündigt, Details im Blog veröffentlichen zu wollen, beginnt die Diskussion unter dem Beitrag. Kritisiert wird unter anderem, dass einige der alten Tests verändert wurden, damit die Rust-Version sie erfolgreich durchläuft. Auf Jarreds Aussage „We now have compiler-assisted tools for catching & preventing memory bugs“ reagieren Kommentatoren, dass das nur zutreffe, wenn man im Code nicht inflationär das Schlüsselwort unsafe verwende, wie Claude es getan habe.

Für das Bun-Team beginnt der größte Teil der Arbeit jetzt: In den GitHub-Issues sammeln sich bereits die ersten Probleme, die mit der Zig-Version nicht auftraten. Noch ist die Rust-Version nicht mit Versionsnummer veröffentlicht, doch das scheint nur eine Frage der Zeit zu sein. Wer Bun nutzt und zunächst abwarten möchte, sollte seine Version auf 1.3.14 festnageln. Das könnte die letzte Zig-Version bleiben.

Was kostet das?

Ein kompletter Umzug eines Projekts dieser Größe, komplett von einem LLM erledigt – das ist ein Novum in der Softwareentwicklung. Wie viele Token Bun dafür aufgewendet hat, verrät Jarred bisher nicht. Erst mit dieser Information könnte man errechnen, was ein solcher Umzug kosten würde, wenn man nicht gerade von Anthropic übernommen wurde.

(jam)

Top 10: Die beste Sportuhr im Test

Top 10: Bester Android-Auto-Wireless-Adapter

Top 7: Die beste Kompressor-Kühlbox im Test

SAP investiert: n8n wird eines der wertvollsten deutschen KI-Startups

2026-05-13T20:54:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

SAP ergänzt sein KI-Portfolio durch weitere Investitionen: Produkte der Start-ups n8n und Parloa sollen die Vision des autonomen Unternehmens verwirklichen.

(Bild: Kittyfly/Shutterstock.com)

13.05.2026, 22:54 Uhr

Lesezeit: 2 Min.

iX Magazin

Von

Axel Kannenberg

Deutschlands Softwareriese SAP investiert erneut in KI-Startups, diesmal in den Berliner Automatisierungsspezialisten n8n sowie in das KI-Kundenservice-Unternehmen Parloa. Konkrete Summen nennen die Beteiligten nicht. n8n teilt aber mit, dass die eigene Bewertung durch die Investition 5,2 Milliarden US-Dollar erreicht habe.

Das sei eine Verdopplung innerhalb weniger als eines Jahres und hebt n8n unter die am höchsten bewerteten KI-Startups in Deutschland. Spitzenreiter bleibt das Münchner KI-Drohnen-Startup Helsing, das laut jüngsten Berichten bald eine Bewertung von 18 Milliarden US-Dollar erreichen könnte.

Automatisierung und KI-Kundenservice

Die Produkte von n8n und Parloa passen gut in die Vision des autonomen Unternehmens, die SAP diese Woche bei der Hausmesse Sapphire vorgestellt hat. In einer autonomen Firma sollen KI-gestützte Assistenzen Hand in Hand mit menschlichem Personal arbeiten und Geschäftsabläufe vollständig übernehmen. n8ns Automatisierungswerkzeug soll laut Mitteilung in Kürze nativ innerhalb der Entwicklungsumgebung Joule Studio auf der SAP Business AI Platform verfügbar sein. Mit n8n lassen sich unter anderem KI-Workflows visuell erstellen und orchestrieren.

Videos by heise

Auch bei Parloa geht es laut der Mitteilung nicht nur um eine strategische Investition, sondern um Produktintegration. Parloas KI-Agenten für Kundenservice über digitale Kanäle und Call-Center sollen sich mit Business-Daten und Prozessen aus der SAP Service Cloud verknüpfen können. Parloa verspricht dabei agentischen Kundenservice, der ein hohes Interaktionsvolumen bewältigen könne und sehr menschlich und markenkonform agiere. Parloas AI Agent Management Platform, die Agentenverwaltung von Design und Testing bis zu Deployment und Optimierung unterstützen soll, findet zudem Eingang in SAPs Geschäfts-App-Store.

SAP shoppt Start-ups

Laut Handelsregister steigt die Beteiligung SAPs an n8n auf fast 1,3 Prozent. Wie das Handelsblatt unter Berufung auf Insider schreibt, steckt SAP 60 Millionen in n8n; auch für Parloa soll ein zweistelliger Millionenbetrag geflossen sein.

Anfang Mai hat SAP das Freiburger KI-Startup Prior Labs übernommen, das sich auf Tabellarische Foundation Models konzentriert, und Pläne zur Übernahme der US-Datenplattform Dremio bekannt gemacht. Bereits im März ist bekannt geworden, dass SAP mit Reltio einen anderen Datenspezialisten aus den USA übernehmen will.

Lesen Sie auch

n8n: Updates beheben kritische Sicherheitslücken in Automatisierungsplattform

Security Operations mit n8n automatisieren

KI-Kundenservice aus Deutschland: Parloa ist eine Milliarde wert

Top 10: Die beste Sportuhr im Test

Top 10: Bester Android-Auto-Wireless-Adapter

Top 7: Die beste Kompressor-Kühlbox im Test

Red Hat baut Ansible zur Steuerzentrale für KI-Agenten um

2026-05-13T10:40:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Red Hat erweitert Ansible um einen Automation Orchestrator für KI-gestützte IT-Automatisierung und stellt Version 2.7 vor.

(Bild: tomeqs / Shutterstock.com)

13.05.2026, 12:40 Uhr

Lesezeit: 3 Min.

iX Magazin

Von

Harald Weiss

Red Hat wird die Ansible Automation Platform um viele neue Funktionen für KI-gestützte IT-Automatisierung erweitern. Im dritten Quartal soll eine neue Version erscheinen, in deren Mittelpunkt der Automation Orchestrator steht. Damit soll die Ansible-Plattform zur zentralen Ausführungsebene für KI-gestützte IT-Operationen werden. Der Orchestrator analysiert Signale von KI-Systemen oder Agenten, erkennt Zusammenhänge und schlägt Maßnahmen vor. Die eigentliche Umsetzung erfolgt über definierte Automatisierungsabläufe in Ansible. Red Hat nennt dieses Prinzip: „KI empfiehlt, Menschen genehmigen und die Automations-Plattform führt aus.“

Des Weiteren soll der Orchestrator unterschiedliche Quellen und Werkzeuge in einem gemeinsamen Ablauf verbinden. Beispielsweise können Alerts von IBM Instana, ServiceNow oder Splunk denselben Workflow starten, bei dem ein Ticket angelegt wird, eine KI den Vorfall analysiert und eine geeignete Maßnahme empfohlen wird. Anschließend muss eine Person diese Aktion freigeben, bevor Ansible das Problem automatisch beheben darf. Das heißt, der Orchestrator nutzt die vorhandenen Automatisierungen, statt diese zu ersetzen. Viele Unternehmen verfügen bereits über Skripte, Runbooks und Ansible-Playbooks, die der neue Orchestrator in KI-gestützte Prozesse einbindet.

Rechte begrenzen und kontrollieren

„KI-Agenten werden in der IT-Administration nur dann erfolgreich sein, wenn sie mit klar begrenzten Rechten innerhalb bewährter Leitplanken operieren“, sagt Sathish Balakrishnan, Vice President der Ansible Business Unit bei Red Hat. „KI kann Situationen analysieren und Maßnahmen empfehlen, doch die Ausführung muss immer über geprüfte Playbooks, Freigaben, Rollenmodelle und Audit-Trails erfolgen“, so Balakrishnan weiter.

Einen Schwerpunkt der neuen Version bilden Kontrollmechanismen. Dazu zählen rollenbasierte Zugriffe, Approval Gates, Auditing, Content Signing und Credential Management. Diese Kontrollmechanismen sollen unabhängig davon gelten, ob eine Automatisierung klassisch aufgabenbasiert, eventgetrieben oder KI-gestützt ausgelöst wird.

Ansible 2.7: Mehr Transparenz und MCP-Server

Parallel hat Red Hat die Ansible Automation Platform 2.7 angekündigt. Sie bringt unter anderem einen visuellen Editor für Execution Environments, einen Content-Katalog und Automation-Dashboards. Diese Dashboards sollen helfen, die Leistung und den wirtschaftlichen Nutzen der Automatisierung besser nachzuvollziehen.

Für AIOps wurde die Ansible-Plattform um einen MCP-Server (Model Context Protocol) erweitert, der auf den bestehenden Ansible-Kontrollen für Benutzeridentitäten, Zugangsdaten und rollenbasierten Zugriffen aufsetzt. Der MCP-Server kann auch im Read-only-Modus betrieben werden, um riskante Aktionen über Human-in-the-loop-Freigaben abzusichern. Hinzu gekommen sind AIOps-Solution-Guides. Der erste davon bietet Integrationen mit IBM Instana, ServiceNow und Splunk. Das ist für Betriebsumgebungen gedacht, in denen Observability-, ITSM- und Security-Signale bereits aus verschiedenen Systemen anfallen. Der Orchestrator soll diese Signale in kontrollierte Automatisierungsabläufe überführen, statt die vorhandenen Werkzeuge zu ersetzen.

Videos by heise

Für Entwickler und Automatisierungsteams gibt es eine Erweiterung, über die per MCP KI-Anwendungen und MCP-Clients angebunden werden können, darunter Claude oder Cursor. Zudem unterstützt ein intelligenter Assistent „bring-your-own-knowledge“, mit dem Modellantworten stärker auf vorhandenes Betriebswissen, Playbooks und interne Abläufe zugeschnitten werden.

(fo)

Top 10: Die beste Sportuhr im Test

Top 10: Bester Android-Auto-Wireless-Adapter

Top 7: Die beste Kompressor-Kühlbox im Test

C-Libraries in Java nutzen 2: Funktionen mit veränderlichen Parametern

2026-05-13T07:26:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Die Foreign Function & Memory API bietet in Java einen deutlich einfacheren Zugang zu Funktionen in C-Libraries als das veraltete JNI.

(Bild: SWstock / Shutterstock.com)

13.05.2026, 09:26 Uhr

Lesezeit: 8 Min.

Developer

Von

Rudolf Ziegaus

Javas Foreign Function & Memory API (FFM) dient dazu, auf Code in einer Shared Library beziehungsweise DLL zuzugreifen, der in einer Programmiersprache wie C oder Rust geschrieben ist. Allerdings muss der Code dazu einige Voraussetzungen erfüllen. Diese dreiteilige Artikelserie zeigt anhand einer in C geschriebenen Demo-Library, wie eine Java-Anwendung die Funktionen der Bibliothek aufruft, welche Vorbereitungen erforderlich sind und welche Regeln zu beachten sind.

Rudolf Ziegaus ist Software-Entwickler, Java-Trainer und Geschäftsführer der IO Software GmbH. Seine Lieblingsthemen sind PKi, Kryptographie und systemnahe Programmierung.

Nachdem der erste Teil gezeigt hat, wie man in Java eine in C geschriebene Shared Library lädt und einfache Funktionen dieser Shared Library aufruft, geht es jetzt um komplexere Szenarien. Er zeigt, wie man aus Java Funktionen mit veränderbaren Parametern aufrufen und Arrays sowie Strukturen übergeben kann.

Funktionen mit veränderbarem Parameter

Die bisherigen Beispiele haben die Aufrufe der nativen Funktionen einfach gehalten. Die Java-Anwendung hat lediglich Parameter durchgereicht und den Rückgabewert übernommen.

Anders sieht es bei den nächsten Beispielen aus. Als erstes folgt die einfache C-Funktion getVersion2, die wie die Funktion getVersion aus Teil 1 die Version der Library ermittelt. Die neue Funktion gibt die Versionsnummer aber nicht als Wert zurück, sondern verändert dazu einen Parameter. Das funktioniert in C, indem eine Anwendung für einen Parameter nicht den Wert selbst, sondern dessen Adresse übergibt (Call by Reference). Dieses Konstrukt sieht in C folgendermaßen aus:

EXPORT void   getVersion2(int* version);

Folgender Java-Code ruft die Funktion auf:

int version;
getVersion2(&version);

Das & kennzeichnet in C, dass die Funktion die Adresse der Variablen nutzt. Java erlaubt das Vorgehen nicht, sodass ein Rückgabewert unerlässlich ist. Folgende Java-Methode verwendet die C-Funktion mit Referenz:

public int getVersion2() throws Throwable
{
  MethodHandle method = getMethodHandle("getVersion2",   
     FunctionDescriptor.of(
				ValueLayout.JAVA_INT, 
				ValueLayout.ADDRESS
				));
  try (Arena arena = Arena.ofConfined())
  {
    MemorySegment versionSeg =   
      arena.allocate(ValueLayout.JAVA_INT.byteSize());
    method.invoke(versionSeg);
    int version = versionSeg.get(ValueLayout.JAVA_INT, 0);
    return version;
  }
}

Zuerst ruft der Code wie im ersten Teil der Serie wieder die Methode getMethodHandle() auf. Der Aufruf definiert den FunctionDescriptor für die Funktion getVersion2().

Die Angabe ValueLayout.ADDRESS für den Parameter zeigt an, dass die C-Funktion eine Adresse erwartet.

Videos by heise

Jetzt kommt der spannendere Teil: Um eine Adresse übergeben zu können, muss die Java-Anwendung mittels der FFM-API einen Speicherbereich von vier Byte (für den Datentyp int) reservieren. Das geschieht mit einer Arena, die er erste Teil bereits erläutert hat. Das Erzeugen der Arena mit dem try-with-ressources-Statement stellt sicher, dass die Arena nach dem try-Block automatisch geschlossen und der darin verwaltete Speicher automatisch freigegeben wird. Es gibt verschiedene Typen von Arenas – die im Beispiel über ofConfined erzeugte sorgt dafür, dass die Anwendung nur auf Speicher des aktuellen Thread zugreifen kann. Eine mit ofConfined() erzeugte Arena – beziehungsweise der damit allozierte Speicher – ist daher nicht threadsicher.

Als nächstes gilt es, den erforderlichen Speicherbereich für den Parameter version zu allokieren. Dafür besitzt die Arena die Methode allocate(). Die Größe des benötigten Speichers kann man durch die Funktion byteSize() für die Variable ermitteln. Hier sei nochmals darauf hingewiesen, dass der Wert die Größe des Java-Datentyps darstellt und nicht zwingend etwas über den C-Datentyp aussagt. Da die C-Funktion einen int-Parameter entgegennimmt, sind wir auf der sicheren Seite, da int in C stets vier Byte umfasst. Bei einem long-Wert in C hängt die Größe dagegen von der Plattform ab.

Der Speicherbereich wird durch ein MemorySegment dargestellt, das beim Aufruf der Methode invoke an die C-Funktion weitergereicht werden muss.

Anschließend kann die Anwendung das Ergebnis auslesen. Dazu ruft sie auf dem MemorySegment die Funktion get auf und übergibt ihr das Layout des Speichers (in diesem Fall ein JAVA_INT) und den Offset zum Lesen aus dem MemorySegment. Für das Beispiel ist der Offset null. Durch die Angabe JAVA_INT gibt die Funktion einen int-Wert zurück, den die Anwendung weiterverarbeiten kann.

Funktionen mit einem Array-Parameter

Die nächste Aufgabe baut auf dem Vorgehen auf, verarbeitet aber nicht nur einen Wert, sondern ermittelt den Durchschnitt aus einer Liste von int-Werten. Dazu muss sie der nativen Funktion ein Array von int-Werten übergeben:

public double calcAverage(int [] values) throws Throwable
{
  MethodHandle calcAverage =  
     getMethodHandle("calcAverage"),
	    FunctionDescriptor.of(
	    ValueLayout.JAVA_DOUBLE,     // return value 
	    ValueLayout.ADDRESS,         // data values 
	    ValueLayout.JAVA_INT));      // number of elements

  try(Arena arena = Arena.ofConfined())  
  {
    long totalSize = ValueLayout.JAVA_INT.byteSize() * values.length;
    MemorySegment valueSegment = arena.allocate(totalSize);
    for (int i = 0; i < values.length; i++) 
    {
      valueSegment.setAtIndex(ValueLayout.JAVA_INT, i, values[i]); 
    }
    double result = (double) calcAverage.invoke(valueSegment, 
                                                values.length);
    return result;
  }
}

Zunächst berechnet der Code die gesamte Speichergröße des Arrays (totalSize) und reserviert den benötigten Speicher mit allocate(). Anschließend belegt der Code den Speicher mit der Methode setAtIndex für das jeweilige MemorySegment. Der Aufruf erfolgt für jedes Element des Arrays.

Schließlich ruft der Code die Methode invoke für den MethodHandle auf und übergibt ihr als Parameter das Array und dessen Länge. Schließlich gibt sie das Ergebnis der C-Funktion zurück.

Top 10: Die beste Sportuhr im Test

Top 10: Bester Android-Auto-Wireless-Adapter

Top 7: Die beste Kompressor-Kühlbox im Test

KI-Ära erzwingt Reformen: GitLab strukturiert um

2026-05-13T06:26:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Der KI-Boom erfordert eine strukturelle und strategische Neuausrichtung. Sagt GitLab und antwortet mit Entlassungen, flacheren Hierarchien und mehr KI.

(Bild: Ole.CNX / Shutterstock.com)

13.05.2026, 08:26 Uhr

Lesezeit: 3 Min.

Developer

Von

Manuel Masiero

GitLab verordnet sich selbst eine strukturelle und strategische Neuausrichtung. Sie soll bis zum 1. Juni 2026 abgeschlossen sein und vier Maßnahmenblöcke umfassen: eine Reduktion der Länderpräsenz, den Abbau mehrerer Managementebenen, eine Umorganisation der Forschungs- und Entwicklungsteams sowie neue Arbeitsprozesse, die den Schwerpunkt auf KI legen. Offen bleibt, wie groß der Stellenabbau wird.

Diese Maßnahmen kündigte GitLab-CEO Bill Staples am 11. Mai in einem Blogbeitrag auf GitLab an. Darin bezeichnet er die agentische Ära als größte Chance in der Unternehmensgeschichte von GitLab, was entsprechende strukturelle und strategische Entscheidungen und Anpassungen erfordere.

Die bisherige Organisationsform, im Blogbeitrag auch als „GitLab Act 1“ bezeichnet, sei für diese neue Phase zu langsam, zu komplex und nicht optimal ausgerichtet. Deshalb greift für Angestellte, Investoren und Kunden nun „GitLab Act 2“. Dessen Maßnahmen sollen GitLab als DevOps-Plattform-Anbieter schneller, effizienter und innovationsstärker aufstellen. Auf Kundenseite hat GitLab schon vorgelegt: Mit der GitLab Duo Agent Platform treibt der Anbieter bereits seit letztem Jahr eine stärkere KI-gestützte Entwicklung voran.

Videos by heise

Länderpräsenz verkleinert sich um bis zu 30 Prozent

Konkrete Zahlen zum Stellenabbau nennt Bill Staples nicht, lässt jedoch dessen Größenordnung durchblicken. Man wolle die Präsenz in Ländern, in denen kleine GitLab-Teams sitzen, um bis zu 30 Prozent reduzieren. Bei GitLab arbeiten derzeit rund 2600 Angestellte, die sich auf mehr als 65 Länder verteilen. Kunden in den betroffenen Gebieten sollen künftig über Partner betreut werden. Dabei bleibt offen, welche Länder auf der roten Liste stehen.

Im Rahmen von GitLab Act 2 will GitLab in einzelnen Unternehmensbereichen auch bis zu drei Managementebenen streichen, was die Kommunikation der Teams untereinander verbessern und beschleunigen soll. Des Weiteren werde man die Rollen und Verantwortlichkeiten auf eine KI-gestützte Arbeitsweise ausrichten und Aufgaben automatisieren, wo immer das möglich ist. Ziel sei es, eine optimale Rollenverteilung innerhalb der Teams zu finden. Als vierte Maßnahme will GitLab sein Forschungs- und Entwicklungsteam neu aufstellen, um damit rund 60 kleinere und schlagkräftigere Teams zu schaffen.

Verträge und Support laufen normal weiter

Für Kundinnen und Kunden ändern sich durch GitLab Act 2 weder Roadmap-Zusagen noch bestehende Vertragsbedingungen, betont der GitLab-CEO. Auch der Support soll ohne Unterbrechung weiterlaufen.

Vorbehaltlich der Zustimmung des Vorstands will GitLab den endgültigen Umfang und die finanziellen Auswirkungen der Restrukturierung im Rahmen des Earnings-Calls am 2. Juni bekannt geben. An den Umsatzzielen für das erste Quartal des Geschäftsjahres 2027 (253 bis 255 Millionen US-Dollar) und das gesamte Geschäftsjahr 2027 (1,099 bis 1,118 Milliarden US-Dollar) halte man dabei fest. Für das vierte Quartal des Geschäftsjahres 2026 meldete GitLab einen Umsatz von 260,4 Millionen US-Dollar, was einem Anstieg von 23 Prozent im Vergleich zum Vorjahr entspricht.

(mro)

Top 10: Die beste Sportuhr im Test

Top 10: Bester Android-Auto-Wireless-Adapter

Top 7: Die beste Kompressor-Kühlbox im Test

SAP setzt auf KI: Autonomous Suite und Business AI Platform vorgestellt

2026-05-12T15:19:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

In Sachen KI geht SAP all-in: Mit der Autonomous Suite auf Basis der Business AI Platform wird eine weitere nun agenten-gestützte Produktlinie vorgestellt.

(Bild: josefkubes/Shutterstock.com)

17:19 Uhr

Lesezeit: 5 Min.

iX Magazin

Von

Achim Born

Seine gerade gestartete Kundenveranstaltung Sapphire nutzt SAP, um die insbesondere von der Finanzwelt herbeigesehnte Antwort auf eine KI-geprägte Software-Welt zu präsentieren. Wenig überraschend lautet das Zielbild Autonomous Enterprise, bei dem KI-gestützte Assistenzen Hand in Hand mit dem gewöhnlichen Personal arbeiten und Geschäftsabläufe vollständig „übernehmen“.

Die neu vorgestellte Autonomous Suite automatisiert die entsprechenden End-to-End-Prozesse. Wie das SAP-Management gerne und häufig betont, stützen sich die Arbeit und Durchführung hierbei auf das seit der SAP-Gründung in über fünfzig Jahren zusammengetragene Kontextwissen zum betrieblichen Geschehen in Unternehmen.

Knowledge Graph als semantisches Herz

Die technische Grundlage für die neue Suite bildet die gleichfalls neu vorgestellte Business-AI-Plattform. Dabei handelt es sich weniger um eine wirkliche Neuentwicklung, sondern zuvorderst um das Zusammenlegen der Business Technology-Plattform (BTP), Business Data Cloud (BDC) und Business AI (Joule, Joule Agents, AI Foundation) in einer geregelten Umgebung.

Das semantische Herz bildet der Knowledge Graph, an dem SAP gleichfalls schon länger strickt. Dieser liefert den Agenten eine strukturierte Übersicht über alle Geschäftseinheiten, Prozesse und Beziehungen in der gesamten SAP-Landschaft eines Anwenderunternehmens. SAP hat inzwischen eine Reihe von Domänenmodellen erstellt, die anhand von Programmcode, Daten, Metadaten, Geschäftsprozessen, Architekturwissen und Dokumentation trainiert wurden. In Kombination mit Kontextgraphen sollen diese die inhärente Logik und Kontrolllogik der SAP-Anwendungswelt den neuen Agenten und Assistenzen zuführen.

Lass das mal die KI-Agenten machen

SAP stellt auf der Sapphire mit Joule Work außerdem einen neuen dynamischen Arbeitsbereich vor, der ein absichtsgesteuertes Arbeiten unterstützt. In natürlicher Sprache sollen Anwender hier einfach formulieren, was sie erreichen wollen und den Rest an die KI beziehungsweise den Joule-Assistenten delegieren. Die Assistenten erkennen anhand des Kontexts die Absichten der Nutzer und koordinieren die entsprechenden Agenten im gesamten Unternehmen. Die Work-Umgebung ist interoperabel angelegt, soll also als zentrale Schnittstelle zwischen SAP- und Nicht-SAP-Umgebungen dienen.

Über Joule Work können Nutzer auch auf die Studio-Umgebung zugreifen. Hier lassen sich dann eigene Agenten erstellen, die über das Model Context Protocol (MCP) und das Agent2Agent-Protokolls (A2A) auch auf Tools oder Agenten von Drittanbietern zurückgreifen können.

Videos by heise

Für die Umsetzung agentenbasierter Funktionen verlässt sich SAP nicht allein auf Eigenentwicklungen, sondern greift weiterhin auf die Tools einschlägiger Anbieter zurück, Anthropics Claude beispielsweise wird die Joule-Agenten in den Bereichen Personalwesen, Beschaffung und Lieferkette unterstützen. Mit AWS sind künftig Datenintegrationen möglich, ohne dass zwischen der Athena und BDC Daten hin- und hergeschaufelt werden müssen.

Mit Zukäufen Lücken geschlossen

Nvidias OpenShell dient wiederum als vertrauenswürdige, sichere Laufzeitumgebung für Joule Studio, um beliebige Agenten in der SAP Business AI Platform erstellen, bereitstellen und verwalten zu können. Ferner schließen Zukäufe mehrere funktionale Lücken im Angebot. Der Reltio-Kauf etwa soll Daten aus unterschiedlichen Quellen graphenbasiert zu einer konsistenten Sicht auf Stammdaten („Golden Record“) zusammenführen. Die angestrebte Übernahme von Dremio beschleunigt den Weg der BDC, SAP- und Nicht-SAP-Daten in ein Apache-Iceberg-natives Lakehouse.

Die gleichzeitig verkündete Akquisition von Prior Labs, einem Pionier für Tabellarische Foundation Models (TFMs), unterstützt die Entwicklung tabellarischer Grundmodelle für betriebliche Aufgaben. Da Unternehmensanwendungen Daten und Zahlen typischerweise in Tabellen organisieren, mangelt es den großen Sprachmodellen an dieser Stelle buchstäblich am grundlegenden Verständnis. Mit dem RPT (Relational Pretrained Transformer) ist SAP selbst hier bereits seit einigen Monaten mit einem eigenen Produkt unterwegs, das auf Grundlage tabellarischer ABAP-Daten Dinge wie Zahlungsverzögerungen, Upselling-Möglichkeiten et cetera vorhersagt. In der neuen 1.5-Version erhält dieses nun einen Chat-Assistenten, um mithilfe von Fragen in natürlicher Sprache tabellarische Daten und die dahinter liegenden Ergebnisse weitergehend erkunden zu können.

Lesen Sie auch

KI: SAP kauft Prior Labs und will über eine Milliarde investieren

Top 5: Das beste Gehäuse für M.2-SSD im Test – externe Festplatte im Selbstbau

Top 10: Der beste Mähroboter im Test

Top 10: Der beste Smart Ring im Test – Oura, Galaxy Ring & Alternativen ohne Abo

Fedora plant KI-Linux-Desktop

2026-05-12T13:57:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Fedora arbeitet an einem Linux-Desktop für KI-Entwickler. Das Projekt will die bislang oft komplexe Einrichtung lokaler KI-Stacks deutlich vereinfachen.

(Bild: Moritz Förster / KI / iX)

15:57 Uhr

Lesezeit: 5 Min.

iX Magazin

Von

Moritz Förster

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.

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.

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.

Videos by heise

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.

Community-Debatte

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

Linux für Gamer: Bazzite 44 basiert auf Fedora 44

Linux-Distribution Fedora 44: KDE Plasma und Wayland im Fokus

Rust Coreutils 0.6 erreicht 96 Prozent GNU-Kompatibilität

Epochaler Wandel bei Textkonsolen von Linux im Werden

Mozilla bringt Firefox Nightly als RPM-Paket für Linux

Top 5: Das beste Gehäuse für M.2-SSD im Test – externe Festplatte im Selbstbau

Top 10: Der beste Mähroboter im Test

Top 10: Der beste Smart Ring im Test – Oura, Galaxy Ring & Alternativen ohne Abo

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

2026-05-12T12:00:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Red Hat erweitert OpenShift um Funktionen für souveräne KI, Cloud-Dienste und verbesserte Virtualisierung. Auch Bare Metal as a Service kommt.

(Bild: tomeqs/Shutterstock.com)

14:00 Uhr

Lesezeit: 3 Min.

iX Magazin

Von

Harald Weiss

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.

Videos by heise

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)

Top 5: Das beste Gehäuse für M.2-SSD im Test – externe Festplatte im Selbstbau

Top 10: Der beste Mähroboter im Test

Top 10: Der beste Smart Ring im Test – Oura, Galaxy Ring & Alternativen ohne Abo

Microsoft veröffentlicht Evaluations-Tool für Copilot-Agenten

2026-05-12T10:10:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Mit dem Tool Microsoft 365 Copilot Agent Evaluations CLI lassen sich Copilot‑Agenten systematisch testen und verbessern. Derzeit geht das kostenlos.

(Bild: IB Photography / Shutterstock.com)

12:10 Uhr

Lesezeit: 2 Min.

Developer

Von

Manuel Masiero

Microsoft hat das Microsoft 365 Copilot Agent Evaluations CLI vorgestellt. Das seit dem 8. Mai als kostenlose Vorschauversion verfügbare Kommandozeilentool ermöglicht es Nutzerinnen und Nutzern, die Qualität von KI‑Agenten zu testen und zu verbessern. Dazu sendet das Agent Evaluations CLI Fragen an einen Agenten und bewertet dessen Antworten mithilfe von Azure-OpenAI-Modellen.

Das Agent Evaluations CLI ist ein Teil der Microsoft-365-Copilot-Extensibility-Plattform, einer zentralen Microsoft-Plattform zur Verwaltung von KI-Agenten. Das Evaluations-CLI steht dort über das Admin Center zur Verfügung und fungiert als eigenständiges Developer-Tool zur Qualitätsmessung.

Bei einem Test sendet das CLI-Tool Prompts an einen innerhalb von Microsoft 365 bereitgestellten Agenten. Dabei unterstützt es mit JSON-Datensätzen, interaktiven Eingaben und Inline-Prompts wie --prompts "Frage 1" "Frage 2" drei Eingabearten, womit es strukturierte Tests genauso abbilden kann wie Live-Dialoge. Die Evaluierungsfunktion lässt sich auch beim Vibe Coding einsetzen.

Videos by heise

Checkliste für Agenten-Bewertung

Vom Agenten gelieferte Antworten bewertet das CLI anhand von sieben Metriken. In die Wertung fließt unter anderem mit ein, wie es um das Kontextverständnis bei Einzel‑ oder Mehrfachdialogen bestellt ist und wie gut der Agent Folgefragen verarbeiten kann. Getestet wird auch, ob der Agent End‑to‑End‑Aufgaben so ausführt, als würde er sich in einem echten Nutzerdialog befinden.

Das Testergebnis als HTML-Report: Das Agent Evaluations Tool hat einen KI-Agenten bewertet.

(Bild: Microsoft)

Die Testberichte im HTML‑, JSON‑ oder CSV‑Format können Entwicklerinnen und Entwickler in ihren eigenen Entwicklungszyklen, Code‑Reviews oder CI/CD‑Pipelines nutzen. Langfristig sollen solche systematischen und wiederholbaren Evaluierungen zu einem Standardbestandteil bei der Softwareentwicklung mit Microsoft 365 Copilot heranwachsen, wie Microsoft in seinem Developer-Blog schreibt.

Während der Testphase, deren Dauer Microsoft nicht konkretisiert, können Programmiererinnen und Programmierer das Microsoft 365 Copilot Agent Evaluations CLI kostenlos nutzen. Dazu benötigen sie eine Microsoft-365-Copilot‑Lizenz, Node.js 24.12.0 oder höher, einen im Tenant bereitgestellten Agenten samt Administratorzustimmung, diesen dort ausführen zu dürfen, sowie einen Azure-OpenAI-Endpunkt für die LLM-Bewertungen (standardmäßig gpt-4o-mini). Aktuell unterstützt das Tool ausschließlich Windows-Entwicklungsumgebungen; Support für macOS und Linux ist angekündigt.

(mro)

heise developer News

Gemini Intelligence mit hohen Hardwareanforderungen an Smartphones

„Höchste Leistungs- und Systemanforderungen“

Updategarantie, sichere Virtualisierung

Kommentar: Das Ende der SaaS-Gelddruckmaschine

Das Geschäftsmodell hinter der Lizenzmaschine

Microsoft sägt am eigenen Ast

Die Börse handelt bereits die nächste Ära

Developer-Häppchen fürs Wochenende – kleinere News der Woche

Code lesen statt Code schreiben: Die unterschätzte Senior-Disziplin

Der eigene Code wird nach drei Wochen zu fremdem Code

LLMs kippen die Bilanz endgültig

Die Abhängigkeitsspirale

Fedora Hummingbird Linux: Neue Container-basierte Distribution

HummingbirdOS ausprobieren

.NET 11.0 Preview 4: Ein bunter Strauß von API-Erweiterungen

Viel Neues für den Prozessstart

GitHub stellt Copilot-Abrechnung auf Flex-Modelle um

Base Credits + Flex-Kontingent = AI Credits

Fallback auf einfachere Modelle entfällt

Symphonia 0.6: Rust-Audioframework wird multimedial

Neue Architektur trennt Tracks und Codecs

Weniger Kopien, mehr Metadatenformate

Neu geschriebene Demuxer und SIMD ab Werk

Genauere Formaterkennung und neue MSRV-Policy

Neu in .NET 10.0 [23]: Neue LINQ-Operatoren LeftJoin() und RightJoin()

software-architektur.tv: John Romeros Prinzipien – mit Tom Asel

Empfohlener redaktioneller Inhalt

Livestream am 15. Mai

Von undefiniert zu definiert: Die Verwendung von std::launder in C++

Wann es zu Problemen kommen kann

Wenn es komplizierter wird

std::launder zur Rettung

Zusammenfassung

KI-Portierung: Claude schreibt Bun-Codebasis in Rust neu

Fragen offen

Was kostet das?

SAP investiert: n8n wird eines der wertvollsten deutschen KI-Startups

Automatisierung und KI-Kundenservice

SAP shoppt Start-ups

Red Hat baut Ansible zur Steuerzentrale für KI-Agenten um

Rechte begrenzen und kontrollieren

Ansible 2.7: Mehr Transparenz und MCP-Server

C-Libraries in Java nutzen 2: Funktionen mit veränderlichen Parametern

Funktionen mit veränderbarem Parameter

Funktionen mit einem Array-Parameter

KI-Ära erzwingt Reformen: GitLab strukturiert um

`std::launder` zur Rettung