Anmelden
(Bild: Moritz Förster / KI / iX)
Microsofts neuer PostgreSQL-Dienst Azure HorizonDB ist als Public Preview verfügbar. Er skaliert bis 128 TByte und 3072 vCores und bringt Vektorsuche mit.
Auf seiner Entwicklerkonferenz Build 2026 hat Microsoft den Datenbankdienst Azure HorizonDB als Public Preview freigegeben. Der Dienst basiert auf PostgreSQL und richtet sich an Unternehmen mit großen Cloud-Anwendungen und datenintensiven KI-Workloads. Microsoft verspricht eine Architektur, die bis zu 128 TByte Speicher und bis zu 3072 vCores unterstützt, dazu integrierte Funktionen für Vektorsuche und KI-Anwendungen.
Angekündigt hatte der Konzern den Dienst bereits auf der Ignite 2025 [1]. Anders als das bestehende Azure Database for PostgreSQL stellt HorizonDB nicht einfach eine verwaltete PostgreSQL-Instanz bereit, sondern eine Plattform, die Microsoft eigenen Angaben zufolge für horizontale Skalierung und hohe Verfügbarkeit entwickelt hat. Mit der Public Preview [2] können Unternehmen den Dienst nun ohne gesondertes Vorschauprogramm testen, zunächst allerdings nur in fünf Azure-Regionen (Central US, West US 2, West US 3, Sweden Central und Australia East).
Ein zentrales Merkmal von HorizonDB [3] ist die Möglichkeit, Rechenleistung und Speicher unabhängig voneinander zu skalieren. Damit unterscheidet sich der Dienst von klassischen PostgreSQL-Installationen, die meist vertikal skalieren – also über größere virtuelle Maschinen mit mehr Arbeitsspeicher und mehr CPU-Kernen. HorizonDB setzt dagegen auf Scale-out: Unternehmen schalten zusätzliche Compute-Knoten zu, ohne gleichzeitig den Speicher ausbauen zu müssen. Betreiber großer E-Commerce-Plattformen oder SaaS-Dienste könnten Lastspitzen so leichter abfangen.
Microsoft hebt zudem die Ausfallsicherheit hervor. HorizonDB repliziert Daten standardmäßig über mehrere Availability Zones hinweg, also über physisch getrennte Rechenzentren innerhalb einer Azure-Region. Fällt eines dieser Rechenzentren aus, soll die Datenbank weiter erreichbar bleiben. Für Schreibvorgänge zwischen den Zonen verspricht Microsoft Latenzen im Submillisekundenbereich. Relevant ist das vor allem für geschäftskritische Transaktionssysteme, etwa im Finanzsektor oder bei SaaS-Plattformen, die auf durchgängige Verfügbarkeit angewiesen sind.
Einen weiteren Schwerpunkt legt Microsoft auf KI-Anwendungen. HorizonDB beherrscht Vektoreinbettungen (Vector Embeddings) und Vektorsuche direkt in der Datenbank. Solche Vektoren bilden Inhalte wie Texte, Bilder oder Dokumente als numerische Merkmalsvektoren ab und sind die Grundlage für semantische Suche. Statt nach exakten Schlüsselwörtern zu suchen, finden Anwendungen damit Inhalte mit ähnlicher Bedeutung – ein Verfahren, das unter anderem bei Retrieval-Augmented Generation (RAG) und in Wissensdatenbanken für KI-Agenten eingesetzt wird.
Die Vektorsuche läuft dabei direkt in HorizonDB, eine separate Vektordatenbank entfällt. Zusätzlich lässt sich der Dienst nach Angaben von Microsoft mit der hauseigenen Foundry-Plattform verbinden. Damit will der Konzern Datenhaltung und KI-Infrastruktur enger verzahnen und den Bedarf an separaten Datenpipelines verringern.
Für Unternehmen dürften auch die Sicherheitsfunktionen eine Rolle spielen. HorizonDB lässt sich an Entra ID anbinden, verschlüsselt Daten im Ruhezustand sowie bei der Übertragung und unterstützt private Netzwerkendpunkte.
Mit HorizonDB folgt Microsoft dem Trend in der Cloud-Branche: Statt für jede Aufgabe eine spezialisierte Datenbank vorzuhalten, sollen Datenplattformen Transaktionen, Analysen und KI-nahe Workloads in einem System bündeln. PostgreSQL entwickelt sich dabei mehr und mehr zur gemeinsamen Grundlage solcher Angebote.
URL dieses Artikels:
https://www.heise.de/-11319972
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Wolf Hosbach / KI / iX)
Eine Lücke auf Github.dev – VS Code im Browser – ermöglichte es Angreifern, alle Repos eines Anwenders zu verseuchen, um verschiedene Angriffe zu starten.
Die Web-Version des Editors VS Code auf GitHub.dev [1] hatte eine Sicherheitslücke, die es Angreifern erlaubt hat, sämtliche Repos eines Opfers zu übernehmen – auch private. Sie hätten hier Lieferkettenangriffe mit weiterem Schadcode initiieren oder einen Maintainer gezielt attackieren können.
Jeder GitHub-Anwender hätte über einen bösartigen Link schnell Opfer werden können. Durch eine Kombination aus eingebetteten Vorschaufenstern mit von JavaScript erzeugten Tastenschlägen hätten Angreifer unbemerkt eine Extension installieren können, die das Zugangs-Token für sämtliche Repos klaut, auf die das Opfer Zugriff hat. Auch die Desktop-Version war prinzipiell betroffen, jedoch mit höheren Hürden. Microsoft hat inzwischen Gegenmaßnahmen ergriffen und verhindert nun, dass Angreifer die Warnung vor einer nicht vertrauenswürdigen Umgebung ausschalten können.
Der Sicherheitsforscher Ammar Askar hat den Angriff in seinem Blog [2] im Detail beschrieben: GitHub bietet eine Version von VS Code im Web unter github.dev. (Genauer genommen ist VS Code ursprünglich eine Webanwendung, die via Electron im Desktop läuft.) Jeder GitHub-Anwender kann seine Repos mit github.dev/user/repo statt github.com/user/repo unmittelbar in einer VS-Code-Umgebung im Browser öffnen, bearbeiten und verwalten.
Dadurch, dass die Web-App „fast die gesamte Ladung der Millionen Zeilen der TypeScript-Codebasis ausführt, eignet sie sich hervorragend als Ziel für jeden, der Bugs in VS Code sucht“, hebt Askar hervor. Im Prinzip schützt der Editor die Anwenderinnen und Anwender durch verschiedene Sandbox-Mechanismen jedoch vor der Übermacht der JavaScript-Funktionen.
Der Angriff nutzt die Funktion Webview [3], die externe Inhalte in einer Sandbox in einem Iframe ausführt, zum Beispiel um Markdown zu rendern oder Jupyter-Notebooks zu bearbeiten. Intern haben Webviews eine andere Code-Quelle: vscode-webview://... statt vscode-file://... und damit keinen Zugriff auf die Node.js-APIs, auf denen VS Code basiert. Aber es gibt einen Informationsaustausch über Messages mit der übergeordneten Hauptseite. So nimmt Webview Tasten-Events (keydown) für das Hauptfenster entgegen, beispielsweise Strg-Shift-P, um die Befehlspalette von VS Code zu öffnen. Über diese wiederum lassen sich Extensions installieren. Um dann die Installation der Extension zu bestätigen, dient Strg-Shift-A, was immer den Default-Button einer Meldung wählt, hier „Install“ für Erweiterungen.
Ein Angreifer kann nun Tastatureingaben einfach mit JavaScript-Code emulieren, um die Installation einer Extension anzustoßen. Askar zeigt, wie sich weitere Sicherheitsmechanismen einfach aushebeln ließen, darunter die Warnung an das Opfer, dass ein neuer Extension-Herausgeber etwas installieren will. Diese Überprüfung konnte Askar über das Vorspielen einer vertrauenswürdigen Local Workspace Extension umgehen – eine Schwachstelle, die Microsoft laut Askar inzwischen bereinigt hat.
Der Forscher demonstriert den Angriff mit einem Jupyter-Notebook, das über einen github.dev-Link wie https://github.dev/angreifer/blob/main/README.ipynb oder über eine Umleitung darauf lädt. Die bösartige Extension tritt dann unbemerkt in Aktion und klaut das Token, mit dem sie Zugriff auf alle Repos bekommt, auf die auch das Opfer Zugriff hat – GitHub vergibt nur ein Token für alle Verzeichnisse.
Nur Anwender, die github.dev noch nicht oder länger nicht mehr benutzt haben, bekommen einmal die Warnung „The extension 'GitHub Repository' wants to sign in using GitHub“. Im Blog von Askar findet sich ein Demo-Link, den die heise-developer-Redaktion jedoch nicht auf Sicherheit überprüft hat.
URL dieses Artikels:
https://www.heise.de/-11319754
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: 13_Phunkod / Shutterstock.com)
Entwickler können begonnene VS-Code-Chats nun auf anderen Geräten fortführen und OpenAI- sowie Anthropic-Modelle erhalten ein vergrößertes Kontextfenster.
Microsoft bringt in Version 1.123 von Visual Studio Code weitere neue Features für den Umgang mit großen Sprachmodellen. Dazu gehören synchronisierte Chat-Sessions über mehrere Geräte hinweg, ein vergrößertes Kontextfenster für spezielle Modelle und die Möglichkeit, multiple Agenten-Fenster parallel zu öffnen.
Als neue Standardfunktion synchronisiert Visual Studio Code nun Chat-Sessions zum GitHub-Account seiner Nutzerinnen und Nutzer, inklusive aller lokalen Agenten-Sessions. Wie Microsoft betont, seien die synchronisierten Chats privat, außer wenn Nutzer sie explizit teilen. Auf github.com erscheinen die Chats im Agents-Tab eines Repositories und lassen sich durchsuchen [1].
Wer die Synchronisierung nicht nutzen will, setzt die auf Organisationsebene bestehende Einstellung chat.sessionSync.enabled auf false.
Das Preview-Feature Agents Window hat eine neue Funktion erhalten: Neben einer geöffneten Agenten-Session lässt sich nun eine zusätzliche in „Side by Side“-Ansicht öffnen. Um eine weitere Session zu öffnen, wählen Entwicklerinnen und Entwickler im Kontextmenü einer Session innerhalb der Session-Liste Open to the Side aus, ziehen die gewünschte Session per Drag & Drop in den Sessions-Ansichtsbereich oder wählen sie bei gedrückter Alt-Taste aus.
Dabei ist zu beachten, dass jeweils nur eine der sichtbaren Sessions aktiv ist. Eine neue ausgewählte Session wird automatisch zur aktiven Session View, außer wenn die vorherige Session angepinnt wurde. Das Anpinnen erfolgt über die Pin-Aktion in der oberen rechten Ecke der View.
(Bild: Microsoft)
Ein weiteres Update betrifft das Kontextfenster unterstützter Anthropic- und OpenAI-Modelle: Es kann nun eine Million Token umfassen. Diese Erweiterung soll es Usern ermöglichen, mit deutlich größeren Codebasen zu arbeiten sowie längere Konversationen zu führen, ohne wichtigen Kontext einzubüßen.
Weitere Details zu den Neuerungen in Visual Studio Code 1.123 lassen sich der Ankündigung entnehmen [2].
Dabei handelt es sich nicht um die einzigen Updates im Bereich KI von Microsoft: Im Rahmen der in dieser Woche stattgefundenen Hauskonferenz Microsoft Build wurde unter anderem eine eigenständige Desktopanwendung für GitHub Copilot [3] vorgestellt.
Siehe auch:
URL dieses Artikels:
https://www.heise.de/-11319338
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Pincasso / Shutterstock.com)
LINQ-Operationen sind nun auch auf Mengen des Typs IAsyncEnumerable
IAsyncEnumerable<T> ist die in .NET Core 3.0 eingeführte asynchrone Variante von IEnumerable<T>. Sie ermöglicht asynchrone Streams: das schrittweise, nicht-blockierende Iterieren über Daten, die asynchron bereitgestellt werden.
LINQ-Operationen auf IAsyncEnumerable<T> erforderten bisher das NuGet-Paket System.Linq.Async. Nun ist diese Funktionalität im Kern von .NET verfügbar.
Folgender Code nutzt Where() und OrderBy() mit IAsyncEnumerable<T>:
FreshRSS namespace NET10_Console.FCL;
using System.Collections.Generic;
using System.Runtime.CompilerServices;
using System.Threading;
using System.Threading.Tasks;
public readonly record struct Kabinettsmitglied(string Name, string Amt);
/// <summary>
/// LINQ auf IAsyncEnumerable<T> erforderte bisher NuGet-Paket System.Linq.Async
/// </summary>
public class FCL10_LINQAsyncEnumerable
{
public async Task Run()
{
CUI.Demo(nameof(FCL10_LINQAsyncEnumerable));
// Hole Personen im Bundeskabinett
var datenquelle = new Bundeskabinett().GetAll();
// Asynchrone Iteration mit LINQ (Filtern und optional Sortieren)
// Achtung: .OrderBy(x=>x.Name) führt dazu, dass foreach auf das letzte Element warten muss --> Vorteil von async entfällt :-(
await foreach (var person in datenquelle.Where(x => x.Amt.Contains("ministerin")))
{
Console.WriteLine(DateTime.Now.ToLongTimeString() + ": " + person);
}
}
public class Bundeskabinett
{
/// <summary>
/// Liefert alle Mitglieder des Bundeskabinetts (Stand: 21.09.2025) als Async-Stream.
/// Quelle: Bundesregierung.de (siehe Code-Kommentar).
/// </summary>
public async IAsyncEnumerable<Kabinettsmitglied> GetAll(
[EnumeratorCancellation] CancellationToken cancellationToken = default)
{
// Quelle: https://www.bundesregierung.de/breg-de/bundesregierung/bundeskabinett
var daten = new List<Kabinettsmitglied>
{
new("Friedrich Merz", "Bundeskanzler"),
new("Lars Klingbeil", "Bundesminister der Finanzen"),
new("Alexander Dobrindt", "Bundesminister des Innern"),
new("Dr. Johann Wadephul", "Bundesminister des Auswärtigen"),
new("Boris Pistorius", "Bundesminister der Verteidigung"),
new("Katherina Reiche", "Bundesministerin für Wirtschaft und Energie"),
new("Dorothee Bär", "Bundesministerin für Forschung, Technologie und Raumfahrt"),
new("Dr. Stefanie Hubig", "Bundesministerin der Justiz und für Verbraucherschutz"),
new("Karin Prien", "Bundesministerin für Bildung, Familie, Senioren, Frauen und Jugend"),
new("Bärbel Bas", "Bundesministerin für Arbeit und Soziales"),
new("Dr. Karsten Wildberger", "Bundesminister für Digitales und Staatsmodernisierung"),
new("Patrick Schnieder", "Bundesminister für Verkehr"),
new("Carsten Schneider", "Bundesminister für Umwelt, Klimaschutz, Naturschutz und nukleare Sicherheit"),
new("Nina Warken", "Bundesministerin für Gesundheit"),
new("Alois Rainer", "Bundesminister für Landwirtschaft, Ernährung und Heimat"),
new("Reem Alabali Radovan", "Bundesministerin für wirtschaftliche Zusammenarbeit und Entwicklung"),
new("Verena Hubertz", "Bundesministerin für Wohnen, Stadtentwicklung und Bauwesen"),
new("Thorsten Frei", "Bundesminister für besondere Aufgaben / Chef des Bundeskanzleramtes"),
};
foreach (var m in daten)
{
cancellationToken.ThrowIfCancellationRequested();
yield return m;
await Task.Delay(200); // Simuliere etwas Wartezeit
await Task.Yield(); // sorgt für echte Asynchronität beim Streamen
}
}
}
}
Ein Praxisbeispiel dazu: Folgender Code zeigt die Ausführung einer Reihe von HTTP-Aufrufen mit asynchroner Ausgabe der Ergebnisse via Task.WhenEach(). Hier ist nun ein Filtern mit Where() oder eine Sortierung mit OrderBy() möglich. Diese blockiert jedoch – wie üblich – die Weiterverarbeitung, bis das letzte Ergebnis vorliegt, und beeinträchtigt damit den Vorteil der asynchronen Ausführung.
public async Task Run()
{
CUI.Demo(nameof(FCL10_LINQAsyncEnumerable));
Console.WriteLine($"{DateTime.Now.ToLongTimeString()}: Starte Websiteabfragen...");
using HttpClient http = new();
Task<HttpResponseMessage> t1 = http.GetAsync("https://www.CNN.com");
Task<HttpResponseMessage> t2 = http.GetAsync("https://microsoft.com");
Task<HttpResponseMessage> t3 = http.GetAsync("https://www.dotnetframework.de");
Task<HttpResponseMessage> t4 = http.GetAsync("https://www.dotnet-lexikon.de");
Task<HttpResponseMessage> t5 = http.GetAsync("https://www.dotnet9.de");
Task<HttpResponseMessage> t6 = http.GetAsync("https://www.dotnet10.de");
Task<HttpResponseMessage> t7 = http.GetAsync("https://www.web.de");
// Liste aus Tasks
List<Task<HttpResponseMessage>> taskList = new() { t1, t2, t3, t4, t5, t6, t7 };
// WhenEach() gibt es seit .NET 9.0
IAsyncEnumerable<Task<HttpResponseMessage>> taskList2 = Task.WhenEach(taskList);
// NEU in .NET 10.0: LINQ auf IAsyncEnumerable<T>
taskList2 = taskList2.Where(x => x.Result.RequestMessage.RequestUri.ToString().Contains("dot"));
taskList2 = taskList2.OrderBy(x => x.Result.RequestMessage.RequestUri.Host);
await foreach (Task<HttpResponseMessage> t in taskList2)
{
try
{
Console.WriteLine($"{DateTime.Now.ToLongTimeString()}: {t.Status} {t.Result?.RequestMessage?.RequestUri} = {t?.Result?.StatusCode}"); // Status des HTTP-Aufrufs
}
catch (Exception ex)
{
CUI.Warning(ex);
}
}
}
URL dieses Artikels:
https://www.heise.de/-11303609
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Cloudflare)
Cloudflare übernimmt VoidZero und damit das Team hinter Vite, Vitest und Co. Die Werkzeuge sollen quelloffen und herstellerneutral bleiben.
Cloudflare übernimmt VoidZero, das Unternehmen hinter den JavaScript-Werkzeugen Vite, Vitest, Rolldown, Oxc und Vite+. Das gab der Cloud- und Netzwerkdienstleister am Donnerstag in einem Blogbeitrag [1] bekannt. Mit der Übernahme wechselt auch das gesamte VoidZero-Team um Gründer Evan You zu Cloudflare. Zu den finanziellen Konditionen machen beide Unternehmen keine Angaben. Auch zum Zeitplan, zu möglichen behördlichen Genehmigungen und zu weiteren Abschlussbedingungen gibt es bislang keine weiteren Informationen.
Für Entwickler dürfte vor allem die Zukunft der Open-Source-Projekte zählen. Hier betonen Cloudflare und VoidZero explizit, dass Vite, Vitest, Rolldown, Oxc und Vite+ quelloffen, herstellerneutral und community-getrieben bleiben sollen. Die Projekte bleiben demnach wie gehabt Open-Source-Software. Und Anwendungen, die auf Vite aufbauen, sollen sich weiterhin unabhängig von Cloudflare auch auf anderen Plattformen betreiben lassen.
VoidZero [2] stammt von Evan You, der auch das JavaScript-Framework Vue.js entwickelt hat. Das Unternehmen baut eine ganze Reihe von Werkzeugen für moderne Webanwendungen. Dazu gehören das Build- und Entwicklungswerkzeug Vite [3], das Test-Framework Vitest [4], der in Rust geschriebene Bundler Rolldown sowie die ebenfalls in Rust entwickelte Toolchain Oxc, die Komponenten zum Parsen, Linten und Formatieren von JavaScript- und TypeScript-Code mitbringt. Mit Vite+ [5] will VoidZero diese Werkzeuge unter einer einheitlichen Toolchain zusammenführen.
Vor allem Vite hat sich in den vergangenen Jahren zu einer zentralen Infrastruktur des JavaScript-Ökosystems entwickelt. Das Werkzeug treibt längst nicht mehr nur Vue-Projekte an, sondern bildet auch die Grundlage zahlreicher Frameworks und Meta-Frameworks wie Nuxt, SvelteKit, Astro, Solid, Qwik oder Angular. Auch mehrere React-basierte Werkzeuge setzen inzwischen auf Vite.
Cloudflare will zusätzliche Ressourcen in die Weiterentwicklung der Projekte stecken. Die Leitung sollen weiterhin Evan You und das bisherige VoidZero-Team übernehmen. Darüber hinaus richtet das Unternehmen einen Fonds über eine Million US-Dollar für das Vite-Ökosystem ein. Damit will Cloudflare Maintainer und weitere Community-Mitglieder unterstützen. Verwalten soll den Fonds das Vite-Kernteam. Ähnlich verfuhr Cloudflare eigenen Angaben zufolge bereits Anfang 2026 beim Web-Framework Astro [6]: Auch dessen Team wechselte zu Cloudflare, ebenfalls unter Beibehaltung der Open-Source-Ausrichtung.
Hinter der Übernahme steckt eine Zusammenarbeit der Unternehmen, die schon länger läuft. Cloudflare und das Vite-Team arbeiten nach eigenen Angaben seit 2024 zusammen, unter anderem an der Environment API. Sie erlaubt es, Server-Code während der lokalen Entwicklung in anderen Laufzeitumgebungen als Node.js auszuführen.
Damit adressiert die Schnittstelle ein altbekanntes Problem: Viele Anwendungen entstehen lokal unter Node.js, laufen in der Produktion aber in einer anderen Laufzeitumgebung. Genau diese Unterschiede zwischen Entwicklung und Produktion führen immer wieder zu Fehlern. Über die Environment API können Anbieter ihre eigenen Laufzeiten direkt in den lokalen Entwicklungsprozess einklinken. Bei Cloudflare übernimmt das die quelloffene Laufzeitumgebung workerd, die auch den Dienst Cloudflare Workers antreibt.
Die Übernahme soll außerdem die künftige Entwicklerplattform von Cloudflare prägen. Das Unternehmen will seine Werkzeuge stärker an Vite ausrichten. So soll das neue Cloudflare-CLI-Tool cf langfristig auf Vite-Workflows aufsetzen. Lokale Entwicklung, Builds und das Deployment auf die Cloudflare-Plattform würden dadurch enger zusammenrücken.
Auch für Vite selbst kündigen die Unternehmen weitergehende Pläne an. Das Projekt soll künftig stärker Full-Stack-Anwendungen unterstützen. Geplant sind unter anderem allgemeine Schnittstellen für Backends, APIs, Deployments und KI-Agenten. Diese Erweiterungen sollen aber plattformneutral bleiben und nicht exklusiv an Cloudflare-Dienste gebunden sein.
URL dieses Artikels:
https://www.heise.de/-11318973
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: PixieMe/shutterstock.com)
Perplexity kündigt einen hybriden Inferenz-Orchestrator an, der KI-Aufgaben automatisch zwischen lokalem Gerät und Cloud aufteilt.
Perplexity hat einen Hybrid-Ansatz für KI-Inferenz angekündigt, der Aufgaben automatisch zwischen dem lokalen Rechner und Cloud-Servern aufteilt. Der sogenannte „Personal Computer“, Perplexitys Variante von persönlichen Desktop-Agenten, der jetzt bald auch für Windows und Mac verfügbar ist, [1] soll sensible Daten auf dem Gerät halten und rechenintensive Arbeit in die Cloud auslagern – ohne dass Nutzer vorab entscheiden müssen, wo etwas verarbeitet wird.
Perplexity beschreibt [2] den neuen Dienst als kompaktes KI-Modell, das lokal auf dem Gerät läuft und entscheidet, welche Teile einer Anfrage dort verbleiben und welche an ein leistungsfähigeres Frontier-Modell in der Cloud gehen sollen. Als typische Anwendungsfälle nennt das Unternehmen den Umgang mit Finanzunterlagen, Gesundheitsinformationen und persönlichen Dateien – also Daten, die aus Datenschutzgründen das Gerät möglichst nicht verlassen sollten.
Ganz neu ist Perplexitys hybrider Ansatz nicht, andere Anbieter haben ähnliche Ansätze. Microsoft verfolgt zum Beispiel mit Copilot+ PCs und lokalen NPU-Funktionen ebenfalls einen Hybridkurs, auch wenn viele Copilot-Funktionen weiterhin eine Cloud-Verbindung benötigen.
Der wesentliche Unterschied liegt laut VentureBeat [3] wohl im Anspruch, die Aufteilung vollautomatisch und aufgabenweise, teils auch während die Aufgabe läuft, vorzunehmen. Auf dem Level, auf dem Perplexity das auf der Computex demonstriert hat, sind andere Anbieter bisher nicht.
Ab Juli soll Personal Computer mit lokaler Inferenz verfügbar werden und dabei helfen, aktuell typische Zielkonflikte zwischen drei Faktoren zu reduzieren: Genauigkeit und komplexe Aufgaben erfordern die leistungsfähigsten, rechenintensiven Modelle, Datenschutz verlangt lokale Verarbeitung und Kosten verlangen einen effizienten Mix zwischen leistungsstarken und günstigen Modellen – je nach Aufgabe. Die Orchestrierung zwischen diesen Anforderungen sei das eigentliche Problem. Genau das wolle der Hybrid-Ansatz nun lösen.
Perplexity stellte den Hybrid-Orchestrator gemeinsam mit Intel vor. Der modellagnostische Orchestrierungsrahmen soll aber auch auf anderer lokaler Hardware laufen, darunter Nvidias RTX Spark [4]. Konkrete Hardware-Mindestanforderungen – etwa zur nötigen NPU- oder GPU-Leistung – nennt Perplexity bislang nicht. Der Computerhersteller HP hat zum Beispiel für Microsofts hybrides Modell Copilot+ PC entschieden [5], dass Laptops für das Copilot+ PC-Label eine dedizierte Neural Processing Unit (NPU) von mindestens 40 TOPS benötigen.
Ebenso fehlen bei Perplexity noch technische Details zu den Routing-Regeln: Wie genau das lokale Modell entscheidet, welche Daten als sensibel gelten und welche Metadaten dennoch an Perplexity-Server übertragen werden könnten, bleibt offen.
Wie belastbar das Datenschutzversprechen im Alltag ist, lässt sich auch erst bewerten, wenn Perplexity technische Dokumentation zu Modellgrößen, Speicherbedarf und dem Umgang mit Telemetriedaten veröffentlicht.
URL dieses Artikels:
https://www.heise.de/-11318486
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: maxuser / Shutterstock.com)
GitHub hat auf der Microsoft Build eine Desktop-App vorgestellt, die parallele KI-Agentensitzungen bündelt und mit Agent Merge den CI/CD-Prozess begleitet.
GitHub hat im Rahmen der Microsoft Build 2026 eine eigenständige Desktop-Anwendung für seinen KI-Assistenten Copilot vorgestellt. Wie das Unternehmen in der Ankündigung ausführt, soll die Copilot-App als zentrale Oberfläche dienen, über die sich mehrere KI-Agentensitzungen parallel starten, beobachten und steuern lassen. Verfügbar ist die Software zunächst als Technical Preview für Abonnenten der Tarife Copilot Pro, Pro+, Business und Enterprise. In den beiden Business-Plänen müssen Administratoren vorab Preview-Funktionen sowie die Copilot-CLI in den Richtlinieneinstellungen freischalten.
Als Motivation hinter der neuen App führt GitHub in seinem Blog [3] an, dass die bislang verfügbaren Werkzeuge nicht auf den parallelen Einsatz mehrerer Agenten ausgelegt seien. Kontextinformationen verteilten sich über verschiedene Fenster, laufende Prozesse seien schwer nachzuverfolgen, und von Agenten erzeugter Code lande in Pull-Requests, ohne dass die Vorgeschichte dokumentiert sei. Nach Angaben des Unternehmens hat sich die Zahl der Commits auf der Plattform im Jahresvergleich nahezu verdoppelt und liegt bei mehr als 1,4 Milliarden pro Monat, parallel werden über zwei Milliarden Minuten GitHub Actions pro Woche verbraucht. Daraus leitet GitHub [4] die Notwendigkeit ab, die zugrunde liegenden Systeme für agentengetriebene Arbeitsabläufe zu härten.
Zentrales Element der Anwendung ist eine Ansicht namens „My Work“. Sie führt aktive Agentensitzungen, Issues, Pull-Requests und Hintergrundautomatisierungen aus mehreren Repositories in einer gemeinsamen Oberfläche zusammen. Damit sollen Entwicklerinnen und Entwickler auf einen Blick erkennen, wo Handlungsbedarf besteht – etwa wenn ein Agent einen Bug in der Produktion analysiert, ein zweiter eine Backlog-Aufgabe abarbeitet und ein dritter Feedback aus einem Code-Review umsetzt. Über einen Posteingang lassen sich aus offenen Issues oder Pull-Requests direkt neue Sessions starten, ohne zwischen Browser-Tabs und lokalen Werkzeugen wechseln zu müssen.
Technisch läuft jede Agentensitzung in einem eigenen git worktree, also einer realen, isolierten Kopie des jeweiligen Branches. Dadurch sollen mehrere Agenten parallel an demselben Repository arbeiten können, ohne sich gegenseitig Änderungen zu überschreiben. Die App verwaltet diese Worktrees laut GitHub vollständig selbst: Sie legt sie automatisch an, trennt sie pro Session und entfernt sie nach Abschluss wieder. Allerdings verhindere diese Architektur Merge-Konflikte nur innerhalb der einzelnen Arbeitsverzeichnisse; beim späteren Zusammenführen in gemeinsame Branches könnten divergierende Änderungen weiterhin zu Konflikten führen. Zudem belegen parallele Worktrees lokale Ressourcen wie Speicherplatz und Dateihandles – das sollten Entwicklungsteams bei CI- und Backup-Konzepten unbedingt berücksichtigen.
Mit „Agent Merge“ hat GitHub zudem eine Funktion vorgestellt, die Pull-Requests durch Review, Continuous Integration und Merge begleiten soll. Das Werkzeug überwacht die CI-Pipelines, verfolgt erforderliche Reviewer, reagiert auf fehlgeschlagene Checks und wartet, bis alle Bedingungen erfüllt sind. Für Organisationen mit etablierten CI/CD-Prozessen betont der Hersteller, dass bestehende Review- und Merge-Anforderungen weiterhin gelten. Branch Protection Rules, verpflichtende Status-Checks und Reviewer-Vorgaben blieben aktiv. Teams können laut Ankündigung konfigurieren, wie weit Agent Merge eingreifen darf – ob es lediglich CI-Läufe wiederholt, Feedback aus Reviews umsetzt oder unter definierten Bedingungen auch automatisch Merges vollzieht.
Standardmäßig fordert der Cloud-Agent vor jedem schreibenden Vorgang eine Erlaubnis ein, etwa vor dem Anlegen eines Issues oder dem Hinterlassen eines Kommentars. Erst wenn ein Team genügend Vertrauen in die Automatisierung gefasst hat, lässt sich ein Autopilot-Modus aktivieren. GitHub betont, dass die Verantwortung für Richtlinien und für die Frage, welche Automatisierungen erlaubt sind, bei den jeweiligen Organisationen bleibt. Für mehr Nachvollziehbarkeit sollen sogenannte „Canvases“ sorgen. Damit sind bidirektionale Arbeitsflächen für Menschen und Agenten gemeint, auf denen Pläne, Zwischenstände und Entscheidungen sichtbar bleiben, anstatt im Chatverlauf unterzugehen.
Ergänzend führt GitHub lokale und cloudbasierte Sandboxes ein, in denen Agenten Code ausführen, testen und iterieren sollen, ohne bereits Produktivsysteme zu berühren. Bei lokaler Ausführung läuft Copilot in einer isolierten Umgebung mit eingeschränktem Zugriff auf das Dateisystem, das Netzwerk und die Systemfunktionen. Cloud-Sandboxes nutzen dazu kurzlebige Linux-Umgebungen, die GitHub selbst betreibt. Die Richtlinien dafür legen Organisationen jeweils selbst fest – ein Punkt, der für Unternehmen mit strengen Compliance-Anforderungen relevant sein dürfte.
Die Copilot-Code-Review wurde um einen „Medium Tier“ erweitert, der Pull-Requests an ein leistungsfähigeres Modell weiterreicht. Auf Repository-Ebene können Administratoren entscheiden, ob ein kostengünstigeres oder ein präziseres Modell eingesetzt wird, etwa stärkere Modelle für sicherheitskritische Codebasen. Ergänzt wird das Review durch spezielle Skills wie /security-review und /rubberduck. Das GitHub-Copilot-SDK steht ab sofort generell zur Verfügung (GA), unter anderem für Node.js, Python, Go, .NET, Rust und Java. Teams sollen damit eigene agentische Werkzeuge auf demselben Runtime-Unterbau entwickeln können.
Auch die Copilot-CLI hat GitHub überarbeitet. Eine neue textbasierte Oberfläche mit Tabs gehört ebenso zu den Neuerungen wie eine On-Device-Spracherkennung, bei der Audiodaten das Gerät nach Angaben des Anbieters nicht verlassen, sowie geplante Aufgaben über den Befehl /every. Als Partner im Ökosystem nennt GitHub unter anderem LaunchDarkly, PagerDuty, Sonar und Miro, die als Agent-Apps in Copilot integriert werden sollen.
URL dieses Artikels:
https://www.heise.de/-11317392
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Microsoft / Moritz Förster / KI / iX)
Mit den neuen Dev Configs von Microsoft wird aus einer Windows-Installation per Einzeiler ein fertiger Entwicklerarbeitsplatz – inklusive WSL und Ubuntu.
Microsoft hat mit Dev Configs for Windows eine Open-Source-Sammlung von Konfigurationen veröffentlicht, die Entwicklerarbeitsplätze unter Windows automatisiert einrichtet. Die Konfigurationen bauen auf der WinGet-Funktion winget configure auf und sollen einen frisch installierten Rechner mit einem einzigen Befehl in eine einsatzbereite Entwicklungsumgebung verwandeln. Sie sind deklarativ aufgebaut, durchlaufen automatisierte Tests und lassen sich laut Microsoft gefahrlos mehrfach ausführen.
Das Projekt zielt auf Entwickler, die ihre Arbeitsumgebung reproduzierbar aufsetzen wollen – auf einem neuen Notebook, einer Testmaschine oder in Teams mit standardisierten Setups. Statt eigene Installationsskripte zu pflegen, beschreiben die Konfigurationen den gewünschten Endzustand eines Systems. Microsoft unterscheidet drei Anwendungsfälle: einen vollständigen Entwicklerarbeitsplatz für Windows, eine erweiterte Shell-Umgebung für WSL sowie einzelne Sprach- und Framework-Workloads.
Die umfangreichste Variante heißt „Windows Dev Config“. Sie installiert typische Entwicklerwerkzeuge, darunter PowerShell 7, Git, GitHub CLI, Visual Studio Code, .NET SDK 10, Python 3.13 mitsamt dem Paketmanager uv, Node.js, Oh My Posh und die PowerToys. Zusätzlich passt die Konfiguration Windows selbst an und aktiviert etwa den Entwicklermodus, lange Dateipfade und den Dark Mode. Auch Datei-Explorer, Startmenü, Suche und Edge erhalten neue Voreinstellungen.
Einen Schwerpunkt legt Microsoft auf das Windows-Subsystem für Linux [1] (WSL). Die Konfiguration installiert WSL samt Ubuntu und überbrückt den dafür nötigen Neustart automatisch. Dazu nutzt sie den Windows-Mechanismus RunOnce, der eine Aufgabe nach dem nächsten Anmelden einmalig ausführt. Anwender müssen nach dem Reboot nicht eingreifen – die Installation läuft selbstständig durch.
Ferner bietet Microsoft mit „WSL Comfort“ eine Konfiguration speziell für die Arbeit mit Linux unter Windows. Sie läuft wahlweise interaktiv oder mit dem Schalter -NonInteractive unbeaufsichtigt und richtet sowohl die Windows- als auch die Linux-Seite ein. Anwender wählen zwischen Bash und Zsh und können optional den Prompt-Generator Starship, Homebrew oder verschiedene moderne Kommandozeilenwerkzeuge dazunehmen. Das Linux-Skript comfort-shell-bootstrap.sh läuft auch eigenständig auf jedem Ubuntu-Host.
Zu diesen Werkzeugen zählen rg (ripgrep) für schnelle Volltextsuchen im Quellcode, bat als Alternative zu cat mit Syntaxhervorhebung, zoxide für eine lernfähige Verzeichnisnavigation sowie fzf, fd, eza und jq. Auf der Windows-Seite richtet die Konfiguration ein angepasstes Profil für das Windows-Terminal sowie die Schriftart Cascadia Code Nerd Font ein. Nerd Fonts enthalten zusätzliche Symbole, die moderne Shell-Prompts etwa für Git-Branches oder Statusanzeigen nutzen.
Wer keine vollständige Entwicklungsumgebung benötigt, kann stattdessen einzelne Workloads installieren. Microsoft nennt unter anderem TypeScript, Python, .NET, Go, Java, Rust, PHP, WinForms und WinUI 3. Jede dieser Konfigurationen bringt eine eigene Datei configuration.winget mit sowie ein Hilfsskript install.ps1, das die Installation anstößt und die PATH-Variable in der aktuellen Shell-Sitzung aktualisiert.
Technisch knüpfen die Dev Configs an die vorhandenen Konfigurationsfunktionen von WinGet an. Die Dateien beschreiben Pakete, Systemeinstellungen und Nachinstallationsschritte deklarativ. Da sie den Zielzustand statt einzelner Schritte definieren, lassen sich Setups zuverlässig wiederholen und auf weitere Rechner übertragen. Voraussetzung ist eine aktuelle Version des App Installers; falls winget configure nicht verfügbar ist, lässt sich die Funktion einmalig mit winget configure --enable aktivieren.
Bereits angekündigt ist eine Erweiterung für die Command Palette der PowerToys. Sie soll die im Projekt definierten Konfigurationsabläufe direkt als auswählbare Einträge anbieten, sodass Anwender die jeweiligen Konfigurationsdateien nicht mehr manuell angeben müssen.
Mit den Dev Configs verfolgt Microsoft einen Ansatz, der an Dotfile-Sammlungen, Infrastructure as Code und automatisierte Entwickler-Setups unter Linux oder macOS erinnert. Weitere Details und die vollständige Liste der unterstützten Toolchains finden sich in der Dokumentation auf Microsoft Learn [2] sowie im GitHub-Repository des Projekts [3].
URL dieses Artikels:
https://www.heise.de/-11317987
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: PradeepGaurs / Shutterstock.com)
Gute UX versteckt ihren Müll. Aber er verschwindet nicht – er landet in Rechenzentren, Lieferketten und Telemetriedatenbanken.
Du öffnest eine App. Nur kurz. Eine Minute. Du willst nichts kaufen, nichts posten, nichts streamen – du willst nur sehen, ob da was ist. Das ist dein Plan. Die App hat einen anderen.
Noch bevor dein Daumen die erste Geste beendet, rollen im Hintergrund Dinge los, die sich in der UX-Folklore „Erlebnis“ nennen und in der Netzwerkanalyse eher wie Müllabfuhr klingen: DNS-Anfragen fahren vor, TLS-Handshakes klacken und klirren wie Altglascontainer, ein CDN kippt dir Assets vor die Füße, während ein Tag-Manager entscheidet, welche Drittparteien heute auf der Tour mitfahren dürfen. „Nur ein klitzekleines Skript“, sagt jemand im Sprint-Review, und meint damit: zusätzliche Domains, zusätzliche Requests, zusätzliche CPU-Zeit auf dem Endgerät, zusätzliche Logs, zusätzliche Datenhaltung, zusätzliche Menschen, die das später „Observability“ nennen.
Du, als Nutzerin oder Nutzer, merkst davon nichts. Du sollst davon nichts merken. Das ist ja der Punkt.
Gute UX ist, wenn sich die Mülltonne von allein leert. Schlechte Ökologie ist, wenn sich die Mülltonne von allein leert.
Materieller Müll stinkt irgendwann, er stapelt sich, er ist schwer und sichtbar. Im Digitalen ist er leicht, unsichtbar und schmiegt sich in Wörter, die so hygienisch klingen, dass man sich damit die Hände waschen möchte: Engagement, Retention, Personalisierung, Experience. Das Interface ist die weiße Küche der Gegenwart: glatte Flächen, keine Krümel, keine Ränder. Und genau wie die weiße Küche nur deshalb so sauber bleibt, weil der Dreck sofort hinter die Front geschoben wird, bleibt das „clean“ designte Produkt nur deshalb so reibungslos, weil es im Hintergrund permanent Daten bewegt, speichert, dupliziert, verdichtet, rehydriert, vorhält – und wieder wegwirft.
Man kann das als Nebenfolge sehen. Als Schatten der Digitalisierung. Ein paar zusätzliche Requests hier, ein paar MByte dort, ein bisschen Strom in Rechenzentren, die ohnehin laufen. Wenn es sich für uns kostenlos anfühlt, muss es doch gut sein, oder?
Oder man nimmt den Müll ernst – und dann wird er zum Spiegel.
Im Folgen-Modell ist digitaler Müll [2] das, was „leider“ anfällt: Datenfäule in alten Backups, Telemetrie-Events, die niemand auswertet, Cache-Leichen, doppelte Fotos, unendliche Versionen von „final_final_7.pdf“. Man optimiert dann ein bisschen: Kompression hier, CDN dort, ein neues Format, ein neuer Codec, ein Green-Hosting-Siegel. Alles richtig, alles nötig – und trotzdem fühlt es sich an wie Mülltrennung auf einem Kreuzfahrtschiff: Die Geste ist ernst gemeint, aber das System, in dem sie stattfindet, ist so strukturell überdimensioniert, dass sie darin spurlos verschwindet.
Im Spiegel-Modell ist digitaler Müll nicht der Kollateralschaden, sondern das Indiz eines totalen Schadens: Er zeigt, dass das System auf Müllproduktion angewiesen ist. Nicht weil Entwicklerinnen und Entwickler böse sind, sondern weil die ökonomische Grammatik vieler Produkte lautet: mehr Interaktion, mehr Messung, mehr Personalisierung, mehr Auktion, mehr Ausspielung. Wer das Interface baut, baut damit auch den Müll.
Und plötzlich ist „UX“ nicht nur die Frage, ob ein Button 44 Pixel hoch ist, sondern auch, ob ein Button 44 Pixel CO₂e hoch ist.
Bevor der Hoffnungsschimmer „bessere Codecs, effizientere Hardware, grüneres Hosting“ zur Erlösung wird, lohnt ein Blick auf das Jevons-Paradox: Der britische Ökonom William Stanley Jevons beschrieb 1865 in seinem Buch „The Coal Question“, dass effizientere Dampfmaschinen nicht weniger Kohle verbrauchten, sondern mehr – weil Effizienz die Nutzung billiger und damit attraktiver macht. Was damals für Kohle galt, gilt heute für Datentransfer, Rechenleistung und Speicher. Effizienzgewinne werden durch Mehrnachfrage aufgefressen. Bessere Kompression bedeutet mehr gestreamte Inhalte in höherer Auflösung. Günstigerer Cloud-Speicher bedeutet mehr gespeicherte Daten. Das Green-Hosting-Siegel macht die einzelne Anfrage sauberer – und motiviert gleichzeitig, mehr Anfragen zu senden.
Das Gemeine am digitalen Müll: Er ist weg, sobald man ihn nicht mehr sehen will. Dafür sorgen Lifecycle Policies, Log-Rotation, Object Storage mit „Archive“-Tier, automatische Skalierung, Caching und Invalidierung. Tausende „Müllfahrzeuge“ fahren, nur heißen sie heute Batch-Jobs, Pipelines und Daemons. Am Morgen ist die Tonne leer. Wo der Müll geblieben ist, weiß kaum jemand. Er ist halt weg. Und die Verdrängung wirkt.
Dabei ist das „weg“ eine teure Illusion. Rechenzentren sind inzwischen so groß, dass sie als eigener Stromsektor diskutiert werden: Die Internationale Energieagentur (IEA) [3] beziffert ihren Stromverbrauch 2024 auf rund 415 TWh – etwa 1,5 Prozent des gesamten Weltstromverbrauchs, gewachsen um 12 Prozent pro Jahr seit 2017. Im Basisszenario erwartet die IEA bis 2030 ungefähr eine Verdopplung auf rund 945 TWh, was dem heutigen Jahresstrombedarf Japans entspricht.
Im materiellen Konsum gibt es einen Moment der Entscheidung: Ich kaufe. Ich bezahle. Ich trage nach Hause. Im digitalen Konsum wurde dieser Moment systematisch zersägt, mikrosegmentiert und in Gesten aufgelöst, die sich nicht wie Entscheidungen anfühlen: ein Wischen, ein Tap, ein „Continue“, ein „Next up“. Der digitale Müll ist die Spur dieser Entscheidungen, die eigentlich keine sein wollen – und die nie enden.
Infinite Scroll ist nicht einfach ein Layout. Es ist ein Vertrag: Du wirst hier keinen natürlichen Abbruch finden, also musst du selbst abbrechen – gegen die Schwerkraft des Designs. Autoplay ist nicht einfach Komfort. Es ist Default-Konsum. Skeleton Screens sind nicht einfach „freundliche“ Ladeindikatoren. Sie sind Toleranztraining: Warte ruhig, wir laden schon noch mehr nach, du hast ja Zeit. Und Microinteractions – Konfetti, Lottie-Animationen [4], haptisches Feedback – sind nicht per se schlecht. Aber sie werden oft wie Puderzucker auf ein System gestreut, das im Hintergrund eine ganze Industrie simuliert, damit User länger bleiben.
Satire, aber leider wahr: Wir haben das Interface so optimiert, dass es Nutzer davon abhält, überhaupt zu merken, dass sie gerade Infrastruktur verheizen.
„AI“ ist der nächste große Sprung in der unsichtbaren Infrastruktur. Eine einzelne Anfrage an ein großes Sprachmodell verbraucht nach aktuellen Schätzungen ein Vielfaches mehr an Energie als eine klassische Websuche. Die Modelle werden zwar effizienter, aber das Jevons-Paradox lässt grüßen: Was pro Anfrage gespart wird, wird durch das schiere Wachstum der Nutzung mehrfach aufgefressen. Und „AI-Features“ werden gerade in jedes Interface eingepflegt – als Autocomplete, als Zusammenfassung, als smarter Suchvorschlag, als Microinteraction.
Was früher ein statisches UI-Element war, ist heute ein API-Call mit GPU-Last im Hintergrund. Im UI: Nur ein freundliches Textfeld, das „denkt“.
Das ist nicht per se falsch. Aber es verschiebt die Kalkulation: Was kostet dieses Feature wirklich? Und wäre eine einfachere Lösung – eine Suche mit klassischem Index, eine statische FAQ-Seite oder ein gut strukturiertes Interface – nicht die ökologisch ehrlichere Antwort?
Ekel ist nicht nur Biologie, sondern Kultur. Und Kultur lässt sich industrialisieren. Was Menschen als schmutzig, riskant oder unsexy empfinden, ist nicht Natur – es ist Erziehung. Die Lebensmittelindustrie hat das mit Pasteurisierung und Verpackungsdesign vorgemacht: Was früher selbstverständlich war (unbehandelte Milch, sichtbare Reifung, anfassbare Rohware), gilt heute als hygienisch bedenklich. Nicht, weil es gefährlicher geworden wäre, sondern weil eine Industrie davon profitiert, dass wir Abstand halten. Im Digitalen läuft dasselbe Spiel, nur mit anderen Objekten.
„Offline“ wirkt schmuddelig. Lokale Dateien wirken chaotisch. Einstellungen wirken gefährlich. Cache wirkt wie Schmutz, den man regelmäßig „bereinigen“ muss, am besten per Ein-Klick-Optimizer (Abo optional). Dahingegen wirkt „Stream“ sauber, „Sync“ modern, „Cloud“ professionell und „AI“ ohnehin wie desinfiziert.
So entsteht ein Autonomie-Ekel: Alles, was Nutzerinnen und Nutzern Kompetenz und Entscheidung zurückgibt, wird als unsexy und riskant markiert. Und alles, was Entscheidung abnimmt, wird als Komfort verkauft.
Das ist keine Verschwörung, das ist Kulturtechnik. Und UX ist ihr Werkzeugkasten.
Der Tetrapak ist das Paradebeispiel für technisch perfekten, aber ökologisch widersinnigen Verbundmüll. Fünf Schichten: Polyethylen, Pappe, Polyethylen, Aluminium, Polyethylen – unlösbar miteinander verschweißt, damit der Inhalt länger haltbar bleibt. Ölindustrie, Forstwirtschaft, Bergbau, alles in einer Verpackung. Recyceln ist theoretisch möglich, praktisch kaum. Das digitale Pendant ist eine UI-Komponente, die wir alle kennen und doch nie wirklich gesehen haben: das Consent-Banner.
Es besteht aus Schichten, die kaum noch zu trennen sind:
Technisch heißt das: zusätzliche Third Parties, zusätzliche Handshakes, zusätzliche Skript-Ausführung auf dem Client, zusätzliche Auktionen und zusätzliche Telemetrie. Kurz: Müll.
Und hier wird die Spiegelthese plötzlich greifbar: Der Müll ist nicht die Folge einer an sich guten Sache („kostenloser Content“), sondern das Indiz dafür, dass das Geschäftsmodell Müll braucht, wie der Tetrapak Einweg braucht.
Die Betriebsenergie ist eine Seite der Rechnung. Die andere ist die Herstellung von Endgeräten. Bei Smartphones macht die Produktion – Stichwort eingebettetes CO₂, seltene Erden, Lieferketten – rund 80 Prozent des gesamten Lebenszyklusabdrucks aus, bei manchen Modellen sogar mehr. Ein Interface, das ältere Geräte durch hohe JavaScript-Last, erzwungene App-Updates oder faktische Mindest-OS-Anforderungen veraltet, produziert also auch Müll, nur eben im Materiellen, am anderen Ende der Lieferkette.
Schlankes, robustes Interface-Design ist damit nicht nur ökologische Nettigkeit, sondern direkte Verlängerung der Gerätelebensdauer. Und das schlägt einen schönen Bogen zurück zu Oliver Schlaudts Originalthema: Müll, der sichtbar wird – nur eben als Geräteschrott statt als Datenmüll.
Zero Waste im Digitalen klingt nach Detox, nach Verzicht, nach „kein Spaß mehr“. Das ist marketingtechnisch unklug und anthropologisch falsch. Der bessere Einstieg ist ein Low-Waste-Experiment: nicht weniger Leben, sondern weniger Müll.
Die ersten 50 Prozent liegen im Ermessen jedes Entwicklungsteams – und sind beschämend leicht:
Die nächsten 50 Prozent sind produktpolitische Entscheidungen:
Die überraschend fruchtbare Übertragung kommt aus der Lebensmittelkunde: Pasteurisierung macht Milch haltbar, hygienisch und jederzeit verfügbar, aber sie stoppt auch den Fermentationsprozess, aus dem Käse, Joghurt oder Butter entstehen. Die Digitalisierung macht dasselbe mit Daten: alles einfrieren, alles vorhalten, alles frisch. Der Denkwechsel wäre: weg vom hygienischen Stillstellen, hin zum Prozessdenken – kurze Retention als Default, Aggregation statt Event-Fetisch, Sampling statt Totalüberwachung und ein „Right to Rot": Daten laufen ab wie Joghurt, und nur wer einen Grund hat, verlängert.
Es gibt bereits Interfaces, die zeigen, dass es anders geht:
Low-Tech Magazine [5] betreibt eine solarbetriebene Website mit sichtbarem Akkustand im Header. Wenn die Sonne nicht scheint, ist die Seite offline. Keine Metapher, sondern eine technische Tatsache als UX-Entscheidung.
GOV.UK [6] hat sich radikal schlankes Design auf die Fahne geschrieben: minimales JavaScript, keine Third-Party-Tracker, klare Informationsarchitektur. Das Ergebnis ist kein Designpreis, sondern ein besonders niedriges Page Weight unter den meistgenutzten Webpräsenzen Europas.
Das sind keine Erlösungsnarrative. Sie sind Belege dafür, dass Entscheidungen möglich sind, und dass sie nicht zwingend schlechtere Produkte erzeugen.
Wenn Müll Spiegel des Konsums ist, braucht man Kulturtechniken, die den Spiegel wieder ins Blickfeld holen. Es folgen drei Gedankenexperimente, die nicht rein hypothetisch sind. Denn zu allen dreien gibt es bereits Vorläufer, Werkzeuge oder politische Initiativen. Was fehlt, ist nicht die Idee, sondern der Wille, sie zur Norm zu machen.
Wer Telemetrie in Umlauf bringt, zahlt Pfand. Zurück gibt es das Pfand nur bei nachweislicher Löschung, Minimierung oder Retention-Limits. Kein Pfandbon, keine Personalisierung.
Die Idee klingt radikal. Sie ist es nicht – zumindest nicht in ihrer Grundstruktur. Die DSGVO [7] enthält seit 2018 exakt dieses Prinzip als Rechtspflicht: Datensparsamkeit und Speicherbegrenzung schreiben vor, dass personenbezogene Daten nur so lange aufbewahrt werden dürfen, wie es der ursprüngliche Zweck erfordert. Was fehlt, ist die Konsequenz in der Praxis. Retention Limits werden selten aktiv durchgesetzt, die Aufsichtsbehörden sind personell unterbesetzt, und das wirtschaftliche Interesse liegt klar auf der Seite der Datenhaltung.
Das Pfand-Modell dreht die Anreizstruktur um: Löschung wird der Normalfall. Denkbar wäre ein öffentlich einsehbares Pflichtregister für Telemetrie-Datenflüsse, das maschinell lesbar wäre und Retention-Angaben enthielte. Oder eine Infrastrukturabgabe für Datenhaltung jenseits definierter Fristen, nicht als Strafe, sondern als Internalisierung externer Kosten: Speicherstrom, Redundanz, Sicherheitsaufwand. Und schließlich ein „Right to Expiry“: ein gesetzlich verankerter Anspruch darauf, dass bestimmte Datenkategorien nach festgelegten Fristen automatisch verfallen, ohne dass Nutzerinnen und Nutzer aktiv handeln müssen.
Das nächste Sprint-Review. Jemand präsentiert ein neues Carousel, einen KI-gestützten Vorschlags-Feed oder ein Echtzeit-Tracking-Dashboard. Die Folie zeigt: „Nutzerzufriedenheit +12 Prozent, Retention +8 Prozent“. Was die Folie nicht zeigt: „+4 Third-Party-Domains, +230 ms Main-Thread-Blocking, +1,4 GByte Datenhaltung pro Monat, +1 neuer Subdomain-Scope für die nächste Datenschutzverletzung“.
Eine Feature-Ampel macht genau diesen unsichtbaren Teil sichtbar, nicht als Veto, sondern als Informationsgrundlage. Jede Funktion bekommt eine Zutatenliste: zusätzliche Requests, Third Parties, JavaScript-Ausführungszeit, Datenhaltung. Nicht um Produktteams zu beschämen, sondern um sie zu entzaubern: „Das ist nicht nur ein kleines UI-Upgrade.“
Die Inspiration kommt aus zwei Richtungen. Der Nutri-Score für Lebensmittel zwingt Hersteller, ihre Rezepturen zu rechtfertigen – kein Verbot von Zucker, aber ein Ende der Unsichtbarkeit. Analog bewertet das Website Carbon Rating System [8] von Wholegrain Digital Websites von A+ bis F nach CO₂-Ausstoß. Die Web Sustainability Guidelines [9] (Group Note Draft 2026) des W3C liefern das bisher ausgefeilteste Rahmenwerk: 80 Richtlinien, 225 Erfolgskriterien. Das Tooling existiert bereits: co2.js [10] der Green Web Foundation lässt sich in Deployment-Pipelines integrieren, Ecograder [11] auditiert URLs mit priorisierten Handlungsempfehlungen.
Ein Modus, der Motion reduziert, Videos konservativ einstellt, Prefetch limitiert, Third Parties kappt, Offline priorisiert. Nicht als „Sparmodus für Arme“, sondern als Qualitätsmerkmal: ein Interface, das auch ohne Dauerfeuer gut ist.
Dieser Modus ist technisch bereits zu einem erheblichen Teil implementierbar. prefers-reduced-motion [12] ist eine CSS Media Query mit breiter Browserunterstützung: Nutzerinnen und Nutzer geben im Betriebssystem an, dass sie weniger Bewegung bevorzugen, und Webseiten schalten Animationen, Parallax-Effekte und Autoplay ab. Der Save-Data HTTP Header [13] funktioniert in mobilen Chromium-Browsern bereits heute. prefers-reduced-data [14] ist noch kein stabiler Standard, aber als W3C-Entwurf in Arbeit: eine Media Query, die es erlaubt, per CSS direkt zu reagieren, etwa um Webfonts wegzulassen, Hintergrundbilder zu ersetzen oder Autoload zu deaktivieren.
Was fehlt, ist nicht die Technik. Es ist das Framing.
Ein Energiesparhaus ist kein Haus zweiter Klasse, sondern ein gut gebautes Haus. Doch der „Sparmodus“ in digitalen Produkten gilt als Rückschritt. Dieses Framing schützt das Engagement-Modell.
Den Carbon Mode als Qualitätsmerkmal zu verankern bedeutet, das Framing zu drehen: Das Basiserlebnis ist das ressourcenschonende. Wer mehr will, also höhere Auflösung, Echtzeitdaten oder Animationseffekte, aktiviert es bewusst. Ein Interface, das dieses Prinzip konsequent umsetzt, ist nicht weniger gut. Es ist ehrlicher.
Die unangenehme Wahrheit von der digitalen Deponie lautet nicht, dass ein paar Tracker oder Animationen „leider“ Energie kosten. Sie lautet: Unsere Definition von guter UX wurde zu oft mit Reibungslosigkeit verwechselt – und Reibungslosigkeit ist in einer Engagement-Ökonomie fast immer Müllproduktion.
Vielleicht müssen wir Verbraucherschutz im Digitalen neu lesen: nicht nur Nutzerinnen und Nutzer vor Konzernen schützen, sondern sie davor schützen, zu reinen Konsumenten zu werden. Das heißt nicht: zurück in die Kommandozeile. Es heißt: Interfaces bauen, die natürliche Abbruchpunkte zulassen, Entscheidungen sichtbar machen, Daten altern lassen und Autonomie nicht als Dreck markieren.
Das gute digitale Leben wartet nicht im nächsten Feature-Release. Es wartet in einem Interface, das wieder „Nein" sagen kann – zu Autoplay, zu unendlichem Scrolling, zu Telemetrie ohne Opt-in. Und ja, es wartet auch in einem Cache, der nicht als Schmutz gilt, sondern als das, was er ist: eine kleine, handwerkliche Form von Effizienz.
Schütten wir ihn nicht unbedacht weg.
URL dieses Artikels:
https://www.heise.de/-11311079
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Moritz Förster / KI / iX)
Microsoft baut eine eigene Container-Plattform ins Windows Subsystem for Linux ein – samt CLI, API und SDK für Windows-Anwendungen.
Microsoft arbeitet an einer eigenen Container-Plattform für das Windows Subsystem for Linux (WSL). Die Funktion WSL Container integriert Linux-Container direkt in WSL und umfasst das neue Kommandozeilen-Tool wslc.exe sowie eine API, über die Windows-Anwendungen Container programmatisch nutzen können.
Microsoft bezeichnet die Funktion offiziell noch als „in Entwicklung“, die Dokumentation zu WSL Container [1] steht jedoch bereits bereit und verweist auf die laufende Entwicklung im WSL-Repository. Auf der Build 2026 [2] kündigte Microsoft am 2. Juni WSLC offiziell als demnächst in Public Preview verfügbar an. Mit einem künftigen WSL-Update soll wslc.exe automatisch als Bestandteil von WSL installiert werden.
Microsoft beschreibt die neue Komponente als Kombination aus der CLI wslc.exe und einer WSL-Container-API. Ein NuGet-Paket ermöglicht Anwendungen, Container-Images herunterzuladen, Container zu starten und mit ihnen zu interagieren. Unterstützt werden unter anderem Ein- und Ausgabe über stdin und stdout, Dateifreigaben, Netzwerkfunktionen sowie der Zugriff auf die GPU.
Für Entwickler bringt die Plattform zudem ein WSLC-SDK mit C++- und C#-Bibliotheken mit. Windows-Anwendungen können Container damit direkt über die bereitgestellte API verwalten. Mögliche Einsatzszenarien reichen von Entwicklungsumgebungen, die automatisch Build-Container hochfahren, bis zu Anwendungen, die Datenbanken oder andere Linux-Dienste im Hintergrund bereitstellen.
Welche technische Basis Microsoft genau verwendet, geht aus den offiziellen Unterlagen nur in Ansätzen hervor. Die Dokumentation spricht lediglich allgemein von Linux-Containern. Etwas mehr Details liefert der zugehörige Pull-Request Add WSLC (WSL Containers) feature [3]: Die Plattform bringt Komponenten zur Verwaltung von Containern, Images, Volumes und Netzwerken mit und unterstützt Container-Registries.
Der Pull-Request nennt weitere technische Bausteine. Beim Netzwerk unterstützt die Plattform Portweiterleitung, DNS-Tunneling und Virtio-Netzwerke und bindet sich in den Windows-Netzwerkstack ein. Container-Daten landen in VHD-basierten Volumes. Für die Container-Dateisysteme nutzt wslc Overlay-Dateisysteme, wie sie unter Linux üblich sind. Für den Dateiaustausch zwischen Windows und der Containerumgebung kommt virtiofs zum Einsatz.
Auch GPU-Beschleunigung gehört zum Funktionsumfang. Sowohl die Dokumentation als auch der Pull Request führen GPU-Zugriff ausdrücklich auf. Die GPU-Unterstützung dürfte insbesondere für KI- und Machine-Learning-Workloads sowie GPU-beschleunigte Entwicklungsumgebungen interessant sein.
Einen Veröffentlichungstermin nennt Microsoft bislang nicht. Die Dokumentation verweist lediglich auf ein künftiges WSL-Update. Teile der Implementierung sind bereits über das WSL-Repository [4] einsehbar.
URL dieses Artikels:
https://www.heise.de/-11317346
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Microsoft)
Schluss mit Copy-and-paste in den Chatbot: Microsofts neues Intelligent Terminal bindet KI-Agenten direkt in die Shell ein und liefert Kontext automatisch mit.
Microsoft hat seinen neuen Intelligent Terminal vorgestellt, einen experimentellen Open-Source-Fork des Windows Terminal. Die Anwendung bindet KI-Agenten direkt in die Terminaloberfläche ein und soll Entwicklern und Administratoren den Wechsel zwischen Shell, Browser und KI-Assistent ersparen. Der Intelligent Terminal läuft als eigenständige Anwendung neben dem regulären Windows Terminal und ersetzt dieses nicht.
Für Windows gibt es bereits mehrere Terminals. Neben dem klassischen Konsolenfenster und dem moderneren Windows Terminal von Microsoft nutzen viele Entwickler Drittanbieterprogramme wie WezTerm, Hyper, Tabby, ConEmu oder MobaXterm.
Mit dem Aufkommen von KI-Agenten sind zudem neue Terminalprojekte entstanden, die KI-Funktionen direkt in die Oberfläche integrieren. Zu den bekanntesten Vertretern zählt Warp [1]. Microsoft verfolgt mit Intelligent Terminal jedoch einen anderen Ansatz: Statt einen neuen Terminal zu entwickeln, erweitert das Unternehmen das vielen Nutzern bereits vertraute Windows Terminal um Agentenfunktionen. Im Mittelpunkt steht ein andockbarer Bereich namens Agent Pane, der dauerhaft Zugriff auf die laufende Shell-Sitzung hat.
Intelligent Terminal ist nicht auf einen einzelnen KI-Anbieter festgelegt. Die Anwendung unterstützt Agenten, die das Agent Client Protocol (ACP) beherrschen. Standardmäßig kommt die GitHub Copilot CLI zum Einsatz, daneben erkennt die Software laut Dokumentation auch CLI-Agenten auf Basis von Claude, Codex oder Gemini. Den Agenten und das Modell wählen Anwender in den Einstellungen aus.
Eine zentrale Neuerung ist die automatische Fehlererkennung: Schlägt ein Befehl fehl, weist das Terminal sichtbar darauf hin und übergibt dem Agenten den Fehlerkontext. Dieser liefert anschließend Erklärungen oder Lösungsvorschläge.
Die Grundidee ist nicht neu. Schon vor dem Aufkommen generativer KI gab es Werkzeuge, die fehlerhafte Shell-Befehle analysierten und korrigierte Varianten vorschlugen – etwa das verbreitete Kommandozeilen-Tool thefuck [2]. Intelligent Terminal geht jedoch einen Schritt weiter und verknüpft die Fehleranalyse mit einem dialogfähigen Agenten. Statt nur einen korrigierten Befehl auszugeben, beantwortet dieser Rückfragen, erläutert verschiedene Lösungswege und kann Folgeaktionen vorbereiten.
Komplexere Aufgaben laufen bei Bedarf im Hintergrund. Mehrstufige Agentenaufträge lagert Intelligent Terminal in separate Tabs aus, sodass die aktive Shell nutzbar bleibt. Als Einsatzszenarien nennt Microsoft etwa die Analyse umfangreicher Logdateien, die Untersuchung von Build-Fehlern oder das Erstellen von Skripten.
Damit Nutzer mehrere parallele Agentenaufgaben im Blick behalten, bringt Intelligent Terminal ein eigenes Verwaltungsfenster mit. Dort lassen sich aktive und abgeschlossene Sitzungen einsehen und bei Bedarf wieder aufnehmen. Auch die Befehlspalette (Command Palette) hat Microsoft erweitert: Über ein vorangestelltes Fragezeichen starten Anwender Agentenaufträge direkt aus der Palette heraus, ohne ihre Arbeitsumgebung zu verlassen. Den Kontext der aktiven Shell übergibt das Terminal automatisch.
Für den schnellen Zugriff auf die neuen Funktionen führt Microsoft zudem eine Agenten-Statusleiste ein. Sie bündelt das Agentenfenster, die Fehlererkennung und die Sitzungsverwaltung an einer Stelle.
Beim Datenschutz beschreibt Microsoft Intelligent Terminal als lokale Transportschicht zwischen Terminal und Agentensoftware. Die Anwendung selbst spricht laut Microsoft nicht mit Cloud-Diensten, sondern reicht Eingaben und Shell-Kontext an den gewählten Agenten weiter. Welche Daten dort verarbeitet werden, hängt vom jeweiligen Anbieter ab. Gesprächsverläufe speichert Intelligent Terminal nicht dauerhaft; Telemetrie- und Diagnosedaten kann es jedoch weiterhin an Microsoft übermitteln.
Microsoft bezeichnet Intelligent Terminal ausdrücklich als Experiment. Die Software erscheint als separate Anwendung und läuft parallel zum regulären Windows Terminal. Mit dem Release stellt Microsoft zudem Terminal Chat im Canary-Channel ein. Voraussetzung ist Windows 11 ab Version 22H2. Weitere Details nennt Microsoft in der Ankündigung zu Intelligent Terminal [3]; Quellcode und technische Dokumentation liegen im GitHub-Repository des Projekts [4]. Den Funktionsumfang der ersten Version beschreiben die Release Notes zu Version 0.1.0 [5].
URL dieses Artikels:
https://www.heise.de/-11317164
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Apple plant das erste europäische Developer Center in Berlin-Mitte. Im Bild: Das Auditorium.
(Bild: Apple)
Apple plant sein erstes Developer Center in Europa in Berlin-Mitte. Es soll für Präsenzveranstaltungen und persönliche Termine genutzt werden.
Apple will noch in diesem Jahr ein erstes Developer Center in Europa eröffnen – und es soll sich in Berlin-Mitte befinden. Das gab der iPhone-Hersteller am Mittwoch, wenige Tage vor Beginn der Entwicklerkonferenz WWDC [1] bekannt. Das neue Zentrum, das vor allem Zwecken der Weiterbildung für App-Entwickler und persönlicher Unterstützung dienen soll, ergänzt die vorhandenen Standorte am Firmen-Stammsitz in Cupertino (USA), im indischen Bengaluru, in Shanghai (China) und Singapur.
Entwicklerinnen und Entwickler sollen am neuen Standort Zugang zu Tools, Workshops und persönlicher Unterstützung durch Apple erhalten. Das Präsenzangebot ergänzt Apples Online-Angebote für Entwickler. Regelmäßige Präsenzveranstaltungen sollen Entwicklern helfen, ihre Fähigkeiten zu verbessern und das Design, die Qualität und die Leistung ihrer Apps für iOS, iPadOS, macOS, tvOS, visionOS und watchOS zu optimieren. Apple hat seine Aktivitäten in Berlin in jüngster Zeit bereits in anderen Bereichen verstärkt [2].
Apple kündigte an, dass das Center die Vielfalt und Kreativität der europäischen Entwickler-Gemeinschaft widerspiegeln soll. „Europa ist die Heimat einer außergewöhnlichen Entwickler-Community, die Apps entwickelt und damit Verbindungen schafft, Kreativität fördert und Innovationen vorantreibt“, sagt Susan Prescott, Vice President of Worldwide Developer Relations bei Apple. Für Apple ist Europa allerdings auch ein spezieller Markt, da hier eine besonders starke Regulierung durch die EU-Kommission greift, die auch den App Store betrifft. So muss Apple zum Beispiel aufgrund des Digital Markets Act (DMA) alternative App Stores zulassen [3].
(Bild: Apple)
Apples App-Prämierungen wie der App Store Award und der Design Award [4] zeigen jedes Jahr aufs Neue, welchen hohen Stellenwert europäische Entwickler für das Angebot im App Store haben. Auch beim Nachwuchswettbewerb Swift Student Challenge sind regelmäßig europäische Nachwuchsentwickler vertreten. Mit dem Apple-Foundation-Programm hatte Apple bereits in zahlreichen europäischen Ländern Entwickler unterstützt. Mit dem neuen Developer Center in Berlin wird nun die Landkarte um ein weiteres Angebot erweitert.
URL dieses Artikels:
https://www.heise.de/-11316854
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Der rehabilitierte Mathematiker Alan Turing ziert die Rückseite der seit 2021 gedruckten 50-Pfund-Sterling-Noten.
(Bild: Bank of England)
Halluzinationen von Sprachmodellen sind kein Engineering-Problem: Sie folgen aus mathematischen Grenzen, die seit den 1930er-Jahren bewiesen sind.
Im Studium begegnen einem Namen wie Kurt Gödel [1] und Alan Turing [2] meist mit derselben Mischung aus Respekt und leichter Resignation. Man liest, was sie bewiesen haben, akzeptiert es als beeindruckend und legt das Wissen anschließend in jenes mentale Archiv, das man irgendwo zwischen „interessant“ und „werde ich nie wieder brauchen“ verortet. Dass die Unvollständigkeit der Arithmetik oder die Unentscheidbarkeit des Halteproblems eines Tages mit der Frage zusammenfallen könnten, warum mir ein Chatbot gerade einen Buchtitel halluziniert hat, hätte ich vor einigen Jahren niemandem geglaubt.
Genau das ist aber passiert. Mehrere wissenschaftliche Arbeiten der letzten drei Jahre zeigen, dass die Halluzinationen von Sprachmodellen kein Implementierungsfehler sind, den man mit mehr Daten oder besserer Architektur wegtrainieren könnte. Sie folgen aus denselben theoretischen Grenzen, an denen einmal das ehrgeizigste Projekt der modernen Mathematik zerbrochen ist. Wer diese Verbindung einmal gesehen hat, liest die aktuelle Debatte um die Zukunft der KI mit deutlich nüchternerem Blick.
Um zu verstehen, warum die Forschungslandschaft der KI heute so ist, wie sie ist, lohnt sich ein Umweg über den Internationalen Mathematikerkongress in Bologna im Jahr 1928. Dort formulierte David Hilbert [3], einer der einflussreichsten Mathematiker seiner Zeit, gemeinsam mit Wilhelm Ackermann ein Forschungsprogramm [4], das die gesamte Mathematik auf eine vollkommen neue Grundlage stellen sollte. Drei Eigenschaften sollten dieses Fundament tragen:
Die dritte Forderung ist als Entscheidungsproblem [5] in die Geschichte eingegangen. Hinter ihr stand eine konkrete Vision. Mathematik sollte mechanisierbar werden. Eine Maschine, die endlich viele Regeln auf endlich vielen Zeichen anwendet, müsste jede mathematische Frage prinzipiell beantworten können. Wer in dieser Vision den Schatten dessen erkennt, was wir heute Computer nennen, liegt nicht falsch. Hilbert dachte den Computer mit, lange bevor es ihn gab.
Sein Optimismus war ungebrochen. Im September 1930 hielt er in Königsberg eine berühmt gewordene Radioansprache, die er mit dem Satz beendete: „Wir müssen wissen, wir werden wissen.“ Es war die letzte große Verkündigung einer Mathematik, die sich selbst noch alles zutraute. Wenige Tage zuvor hatte am selben Ort, auf einer parallel laufenden erkenntnistheoretischen Tagung, ein junger Mann namens Kurt Gödel in einer beiläufigen Bemerkung erstmals jene Ergebnisse skizziert, die Hilberts Programm in den Grundfesten erschüttern sollten. Dass die beiden Ereignisse so dicht beieinander lagen, ist eine historische Pointe, der man nicht zu viel symbolisches Gewicht aufladen sollte. Aber interessant ist sie allemal.
Was Gödel 1930 vorgestellt und 1931 ausführlich publiziert hat, lässt sich erstaunlich gut ohne mathematische Notation erklären. Sein Trick beruht auf einem Verfahren, das jeder verständlich findet, der einmal eine sich selbst aufrufende Funktion gesehen hat: Selbstreferenz. Stellen Sie sich ein hinreichend mächtiges formales System vor, in dem sich arithmetische Aussagen formulieren lassen. Gödel hat gezeigt, wie sich innerhalb eines solchen Systems eine Aussage konstruieren lässt, die in etwa besagt: „Diese Aussage ist im vorliegenden System nicht beweisbar.“
An diesem Punkt sollte man kurz innehalten, weil die Konsequenz unausweichlich ist. Ist die Aussage wahr, dann gibt es eine wahre arithmetische Aussage, die das System nicht beweisen kann. Damit ist das System unvollständig. Ist die Aussage falsch, dann beweist das System eine Aussage, die behauptet, nicht beweisbar zu sein, obwohl sie es offenbar doch ist. Damit ist das System inkonsistent. Es gibt keinen dritten Weg.
Wer den Lügner aus der antiken Philosophie kennt, der sich selbst der Lüge bezichtigt, erkennt das Muster wieder. Was Gödel jedoch geleistet hat, war keine philosophische Spielerei, sondern ein streng formaler Beweis innerhalb der Arithmetik selbst. Er zeigte, dass die Selbstreferenz nicht auf gemeinsprachliche Aussagen beschränkt bleibt, sondern in jedem hinreichend ausdrucksstarken formalen System auftaucht.
Gödel hat damit nicht gezeigt, dass die Mathematik kaputt ist. Er hat gezeigt, dass es prinzipielle Grenzen gibt, an denen jede ausreichend mächtige Theorie auf sich selbst zurückgeworfen wird. Hilberts Vision einer mechanisierbaren, in sich abgeschlossenen Mathematik bekam damit einen Riss, den niemand mehr kitten konnte. Die Konsequenz wurde später so formuliert: Jedes System, das genug Ausdrucksstärke hat, um über sich selbst zu sprechen, hat blinde Flecken, die sich nicht wegoptimieren lassen.
Besonders bemerkenswert an Gödels Ergebnis ist, dass es nicht von einer bestimmten Theorie abhängt. Es gilt für die Arithmetik, für die Mengenlehre, für jede formale Theorie, die ausreichend Ausdrucksstärke besitzt, um die natürlichen Zahlen mitsamt Addition und Multiplikation zu beschreiben. Wer das System tauscht, tauscht nur das Gewand der Grenze, nicht die Grenze selbst. In den Jahrzehnten nach Gödel wurden zahlreiche weitere Sätze bewiesen, die zeigen, dass die Selbstreferenz an erstaunlich (oder erschreckend) vielen Stellen ihren Tribut fordert. Das Halteproblem [6] ist nur das bekannteste Beispiel dafür.
Sechs Jahre nach Gödels Beweis erschien in den Proceedings of the London Mathematical Society eine Arbeit, die heute zu den Gründungsdokumenten der Informatik zählt: Alan Turings Aufsatz „On Computable Numbers, with an Application to the Entscheidungsproblem“. Turing hatte sich gefragt, was es eigentlich heißt, dass ein Verfahren mechanisch ausführbar ist. Er entwarf dafür ein gedankliches Konstrukt, das wir heute Turing-Maschine nennen, und nutzte es, um Hilberts dritter Forderung den Garaus zu machen. Im selben Jahr und unabhängig von Turing kam Alonzo Church zu einem entsprechenden Ergebnis auf dem Weg über den Lambda-Kalkül.
Turings Resultat ist als Halteproblem bekannt. Es lässt sich in einem Satz zusammenfassen: Es gibt kein allgemeines Verfahren, das für ein beliebiges Programm und eine beliebige Eingabe entscheiden kann, ob das Programm jemals zum Ende kommt. Diese Aussage klingt zunächst harmlos, ist aber von erheblicher Tragweite. Sie sagt nicht, dass wir bisher kein solches Verfahren gefunden haben. Sie sagt, dass es ein solches Verfahren niemals geben kann.
Wer heute in der Softwareentwicklung arbeitet, lebt mit den Konsequenzen dieses Beweises, ohne sich dessen jeden Tag bewusst zu sein. Statische Codeanalyse stößt bei substanziellen Fragen über das Programmverhalten auf prinzipielle Grenzen. Compiler-Optimierer müssen Heuristiken einsetzen, weil eine vollständige Analyse mancher Codepfade unentscheidbar bleibt. Formale Verifikation funktioniert nur dort wirklich gut, wo man das untersuchte Problem auf entscheidbare Fragmente einschränkt. Wir haben uns daran gewöhnt, mit den Folgen einer mathematischen Grenze umzugehen, ohne sie noch jedes Mal benennen zu müssen.
Verschärft wird die Lage durch ein Ergebnis, das Henry Gordon Rice 1953 bewiesen hat. Sein Satz [7] besagt, dass jede nicht-triviale semantische Eigenschaft eines Programms unentscheidbar ist. Damit ist nicht nur die Frage nach dem Terminieren prinzipiell offen, sondern praktisch jede interessante Frage über das Verhalten von Programmen. Ob ein bestimmter Codepfad jemals durchlaufen wird, ob zwei Programme funktional äquivalent sind, ob ein Programm eine bestimmte Ausgabe niemals produziert: Für all das gibt es kein allgemeines Entscheidungsverfahren. Was dem Berufsalltag in der Softwareentwicklung als zähe Heuristik begegnet, ist im Kern dieselbe Grenze, an die Hilbert 1928 gehofft hatte, nicht zu stoßen.
Mit Turings Arbeit war Hilberts Programm in seiner ursprünglichen Form endgültig erledigt. Konsistenz und Vollständigkeit hatte Gödel zerlegt, die Entscheidbarkeit nahmen Turing und Church mit nach Hause. Das ehrgeizigste mathematische Forschungsprogramm des frühen 20. Jahrhunderts war an seinen eigenen Voraussetzungen gescheitert. Was übrig blieb, war die nüchterne Einsicht, dass auch die Mathematik mit Grenzen leben muss, die sie nicht selbst aufgehoben hat, sondern an denen sie sich vorfindet.
Damit kehre ich zu der Frage zurück, die diesen Text ausgelöst hat. Was hat das alles mit Sprachmodellen zu tun?
Im Januar 2024 reichten Ziwei Xu, Sanjay Jain und Mohan Kankanhalli von der National University of Singapore eine Arbeit mit dem Titel „Hallucination is Inevitable: An Innate Limitation of Large Language Models [8]“ ein. Sie formalisieren das Problem in einer formalen Welt, in der Halluzination als Inkonsistenz zwischen einem berechenbaren Sprachmodell und einer berechenbaren Wahrheitsfunktion definiert ist. Ihr zentrales Ergebnis stützt sich auf die Lerntheorie und auf ein Argument, das in seiner Struktur direkt mit den Diagonalisierungsverfahren Cantors und Turings verwandt ist: Sprachmodelle können nicht alle berechenbaren Funktionen lernen. Sobald sie ein breites Spektrum an Problemen lösen sollen, werden sie zwangsläufig halluzinieren. Es gibt keine Trainingsmethode, keine Architekturvariante und keinen Datenumfang, der diese Grenze verschiebt.
Wenige Monate später, im September 2024, legten Sourav Banerjee, Ayushi Agarwal und Saloni Singla mit „LLMs Will Always Hallucinate, and We Need to Live With This [9]“ eine zweite, unabhängige Argumentationslinie vor. Sie gehen direkter zur Sache und stützen sich ausdrücklich auf Gödels ersten Unvollständigkeitssatz sowie auf die Unentscheidbarkeit von Halteproblem, Emptiness-Problem und Acceptance-Problem. Ihre Schlussfolgerung ist noch entschiedener formuliert: Halluzinationen lassen sich nicht durch architektonische Verbesserungen, Datenanreicherung oder Fact-Checking eliminieren, weil sie aus der fundamentalen mathematischen und logischen Struktur dieser Modelle folgen. Sie führen dafür den Begriff der Structural Hallucination ein, der das Phänomen nicht als Fehler, sondern als strukturelle Eigenschaft beschreibt.
An dieser Stelle ist Vorsicht geboten, denn beide Arbeiten verwenden den Begriff der Halluzination in einer formal definierten Weise, die sich nicht vollständig mit dem alltagssprachlichen Gebrauch deckt. Die Aussagen bedeuten nicht, dass jeder zweite Satz eines Sprachmodells falsch sein muss. Sie bedeuten, dass eine perfekte Wahrheitsmaschine, die in beliebigen Domänen zuverlässig korrekte Antworten liefert, mathematisch unmöglich ist. Was die alltägliche Halluzinationsrate angeht, ist mit weiteren Verbesserungen zu rechnen. Was die prinzipielle Eliminierbarkeit angeht, ist mit nichts dergleichen zu rechnen.
Konkret heißt das Folgendes: Selbst wenn ein Sprachmodell auf einer perfekten Datenbasis trainiert würde und über beliebig viele Parameter verfügte, gäbe es immer Fragen, auf die es plausibel klingende, aber falsche Antworten liefern würde. Banerjee, Agarwal und Singla zeigen darüber hinaus, dass jede Stufe des Verarbeitungsprozesses, von der Zusammenstellung der Trainingsdaten über die Faktenwiederherstellung bis zur eigentlichen Textgenerierung, eine von Null verschiedene Fehlerwahrscheinlichkeit aufweist. Diese Fehler summieren sich auf, lassen sich aber an keiner Stelle vollständig vermeiden. Das ist keine empirische Beobachtung, die sich durch bessere Verfahren widerlegen ließe. Es ist ein Ergebnis derselben Art wie die Unmöglichkeit, einen allgemeinen Halteprüfer zu bauen.
Bemerkenswert ist, dass beide Arbeiten unabhängig voneinander zu demselben Schluss gelangen, allerdings über unterschiedliche Wege. Xu, Jain und Kankanhalli argumentieren über die Lerntheorie. Banerjee, Agarwal und Singla argumentieren über die klassische Berechenbarkeitstheorie. Es ist dieselbe Mauer, an die beide Gruppen laufen. Wer mit den Ergebnissen Gödels und Turings vertraut ist, erkennt sie sofort wieder.
Damit gewinnt auch die populäre Forderung, das Problem der Halluzinationen einfach durch mehr Trainingsdaten oder größere Modelle zu lösen, einen anderen Beiklang. Sie ist nicht falsch in dem Sinne, dass größere Modelle nicht besser werden würden. Sie übersieht nur, dass eine Skalierung an dieser Stelle nicht das Problem berührt, das die zitierten Arbeiten beschreiben. Eine Funktion, die nicht lernbar ist, wird nicht durch mehr Parameter lernbar. Eine Frage, die unentscheidbar ist, wird nicht durch mehr Daten entscheidbar. Die Grenze ist keine Frage des Maßstabs, sondern eine Frage der Natur des Verfahrens.
Hilbert hat sein Programm bis zum Lebensende nicht völlig aufgegeben. Auch nachdem Gödel und Turing seine Voraussetzungen widerlegt hatten, hielt er an dem Glauben fest, dass der wissenschaftliche Geist letztlich jede Frage werde beantworten können. Heute klingt diese Haltung beinahe rührend, gewiss aber als historische Anekdote. Man kann sich darin gefallen, sie etwas belustigt zu betrachten und nachsichtig zu schmunzeln über einen großen Geist, der eine bewiesene Grenze nicht akzeptieren wollte.
Bei aller Belustigung sollte man sich dabei aber fragen, was die Forschungslandschaft der nächsten Jahre über uns selbst erzählen wird. Wir bauen mit erheblichem Aufwand Systeme, die immer mehr Sprache aus der Welt aufsaugen und auf immer mehr Parameter verteilen, in der erkennbaren Hoffnung, dass irgendwann die Halluzinationen verschwinden, wenn man nur lange genug skaliert. Die Mathematik der letzten 90 Jahre legt nahe, dass dieser Weg an genau jene Wand stoßen wird, an die Hilbert gestoßen ist. Nicht weil die Modelle zu klein wären, sondern weil das, was wir uns von ihnen erhoffen, in der gewählten Form nicht zu haben ist.
Vielleicht stellt sich in einigen Jahren heraus, dass der heutige Ansatz für KI nicht der richtige war. Vielleicht auch nicht. Aber dass es sich lohnt, die Frage zu stellen, ob wir gerade ein zweites Mal dabei sind, eine bewiesene Grenze zu ignorieren, kann ich nur empfehlen. Die alten Studieninhalte sind vielleicht doch nicht so trocken, wie sie damals schienen.
URL dieses Artikels:
https://www.heise.de/-11308945
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Microsoft)
Microsoft stellt neuen Quantenchip Majorana 2 vor. Das Unternehmen verspricht drastisch verbesserte Stabilität und zieht die Roadmap vor.
Microsoft hat auf der Build-Konferenz seinen Quantenchip [1] Majorana 2 angekündigt. Laut der Ankündigung sollen die Qubits nun 1.000-mal zuverlässiger sein als jene im Vorgängerchip – mit einer mittleren Qubit-Lebensdauer von 20 Sekunden und vereinzelten Werten von bis zu einer Minute. Andere gängige Ansätze messen Qubit-Lebensdauern in Mikrosekunden.
Der entscheidende technische Unterschied zum Vorgänger liegt laut Microsoft im Materialmix [2]: Majorana 2 ersetzt den in Majorana 1 verwendeten Supraleiter Aluminium durch Blei und aktualisiert die aktive Halbleiterregion auf eine Kombination aus Indiumarsenid und Indiumarsenidantimonid. Diese Änderung soll zu einer signifikant robusteren topologischen Phase führen; die sogenannte topologische Lücke, die Qubits vor Umgebungsrauschen und Fehlern schützen soll, sei mehr als doppelt so groß wie beim Vorgänger, sagt Microsoft. Details dazu finden sich in dem wisschenschaftlichen Paper „20 Second Parity Lifetime in an InAs–Pb Tetron Device“ zu Majorana 2 [3]. Auf Basis dieser selbst berichteten Fortschritte hat das Unternehmen seine ursprüngliche Roadmap halbiert und peilt 2029 als Zieldatum für einen skalierbaren, kommerziell nutzbaren Quantencomputer an.
Die Bauelemente in Microsofts Quantenprozessoren bestehen aus sogenannten Tetrons, einem Typ topologischer Qubits aus zwei supraleitenden Nanodrähten mit Majorana-Nullmoden (MZMs) an ihren Enden. MZMs sollen Quanteninformation über die Parität, also die Geradzahligkeit oder Ungeradzahligkeit der Elektronenanzahl in einem Topoleiter-Draht, robust speichern. Fundamentale Operationen werden durch Messungen ausgeführt: Jede Paritätsmessung liefert eine 0 oder eine 1.
Bei der Entwicklung von Majorana 2 soll Microsofts KI-Plattform Microsoft Discovery eine wesentliche Rolle gespielt haben. Wie Microsoft beschreibt [4], soll das Quantenteam agentenbasierte KI eingesetzt haben, um Arbeitsabläufe zu verwalten, Messungen zu automatisieren, Fertigungsprozesse zu optimieren und bislang unbemerkte Fehler aufzuspüren. Das Erstellen eines topologischen Zustands erfordert das Einstellen von Hunderten Parametern – ein Prozess, der manuell Wochen dauert. KI-Agenten sollen die Zykluszeit erheblich reduzieren.
Als Beleg für externe Validierung verweist Microsoft auf seine Teilnahme am DARPA-Quantenbenchmarking-Programm. DARPA hat Microsoft als eines von nur zwei Unternehmen in die Abschlussphase seines Evaluierungsprogramms für Quantensysteme aufgenommen. In dieser Phase soll Microsoft einen fehlertoleranten Prototyp auf Basis topologischer Qubits entwickeln. Die Bewertung durch DARPA-Experten liefert zumindest einen externen Rahmen, ersetzt jedoch keine unabhängige wissenschaftliche Überprüfung der zentralen Behauptungen.
Die Ankündigung muss vor dem Hintergrund einer belasteten Forschungsgeschichte gelesen werden. Microsoft arbeitet seit rund zwei Jahrzehnten an topologischen Qubits auf Basis von Majorana-Zuständen – mit erheblichen Rückschlägen. Ein 2018 in Nature veröffentlichtes Paper eines Microsoft-Teams, das erstmals einen Majorana-Zustand nachgewiesen haben wollte, musste 2021 zurückgezogen werden, nachdem sich herausgestellt hatte, dass die ursprüngliche Datenanalyse wissenschaftlichen Qualitätsstandards nicht genügte.
Beim Nachfolger Majorana 1, den Microsoft im Februar 2025 vorstellte, war die Reaktion der Fachwelt gespalten. Zahlreiche Physiker meldeten erhebliche Zweifel an, ob topologische Qubits in realer Hardware tatsächlich so auftreten wie theoretisch vorhergesagt. Der Kernstreit: Ob die gemessenen Signale eindeutige Belege für Majorana-Nullmoden sind, oder ob sie sich auch durch konventionellere Effekte erklären lassen.
Microsofts Ansatz unterscheidet sich grundlegend von dem seiner Mitbewerber. Während Google mit Willow und IBM mit Nighthawk auf eine wachsende Zahl supraleitender Qubits mit verbesserter Fehlerkorrektur setzen [5], soll Microsofts topologische Architektur inhärent geringere Fehlerraten liefern – und damit den Overhead für Fehlerkorrektur drastisch reduzieren. Beide Mitbewerber streben ebenfalls 2029 als Zieldatum für fehlertolerantes Quantencomputing an.
URL dieses Artikels:
https://www.heise.de/-11316146
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Donald Trump spricht am 24. Februar 2024 auf einer Wahlkampfveranstaltung in National Harbor, US-Bundesstaat Maryland.
(Bild: Jonah Elkowitz/Shutterstock.com)
Geheimes Benchmarking von KI, Zugriff für die US-Regierung vor allen anderen, staatliche Suche nach Software-Bugs. Das und mehr ordnet der US-Präsident an.
Nach einigem Hin und Her hat US-Präsident Donald Trump am Dienstag doch einen Erlass zum Thema Künstliche Intelligenz veröffentlicht. Er richtet eine ganze Latte neuer Arbeitskreise ein, die sich Themen rund um KI und IT-Sicherheit widmen sollen. Klaffende Lücke bleibt Sicherheit der KI selbst – eine entsprechende Vereinbarung der US-Regierung mit der KI-Branche hat Trump am ersten Amtstag seiner zweiten Amtszeit aufgekündigt [1].
Zwar erklärt er die Förderung von KI-Innovation und Sicherheit zum offiziellen Ziel, ordnet dann aber keine konkreten Maßnahmen zur Stärkung der KI-Sicherheit an. Erreicht werden soll das durch „Zusammenarbeit mit der Privatwirtschaft zwecks Modernisierung von IT-Systemen in Verwaltung und Privatwirtschaft und deren Härtung gegen Bedrohung von außen”. Tatsächlich stellen Insider grundsätzlich die größere Bedrohung [2] dar, neuerdings kommen noch Risiken durch intern aufgesetzte KI-Agenten hinzu.
Trump belässt es bei allgemeinen Befehlen zur „Priorisierung” von IT-Abwehr bei Militär, Geheimdiensten, zivilen Behörden und deren Dienstleistern – binnen 30 Tagen. Nicht näher bezeichnete Bundesprogramme zur „Verbesserung KI-fähiger Abwehrwerkzeuge” sollen ausgeweitet oder gegründet werden. Nebenbei soll der Justizminister verstärkt gegen Straftäter vorgehen, die KI für ihre Machenschaften einsetzen.
Und Trump hält Behörden dazu, an Geld auszugeben: Einerseits sollen IT-Sicherheitswerkzeuge und -dienstleistungen beschafft werden, für Behörden des Bundes, der US-Staaten und lokaler Körperschaften, sowie für Betreiber Kritischer Infrastruktur „wie ländliche Spitäler, lokale Banken und lokale Versorgungsunternehmen”. Wer sich darum kümmern soll und aus welchem Budget das zu bedecken wäre, lässt Trump offen. Insofern handelt es sich eher um einen Wunschbrief ans Parlament, das über das Bundesbudget bestimmt.
Andererseits soll sich die Budgetabteilung des Weißen Hauses auf die Suche nach bereits bestehenden Förderprogrammen machen, deren Mittel gewidmet werden können zur Subvention von KI-Entwicklung: konkret fortschrittlicher KI zur Entdeckung von Sicherheitslücken. Die eine oder andere Umwidmung dürfte auch ohne Parlamentsbeschluss zulässig sein, in Summe aber nicht viel bringen.
Parallel dazu soll das Finanzministerium gemeinsam mit dem Verteidigungsminister vertreten durch den Geheimdienst NSA, sowie dem Minister für Heimatsicherheit vertreten durch CISA (Cybersecurity and Infrastructure Security Agency), ein KI-Clearinghouse einrichten. Dieses soll in „freiwilliger Zusammenarbeit” mit der KI-Branche und Betreibern Kritischer Infrastruktur das Scannen nach Software-Sicherheitslücken koordinieren und deeskalieren.
Das Clearinghouse soll auch selbst solche Lücken finden und bestätigen, sowie deren Schließung koordinieren und priorisieren, samt Verteilung von Sicherheitsupdates. Information der Öffentlichkeit schreibt der Erlass nicht vor. Im Endeffekt bedeutet dies, dass NSA und Co Sicherheitslücken suchen, finden, und dann steuern, ob und wann sie bei wem gefixt werden. Von Unterstützung für die darbende Schwachstellendatenbank NVD des NIST [3] ist keine Rede.
Da die KI nicht alles alleine kann, und Elon Musks Doge zahlreiche IT-Experten grundlos gefeuert hat, muss neues Fachpersonal her. Dazu hat die US-Regierung Ende 2025 die „US Tech Force” ausgerufen [4]. Dieses auf Dauer angelegte Programm erlaubt knapp 30 KI-Konzernen, insgesamt zirka 1.000 eigene Mitarbeiter für jeweils zwei Jahre in US-Ministerien zu platzieren, die dafür ausnehmend hohe Gehälter bezahlen. Die meisten der beteiligten Konzerne haben direkt oder indirekt für Donald Trump gespendet. Sein aktueller Erlass sieht vor, die US Tech Force auszuweiten: Die Behörden brauchen mehr Experten für IT-Sicherheit.
Abschnitt 3 des Erlasses zielt auf exklusiven Vorrang der US-Regierung bei sogenannten „frontier models” ab. Gemeint sind die fortschrittlichsten großen KI-Modelle, also der jeweils neueste Schrei. Sie sollen möglichst nicht mehr direkt auf den Markt kommen, sondern zunächst 30 Tage lang exklusiv der Regierung zur Verfügung gestellt werden.
Auch danach ist kein freier Marktzugang gewünscht: Vielmehr sollen Betreiber und Regierung gemeinsam festlegen, welche vertrauenswürdigen Partner das frontier model verwenden dürfen, „um sichere Innovation zu fördern und die IT-Sicherheit Kritischer Infrastruktur zu stärken”. Der Präsident kann diese Einschränkungen nicht erzwingen, weshalb er ein freiwilliges Framework für KI-Entwickler aufstellen lässt. Sie werden also voluntold, zu Freiwilligen ernannt.
Zuständig ist wieder der vom Clearinghouse bekannte Arbeitskreis aus NSA, CISA und Finanzministerium. Um feststellen zu können, was überhaupt als frontier model gilt, sollen sie einen geheimen Vergleichsmaßstab (Benchmark) ausarbeiten. Daran soll die NSA neue KI-Modelle bewerten, im Geheimen. Stuft sie eines als frontier model ein, soll die NSA KI-Entwickler und Forscher, „soweit angemessen”, informieren.
Teilnehmer des Frameworks dürfen zudem fragen, ob ein KI-Modell, an dem sie gerade arbeiten, voraussichtlich als frontier model gelten wird. Sonst könnte passieren, dass ein Konzern, seine technische Errungenschaft unterschätzend, seine freiwillige Verpflichtung verletzt und die Super-KI kurzerhand veröffentlicht.
URL dieses Artikels:
https://www.heise.de/-11316188
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Microsoft CEO Satya Nadella stellt zum Auftakt der Build die Surface RTX Spark Dev Box vor.
(Bild: Screenshot/Microsoft)
Nach dem Surface Laptop Ultra kündigt Microsoft auf der Konferenz Build einen Desktop mit RTX Spark speziell für Entwickler an.
Microsoft kündigt eine Desktop-Umgebung für die Softwareentwicklung mit Künstlicher Intelligenz an. Nachdem der kleine Ausblick auf das kommende Surface Laptop Ultra auf der Computex bereits für Aufsehen gesorgt hat, legt Microsoft jetzt mit einer Desktop-Variante auf Grundlage des neuen RTX Spark von Nvidia [1] nach: Surface RTX Spark Dev Box.
„Wir haben uns gesagt, lass uns diese Architektur bis an die Grenzen ausreizen und eine Maschine für Entwickler bauen”, sagte Microsoft-CEO Satya Nadella am Dienstagabend zum Auftakt der Entwicklerkonferenz Build in San Francisco. „Das ist wirklich eine Traummaschine.”
Die Traummaschine stellt sich einem kurzen Video in einem schwarzen Gehäuse mit einer Gitterstruktur vor. Über die inneren Werte verrät Microsoft bisher noch nicht viel [2]. „Sie hat 1 Petaflop Rechenkapazität für KI und verfügt über 20 CPU-Kerne sowie 128 Gigabyte geteilten Speicher”, verriet Nadella. Die Dev Box kommt mit Windows 11 Pro und diversen vorinstallierten Entwicklerwerkzeugen.
(Bild: Microsoft)
Die Surface RTX Spark Dev Box soll wie das Surface Laptop Ultra im Herbst erhältlich sein. Weitere Einzelheiten wie mögliche Modellvarianten oder Preise gibt es noch nicht. Interessenten können sich bei Microsoft auf eine Warteliste eintragen [3] lassen, sagte Nadella.
Abgesehen von schicker Hardware will Microsoft den Entwicklern auch die Arbeit mit Windows erleichtern – und den Umstieg, wie Nadella bemerkte. Über 70 klassische Kommandozeilen-Tools aus der Linux-Welt wie grep halten Einzug ins Terminal. Auch einige Anwendungen wie Homebrew, die man von macOS kennt, sind künftig im Terminal verfügbar. Das Terminal in Windows werde mit eingebautem Copilot zu einem „intelligenten Terminal”, so Nadella.
URL dieses Artikels:
https://www.heise.de/-11316058
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: heise medien)
Die Entwicklerkonferenz Microsoft Build 2026 liefert mehr KI-Tools und -Integration für Developer von Windows-Apps.
Microsoft [1] veranstaltet am 2. und 3. Juni 2026 die Entwicklerkonferenz MS Build 2026 [2]. Das Unternehmen wendet sich damit insbesondere an Entwickler, die ihre Software für das Windows-Ökosystem entwickeln. Wie in den vergangenen Jahren steht auch dieses Jahr wieder ganz viel Künstliche Intelligenz auf der Agenda. Konkrete Windows-Weiterentwicklung findet sich jedoch kaum.
Erneut steht die Entwicklung mit Hilfe von KI und von KI-basierten Helfern ganz oben auf der Liste [3]. Insgesamt sieben neue KI-Modelle entlässt das „Microsoft AI Superintelligence Team“ in die Welt. Darunter ist das erste Reasoning-Modell MAI-Thinking-1 von Microsoft. MAI-Image-2.5 und eine Flash-Variante davon beherrschen Text-to-Image, sie sollen Google Nano Banana Pro überholen. MAI-Transcribe-1.5 verschriftlicht Ton in 43 Sprachen, Streaming soll aber erst demnächst dazukommen. MAI-Voice-2 und eine Flash-Variante davon bedienen 15 Sprachen und haben neue Stimmen-Optionen bekommen. Beim Programmieren auf GitHub hilft MAI-Code-1. Microsoft erwähnt OpenAI in dem Zuge nicht.
Vorträge behandeln etwa das Bauen, Verteilen und Skalieren von KI-Agenten mit dem Cloud-PC Windows 365. Ein Vortrag zum Windows Subsystem for Linux verspricht Neuigkeiten. Eigentlich befassen sich bislang alle der wenigen Windows-spezifischen Vorträge mit dem Einsatz von KI-Tools zur Entwicklung unter Windows sowie mit dem Betreiben von KI-Bots wie OpenClaw. Ein Vortrag fällt etwas heraus: Er beschreibt, wie Developer mit dem Windows Terminal ihre Produktivität steigern können sollen.
Mächtig blumig umschreibt Microsofts Marketingabteilung, was Entwickler denn so bräuchten, um die Lösungen gleich mit anzubieten. Am Ende destilliert sich daraus zusammen, dass sie Sicherheit von Infrastrukturen und Apps sowie beschleunigte und vereinfachte Entwicklung benötigten. Und das nicht nur für Teilprobleme, sondern Full-Stack, mit Tools, Modellen und Prozessen nach den Vorstellungen der Developer.
Windows soll dafür selbstverständlich die ideale Plattform sein – man bekommt bei den ganzen schwerpunktmäßigen Beiträgen zu Entwicklung von und mit KI fast das Gefühl, dass das Betriebssystem komplett entkoppelt und irrelevant geworden ist. Microsoft kündigt dafür jedoch eine neue Entwickler-Konfiguration an: Die soll flexiblere und reibungslosere Shell- und Terminal-Erfahrungen liefern. Außerdem lassen sich Agents in lokale Sandboxen verfrachten: Microsoft spricht davon, Windows zu einer nativen Agent-Runtime zu machen. Als Vorschauversion gibt es die Microsoft Execution Containers (MXC) genannten Sandboxen, die bis Enterprise-tauglich sein sollen – etwa, um OpenClaw mit „Sicherheitsbeschränkungen“ auszuführen.
Die Vorschau der GitHub-Copilot-App soll agentische Entwicklung zur nativen Desktop-Erfahrung für eine viel weiterreichende Zielgruppe machen: Interessierte sollen einfach eine Idee oder ein existierendes Problem beschreiben, und schon legt die App los und lässt mehrere Agentensitzungen parallel laufen und behält die Änderungen im Blick. Jede Session setzt dabei auf git-Trees, sodass die Teile getrennt bleiben. Die Entwickler behalten die Kontrolle, während Copilot sich um die Ausführung kümmert. Entwickler sollen Apps so in Sekunden erstellen können.
Auch für Zugriff auf Datenbanken und Dienste hat Microsoft ein Backend-as-a-Service im Angebot, die Vorschau auf die Plattform Project Rayfin. Das soll die Entwicklung vom Prototypen bis zum Produktionslevel ermöglichen, ohne dass Entwickler sich um die Verwaltung von Infrastruktur kümmern müssten.
Neue KI-Hardware hat Microsoft ebenfalls zu bieten: Das Surface RTX Spark ist eine Developer-Box für dauerhafte Workloads. Training, agentische KI-Pipelines und lokales Finetuning von Modellen, all das soll sie mit einer Last von 100 Watt erledigen. Darin werkelt dem Namen entsprechend eine Nvidia RTX Spark mit bis zu einem Petaflop KI-Rechenleistung (ungenannte Präzision) und 128 GByte an RAM (unified, also mit Prozessor geteilt). Die Maschine soll Modelle mit bis zu 120 Milliarden Parameter lokal laufen lassen können.
Windows Subsystem for Linux 2 (WSL2) mit nativem GPU-Passthrough sowie vollem CUDA-Support liefert Microsoft vorkonfiguriert mit. Zudem sollen Visual Studio Code, GitHub Copilot und zahlreiche weitere beliebte Dev-Tools vorinstalliert sein. Kleiner Haken: Diese Entwicklerkiste soll erst später im Jahr verfügbar werden – und vorerst auch nur in den Vereinigten Staaten.
URL dieses Artikels:
https://www.heise.de/-11315395
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: tomeqs/Shutterstock.com)
Die Managed Cloud Services von Red Hat waren das Ziel einer Lieferkettenattacke. Dahinter steckt ein Klon des npm-Wurms Mini Shai‑Hulud.
Ende Mai haben Cyberkriminelle in einer Lieferkettenattacke, die mittels eines Mini-Shai-Hulud-Klons erfolgte, bösartige Versionen von npm-Paketen verbreitet. Ziel der Malware, die sich selbst Miasma nennt, waren die Managed Cloud Services von Red Hat. Mittlerweile sind keine bösartigen Paketversionen mehr im Umlauf. Sicherheitsexperten raten dennoch dazu, die Credentials zu rotieren.
Miasma ist eine Variante des Shai-Hulud-Wurms. Sie brachte den Sicherheitsforschern von Socket zufolge [1] 96 bösartige Versionen von 32 npm-Paketen in Umlauf, die sich dem Namespace @redhat-cloud-services zuordnen lassen. Insgesamt gab es drei Angriffswellen, die sich jeweils auf kompromittierte Konten von Projekt-Maintainern zurückführen lassen.
Laut Red Hat wurden alle drei Wellen mittlerweile gestoppt [2]. Dabei betonte der Anbieter, dass die betroffenen Pakete ausschließlich für die interne Entwicklung bestimmt gewesen seien. Ein Einfluss auf Kundenumgebungen oder Produktivsysteme sei bislang nicht festgestellt worden.
Betroffene Pakete sind unter anderem @redhat-cloud-services/vulnerabilities-client, @redhat-cloud-services/tsc-transform-imports, @redhat-cloud-services/topological-inventory-client, @redhat-cloud-services/sources-client und @redhat-cloud-services/rule-components. OX Security hat nachgezählt, dass sie zusammen wöchentlich auf mehr als 100.000 Downloads [3] kommen.
Miasma folgt dem klassischen Mini-Shai-Hulud-Schema: Die Malware nutzt gestohlene Credentials, um manipulierte npm-Pakete in der CI/CD-Lieferkette zu platzieren. Die saugen dann eine Vielzahl sensibler Informationen ab, darunter Zugangsdaten zu Amazon Web Services (AWS) sowie SSH-Schlüssel, Crypto-Wallets, npm- und GitHub-Tokens. Die gestohlenen Daten landen verschlüsselt in einem neuen GitHub-Repository, das die Malware anlegt. Von Miasma kompromittierte GitHub-Konten lassen sich an der Textzeile „Miasma : The Spreading Blight“ in der README.md [4] erkennen.
Der Cyberangriff von Miasma folgt dem Infektionsschema anderer Lieferkettenattacken, die unter der Eigenbezeichnung Mini Shai-Hulud laufen und es seit Ende April unter anderem auf npm-Pakete von SAP [5] und TanStack [6] abgesehen haben. Und er könnte mit der Cybergang TeamPCP in Verbindung stehen, die Mitte Mai den Quellcode des npm-Wurms Shai-Hulud auf GitHub veröffentlichte und parallel dazu zu einem Wettbewerb um den größten Supply-Chain-Angriff [7] aufrief. Kurz danach erschienen die ersten Klone, von denen einer kürzlich AntV [8] ins Visier nahm.
URL dieses Artikels:
https://www.heise.de/-11315039
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Android 17 ist kurz vor dem Release.
(Bild: Google)
Google hat eine weitere Beta für Android 17 veröffentlicht. Das Update auf Beta-Version 4.1 dürfte die letzten Bugs vor dem erwarteten Release ausbügeln.
Eigentlich sagte Google im April, dass das Update auf Android 17 Beta 4 [1] die „letzte geplante Beta“ des Entwicklungszyklus sei, bevor die Version als stabile Version veröffentlicht werde. Mit der Beta 4.1 kommt der Konzern also ein wenig überraschend um die Ecke. Zudem macht Google darauf aufmerksam, dass einige Hardwarepartner auch schon Betas für einige ihrer Geräte anbieten.
Das Update Android 17 Beta 4.1 ist den Release-Notes [2] zufolge recht klein, steht aber für das Pixel 6 bis hin zu den Geräten der neuen Pixel-10-Serie zur Installation bereit. Der Build CP21.260330.011.A1 ist für Pixel 6/Pro/a Pixel 7/Pro bestimmt, während sich CP21.260330.011 an alle anderen Pixel-Modelle richtet.
Hinsichtlich der Neuerungen enthält die Beta 4.1 lediglich fünf kleine Fehlerbehebungen, jedoch keine neuen Funktionen. Die aus Googles Sicht wichtigsten neuen Features hatte der Konzern im Zuge der Android Show: I/O Edition [3] am 12. Mai gezeigt – inklusive der agentischen KI Gemini Intelligence [4], die jedoch nur für High-End-Geräte bestimmt ist [5].
Google erklärt, dass es mit dem nun veröffentlichten Update ein Problem behebt, bei dem die Statusleiste fälschlicherweise keinen Signalbalken anzeigte, obwohl eine Verbindung bestand. Ebenso haben die Entwickler ein Problem mit der UI-Synchronisation gefixt, bei dem das Symbol für die Schnellsteuerung der mobilen Daten im Flugmodus aktiv blieb.
Zudem soll es keine Probleme mehr beim Anschluss externer Displays geben – zumindest sollen sie nun nicht mehr schwarz werden, wenn eine hohe Auflösung ausgewählt wird. Ebenso habe Google einen Fehler bei der Bluetooth-Audioübertragung behoben, der nach Systemunterbrechungen wie Timern zu einer Unterbrechung der Wiedergabe führte. Außerdem sollen Hörgeräte nach Inaktivität oder dem Aufladen nicht mehr automatisch aus den gekoppelten Geräten entfernt werden.
Während Google seine Betas nur für seine Pixel-Modelle anbietet, macht der Konzern darauf aufmerksam, dass einige Hardwarepartner Versionen der Android-17-Beta für ausgewählte Smartphones anbieten.
Zu den Partnern zählen Honor, iQOO, Lenovo/Motorola, OnePlus, Oppo, Realme, Sharp, Vivo und Xiaomi. Interessanterweise erwähnt Google seinen engen Partner Samsung nicht, obwohl der Konzern sein Betaprogramm auf One UI 9 auf Basis von Android 17 für die Galaxy-S26-Serie [6] gestartet hat.
Für interessierte und wagemutige Besitzerinnen und Besitzer eines der kompatiblen Modelle hat Google eine Übersichtsseite gestaltet, die zu den jeweiligen Betaprogrammen führt [7].
Auf den Webseiten der Partner finden Nutzer jeweils Anleitungen, wie sie die Android-17-Beta installieren können. Die meisten bieten System-Images zum Herunterladen und Flashen an, einige unterstützen derweil zusätzlich Over-the-Air-Updates (OTA), wie etwa Samsung über sein eigenes Betaprogramm.
URL dieses Artikels:
https://www.heise.de/-11314670
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Richard Seidl)
Ist Agilität in Unternehmen wirklich am Ende oder braucht sie nur dringend Hilfe? Das diskutiert Richard Seidl mit Miriam Sasse.
In diesem Interview spricht Richard Seidl mit Miriam Sasse über den „Patienten Agilität“. Die beiden stellen sich die Frage, ob Agilität in Unternehmen wirklich am Ende ist oder ob sie nur dringend Hilfe braucht. Mit anschaulichen Metaphern aus der Notfallmedizin befragt Miriam Sasse typische Symptome: Warum fallen Unternehmen in Krisen zurück in alte Muster? Weshalb scheint Agilität oft nicht Teil der Unternehmenskultur zu sein? Gemeinsam beleuchten sie, wie gezielte Diagnose und dosierte Maßnahmen helfen können, Teams und Prozesse nachhaltig zu stärken.
„Bei vielen heißt es schon, oh geh‘ mir weg mit agil.“ – Miriam Sasse
Dr. Miriam Sasse [2] ist promovierte Maschinenbauerin und zertifizierter Coach. Sie begleitet Organisationen bei agiler und digitaler Transformation, mit Fokus auf Deep-Tech-Teams und Game Design. Als TEDx-Speakerin und Autorin beschäftigt sie sich mit der Zukunft von Führung und Organisationsdesign. Sie lehrt an Hochschulen und leitet die Regionalgruppe der GPM OWL.
Dieses Format fokussiert sich auf Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste betrachten die Dinge, die die Qualität in der Softwareentwicklung steigern.
Die aktuelle Episode ist auch auf Richard Seidls Blog verfügbar [3].
URL dieses Artikels:
https://www.heise.de/-11314073
Links in diesem Artikel:
Copyright © 2026 Heise Medien
