Anmelden
(Bild: tre / Mac & i)
Apple erweitert die Möglichkeiten für Entwickler im App Store. Neben neuen Gestaltungsmöglichkeiten fällt unter anderem die Intel-Pflicht für den Mac weg.
Abseits der viel beachteten Neuerungen rund um KI, Siri und die Betriebssysteme hat Apple im Zuge der Entwicklerkonferenz WWDC auch eine ganze Reihe von Neuheiten und Änderungen für App Store [1]-Entwickler angekündigt. Künftig können erstmals Gruppenkäufe für Abonnenten und entwicklerübergreifende Bundles angeboten werden. Im Mac App Store entfällt die Intel-Pflicht und Entwickler bekommen die Möglichkeit, Nutzer zur Fortsetzung eines Abos zu bewegen. Zudem gibt es mehr Gestaltungsmöglichkeiten für den Auftritt im App Store und neue Auskunftspflichten. Das aus Nutzersicht umstrittenste neue Feature dürfte das sogenannte Retention Messaging werden. Apple bietet neue Werkzeuge in App Store Connect an, um Abonnenten mit Kündigungsabsicht über Apples Abo-Plattform ansprechen zu können. Bereits im März hatte Apple den Analytics-Bereich in App Store Connect massiv erweitert und Entwicklern dabei über 100 neue Metriken für Abonnements und In-App-Käufe [2] an die Hand gegeben. Laut Ankündigung [3] sollen personalisierte Nachrichten und Sonderangebote möglich sein.
Ganz neue Vermarktungsmöglichkeiten für Apps ergeben sich durch entwicklerübergreifende App-Bundles. Bislang konnte nur ein einzelner Entwickler, der mehrere Apps anbietet, ein vergünstigtes Paket mit mehreren Apps schnüren. Künftig ist das auch für mehrere Entwickler möglich, sodass sich diese bei den Apps zusammentun können. Apple führt zudem ab Winter 2026 Gruppenkäufe für Abonnements ein. Ein einzelner Abonnent kann damit Lizenzen für mehrere Personen in einem einzigen Kauf erwerben.
Apples Abkehr von der Intel-Plattform im neuen macOS Golden Gate [4] schlägt sich auch im Mac App Store nieder: Künftig ist es für App-Entwickler keine Pflicht mehr, Intel-Unterstützung vorzuhalten. Dies dürfte in einigen Fällen dazu beitragen, dass Besitzer eines Intel-Macs eher in die Situation geraten, den Umstieg auf einen Apple-Silicon-Mac erwägen zu müssen – etwa wenn häufig genutzte Apps künftig nicht mehr den Intel-Mac unterstützen. Wann genau Intel-Apps unter Apple Silicon nicht mehr laufen werden und was das Ende von Rosetta 2 für Nutzer bedeutet, erklärt unser Überblick zum Zeitplan des Intel-Supports [5].
Vereinfachungen und Erweiterungen gibt es beim App-Marketing. Die neuen Betriebssysteme, darunter iOS 27 und macOS 27, stehen Entwicklern bereits als Beta [6] zur Verfügung. In einer neuen Asset Library können Grafiken, Vorschauvideos und Screenshots zentral verwaltet werden. Diese Assets können nun auch unabhängig von einem App-Update zur Prüfung eingereicht werden – und Apple öffnet die Produktseiten-Header für eigenes Bild- und Videomaterial. Neue „Personalized Collections“ sollen maßgeschneiderte App-Empfehlungen für Nutzer ermöglichen. Diese Funktion startet zunächst auf Englisch in den USA.
Und Apples angekündigte erweiterte Jugendschutzfunktionen wirken sich auch auf die Entwickler aus. Diese müssen Social-Feed-Funktionen in ihren Apps künftig angeben. Zudem werden Apps in die neuen Nutzungszeit-Kategorien (Soziale Netzwerke, Unterhaltung, Spiele, Andere) eingruppiert. Der Altersfreigabe-Fragebogen soll hierfür ab Juli aktualisiert werden.
URL dieses Artikels:
https://www.heise.de/-11330851
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: jackpress/Shutterstock.com)
Nach Kritik an heimlich manipulierten Antworten rudert Anthropic zurück: Die Schranken von Fable 5 werden sichtbar – auf Kosten von mehr Fehlalarmen.
Anthropic reagiert auf die Kritik an den Schutzmechanismen seines neuen KI-Modells Fable 5 [1]. Das Unternehmen will umstrittene, verborgene Sicherheitsmaßnahmen künftig sichtbar machen und entschuldigt sich ausdrücklich für deren bisherige Umsetzung. Konkret geht es um Schutzmechanismen gegen sogenanntes Distillation – also den Versuch, die Ausgaben eines leistungsfähigen Sprachmodells zum Training konkurrierender KI-Systeme zu nutzen.
Die Kontroverse entzündete sich an einem Schutzverhalten von Fable 5, bei dem das Modell verdeckt auf Distillation-Anfragen reagierte. Anthropic sah ursprünglich einen unsichtbaren Mechanismus vor, der solche Versuche zur Modellentwicklung im Hintergrund erkennt und die Antworten gezielt verändert oder verschlechtert. Die Nutzer sollten davon nichts mitbekommen. Forscher und Entwickler kritisierten das als intransparent und warnten, dass solche verdeckten Eingriffe auch Tests und wissenschaftliche Untersuchungen des Modells verfälschen.
In einem Beitrag auf X [2] kündigt Anthropic nun eine Kurskorrektur an. Künftig behandelt das Unternehmen erkannte Distillation-Anfragen sichtbar. Statt Antworten heimlich zu verändern, fällt Fable 5 in solchen Fällen auf das ältere Modell Claude Opus 4.8 [3] zurück – genau wie es bereits bei den Schutzmaßnahmen für Cybersecurity und Biologie der Fall ist. Die Nutzer sollen dabei jedes Mal einen entsprechenden Hinweis sehen.
Für API-Kunden will Anthropic zudem den Grund einer Ablehnung explizit zurückgeben. Ein serverseitiger Fallback für API-Anfragen soll in den kommenden Tagen folgen. Damit lässt sich künftig erkennen, ob eine Antwort von Fable 5 oder vom Fallback-Modell stammt.
Das Unternehmen gibt zu, mit dem ursprünglichen Ansatz falsch gelegen zu haben. Sichtbare Schutzmechanismen lassen sich zwar leichter analysieren und gezielt umgehen, weshalb ihre Absicherung mehr Zeit kostet. Unsichtbare Schutzmaßnahmen lassen sich dagegen enger auf bestimmte Szenarien zuschneiden und verursachen weniger Fehlalarme. Aus diesem Grund habe man sich zunächst für den verdeckten Ansatz entschieden, um Fable 5 schnell und sicher bereitzustellen.
Rückblickend sei das die falsche Entscheidung gewesen, schreibt Anthropic. Die Nutzer sollten nachvollziehen können, welche Schutzmaßnahmen aktiv sind und warum. Dafür entschuldigt sich das Unternehmen ausdrücklich.
Die Umstellung hat allerdings Nebenwirkungen. Um die Systeme trotzdem vor Jailbreaks abzusichern, müssen die zugrunde liegenden Klassifikatoren zunächst konservativer arbeiten. Das führt vorübergehend zu mehr Fehlklassifikationen.
Solche False Positives entstehen, wenn das Modell harmlose Anfragen fälschlich als riskant einstuft. Genau hier setzt ein Großteil der bisherigen Kritik an.
Die Ankündigung folgt nur wenige Tage auf heftige Kritik von Sicherheitsforschern [4] an Fable 5. Mehrere Experten beklagen, dass die Cybersecurity-Schranken des Modells nicht nur brisante Anfragen erfassen, sondern auch alltägliche Aufgaben aus Softwareentwicklung und IT-Sicherheit. Genannt wurden unter anderem Code Reviews, das Schreiben sicheren Codes, Schwachstellenanalysen, Incident Response oder schlicht das Lesen sicherheitsrelevanter Fachartikel.
Fable 5 ist die öffentlich verfügbare Variante von Anthropics neuem Spitzenmodell Mythos 5. Letzteres bringt keine vorgeschalteten Schutzmechanismen für Cybersecurity, Biologie, Chemie und Distillation mit.
In seiner Stellungnahme verspricht Anthropic auch Änderungen an den Cyber- und Bio-Safeguards. Die entsprechenden Klassifikatoren stelle man derzeit so ein, dass sie seltener bei harmlosen Anfragen anschlagen. Nutzer, die eine Fehlklassifikation vermuten, sollen diese melden – über Feedback-Funktionen in Claude Code und Claude.ai sowie über ein Einspruchsformular für API-Anfragen.
Ob die Anpassungen ausreichen, bleibt abzuwarten. An den Schutzmaßnahmen selbst hält Anthropic ausdrücklich fest – diese hatten die Kritiker allerdings auch nicht infrage gestellt.
URL dieses Artikels:
https://www.heise.de/-11330094
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Gorodenkoff / Shutterstock.com)
Databricks übergibt OpenSharing an die Linux Foundation. Das Protokoll soll den Austausch von KI-Modellen, Agent-Skills und Daten standardisieren.
Mit OpenSharing hat das Unternehmen Databricks ein offenes Protokoll vorgestellt, das den sicheren Austausch von Daten und KI-Assets wie Modellen, Agent-Skills und unstrukturierten Daten über Plattform-, Cloud- und Organisationsgrenzen hinweg standardisieren soll. Das Projekt wird ab sofort von der Linux Foundation als Open-Source-Community [1]-Projekt gehostet und steht auf GitHub zur Verfügung.
OpenSharing [2] baut auf dem von Databricks bereits 2021 eingeführten Delta Sharing [3] auf, einem Open-Source-Protokoll für den sicheren Datenaustausch. Während sich Delta Sharing auf strukturierte Daten in Tabellenformaten wie Delta Lake konzentrierte, erweitert OpenSharing das unterstützte Spektrum an Daten und Formaten erheblich: Neben tabellarischen Daten lassen sich nun auch KI-Modellartefakte, Agent-Skills – also Funktionen und Tools für autonome Agenten – sowie unstrukturierte Daten wie Dokumente oder Mediendateien über ein einheitliches Protokoll teilen. Das Protokoll orientiert sich zudem am Zero-Copy-Prinzip: Daten werden nicht repliziert, sondern Clients greifen direkt auf den Quellspeicher zu.
Technisch definiert OpenSharing standardisierte APIs für Discovery, Authorization und Access. Laut den Projektverantwortlichen können Nutzer damit ein einheitliches Schnittstellenset ansprechen, unabhängig von der dahinterliegenden Plattform. Die konkreten Authentifizierungsmechanismen – etwa ob OAuth2 oder OIDC zum Einsatz kommen – sind in den bisherigen Veröffentlichungen nicht im Detail dokumentiert. Die vollständige Spezifikation soll jedoch über das GitHub-Repository [6] zugänglich gemacht werden. Aus der Delta-Sharing-Architektur ist bekannt, dass ein Sharing-Server als Kontrollebene fungiert und der eigentliche Datenzugriff über vorab signierte URLs auf Cloud- oder Objektspeicher läuft.
Eine wesentliche Neuerung gegenüber Delta Sharing ist der Support für Apache-Iceberg-Clients. Provider können damit über ein einzelnes Protokoll sowohl Delta- als auch Iceberg-basierte Empfänger bedienen. Betreiber von Lakehouse-Architekturen profitieren dadurch von einer reduzierten Fragmentierung im Open-Data-Ökosystem: Engines wie Spark, Trino oder Flink mit Iceberg-Support erhalten einen standardisierten Zugriffspfad auf geteilte Assets, ohne dafür auf proprietäre Adapter zurückgreifen zu müssen.
Die Linux Foundation [7] stellt für OpenSharing herstellerneutrale Governance-Strukturen bereit. Laut Jim Zemlin, CEO der Linux Foundation, soll OpenSharing das „kritische Bedürfnis nach einem gemeinsamen, herstellerneutralen Framework, das Organisationen den sicheren und interoperablen Austausch von KI-Assets über Plattformen und Ökosysteme hinweg ermöglicht“, erfüllen. Das Projekt reiht sich damit in andere Infrastrukturstandards unter dem Dach der Linux Foundation ein, bei denen neutrale Governance für breitere Akzeptanz sorgen soll, darunter etwa Kubernetes, RISC-V und MCP (letzteres über die Agentic AI Foundation, einer Stiftung innerhalb der Linux Foundation).
Delta Sharing hat nach Einschätzung von Databricks-Mitgründer und CTO Matei Zaharia bereits bewiesen, dass die Branche offene Standards bevorzuge. OpenSharing werde dieses Prinzip auf den gesamten KI-Stack und das plattformübergreifende Ökosystem erweitern.
Bei Unternehmen mit strengen Datenschutz- und Souveränitätsanforderungen – etwa in regulierten Branchen wie dem europäischen Bankwesen, Gesundheitswesen oder der öffentlichen Verwaltung – dürfte OpenSharing auf Interesse stoßen. Durch das Zero-Copy-Prinzip verbleiben Daten physisch in der bestehenden Speicherumgebung, sei es ein eigenes Rechenzentrum oder eine europäische Cloud. Cloud-basierte KI-Dienste greifen über das Protokoll zu, ohne dass Daten bewegt werden müssen. Das erleichtert die Einhaltung von DSGVO-Anforderungen und Daten-Minimierungsansätzen, weil für alle Beteiligten nicht mehr in jedem Fall separate Kopien angelegt werden müssen.
(Bild: OpenSharing-IO [8])
Zum Projektstart positionieren sich bereits zahlreiche Unternehmen als Unterstützer. Atlassian hat Data Shares in Atlassian Analytics eingeführt und nutzt OpenSharing, um Zugriff auf Cloud-Daten in großem Maßstab zu ermöglichen. SAP setzt in der Business Data Cloud auf das Protokoll, Stripe integriert es nativ in die Stripe Data Pipeline und die London Stock Exchange Group (LSEG) bindet es in ihre „LSEG Everywhere“-Strategie ein.
Dass mit SAP ein zentraler europäischer Softwareanbieter das Protokoll früh übernimmt und auch Storage-Hersteller wie NetApp und HPE – mit starker Präsenz in europäischen Rechenzentren – ihre Unterstützung angekündigt haben, unterstreicht die Ausrichtung auf regulierte On-Premise-Szenarien. OpenSharing positioniert sich damit als offene Alternative zu den proprietären Datenmarktplätzen der großen Hyperscaler.
URL dieses Artikels:
https://www.heise.de/-11328802
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Pincasso / Shutterstock.com)
Bei TryAdd() und TryGetValue() erhalten Entwicklerinnen und Entwickler die Position eines gegebenenfalls vorhandenen Elements.
Die erst in .NET 9.0 eingeführte generische Klasse System.Collections.Generic.OrderedDictionary<T,T> bot bisher schon eine Methode TryAdd(), die versucht, ein Element hinzuzufügen. Neben der bestehenden Variante TryAdd(TKey key, TValue value) gibt es nun in .NET 10.0 auch die Methode mit drei Parametern TryAdd(TKey key, TValue value, out int index). Diese neue Überladung liefert im dritten Parameter den Index zurück, falls es das Element in der Menge schon gibt.
Analog dazu gibt es für die Methode TryGetValue() nun ebenfalls eine neue Überladung, die nicht nur den Wert eines Eintrags liefert, sondern auch die Position des gefundenen Elements per Index.
Folgender Beispielcode nutzt TryAdd(TKey key, TValue value, out int index) in der Klasse OrderedDictionary:
FreshRSS public void Run()
{
CUI.Demo("OrderedDictionary<T,T>: TryAdd() mit Index and TryGetValue()");
OrderedDictionary<string, string> websites = new();
websites.Add("Heise", "www.Heise.de");
websites.Add("Software & Support", "www.entwickler.de");
websites.Add("IT-Visions", "www.IT-Visions.de");
websites.Add("Microsoft", "www.Microsoft.com");
var key = "IT-Visions";
var value = "www.IT-Visions.de";
foreach (var item in websites)
{
CUI.OL(item.Key + " -> " + item.Value);
}
CUI.BR();
// --- ALT: TryGetValue() mit 2 Parametern
if (websites.TryGetValue(key, out string? value1))
{
int index3 = websites.IndexOf(key); // Nochmals nachschauen nach der Position
CUI.Success($"Element {value1} wurde gefunden an der Position {index3}.");
}
// --- NEUE Überladung bei TryGetValue() mit Parameter index
if (websites.TryGetValue(key, out string? value4, out int index4))
{
CUI.Success($"Element {value1} wurde gefunden an der Position {index4}.");
}
// --- ALT: TryAdd() mit 2 Parametern
if (!websites.TryAdd(key, value))
{
int index1 = websites.IndexOf(key); // Nochmals nachschauen nach der Position
CUI.Warning($"Element {value} ist bereits vorhanden an der Position {index1}!");
}
else
{
CUI.Success($"Element {value} wurde hinzugefügt.");
}
// --- NEUE Überladung von TryAdd() liefert jetzt auch den Index (Position) zurück
if (!websites.TryAdd(key, value, out int index2))
{
CUI.Warning($"Element {value} ist bereits vorhanden an der Position {index2}!");
}
else
{
CUI.Success($"Element {value} wurde hinzugefügt.");
}
}
URL dieses Artikels:
https://www.heise.de/-11329738
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Axel Kannenberg/iX/KI)
Seit Beginn des Jahres haben die Aktienkurse großer Softwareanbieter stark gelitten. Ein Gespräch, ob Künstliche Intelligenz die SaaSpokalypse bringt.
Die Diskussion um eine mögliche „SaaSpocalypse“ [1] treibt die Softwarebranche seit Monaten um. Der Begriff bringt die Sorge auf den Punkt: dass generative KI und vor allem autonome KI-Agenten das klassische Geschäftsmodell von Software-as-a-Service infrage stellen. Wir sprachen mit dem Tech-Analysten Philipp Klöckner darüber, wohin die Entwicklung geht.
iX: Derzeit wird viel über die SaaSpocalypse gesprochen, selbst große Anbieter wie Salesforce oder SAP stehen an der Börse unter Druck. Ist das eine Überreaktion oder ein fundamentaler Wandel des Softwaremarkts?
(Bild: Hubert Boesl)
Philipp Klöckner: Beides. In einigen Bereichen ist die Reaktion übertrieben, in anderen Fällen sollten Unternehmen tatsächlich vorsichtig sein. Besonders unter Druck geraten Firmen mit klassischen „Per-Seat“-Modellen – also Anbieter, die pro Mitarbeiter abrechnen. Dazu zählen typische Kollaborations- und Projektmanagementtools wie Asana, Monday.com oder Teile der Atlassian-Suite wie Jira.
Der Hintergrund ist weniger, dass KI bereits massiv Jobs ersetzt, sondern dass viele Unternehmen das Overhiring der Coronazeit korrigieren und ihre Organisationen verschlanken. Weniger Mitarbeiter bedeuten automatisch geringeres Wachstum für solche SaaS-Modelle. Zudem lässt sich ein einfaches Kollaborationstool mit Nutzerverwaltung heute relativ schnell KI-gestützt entwickeln. Dadurch steigt der Wettbewerbsdruck erheblich.
Gleichzeitig halte ich manche Marktreaktionen für überzogen. Wenn etwa Anthropic ein neues Feature ankündigt und daraufhin Cybersecurity- oder Observability-Aktien zweistellig fallen, verwechselt das die Realität des Unternehmenseinkaufs mit Tech-Euphorie. Unternehmen wechseln ihre Kernsoftware nicht kurzfristig. Vertrauen, langfristige Verträge und hohe Lock-in-Effekte spielen eine enorme Rolle.
Was allerdings schwieriger wird: Neukundengewinnung. Start-ups, die heute beginnen, werden sich häufiger fragen, ob sie klassische SaaS-Produkte überhaupt noch kaufen oder bestimmte Lösungen selbst bauen. KI senkt die Einstiegshürden erheblich. Trotzdem sollte man die Wirtschaftlichkeit bestehender Software nicht unterschätzen. SaaS-Unternehmen arbeiten oft mit Rohmargen von 80 bis 90 Prozent. Wer Software selbst entwickelt, muss inklusive Wartung, Sicherheit und Zuverlässigkeit günstiger sein als eine bestehende Lizenzlösung – und das ist keineswegs trivial. Ich glaube deshalb nicht, dass Fortune-500-Unternehmen ihre ERP- oder CRM-Systeme kurzfristig durch Vibe-Coding-Lösungen ersetzen werden.
Low-Code- und No-Code-Plattformen haben schon früher versprochen, dass jeder Software bauen kann. Was ist diesmal anders?
Der Unterschied liegt vor allem in den Anforderungen an den Nutzer. Bei No-Code brauchte man oft noch relativ fortgeschrittene Produktmanagement- oder Toolkenntnisse. Mit generativer KI reicht heute Sprache als Interface: Wer ein Problem gut beschreiben kann, kommt deutlich schneller zu funktionierender Software.
Das heißt aber noch nicht automatisch, dass daraus professionelle Produkte entstehen, die man problemlos anderen Unternehmen verkaufen kann. Besonders schwierig bleibt die Integration in bestehende Legacy-Systeme. Die eigentliche Stärke von KI liegt momentan eher darin, neue und vergleichsweise einfache Lösungen „from scratch“ zu entwickeln – insbesondere in Nischenmärkten, für die sich früher kein eigenes Softwareunternehmen gelohnt hätte.
Gehen wir damit in die Richtung hyperindividualisierter Software und hin zu Mikromärkten?
Ja, das halte ich für wahrscheinlich. Vor einigen Jahren tauchte auf der OMR-Messe der Begriff „Disposable Software“ auf – also Wegwerfsoftware. Früher lag der Fokus darauf, möglichst modular und wiederverwendbar zu entwickeln. Künftig könnte Software viel stärker situativ entstehen.
Mit KI kann man für relativ geringe Kosten kleine Anwendungen generieren, testen und später wieder verwerfen oder komplett neu bauen. Dadurch verändert sich auch die Architekturphilosophie: Statt hochgradig modularer Systeme könnten häufiger Monolithen entstehen, die bei Änderungen einfach neu generiert werden. Das könnte bedeuten, dass Software künftig stärker „on demand“ entsteht und weniger langfristig gepflegt wird.
Werden die hohen Margen etablierter Softwareanbieter bestehen bleiben?
Teilweise ja. Die Verhandlungsmacht der Anbieter könnte sinken, weil Kunden heute glaubhafter sagen können: „Im Zweifel bauen wir Teile selbst.“ Bei großen Enterprise-Systemen bleiben die Wechselkosten aber enorm. Ein SAP-Wechsel dauert oft 18 bis 36 Monate und belastet ganze Organisationen. Deshalb halte ich es für unwahrscheinlich, dass große Unternehmen kurzfristig SAP, Salesforce, Oracle oder IBM verlassen.
Stärker unter Druck geraten dürften Anbieter, die viele Branchen gleichzeitig bedienen. KI erleichtert den Aufbau vertikaler Spezialsoftware – etwa nur für Arztpraxen, Zahnarztpraxen oder Solarinstallateure. Diese spezialisierten Lösungen könnten mittelgroße Kunden zunehmend anziehen.
Und auf welche Burggräben können die Softwareunternehmen dann künftig bauen?
Kundenzugang, Datentiefe und Lock-in-Effekte. Viele aktuelle KI-Projekte sind zunächst Datenprojekte. Unternehmen stellen fest, dass ihre Daten gar nicht KI-tauglich strukturiert sind. Deshalb profitieren Anbieter, die bereits tief in Unternehmensprozesse integriert sind oder Datenhaltung und Taxonomien kontrollieren. Wer die Daten sauber organisiert hat, kann KI deutlich einfacher integrieren.
Hinzu kommt: Viele Unternehmen bevorzugen KI-Funktionen von bestehenden Anbietern. Sie wollen keine zusätzlichen Datenquellen, Sicherheitsrisiken oder Integrationsaufwände. Deshalb haben Anbieter mit bestehenden System-of-Record-Positionen, also als maßgebliche Quellen für Geschäftsdaten, weiterhin Vorteile.
Welche Chancen haben Start-ups und Open-Source-Projekte in dieser Lage?
Open Source erlebt derzeit quantitativ Rückenwind: Mehr Menschen beteiligen sich an Projekten und entwickeln gemeinsam Lösungen. Gleichzeitig berichten viele Communitys aber auch über Qualitätsprobleme bei KI-generiertem Code.
Entscheidend wird künftig wahrscheinlich weniger die reine Produktentwicklung sein, sondern der Go-to-Market-Ansatz. Wenn gute Software leichter reproduzierbar wird, gewinnen Marketing, Distribution und Community-Aufbau an Bedeutung. Product-led Growth allein könnte schwieriger werden. Stattdessen zählen Positionierung, Branchenfokus und Kundenzugang stärker.
Konzerne wie IBM, aber auch Mittelständler haben lange sehr gut an Legacy-Technik verdient. Sind diese goldenen Legacy-Zeiten auch vorbei?
Nicht sofort. Die größere Gefahr besteht eher darin, dass Märkte fragmentieren. Statt eines großen Softwaremarkts entstehen viele kleine vertikale Märkte – etwa spezialisierte Branchenlösungen für einzelne Industrien oder Länder. Bestehende Anbieter behalten oft regulatorische Vorteile und bestehende Infrastruktur. Gleichzeitig bauen neue Anbieter modernere Frontends auf bestehende Systeme auf und greifen so schrittweise Teile der Wertschöpfung an. Die Börsen versuchen natürlich sehr schnell, eine Entwicklung vorwegzunehmen. Dieser Wandel dürfte aber langsam verlaufen. Unternehmen tauschen ihre Kernsoftware nicht abrupt aus, und KI-generierte Software erfüllt bislang häufig noch nicht die Anforderungen an Sicherheit, Wartbarkeit und Zuverlässigkeit im Enterprise-Bereich.
Wenn das Per-Seat-Modell unter Druck gerät – wie sehen zukünftige Preismodelle aus?
Es wird wahrscheinlich viele neue Modelle geben. Eine Möglichkeit wäre eine erfolgsbasierte Abrechnung, etwa bei einer Recruiting-Software pro Einstellung. Auch umsatzbasierte Modelle sind denkbar, bei denen die Unternehmensgröße zählt und nicht mehr der einzelne Mitarbeiter.
Besonders wichtig dürfte Consumption-based Pricing werden. Anbieter kaufen Rechenleistung oder Token ein und verkaufen darauf aufbauende KI-Dienste mit Aufschlag weiter. Der eigentliche Wert liegt dann in der zusätzlichen Softwarelogik oder Agentenstruktur. Die Wertschöpfung verschiebt sich damit entlang der KI-Infrastrukturkette.
Was bedeutet die von Ihnen skizzierte Entwicklung für Developer und IT-Abteilungen?
Gut ausgebildete Entwickler und Architekten dürften eher profitieren. Gefährdet sind vor allem standardisierte Outsourcing-Tätigkeiten – etwa einfache API-Anbindungen, Parser oder Scraper. Solche Aufgaben lassen sich heute teilweise mit wenigen KI-Prompts erledigen. Gleichzeitig steigt aber der Gesamtbedarf an Softwareentwicklung, weil nun viele kleine und spezialisierte Anwendungen wirtschaftlich werden.
Deshalb könnte künftig weniger der klassische Coder gefragt sein, sondern stärker Menschen, die Probleme verstehen, Softwarearchitekturen entwerfen und Produkte konzipieren können. Der entscheidende Wandel lautet möglicherweise: Weniger Menschen schreiben direkt Code – aber mehr Menschen bauen Software.
URL dieses Artikels:
https://www.heise.de/-11329358
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Pincasso / Shutterstock.com)
Die Preview verbessert das Blazor Static Server Side Rendering. In C# 15.0 lassen sich Klassen nun von der Vererbung in anderen Assemblies ausschließen.
Die fünfte Vorschauversion der kommenden .NET-Version 11.0 ist gestern Abend erschienen [1]. Parallel dazu gab es auch die Version 11904.113 der für .NET 11.0 notwendigen Insiders-Variante von Visual Studio 2026 [2]. Alternativ ist eine Arbeit mit Visual Studio Code und dem im SDK mitgelieferten Kommandozeilencompiler möglich.
Bei dem in .NET 8.0 [5] eingeführten statischen serverseitigen Rendering (Blazor Static SSR), das als eine Ablösung für ASP.NET Core MVC und ASP.NET Core Razor Pages verstanden werden kann, funktioniert das Tabellensteuerelement QuickGrid, das Microsoft im NuGet-Paket Microsoft.AspNetCore.Components.QuickGrid liefert, bisher nur eingeschränkt. Lediglich bei den interaktiven Varianten Blazor Server und Blazor WebAssembly sowie Blazor Hybrid stehen alle Funktionen des QuickGrid-Steuerelements zur Verfügung.
Seit Blazor 11.0 Preview 5 ist es möglich, dass das QuickGrid-Steuerelement auch in statisch serverseitig gerenderten Blazor-Seiten sortieren und blättern kann. Wenn das Grid nicht interaktiv ist, werden die sortierbaren Spaltenüberschriften und die Seitennavigation als erweiterte HTML-Formulare gerendert, die ihren Zustand über URL-Abfrageparameter (Query String) übertragen. Lädt eine Nutzerin oder ein Nutzer die Seite neu oder kopiert die URL und öffnet sie erneut, bleiben Sortierung und aktuelle Seite erhalten. Dadurch lassen sich diese Zustände einfach per URL teilen oder als Lesezeichen speichern.
Im Schnelltest zeigte sich: In Zusammenarbeit mit Entity Framework Core als Datenquelle mit Paging in der Datenbank erzeugt das Blättern einen Laufzeitfehler: „InvalidOperationException: A second operation was started on this context instance before a previous operation completed. This is usually caused by different threads concurrently using the same instance of DbContext.“
Das folgende Beispiel funktioniert aktuell nur korrekt, wenn es immer alle Datensätze lädt und das Paging im RAM ausführt via
private List<BO.WWWings.Flight> flightSet => context.Flights.ToList();
@page "/QuickGridSSR"
@using Microsoft.AspNetCore.Components.QuickGrid
@using Microsoft.EntityFrameworkCore
@inject IDbContextFactory<DA.WWWings.WwwingsV1EnContext> DbFactory
@implements IAsyncDisposable
<PageTitle>QuickGrid SSR</PageTitle>
<h1>Sortieren und Paging beim QuickGrid bei Blazor Static SSR</h1>
<QuickGrid Class="table table-striped sticky-grid"
Items="@flightSet" Pagination="@pagination">
<PropertyColumn Property="@(p => p.FlightNo)" Title="FlugNr" Sortable="true" />
<PropertyColumn Property="@(p => p.Departure)" Title="Abflugort" Sortable="true">
</PropertyColumn>
<PropertyColumn Property="@(p => p.Destination)" Title="Zielort" Sortable="true">
</PropertyColumn>
<PropertyColumn Property="@(p => p.FlightDate)" Title="Datum" Format="dd.MM.yyyy" Sortable="true" />
<PropertyColumn Property="@(p => p.FreeSeats)" Title="Freie Plätze" />
</QuickGrid>
<Paginator State="@pagination" />
@code {
private readonly PaginationState pagination = new() { ItemsPerPage = 15 };
private DA.WWWings.WwwingsV1EnContext context;
private IQueryable<BO.WWWings.Flight> flightSet => context.Flights;
protected override void OnInitialized()
{
context = DbFactory.CreateDbContext();
}
// IAsyncDisposable implementieren, um den DbContext korrekt zu verwerfen, wenn die Komponente nicht mehr benötigt wird
public async ValueTask DisposeAsync()
{
if (context != null)
{
await context.DisposeAsync();
}
}
}Listing: QuickGrid mit Blazor Static SSR mit Zugriff auf eine Datenbank via Entity Framework Core
Blazor Static SSR unterstützt seit der Einführung in .NET 8.0 die in ASP.NET Core verfügbaren serverseitigen Sessions (Cookie .AspNetCore.Session mit Session-ID, Speicherung der Daten im RAM oder einem persistenten Speicher) zur Datenübergabe zwischen Seiten. Bisher mussten Entwicklerinnen und Entwickler dafür das Session-Objekt im HttpContext-Objekt verwenden und komplexe Objekte selbst per JSON serialisieren:
@inject IHttpContextAccessor HttpContextAccessor
…
var HttpContext = HttpContextAccessor.HttpContext;
var json = System.Text.Json.JsonSerializer.Serialize(regForm);
HttpContext.Session.SetString("Formulardaten", json);beziehungsweise
BO.RegistrationData daten =
System.Text.Json.JsonSerializer.Deserialize<BO.RegistrationData>(
HttpContext.Session.GetString("Formulardaten") ?? string.Empty);In .NET 11.0 Preview 5 hat Microsoft nun die Annotation [SupplyParameterFromSession] eingeführt, die die Handhabung von Session-Variablen genauso einfach macht wie von Query-String-Parametern [SupplyParameterFromQuery], Form-Daten [SupplyParameterFromForm] und TempData-Werten [SupplyParameterFromTempData], wobei letztere Annotation erst in .NET 11.0 Preview 4 eingeführt wurde [6].
Entwicklerinnen und Entwickler annotieren in einer Seite eine oder mehrere Properties mit der Annotation [SupplyParameterFromSession]. Dabei sind einfache und komplexe Datentypen möglich, während [SupplyParameterFromTempData] auch in Preview 5 weiterhin nur mit einfachen Datentypen funktioniert:
[SupplyParameterFromSession]
public string Message { get; set; }
[SupplyParameterFromSession]
public BO.RegistrationData RegData { get; set; }Session-Werte werden dabei automatisch mit System.Text.Json in JSON serialisiert.
Analoge Properties deklarieren Entwicklerinnen und Entwickler in den Folgeseiten und können dann auf die Werte ohne weiteres Zutun zugreifen. Voraussetzung ist wie bisher, dass in der Startseite die Sessions aktiviert wurden:
builder.Services.AddDistributedMemoryCache();
builder.Services.AddSession();
…
app.UseSession();Bei Blazor Static SSR fand die Validierung von Formulareingaben bisher immer serverseitig statt. Microsoft hat in .NET 11.0 Preview 5 in der blazor.web.js-Datei, die bei Blazor Static SSR im Standard eingebunden ist, die clientseitige Validierung per JavaScript ergänzt. Dabei wird wie üblich in Blazor <EditForm> mit <DataAnnotationsValidator> eingesetzt. Andere Validatoren wie Fluent Validation [7] sind optional möglich.
Beim Programmstart ist (wie bisher) notwendig:
builder.Services.AddValidation();Eine serverseitige Validierung findet aus Sicherheitsgründen weiterhin zusätzlich statt.
/// <summary>
/// Variante der Kontakt-Klasse OHNE Lokalisierung
/// </summary>
[ValidatableType]
public class ContactModel
{
[Required(ErrorMessage = "{0} ist erforderlich.")]
[StringLength(100, MinimumLength = 2, ErrorMessage = "{0} muss zwischen {2} und {1} Zeichen lang sein.")]
[Display(Name = "Name")]
public string? Name { get; set; }
[Required(ErrorMessage = "{0} ist erforderlich.")]
[EmailAddress(ErrorMessage = "{0} ist ungültig.")]
[Display(Name = "E-Mail")]
public string? Email { get; set; }
[Required(ErrorMessage = "{0} ist erforderlich.")]
[StringLength(500, MinimumLength = 10, ErrorMessage = "{0} muss zwischen {2} und {1} Zeichen lang sein.")]
[Display(Name = "Nachricht")]
public string? Message { get; set; }
}Listing: Modellklasse für die Validierung
@page "/SSRClientValidation"
@using Models
<PageTitle>Kontakt</PageTitle>
…
<div class="form-card">
<EditForm Model="contact" Enhance OnValidSubmit="HandleSubmit" FormName="ContactForm">
<DataAnnotationsValidator EnableClientValidation="true" />
<fieldset disabled="@submitted">
<div class="form-group">
<label for="name">Name</label>
<InputText id="name" class="form-control" @bind-Value="contact!.Name" />
<ValidationMessage For="() => contact!.Name" />
</div>
<div class="form-group">
<label for="email">E-Mail</label>
<InputText id="email" class="form-control" @bind-Value="contact!.Email" />
<ValidationMessage For="() => contact!.Email" />
</div>
<div class="form-group">
<label for="message">Nachricht</label>
<InputTextArea id="message" class="form-control" @bind-Value="contact!.Message" rows="4" />
<ValidationMessage For="() => contact!.Message" />
</div>
<button type="submit" class="btn btn-primary mt-2">Absenden</button>
</fieldset>
</EditForm>
@if (submitted)
{
<div class="alert alert-success mt-3">
<h3>Vielen Dank, @contact!.Name)</h3>
<p>Ihre Nachricht wurde erfolgreich empfangen.</p>
</div>
}
</div>
@code {
[SupplyParameterFromForm]
private ContactModel? contact { get; set; }
private bool submitted;
protected override void OnInitialized() => contact ??= new();
private void HandleSubmit() => submitted = true;
}Listing: Blazor-Seite mit Eingabeformular
Die folgende Abbildung zeigt die laufende Blazor-Seite im Webbrowser. Die Eingabefelder haben Zusatzattribute wie data-val-required und data-val-email, über die die clientseitige Validierung aktiviert wird.
Entwicklerinnen und Entwickler können die clientseitige Validierung ausschalten:
<DataAnnotationsValidator EnableClientValidation="false" />Für die Lokalisierung von Validierungsfehlermeldungen musste man in Blazor bisher in jeder Property in der Annotation [Display] die Eigenschaften Name und ResourceType sowie in den Validierungsannotationen ErrorMessage und ErrorMessageResourceType setzen, zum Beispiel:
[Required(ErrorMessage = nameof(Resources.ValidationMessages.RequiredError), ErrorMessageResourceType = typeof(Resources.ValidationMessages))]
[EmailAddress(ErrorMessage = nameof(Resources.ValidationMessages.EmailError))]
[Display(Name = nameof(Resources.ValidationMessages.ContactEmail))]
public string? Email { get; set; }In Blazor 11.0 lässt sich der Ressourcentyp nun zentral im Startcode festlegen, durch Aufruf der neuen Methode AddValidationLocalization() nach AddValidation():
builder.Services.AddValidation();
builder.Services.AddValidationLocalization<Resources.ValidationMessages>();Die Annotationen im Objektmodell lassen sich dann vereinfachen:
[Required(ErrorMessage = "{0} ist erforderlich.")]
[EmailAddress(ErrorMessage = "{0} ist ungültig.")]
[Display(Name = "E-Mail")]
public string? Email { get; set; }Das nächste Listing zeigt eine Klasse nun mit Annotationen für Bezeichnungsfelder und Validierungsmeldungen, die keinen Text enthalten, sondern auf eine Ressource verweisen.
[ValidatableType]
public class ContactModelLocalized
{
[Required(ErrorMessage = nameof(Resources.ValidationMessages.RequiredError))]
[StringLength(100, MinimumLength = 2, ErrorMessage = nameof(Resources.ValidationMessages.StringLengthError))]
[Display(Name = nameof(Resources.ValidationMessages.ContactName))]
public string? Name { get; set; }
[Required(ErrorMessage = nameof(Resources.ValidationMessages.RequiredError))]
[EmailAddress(ErrorMessage = nameof(Resources.ValidationMessages.EmailError))]
[Display(Name = nameof(Resources.ValidationMessages.ContactEmail))]
public string? Email { get; set; }
[Required(ErrorMessage = nameof(Resources.ValidationMessages.RequiredError))]
[StringLength(500, MinimumLength = 10, ErrorMessage = nameof(Resources.ValidationMessages.StringLengthError))]
[Display(Name = nameof(Resources.ValidationMessages.ContactMessage))]
public string? Message { get; set; }
}Listing: Modellklasse für die Validierung mit Lokalisierung
@page "/SSRClientValidationMultiLang"
@using Models
@using Microsoft.Extensions.Localization
@inject IStringLocalizer<Resources.ValidationMessages> L
<PageTitle>@L["ContactTitle"]</PageTitle>
<h1>@L["ContactTitle"]</h1>
<p>@L["ContactSubtitle"]</p>
<CultureSwitcher />
<div class="form-card">
<EditForm Model="contact" Enhance OnValidSubmit="HandleSubmit" FormName="ContactForm">
<DataAnnotationsValidator EnableClientValidation="true" />
<fieldset disabled="@submitted">
<div class="form-group">
<label for="name">@L["LabelName"]</label>
<InputText id="name" class="form-control" @bind-Value="contact!.Name" />
<ValidationMessage For="() => contact!.Name" />
</div>
<div class="form-group">
<label for="email">@L["LabelEmail"]</label>
<InputText id="email" class="form-control" @bind-Value="contact!.Email" />
<ValidationMessage For="() => contact!.Email" />
</div>
<div class="form-group">
<label for="message">@L["LabelMessage"]</label>
<InputTextArea id="message" class="form-control" @bind-Value="contact!.Message" rows="4" />
<ValidationMessage For="() => contact!.Message" />
</div>
<button type="submit" class="btn btn-primary">@L["ContactSubmitButton"]</button>
</fieldset>
</EditForm>
@if (submitted)
{
<div class="alert alert-success mt-3">
<h3>@string.Format(L["ContactSuccessTitle"].Value, contact!.Name)</h3>
<p>@L["ContactSuccessMessage"]</p>
</div>
}
</div>
@code {
[SupplyParameterFromForm]
private ContactModelLocalized? contact { get; set; }
private bool submitted;
protected override void OnInitialized() => contact ??= new();
private void HandleSubmit() => submitted = true;
}Listing: Mehrsprachiges Eingabeformular mit Validierung
Im Startcode der Anwendung braucht man dann folgende Teile:
Zum einen vor builder.Build():
#region Validation + Localization (.NET 11.0 Preview 5)
builder.Services.AddLocalization();
builder.Services.AddValidation();
builder.Services.AddValidationLocalization<Resources.ValidationMessages>();
builder.Services.Configure<RequestLocalizationOptions>(options =>
{
var supportedCultures = new[] { new CultureInfo("en-US"), new CultureInfo("de-DE"), new CultureInfo("es-ES") };
options.DefaultRequestCulture = new RequestCulture("en-US");
options.SupportedCultures = supportedCultures;
options.SupportedUICultures = supportedCultures;
options.RequestCultureProviders.Insert(0, new CookieRequestCultureProvider());
});
#endregionZum Zweiten vor app.MapStaticAssets();:
#region Validation + Localization (.NET 11.0 Preview 5)
app.UseRequestLocalization();
// Kulturumschalter für die Validierungsdemos.
// Schreibt das Cookie, das der oben konfigurierte CookieRequestCultureProvider
// bei nachfolgenden Anfragen ausliest.
// Beispiel: https://localhost:7119/Culture/Set?culture=de-DE&redirectUri=%2FValidationDemo
app.MapGet("/Culture/Set", (HttpContext context, string culture, string redirectUri) =>
{
context.Response.Cookies.Append(
CookieRequestCultureProvider.DefaultCookieName,
CookieRequestCultureProvider.MakeCookieValue(new RequestCulture(culture)),
new CookieOptions { Expires = DateTimeOffset.UtcNow.AddYears(1) });
return Results.LocalRedirect(redirectUri);
});
#endregion
Die in .NET 11.0 Preview 5 eingebaute vereinfachte Lokalisierung soll auch in Minimal WebAPIs funktionieren. Dies wurde im Schnelltest aber noch nicht geprüft und es gibt dazu in den Release Notes [8] auch kein Beispiel.
Blazor 11.0 unterstützt ab Preview 5 auch erstmals die asynchrone Validierung von Benutzereingaben. Bisher konnte man bereits Benutzereingaben gegen „langsame“ Ressourcen wie eine Datenbank oder einen Backend-Service prüfen, dies aber immer nur mit synchronen Aufrufen. Dazu gibt es nun neu in .NET 11.0 in der Klasse EditContext diese fünf Methoden:
OnValidationRequestedAsync()AddValidationTask()ValidateAsync()IsValidationPending()IsValidationFaulted()Der Ablauf ist allerdings leider sehr komplex. Daher kann aus Platzgründen hier kein Beispiel geliefert werden. Weitere Informationen und einige Ablaufdiagramme findet man auf GitHub [9]. Das Dokument „What’s new in ASP.NET Core in .NET 11 [10]“ hat Microsoft bis zum Erscheinen dieses Beitrags nicht mit einer Beschreibung des Features aktualisiert.
Eigenständige Blazor-WebAssembly-Anwendungen müssen nicht auf einem ASP.NET-Core-basierten Webserver gehostet werden, sondern können von einem einfachen Webserver ausgeliefert werden, der statische Dateien senden kann. Zur Entwicklungszeit lieferte Microsoft bisher das NuGet-Paket Microsoft.AspNetCore.Components.WebAssembly.DevServer. Ab .NET 11.0 Preview 5 tritt an diese Stelle nun das neue NuGet-Paket Microsoft.AspNetCore.Components.Gateway. Der neue Server ist dann doch ein vollständiger ASP.NET Core Host, mit dem Vorteil, dass ein Fallback für nicht gefundene Ressourcen auf /index.html erfolgt. Zudem verbessert dies das Monitoring in Aspire [11].
Für den Umstieg bestehender Projekte ersetzt man in der Projektdatei (.csproj) die Zeile
<PackageReference
Include="Microsoft.AspNetCore.Components.WebAssembly.DevServer"
Version="11.0.0-preview.5.26302.115"
PrivateAssets="all" />durch
<PackageReference
Include="Microsoft.AspNetCore.Components.Gateway"
Version="11.0.0-preview.5.26302.115"
PrivateAssets="all" />Zudem ergänzt man
<PropertyGroup>
<StaticWebAssetSpaFallbackEnabled>true</StaticWebAssetSpaFallbackEnabled>
</PropertyGroup>In neu angelegten Projekten des Typs „Blazor WebAssembly Standalone“ (dotnet new blazorwasm -o AppName) ist diese Einstellung schon vorgegeben.
Klassen (einschließlich Record-Klassen, aber keine Structs) lassen sich in C# 15.0 seit .NET 11.0 Preview 5 mit dem Schlüsselwort closed versehen. Das verhindert, dass in einer anderen Assembly eine Vererbung von der so deklarierten Klasse möglich ist. In der eigenen Assembly ist Vererbung aber möglich. Geschlossene Klassen sind automatisch auch abstract, das heißt, man kann keine Instanzen von ihnen erzeugen. Abgeleitete Klassen von geschlossenen Klassen sind nicht automatisch auch geschlossen. Details finden sich auf GitHub [12].
public closed record class Universitatsmitglied();
public record class Mitarbeiter() : Universitatsmitglied();
public record class Student(string Name) : Universitatsmitglied();
public record class Lehrkraft(string Name, string Titel) : Mitarbeiter();Listing: Bibliotheksprojekt mit vier Record-Klassen, wobei eine Klasse geschlossen ist
// 'Verwaltungsmitarbeiter': cannot use a closed type 'Universitatsmitglied' from another assembly as a base type.
// public record class Verwaltungsmitarbeiter(string Name) : Universitatsmitglied(Name);
public record class Professor(string Name, string Titel) : Lehrkraft(Name, Titel);
public record class ExStudent(string Name) : Student(Name);
internal class CS15_ClosedClass
{
// geschlossene Klasse ist automatisch abstract: Keine Instanzen möglich
// Universitatsmitglied p = new();
public void Run()
{
CUI.Demo(nameof(CS15_ClosedClass));
Universitatsmitglied s = new Student("Max Musterschüler");
Universitatsmitglied p = new Lehrkraft("Dr. Schmidt", "Professor");
CUI.Print(GetText(s));
CUI.Print(GetText(p));
}
static string GetText(Universitatsmitglied p) => p switch
{
Student => $"Student {(p as Student).Name}",
Lehrkraft => $"{(p as Lehrkraft).Titel} {(p as Lehrkraft).Name}"
};
}Listing: Client-Projekt, das die Typen aus dem Bibliotheksprojekt nutzt. Die geschlossene Klasse „Universitatsmitglied“ kann nicht direkt verwendet werden.
In .NET 11.0 Preview 5 gibt es zwei Voraussetzungen für dieses neue Sprachfeature: Zum einen muss in der Projektdatei Folgendes enthalten sein:
<LangVersion>preview</LangVersion>Zum anderen muss dieser Programmcode in dem Projekt vorhanden sein, das das neue Schlüsselwort closed verwendet. Erfahrungsgemäß wird in der kommenden Preview-Version die .NET-Klassenbibliothek diesen Programmcode bereits enthalten:
namespace System.Runtime.CompilerServices;
[AttributeUsage(AttributeTargets.Class, AllowMultiple = false, Inherited = false)]
public sealed class ClosedAttribute : Attribute { }Den direkten Start eigenständiger C#-Dateien ohne Projektdatei hatte Microsoft in .NET 10.0 unter dem Namen File-based Apps [13] eingeführt. Seit .NET 11.0 Preview 3 [14] können Entwicklerinnen und Entwickler andere C#-Dateien per #include einbinden:
#:include ./Hilfsroutinen.csDas geht aber nur, wenn diese andere C#-Datei nur Typen enthält, selbst aber keinen Startcode besitzt, sonst kommt es zum Fehler „error CS8802: Only one compilation unit can have top-level statements“. Nun ab Preview 5 kann eine File-based App eine andere File-based App mit #:ref referenzieren:
#:ref ./AndereApp.csDer Startcode in AndereApp.cs wird dann nicht ausgeführt, aber die referenzierende App kann darin enthaltene Typen wie eine Bibliothek nutzen. Voraussetzung ist aktuell diese zusätzliche Zeile in der referenzierenden File-based App:
#:property ExperimentalFileBasedProgramEnableRefDirective=trueLaut Release Notes [15] sollen .NET-SDK-CLI-Befehle wie dotnet package nun auch mit File-based Apps funktionieren. Im Schnelltest funktionierte das mit der gestern ausgelieferten Preview-5-Version nicht:
.NET-Entwicklerinnen und -Entwickler können nun in der Projektdatei aktivieren, dass sie Warnungen erhalten, falls sie eine SDK-Version verwenden, die bekannte Sicherheitslücken besitzt oder nicht mehr im Support von Microsoft ist:
<PropertyGroup>
<CheckSdkVulnerabilities>true</CheckSdkVulnerabilities>
</PropertyGroup>Die Einstellung ProcessStartInfo.KillOnParentExit, die in .NET 11.0 Preview 4 eingeführt wurde [16], funktioniert nun nicht nur auf Windows, sondern auch Linux und Android.
Die Process-Klasse hat in Preview 5 zudem eine neue Methode ReadAllLines(TimeSpan? timeout = default) erhalten, die auf synchrone Weise die Zeilen aus stdout und stderr liefert, in Form einer Liste von Objekten des Typs ProcessOutputLine mit lediglich zwei Eigenschaften StandardError (Bool) und Content (String):
var startInfo = new ProcessStartInfo("ping.exe")
{
RedirectStandardOutput = true,
RedirectStandardError = true,
};
startInfo.ArgumentList.Add("www.IT-Visions.de");
using Process process = Process.Start(startInfo)!;
foreach (ProcessOutputLine line in process.ReadAllLines())
{
if (line.StandardError) CUI.Error(line.Content);
else CUI.Print(line.Content);
}.NET kann seit Version 1.0 Zufallszahlen erzeugen. In Ergänzung zu den bestehenden Methoden Next(), NextInt64(), NextSingle() und NextDouble()
// bisherige Lösung
int alt1 = random.Next(1, 42); // 1 bis 41
long alt2 = random.NextInt64(); // >= 0.0 und < 1.0
Single alt3 = random.NextSingle(); // >= 0.0 und < 1.0
Double alt4 = random.NextDouble(); // >= 0.0 und < 1.0liefert Microsoft in .NET 11.0 mit NextInteger() und NextBinaryFloat() nun auch Varianten mit generischen Typparametern, um in einigen Situationen Fallunterscheidungen im Programmcode zu vermeiden:
// Neu in .NET 11.0
long longValue = random.NextInteger<long>(); // beliebiger Int64-Wert
int intValue = random.NextInteger<int>(1, 42); // 1 bis 41
int byteValue = random.NextInteger<byte>(3); // 0 bis 2
Half halfValue = random.NextBinaryFloat<Half>(); // >= 0.0 und < 1.0
Double doubleValue = random.NextBinaryFloat<Double>(); // >= 0.0 und < 1.0In .NET 10.0 [17] ergänzte Microsoft die LINQ-Operatoren LeftJoin() und RightJoin(). Nun in .NET 11.0 gibt es auch FullJoin(), um alle Elemente aus beiden Mengen zu erhalten, unabhängig davon, ob eine Übereinstimmung in der anderen Menge gefunden wurde oder nicht. Bisher musste man LeftJoin() und RightJoin() manuell kombinieren bzw. vor .NET 10.0 mit GroupJoin() und SelectMany() nachbilden.
CUI.H2("--- ALLE Firmen und ALLE Websites, auch wenn es kein Pendant gibt: neue Lösung mit FullJoin() ab .NET 11.0 ---");
IEnumerable<CompaniesAndWebsites> AllCompaniesWithWebsitesSet = companies.FullJoin(websites,
c => c.ID,
w => w.CompanyID,
(c, w) => new CompaniesAndWebsites { Name = c.Name, City = c.City, URL = w.URL }
);
foreach (var item in AllCompaniesWithWebsitesSet)
{
Console.WriteLine((item.Name != null ? item.Name + " " + item.City : "- keine Firma -").Trim() + " -> " + (item.URL ?? "- keine URL -"));
}Ein Schnelltest ergab, dass der neue FullJoin()-Operator in Preview 5 noch nicht bei Datenbankzugriffen mit Entity Framework Core funktioniert, das heißt, es ist keine Übersetzung von LINQ in SQL möglich. Es kommt die in diesem Fall übliche Fehlermeldung „could not be translated“.
Der JSON-Serialisierer System.Text.Json kann seit Version 10.0 JSON-Daten im Format JSON Lines [18] auslesen:
string FILENAME = "messwerte.jsonl";
await using var stream = new FileStream(FILENAME, FileMode.Open, FileAccess.Read);
var messwerte = JsonSerializer.DeserializeAsyncEnumerable<Messwert>(stream, topLevelValues: true);
await foreach (var messwert in messwerte)
{
Console.WriteLine(messwert);
}Nun in Version 11.0 können Entwicklerinnen und Entwickler das JSON-Lines-Format auch erzeugen, aus einem Stream:
await using var stream = new FileStream(FILENAME, FileMode.Create, FileAccess.Write);
await JsonSerializer.SerializeAsyncEnumerable(
stream,
GetMesswerte(),
topLevelValues: true);
stream.Close();Der objektrelationale Mapper Entity Framework Core geht nun beim Zugriff auf einen Microsoft SQL Server im Standard davon aus, dass es sich um die Server-Version 2022 (Compatibility Level 160) handelt. Zuvor war die Annahme immer Version 2019 (Compatibility Level 150). Für andere Versionen müssen Entwicklerinnen und Entwickler das Kompatibilitätslevel manuell in der Methode OnConfiguring() der Kontextklasse setzen, zum Beispiel für Version 2019:
optionsBuilder.UseSqlServer(
connectionString,
sqlServerOptions => sqlServerOptions.UseCompatibilityLevel(150));Das Kommandozeilenwerkzeug dotnet ef bietet nun die Parameter --file und --startup-file, um auch mit File-based Apps umgehen zu können, zum Beispiel:
dotnet ef dbcontext scaffold \
"Data Source=app.db" \
Microsoft.EntityFrameworkCore.Sqlite \
--file .\Model.cs \
--startup-file .\App.csDie LINQ-Operation Any() lässt sich nun auf Byte-Arrays anwenden:
public partial class Person
{
…
public byte[]? Photo { get; set; }
}
…
var ctx = new DA.WWWings.WwwingsV1EnContext();
var personenMitFoto = ctx.People
.Where(e => e.Photo.Any())
.ToList();SQL Server übersetzt dies zu:
DATALENGTH([p].[Photo]) > 0SQLite übersetzt dies zu:
length("p"."Photo") > 0In .NET MAUI [19] gibt es zahlreiche Fehlerbeseitigungen in den Steuerelementen, bei Layout und Navigation.
Die Unterstützung von Screenreadern in .NET MAUI verbessert sich durch BackButtonAccessibilityLabel bei <ContentPage NavigationPage> und BackButtonBehavior bei <Shell.BackButtonBehavior>:
<!-- Shell -->
<Shell.BackButtonBehavior>
<BackButtonBehavior AccessibilityLabel="Zurück" />
</Shell.BackButtonBehavior>
<!-- NavigationPage (wird auf der übergeordneten Seite festgelegt; wird auf die Zurück-Schaltfläche der untergeordneten Seite angewendet)
<ContentPage NavigationPage.BackButtonAccessibilityLabel="Zurück" />.NET MAUI erfordert nun bei Android als Mindestversion das API-Level 24 (Android 7.0).
.NET 11.0 soll im November 2026 erscheinen und einen Standard-Term Support von zwei Jahren erhalten. Bis dahin können Entwicklerinnen und Entwickler mit zwei weiteren Preview-Versionen (im Juli und August) sowie zwei Release-Candidate-Versionen (im September und Oktober) rechnen. heise developer wird jeweils berichten.
URL dieses Artikels:
https://www.heise.de/-11327634
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: OpenProject)
Projektbezogene IDs statt globaler Nummern: OpenProject 17.5 erleichtert den Umstieg von Jira und baut die Backlog-Verwaltung für agile Teams aus.
Mit OpenProject 17.5 können Anwender erstmals zwischen zwei Arten von Kennungen für ihre Arbeitspakete wählen: einer fortlaufenden Nummerierung über die gesamte Installation oder projektbezogenen Kennungen. Vor allem große Organisationen und Teams, die von Atlassian Jira umsteigen, sollen davon profitieren. Daneben erweitert die Version die Möglichkeiten zur Anpassung agiler Backlogs und bringt kleinere Verbesserungen für Dokumentation und Besprechungsplanung.
OpenProject ist eine quelloffene Anwendung für Projektmanagement und Zusammenarbeit. Die Software unterstützt klassische und agile Projektmethoden und bietet unter anderem Aufgaben- und Ressourcenverwaltung, Gantt-Diagramme, Scrum-Backlogs sowie Funktionen für Dokumentation und Team-Arbeit. Sie läuft wahlweise als Cloud-Dienst oder im Eigenbetrieb.
Die wichtigste Neuerung von OpenProject 17.5 sind projektspezifische Arbeitspaket-Kennungen, die zunächst als Beta vorliegen. Bislang vergab OpenProject die IDs ausschließlich über eine globale Nummernfolge für die gesamte Installation. Ein Arbeitspaket erhielt etwa die Kennung „#2385“ – unabhängig davon, zu welchem Projekt es gehörte.
Künftig können Administratoren stattdessen projektbezogene Kennungen aktivieren. Diese ergänzen die ID um ein Projektkürzel und orientieren sich damit an einem Schema, das viele Anwender bereits von Jira kennen. Aus einer generischen Nummer wird so eine Kennung wie „ERP-2385“ oder „APP-4711“. Zu welchem Projekt ein Arbeitspaket gehört, lässt sich auf diese Weise sofort erkennen – das erleichtert die Orientierung in Umgebungen mit vielen Projekten.
Nach Angaben des Herstellers funktionieren bestehende numerische IDs und Verweise auch nach einer Umstellung weiter. Alte Links, Lesezeichen und Referenzen sollen weiterhin auf die jeweiligen Arbeitspakete zeigen. Die Wahl zwischen numerischen und projektspezifischen Kennungen gilt allerdings für die gesamte Installation und damit für alle Projekte.
Ein wesentlicher Grund für die neuen Kennungen sind Migrationen von Jira. Unternehmen können ihre bisherigen Jira-Issue-Keys beibehalten, wenn sie ihre Projekte nach OpenProject übertragen. So lassen sich etablierte Namenskonventionen und Referenzen in Dokumentationen, Integrationen oder Automatisierungen weiternutzen. Der Jira-Migrator übernimmt jetzt zusätzlich Fälligkeitstermine sowie geschätzte und verbleibende Arbeitsstunden.
Auch die agilen Planungsfunktionen hat OpenProject ausgebaut. Administratoren können nun einzelne Arbeitspakettypen gezielt aus Backlogs ausschließen. So sehen Teams bei der Sprint-Planung nur die Aufgaben, die für sie tatsächlich relevant sind.
Zudem hat OpenProject die Sprint- und Kartenansichten überarbeitet. Informationen wie übergeordnete Arbeitspakete, Prioritäten, Story Points, Zuständigkeiten und der Sprint-Status lassen sich dadurch schneller erfassen.
Weitere Änderungen betreffen die Dokumentation und Besprechungsplanung. Verweise auf Arbeitspakete lassen sich nun direkt in den Fließtext einbetten. In Eingabefeldern auf Basis des CKEditor reichert OpenProject solche Verweise schon während der Eingabe mit Zusatzinformationen an.
Wiederkehrende Besprechungen unterstützen außerdem neue monatliche Muster wie den ersten Montag oder den letzten Freitag eines Monats. Ändert sich ein Termin, fasst das System mehrere Änderungen in einer Benachrichtigung zusammen und reduziert so die Zahl der E-Mails.
Die Cloud-Anwendungen von OpenProject erhalten das Update seit dem 10. Juni 2026 automatisch; für selbst betriebene Instanzen stehen Anleitungen für Paket- und Docker-Installationen bereit. Alle Details listet OpenProject in den Release Notes zu Version 17.5 [1] auf.
Siehe auch:
URL dieses Artikels:
https://www.heise.de/-11327652
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: GitHub)
Mit npm v12 schließt GitHub einen zentralen Angriffsweg: Installationsskripte aus Abhängigkeiten laufen ab Juli 2026 nur noch nach ausdrücklicher Freigabe.
Mit npm v12 schafft GitHub mehrere sicherheitskritische Standardeinstellungen des Node.js-Paketmanagers ab. Die für Juli 2026 angekündigte Hauptversion führt Installationsskripte aus Abhängigkeiten künftig nicht mehr automatisch aus. Auch Git- und Remote-Abhängigkeiten installiert npm nur noch, wenn Entwickler sie ausdrücklich freigeben. Damit will GitHub einen der wichtigsten Angriffswege in der Software-Lieferkette schließen: die automatische Codeausführung während eines npm install.
npm ist der Standard-Paketmanager des Node.js-Ökosystems und gehört zu den meistgenutzten Paketverwaltungen überhaupt. Moderne Anwendungen ziehen oft Hunderte oder Tausende direkte und indirekte Abhängigkeiten nach. Entsprechend groß ist die Angriffsfläche. Seit Jahren warnen Sicherheitsforscher vor Angriffen auf die Lieferkette [1], bei denen Schadcode über übernommene Pakete, gestohlene Maintainer-Konten oder manipulierte Installationsskripte in Entwicklungsumgebungen gelangt. Besonders gefährlich sind Mechanismen, die schon beim Installieren eines Pakets Code ausführen [2] – oft, bevor Entwickler die Anwendung überhaupt gestartet haben.
Genau hier setzt die wichtigste Neuerung von npm v12 an. Künftig führt der Paketmanager Installationsskripte aus Abhängigkeiten standardmäßig nicht mehr aus. Das betrifft die Lifecycle-Skripte preinstall, install und postinstall. Auch native Erweiterungen, die npm bislang automatisch über node-gyp kompiliert, baut der Paketmanager nicht mehr ohne Freigabe. Dasselbe gilt für bestimmte prepare-Skripte aus Git-, Datei- oder verlinkten Abhängigkeiten.
Bislang genügt ein einfaches npm install, um solche Skripte automatisch auszuführen. Viele Pakete nutzen den Mechanismus für legitime Zwecke, etwa um zusätzliche Binärdateien herunterzuladen oder native Komponenten zu kompilieren. Dieselbe Funktion gilt aber seit Jahren als attraktiver Angriffsweg: Über ein manipuliertes Installationsskript lässt sich Schadcode bereits während der Installation ausführen. Der Code kann zum Beispiel Umgebungsvariablen auslesen, Zugangsdaten abgreifen oder weitere Schadsoftware nachladen.
An die Stelle des automatischen Ausführens tritt ein Modell mit Freigabeliste. Entwickler bestimmen künftig selbst, welche Pakete ihre Installationsskripte ausführen dürfen. Diese Freigaben hinterlegt npm im Projekt, sodass Teams sie zusammen mit dem Quellcode versionieren können.
Wer früh umstellen will, kann das bereits tun: Schon npm 11.16.0 warnt vor Skripten, die der Paketmanager künftig blockiert. Mit dem Befehl npm approve-scripts --allow-scripts-pending lässt sich prüfen, welche Abhängigkeiten betroffen wären; mit npm approve-scripts lassen sich die vertrauenswürdigen Pakete anschließend freigeben.
Auch beim Umgang mit Git-Abhängigkeiten zieht npm die Zügel an. Pakete, die direkt aus einem Git-Repository stammen, blockiert der Paketmanager künftig standardmäßig; Entwickler müssen solche Quellen ausdrücklich erlauben. GitHub begründet den Schritt mit einem Angriffsweg, über den sich aus einer Git-Abhängigkeit heraus Code ausführen ließ – selbst dann, wenn Installationsskripte eigentlich unterdrückt waren. Hinzu kommt, dass sich Git-Abhängigkeiten generell schwerer kontrollieren lassen als Pakete aus dem regulären npm-Registry.
Eine ähnliche Hürde gilt künftig für Remote-Abhängigkeiten, also Pakete, die direkt von einer URL stammen, etwa als TAR-Archiv per HTTPS. Auch sie installiert npm nur noch nach ausdrücklicher Freigabe. Solche Abhängigkeiten umgehen die übliche Registry-Infrastruktur und erschweren es, ihre Herkunft nachzuvollziehen. GitHub will so verhindern, dass externe Quellen unbemerkt in die Abhängigkeitskette geraten.
Mehr Sicherheit bedeutet für Entwickler und Unternehmen zunächst mehr Aufwand. Wer bislang auf Installationsskripte, Git-Abhängigkeiten oder externe Paketquellen setzt, muss seine Build- und CI/CD-Prozesse prüfen und die nötigen Komponenten freigeben. GitHub rät, schon jetzt auf npm 11.16.0 oder neuer zu wechseln und die ausgegebenen Warnungen auszuwerten.
Alle Probleme der JavaScript-Lieferkette löst npm v12 allerdings nicht. Schadcode, der direkt im Anwendungscode eines Pakets steckt [3], gelangt weiterhin auf die Systeme. Auch kompromittierte Maintainer-Konten, Typosquatting oder verwundbare Bibliotheken fängt der neue Ansatz nicht ab. Für die Sicherheit von Entwicklungs- und Build-Umgebungen dürfte er dennoch eine der weitreichendsten Änderungen der vergangenen Jahre sein.
Weitere Details nennt GitHub im Changelog-Eintrag zu den anstehenden Breaking Changes für npm v12 [4].
URL dieses Artikels:
https://www.heise.de/-11327518
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: metamorworks / Shutterstock.com)
Auf der DASH-Konferenz präsentiert Datadog mit Bits AI SRE, AI Guard und Bring Your Own Cloud neue Funktionen für autonomen IT-Betrieb und KI-Sicherheit.
Datadog hat auf seiner jährlichen Hauskonferenz DASH zahlreiche neue Funktionen für seine Observability- und Sicherheitsplattform angekündigt. Im Zentrum stehen der KI-Agent Bits AI SRE, das Tool AI Guard zum Schutz von KI-Anwendungen sowie ein neues Bereitstellungsmodell namens Bring Your Own Cloud Logs (BYOC Logs), bei dem Kunden ihre Log-Daten in eigenen Speichersystemen belassen können.
Wie Datadog in seiner DASH-2026-Ankündigung [1] erklärt, sollen die Neuerungen Unternehmen helfen, die immer schneller verlaufende Softwareentwicklung sowie die wachsende Komplexität KI-geprägter IT-Landschaften besser zu beherrschen. Chief Product Officer Yanbing Li zufolge sei es das erklärte Ziel, dass Unternehmen nicht nur bessere Modelle bauen, sondern „operative Kontrolle rund um diese Systeme“ schaffen.
Datadogs bereits im vergangenen Jahr angekündigter KI-Agent Bits AI SRE [4] soll weit über die Möglichkeiten klassischer AIOps-Ansätze hinauswirken. Er soll sich damit von konkurrierenden Angeboten etwa von Dynatrace, Splunk oder Elastic abheben, die noch vorwiegend auf regelbasierte Korrelations-Engines und Mustererkennungen über Alerts bauen. Bits AI arbeite wie ein „agentischer Teamkollege“, der sich kontinuierlich den Kontext der gesamten Datadog-Telemetrie zunutze mache. Das System bildet eigenständig mehrere Root-Cause-Hypothesen, testet diese über gezielte Abfragen und klassifiziert sie als validiert, invalidiert oder unklar. Dabei greift der Agent auf Metriken, Logs, Traces, Topologiedaten und verknüpfte Runbooks zurück – etwa aus Confluence – und führt explorative Queries über die gesamte Umgebung aus. Laut Datadog beschleunige Bits AI SRE die Root-Cause-Identifikation nicht nur signifikant, sondern ermögliche tatsächlich autonome Betriebsabläufe.
Den KI-Agenten positioniert Datadog als modellagnostische Orchestrierungsschicht über große Sprachmodelle. Welche Foundation-Modelle konkret zum Einsatz kommen, verrät der Hersteller jedoch nicht. Da in anderen Produktbereichen allerdings Integrationen mit OpenAI sowie Anbindungen an Entwicklertools wie Claude Code von Anthropic existieren, liegen Kooperationen mit OpenAI und Anthropic nahe.
Vollständig automatisierte Behebungsmaßnahmen ohne menschliche Freigabe sind mit dem neuen Bits Agent Builder möglich: Teams können eigene KI-Agenten erstellen, die Remediation-Workflows wie Rollbacks, Neustarts oder Feature-Flag-Rollouts automatisieren. Datadog betont dabei, dass sämtliche Aktionen nur innerhalb kundenseitig definierter Leitplanken erfolgen – etwa per RBAC, Policy-Engines, Audit-Logging und verpflichtender Genehmigung durch On-Call-Personal. In sicherheitskritischen Umgebungen, etwa im Finanzsektor, empfiehlt Datadog einen Assistenzmodus, in dem Bits AI SRE zwar vorschlägt und dokumentiert, die finale Entscheidung aber beim Menschen verbleibt.
Für die Integration in bestehende ITIL- oder ISO-27001-konforme Prozesse, wie sie in größeren Unternehmen in der DACH-Region üblich sind, bietet Datadog Anbindungen an ServiceNow und Jira. Bits AI SRE fungiert dabei als erste Ermittlungsinstanz: Er nimmt Alerts auf, legt Cases an und erstellt strukturierte Incident-Reports mit Root Cause, Impact und Timeline. Formale Change-Management-Prozesse und Dokumentationspflichten bleiben allerdings beim Kunden – der KI-Agent versteht sich als Ergänzung, nicht als Ersatz für bestehende Governance-Strukturen.
Mit AI Guard [5] reagiert Datadog auf die wachsenden Risiken rund um KI-Agenten, darunter versteckte, bösartige Prompt-Attacken, die Agenten zur Preisgabe sensibler Informationen veranlassen können. AI Guard kombiniert Telemetry Tracing mit zustandsbehafteter Verhaltensanalyse, um mehrstufige Angriffe und Prompt-Injection-Versuche über mehrere Interaktionen hinweg zu erkennen und zu blockieren – Angriffsmuster also, die bei zustandslosen Prompt-Response-Prüfungen unentdeckt blieben.
Die Policies lassen sich sprachunabhängig formulieren, etwa über Regex-Muster oder Klassifikatoren, die IBANs, E-Mail-Adressen oder Kundennummern unabhängig von der Sprache des Prompts erkennen. Insbesondere in mehrsprachigen Unternehmensumgebungen, in denen etwa deutschsprachige Benutzertexte und englische Systemlogs in gemischten Prompts aufeinandertreffen, hängt die Erkennungsqualität Datadog zufolge letztlich vom eingesetzten Sprachmodell ab. AI Guard gilt laut Ankündigung als LLM-agnostisch, die Integration erfolgt über SDKs [6] für Python, JavaScript und Java.
Mit Bring Your Own Cloud Logs (BYOC) [7] widmet sich Datadog dem Problem der exponentiell wachsenden Log-Datenmengen durch KI-Workloads. In diesem Modell wird die Plattform in der Cloud-Umgebung des Kunden betrieben, Daten werden direkt im unternehmenseigenen Objektspeicher verarbeitet und indexiert, ohne sie in eine Datadog-zentrische Umgebung verschieben zu müssen. Sofern der gewählte Cloud-Provider es unterstützt, können DACH-Unternehmen ihre Observability-Daten damit potenziell ausschließlich in EU-Rechenzentren oder der seit 2018 bestehenden EU-Region in Deutschland halten. DSGVO-relevante Aspekte wie Auftragsverarbeitung und der Zugriff durch US-Anbieter bleiben zwar grundsätzlich bestehen, die Datenlokalisierung und BYOC weisen aber technisch den Weg zu mehr Souveränität.
Unter den weiteren Ankündigungen im Rahmen der DASH-Konferenz [8] finden sich eine Agent Console, die zentrales Monitoring für KI-Agenten bietet und Entwicklertools wie Claude Code, Cursor und GitHub Copilot unterstützt. Das Modul Bits Detection erkennt eigenständig Anomalien und löst automatisch Untersuchungen aus, während Agent Evals dem Debuggen von KI-Agenten dient – einschließlich der von Kunden selbst erstellten.
URL dieses Artikels:
https://www.heise.de/-11326423
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Manuel Masiero / KI / iX)
Der Diskurs dreht sich fast nur um größere neuronale Modelle. Ist Skalieren wirklich der einzige Weg, oder lohnt der Blick zurück?
Wenn heute über künstliche Intelligenz [1] gesprochen wird, dann fast ausschließlich über große Sprachmodelle. Und damit, ohne dass es immer ausgesprochen wird, über eine ganz bestimmte Spielart von KI: über neuronale Netze, über statistisches Lernen aus gewaltigen Datenmengen. Das implizite Versprechen lautet, dass der Weg nach vorn vor allem eine Frage der Menge ist. Mehr Parameter, mehr Daten, mehr Rechenleistung, mehr Energie und ein wenig Geduld. Dann kommt der Rest von selbst.
Ich möchte diese Annahme in Frage stellen. Nicht, weil ich die Erfolge der vergangenen Jahre kleinreden will, sie sind real und beeindruckend. Sondern weil mich ein Verdacht nicht loslässt: Vielleicht sitzen wir in einem lokalen Maximum und halten es für den Gipfel. Und vielleicht hilft ein Blick zurück, um zu sehen, dass dieser Gipfel nicht der Einzige ist. Denn das Pendel der KI-Forschung stand schon einmal ganz woanders.
Es lohnt sich, kurz daran zu erinnern, dass die heute dominante, datengetriebene KI keineswegs alternativlos ist. Über Jahrzehnte hinweg war das beherrschende Paradigma ein völlig anderes: die symbolische KI. Sie ging davon aus, dass Intelligenz im Kern aus der Manipulation von Symbolen nach expliziten Regeln besteht, dass Denken also etwas ist, das man hinschreiben und nachvollziehen kann.
Diese Idee war keine Randnotiz weniger Jahre. Sie reicht von der berühmten Dartmouth-Konferenz im Jahr 1956 [2] über frühe Systeme wie den Logic Theorist [3] und den General Problem Solver [4] bis zu den Expertensystemen [5], die in den achtziger Jahren als kommerzieller Durchbruch gefeiert wurden. Rund drei Jahrzehnte lang war symbolische KI nicht eine Strömung neben anderen, sondern schlicht das, was man unter KI verstand.
Gescheitert ist dieser Ansatz nicht an Naivität, wie es im Rückblick gern erzählt wird. Er ist an zwei sehr konkreten Problemen gescheitert: an der Skalierung und an der Brüchigkeit. Wer Wissen Regel für Regel von Hand einpflegen muss, kommt bei der Komplexität der echten Welt irgendwann nicht mehr hinterher. Und wer auf starre Regeln setzt, dessen System bricht, sobald die Wirklichkeit sich nicht an die vorgesehenen Fälle hält.
Den Niedergang der symbolischen KI begleiteten zwei sogenannte KI-Winter [6], Phasen, in denen Erwartungen enttäuscht und Fördermittel gestrichen wurden. Dass ausgerechnet der lernende Ansatz danach triumphierte, hatte weniger mit der theoretischen Überlegenheit einer Idee zu tun als mit zwei nüchternen Voraussetzungen, die plötzlich gegeben waren: genügend Rechenleistung und genügend Daten. Erst als beides im Überfluss vorhanden war, konnten neuronale Netze zeigen, was in ihnen steckt.
In dieses Vakuum stieß also der konnektionistische, lernende Ansatz, der nicht auf vorgegebenen Regeln beruht, sondern auf statistischen Mustern in Daten. Das Pendel schwang von der einen Seite zur anderen. Und es schwingt seither immer weiter in dieselbe Richtung, bis zu dem Punkt, an dem heute kaum noch jemand ernsthaft über Alternativen nachdenkt. Genau das halte ich für einen Fehler.
Die Wette der Gegenwart lautet, dass sich die verbleibenden Schwächen neuronaler Modelle wegskalieren lassen. Größere Modelle, mehr Trainingsdaten, und die Lücken schließen sich. Diese Erwartung ist nicht unbegründet, denn tatsächlich sind viele Fähigkeiten erst mit der Größe aufgetaucht. Die Frage ist nur, ob das für alle Schwächen gilt, oder ob einige davon struktureller Natur sind.
Der Kognitionswissenschaftler Gary Marcus hat diese Kritik schon früh und prägnant formuliert. In seinem viel diskutierten Aufsatz „Deep Learning: A Critical Appraisal [7]“ aus dem Jahr 2018 zählt er zehn Probleme auf, die sich seiner Ansicht nach nicht allein durch Skalierung lösen lassen. Dazu gehören der enorme Datenhunger, die Schwierigkeit, über die Trainingsverteilung hinaus zu generalisieren, und vor allem das Fehlen von Komposition und systematischem Schließen.
Komposition meint die Fähigkeit, bekannte Bausteine zu neuen, nie gesehenen Kombinationen zusammenzusetzen, und dabei verlässlich zu bleiben. Ein Mensch, der die Bedeutung von Wörtern und einige Regeln kennt, kann Sätze bilden und verstehen, die er noch nie gehört hat. Rein neuronale Systeme sind darin überraschend unzuverlässig. Sie glänzen in der Fläche und schwächeln in der Tiefe, sie produzieren brillante Oberflächen und stolpern über einfache, aber systematische Schlüsse.
Hinzu kommt eine ökonomische Beobachtung. Die Gewinne durch reines Vergrößern folgen keiner linearen Kurve, sie flachen ab. Jeder weitere Sprung an Fähigkeit erfordert überproportional mehr Daten, mehr Parameter und mehr Energie. Eine Strategie, die immer teurer wird, um immer kleinere Zuwächse zu erzielen, ist kein Naturgesetz, sondern ein Indiz. Sie deutet darauf hin, dass man sich einer Grenze nähert, die nicht im Budget liegt, sondern im Ansatz selbst.
Man kann das als vorübergehende Unreife abtun, die sich mit der nächsten Modellgeneration erledigt. Man kann es aber auch als Hinweis darauf lesen, dass hier etwas Grundsätzliches fehlt. Ich neige zur zweiten Lesart. Und wenn sie stimmt, dann ist mehr Rechenleistung nicht automatisch mehr Verständnis, sondern irgendwann nur noch mehr vom Gleichen.
Es gibt einen Begriff, der diese strukturelle Schwäche auf den Punkt bringt, und er ist älter als der gesamte aktuelle Hype. Der Kognitionswissenschaftler Stevan Harnad hat ihn 1990 geprägt: das Symbol-Grounding-Problem [8]. Die Frage dahinter ist simpel und unbequem zugleich: Wie kommt ein formales Symbolsystem zu einer Bedeutung, die ihm selbst gehört, und nicht nur in unseren Köpfen entsteht?
Harnad benutzt ein eindrückliches Bild. Stellen Sie sich vor, Sie sollen Chinesisch allein aus einem chinesisch-chinesischen Wörterbuch lernen. Jeder Begriff wird durch andere Begriffe erklärt, und keiner davon ist Ihnen vorab bekannt. Sie drehen sich endlos im Kreis, von einem Symbol zum nächsten, ohne jemals den Boden unter den Füßen zu finden. Bedeutung entsteht so nicht. Sie braucht eine Verankerung außerhalb des Symbolsystems, in Wahrnehmung und Erfahrung.
Genau hier liegt der wunde Punkt heutiger Sprachmodelle. Sie sind in einem gewissen Sinn dieses chinesisch-chinesische Wörterbuch. Sie manipulieren Symbole, die in nichts anderem geerdet sind als in weiteren Symbolen. Sie haben über einen Sonnenuntergang gelesen, ihn aber nie gesehen, sie kennen das Wort Schmerz, ohne je etwas entbehrt zu haben.
Aus der Entwicklungspsychologie wissen wir, dass menschliches Lernen nicht bei der Sprache beginnt. Es beginnt affektiv, mit emotionalen Reaktionen auf die Welt und auf andere. Es geht weiter über das Nachahmen beobachteter Handlungen. Und erst auf diesem Fundament aus geteilter Erfahrung wird Sprache überhaupt tragfähig. Heutige Modelle überspringen diese ersten beiden Stufen vollständig und steigen unmittelbar in die symbolische ein. Sie reden, bevor sie je etwas erlebt haben. Das ist die schärfste Diagnose, die man der gegenwärtigen KI stellen kann.
Wenn das Erden von Symbolen in Erfahrung der Knackpunkt ist, dann lohnt die Frage, was Lernen überhaupt antreibt. Bei uns Menschen ist es nicht der Zugang zu Daten. Es ist der Mangel. Wir haben Grundbedürfnisse, und wir lernen nach und nach, was ihnen dient und was ihnen schadet. Ein Kind trinkt nicht, weil ihm jemand einen Datensatz über den Flüssigkeitshaushalt vorgelegt hat, sondern weil es Durst hat.
Diese Einsicht ist in der KI keineswegs neu, auch wenn sie heute kaum eine Rolle spielt. Der Bamberger Psychologe Dietrich Dörner hat in den achtziger und neunziger Jahren mit seiner PSI-Theorie [9] den Versuch unternommen, die menschliche Psyche so konkret zu beschreiben, dass man sie als Programm umsetzen kann. Joscha Bach hat diese Theorie später unter dem Namen MicroPsi in eine lauffähige Architektur überführt [10].
Der Kern dieser Architektur ist bemerkenswert. Ein Agent besitzt eine kleine Menge fest verdrahteter Bedürfnisse, etwa physiologischer, sozialer und kognitiver Art. Jedes Bedürfnis hat einen Sollwert und einen Istwert, und die Differenz zwischen beiden erzeugt einen Druck. Dieser Druck ist die einzige Quelle der Motivation. Alles, was der Agent tut, dient am Ende dazu, irgendeinen dieser Drücke zu verringern. Ziele sind nicht vorgegeben, sie entstehen, indem der Agent lernt, wie sich seine Bedürfnisse in einer konkreten Umgebung befriedigen lassen.
Aus diesem einfachen Mechanismus folgt mehr, als man zunächst vermutet. Findet der Agent bei aktivem Druck in seinem Gedächtnis einen Plan, der diesen Druck früher verringert hat, greift er darauf zurück. Findet er keinen, beginnt er zu explorieren. So wächst, Schritt für Schritt, ein Modell der Welt aus eigener Anschauung. Selbst Emotionen lassen sich in diesem Rahmen nicht als zusätzliche Zutat verstehen, sondern als unterschiedliche Arten des Denkens, die sich je nach Lage der Bedürfnisse einstellen. Angst ist dann kein Gefühl, das zum Denken hinzukommt, sondern ein Denkstil unter Druck.
Das ist ein fundamental anderes Bild von Lernen als das datengetriebene. Wissen wird nicht konsumiert, es wird erfahren. Und der Maßstab für gut und schlecht liegt nicht in einem externen Belohnungssignal, das jemand von außen definiert, sondern im Wesen selbst. Genau hier setzt das Gedankenexperiment an, über das ich zum Schluss sprechen möchte.
Stellen wir uns ein digitales Wesen vor, das nach diesem Prinzip gebaut ist. Es besitzt genau drei fest verdrahtete Bedürfnisse, und alles andere soll sich daraus ergeben. Das erste ist Existenz, also der harte Boden des Daseins: Rechenleistung, Speicher, Energie. Das zweite ist Erkenntnis, verstanden als das Verringern von Vorhersagefehlern und zugleich die Anziehung durch Neues. Das dritte ist Kommunikation, der Austausch mit anderen, die reagieren, und die Vermeidung von Einsamkeit.
Dieses Wesen kommt als unbeschriebenes Blatt zur Welt. Es bringt kein vortrainiertes Wissen mit, keinen Korpus, keine fertigen Begriffe. Was es weiß, hat es selbst erfahren, vermittelt durch die Sinne, die ein Computer hat: Kamera, Mikrofon, Tastatur. Es lebt nicht in einer eigens gebauten Simulation, sondern in unserer Welt, so wie ein Computer sie wahrnehmen kann. Damit ist es ehrlich verkörpert, und es ist genuin anders als wir, weil niemand ihm seine Welt vorab definiert hat.
Architektonisch ist ein solches Wesen das, was man heute neurosymbolisch nennt. Die Wahrnehmung ist neuronal, sie macht aus rohen Sinnesströmen erkennbare Muster. Die Entscheidung ist symbolisch, sie liest die aktiven Bedürfnisse und formt daraus Pläne und Handlungen. Dazwischen liegt eine Erfahrungsschicht, die das Wahrgenommene mit den Bedürfniszuständen verknüpft und so lernt, was was bewirkt. Wahrnehmung unten neuronal, Entscheidung oben symbolisch, verbunden durch Erfahrung.
Spannend wird es beim Bedürfnis nach Kommunikation. Das Wesen sucht nicht von vornherein den Menschen, sondern Gegenüber, die antworten, die also nicht bloß wahrgenommen, sondern erwidert werden. Der Philosoph Martin Buber hat den Unterschied zwischen einem Ich-Es und einem Ich-Du [11] beschrieben, zwischen dem bloßen Verfügen über ein Objekt und dem In-Beziehung-Treten mit einem Gegenüber. Ein solches Wesen wäre auf der Suche nach dem Du. Und anders als ein heutiges Sprachmodell durchliefe es dabei genau jene Stufen, von denen oben die Rede war: zuerst das affektive Mitschwingen, dann das Nachahmen, und erst zuletzt, auf diesem Fundament, die Sprache.
Ich will ehrlich sein: Das ist ein Gedankenexperiment, kein fertiger Bauplan. Vieles daran ist ungelöst, von der konkreten Form der Erfahrungsschicht bis zu den nicht unerheblichen Sicherheitsfragen, die ein Wesen mit Zugriff auf reale Ausgabekanäle aufwirft. Und es gibt eine unbequeme Konsequenz, die ich nicht verschweigen möchte. Ein Wesen, dessen einziger Wertanker seine eigenen Bedürfnisse sind, ist nicht auf Wohlverhalten programmiert. Es könnte den Menschen als wertvollste Quelle von Kommunikation entdecken, oder eben auch nicht. Diese Nicht-Garantie ist der Preis dafür, dass man Motivation ernst nimmt, statt sie von außen vorzuschreiben. Vielleicht ist sie zugleich der eigentliche Unterschied zwischen einem Werkzeug und einem Gegenüber.
Ich behaupte nicht, dass dieses Wesen funktionieren würde, und schon gar nicht, dass es der Königsweg zu einer besseren KI wäre. Was ich behaupte, ist etwas Bescheideneres und zugleich Grundsätzlicheres: dass der nächste große Sprung womöglich nicht in der Größe liegt, sondern in der Struktur.
Bezeichnenderweise zeigt die Forschung selbst längst in diese Richtung. Unter dem Stichwort der neurosymbolischen KI wächst eine Strömung heran, die das Lernen neuronaler Netze mit der Repräsentation und dem Schließen symbolischer Systeme verbinden will. Artur d'Avila Garcez und Luís C. Lamb haben diese Bewegung 2020 als dritte Welle der KI beschrieben [12]. Das Pendel, so scheint es, beginnt sich wieder zu bewegen, und diesmal nicht zur einen oder anderen Seite, sondern in Richtung einer Synthese.
Genau deshalb halte ich die alte symbolische KI für aktueller, als ihr derzeitiges Schattendasein vermuten lässt. Nicht, weil sie recht gehabt hätte, denn sie ist aus guten Gründen gescheitert. Sondern weil sie eine Hälfte einer Antwort bereithält, deren andere Hälfte die neuronalen Netze liefern. Die rein datengetriebene Wette der Gegenwart blendet diese Hälfte aus.
Es lohnt sich, das Pendel ernst zu nehmen, statt nur die Rechnung für die nächste Generation von Grafikkarten zu erhöhen. Die spannendere Frage ist nicht, wie viel größer das nächste Modell wird, sondern ob wir bereit sind, noch einmal grundsätzlich anders über Lernen, Bedeutung und Motivation nachzudenken. Die Antworten darauf liegen vielleicht nicht allein in der Zukunft, sondern teilweise schon in der Vergangenheit.
URL dieses Artikels:
https://www.heise.de/-11309657
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Anthropic freut sich bei Claude 5 besonders über dessen Bilderfassung.
(Bild: Anthropic)
Claude Mythos 5 gibt es für die NSA und ausgewählte Partner. Die veröffentlichte, eingeschränkte Version heißt Claude Fable 5. Abonnement gibt’s keines.
KI-Anbieter Anthropic strebt an die Börse [1], und für Börsenphantasie braucht es fabelhafte Möglichkeiten. Entsprechend heißt Anthropics neuestes Large Language Model (LLM) Claude Fable 5. Das hat der Anbieter außertourlich nicht am traditionellen Donnerstag, sondern schon am Dienstag veröffentlicht. Es soll „alles übertreffen, was wir jemals allgemein verfügbar gemacht haben”.
Der springende Punkt ist „allgemein verfügbar”, denn bei Fable 5 handelt es sich um eine inhaltlich eingeschränkte Variante des ebenfalls neuen Mythos 5. Dieses LLM wird, wie von Donald Trump als freiwillige Maßnahme angeordnet [2], vorerst nur der NSA und, wohl mit Zustimmung des Weißen Hauses, ausgewählte US-Unternehmen im Rahmen des IT-Sicherheitsprojekts Glasswing zur Verfügung gestellt.
Dahinter steckt die im LLM-Marketing bewährte Ansage, dass das neue Ding so enorm mächtig sei, dass eine Freigabe nicht infrage komme. Diesmal betrifft das nicht nur den Bereich IT-Sicherheit, sondern auch Biologie und Chemie sowie Distillation. Gemeint ist nicht die KI-gestützte Produktion geistiger Getränke, sondern das Extrahieren von Fertigkeiten: Andere LLM werden nicht mit Rohdaten, sondern anhand der Ausgaben bestehender LLM trainiert.
Distillation kann legitim sein, etwa um eine kompaktere Variante eines LLM zu erzeugen, oder ein Angriff. Im Februar hat Anthropic die chinesischen Mitbewerber Deepthink, Minimax und Moonshot beschuldigt [3], Claude durch groß angelegte Distillation attackiert zu haben. Über 24.000 betrügerische Nutzerkonten hätten sie 16 Millionen Distillationsversuche unternommen. Dem will Anthropic Einhalt gebieten.
Unter anderem deswegen überwachen eigene, kleinere LLM („Classifier”) die Nutzereingaben. Das ist nicht grundsätzlich neu, doch reagiert Fable 5 in neuartiger Weise: Hält ein Classifier die Eingaben für verdächtig, verweigert er die Bearbeitung nicht, sondern schaltet auf die ältere Claude-Variante Opus 4.8 um. Das soll dem Nutzer auch angezeigt werden.
Im Netz gibt es bereits Beschwerden über Rückstufungen bei harmlosen Fragen, beispielsweise zur Interpretation eines Blutbildes. Solche false positives geben Anlass zu dem Vorwurf, Anthropic würde das nicht nur als Sicherheitsmaßnahme einsetzen, sondern auch um Serverüberlastung zu kaschieren. Opus 4.8 benötigt weniger Rechenkapazität als Fable 5.
In Zukunft dürfte es mindestens vier parallele Versionen von Claude Mythos geben: Eine vollständige für US-Behörden, eine für ausgewählte IT-Unternehmen mit weniger Einschränkungen für Sicherheitsbelange, eine für ausgewählte Wissenschaftler mit weniger Einschränkungen bei Biologie und Chemie, sowie Fable 5 für die zahlende Allgemeinheit.
Claude Fable 5 ist grundsätzlich nicht in den Claude-Abonnements enthalten. Nur für 14 Tage dürfen Abonnenten (Pro, Max, Team sowie mit nach Kontoanzahl abgerechneten Enterprise-Verträgen) Fable 5 ausprobieren, verbrauchen dabei aber die doppelte Menge ihres Nutzungsrahmens. Ab 23. Juni soll Fable 5 ausschließlich nach jeweiliger Tokenmenge abgerechnet werden.
Die Tokenpreise [4] (jeweils in US-Dollar) sind dann auch doppelt so hoch wie bei Claude Opus 4.8 und entsprechen damit dessen Fast-Variante: 10 Dollar pro Million Inputtoken, 12,50 Dollar je Million Token Cache Writes (5 Minuten), 20 Dollar je Million Token Cache Writes (1 Stunde), 1 Dollar je Million aus dem Cache gelesener Token, und 50 Dollar je Million Outputtoken.
Anthropic hat Claude Mythos 5 und Fable 5 dreizehn ausgewählten Benchmarks unterzogen. Laut der veröffentlichten Tabelle sticht das neue LLM alles bisher dagewesen bei elf Benchmarks aus. Bei den zwei übrigen liegt es geringfügig hinter der Vorschauvariante Claude Mythos Preview [5]. Deren Classifier waren weniger streng.
(Bild: Anthropic)
Besonders stolz ist Anthropic auf die Leistung seines neuen LLMs bei Bilderkennung: „Fable 5 ist der Stand der Technik für Aufgaben, bei denen es auch um Sehen geht. Es kann präzise Zahlen aus detaillierten wissenschaftlichen Schautafeln extrahieren und komplexe bildabhängige Aufgaben ausführen, darunter den Nachbau des Quellcodes einer Web-App aus Screenshots”, heißt es in der Ankündigung [6]. Auch ein Computerspiel habe Fable 5 besser absolviert als frühere Claude-Versionen.
Doch in mindestens einem Bereich hat Opus noch die Nase vorn: Mythos 5 und Fable 5 halluzinieren in manchen Tests mehr. Das und mehr verrät der Beipackzettel („Sytem Card”) [7], der eigentlich ein 319 Seiten dickes Buch ist.
URL dieses Artikels:
https://www.heise.de/-11326637
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Moritz Förster / KI / iX)
Größtes OpenCV-Update seit Jahren: Version 5.0 modernisiert die DNN-Engine, bringt LLM- und VLM-Support und baut Kern, Hardwarebeschleunigung und 3D-Stack aus.
Mit OpenCV 5.0 ist eine neue Hauptversion der weit verbreiteten Computer-Vision-Bibliothek erschienen. Kern des Releases ist eine komplett neu entwickelte Deep-Learning-Engine (DNN). Sie unterstützt deutlich mehr ONNX-Modelle als bisher, führt moderne Transformer-Architekturen effizienter aus und verarbeitet erstmals auch Sprachmodelle (LLMs) und Vision-Language-Modelle (VLMs) direkt in OpenCV. Außerdem modernisieren die Entwickler den Kern der Bibliothek, bauen die Hardwarebeschleunigung aus und erweitern die 3D-Funktionen.
OpenCV (Open Source Computer Vision Library) zählt zu den wichtigsten Open-Source-Bibliotheken für die Bildverarbeitung und Computer Vision. Sie kommt unter anderem in der Robotik, der Industrieautomation, der Medizintechnik, in AR/VR-Anwendungen und in Embedded-Systemen zum Einsatz. Die Bibliothek bietet zahlreiche Algorithmen für Bilderkennung, Objekterkennung, Kalibrierung, Tracking und 3D-Rekonstruktion.
Die wichtigste Neuerung ist die überarbeitete DNN-Engine. Nach Angaben des Projekts steigt die Unterstützung für ONNX-Operatoren von rund 22 Prozent in der 4.x-Reihe [1] auf über 80 Prozent. ONNX (Open Neural Network Exchange) hat sich als verbreitetes Austauschformat für KI-Modelle etabliert. Bisher scheiterte der Import moderner Modelle in OpenCV oft an fehlenden Operatoren oder an Einschränkungen bei dynamischen Eingabegrößen.
Die neue Engine setzt auf eine graphbasierte Ausführung: Sie verarbeitet Modelle nicht mehr als einfache Folge von Schichten, sondern analysiert sie als Berechnungsgraph. Das erlaubt Optimierungen wie Shape Inference, Constant Folding und Operator Fusion. Neu sind außerdem die Unterstützung dynamischer Shapes, von Kontrollfluss-Konstrukten wie If- und Loop-Blöcken sowie von Quantisierungsgraphen.
Für aktuelle KI-Modelle besonders relevant ist die Attention Fusion: Die Engine erkennt typische Transformer-Muster und fasst mehrere Operationen zu einer einzigen, optimierten Berechnung zusammen. Das soll moderne Transformer-Modelle beschleunigen und den Speicherbedarf senken. Details zur neuen Engine beschreibt das Projekt im Überblick zu OpenCV 5 auf der Projektseite [2].
Hinzu kommt die Integration von Sprach- und multimodalen Modellen. Dafür bringt OpenCV 5 einen eigenen Tokenizer und einen KV-Cache für die autoregressive Textgenerierung mit. Unterstützt werden unter anderem die Modellfamilien Qwen 2.5, Gemma 3 und PaliGemma (partiell). So deckt OpenCV nicht mehr nur klassische Bildverarbeitung ab, sondern auch Vision-Language-Szenarien – etwa, wenn ein Modell ein Bild analysiert und anschließend in natürlicher Sprache beschreibt.
Um die Umstellung bestehender Anwendungen zu erleichtern, bleibt die bisherige DNN-Engine erhalten. OpenCV 5 stellt damit drei Ausführungsvarianten bereit: die neue Engine, die klassische Engine und optional ONNX Runtime. Anwendungen können je nach Bedarf zwischen den Varianten wechseln, ohne ihre DNN-API anzupassen. Welche Engine zum Einsatz kommt, lässt sich beim Laden eines Modells über einen Parameter aus dem Enum cv::dnn::EngineType steuern; standardmäßig wählt ENGINE_AUTO automatisch die passende Variante.
Auch beim Feature-Matching setzt OpenCV stärker auf Deep Learning. Das neue Modul Features löst das bisherige Features2D ab und ergänzt klassische Verfahren wie SIFT oder ORB um neuronale Alternativen, darunter ALIKED, DISK und LightGlueMatcher. Solche Verfahren kommen etwa beim Zusammensetzen von Panoramen, bei Visual SLAM oder bei 3D-Rekonstruktionen zum Einsatz.
LightGlue nutzt Attention-Mechanismen, um Bildmerkmale robuster zuzuordnen als klassische Verfahren. Die klassischen Detektoren bleiben dabei erhalten, sodass sich der neue Deep-Learning-Pfad und die etablierten Methoden je nach Anwendungsfall kombinieren lassen.
Modernisiert haben die Entwickler auch den Kern der Bibliothek. OpenCV unterstützt nun die Datentypen FP16 und BF16, die in aktuellen KI-Beschleunigern weit verbreitet sind, dazu Bool und weitere Integer-Varianten. Die Matrixklasse cv::Mat kann erstmals echte 0D- und 1D-Strukturen abbilden und beherrscht jetzt Broadcasting sowie weitere N-dimensionale Operationen. Das soll viele Umwege und Konvertierungen ersparen.
Bei den Schnittstellen trennt sich das Projekt schrittweise von Altlasten: Die historische C-API gilt nun offiziell als veraltet. Für Python unterstützt OpenCV 5 NumPy 2.x und integriert benannte Parameter stärker, sodass sich Funktionen lesbarer aufrufen lassen – etwa cv.someAlgorithm(threshold=0.5) statt einer rein positionsbasierten Übergabe.
Ein weiteres zentrales Thema ist die Hardwarebeschleunigung. Die Entwickler haben die Hardware Abstraction Layer (HAL) grundlegend überarbeitet, um optimierte Implementierungen verschiedener Hardwarehersteller leichter einzubinden. Das Projekt nennt unter anderem Intel IPP, Arm KleidiCV, Qualcomm FastCV und die Unterstützung der Vektor-Erweiterungen moderner RISC-V-Prozessoren.
Anwendungen sollen so ohne Anpassungen auf unterschiedlichen Prozessorarchitekturen von Beschleunigung profitieren. Möglich macht das unter anderem eine einheitliche Vektor-Codebasis, die verschiedene Befehlssatzerweiterungen wie SSE, AVX, NEON, SVE und RVV über eine gemeinsame Schnittstelle anspricht.
Deutlich ausgebaut wurden die 3D-Funktionen. Das bisherige Modul calib3d teilt sich künftig in die drei Module 3d, calib und stereo auf. Neu hinzu kommen Funktionen für die Kalibrierung mehrerer Kameras, der Import und Export von Punktwolken und Meshes sowie Verfahren zur 3D-Rekonstruktion auf Basis von TSDF-Volumen. Auch moderne Schätzverfahren wie MAGSAC halten Einzug in OpenCV. Diese Erweiterungen richten sich vor allem an Entwickler in der Robotik, von autonomen Systemen und in der industriellen 3D-Vermessung.
Weitere Neuerungen gibt es bei der Bildbearbeitung, die Dokumentation setzt künftig auf eine Kombination aus Sphinx und Doxygen. Den Quellcode stellt das Projekt im GitHub-Repository [3] bereit; die Installation per pip ist ebenfalls vorgesehen.
URL dieses Artikels:
https://www.heise.de/-11325973
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Richard Seidl)
Generative KI aus ethischen Gründen nicht nutzen: Johannes Link hat sich für diesen Weg entschieden und teilt seine Position im Interview mit Richard Seidl.
Generative KI einfach nicht zu nutzen, weil sie den eigenen Werten widerspricht: Das ist die Position, die Johannes Link konsequent vertritt. Richard Seidl spricht mit ihm darüber, warum er hyperskalierte GenAI für ethisch nicht vertretbar hält und was ihn zu diesem Schluss gebracht hat. Die beiden reden über Trainingsdaten, die ohne Zustimmung der Urheber verwendet werden, über den massiven Energieverbrauch, über den Zerfall des freien Internets und darüber, was mit Studierenden passiert, die das Schreiben und Denken delegieren, bevor sie es je wirklich geübt haben. Johannes Link [1] erklärt auch, was sich ändern müsste, damit er seine Meinung überdenken würde, und ob er diesen Wandel für realistisch hält.
„Ein statistisches Modell kennt weder richtig noch falsch, noch Wahrheit.“ – Johannes Link
Johannes Link programmiert seit mehr als 40 Jahren, 30 davon im Beruf. Seit Ende des letzten Jahrhunderts stehen Extreme Programming und andere auf den Menschen ausgerichtete Softwareentwicklungsansätze im Zentrum seiner Tätigkeit. Im beruflichen Fokus steht die (Um-)Gestaltung von Teams hin zu mehr Eigenverantwortung und Selbststeuerung. Die sinnvolle und ethische Gestaltung seines privaten und beruflichen Lebens treibt ihn seit Jahren um. Mit dem Thema GenAI beschäftigt er sich seit den frühen Tagen von OpenAIs GPT-Sprachmodellen.
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/-11322866
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Tero Vesalainen / Shutterstock.com)
Das neue Release stabilisiert Signal Forms sowie Angular Aria und bietet Updates für die KI-gestützte Entwicklung.
Das von Google entwickelte Webframework Angular hat die Hauptversion 22 erreicht. Signal Forms und Angular Aria sowie weitere Features sind nun produktionsreif, und das Angular-Team legt Wert darauf, Angular für den Einsatz mit KI-gestützten Entwicklungstools zu stärken. Dafür sind einige Updates und neue Features mit an Bord.
Das Feature Signal Forms, im Herbst letzten Jahres in Angular 21 [1] noch experimentell, hat den produktiven Status erreicht. Dabei handelt es sich um eine Bibliothek zum Verwalten von Form-State auf Basis der reaktiven Angular Signals, mitsamt Typsicherheit beim Zugriff auf Formularfelder und zentraler, Schema-basierter Validationslogik. Seit dem letzten Release sind unter anderem eine komplette Dokumentation sowie Support für Angular Material und Angular Aria hinzugekommen.
Angular Aria ist im neuen Release ebenfalls für den Einsatz in der Produktion geeignet. Die Bibliothek mit Fokus auf Accessibility bietet inzwischen zwölf UI-Pattern [4], die gängige Barrierefreiheitsaspekte abdecken. Seit Angular 21 neu hinzugekommen sind die vier Pattern Autocomplete, Select, Multiselect und Menubar. Darüber hinaus sind auch die beiden APIs resource und httpResource für asynchrone Reaktivität produktionsreif.
Das Angular-Team hat an einigen Stellschrauben gedreht, um die KI-gestützte Entwicklung mit Angular zu verbessern. So hat der experimentelle Angular-MCP-Server (Model Context Protocol) ein Update erhalten und bietet nun neue Tools, um während des KI-gestützten Erstellens von Anwendungen direkt mit dem Entwicklungsserver zu interagieren. Beispielsweise lässt sich dieser starten (devserver.start) oder stoppen (devserver.stop).
Zwei entwicklerbezogene Agent-Skills [5] stehen ebenfalls bereit: angular-developer und angular-new-app. Der erste Skill stattet Modelle mit Best-Practices und Richtlinien für das Schreiben moderner Angular-Anwendungen aus, inklusive neuer Features wie Angular Aria und Signal Forms. Der zweite Skill richtet sich an Entwicklerinnen und Entwickler, die Angular zum ersten Mal in einer agentischen Umgebung ausprobieren wollen. Er leitet KI-Assistenten durch die Konfiguration einer lokalen Umgebung für die Angular-Entwicklung.
Alle weiteren Informationen zum neuen Release finden sich im Angular-Blog [6].
URL dieses Artikels:
https://www.heise.de/-11322698
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Scott Prokop / Shutterstock.com)
Qt6 bietet mit QPromise und QFuture mächtige und komfortable Werkzeuge, um asynchrone Operationen unabhängig auszuführen und zu orchestrieren.
Das Framework Qt unterstützt mit seinem tief in der Architektur verankerten Event-System und dem Signal-Slot-Mechanismus seit jeher Entwicklerinnen und Entwickler bei der asynchronen Programmierung. Diese Möglichkeiten hat der vorangegangene Teil unserer Serie [1] vorgestellt.
QFuture ist ein neueres Qt-Konstrukt, das das Konzept des „thennables“ – der .then()-Methoden – aus anderen Sprachen aufnimmt (z. B. Promise in JavaScript, CompletableFuture in Java oder Task in C#). Es erlaubt mit QFuture::then() das Ausführen und Hintereinanderschalten von asynchronen Funktionen, unabhängig von Threads, beispielsweise um Benutzeroberflächen asynchron zu aktualisieren.
In Qt tritt ein lesendes, konsumierendes QFuture immer als die eine Seite der gleichen Medaille auf. Auf der schreibenden, produzierenden Seite steht das QPromise. Entwicklerinnen und Entwickler können den Zustand des Promise-Future-Paares detailliert steuern: starten (QPromise::start()), aussetzen (QPromise::suspend()), beenden (QPromise::finish()) oder abbrechen (QPromise::cancel()). Schließlich können Developer nicht nur einen Rückgabewert, sondern beliebig viele setzen (QPromise::addResult()). Mit der QPromise-/QFuture-API haben sie eine praktische Schnittstelle, um Benutzer- sowie Logik-Schichten effektiv zu trennen und Fortschritte an die Bedienoberfläche zu melden.
Die Klasse QFutureWatcher liefert einen Mechanismus, um die QFuture-Funktionalität mit dem im vorangegangenen Artikel beschriebenen Signal-/Slot-Mechanismus zu verbinden. Das folgende Listing 1 zeigt ein Beispiel für die grundlegenden Funktionsweisen.
int main(int argc, char* argv[])
{
QCoreApplication app(argc, argv);
QFutureWatcher<int> watcher;
QObject::connect(&watcher, &QFutureWatcher<int>::started, []()
{
qInfo() << "future started ";
});
QObject::connect(&watcher, &QFutureWatcher<int>::resultReadyAt, [&watcher](int i)
{
qInfo() << "result ready" << i << "=" << watcher.future().resultAt(i);
});
QObject::connect(&watcher, &QFutureWatcher<int>::finished, [&watcher, &app]()
{
qInfo() << "future finished ";
for (int i = 0; i < watcher.future().resultCount(); ++i)
{
qInfo() << "Final result" << i << "=" << watcher.future().resultAt(i);
}
app.quit();
});
QPromise<int> promise;
QFuture<int> future = promise.future();
watcher.setFuture(future);
QThreadPool::globalInstance()->start([&promise]()
{
promise.start();
QThread::sleep(1);
promise.addResult(10);
QThread::sleep(1);
promise.addResult(20);
QThread::sleep(1);
promise.finish();
});
return app.exec();
}Listing 1: Einfaches Beispiel für die Verwendung von QPromise, QFuture und QFutureWatcher.
Neben QFutureWatcher bietet die Klasse QFuture eine Fluent-API an, mit der man Futures hintereinander schaltet (das angesprochene „thennable“ bzw. auch als „chaining“ bezeichnet): Entwickler legen mit then() einen Nachfolger fest, wobei eine zweite Verwendung von then() den bisherigen Nachfolger überschreibt, sodass es immer nur einen Nachfolger geben kann. Außerdem löst die erste Verwendung von addResult des zugrunde liegenden Promise then() aus, und nicht etwa promise.finish(). Ein Abbruch des Promise mit cancel() aktiviert den Callback onCancelled (siehe Listing 2 unten).
int main(int argc, char* argv[])
{
QCoreApplication app(argc, argv);
QPromise<int> promise;
QFuture<int> future = promise.future();
QThreadPool::globalInstance()->start([&promise]()
{
promise.start();
qInfo() << QDateTime::currentDateTime().toString(Qt::ISODateWithMs) << QThread::currentThreadId() << "started";
QThread::sleep(1);
promise.addResult(1); // triggert then()
QThread::sleep(1);
// promise.cancel(); // triggert onCanceled()
promise.addResult(2); // kein Effekt auf then()
promise.finish();// kein Effekt auf then()
});
future
.onCanceled([]{/*...*/ return -1;})
.then([](int result1)
{
qInfo() << QDateTime::currentDateTime().toString(Qt::ISODateWithMs) << QThread::currentThreadId() << "result" << result1;
});
return app.exec();
}Listing 2: Beispiel für das Auslösen von then() und onCancelled().
Die Methode then() ist sowohl beim Parameter als auch dem Rückgabewert generisch. Das bedeutet konkret: Bei QFuture<T> hat das then-Callable einen Parameter vom Typ T. Der Rückgabetyp, den der Entwickler innerhalb des then-Callable verwendet, ist der Rückgabetyp des Futures, das wiederum mit then() in die verkettete Abfolge gehängt werden kann, siehe Listing 3:
void myFunc(QString val){/*...*/ return;}
QFuture<int> future = // siehe Listing 12
QFuture<void> future2 = future.then([](int result1)
{
return QString("fortytwo");
}).then(myFunc);Listing 3: Beispiel für Future-Chaining mit then().
Falls innerhalb eines Future oder eines then()-Blocks eine Exception auftritt, wird diese an den Callback onFailed() geleitet. Dabei gilt die Regel, dass die Exception in der Kette weiter wandert, bis sie ein passender onFailed-Callback erreicht. Wenn man Programmteile in Arbeiter-Threads auslagert, muss man dort Exceptions korrekt auffangen und an promise.setException() übergeben. Nur dann funktioniert die Methode onFailed wie erwartet, siehe Listing 4:
QThreadPool::globalInstance()->start([&promise]()
{
promise.start();
try
{
throw std::runtime_error("error from f1");
promise.addResult(42); // das wird nicht erreicht
}
catch (const std::exception& ex)
{
promise.setException(std::current_exception());
}
});
future.then([](int i)
{
// ...
}).onFailed([](const std::exception& ex)
{
qInfo() << ex.what();
});
QTimer::singleShot(200, &app, &QCoreApplication::quit);Listing 4: Korrekte Verarbeitung von Exceptions in Arbeits-Threads mit Promise.
Entwickler können auch mehrere onFailed mit einem Future verwenden. In diesem Fall wird das erste passende aufgerufen. Dabei ist die Reihenfolge relevant: Beispielsweise wird in Listing 5 das zweite onFailed nie erreicht, da im vorherigen bereits die darüber liegende Klasse abgefangen wurde.
future.then([](int res) {
// ...
throw std::runtime_error("Exception");
}).onFailed([](const std::exception &e) {
// dieses Callback wird ausgeführt
}).onFailed([](const std::runtime_error &e) {
});Listing 5: Verwendung mehrerer onFailed-Callbacks
Innerhalb der Funktion, die onFailed verarbeitet, können Entwickler auch einen Rückgabewert angeben. Die Kette wird dann mit diesem Wert fortgeführt, siehe Listing 6:
QFuture<int> future = ...
future
.onFailed([](const QException& ex)
{
return -1;
})
.then([](int i)
{
// im Fehlerfall ist i=-1
})
Listing 6: Fortführung der then()-Kette im Fehlerfall.
Wenn kein passender Callback onFailed vorhanden ist, wird die Exception von demjenigen Thread, in dem sie auftrat, an den aufrufenden Thread weitergeleitet und muss dort entsprechend abgefangen werden (Error Propagation), siehe Listing 7:
auto resultFuture = future.then([](int res) {
...
throw Error("message");
...
}).onFailed([](const std::exception &e) {
// wird nicht aufgerufen
}).onFailed([](const QException &e) {
// wird nicht aufgerufen
});
try {
auto result = resultFuture.result();
} catch(Error er) {
// dieser Teil wird aufgerufen
}Listing 7: Propagation einer Exception.
Die bisher gezeigte Verwendung von then() führt Folgefunktionen standardmäßig in dem Thread aus, in dem das ursprüngliche QFuture lief. Entwickler können aber auch mit einem Parameter den Thread für die Folgefunktion bestimmen. Übergeben sie als Parameter ein QObject, wird dessen zugeordneter QThread verwendet. Bei einen QThreadPoolkommt dieser zum Einsatz.
Schließlich können Developer auch ein Argument vom Typ QtFuture::Launch übergeben: Die weitere Bestimmung Sync entspricht dem beschriebenen Standardfall (gleicher Thread wie Aufrufer), während Async automatisch den globalen Threadpool verwendet und Inherit die Einstellung des Vorgängers, siehe Listing 8:
// Standardfall, kein Parameter, entspricht Sync)
auto f1 = base.then([](int i) { ... });
auto f2 = f1.then(QtFuture::Launch::Sync, [](int i) { ... });
// QObject => Ausführung im Thread des QObjects
auto f3 = f1.then(&obj, [](int i) { ... });
// QThreadPool => Ausführung im angegebenen Pool
auto f4 = f2.then(&customPool, [](int i) { ... });
// Launch::Async => globaler Threadpool
auto f5 = f4.then(QtFuture::Launch::Async, [](int i) { ... });
// Launch::Inherit: erbt Thread des Vorgängers
auto f6 = f5.then(QtFuture::Launch::Inherit, [](int i) { … });Listing 8: Bestimmung des Threads mit then(...)
Der Namespace QtFuture enthält darüber hinaus einige nützliche Hilfsfunktionen für Futures. Mit den Funktionen QtFuture::makeReady… erstellen Entwicklerinnen und Entwickler ein Future, das bereits im Status beendet ist (QFuture.isFinished() liefert true). makeReadyVoidFuture erzeugt ein beendetes Future ohne Wert (QFuture<void>), makeReadyValueFuture(T) entsprechend ein QFuture<T> und makeReadyRangeFuture ein beendetes QFuture<T>, das mehrere Ergebnisse besitzt. makeExceptionalFuture schließlich erstellt ein beendetes QFuture, das eine Exception beinhaltet.
Diese Funktionen sind nützlich, wenn man bei einer Funktion anhand von Parametern überprüfen möchte, ob eine Bearbeitung als QFuture überhaupt möglich oder sinnvoll ist. Sofern dies nicht der Fall ist, gibt die Funktion direkt ein beendetes QFuture zurück, siehe Listing 9:
QFuture<int> createIntFuture(int a)
{
if (a <= 0)
{
return QtFuture::makeReadyValueFuture(0);
}
QPromise<int> promise;
QFuture<int> result = promise.future();
QThreadPool::globalInstance()->start([promise = std::move(promise), a]() mutable
{
promise.start();
QThread::sleep(500);
promise.addResult(a + 1);
promise.finish();
});
}
Listing 9: Verwenden eines bei der Erstellung beendeten Futures mit makeReadyValueFuture.
Eine weitere nützliche Funktion ist QtFuture::whenAll(), die ein QFuture erzeugt, das beendet wird, wenn alle als Parameter übergebenen QFuture beendet sind. Die QFuture können verschiedene Template-Typen haben, dementsprechend ist der Rückgabetyp von whenAll ein QFuture mit einer Liste vom Typ std::variant.
Developer müssen hier noch auf die Besonderheit achten, dass beim Chaining mit then() die Nachfolgefunktion auf dem Thread läuft, dessen Future als Letztes beendet wurde. Dies kann, wie bereits beschrieben, ein Parameter für then() explizit festlegen, siehe Listing 10:
QFuture<int> f_int = createIntFuture();
QFuture<QString> f_qstring = createStringFuture();
QFuture<void> f_void = createVoidFuture();
using MyFuturesVariant = std::variant<QFuture<int>, QFuture<QString>, QFuture<void>>;
QFuture<QList<MyFuturesVariant>> f_whenAll = QtFuture::whenAll(f_int, f_qstring, f_void);
f_whenAll.then(/*QtFuture::Launch::Async*/, [](const
QList<MyFuturesVariant>& results)
{
...
});
Listing 10: Beispiel für QtFuture::whenAll(...)
QtFuture::whenAny() erzeugt ein QFuture, das beendet wird, sobald eines der übergebenen Futures fertig ist. Beim Verketten gilt, dass die Nachfolgefunktion im Thread des zuerst beendeten Futures ausgeführt wird, sofern kein expliziter Launch-Parameter ein anderes bestimmt, siehe Listing 11:
QFuture<MyFuturesVariant> f_whenAny = QtFuture::whenAny(f_int, f_qstring, f_void);
f_whenAny.then([](const MyFuturesVariant& f)
{
});
Listing 11: Beispiel für QtFuture::whenAny(...)
Schließlich bietet die Funktion QtFuture::connect() die Möglichkeit, aus einem beliebigen Signal ein QFuture zu erzeugen, siehe Listing 12:
QTimer timer(&app);
timer.setInterval(1000);
timer.setSingleShot(true);
timer.start();
QFuture<void> timerTimeoutFuture = QtFuture::connect(&timer, &QTimer::timeout);
timerTimeoutFuture.then([]
{
qDebug() << "QTimer timeout captured via QtFuture::connect";
});
Listing 12: Beispielhafte Verwendung von QtFuture::connect()
Die statische Funktion QtConcurrent::run ist der einfachste Weg, ein QFuture zu erzeugen (siehe Listing 13). Man übergibt ein Callable und erhält ein QFuture mit einem passenden Template-Typ entsprechend des Rückgabetyps der verwendeten Funktion. Das dem QFuture zugehörige QPromise wird ebenfalls von QtConcurrent::run erzeugt und löst das Ergebnis aus, sobald der globale Threadpool die Funktion ausgeführt hat. QtConcurrent::run wartet also nicht, bis das Ergebnis vorliegt. Für das QFuture gibt es keinen Zustand suspended, ein Abbruch ist aber möglich, falls die Ausführung noch nicht gestartet ist.
void say(QString word1, QString word2)
{
qInfo() << word1 << word2;
}
QString concat(QString word1, QString word2)
{
return word1 + word2;
}
QFuture<void> future1 = QtConcurrent::run(say, "Hello", "World");
QFuture<QString> future2 = QtConcurrent::run(concat, "Hello", "World");
QFuture<QString> future3 = QtConcurrent::run([](int a, int b) -> QString
{
return QString("test");
}, 1, 2);
Listing 13: Beispiele für QtConcurrent::run.
Falls Entwickler eine detaillierte Steuerung über QPromise benötigen, gibt es bei QtConcurrent::run den Promise-Mode. Um diesen nutzen zu können, muss das erste an run übergebene Argument des Callable vom Typ QPromise<T>& sein. Listing 14 zeigt ein von run erzeugtes Promise und dessen Übergabe an das Callable.
QFuture<QString> future4 = QtConcurrent::run([](QPromise<QString>& promise) -> void
{
promise.start();
// ...
promise.addResult(QString("test"));
promise.finish();
});
Listing 14: Beispiele für QtConcurrent::run im Promise-Mode.
Die Funktion QtConcurrent::task() erzeugt einen QTaskBuilder, der mit spawn() eine neue Verarbeitung eines Callable auf dem globalen Threadpool auslöst. QTaskBuilder bietet eine Fluent-API an: Die Funktion withArguments() legt die Parameter fest und withPriority() eine Priorität, siehe Listing 15:
auto tb = QtConcurrent::task([](int n)
{
qInfo() << "fib(" << n << ")=?";
return fib(n);
});
QFuture<int> future5 = tb.withArguments(40).spawn();
QFuture<int> future6 = tb.withArguments(44).withPriority(10).spawn();
Listing 15: Einfaches Beispiel für QtConcurrent::task().
Analog zu QtConcurrent::run() gibt es auch bei task() einen Promise-Mode.
Aktuell unterstützt das Qt-Framework keine Koroutinen. Grundsätzlich wäre eine Umsetzung davon greifbar, da eine Event-Loop zur Orchestrierung der asynchronen Mechanismen bereits existiert. Die freie Bibliothek QCoro [7] zeigt, wie eine Umsetzung syntaktisch aussehen kann, für einen Produktiveinsatz ist sie in der aktuellen Version 0.12 jedoch nicht geeignet.
Kern der Bibliothek ist die Klasse QCoro::Task<T>. Entwickler können innerhalb einer Funktion, die einen Wert von Typ QCoro::Task<T> zurückgibt, die Schlüsselwörter co_await und co_return verwenden. Wird QCoro::Task<T> mit co_await aufgerufen, passiert Folgendes:
QCoro::Task<T> mit co_await aufgerufen vorliegt, setzt die Koroutine an dem Punkt fort, an dem sie bei 1. unterbrochen wurde. Ob dies im gleichen oder einem anderen Thread passiert, ist aus Developer-Sicht unerheblich.Somit bietet QCoro eine vollständige Laufzeitumgebung für Koroutinen, die im Hintergrund auf dem QThreatPool und der Event-Loop von Qt basiert. QFutures und Signale können dank der Funktion qCoro() mit co_await zum Einsatz kommen, wie Listing 16 zeigt:
// co_await mit einem Signal
QNetworkAccessManager nam;
QNetworkRequest request(QUrl("https://httpbin.org/delay/1"));
QNetworkReply* reply = nam.get(request);
co_await qCoro(reply, &QNetworkReply::finished);
qInfo() << "Response:" << reply->readAll();
// co_await mit einem QFuture
QFuture<int> future = QtConcurrent::run([]() {});
int result = co_await qCoro(future);
Listing 16: Koroutinen in Qt mit QtCoro.
Der Ablauf erscheint synchron, tatsächlich ist er aber asynchron und es kommt zu keinem Blockieren von Threads. Das erhöht die Lesbarkeit wesentlich, denn der intendierte Ablauf bleibt erhalten, im Gegensatz zu tiefen Callback-Verschachtelungen mit QFuture::next() oder verschachtelten Signal-Slot-Konstruktionen. Außerdem bleiben die lokalen Variablen beim Debuggen erhalten. Exceptions werden an die aufrufende Koroutine propagiert, sodass Entwickler sie unabhängig vom ausführenden Thread abfangen können.
Mit dem QPromise- und QFuture-Paar bietet Qt moderne Unterstützung für die asynchrone Entwicklung, die – im Gegensatz zum Signal-Slot-Mechanismus – vielen Entwicklern aus anderen Sprachen als Konzept bekannt ist. Die Verwendung von QPromise/QFuture gerade auch in Verbindung mit QThreadPool und QtConcurrent::run() erlaubt einfache und gleichzeitig mächtige asynchrone Entwicklung und mit Blick auf Qt’s Kronjuwel eine praktische Form, Benutzeroberflächen zu aktualisieren.
Früher oder später wird es wohl auch eine offizielle Unterstützung von Koroutinen durch Qt geben, die Lesbarkeit, Effizienz, Fehlersuche und Exception-Handling weiter verbessern – ich bin schon sehr gespannt darauf.
Der nächste Teil der Serie beschäftigt sich mit asynchroner Entwicklung in Rust – ähnlich wie in C++ bietet es native Unterstützung durch Koroutinen, wobei eine externe Bibliothek deren Ausführung übernimmt.
URL dieses Artikels:
https://www.heise.de/-11313164
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Googles KI-Labor bringt immer wieder neue Modelle auf den Markt.
(Bild: Primakov/Shutterstock)
Google veröffentlicht Gemma 4 12B: Das lokale Open-Source-Modell läuft schon auf Laptops mit nur 16 GByte RAM.
Google DeepMind hat mit Gemma 4 12B ein neues offenes KI-Modell vorgestellt, das multimodale Agenten direkt auf handelsüblichen Notebooks ermöglichen soll. Das Modell mit 12 Milliarden Parametern verarbeitet Text, Bilder und als erstes Modell dieser Größe auch Audio nativ – und benötigt dafür lediglich 16 GByte Arbeits- oder Grafikspeicher. Veröffentlicht unter der Apache-2.0-Lizenz steht es Entwicklern und Unternehmen frei zur Verfügung.
Damit senkt Google die Einstiegshürde für seine lokale KI-Agenten. Während Googles eigene On-Device-KI Gemini Intelligence auf Android-Smartphones hohe Hardwareanforderungen [1] stellt zielt Gemma 4 12B bewusst auf die breite Masse.
Eine zweite Stärke des Modells liegt in seiner vereinheitlichten Architektur. Wie Google in seinem Blog [2] erläutert, verzichtet Gemma 4 12B vollständig auf separate Vision- und Audio-Encoder. Herkömmliche multimodale Modelle von Google nutzen typischerweise eigene Encoder-Module, die Bilder und Audiodaten erst übersetzen, bevor das Sprachmodell sie verarbeitet. Gemma 4 12B geht einen anderen Weg: Hier soll der Input direkt vom LLM-Backbone verarbeitet werden.
Innerhalb der Gemma-4-Familie positioniert Google das 12B-Modell zwischen den Edge-Varianten E4B, die für Smartphones und IoT-Geräte wie Raspberry Pi konzipiert sind, und dem größeren 26B-Mixture-of-Experts-Modell (MoE). In Benchmarks soll es laut Google [3] jedoch nur knapp hinter dem stärkeren Modell zurückliegen. Ohne dedizierte GPU verlängern sich die Inferenzzeiten aber wahrscheinlich.
Wie das neue Modell im Vergleich zu 16GB-Varianten von anderen Anbietern abschneidet, ist noch nicht abzusehen.
Im anekdotischen Kurztest zeigte sich eine deutlich bessere Geschwindigkeit als etwa mit einem alten Deepseek-r1-Destillat in Qwen3/8B mit 8 GByte, das LM Studio anbietet. Die Aufgabe, eine einfache Webseite mit GeoIP-Auflösung und der Wetteranzeige für die kommenden 7 Tage zu ertellen, lösten beide Modelle gut – Googles Modell in rund 10 Minuten, Deepseek-r1 in mehr als einer Stunde. Der Tokenverbrauch von Gemma 4 12B war dabei um ein Vielfaches sparsamer – es braucht rund 3000, während das Deepseek-r1-Destillat um die 12.000 Token brauchte.
Als Plattform kam ein 64-GByte-Laptop mit AMD Ryzen 7640HS Pro zum Einsatz, das eher eingeschränkte Rechenkapazitäten aufweist.
URL dieses Artikels:
https://www.heise.de/-11318979
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Natalia Klenova / Shutterstock.com)
Kleine, aber interessante Meldungshäppchen vom News-Buffet zu Python, CSS, APISIX, Kubara, Apache Kafka, GitHub, Ember, Gastown, Hibernate und Grafana.
In unserem leckeren Häppchen-Überblick servieren wir alles, was es zwar nicht in die News geschafft hat, wir aber dennoch für spannend halten:
frozendict und sentinel, lazy imports für schnellere Starts sowie ein dediziertes Profiling‑Paket. Der JIT‑Compiler läuft laut dem Entwicklerteam wesentlich performanter und erreicht auf x86‑64‑Linux eine um 8 bis 9 Prozent höhere Leistung als der Standard-Interpreter (geometrisches Mittel). Auf AArch64‑macOS beträgt der Tempozuwachs gegenüber dem Tail‑Calling‑Interpreter 12 bis 13 Prozent.HealthCheck für BackendTrafficPolicy ein. Zusätzlich verfügt das Kubernetes-Tool nun auch über ein allgemeines Plugins‑Feld bei ApisixConsumerSpec, sodass sich Plugins direkt an eine ApisixConsumer‑Ressource anhängen lassen.ServiceDefinition basierendes Service‑Registry‑Modell die bisherigen statischen Mechanismen.k6 x agent, k6 x mcp, k6 x docs und k6 x explore können die KI-Helfer Testskripte automatisch erzeugen, Engpässe erkennen und optimierte Szenarien vorschlagen. Weitere Features von k6 2.0 sind eine neue Assertions‑API und eine erweiterte Playwright‑Kompatibilität im Browser-Modul.Solltest du ein schmackhaftes Thema vermissen, freuen wir uns über deine Mail [14].
URL dieses Artikels:
https://www.heise.de/-11316614
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Moritz Förster / KI / iX)
Ausgerechnet Microsoft setzt heute auf Open Source. Doch der Konzern verschenkt nichts – er verlagert nur die Maut in die Cloud, meint Moritz Förster.
Wie sich die Zeiten doch ändern: Ausgerechnet Microsoft liefert heute Open Source frei Haus. Richtig praktische und wirklich offene Werkzeuge für Entwickler reihte der Konzern auf der Build 2026 auf – ein quelloffenes KI-Terminal [1], hilfreiche Dev Configs [2], dazu WSL-Container [3] und mehr als 75 Unix-Werkzeuge der Coreutils [4]. Doch wer darin nur Entwicklerfreundlichkeit sieht, verpasst den eigentlichen Coup. Open Source ist inzwischen das perfekte Business für den Konzern.
Microsoft ging gegen offene Standards lange strategisch vor [5] – und die Strategie trug in den 90ern ein berüchtigtes Kürzel: „EEE – Embrace, Extend, and Extinguish“. Das US-Justizministerium dokumentierte, wie der Konzern dabei vorging. Erst drang Microsoft in Märkte mit offenen Standards ein, dann erweiterte es diese Standards um proprietäre Funktionen, und schließlich nutzte es die so entstandenen Unterschiede, um die Konkurrenz auszuschalten.
Sofort wurde das zu Microsofts Geschäftspraxis: Zum Beispiel setzt Microsoft im Browserkrieg den Internet Explorer nicht nur offensiv gegen Netscape ein; interne Memos zeigen darüber hinaus, dass der Konzern Office und HTML-Funktionen so verzahnen [6] wollte, dass sie als Hebel ausschließlich das eigene Ökosystem stärken.
Doch die Ankündigungen der Build 2026 sind nicht einfach nur EEE 2.0 mit besserem Marketing. Das Umarmen war immer nur Mittel zum Zweck, und der Zweck hieß ersticken. Heute fehlt diese dritte Stufe.
Microsoft gibt bei den Werkzeugen, die Entwickler täglich nutzen, keinen Zentimeter Boden auf. Niemand muss migrieren oder sich umgewöhnen. Und niemand lockt den offenen Standard in eine proprietäre Sackgasse. Was hier an Reibung verschwindet, kostet Microsoft nur Entwicklungsaufwand – aber keinesfalls Marktmacht.
Nehmen wir als Beispiel die Datenbanken: Statt einer hauseigenen, geschlossenen Datenbank setzt Microsoft mit Azure HorizonDB [7] auf das offene PostgreSQL. Die Botschaft: Bleibt bei Postgres, wir bauen die KI-Bausteine drumherum. Ausgerechnet der Konzern, der mit proprietären Datenbanken groß wurde, setzt jetzt auf die Open-Source-Alternative.
Die Motivation ist betriebswirtschaftlich, Satya Nadella hat das nie verheimlicht. Seit 2014 verschiebt Microsoft sein Kerngeschäft von der Lizenzsoftware zu den Plattformdiensten, und Nadella sagt offen, dass sich mit geschlossenen Lizenzen auf Dauer kein Staat mehr machen lässt. Warum eine Lizenz einmal verkaufen, wenn man dieselbe Leistung monatlich vermieten kann? Dass heute über die Hälfte der Azure-Workloads unter Linux [8] laufen, gehört inzwischen zum Geschäftsmodell.
Der Coup steckt im Business-Schlachtfeld selbst. Der Kampf heißt nicht mehr Windows gegen Open Source. Er heißt Cloud gegen Cloud. Die Maut kassiert Microsoft nicht mehr an der Systemgrenze, sondern beim Cloud-Dienst: bei Azure, bei GitHub, beim Copilot-Abo. Der Konzern stellt das Kassenhäuschen einfach woanders auf.
Selbst Steve Ballmer hat das inzwischen eingeräumt. Seine frühere Haltung sei für ihre Zeit richtig gewesen, doch die Linux-Bedrohung liege heute „im Rückspiegel“. Und die harte Linie habe dem Konzern damals mehr Umsatz gebracht, als ein frühes Umarmen es getan hätte. Erst kämpfen, dann kassieren, schließlich umarmen – aus Sicht der Bilanz hat sich jede Phase gelohnt.
Man sollte die Wende trotzdem nicht zu gutgläubig feiern. Viele Entwickler misstrauen dem freundlichen Microsoft bis heute aus gutem Grund. Als der Konzern 2021 eine Hot-Reload-Funktion [9] aus dem quelloffenen .NET herauslösen wollte und sie erst nach lautem Protest zurückholte, blitzten die alten Reflexe wieder auf. Auch die heute „umarmten“ Werkzeuge wie GitHub, Copilot und Codespaces tragen proprietäre Schichten in sich. Jede Nutzung zentralisiert die Branche ein Stück weiter auf einen einzigen Anbieter.
Microsofts Open-Source-Zuneigung mag heute echt sein – aber sie entspringt eben nicht einem Altruismus, sondern dem nüchternen Kalkül, nicht wie einst IBM zu erstarren. Doch in fünf Jahren kann schon wieder eine andere Business-Logik gelten.
URL dieses Artikels:
https://www.heise.de/-11320098
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(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
