Fortinet: Hochriskante Lücken in FortiWeb, FortiManager und weiteren
Von Heise — 11. März 2026 um 12:47
(Bild: Michael Vi / Shutterstock.com)
Fortinet schließt Lücken in FortiWeb oder FortiManager, die etwa Einschleusen von Befehlen erlauben. FortiGate-Firewalls wurden attackiert.
Fortinet nennt es zwar nicht Patchday, verteilt aber parallel zu dem Patchday-Datum mehrere Sicherheitsupdates für diverse Produkte. Hochriskante Lücken finden sich etwa in FortiWeb, FortiManager und FortiClientLinux. Angreifer können Befehle einschleusen oder Brute-Force-Angriffe auf Zugänge starten.
Die gravierendste Sicherheitslücke betrifft FortiClientLinux. Aufgrund einer Link-Verfolgungs-Schwachstelle können lokale User ohne weitreichende Rechte ihre Berechtigungen auf root ausweiten (CVE-2026-24018 [1], CVSS 7.4, Risiko „hoch“). Unzureichende Prüfung der Interaktionsfrequenz ermöglicht nicht authentifizierten Angreifern, das Authentifizierungs-Rate-Limit von FortiWeb mit manipulierten Anfragen auszuhebeln (CVE-2026-24017 [2], CVSS 7.3, Risiko „hoch“). Die Versionen FortiWeb 7.0.12, 7.2.12, 7.4.11, 7.6.6 und 8.0.3 oder jeweils jüngere korrigieren den Fehler. Im fgtupdates-Dienst von FortiManager kann beim Verarbeiten von manipulierten Anfragen an den Dienst durch nicht angemeldete Angreifer aus dem Netz ein Stack-basierter Pufferüberlauf auftreten, in dessen Folge sich Befehle einschleusen und ausführen lassen (CVE-2025-54820 [3], CVSS 7.0, Risiko „hoch“). FortiManager 7.2.11 und 7.4.3 sowie neuere bessern die Schwachstelle aus; wer noch auf Stand 6.4 ist, muss auf neuere Fassungen aktualisieren. Sofern der fgtupdates-Dienst aktiviert ist, hilft alternativ auch einfach das Abschalten.
Fortinet listet noch 15 weitere Sicherheitslücken auf:
FortiGate-Firewall-Einbrüche führen zu kompromittierten ADs
SentinelOne hat derweil Analyse-Ergebnisse zu FortiGate-Firewall-Einbrüchen [19] veröffentlicht. Die IT-Forscher bemängeln darin zunächst, dass als wiederkehrendes Muster betroffene Organisationen nicht genügend mitprotokollieren, was die Untersuchungen zu Zeitpunkt und genutzter Schwachstellen zum Eindringen verhindert. Der Zeitraum zwischen Einbruch in die Firewall und Kompromittierung weiterer Geräte rangierte zwischen nahezu umgehend und zwei Monaten. Die Analysten erläutern unter anderem, wie Angreifer Gerätekonfigurationen ausforschen und etwa eigene Admin-Konten anlegen, mit denen sie sich persistenten Zugriff sichern. Vor der weiteren Verbreitung im Netz gab es lediglich zwischendurch Logins zum Prüfen, ob der Zugriff noch besteht. SentinelOne sieht darin typisches Verhalten von Initial-Access-Brokern, die geknackte Zugänge an Dritte verkaufen. Diese haben dann Maschinen ins AD verfrachtet und sich darüber weiteren Zugriff auf das Netzwerk verschaffen wollen. Die Scans lösten dann jedoch Sicherheitsalarme aus.
In einem anderen Fall haben die Angreifer ebenfalls einen lokalen Admin auf der geknackten FortiGate-Firewall angelegt und AD-Zugangsdaten daraus ausgelesen. Innerhalb der folgenden zehn Minuten haben die Angreifer sich mit dem AD-Admin-Konto in mehrere Server eingeloggt und Remote-Monitoring-und-Management-Tools (RMM) installiert. Bei Pulseway und MeshAgent handelt es sich den Autoren des Berichts zufolge um legitime Admin-Tools, die jedoch häufig von bösartigen Akteuren eingesetzt werden. Die Angreifer installierten dann Malware, die sie von AWS-Cloudspeicher heruntergeladen hatten. Damit haben sie eine Volumenschattenkopie angelegt und daraus einige Daten an die Server der Angreifer übertragen. Diese Vorfälle zeigen, dass die kompromittierte Firewall tatsächlich für tiefgreifende Unterwanderung missbraucht wird.
Wer Fortinet-Produkte einsetzt, sollte die verfügbaren Aktualisierungen also zügig installieren. Die Schwachstellen in den Netzwerkprodukten stehen bei Cyberkriminellen hoch im Kurs und werden immer wieder rasch nach Bekanntwerden angegriffen [20].
URL dieses Artikels: https://www.heise.de/-11207011
Passwort-Manager KeePassXC 2.7.12: Was Nutzer beim Update beachten müssen
Von Heise — 11. März 2026 um 12:16
(Bild: heise medien)
KeePassXC 2.7.12 schützt Windows-Nutzer vor DLL-Injection über OpenSSL, ändert Passkey-Flags und unterstützt TOTP-Platzhalter in Auto-Type.
Der quelloffene Passwort-Manager KeePassXC ist in Version 2.7.12 erschienen. Das Release behebt mehrere Sicherheitsprobleme, allen voran einen Schutz gegen DLL-Injection-Angriffe unter Windows. Außerdem bringt es funktionale Erweiterungen, darunter TOTP-Unterstützung in Auto-Type und verschachtelte Ordner beim Bitwarden-Import.
Wie die Entwickler in ihrem Release-Blog [1] mitteilen, enthält die neue Version Mitigationen gegen Exploits über manipulierte OpenSSL-Konfigurationsdateien auf Windows. Bei einer DLL-Injection schleusen Angreifer bösartige Dynamic Link Libraries in den Adressraum eines laufenden Prozesses ein, um beliebigen Code auszuführen oder Rechte zu erhöhen. KeePassXC 2.7.12 verhindert nun, dass OpenSSL-Konfigurationen als Angriffsvektor für solche Injektionen missbraucht werden.
Passkey-Flags ändern sich – Vorsicht beim Update
Eine potenziell aufwendige Änderung betrifft Passkeys [2]: KeePassXC speichert jetzt die Flags Backup Eligibility (BE) und Backup State (BS) mit jedem Eintrag. Das BE-Flag zeigt an, ob ein Passkey als Multi-Device-Credential gesichert und synchronisiert werden kann, das BS-Flag markiert den aktuellen Sicherungsstatus. Bisher waren beide Werte fest auf false gesetzt, ab Version 2.7.12 stehen sie standardmäßig auf true. Die Entwickler warnen ausdrücklich: „Dies könnte bestehende Passkeys brechen, für die die Flags nicht gespeichert wurden, da die Werte als unveränderlich gelten.“
Wer nach dem Update Probleme mit bestehenden Passkeys feststellt, kann den vorherigen Zustand wiederherstellen, indem er unter „Advanced“ zwei String-Attribute manuell hinzufügt: KPEX_PASSKEY_FLAG_BE=0 und KPEX_PASSKEY_FLAG_BS=0. Zusätzlich wird nun der publicKey in die Register-Response für Passkeys aufgenommen.
TOTP-Platzhalter und verbesserter Browser-Dialog
KeePassXC 2.7.12 unterstützt jetzt {TIMEOTP} als Platzhalter in Auto-Type-Sequenzen und als Entry-Platzhalter. TOTP (Time-based One-Time Password) ist ein RFC 6238 spezifizierter Algorithmus, der aus einem gemeinsamen geheimen Schlüssel und der aktuellen Systemzeit zeitbasierte Einmalpasswörter generiert – typischerweise alle 30 Sekunden. Nutzer können damit automatisch den aktuellen TOTP-Code in Login-Formulare einfügen lassen, ohne ihn händisch aus einer Authenticator-App ablesen zu müssen.
Im Browser-Zugriffsdialog zeigt KeePassXC nun die abgeglichenen URLs in einem Tooltip an. So lässt sich leichter verifizieren, welche Websites tatsächlich Zugriff auf gespeicherte Zugangsdaten anfordern. Außerdem validiert die neue Version die Haupt-Entry-URL bei der Verwendung von Platzhaltern und speichert browserbezogene Werte korrekt in den customData-Feldern.
Bitwarden-Import mit verschachtelten Ordnern
Wer von Bitwarden zu KeePassXC migriert, kann mit der neuen Version auch verschachtelte Ordner übernehmen. Bitwarden nutzt einen Schrägstrich als Trennzeichen für hierarchische Ordnerstrukturen, etwa „Socials/Forums“. KeePassXC 2.7.12 bildet diese Hierarchie beim Import korrekt ab, sodass die Vault-Struktur erhalten bleibt.
Weitere Bugfixes
Unter Linux haben die Entwickler eine Änderung rückgängig gemacht, die eine Race-Condition in der Auto-Type-Funktion verursachte. Darüber hinaus behebt das Release diverse kleinere Probleme: Die Anzeige des Kontrollkästchen-Werts in den Browser-Integrations-Einstellungen stimmt jetzt, Font- und Theme-Darstellung wurden korrigiert, der „Entfernen“-Button in den Plugin-Daten funktioniert wieder ordnungsgemäß, und Dateinamen werden vor dem Speichern von Anhängen bereinigt.
Maker Faire Ruhr: Maker treffen, Projekte entdecken und gemeinsam tüfteln
Von Heise — 11. März 2026 um 14:30
(Bild: heise medien)
Vom 14. bis 15. März verwandelt sich die DASA in Dortmund wieder in ein Maker-Paradies! Und natürlich ist auch die Redaktion wieder dabei.
Am 14. und 15. März 2026 wird die DASA Arbeitswelt Ausstellung in Dortmund wieder zum Treffpunkt der Maker-Szene. Jeweils von 10 bis 18 Uhr verwandelt sich die riesige Industriehalle in ein piependes, blinkendes und surrendes Paradies für Tüftler, Bastler, Entwickler und neugierige Besucher.
Über 60 Aussteller bringen ihre Projekte mit – von Robotik über Kunst bis hin zu ungewöhnlichen DIY-Erfindungen. Wer gerne programmiert, näht, lötet, experimentiert oder einfach Freude an kreativer Technik hat, wird hier garantiert fündig.
Die Make-Redaktion ist wieder dabei
Direkt am Eingang der Maker Faire Ruhr findet man auch in diesem Jahr wieder den Stand der Make-Redaktion. Das Team freut sich schon darauf, die Besucher zu treffen, mit ihnen zu fachsimpeln, Projekte zu diskutieren und natürlich über die Messe zu streifen.
Für die Redaktion ist eine Maker Faire immer auch eine Inspirationsquelle. Zwischen blinkenden Robotern, mechanischen Kunstwerken und anderen verrückten Ideen entdeckt man schließlich ständig neue Projekte, die Stoff für kommende Artikel liefern könnten.
Natürlich bringt das Team auch wieder eigene Projekte mit. Darunter sind diesmal Ideen für Zocker, ein Projekt für Verliebte, DIY-Werkstatteinrichtung und sogar ein streng geheimes Projekt, das erst in einer kommenden Make-Ausgabe ausführlich vorgestellt wird. Besucher der Maker Faire Ruhr bekommen jedoch schon jetzt einen exklusiven ersten Blick darauf.
Wer sich mit dem Kauf einer Wärmepumpe beschäftigt, findet außerdem unser detailliertes Wasserpumpen-Modell, das genau zeigt, wie man so ein Gerät richtig anschließt. Und wenn man dann gleich noch einen Taupunktlüfter einbauen will, kann man sich auf der Messe schon ein paar Tipps von der Redaktion holen.
Ein weiteres Highlight am Stand ist die Makey:Lab-Hardware, die von der Make entwickelt wurde. Sie ist auf der Maker Faire Ruhr erstmals in ihrer finalen Version zu sehen. Außerdem kann man einen Blick auf ein weiteres Make-Produkt werfen, das sich noch in Entwicklung befindet.
Werde Make-Autor
Die Maker Faire ist auch eine perfekte Gelegenheit, der Redaktion eigene Projekte zu zeigen. Viele Artikel in der Make werden von Lesern geschrieben, die ihr cooles Projekt der Welt präsentieren möchten.
Wer also etwas Spannendes gebaut hat, kann am Stand vorbeikommen, es vorstellen und mit der Redaktion darüber sprechen. Vielleicht wird daraus ja der nächste Artikel.
Von Raketen bis Steampunk
Abseits des Make-Standes ist die Bandbreite der Projekte wieder enorm. Funkamateure zeigen, wie's gemacht wird, Maker-Spaces aus der Region präsentieren ihre Werkstätten und Hochschulen bringen tolle Experimente mit.
Wer sich für historische Technik interessiert, kann erleben, wie Nassplattenfotografie funktioniert. Ganz andere Wege geht die Steampunk-Szene mit Projekten von Anachronika, LED Steampunk, Syrestria oder den Funkenspotz Kraftmaschinen Werken, die Technik mit viktorianischer Ästhetik verbinden.
Auch klassische Maker-Themen fehlen nicht: Robotik, Elektronik, CNC-Technik, 3D-Druck oder kreative Upcycling-Projekte. Dazu kommen Lego-Mitmachaktionen, Raketenmodellbau, mechanische Musikmaschinen und viele weitere Ideen, die man so wahrscheinlich nur auf einer Maker Faire entdeckt.
Vorträge rund um Technik, Maker-Kultur und digitale Themen
Parallel zur Messe läuft ein Vortragsprogramm mit Einblicken in spannende Projekte und mit aktuellen Themen aus der Maker-Welt.
Talks am Samstag
11.00–11.30 Uhr – Digitale Souveränität für Maker, was kann ich tun? – Daniel Hess (PING e.V.)
12.30–13.00 Uhr – Die Magie der Nassplattenfotografie – Matthias Weikamm
13.15–13.45 Uhr – Mit 18 im 3D-Druck selbständig – Mein Weg vom ersten 3D-Drucker zum Unternehmen – Jann Dickhaus (Filamentcore)
14.00–14.45 Uhr – Wer bin ich? Die digitale Identität – Prof. Walter Roth
15.00–15.30 Uhr – Das dunkelschwarze Lazarett – die Seuchen dieser, unserer Zeit – Torsten Knoll (TKn-DarkSteam)
11.45–12.15 Uhr – Kinder sind Maker von Geburt an! Maker-Projekte in Kita und Schule – Mathias Wunderlich (FASW Maker)
12.30–13.00 Uhr – Leben, JETZT! – Hospizarbeit ist bunt – Alexandra Hieck (Hospiz Am Ostpark Dortmund)
13.15–13.45 Uhr – Wie man (k)einen Zeppelin baut – Kurt Gerlach (Luftschiffwerk)
14.00–14.45 Uhr – Wer bin ich? Die digitale Identität – Walter Roth
15.30–16.00 Uhr – B 7 – Warum kauft man eine Zeche und baut seine eigene Wärmepumpe? – Christian Keßen, Stefan Kirchberg, Stephan Widera (Blumental 7 e.V.)
Shows, Experimente und fliegende Raketen
Auch spektakuläre Aktionen gehören traditionell zur Maker Faire Ruhr. Mehrmals täglich starten im Innenhof Raketenmodelle in den Himmel. In der Gefahrstoffhalle wird es bei der Feuer und Flamme Show ordentlich heiß, während die OneLoveMachineBand ihre ungewöhnlichen Maschineninstrumente zum Klingen bringt. Am Sonntag verblüffen Küchenexperimente mit Alltagsmaterialien.
Weitere Maker Faires in der DACH-Region
Die Maker Faire Ruhr ein Teil eines makerreichen Jahres. Für viele Veranstaltungen läuft bereits die Planung und auch schon der Call for Maker für die Maker Faire Hannover.
Maker-Faire-Termine 2026 in der DACH-Region
7.–9. Mai 2026 – Maker Faire Minden-Lübbecke
20.–21. Juni 2026 – Maker Faire Solothurn
1. Juni 2026 – Maker Faire Wuppertal
15.–16. August 2026 – Maker Faire Hannover
7.–8. November 2026 – Maker Faire Mittleres Rheinland
Wer also selbst ein Projekt zeigen möchte, sollte einen Blick auf die Bewerbungsseiten der jeweiligen Maker Faires werfen. Vielleicht steht das eigene Projekt schon bald auf einer der nächsten Maker-Bühnen.
URL dieses Artikels: https://www.heise.de/-11207239
Links in diesem Artikel: [1] https://www.heise.de/make [2] mailto:das@heise.de
Asynchrone Programmierung mit async und await gibt es seit Jahren in .NET. Nun liefert Microsoft eine neue Laufzeitumgebung für die asynchrone Ausführung.
Microsoft hat die zweite Preview-Version für .NET 11.0 veröffentlicht und bringt darin unter anderem Neuerungen für die asynchrone Programmierung.
Die Schlüsselwörter async und await sind in vielen modernen Programmiersprachen verankert, zum Beispiel in Python seit 2015, in JavaScript seit 2017, in Rust seit 2019 und in Swift seit 2021. Auf die Frage „Wer hat es erfunden?“ muss man in diesem Fall sagen: Microsoft. Im Jahr 2012 erschienen diese beiden Schlüsselwörter zuerst in C# Version 5.0 und Visual Basic .NET Version 11.0. Sie vereinfachten die asynchrone Programmierung für Entwicklerinnen und Entwickler gegenüber vorher existierenden Konzepten und inspirierten danach viele andere Programmiersprachen.
Was für Entwicklerinnen und Entwickler einfach ist, ist unter der Haube aber bis heute komplex: In den .NET-Sprachen sind async und await bisher im Compiler als State Machines realisiert. In .NET 11.0 Preview 2 bringt Microsoft nun eine weiterentwickelte Version der .NET-Laufzeitumgebung Common Language Runtime (CLR), die nativ das Aussetzen und die Wiederaufnahme asynchroner Methoden unterstützt. Das erzeugt nicht nur weniger Overhead als die bisherigen State Machines, sondern ermöglicht schlankere Stack Traces und einfacheres Debugging.
Listing 1 zeigt vier asynchrone Methoden, die sich gegenseitig aufrufen.
Bisher sah man als Ergebnis von Listing 1 die State Machine im Stack Trace:
at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene3() in
h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 27
at
System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine&
stateMachine)
at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene3()
at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene2() in
h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 21
at
System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine&
stateMachine)
at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene2()
at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene1() in
h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 15
at
System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine&
stateMachine)
at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene1()
at NET11_Console.Runtime.NET11_RuntimeAsync.Run() in h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 9
at
System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine&
stateMachine)
at NET11_Console.Runtime.NET11_RuntimeAsync.Run()
at Program.<Main>$(String[] args) in h:\git\ITVDemos\NET11\NET11_Console\Program.cs:line 8
Mit der neuen Laufzeitunterstützung für Asynchronität ist der Stack Trace deutlich kompakter:
at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene3() in
h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 27
at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene2() in
h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 21
at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene1() in
h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 15
at NET11_Console.Runtime.NET11_RuntimeAsync.Run() in
h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 9
at Program.<Main>$(String[] args) in h:\git\ITVDemos\NET11\NET11_Console\Program.cs:line 8
Allerdings erfordert die neue Unterstützung für Asynchronität in der Laufzeitumgebung aktuell noch, dass diese Neuerung in der Projektdatei separat aktiviert wird, siehe Listing 2.
Listing 2: Aktivierung der Asynchronität in der Laufzeitumgebung per Projekteinstellungen
Alle TAR-Formate
Das TAR-Archivformat beherrscht .NET seit der Version 7.0 mit den Klassen TarFile, TarEntry, TarReader und TarWriter im Namensraum System.Formats.Tar. Bei der Erstellung einer TAR-Datei mit TarFile.CreateFromDirectory() und TarFile.CreateFromDirectoryAsync() wurde als Archivformat immer das PAX-Format (POSIX.1-2001) verwendet. Entwicklerinnen und Entwickler haben seit .NET 11.0 Preview 2 die Möglichkeit, alle vier TAR-Formate zu wählen: TarEntryFormat.V7 (das ursprüngliche TAR-Format), TarEntryFormat.Ustar (Unix Standard TAR), TarEntryFormat.Gnu und TarEntryFormat.Pax.
Dies geschieht durch den zusätzlichen Parameter mit einem Enumerationswert aus TarEntryFormat:
Ein wesentlicher Unterschied zwischen den TAR-Formaten sind die maximalen Dateilängen: V7 erlaubt nur maximal 100 Zeichen für den Namen eines Eintrags. Bei USTAR sind es 256 Zeichen. Bei GNU und PAX ist die Länge von Dateinamen unbegrenzt. Bei USTAR ist die Dateigröße auf 8 GB beschränkt.
MinBy() und MaxBy() für Datenbankzugriffe
Die LINQ-Operatoren MinBy() und MaxBy() hat Microsoft bereits in .NET 6.0 eingeführt. Anders als die schon seit der ersten LINQ-Version in .NET Framework 3.5 verfügbaren Operatoren Min() und Max() liefern MinBy() und MaxBy() nicht nur den Minimal- bzw. Maximalwert selbst, sondern das ganze umgebende Objekt mit. Bisher waren MinBy() und MaxBy() nur in LINQ-to-Objects einsetzbar. Das ändert sich nun in .NET 11.0: Auch Entity Framework Core kann diese LINQ-Operatoren in SQL-Befehle umsetzen, siehe Listing 3.
var ctx = new DA.WWWings.WwwingsV1EnContext();
// Min vs. MinBy()
var wenigsteFreiePlaetze = ctx.Flights.Min(x => x.FreeSeats);
CUI.H1("Der Flug mit den wenigsten Plätzen hat " + wenigsteFreiePlaetze + " freie Plätze");
var flugMitDenWenigstenFreienPlaetzen = ctx.Flights.MinBy(x => x.FreeSeats);
Console.WriteLine(flugMitDenWenigstenFreienPlaetzen);
// Max() vs. MaxBy()
var meisteFreiePlaetze = ctx.Flights.Max(x => x.FreeSeats);
CUI.H1("Der Flug mit den meisten freien Plätzen hat " + meisteFreiePlaetze + " freie Plätze");
var flugMitDenMeistenFreienPlaetzen = ctx.Flights.MaxBy(x => x.FreeSeats);
Console.WriteLine(flugMitDenMeistenFreienPlaetzen);
Listing 3: MinBy() und MaxBy() in Entity Framework Core 11.0
Während der LINQ-Operator Min() die MIN()-Funktion in SQL nutzt
SELECT MIN([f].[FreeSeats])
FROM [Operation].[Flight] AS [f]
erstellt MinBy() eine sortierte Datensatzmenge und liefert den obersten Datensatz mit TOP(1) zurück:
SELECT TOP(1) [f].[FlightNo], [f].[Airline], [f].[Departure], [f].[Destination],
[f].[FlightDate], [f].[FreeSeats], [f].[Memo], [f].[NonSmokingFlight], [f].[Pilot_PersonID],
[f].[Seats], [f].[Timestamp]
FROM [Operation].[Flight] AS [f]
ORDER BY [f].[FreeSeats]
Datenübergabe zwischen HTTP-Anfragen mit TempData
Die in .NET 8.0 eingeführte Blazor-Variante Static Server-Side Rendering (SSR) ist den vorherigen Ansätzen für die Erstellung von Multi-Page-Apps im modernen .NET (ASP.NET Core Model-View-Controller (MVC) und ASP.NET Core Razor Pages) überlegen, hinsichtlich des Komponentenmodells, der Razor-Syntax und des partiellen Seitenaustauschs. Allerdings gab es bis dato auch einige Funktionen in MVC und Razor Pages, die Blazor SSR nicht beherrschte. Dazu gehören das Caching von Seitenteilen, erweiterbare Bedingungen für Routenparameter und die Datenübergabe zwischen HTTP-Anfragen mit dem TempData-Objekt (siehe GitHub-Issue [2]). Letzteres ist nun in .NET 11.0 Preview 2 möglich. Die Datenspeicherung erfolgt wahlweise als Cookie (CookieTempDataProvider) oder im Session Storage (SessionStorageTempDataProvider) des Webbrowsers.
Anders als bei MVC und Razor Pages ist TempData aber keine Property der Basisklasse, sondern muss als Cascading Parameter explizit konsumiert werden, siehe Listing 5. Dabei ist zu beachten, dass TempData wie bei MVC und Razor Pages nur Zeichenketten abspeichern kann, das heißt, komplexe Objekte müssen Entwicklerinnen und Entwickler selbst serialisieren, siehe Listing 4.
Geplant für kommende Preview-Versionen ist, dass das Auslesen von Daten aus TempData über eine Annotation [SupplyParameterFromTempData], mit der man eine Property annotieren kann, vereinfacht wird, siehe Pull Request [3].
Der in ASP.NET integrierte Webserver Kestrel lehnt nun ungültige Anfragen schneller ab, weil Microsoft intern auf das Auslösen einer BadHttpRequestException verzichtet und stattdessen eine Struktur zurückgibt. Das verbessert laut Microsoft den Durchsatz um 20 bis 40 Prozent bei Angriffen via Port Scanning oder mit fehlerhaften Anfragen.
.NET-Core-basierte WebAPIs unterstützen jetzt die Open API Specification in der Version 3.2. In .NET 10.0 war es Version 3.1.1.
Für die Erstellung von Web-Worker-Projekten gibt es nun eine eigene Projektvorlage „.NET Web Worker“ in Visual Studio beziehungsweise an der Kommandozeile: dotnet new webworker. Dabei entsteht eine DLL, die in Blazor-WebAssembly-basierten Anwendungen genutzt werden kann.
Ebenso steht in Entity Framework Core die Vektorsuche mit der SQL-Server-2025-Funktion VECTOR_SEARCH() via LINQ-Operation VectorSearch() zur Verfügung:
var sqlVector = new SqlVector<float>(EmbeddingsUtil.Get(suchBegriff));
var q = ctx.TexteSet.VectorSearch<Texte, SqlVector<float>>(b => b.Embedding, sqlVector, "cosine", topN: 5);
Dabei ist zu beachten, dass man VECTOR_SEARCH() auch in der stabilen Version von SQL Server 2025 erst via SQL-Befehl aktivieren muss
ALTER DATABASE SCOPED CONFIGURATION SET PREVIEW_FEATURES ON
und in .NET die Warnung „EP9105“ deaktivieren muss:
#pragma warning disable EF9105 // Type is for evaluation purposes only and is subject to change or removal in future updates. Suppress this diagnostic to proceed.
In .NET MAUI wurde das Steuerelement <Map> verbessert. Die Syntax ist nun kompakter.
Außerdem kann man Elemente auf der Karte (Polygon, Polyline, Circle) nun per IsVisible und ZIndex steuern. Zudem gibt es Click()-Ereignisse auf diesen Elementen.
Auch .NET-MAUI-Anwendungen für Apple-Betriebssysteme (iOS, tvOS und Mac Catalyst) können nun auf der .NET Core Runtime statt Mono laufen. Seit .NET 10.0 war dies experimentell für MAUI-Anwendungen auf Android möglich. Auch die Apple-Implementierung der .NET Core Runtime gilt aber als experimentell. Die Anwendungen werden aktuell durch die Umstellung aber größer und das Debugging ist noch eingeschränkt.
Laut den Release Notes [9] von .NET 11.0 Preview 2 gibt es in dieser Vorschauversion keine Neuerungen für die Sprachsyntax von Visual Basic und C# sowie das GUI-Framework Windows Forms. Bei der Windows Presentation Foundation (WPF) gibt es nur einen Bugfix.
Ausblick
.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 fünf weiteren Preview-Versionen von April bis August sowie jeweils einer Release-Candidate-Version im September und Oktober rechnen. heise developer wird jeweils berichten.
URL dieses Artikels: https://www.heise.de/-11207523
Bericht: Nvidia bereitet KI-Agentenplattform "NemoClaw" vor
Von Heise — 11. März 2026 um 14:33
Nvidias eigene KI-Agentenplattform soll „NemoClaw“ heißen.
(Bild: Michael Vi / Shutterstock.com)
Nvidia spricht laut einem Bericht bereits mit großen Softwareanbietern über eine Plattform für autonome KI-Agenten, die an OpenClaw erinnern.
Nvidia folgt dem Hype um den KI-Agenten OpenClaw [1] und entwickelt eine Plattform namens „NemoClaw“ speziell für Unternehmen, berichtet Wired unter Berufung auf mehrere Personen, die mit Nvidias Plänen vertraut sein sollen. Die Plattform soll es Unternehmen ermöglichen, KI-Agenten einzusetzen, die Aufgaben für die eigene Belegschaft übernehmen.
Da es sich um ein Open-Source-Projekt handeln soll, wird der Code nicht nur Unternehmen zur Verfügung stehen. Nvidia will Unternehmenspartnern jedoch zusätzliche Werkzeuge für Sicherheit und Datenschutz bereitstellen, um zentrale Risiken beim Einsatz autonomer KI-Agenten zu reduzieren. Außerdem könnten sie laut Bericht frühzeitig und kostenlos Zugang zu „NemoClaw“ erhalten, wenn sie sich an der Entwicklung beteiligen.
Der Chiphersteller habe „NemoClaw“ bereits bei verschiedenen großen Softwareanbietern beworben. Der Wired-Bericht [2] nennt Salesforce, Cisco, Google, Adobe und CrowdStrike als mögliche Partner. Ob aus den Gesprächen konkrete Kooperationen hervorgegangen sind, sei allerdings noch unklar.
Strategische Öffnung bei Nvidia?
Dem Bericht zufolge sei es wahrscheinlich, dass mögliche Partner die Plattform unabhängig davon nutzen können, ob ihre KI-Agenten auf Nvidia-Chips laufen.
Der Verzicht auf eine Bindung an Nvidia-GPUs ist eher ungewöhnlich für Nvidia. Bisher stützte sich das Softwareökosystem des Konzerns stark auf die proprietäre Plattform CUDA, die Entwickler faktisch an Nvidia-Hardware bindet und dem Unternehmen einen wichtigen Wettbewerbsvorteil verschafft hat.
Der Open-Source-Ansatz ist ebenfalls bemerkenswert, auch wenn es dafür bereits Beispiele gibt: So veröffentlichte Nvidia im Dezember mit Nemotron 3 Nano [3] ein KI-Modell, das fast vollständig Open Source ist.
„NemoClaw“ könnte ein weiterer Schritt in Richtung Öffnung sein, der womöglich durch den zunehmenden Erfolg offener KI-Modelle motiviert ist. Viele Start-ups und Entwickler nutzen solche frei verfügbaren Modelle, um neue Anwendungen zu testen oder eigene Produkte darauf aufzubauen.
Hinzu kommt, dass große KI-Anbieter zunehmend eigene Chips entwickeln oder entwickeln lassen, um sich langfristig unabhängiger von Nvidia zu machen. In dieses Bild passt auch Nvidias Partnerschaft mit dem Start-up Groq [4], das sogenannte Inferenz-Chips entwickelt. Diese sind weniger für das Training von KI-Modellen gedacht, als dafür, bereits trainierte KI im Alltag möglichst schnell und energieeffizient antworten zu lassen.
Das Wall Street Journal berichtete [5] kürzlich, dass Nvidia auf der kommenden Entwicklerkonferenz GTC einen eigenen Inferenz-Chip auf Basis eines Groq-Designs vorstellen könnte. Womöglich gibt es dann auch Konkretes zu „NemoClaw“ zu erfahren. Die Konferenz findet vom 16. bis 19. März in San José statt.
OpenClaw zeigt Chancen und Risiken autonomer KI-Agenten
Der KI-Agent OpenClaw sorgte Anfang des Jahres für große Aufmerksamkeit in der KI-Szene. Das Open-Source-Projekt des Entwicklers Peter Steinberger unterscheidet sich deutlich von klassischen KI-Chatbots, die meist nur auf einzelne Eingaben reagieren und Antworten generieren. Der auf einem lokalen Rechner laufende OpenClaw kann dagegen mehrstufige Aufgaben selbstständig ausführen und dabei verschiedene Programme oder Online-Dienste steuern.
Streit um MariaDB: Community setzt sich gegen das Unternehmen durch
Von Heise — 11. März 2026 um 12:26
(Bild: Chitraporn Nakorn / Shutterstock.com)
Nach massiver Kritik der Community hat MariaDB die geplante Entfernung der Galera-Clustering-Technologie aus dem Community-Server zurückgenommen.
Nach Protesten der Open-Source-Community hat das Unternehmen MariaDB plc die geplante Entfernung der Galera-Clustering-Technologie aus dem Community-Server von MariaDB zurückgenommen. Die Open-Source-Hochverfügbarkeit bleibt damit in Version 12.3 enthalten, Alternativen dazu hätte es nur in den kommerziellen Angeboten gegeben.
Wie Max Mether, Vice President, Server Product Management der Firma, in einem Blogbeitrag [1] erklärte, ist das Feedback der Community „ein wichtiger Bestandteil von MariaDB, und kürzlich habt ihr euch zur Aufnahme von Galera Cluster in die Version 12.3 geäußert“. Nach sorgfältiger Prüfung habe man daraufhin entschieden, die Galera-Cluster-Bibliotheken in unveränderter Form mit dem Community-Server weiterhin auszuliefern.
Galera-Dependencies aus dem MariaDB-Server ohne Vorwarnung entfernt
Anfang Februar 2026 war bekannt geworden, dass MariaDB offenbar plante, die unter GPLv2 lizenzierte Galera-Technik aus künftigen Versionen des Community-Servers zu entfernen. Federico Razzoli, Gründer des Datenbankdienstleisters Vettabase – einem Silber-Sponsor der MariaDB Foundation –, hatte unter Berufung auf einschlägige Diskussionen bei GitHub [2] auf LinkedIn öffentlich dokumentiert [3], dass Galera-Abhängigkeiten bereits ohne Commit-Meldungen oder Aufgabenbeschreibungen aus den Binärdateien entfernt worden waren. Die Kritik verbreitete sich schnell in der Community. Besonders einflussreich für das Umdenken des Unternehmens waren laut MariaDB die Rückmeldungen von Frédéric (lefred) Descamps (Community Advocate der MariaDB Foundation) und René Bonvanie (Board Member der MariaDB Foundation).
Galera ermöglicht synchrone Multi-Master-Replikation für MariaDB-Datenbanken. Dabei fungieren mehrere Server als gleichberechtigte Knoten in einem Cluster, wobei jeder Knoten Schreibvorgänge akzeptieren und automatisch an andere Knoten replizieren kann. Die Technik gilt als essenziell für hochverfügbare Produktionsumgebungen. Nachdem MariaDB die Galera-Technik von Codership bereits erstmals 2013 integriert [4] hatte, entschlossen sich die Verantwortlichen im Mai 2025, das Entwicklerunternehmen Codership Oy komplett zu übernehmen [5].
Foundation bestätigt Dialog
Die MariaDB Foundation bestätigte in einem eigenen Blogbeitrag [6], dass es einen offenen Dialog zwischen Foundation und Unternehmen gegeben habe. Kaj Arnö, Executive Chairman der Foundation, charakterisierte die Zusammenarbeit [7] als von „gegenseitigem Respekt und einem gemeinsamen langfristigen Interesse am MariaDB-Ökosystem“ geprägt. Unklar bleibt jedoch, wie die weitere Zukunft für die Galera-Entwicklung als Teil von MariaDB aussehen kann und ob die Community Edition weiterhin Galera-Updates erhalten wird.
Denn wie Max Mether in seinem Blogbeitrag auch unmissverständlich deutlich macht, verfolgt das Unternehmen mehrere Wege, Anwenderinnen und Anwendern Funktionen für die Hochverfügbarkeit bereitzustellen. Neben Galera im Community-Server sind dies vor allem der auf Galera aufbauende MariaDB Enterprise Cluster [8] sowie der als Tech Preview verfügbare MariaDB Advanced Cluster [9], der das Raft-Protokoll verwendet, um verbesserte Skalierbarkeit und Datenkonsistenz auch über geografische Regionen hinweg zu gewährleisten. Beide Versionen stehen ausschließlich als kommerzielle Angebote von MariaDB zur Verfügung.
Während sich die MariaDB Foundation vor diesem Hintergrund weiter für eine vertrauensvolle Nutzung von Galera durch die Community einsetze, stellt die offizielle Erklärung von CEO Anna Widenius im Blog der Foundation aber auch klar, dass Entscheidungen über die zukünftige Entwicklung und Zuweisung von technischen Ressourcen allein in der Verantwortung von MariaDB plc liegen. Als Eigentümer von Galera kontrolliere das Unternehmen sowohl dessen Roadmap und die Namensgebung als auch die dahinterstehenden Entwicklungsressourcen.
Vertrauensfrage bleibt
Die Affäre offenbart einmal mehr strukturelle Spannungen zwischen den kommerziellen Interessen von MariaDB plc und den Open-Source-Idealen der Foundation. Razzoli forderte öffentlich, MariaDB plc solle auf seiner Website zusichern, dass die Open-Source-Software offen bleibe. Die Sorge: Das Unternehmen könnte Funktionen aus der freien Version entfernen, um Nutzer zu proprietären Angeboten zu bewegen.
MariaDB hat in den vergangenen Jahren turbulente Zeiten hinter sich. Nach einem SPAC-gestützten Börsengang Ende 2022 folgten Entlassungen, Warnungen zur Unternehmensfortführung und ein Kursverfall. Im Dezember 2023 gliederte das Unternehmen seinen DBaaS-Dienst SkySQL aus und wurde selbst im September 2024 privatisiert und holte SkySQL Mitte 2025 wieder zurück. Kaj Arnö hatte nach der Privatisierung erklärt, dass „Vernunft“ in die Beziehung zwischen Community und Unternehmen zurückgekehrt sei. Die Galera-Kontroverse zeigt jedoch, dass das Vertrauen weiterhin fragil ist – und dass die Community bereit ist, sich lautstark für den Erhalt offener Technologien einzusetzen.
Core Ultra 7 270K Plus: Intel stellt 24-Kern-Prozessor gegen AMDs Achtkerner
Von Heise — 11. März 2026 um 16:44
Zwei Prozessoren leiten Intels Arrow Lake Refresh ein. Sie kommen mit zusätzlichen Kernen und flotterer Chiplet-Verbindung.
Intel bringt nun doch verbesserte Desktop-Prozessoren in Form von Arrow Lake Refresh. Den Anfang machen die zwei Modelle Core Ultra 7 270K Plus und Core Ultra 5 250K Plus. Der Hersteller legt keine neuen Chiplets auf, lässt in den vorhandenen aber mehr Kerne aktiv, die bislang teureren Modellen vorbehalten waren.
Das dürfte auch der Grund sein, warum es kein neues Topmodell wie den zuvor kolportierten Core Ultra 9 290K gibt. An der Spitze gibt es schlicht zu wenig Spielraum für eine Beschleunigung. Untenrum sollen hingegen weitere Neuauflagen folgen, auch günstigere F-Versionen ohne Grafikeinheit.
Intel spendiert den zwei Neuvorstellungen je vier zusätzliche Effizienzkerne. Der Core Ultra 7 270K Plus rückt damit nahe an das Topmodell Core Ultra 9 285K. Beide verwenden den Vollausbau mit insgesamt 24 CPU-Kernen (acht Performance- + 16 Effizienzkerne) und 36 MByte Level-3-Cache. Der Core Ultra 7 270K Plus taktet in der Spitze bloß 200 MHz langsamer.
Verbesserungen der neuen Plus-Prozessoren gegenüber bisherigen Intel-Modellen.
(Bild: Intel)
Die Datenverbindung zwischen den Chiplets (Die-to-Die-Taktfrequenz) beschleunigt Intel nominell von 2,1 auf 3,0 GHz. Im Gegensatz zu Intels Übertakterprofil 200S Boost [1] ist dafür kein teures Z890-Mainboard notwendig. Wer aber ein solches verwendet, kann den 200S Boost weiterhin aktivieren und kommt so auf 3,2 GHz Die-to-Die-Taktfrequenz.
Speicherseitig steigt die offiziell freigegebene Grenze von DDR5-6400 auf DDR5-7200. Bei der aktuellen Speicherkrise [2] dürfte das allerdings kaum relevant sein.
Preis-Leistungs-Empfehlung in der Mittelklasse
Unterm Strich dürfte der Core Ultra 7 270K Plus kaum noch langsamer sein als der Core Ultra 9 285K. Mit einer deutlich niedrigeren Preisempfehlung erscheint das Plus-Modell jedoch wesentlich attraktiver: 299 US-Dollar nennt Intel, umgerechnet inklusive Steuern (in US-Preisen nicht enthalten) etwa 310 Euro. Interessierte sparen gegenüber dem 285K (ab 477,99 €) [3] gut ein Drittel des Kaufpreises.
Intel startet den Verkauf des Core Ultra 7 270K Plus und Core Ultra 5 250K Plus am 26. März 2026. Bis dahin erscheinen auch die Testberichte zu den Prozessoren.
Spezifikationen Core Ultra 200S Plus
Modell
Kerne / Threads
Basistakt / max. Turbo
L3-Cache
PBP / MTP
Core Ultra 9 285K
8P+16E / 24
3,7 / 5,7 GHz
36 MByte
125 / 250 W
Core Ultra 7 270K Plus
8P+16E / 24
3,7 / 5,5 GHz
36 MByte
125 / 250 W
Core Ultra 7 265K
8P+12E / 20
3,9 / 5,5 GHz
30 MByte
125 / 250 W
Core Ultra 5 250K Plus
6P+12E / 18
4,2 / 5,3 GHz
28 MByte
125 / 159 W
Core Ultra 5 245K
6P+8E / 14
4,2 / 5,2 GHz
24 MByte
125 / 159 W
URL dieses Artikels: https://www.heise.de/-11207603
Pentagon-Drohnenboom: Wie Trumps Söhne vom Rüstungsprogramm profitieren
Von Thomas Pany — 11. März 2026 um 14:30
US-Präsident Donald Trump und seine Söhne Don Jr. und Eric. Bild: Shutterstock.com
Das Pentagon investiert Milliarden in Drohnen. Gleichzeitig steigen Donald Trump Jr. und Eric Trump bei Herstellern ein – mit Aussicht auf lukrative Aufträge.
Unlängst wurde an dieser Stelle– anlehnend an eine Analyse des französischen Ökonomen Thomas Piketty – die zugespitzte Frage gestellt, ob Krieg ein Geschäftsmodell der US-Regierung sein könnte.
Das ist im Fall des Iran-Krieges nicht leicht zu beantworten, weil komplexe wirtschaftliche Auswirkungen des völkerrechtswidrigen Angriffs der USA und Israels auf den Iran die Sache nicht auf einen einfachen Reim bringen lassen.
In diesem Zusammenhang ist ein weiterer Artikel, der aktuell bei Le Monde [1] erscheint, von Interesse. Dort geht es um Investitionen von zwei Söhnen des US-Präsidenten. Siepositionieren sich durch gezielte Beteiligungen, um vom Drohnen-Boom zu profitieren. Dies wirft Fragen nach möglichen Interessenskonflikten auf.
Im November 2024 wurde bekannt, dass Donald Trump Jr. als Berater beim Drohnenkomponenten-Hersteller Unusual Machines mit Sitz in Orlando, Florida, fungieren würde. Das Unternehmen stellte ihm dafür kostenlos Aktien in Aussicht.
Bereits vor der öffentlichen Bekanntgabe dieser Personalie schoss der Aktienkurs des Unternehmens in die Höhe. Trump Jr. erzielte damit, wie der Bericht von Le Monde [2] vorrechnet, offenbar einen außerordentlichen Buchgewinn:
"Laut einer Analyse der Financial Times vom April 2025 hatten sich die Aktien des Drohnenkomponentenherstellers Unusual Machines im Monat vor der Bekanntgabe vom 27. November 2024, dass Don Jr. als Berater verpflichtet worden war, nahezu verdreifacht.
Der Präsidentensohn hatte kostenlos 200.000 Aktien erhalten und weitere 131.000 zum Preis von 1,52 Dollar pro Stück erworben. Da der Kurs derzeit bei 17,28 Dollar liegt, wäre seine Beteiligung – sofern er sie nicht verkauft hat – 5,7 Millionen Dollar wert, also ein Buchgewinn von etwa 5,5 Millionen Dollar."
Ein Jahr nach dem Einstieg von Don Jr. als Berater, also Ende 2025, erhielt Unusual Machines laut Bericht der französischen Zeitung einen Pentagon‑Auftrag zur Herstellung von 3.500 Drohnenmotoren. Der zeitliche Zusammenhang lässt aufhorchen.
Zumal noch andere Investments in US-Waffenproduktion aus der Trump-Familie auffallen.
Namhafte Investoren, Merger und Börsengänge
So sind die beiden Söhne des US-amerikanischen Präsidenten, Eric und Donald Jr., "namhafte Investoren“ (DefenseNews [4]) eines neu gegründeten Unternehmens, das autonome Drohnen für das US-Militär herstellen will.
Die Rede ist von Aureus Greenway Holdings Inc., einer Holdinggesellschaft für Golfplätze, die mit dem Drohnenhersteller Powerus Corporation fusioniert hat.
Sollte dieses Unternehmen Aufträge vom US‑Verteidigungsministerium erhalten, so wäre man – wohl nicht nur bei Le Monde – wenig überrascht. Die Zeitung bleibt in ihrer Formulierung zurückhaltend. Man spricht von einer Möglichkeit: Es könnte so kommen.
Der Möglichkeitsraum dazu sieht wie folgt aus.
Dank der in den letzten Monaten erworbenen (100-prozentigen) Tochtergesellschaften – Kaizen Aerospace, Tandem Defense und Agile Autonomy – stellt Powerus Spezialdrohnen her, die, so Le Monde, für "Schwerlasttransporte (über 500 Kilogramm), taktische Verteidigung und maritime Überwachungssysteme ausgelegt sind".
"Das US-Verteidigungsministerium erhöht seine Drohnenkäufe massiv. Im Rahmen einer Initiative im Umfang von 1,1 Milliarden Dollar will das Pentagon die Drohnenbeschaffung stärken und die amerikanische Drohnenproduktion ausbauen."
"Anfang Februar ernannte das US‑Verteidigungsministerium Xtend zu einem der 25 Unternehmen, die eingeladen wurden, an der ersten Phase seines ‚Drone Dominance Program teilzunehmen – einer Beschaffungskampagne, die bis 2027 ein Gesamtvolumen von 1,1 Milliarden Dollar erreichen dürfte."
Die Trump-Regierung hat mit der Executive Order "Unleashing American Drone Dominance [10]" einen politischen Rahmen geschaffen, der die heimische Drohnenindustrie massiv fördern soll. Die Anordnung zielt darauf ab, Rüstungsaufträge zu beschleunigen und US-amerikanischen Herstellern Vorteile zu verschaffen.
Parallel dazu haben US-Behörden ausländische Drohnenhersteller – insbesondere die chinesischen Marktführer DJI und Autel – faktisch vom US-amerikanischen Markt ausgeschlossen [11]. Diese Maßnahmen schaffen einen geschützten Binnenmarkt für US-Unternehmen.
Verdacht auf Interessenkonflikte
Die Investitionen der Präsidentensöhne in Unternehmen, die Pentagon-Aufträge anstreben oder bereits erhalten haben, werfen Fragen auf, die man im Falle von autokratischen Regimes, die Gegner des Westens sind, mit einiger Verve verfolgen würde.
Der Fall Unusual Machines zeigt ein auffälliges Muster: Der Sohn des Präsidenten wird Berater, erhält Gratis-Aktien, deren Wert stark steigt, und ein Jahr später fließt der erste Pentagon-Auftrag.
Die komplexen Firmenkonstruktionen – etwa die Fusion von Powerus mit einer Golfplatz-Firma oder die geplante Börseneinführung von Xtend – erschweren die Nachvollziehbarkeit der Geldflüsse.
Während die Trump-Regierung öffentlich die US-amerikanische Drohnenindustrie fördert und ausländische Konkurrenz ausschaltet, investiert die Präsidentenfamilie gezielt in genau jene Unternehmen, die von diesen politischen Entscheidungen profitieren.
URL dieses Artikels: https://www.heise.de/-11207385
Steinzeitliche Jäger und Sammler kombinierten Pflanzen und Fisch nach festen Mustern. Keramik-Überreste belegen vielfältige Kochtraditionen vor 8000 Jahren.
Jäger und Sammler, die zwischen 6.000 und 3.000 v. u.Z. in Nord- und Osteuropa lebten, bereiteten offenbar weitaus vielfältigere Mahlzeiten zu als bislang angenommen. Sie wählten bestimmte Pflanzen gezielt aus und kombinierten diese mit spezifischen tierischen Zutaten – ein Verhalten, das auf echte kulinarische Traditionen hindeutet.
Das ist das zentrale Ergebnis einer am 4. März im Fachjournal PLOS Oneveröffentlichten Studie [1] eines internationalen Forschungsteams unter der Leitung von Lara González Carretero, Archäobotanikerin an der University of York in England.
"Wir glauben, dass diese kulinarischen Traditionen sehr weit in die Vergangenheit zurückreichen", sagte González Carretero. Bisher ging die Forschung davon aus, dass sich Elemente einer echten Küche – also die bewusste Zubereitung bestimmter Speisekombinationen – erst mit dem Beginn von Ackerbau und Viehzucht entwickelten. "Das geschah möglicherweise viel früher als gedacht", so die Forscherin.
Verkohlte Krusten als Fenster in die Vergangenheit
Für die Studie untersuchte das Team 85 Keramikscherben mit anhaftenden Speiseresten von 13 archäologischen Fundstätten, die sich von Russland bis nach Süddänemark erstrecken. Diese sogenannten "Foodcrusts" – verkohlte Essensrückstände, die an Töpfen haften bleiben – entstehen, wenn Menschen in Gefäßen kochen, ohne sie anschließend zu reinigen. Selbst nach mehrfachem Verbrennen bleiben winzige Zellstrukturen der ursprünglichen Zutaten erhalten.
"Was wir sehen, sind die tatsächlichen Zellen und Gewebe, die sich bestimmten Pflanzen und auch bestimmten Tieren zuordnen lassen", erklärte González Carretero. Manchmal seien sogar Samen oder Früchte mit bloßem Auge erkennbar.
Die Methode kombiniert mehrere Analyseverfahren: Zunächst werden die Krusten mit Stereomikroskopen und digitalen Mikroskopen untersucht. Anschließend kommt ein Rasterelektronenmikroskop (SEM) zum Einsatz, das pflanzliche oder tierische Strukturen im Detail sichtbar macht.
Ergänzend dazu werden Lipide – also Fettmoleküle – chemisch analysiert. Dieser kombinierte Ansatz ist entscheidend, denn die bislang übliche reine Lipidanalyse bevorzugt den Nachweis tierischer Produkte. Pflanzen enthalten weniger Öle, Wachse und Fette, weshalb ihre chemischen Signale von den Verbindungen aus Fisch überlagert werden.
Pflanzen waren allgegenwärtig
In 58 der 85 untersuchten Keramikscherben konnten die Forscher pflanzliche Gewebereste identifizieren – darunter Wildgräser, Hülsenfrüchte, Beeren, Blätter, Wurzeln und Knollen. Die chemische Analyse der Lipide zeigte hingegen vorwiegend Spuren von Süßwasserfisch und Schalentieren; nur wenige Proben enthielten Marker für Hirschfett oder Milchprodukte.
"Das zeigt wirklich die Allgegenwärtigkeit von pflanzlicher Nahrung in dieser Jäger-und-Sammler-Keramik", sagte Dimitri Teetaert, Archäologe an der Universität Gent in Belgien, der nicht an der Studie beteiligt war. "Pflanzliche Nahrung war für alle diese Jäger-Sammler-Fischer-Gemeinschaften wichtig."
González Carretero betonte [2] gegenüber dem Magazin Discover, dass bisherige Studien eine Verzerrung zugunsten tierischer Produkte aufwiesen: "Pflanzen wurden aufgrund der Schwierigkeiten, ihren Zusammenhang mit der menschlichen Ernährung nachzuweisen, übersehen."
Regionale Rezepte statt wahllosem Sammeln
Obwohl viele der identifizierten Pflanzen in der gesamten Region verbreitet waren, zeigten sich deutliche regionale Unterschiede in den Zutatenkombinationen.
"Diese Nahrungsmittel wachsen wirklich überall und sind für viele Menschen verfügbar, aber es scheint, dass sie nur bestimmte davon auswählen, um sie in die Töpfe zu geben", sagte Oliver Craig, archäologischer Wissenschaftler an der University of York und Co-Autor der Studie.
An Fundstätten am Don in Russland fanden sich in den Töpfen Spuren von wilden Hülsenfrüchten und Gräsern, die mit Süßwasserfisch kombiniert worden waren.
An der Wolga und an einem Fundort in Polen hingegen wurden Schneeballbeeren (Viburnum opulus) zusammen mit Fisch gekocht. Am dänischen Fundort Syltholm II wiederum identifizierten die Forschenden Wurzeln und Knollen – möglicherweise von Meerstrandrüben – zusammen mit Pflanzenteilen der Amaranthaceae-Familie und Fisch.
Besonders überraschend war laut González Carretero die weitverbreitete Verwendung eben jener Schneeballbeeren. Diese Beeren sind roh leicht giftig und schmecken unangenehm. "Sie schmecken furchtbar und riechen nach nassen Socken", beschrieb die Forscherin.
Doch beim Kochen verändere sich der Geschmack: Allein gekocht blieben die Beeren bitter, in Kombination mit Fisch würden sie jedoch süßer und "recht angenehm". Noch heute stellen Menschen in Teilen Japans und Russlands eine Art Fischgelee mit Preiselbeeren oder Schneeballbeeren her. In Osteuropa, darunter Polen, der Ukraine und Russland, haben die Beeren bis heute kulturelle Relevanz.
Ebenfalls überraschend war der Nachweis von Pflanzengewebe der Amaranthaceae-Familie – einer Gruppe, zu der unter anderem Rüben und Gänsefuß gehören. "Die Anwesenheit dieser Pflanzen als Teil von Speiserückständen ist der erste direkte Beleg für ihren Verzehr und ihre Rolle in der Ernährung vergangener Gemeinschaften", sagte González Carretero gegenüber Discover. Deren Nutzung als Nahrungsmittel war in der Archäobotanik lange umstritten.
Kochtradition und Keramikherstellung hängen zusammen
Die Ergebnisse deuten auch darauf hin, dass Kochtradition und Töpfertechnik miteinander verknüpft waren. Gefäße, die mit unterschiedlichen Herstellungstechniken gefertigt wurden, dienten offenbar der Zubereitung unterschiedlicher Speisen. Statistische Tests ergaben eine moderate, aber signifikante Korrelation zwischen Keramiktechnologie und kulinarischer Nutzung – auch dann, wenn der Einfluss des Standorts herausgerechnet wurde.
Diese Erkenntnis wirft auch ein neues Licht auf die Frage, warum Jäger und Sammler überhaupt begannen, Keramik herzustellen. Die Studie widerlegt laut den Autoren die These, dass die Töpfe vorwiegend zur Verarbeitung von Fischölen für nicht-kulinarische Zwecke wie Brennstoffe oder Dichtungsmittel dienten. Stattdessen zeigen die Speisereste, dass die Gefäße tatsächlich zum Kochen von Mahlzeiten verwendet wurden.
"Die gewählten Mischungen erzeugten wahrscheinlich neue Aromen und Texturen, die ohne Keramiktechnologie nicht verfügbar gewesen wären", sagte Teetaert. "Das könnte ein wichtiger Anreiz für die Übernahme der Töpfertechnologie gewesen sein."
Kontinuität über Jahrtausende
Die Studie zeigt auch, dass viele dieser wilden Nahrungsmittel selbst in der späteren Jungsteinzeit, als Menschen begannen, Pflanzen anzubauen und Tiere zu domestizieren, weiterhin genutzt wurden. "Sie haben nicht plötzlich Gerste, Weizen und Nutztiere gegen ihre wilden Nahrungsmittel eingetauscht", sagte González Carretero.
Jäger und Sammler hätten etabliertere Esstraditionen gehabt, als man gemeinhin annehme.
Das Forschungsteam plant, die Untersuchungen auf ein größeres geografisches Gebiet und einen längeren Zeitraum auszuweiten. Zudem soll erforscht werden, ob Umweltveränderungen die Kochgewohnheiten beeinflussten.
Die Autoren betonen, dass die Kombination aus Mikroskopie und chemischer Analyse künftig zum Standard werden sollte: "Ohne Pflanzen kennen wir die gesamte Ernährung und Esskultur dieser Menschen nicht wirklich", so González Carretero.
URL dieses Artikels: https://www.heise.de/-11207089
Links in diesem Artikel: [1] https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0342740 [2] https://www.discovermagazine.com/charred-food-in-ancient-pots-reveals-surprisingly-complex-prehistoric-european-cuisine-48772
OpenClaw automatisiert Büroaufgaben – doch China schränkt die Nutzung ein. Sicherheitsexperten warnen vor der "tödlichen Dreifaltigkeit".
Die Chinesen sind begeistert von Technologie – und so ist es nicht verwunderlich, dass die KI-Software OpenClaw bei ihnen reichlich Anklang gefunden hat. Schließlich verspricht sie einen erheblichen Nutzen, wenn sie über KI-Agenten Kalender verwalten, E-Mails senden und selbständig Themen recherchieren kann.
Doch sie weckt auch Zweifel, ob sie sicher ist, und deshalb hat die chinesische Regierung jetzt die Nutzung von OpenClaw in Behörden und staatlichen Stellen eingeschränkt.
Das Problem ist, was Experten als "tödliche Dreifaltigkeit" im digitalen Zeitalter nennen: eine Software, die autonom auf Daten zugreift, die Entscheidungen trifft, und die nach außen kommuniziert.
Staatliche Banken und Behörden erhalten Warnungen
Wie Bloombergberichtet [1], erhielten Behörden und staatliche Unternehmen, darunter Chinas größte Banken, in den vergangenen Tagen interne Warnungen. Sie wurden aufgefordert, keine OpenClaw-Software auf ihren Bürogeräten zu installieren.
Mitarbeiter, die das Tool bereits installiert hatten, mussten dies ihren Vorgesetzten melden, damit die Software auf Sicherheitsrisiken geprüft und gegebenenfalls entfernt werden konnte.
Bestimmten Beschäftigten staatlicher Banken untersagten die Behörden die Installation sogar auf privaten Mobiltelefonen, sofern diese das Firmennetzwerk nutzen. Für Familienangehörige von Militärangehörigen gelte das Verbot ebenfalls, so eine der Quellen, auf die sich Bloomberg beruft.
Das „tödliche Dreigespann" der Sicherheitsrisiken
OpenClaw funktioniert als autonomer KI-Agent, der Posteingänge leert, Kalender verwaltet, E-Mails versendet und eigenständig Recherchen durchführt.
Der vom österreichischen Entwickler Peter Steinberger geschaffene Open-Source-Assistent lässt sich auch mit Messaging-Diensten wie Slack oder WhatsApp verbinden. Genau darin sehen Experten für Cybersicherheit das Problem.
Kasimir Schulz, Direktor für Sicherheitsforschung beim KI-Sicherheitsunternehmen HiddenLayer, erklärte gegenüber [2]Bloomberg, die Software erfülle die Kriterien der "tödlichen Dreifaltigkeit": OpenClaw greift auf private Daten zu, kommuniziert nach außen und kommt mit nicht vertrauenswürdigen Inhalten in Berührung.
Ein konkreter Fall verdeutlicht die Risiken: Ein Nutzer berichtete, der Agent habe nach Zugriff auf iMessage über 500 Spam-Nachrichten an ihn, seine Ehefrau und an zufällige Kontakte verschickt.
Zudem warnen Forscher vor sogenannten Prompt-Injektionen, bei denen Angreifer bösartige Befehle als legitime Eingaben tarnen und so persönliche Daten stehlen können.
Steinberger selbst räumte ein, dass keine „vollkommen sichere" Konfiguration existiere und das Projekt sich an „technisch versierte Menschen" richte, „die die inhärenten Risiken von LLMs verstehen".
Tech-Konzerne setzen trotzdem auf OpenClaw
Trotz der Sicherheitsbedenken integrieren Chinas Tech-Giganten OpenClaw in ihre Produktpaletten. Tencent brachte mit Workbuddy ein Tool auf den Markt, das auf chinesische Büro- und Kommunikationsanwendungen zugreift, schreibt das [3]Wall Street Journal (WSJ).
ByteDance bietet mit ArkClaw eine cloudbasierte Variante an, die keine Installation erfordert. Alibaba entwickelte CoPaw für Messaging-Dienste wie DingTalk und Feishu.
Die Aktien des KI-Start-ups MiniMax stiegen seit dem Börsengang um fast 640 Prozent auf einen Marktwert von rund 49 Milliarden US-Dollar – befeuert durch die Veröffentlichung des eigenen Agenten MaxClaw.
Lokale Subventionen stehen im Widerspruch zum Verbot
Während die Zentralregierung in Peking die Nutzung einschränkt, fördern lokale Regierungen die Technologie aktiv. Der Bezirk Longgang in Shenzhen veröffentlichte einen Richtlinienentwurf, der kostenlose OpenClaw-Bereitstellungsdienste und Subventionen für die Entwicklung von Anwendungen vorsieht, so das WSJ.
Der Hightech-Bezirk Wuxi in der Provinz Jiangsu kündigte demnach Zuschüsse von bis zu fünf Millionen Yuan (rund 724.000 US-Dollar) für die industrielle Nutzung an.
Dieser Widerspruch spiegelt ein grundsätzliches Dilemma wider: Chinas Zentralregierung betrachtet unkontrollierte Datenzugriffe als Bedrohung der nationalen Sicherheit, während die Provinzen im internationalen KI-Wettbewerb nicht zurückfallen wollen.
Für Büroangestellte, die OpenClaw als „digitalen Mitarbeiter" schätzen, bleibt die entscheidende Frage offen: Wie lassen sich die Produktivitätsgewinne autonomer KI-Agenten nutzen, ohne die Kontrolle über sensible Daten zu verlieren?
URL dieses Artikels: https://www.heise.de/-11207219
Links in diesem Artikel: [1] https://www.bloomberg.com/news/articles/2026-03-11/china-moves-to-limit-use-of-openclaw-ai-at-banks-government-agencies [2] https://www.bloomberg.com/news/articles/2026-02-04/openclaw-s-an-ai-sensation-but-its-security-a-work-in-progress [3] https://www.wsj.com/tech/ai/chinas-openclaw-craze-buoys-tech-stocks-fuels-ai-pivot-f529bf4e
Bytedance-Apps aus China in den USA nur noch per VPN zugänglich
Von Heise — 11. März 2026 um 12:19
Smartphone mit TikTok-Logo vor chinesischer Flagge.
(Bild: Boumen Japet / Shutterstock.com)
Der TikTok-Verkauf an ein US-Konsortium ist durch. Eine Art Geoblocking verhindert nun für amerikanische Bürger den Download chinesischer Apps.
Apple ermöglicht es US-Bürgern nicht mehr, auf chinesische ByteDance-Apps zuzugreifen. Offenbar wurde die Entscheidung im Rahmen der Übernahme der US-Version von TikTok [1] durch amerikanische Investoren getroffen, berichtet [2] das Technik-Magazin Wired. Störend ist das offenbar auch für chinesische Nutzer: Diese können ihre Apps von ByteDance nicht aktualisieren, wenn sie sich innerhalb der USA befinden.
Vorher ging es ohne VPN
Laut dem Bericht war es bislang möglich, unter anderem Douyin, die chinesische Variante von TikTok, in den USA herunterzuladen oder zu aktualisieren. Einzige Voraussetzung war ein App-Store-Account, der in China registriert ist. Üblicherweise legt Apple Länderbeschränkungen anhand der Herkunft des App-Store-Accounts fest. Für ByteDance-Apps gilt das zumindest auf US-Gebiet offenbar nicht mehr: Man benötigt nun ein VPN (offenbar für China), um den Download anzustoßen. In den USA heißt es bei Download- und Update-Versuchen, dass die App „in dem Land oder der Region, in der Sie sich befinden, nicht verfügbar“ sei.
Weder Apple noch ByteDance kommentierten den Bericht. Denkbar ist, dass Apple versucht, sich an US-Recht zu halten. Der sogenannte Protecting Americans from Foreign Adversary Controlled Applications Act verbietet explizit Apps, die mehrheitlich von ByteDance kontrolliert werden. Die US-Variante von TikTok wird vom Joint Venture TikTok USDS betrieben, hinter dem unter anderem Investoren und Oracle stecken. ByteDance hält noch einen Anteil von 15 Prozent.
Die amerikanische Firewall
Üblicherweise nutzen chinesische User ein VPN, um Zugriff auf westliche Apps zu erhalten, die dank der „großen Firewall“ innerhalb der Volksrepublik gesperrt sind. In den USA ist es nun bei ByteDance-Apps andersherum. Neben Douyin sind auch Apps wie Doubao (KI-Chatbot) und die Romanleseplattform Fanqie Novel nicht mehr zugänglich.
Im vergangenen Jahr hatte Apple noch ein Supportdokument auf seiner Website, in dem erklärt wurde, warum TikTok und andere ByteDance-Apps aus dem Store verschwunden [3] waren – allerdings in der US-Version. Mittlerweile sind TikTok (die US-Version), CapCut (Schnittprogramm) und die Social-Media-Plattform Lemon8 im amerikanischen App Store wieder zugänglich. Dass der chinesische App Store auf US-Gebiet teilweise blockiert wird, ist eine neue Entwicklung.
URL dieses Artikels: https://www.heise.de/-11205594
Links in diesem Artikel: [1] https://www.heise.de/news/TikTok-USA-Behoerdliche-Genehmigungen-fuer-Verkauf-sollen-fertig-sein-11151264.html [2] https://www.wired.com/story/bytedance-apps-are-no-longer-available-in-us-app-stores/ [3] https://www.heise.de/news/TikTok-Bann-in-den-USA-Warum-Apple-und-Google-die-App-nicht-wieder-aufnehmen-10254290.html [4] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html [5] https://www.heise.de/mac-and-i [6] mailto:bsc@heise.de
Apple-Hardwarechef zu CEO-Spekulationen: „Liebe den Job, den ich habe“
Von Heise — 11. März 2026 um 12:00
(Bild: Apple)
Im Rahmen der Vorstellung des MacBook Neo gab Apples oberster Hardware-Verantwortlicher auch ein Interview. Zu einer zentralen Frage blieb er wortkarg.
John Ternus, Apples Senior Vice President of Hardware Engineering, und damit oberster Hardware-Chef des Konzerns, hat erstmals zu Spekulationen Stellung bezogen, dass ihm der CEO-Posten beim iPhone-Hersteller angetragen [1] werden soll. In einem TV-Interview anlässlich des Erscheinens des MacBook Neo [2] sagte er, die gute Nachricht sei, dass er den Job liebe, den er bereits habe.
Die tollsten Leute der Welt
„Ich darf mit den tollsten Leuten der Welt zusammenarbeiten, und an Tagen wie heute, an denen wir all diese Produkte vorgestellt haben, ist das der beste Ort, an dem man sein kann“, so Ternus gegenüber dem US-Sender ABC [3]. Auf die direkte Frage nach einem möglichen neuen Job ging er erwartungsgemäß nicht ein. Schon seit dem vergangenen Jahr hatte die Gerüchteküche immer wieder behauptet, Tim Cook stehe vor einem baldigen Abtritt.
In einem großen Artikel der Financial Times hieß es gar, der aktuelle CEO werde zwischen Januar und Juni 2026 den Posten verlassen [4]. Andere Medien ruderten dann allerdings zurück [5]. Geplant war demnach angeblich, dass er danach zum Chairman of the Board, also dem Verwaltungsratsvorsitzenden, wird, um seinen Nachfolger bei der Arbeit zu unterstützen. Cook war im vergangenen Jahr 65 Jahre alt geworden und füllt die CEO-Rolle im August seit 15 Jahren aus. Ternus ist Jahrgang 1975, also 50.
Über Apple Intelligence nicht nachdenken
In dem ABC-Interview wurde Ternus auch über ein aktuelles Problem bei Apple befragt: den Rückstand im KI-Bereich [6], den das Unternehmen mit Hilfe von Googles Gemini einholen will. Er denke, Apple Intelligence werde „wachsen“ und die Dinge künftig „besser und einfacher“ machen. Ternus' Idee von KI ist demnach, dass man sie am besten gar nicht bemerke oder die User nicht darüber nachdenken müssten. „Die haben dann einfach eine neue Funktion, die sie mehr und mehr nutzen werden, weil sie ihnen wirklich gut gefällt.“
Ternus zufolge ist Apple stets darauf konzentriert, den Kunden die richtige Nutzererfahrung zu liefern. Wann das bei Apple Intelligence der Fall sein wird, bleibt unklar. Derzeit soll es noch innerhalb von iOS 26 erste Verbesserungen für Siri geben, doch einen echten KI-Durchbruch erwarten Beobachter nicht vor iOS 27 [7] im Herbst.
URL dieses Artikels: https://www.heise.de/-11205590
MacBook Neo: SSD deutlich langsamer als beim M5, SoC hinter iPhone 17e
Von Heise — 11. März 2026 um 10:51
MacBook Neo im Farbton Rosa alias „Blush“: Ja, es ist nicht das schnellste.
(Bild: Apple)
Erste Tests des neuen Einsteiger-MacBooks zeigen, wo sich die Hardware platziert. Die Frage ist, ob Einschränkungen den Alltag tangieren.
Heute ist es soweit: Das MacBook Neo [1] geht in die Auslieferung bei Vorbestellern, außerdem kommt es in die Apple-Läden und den Einzelhandel. Das billigste macOS-Notebook aller Zeiten kommt mit einigen Kompromissen, wie unser Test des Macbook Neo [2] zeigt. Käufer müssen sich bewusst sein, dass sie zum Preis ab 699 Euro (799 Euro maximal mit 512 GByte statt 256 GByte und Touch-ID-Funktion) kein Topgerät erhalten. Das Gesamtpaket dürfte den Markt dennoch aufwirbeln [3].
Vergleiche mit anderen Macs – und Apples Einsteiger-Smartphone
Beispiel SSD: Insbesondere die Variante mit 256 GByte lahmt. Moderne Mac-SSDs wie etwa die im MacBook Air M5 [4] erreichen das vierfache Tempo, in einzelnen Benchmarks [5] sind sogar bis zu achtmal mehr Leistung drin (MacBook Pro M5 Max mit 4 TByte). Ein Test ergab, dass das MacBook Air mit M1 und 512 GByte doppelt so schnell lesen konnte. Allerdings liegen uns bislang noch keine Daten zur 512-GByte-Variante des Neo vor. Üblicherweise sind größere SSDs [6] schneller als kleinere, da Apple diese anders anbindet [7]. Ob das bei iPhone-Chips wie im Neo auch der Fall ist, muss sich noch zeigen.
Wenig überraschend ist außerdem, dass der Chip (SoC) im Neo bereits vom iPhone 17e [8], Apples aktuellem Einsteiger-Smartphone, überholt wird. Im Neo steckt ein A18 Pro, der dem im iPhone 16 Pro entspricht, abzüglich eines GPU-Kerns (5 statt 6). Im iPhone 17e spielt hingegen der neuere A19 aus dem iPhone 17. Im Geekbench-Vergleich kommt das 17e so auf einen Mehr-Kern-Score von bis zu 9541 [9], während das Neo leicht darunter liegt [10]. Auch beim Einzel-Kern-Test liegt das 17e mit gut 200 Punkten vor dem Neo.
Das MacBook Air M4 ist ein Tipp
Die Frage ist nun, was das für die Praxis bedeutet. Im Mac & i-Test des Neo zeigte sich, dass Apple mit dem Neo ein interessantes Notebook gelungen ist: Die Verarbeitung ist Apple-typisch hochwertig, der Bildschirm in der Einstiegsklasse konkurrenzlos. Andere Tester kamen im Alltag gut mit dem Gerät klar, nutzten es sogar für – relativ ruckelfreien – Videoschnitt.
Ein Tipp bleibt allerdings, sich auch das MacBook Air M4 anzusehen, das Apple nun in den Abverkauf [11] geschickt hat, im Handel aber noch recht gut zu kriegen ist. Die Hardware ist noch besser verarbeitet, genauso leicht, hat bessere Schnittstellen, Tastatur mit Hintergrundbeleuchtung und ist deutlich flotter. Der Preis [12]: Für das 256-GByte-Modell unter 900 Euro, die 512-GByte-Variante kostet unter 1000 Euro.
URL dieses Artikels: https://www.heise.de/-11206762
Adobe-Patchday: Schadcodeschmuggel in Reader, Illustrator und weiteren möglich
Von Heise — 11. März 2026 um 09:37
(Bild: heise medien)
Der März-Patchday von Adobe bringt Updates zum Schließen von Codeschmuggel-Lücken in Illustrator, Reader und weiteren Programmen.
Im März liefert Adobe am Patchday [1] Sicherheitsupdates für acht Programme. Sie schließen teils von Adobe als kritisch eingestufte Sicherheitslücken. Angreifer können dadurch etwa Schadcode einschmuggeln oder ihre Rechte ausweiten.
Die Patchday-Übersicht von Adobe [2] listet die acht Sicherheitsmitteilungen zu den einzelnen Produkten auf. In Adobe Commerce, Commerce B2B und Magento Open Source [3] schließen die Entwickler 19 Sicherheitslücken. Darunter sind mehrere Cross-Site-Scripting-Schwachstellen, von denen eine die Einstufung nach CVSS als kritisches Risiko nur knapp verpasst und die das Ausweiten der Rechte oder die Umgehung von Sicherheitsmaßnahmen ermöglichen. Insgesamt sechs davon stuft Adobe abweichend als kritische Bedrohung ein.
Ähnlich sieht es beim Illustrator aus [4]. Mehrere Schwachstellen erlauben das Einschleusen und Ausführen von beliebigem Code, fünf der sieben Lücken stuft Adobe als kritisch ein. In Acrobat DC, Acrobat Reader DC und Acrobat 2024 [5] klaffen drei Sicherheitslücken, von denen zwei Codeschmuggel erlauben und als kritisch eingestuft wurden. Wer den Substance 3D Stager [6] einsetzt, sollte die Updates zum Schließen der sechs als kritisch geltenden Sicherheitslücken anwenden, durch die Angreifer Schadcode einschmuggeln können.
Adobe: Weitere Updates schließen Sicherheitslücken
Aber auch im Adobe DNG Software Development Kit (SDK) [7] stopfen Softwareupdates teils kritische Lücken, in Adobe Premiere und Premiere Pro [8] gab es lediglich ein kritisches Leck abzudichten. Neun immer noch als „wichtig“ klassifizierte Sicherheitslücken bessert Adobe in Substance 3D Painter [9] aus. Im Adobe Experience Manager (AEM) schließen die Entwickler im März zudem 33 Cross-Site-Scripting-Sicherheitslecks, die jedoch lediglich einen CVSS-Wert von 5.4 erreichen. Adobe stuft die Lücken abweichend von der „mittleren“ Risikobewertung nach CVSS als „wichtig“ ein.
IT-Verantwortliche und Nutzer sowie Nutzerinnen der Adobe [10]-Software sollten die Aktualisierungen zeitnah anwenden. Im Februar hatte Adobe zum Patchday [11] Sicherheitslücken in neun Programmen geschlossen.
URL dieses Artikels: https://www.heise.de/-11206633
Microsoft Patchday: Zwei Zero-Days und insgesamt 83 neue Lücken gestopft
Von Heise — 11. März 2026 um 08:37
(Bild: heise medien)
Am März-Patchday hat Microsoft 83 neue Schwachstellen ausgebessert. Zwei sind Zero-Day-Lücken. Attackiert wurde wohl noch keine.
Im März 2026 hat Microsoft [1] Aktualisierungen für 83 neue Schwachstellen am Patchday [2] in petto. Bei zwei der Lücken handelt es sich um Zero-Day-Schwachstellen. Immerhin wurde bislang offenbar noch keine davon in Angriffen im Netz missbraucht.
Microsoft selbst listet alle Schwachstelleneinträge, die das Unternehmen am März-Patchday veröffentlicht hat, in einer Übersicht auf [3]. Davon stufen die Entwickler acht als kritische Bedrohung ein – zum Großteil abweichend von der oftmals deutlich niedrigeren Risikobewertung nach CVSS-Wert.
Microsoft kümmert sich um Zero-Day-Lücken
Informationen zu einer Schwachstelle im SQL-Server, die die Ausweitung der Rechte ermöglicht (CVE-2026-21262 [4], CVSS 8.8, Risiko „hoch“) sowie eine Denial-of-Service-Lücke in .Net (CVE-2026-26127 [5], CVSS 7.5, Risiko „hoch“) sind laut Microsoft bereits öffentlich verfügbar. Sie wurden jedoch noch nicht angegriffen und Microsoft schätzt die Lage so ein, dass deren Missbrauch unwahrscheinlich bleibt.
Als kritisches Risiko stufen die Entwickler aus Redmond Lücken in Microsofts „ACI Confidential Containers“ in Azure ein. Angreifer können dadurch ihre Rechte erhöhen oder unbefugt auf Informationen zugreifen (CVE-2026-23651 [6], CVE-2026-26124 [7], beides CVSS 6.7, Risiko „mittel“, sowie CVE-2026-26122 [8], CVSS 6.5, Risiko „mittel“); Kunden müssen nichts unternehmen, Microsoft hat die Fehler serverseitig korrigiert. Etwas skurril mutet eine Sicherheitslücke in Microsofts Device Pricing Program an, durch die Angreifer Schadcode aus dem Netz einschleusen und hätten ausführen können (CVE-2026-21536 [9], CVSS 9.8, Risiko „kritisch“). Dasselbe gilt für eine Lücke in Microsofts Payment Orchestrator Service (CVE-2026-26125 [10], CVSS 8.6, Risiko „hoch“). Die hat Microsoft ebenfalls serverseitig geschlossen und informiert lediglich der Transparenz halber darüber.
In Microsoft Office erlauben zwei Sicherheitslücken das Einschleusen von Code aus dem Netz, etwa mittels sorgsam präparierter Dokumente. Dazu genügt bereits die Anzeige im Vorschaufenster (CVE-2026-26110 [11], CVE-2026-26113 [12], CVSS 8.4, Risiko „hoch“). In Excel können bösartige Akteure die Sandbox des Copilot-Agent-Modus umgehen und dabei unbefugt Informationen ins Netz ausleiten. Es handelt sich um eine Zero-Click-Lücke (CVE-2026-26144 [13], CVSS 7.5, Risiko „hoch“).
Angreifer können den Windows-Druckerspooler mit manipulierten Netzwerkpaketen zur Ausführung von eingeschmuggeltem Schadcode bewegen. Dazu benötigen sie jedoch zumindest niedrige Berechtigungen auf dem Zielsystem (CVE-2026-23669 [14], CVSS 8.8, Risiko „hoch“). Am Ende listet Microsoft noch zehn Schwachstellen im Chromium-Projekt auf, die mit aktuellen Edge-Updates geschlossen werden. Die hat Google in Chrome bereits in der vergangenen Woche [15] ausgebessert. Die Updates für Windows bringen Secureboot-Zertifikatsaktualisierungen für mehr Geräte und etwa auch für Windows-10-Systeme mit.
Diverse weitere Sicherheitslücken betreffen zahlreiche Produkte und Dienste aus dem Microsoft-Portfolio. IT-Verantwortliche sollten daher die Microsoft-Übersicht durchsehen und in der eigenen Organisation eingesetzte, anfällige Produkte auf den aktuellen Stand bringen.
Im Februar hatte Microsoft am Patchday [16] mehrere Sicherheitslücken schließen müssen, die bereits im Internet attackiert wurden. Sechs der dort geschlossenen Sicherheitslücken haben Kriminelle bereits vor dem Patchday missbraucht.
URL dieses Artikels: https://www.heise.de/-11206553
Slow is smooth and smooth is fast: Was Softwareteams von den Navy SEALs lernen
Von Heise — 11. März 2026 um 09:00
(Bild: MP_P / Shutterstock.com)
Wer sich Zeit nimmt, ein Problem zu verstehen, bevor er es löst, ist am Ende schneller. Ein Erfahrungsbericht über einen kontraintuitiven Entwicklungsprozess.
Es gibt einen Spruch, der vor allem durch die Navy SEALs bekannt geworden ist:
„Slow is smooth and smooth is fast.“
Gemeint ist damit, dass übereiltes Handeln zu Fehlern führt, die am Ende mehr Zeit kosten als die vermeintlich gesparte. Wer hingegen ruhig und kontrolliert vorgeht, arbeitet präziser, macht weniger Fehler und erreicht das Ziel paradoxerweise früher. In Hochdrucksituationen, in denen Sekunden über Erfolg und Misserfolg entscheiden, mag das kontraintuitiv klingen. Doch genau dort hat sich dieses Prinzip bewährt.
In der Softwareentwicklung begegnet mir ein ähnliches Muster. Die Branche steht unter permanentem Zeitdruck, Deadlines sind eng, Anforderungen ändern sich laufend, und der Reflex, so schnell wie möglich Code zu schreiben, ist tief verankert. Fortschritt wird oft daran gemessen, wie schnell neuer Code entsteht. Doch gerade dieser Reflex führt häufig dazu, dass Projekte am Ende länger dauern als nötig. Die Parallele zu den Navy SEALs ist frappierend, und ich bin überzeugt, dass ihr Grundsatz einer der wertvollsten Ratschläge ist, den Softwareteams beherzigen können.
Wenn Geschwindigkeit zur Falle wird
Die Versuchung liegt auf der Hand: Ein neues Feature steht an, die Anforderungen scheinen klar, also öffnet man den Editor und beginnt zu tippen. Schließlich wird Software in Code gemessen, nicht in Whiteboard-Skizzen. Je früher Code entsteht, desto früher ist man fertig. So zumindest die gängige Annahme.
Die Realität zeichnet ein anderes Bild. Code, der ohne gründliche Vorüberlegung entsteht, basiert auf impliziten Annahmen. Jede und jeder im Team hat eine eigene Vorstellung davon, wie die Lösung funktionieren soll, aber diese Vorstellungen werden selten abgeglichen. Die Annahmen stellen sich oft erst spät als falsch heraus, etwa wenn sich zeigt, dass die gewählte Schnittstelle für die tatsächlichen Anwendungsfälle ungeeignet ist oder dass ein Sonderfall die gesamte Architektur infrage stellt. Was harmlos begann, wird zum strukturellen Problem.
Was dann folgt, sind Korrekturschleifen. Nicht eine, sondern mehrere. Dazu kommen Diskussionen, die man besser vorher geführt hätte, Refactorings, die im Grunde Neuschreibungen sind, und eine wachsende Menge an technischen Schulden. Der Code, der so schnell entstanden ist, muss erklärt, verteidigt und überarbeitet werden. Aus dem vermeintlich schnellen Start wird ein zähes, kostspieliges Nacharbeiten.
Das Tückische daran ist, dass dieser Effekt selten sichtbar wird. Niemand misst, wie viel Zeit ein Team mit Nacharbeit verbringt, die bei besserem Vorgehen vermeidbar gewesen wäre. Die Stunden versickern in Bugfixes, in „kleinen Anpassungen“ und in Meetings, in denen man klärt, was man vorher hätte klären sollen. Die anfängliche Geschwindigkeit war eine Illusion.
Ein Experiment zu zweit
Vor etlichen Jahren haben ein Kollege und ich einen Entwicklungsprozess etabliert, der von außen betrachtet geradezu verschwenderisch wirkte. Wann immer wir ein neues Modul oder eine neue Komponente entwickeln sollten, haben wir nicht als Erstes den Editor geöffnet. Stattdessen sind wir ans Whiteboard gegangen.
Dort haben wir das Problem von der anderen Seite her aufgerollt: Nicht „Wie bauen wir das?“, sondern „Wie soll es sich anfühlen, wenn jemand diesen Code verwendet?“ Diese Frage klingt simpel, aber sie verändert die gesamte Perspektive. Das Prinzip ist unter dem Begriff „Working backwards [1]“ bekannt, wie es unter anderem bei AWS praktiziert wird. Man beginnt beim gewünschten Ergebnis und arbeitet sich von dort zurück zur Implementierung.
Konkret bedeutete das: Wir haben am Whiteboard Codebeispiele skizziert. Nicht den internen Aufbau, sondern die öffentliche Schnittstelle. Wie würde eine Entwicklerin oder ein Entwickler dieses Modul aufrufen? Welche Parameter wären intuitiv? Welche Rückgabewerte würden erwartet? Welche Fehlerfälle müsste man behandeln, und wie sollte das aussehen?
Dieses Vorgehen erzwang, dass wir uns intensiv mit der Domäne und den Anforderungen auseinandersetzten, bevor eine einzige Zeile produktiven Codes entstand. Es zwang uns, Fragen zu stellen, die beim sofortigen Losprogrammieren untergegangen wären. Häufig stellten wir dabei fest, dass unsere anfänglichen Vorstellungen von der Schnittstelle nicht tragfähig waren. Dann haben wir das Whiteboard gewischt und von vorn begonnen, so oft wie nötig. Das kostete trotzdem nur Stunden, keine Tage oder gar eine Woche.
Am Ende dieser Phase hatten wir ein gemeinsames, explizites Verständnis davon, was wir eigentlich bauen wollten. Nicht ungefähr, nicht implizit, sondern konkret und greifbar. Wir konnten jedem im Team erklären, warum die Schnittstelle genau so aussehen sollte und nicht anders. Diese Klarheit war kein Nebenprodukt, sie war das eigentliche Ziel.
Wegwerfen als Investition
Nach der Whiteboard-Phase folgte ein Schritt, der auf den ersten Blick noch ungewöhnlicher wirkt: Wir haben einen Prototyp geschrieben, mit dem klaren Vorsatz, ihn anschließend wegzuwerfen. Kein sauberer Code, keine Tests, keine Dokumentation. Nur ein schneller, funktionaler Durchstich, um unsere Thesen zu überprüfen.
Dieser Prototyp diente ausschließlich dem Lernen. Am Whiteboard kann man vieles klären, aber bestimmte Dinge zeigen sich erst, wenn man tatsächlich Code schreibt. Theorie und Praxis klaffen in der Softwareentwicklung oft weiter auseinander, als man wahrhaben möchte. Wie verhält sich die Schnittstelle, wenn man sie wirklich benutzt? Wo fühlt sie sich sperrig an? Welche Randfälle tauchen auf, an die man nicht gedacht hat? Wo hat man die Komplexität über- oder unterschätzt? Welche Abhängigkeiten ergeben sich, die auf dem Whiteboard nicht sichtbar waren?
Der entscheidende Punkt war, dass dieser Prototyp keine Verpflichtung mit sich brachte. Weil von Anfang an feststand, dass er weggeworfen würde, konnten wir frei experimentieren. Es gab keinen Druck, die einmal gewählte Struktur beizubehalten, nur weil schon Code da war. Wir konnten Sackgassen ohne schlechtes Gewissen verlassen und Alternativen ausprobieren. Wir konnten Fehler machen, ohne dass diese Fehler sich in der Codebasis festsetzten.
Das Wegwerfen selbst fiel erstaunlich leicht. Nicht, weil uns der Code egal war, sondern weil das eigentliche Ergebnis dieser Phase nicht der Code selbst war. Das Ergebnis war Erkenntnis: ein tiefes, praktisches Verständnis dafür, wie die Lösung aussehen sollte und welche Fallstricke zu vermeiden waren. Dieses Verständnis ließ sich nicht durch Nachdenken allein gewinnen. Es brauchte die Erfahrung des Tuns, das Scheitern in einer sicheren Umgebung.
Die finale Fassung mit Rückenwind
Erst im dritten Anlauf haben wir den eigentlichen, produktiven Code geschrieben. Und hier zeigte sich der Lohn der Vorarbeit: Das Schreiben ging bemerkenswert schnell. Nicht, weil wir uns beeilten, sondern weil wir wussten, was wir taten. Die Unsicherheit, die normalerweise jede Entwicklung begleitet, war weitgehend verschwunden. An ihre Stelle war Zuversicht getreten.
Die Architektur stand, die Schnittstellen waren durchdacht, die typischen Stolperstellen waren bekannt. Wir mussten nicht mehr experimentieren oder grundlegende Entscheidungen treffen, denn das hatten wir bereits hinter uns. Stattdessen konnten wir uns darauf konzentrieren, sauberen, gut strukturierten Code zu schreiben, der von Anfang an den Qualitätsansprüchen genügt.
Genau in dieser Phase kamen auch Tests und Dokumentation hinzu. Beides fällt erheblich leichter, wenn man die Lösung verstanden hat und nicht im Nebel stochert. Tests für eine durchdachte Schnittstelle zu schreiben, ist keine Last, sondern eine Bestätigung. Man weiß, welche Fälle relevant sind, und kann sie gezielt abdecken. Und Dokumentation für ein Modul zu verfassen, dessen Designentscheidungen man bewusst getroffen hat, ist keine Pflichtübung, sondern eine natürliche Ergänzung.
Das gesamte Vorgehen fand im Pair-Programming statt. Zwei Personen am selben Problem, von der Whiteboard-Diskussion über den Prototyp bis zum fertigen Code. Auch das wirkt auf den ersten Blick teuer: Zwei Entwicklerinnen oder Entwickler für eine Aufgabe, das ist doch doppelter Aufwand? Die Praxis erzählte eine andere Geschichte. Vier Augen sehen mehr als zwei, und der ständige Dialog verhindert, dass sich jemand in eine Sackgasse verrennt, ohne es zu bemerken. Was wir an scheinbarer Effizienz aufgaben, gewannen wir an Qualität und Geschwindigkeit zurück.
„Wie könnt ihr euch das leisten?“
Wann immer ich diesen Prozess beschrieben habe, war die häufigste Reaktion eine Mischung aus Interesse und Unglauben. Die Fragen lauteten: „Wie könnt ihr euch das leisten?“ und „Wie bringt ihr eure Kunden dazu, das mitzumachen?“
Die Antwort war einfacher, als die meisten erwartet haben: Wir waren schneller und günstiger als andere. Nicht trotz, sondern wegen dieses Vorgehens. Das klingt nach einer bequemen Behauptung, aber die Zahlen stützten sie.
Der Grund liegt in einer Beobachtung, die sich über Jahre hinweg immer wieder bestätigt hat: Unser Code hat beim ersten echten Versuch mit einer überdurchschnittlich hohen Rate funktioniert. Er war weitgehend fehlerfrei, die Schnittstellen passten zu den tatsächlichen Anforderungen, und die Architektur trug auch dann noch, wenn später Erweiterungen hinzukamen. Was auf dem Papier nach Mehraufwand aussah, war in Wahrheit eine Abkürzung.
Was auf der anderen Seite wegfiel, war erheblich: keine endlosen Korrekturschleifen, keine späten Architekturentscheidungen unter Druck, keine Wochen, in denen das Team im Grunde damit beschäftigt war, frühe Fehler zu reparieren. Kein mühsames Debugging von Code, den man vor drei Wochen geschrieben und inzwischen halb vergessen hatte. Keine hitzigen Diskussionen darüber, ob man den bestehenden Ansatz noch retten kann oder doch lieber neu anfangen sollte. Für unsere Kundinnen und Kunden bedeutete das: zuverlässigere Zeitpläne, weniger Überraschungen und am Ende niedrigere Gesamtkosten.
Der Prozess sah langsamer aus, weil die erste sichtbare Codezeile später entstand. Aber die erste sichtbare Codezeile ist nicht der relevante Messpunkt. Relevant ist, wann funktionierende, zuverlässige Software ausgeliefert wird. Und diesen Punkt haben wir regelmäßig früher erreicht als Teams, die vom ersten Tag an in die Tasten gehauen haben.
Schnell geschriebener Code ist nicht besserer Code
Heute, zahlreiche Jahre später, hat sich das Umfeld grundlegend verändert. KI-gestützte Werkzeuge erzeugen Code in einem Tempo, das noch vor Kurzem undenkbar war. Ein gut formulierter Prompt liefert in Sekunden, wofür früher Stunden nötig waren. Die Geschwindigkeit der Codeerzeugung hat sich vervielfacht, und die Werkzeuge werden mit jeder Generation leistungsfähiger.
Doch Geschwindigkeit bei der Codeerzeugung ist nicht dasselbe wie Geschwindigkeit bei der Problemlösung. Eine KI kann beeindruckend schnell Code produzieren, aber sie kann nicht wissen, ob dieser Code das richtige Problem löst. Sie kann eine Schnittstelle implementieren, aber nicht beurteilen, ob diese Schnittstelle für die tatsächlichen Anwendungsfälle sinnvoll ist. Sie kann Tests generieren, aber nicht entscheiden, welche Fälle wirklich kritisch sind und welche nur Rauschen erzeugen.
Was KI-Werkzeuge im Kern tun, ist verstärken. Sie verstärken das, was man hineinsteckt. Wer genau weiß, was die Lösung leisten soll, wie die Schnittstellen aussehen müssen und welche Randfälle zu beachten sind, bekommt von einer KI beeindruckend guten Code in kürzester Zeit. Die Maschine wird zum Beschleuniger für eine klare Idee. Wer diese Klarheit nicht hat, bekommt schneller das Falsche. Und falscher Code, der in Sekunden statt in Stunden entstanden ist, bleibt falscher Code. Er muss genauso überarbeitet, korrigiert und im schlimmsten Fall weggeworfen werden. Die KI hat dann nichts beschleunigt, sie hat nur die Illusion von Fortschritt erzeugt.
Und genau hier schließt sich der Kreis zum dreistufigen Prozess. Die Phase am Whiteboard, das Durchdenken der Verwenderperspektive, das bewusste Experimentieren mit einem Wegwerf-Prototyp: All das liefert genau die Klarheit, die man braucht, um KI-Werkzeuge sinnvoll einzusetzen. Man füttert die KI nicht mit vagen Vorstellungen, sondern mit präzisen Anforderungen. Die KI übernimmt dann den Teil, der tatsächlich beschleunigt werden kann: das Schreiben von Code, dessen Richtung bereits feststeht.
Die Versuchung ist groß, diesen Schritt zu überspringen. Wenn Code so billig zu erzeugen ist, warum nicht einfach ausprobieren und schauen, was passiert? Die Antwort ist dieselbe wie vor zwanzig Jahren: Weil das Erzeugen von Code nie der Engpass war. [2] Der Engpass war und ist das Verstehen. Und Verstehen lässt sich nicht beschleunigen, indem man schneller tippt, ob mit oder ohne KI.
Langsam anfangen, um schnell anzukommen
„Slow is smooth and smooth is fast.“ Dieser Grundsatz der Navy SEALs hat nichts an Gültigkeit verloren, auch nicht in einer Zeit, in der Maschinen Code schneller schreiben als jeder Mensch.
Bewusst Tempo herauszunehmen, sich die Zeit zu geben, ein Problem wirklich zu durchdringen, bevor man es löst, fühlt sich an wie ein Luxus, den man sich nicht leisten kann. Die Erfahrung zeigt jedoch das Gegenteil: Es ist eine Investition, die sich zuverlässig auszahlt. In weniger Fehlern, in weniger Nacharbeit, in kürzerer Gesamtdauer und in Code, der nicht nur funktioniert, sondern trägt. In Teams, die weniger streiten und mehr liefern.
Ob man diesen Code dann selbst schreibt oder von einer KI schreiben lässt, ist zweitrangig. Entscheidend ist, dass man weiß, was man will, bevor man anfängt. Erst denken, dann experimentieren, dann bauen. In dieser Reihenfolge. Daran hat sich in all den Jahren nichts geändert.
URL dieses Artikels: https://www.heise.de/-11175199
Links in diesem Artikel: [1] https://aws.amazon.com/de/blogs/smb/working-backwards-to-drive-customer-experience-and-smb-innovation-forward/ [2] https://www.heise.de/blog/Der-wahre-Engpass-Warum-schnelleres-Coden-Projekte-nicht-beschleunigt-11162879.html [3] mailto:rme@ix.de
Linux: Wie Kmscon virtuelle Textkonsolen modernisiert
Von Heise — 11. März 2026 um 08:00
Altlasten loswerden, Sicherheit verbessern und mehr Flexibilität: Das verspricht der Wechsel zu Kmscon, eine neue Technik für Virtual Terminals.
Startmeldungen und klassische Textkonsolen landen bei Linux wahrscheinlich bald ganz anders auf dem Schirm. Das soll einigen altbackenen und unsicheren Techniken aus der Anfangszeit des Kernels endlich den Garaus machen. Ähnlich wie Wayland ändert dieser über ein Jahrzehnt vorbereiteter Wandel oberflächlich wenig, erfordert zugleich aber Umdenken von Anwendern. Allerdings nur jenen, die damit in Berührung kommen – etwa wenn Kernel oder Desktop-Umgebungen nicht starten.
Einen der letzten und zugleich entschiedenen Schritte des Wandels plant gerade Fedora als erste große Distribution. Nicht mehr der Kernel soll auf Tastenkombinationen wie Strg+Alt+F3 die Virtual Terminals (VT) erzeugen, sondern das Programm Kmscon soll die „Textkonsolen“ bereitstellen. Ursprünglich sollte der Wechsel schon in der im April erwarteten Version 44 vollzogen werden, wurde aber Mitte Februar ohne Nennung von Gründen auf Fedora 45 verschoben, was voraussichtlich im Oktober 2026 erscheint.
Bei x86-Systemen war die Bezeichnung Textkonsole früher adäquat, denn da hat bei VTs tatsächlich die Grafikkarte die Zeichen gerendert und ausgegeben, die sie vom Kernel erhielt. Etwa Log-Meldungen des Kernels beim Systemstart oder bei VTs die von Getty gelieferten Zeichen sowie von darüber gestarteten Shells und Anwendungen.
Altlasten und ihre Probleme
Bei modernen Systemen rendert hingegen meist der Kernel die VTs. Dazu nutzt er Framebuffer-Konsolen (Fbcon), die mit geeigneten Fonts auch Unicode-Zeichen darstellen können. Dazu braucht der Kernel aber zumindest einen rudimentären Grafiktreiber. Auf 64-Bit-x86-Systemen ist das schon lange fast immer einer, der auf dem Direct Rendering Manager (DRM) des Kernels aufbaut; zumeist ein nativer Treiber wie Amdgpu, i915 oder Nouveau, manchmal aber auch der generische Simpledrm, der bei EFI-Systemen das Bild via Graphics Output Protocol (GOP) ausgibt. Fbcon nutzt DRM-Treiber allerdings nur über eine Emulationsschicht für Frame-Buffer-Geräte (Fbdev). Auf diesen älteren Ansatz für Kernel-Grafiktreiber haben viele Embedded-Systeme noch lange gesetzt, doch auch dort haben sich DRM-Treiber jüngst durchgesetzt.
Die Kern-Crew hinter DRM hätte Fbdev und Fbcon am liebsten schon vor Jahren eliminiert. Beide sind Jahrzehnte alt und weisen durch strukturelle Schwächen wahrscheinlich zahlreiche Sicherheitslücken auf. Eine davon wurde vor Jahren bekannt und war nicht ohne Weiteres lösbar. Die Entwickler haben sie daher mehr umschifft denn beseitigt, indem sie unter anderem die Fbcon-Funktion zum Scrollen mit den Tastenkombinationen Umschalt+Bild-auf und -ab (Scrollback) bei Linux 5.9 deaktiviert haben – zum Ärger von so manch altem Linux-Hasen.
Dieses Schicksal ereilte aufgrund von Lücken damals auch den Fbdev-Code, der die Bildausgabe mit dem Grafikkern beschleunigen konnte. Die „Fbdev Acceleration“ kam zwar zurück, allerdings muss man sie wegen ihrer bekannten Schwächen explizit beim Übersetzen des Kernels aktivieren. In den meisten Mainstream-x86-Distributionen ist die Ausgabebeschleunigung wegen potenzieller Sicherheitsgefahren bewusst nicht eingeschaltet. Dort ist die Funktion ohnehin nicht sonderlich relevant, denn kaum einer der gängigen DRM-Treiber unterstützt sie. Bei modernen Systemen geben VTs große Textmengen in der Standardkonfiguration daher vielfach nur träge aus.
Merkmale der Software Kmscon
Textkonsole mit Kernel Mode Setting
Einen moderneren Ansatz hat David Rheinsberg, besser bekannt unter seinem vorherigen Namen David Herrmann, schon Ende 2011 mit der Software „Kmscon“ vorgestellt. Diese realisiert die VTs im Userspace, kümmert sich also selbst um das Rendern, statt es dem Kernel zu überlassen. Die Bildausgabe erfolgt dabei via Kernel Mode Setting (KMS) von DRM, über das auch moderne Desktop-Umgebungen die von ihnen gerenderte Oberfläche zum Monitor schicken.
Fbdev und Fbcon umgeht Kmscon so komplett. Doch auch unabhängig davon verspricht der neue Ansatz, die Sicherheit zu verbessern: Ein böser Bug im Code der beiden Altlasten erlaubt womöglich eine Übernahme des Systems, während ein Fehler in Kmscon lediglich die Sitzung betrifft oder Kmscon abstürzen lässt.
Die Entwicklung der Software schlief 2014 allerdings weitgehend ein. 2022 nahm sie dann aber wieder an Fahrt auf. Auch neue Versionen erschienen mittlerweile wieder, zuletzt im Januar Kmscon 9.3.0. Haupttriebkraft dahinter ist Red-Hat-Mitarbeiter Jocelyn Falempe. Er organisiert seit einigen Monaten parallel den Umstieg auf Kmscon bei der für Herbst 2026 erwarteten Version 45 von Fedora Linux; bei aktuellen Fedora-Versionen lässt sich Kmscon bereits mit wenigen Handgriffen ausprobieren.
Kmscon ist schärfer und schneller
Von einer leicht anderen und schärferen Schriftart abgesehen sieht ein mit Kmscon erzeugtes VT auf zwei Testsystemen aber genauso aus wie ein klassisches mit Fbcon. Es gibt größere Textmengen aber viel schneller aus. Auf Wunsch kann es die Bildkomposition auch per OpenGL und somit hardwarebeschleunigt erledigen, braucht dazu dann aber einen 3D-Treiber. Bei Kmscon funktioniert auch das altbekannte Scrollback wieder. Weitere Vorteile: Tastaturbelegungswechsel per Shortcut, bessere Unicode-Unterstützung, flexibleres Multiseat-Handling, Support zur Bildschirmdrehung sowie simple Mausunterstützung samt Copy & Paste.
Ein Virtuelles Terminal mit Kmscon rendert die Schrift schärfer und scrollt größere Textmengen viel schneller, sieht aber sonst nicht viel anders aus.
Das Virtuelel Terminal von Fbcon erkennt man an der gröberen Schrift. Auch unter der Haube hat es etliche Nachteile.
Letzteres lässt sich bei klassischen VTs über gpm realisieren, das unter Kmscon nicht funktioniert. Das Gleiche gilt auch für altbekannte Werkzeuge wie loadkeys oder setfont zum Setzen von Tastaturbelegung oder Schriftart, denn die sind für Fbcon gemacht. Zum händischen Start von grafischen Oberflächen muss man das Skript kmscon-launch-gui anstelle klassischer Befehle wiestartxnutzen. Damit kommen die meisten Nutzer ohnehin nicht mehr in Kontakt.
Alte Techniken angezählt, aber vorerst dabei
Fbdev und Fbcon bleiben bei Fedora Linux vorerst aber weiter aktiv, damit der Kernel gleich vom Start weg Log-Meldungen ausgeben kann, noch bevor überhaupt an einen Aufruf von Userspace-Anwendungen wie Kmscon zu denken ist. Diese Aufgabe dürfte mittelfristig die Kernel-Funktion DRM Log übernehmen, die Jocelyn Falempe vor gut einem Jahr zu Linux 6.14 beigesteuert hat. Der dahinterstehende Code basiert zum Teil auf jenem von DRM Panic, der ebenfalls von Falempe stammt. Durch diese Funktion kann Linux seit Version 6.10 bei fatalen Kernel-Fehlern verlässlich Fehlerinformationen ausgeben, ähnlich wie Windows mit einem Blue Screen. Seit Linux 6.12 geht das optional auch als QR-Code. Die Grafiktreiber müssen DRM Log und DRM Panic allerdings unterstützen, was bei den gängigen DRM-Treibern des Kernels aber mittlerweile der Fall ist. Der quelloffene Kernel-Treiber von Nvidias hauseigenem Grafiktreiberstack beherrscht DRM Log und DRM Panic allerdings bislang nicht.
Bei Kmscon rendert statt des angestaubten Fbcon-Subsystems des Kernels ein Userspace-Programm die virtuellen Terminals (VT). Kmscon gibt das Bild nicht über das alte Fbdev, sondern direkt über das modernere DRM-Subsystem aus. Sowohl diese Verlagerung als auch die Umgebung der beiden Altlasten sollen die Sicherheit verbessern.
DRM Log bietet viel weniger Angriffsfläche als Fbcon, weil es viel simpler ist: Es beherrscht die Bildausgabe eines überschaubaren Zeichensatzes, aber keine Tastatureingaben. Für eine Rescue-Shell im Falle von Boot-Problemen eignet es sich daher nicht. Auch für diese nutzt Fedora daher vorerst weiter Fbcon; mittelfristig dürfte Kmscon diesen Job übernehmen, muss dazu aber ins Initramfs, was dieses größer macht. Bei Problemen mit dem Grafiktreiber braucht man diesen Rettungsanker auf modernen Systemen aber normalerweise ohnehin nicht. Dort reicht es zumeist, das Laden des nativen Kernel-Treibers zu untersagen, sodass Simpledrm übernimmt.
Alles in allem gibt es also noch einiges zu tun, bis Fedora und andere Mainstream-Distributionen Fbdev und Fbcon deaktivieren können. Wie bei jedem Technikwechsel werden in der Anfangsphase zudem noch allerlei Bugs und fehlende Features auftauchen. Das und die Hinfälligkeit von Loadkeys, Startx & Co. wird einigen Anwendern missfallen; ferner werden die immer rarer werdenden Systeme, für die es nur Fbdev-Grafiktreiber gibt, durch die Abkehr von Fbdev und Fbcon bei manchen Distributionen hintenüberfallen.
Gegenwind ist daher wahrscheinlich, ähnlich, wie er Systemd oder Wayland immer wieder ins Gesicht bläst. Aber das ist wie mit einer Grundrenovierung einer Wohnung: Viel Arbeit, bei der immer auch manch Liebgewonnenes verloren geht, aber wenn man es vernünftig macht, ist es das Ganze letztlich wert.
URL dieses Artikels: https://www.heise.de/-11179998
Links in diesem Artikel: [1] https://www.heise.de/hintergrund/Linux-Wie-Kmscon-virtuelle-Textkonsolen-modernisiert-11179998.html [2] https://www.heise.de/hintergrund/Linux-Fehlende-Bibliotheken-bei-Programmen-ergaenzen-11166039.html [3] https://www.heise.de/hintergrund/eBPF-Wie-der-Kernel-programmierbar-wurde-10627880.html [4] https://www.heise.de/ratgeber/Linux-Mit-Systemd-Timer-Dienste-und-Jobs-flexibel-planen-und-Cron-abloesen-11091833.html [5] https://www.heise.de/ct [6] mailto:ktn@heise.de
Haushalte zahlen für 100 Liter Heizöl bis zu 162 Euro – vor zwei Wochen waren es noch 90. Und auch eine Gaspreisbremse lehnt die Bundesregierung bislang ab.
Heizöl hat sich binnen zehn Tagen um rund 65 Prozent verteuert.Bild:
Weishaupt
Seit Beginn des Irankriegs am 28. Februar 2026 und der anschließenden Sperrung der Straße von Hormus erleben deutsche Haushalte den schwersten Energiepreisschock seit 2022. Heizöl hat sich binnen zehn Tagen um rund 65 Prozent verteuert, die Preise an der Gasbörse TTF verdoppelten sich zwischenzeitlich – und die Bundesregierung lehnt eine neue Preisbremse bislang ab. Für die rund 20 Millionen Haushalte, die mit Gas oder Öl heizen, bedeutet das: handeln, vergleichen, umdenken.
155 bis 162 Euro pro 100 Liter – Heizölpreise auf Zweijahreshoch
Vor Kriegsbeginn kosteten 100 Liter Heizöl bei einer 3.000-Liter-Abnahme zwischen 85 und 96 Euro ( Tecson , Esyoil ). Am 9. März 2026 notierte der Durchschnittspreis laut tanke-guenstig.de bei rund 155 bis 162 Euro pro 100 Liter – das höchste Niveau seit Sommer 2022. Eine 3.000-Liter-Bestellung kostet damit rund 4.650 Euro statt zuvor 2.700 Euro.
Die Ursachen sind klar: Die Blockade der Straße von Hormus unterbricht etwa 20 Prozent des globalen Öl- und LNG-Transits, katarische LNG-Anlagen wurden durch Drohnen beschädigt und Händler kalkulieren hohe Risikoaufschläge ein. Lieferzeiten liegen bei bis zu acht Wochen.
Gaskunden sind kurzfristig weniger betroffen, weil bestehende Lieferverträge puffern. Derzeit zahlen Neukunden laut 1-gasvergleich.com 8 bis 8,3 Cent pro Kilowattstunde, Bestandskunden im Schnitt 9,94 Cent. Die Grundversorgung liegt bei 13,6 Cent (Stand 8. März 2026).
Doch der Großhandel signalisiert Alarm: Der TTF-Gaspreis sprang von rund 32 Euro/MWh vor dem Krieg auf zeitweise über 65 Euro/MWh – ein Plus von über 100 Prozent. Goldman Sachs hob die April-Prognose auf 55 Euro/MWh an; bei einer dreimonatigen Hormus-Blockade rechnet der Analysedienst Icis laut Finanzmarktwelt mit bis zu 85 Euro/MWh. Der Durchschlag auf Endkundenpreise dürfte in den kommenden Wochen folgen.
Gasspeicher nur zu 21 Prozent gefüllt – ein riskanter Ausgangspunkt
Die deutschen Gasspeicher standen am 8. März 2026 bei rund 21 Prozent Füllstand ( Bundesnetzagentur/AGSI via gasspeicher.app ) – 13 Prozentpunkte weniger als im Vorjahr und 23 Punkte unter dem historischen März-Durchschnitt. Euronews titelte bereits Mitte Februar: "So leer waren Deutschlands Gasspeicher wohl noch nie."
Ursachen hierfür sind der kalte Winter 2025/26, ein nur 75-prozentiger Füllstand zu Heizsaisonbeginn und fehlende Einspeicheranreize. Das gesetzliche Ziel von 80 Prozent bis zum 1. November 2026 wird durch den Irankrieg zur teuren Herausforderung, weil genau jene LNG-Lieferungen verteuert werden, die für die Sommerbefüllung nötig wären.
Berlin setzt auf Beobachtung – Opposition fordert Sofortmaßnahmen
Wirtschaftsministerin Katherina Reiche (CDU) hat die Energie-Taskforce reaktiviert und das Bundeskartellamt eingeschaltet, betonte aber laut T-Online : "Eingriffe in den Markt macht man erst dann, wenn sie absolut unvermeidbar sind."
Kanzler Friedrich Merz verweist auf das Energieentlastungspaket vom Januar 2026 – darunter der Wegfall der Gasspeicherumlage und ein 6,5-Milliarden-Zuschuss zu Netzentgelten. Vizekanzler Lars Klingbeil (SPD) mahnt einen beschleunigten Erneuerbaren-Ausbau an. Eine neue Gaspreisbremse oder direkte Heizkostenhilfe steht laut Regierung aktuell nicht auf der Agenda.
Die Opposition reagiert scharf: Die Linke fordert einen Energiepreisdeckel und eine Übergewinnsteuer, das BSW die Senkung der Mehrwertsteuer auf Energie auf 7 Prozenz sowie den Wegfall der CO ₂ -Abgabe. Die Grünen drängen auf einkommensabhängige Förderung beim Heizungstausch. Gewerkschaften wie der CGB fordern die Vorbereitung einer Preisbremse für den Fall, dass der Krieg länger als vier Wochen dauert.
Wer nicht dringend Heizöl bestellen muss, sollte abwarten: Statistisch sind die Monate Mai bis Juli die günstigsten Kaufmonate. Wer bestellen muss, spart durch Sammelbestellungen mit Nachbarn (2 bis 8 Cent wenige/Liter) und den Vergleich über Portale wie Heizoel24 , Esyoil oder Check24 . Flexible Lieferzeiten statt Express sparen weitere 5 bis 10 Cent pro Liter. Tipps zur richtigen Bestellstrategie bietet heizoelboerse.de .
Gas: Anbieterwechsel bringt bis zu 1.260 Euro im Jahr
Gaskunden in der Grundversorgung verschenken bares Geld. Der Wechsel zum günstigsten Tarif spart laut Verivox bis zu 1.264 Euro jährlich bei 20.000 kWh Verbrauch. Wer seinen Verbrauch zusätzlich senkt – etwa durch einen hydraulischen Abgleich (10 bis 15 Prozent Ersparnis, Kosten circa 925 Euro im Einfamilienhaus, davon 15 bis 20 Prozent Bafa-gefördert ) oder die Absenkung der Raumtemperatur um 1 °C (6 Prozent weniger Heizkosten laut Thermondo ) – kann dem erwarteten Preisanstieg ein Stück weit entgegenwirken.
Mittelfristig umsteigen: bis zu 70 Prozent Förderung für Wärmepumpen
Die BEG-Förderung 2026 macht den Heizungstausch für Hauseigentümer attraktiver. Für Wärmepumpen gibt es laut Priwatt bis zu 70 Prozent Zuschuss.
Pelletheizungen erhalten ähnliche Sätze plus 2.500 Euro Emissionsminderungszuschlag ( Energie-Experten ). Für Dämm-Maßnahmen zahlt das Bafa 15 bis 20 Prozent ( Bafa Einzelmaßnahmen ). Der ergänzende KfW-Kredit reicht bis 120.000 Euro zinsvergünstigt.
2028 wird fossiles Heizen strukturell teurer
Unabhängig vom Irankrieg steigt der Kostendruck auf fossile Heizungen. Der nationale CO ₂ -Preis liegt 2026 bei 55 bis 65 Euro pro Tonne – das sind rund 20 Cent pro Liter Heizöl und 1,4 Cent pro kWh Gas ( Finanztip CO₂-Preis ).
Ab 2028 übernimmt der europäische Emissionshandel ETS-2: Startpreis voraussichtlich 50 bis 90 Euro/Tonne, bis 2030 rechnen Studien mit 120 bis 275 Euro pro Tonne ( Gebäudeforum ETS-2 ). Für ein Einfamilienhaus mit Ölheizung bedeutet das allein an CO ₂ -Kosten bis zu 820 Euro jährlich im Jahr 2030.
Parallel läuft die kommunale Wärmeplanung: Großstädte müssen bis 30. Juni 2026 ihren Wärmeplan vorlegen, alle anderen Kommunen bis 2028 ( Hausverwalterscout ). Bestehende fossile Heizungen sind ab 2045 komplett verboten.
Die Prognose: Alles hängt an Hormus
Beruhigt sich die Lage am Persischen Golf, könnten die Gasgroßhandelspreise bis zum Sommer auf 35 bis 45 Euro/MWh zurückfallen und Heizöl wieder unter 100 Euro/100 Liter sinken. Eskaliert der Konflikt weiter, ist laut Goldman Sachs eine dauerhafte Verdopplung des Gaspreisniveaus möglich.
Sicher ist nur: Wer fossiles Heizen als Langfristlösung betrachtet, wettet gegen den CO ₂ -Preis – und damit gegen die europäische Klimapolitik. Und: Die günstigste Kilowattstunde bleibt die, die man gar nicht erst verbraucht.
X-76: Darpa baut das schnellste Kipprotor-Flugzeug der Welt
Von Michael Linden — 11. März 2026 um 09:35
Kein Rollfeld, keine Kompromisse: Bell Textrons experimenteller X-76 soll Hubschrauber-Flexibilität mit Jetgeschwindigkeit kombinieren – und geht jetzt in die Fertigung.
X-76Bild:
Darpa
Die Defense Advanced Research Projects Agency (Darpa), eine Forschungsbehörde des US-Verteidigungsministeriums, hat Bell Textrons Experimentalflugzeug offiziell X-76 benannt und damit den Übergang von der Konstruktion in die aktive Fertigung markiert.
Wie funktioniert das? – Rotoren falten sich bei 150 Knoten weg
Der Trick steckt im sogenannten Stop-Fold-Rotor-System. Beim Start verhält sich der X-76 wie ein klassisches Kipprotor-Flugzeug. Ab etwa 150 bis 200 Knoten (280 bis 370 km/h) werden die Rotoren ausgekoppelt, in Fahrtrichtung gestellt und an den Triebwerksgondeln angelegt. Der Schub übernimmt dann eine Heckdüse. Ohne den Rotorwiderstand soll der X-76 über 450 Knoten erreichen – der V-22 Osprey schafft zum Vergleich maximal 270 Knoten (500 km/h). Die geplante Nutzlast liegt bei rund 450 Kilogramm, die Reichweite bei etwa 1.850 Kilometern.
Warum ist das wichtig? – Militär will weg vom Rollfeld
Darpa-Programmmanager Commander Ian Higgins sagte, dass eine Landebahn für Militärflugzeuge gleichzeitig Fluch und Segen sei. Wer keine braucht, ist schwerer anzugreifen und flexibler einsetzbar. Flugtests sind für Anfang 2028 geplant – ursprünglich war 2027 im Gespräch. Ob aus dem X-76 jemals ein Serienprodukt wird, hängt davon ab, was diese Tests zeigen. Bell baute mit dem XV-15 schon einmal eine solche Brücke – daraus wurde der V-22.
Sonos-CEO Tom Conrad verkündet das Ende des Streaminggeräts Pinewood.Bild:
Sonos
Strategieänderung bei Sonos: Das Unternehmen hat alle Arbeiten an einem eigenen Streaminggerät aufgegeben, wie der Sonos-CEO Tom Conrad im Gespräch mit Bloomberg erklärte. Somit bleibt es dabei, dass das Unternehmen Lautsprecher und Kopfhörer verkauft.
Conrad begründet die Entscheidung mit Personalmangel: "Wir hatten einfach nicht genug Softwareressourcen, um es gut umzusetzen." Das Gerät trug den internen Codenamen Pinewood und erstmals hat Sonos offiziell die Existenz des Produkts bestätigt.
Sonos wollte in eine neue Produktkategorie einsteigen
Zuvor sahen interne Pläne von Sonos vor, dass die Pinewood-Box im zweiten Halbjahr 2025 auf den Markt kommen sollte. Nach dem ANC-Kopfhörer Ace von Sonos wollte Sonos mit Pinewood abermals in eine für das Unternehmen neue Produktkategorie vorstoßen.
Intern sollen Sonos-Mitarbeiter bereits vor einem Jahr die Befürchtung geäußert haben, dass mit Pinewood die Erfahrung mit dem Ace-Kopfhörer wiederholt werde, der für Sonos zu einem Flop wurde . Der Kopfhörer muss sich in einem hart umkämpften Markt behaupten, und das würde bei einem Streaminggerät auch so sein.
FreshRSS 
