Anmelden
Die Karte zeigt die Ausdehnung von Trockenheit in den USA, mit besonders betroffenen Gebieten im Westen und Süden.
(Bild: U.S. Drought Monitor)
Die USA trocknen so schnell aus wie seit Jahrzehnten nicht – und ein bisher kaum beachteter Messwert zeigt, warum es diesmal anders ist.
Die Luft über dem Westen der USA wirkt derzeit wie ein überhitzter Schwamm: Sie saugt Feuchtigkeit aus Böden und Pflanzen schneller heraus als je zuvor gemessen.
Ein zentraler Messwert, das sogenannte Dampfdruckdefizit (Vapor Pressure Deficit, VPD), liegt für die Monate Januar bis März 77 Prozent über dem langjährigen Mittel – und damit mehr als 25 Prozent über dem bisherigen Rekord, wie AP News berichtet [1]. Park Williams, Hydroklimatologe an der University of California, Los Angeles (UCLA), bezeichnete dieses Ausmaß laut Bericht als etwas, "das vorher kaum vorstellbar gewesen wäre".
VPD beschreibt die Differenz zwischen der Wasserdampfmenge, die warme Luft theoretisch aufnehmen könnte, und der tatsächlich enthaltenen Feuchte. Je heißer und trockener die Luft, desto gieriger zieht sie Wasser aus allem, was sie umgibt – Äcker, Wälder, Flüsse, selbst lebende Pflanzen.
Fachleute halten diesen Wert für einen besseren Indikator der tatsächlichen Dürreintensität als reine Niederschlagsdaten, weil er erklärt, warum Landstriche austrocknen, obwohl der Regen gar nicht dramatisch zurückgegangen ist.
Die Zahlen sind alarmierend. Mehr als 61 Prozent der zusammenhängenden US-Bundesstaaten stecken laut U.S. Drought Monitor [2] in moderater bis außergewöhnlicher Dürre – darunter 97 Prozent des Südostens und zwei Drittel des Westens.
Der Palmer Drought Severity Index der US-Wetterbehörde NOAA erreichte im März 2026 laut AP News den höchsten Wert seit Beginn der Aufzeichnungen 1895. Insgesamt war der März der dritttrockenste Monat, der jemals in den USA gemessen wurde – nur die berüchtigten Dust-Bowl-Monate Juli und August 1934 waren noch trockener.
Besonders brisant: Zwei eigentlich unabhängige Dürrezonen fallen zeitlich zusammen. Im Westen sorgten Rekordhitze und extrem wenig Schnee dafür, dass die übliche Wasserspeicherung im Gebirge weitgehend ausfiel. Im
Süden und Südosten – von Texas bis zur Ostküste – hält ein verlagertes Jetstream-Muster Niederschlagsgebiete fern. Um die Dürre im Osten von Texas zu brechen, wären nach NOAA-Berechnungen rund 480 Millimeter Regen in einem einzigen Monat nötig.
Wie Andrew Ellis [3], Klimatologe am Virginia Polytechnic Institute and State University, erläutert, hat eine atypische La-Niña-Phase die Trockenheit massiv verschärft. Im Normalfall verschiebt La Niña – eine Abkühlung des westlichen äquatorialen Pazifiks – die Sturmbahnen nach Norden und lässt den Süden der USA trockener werden.
Diesmal blieb jedoch auch der Pazifische Nordwesten ungewöhnlich niederschlagsarm. Ellis betont, dass steigende Temperaturen durch den Klimawandel die Verdunstung aus dem Boden zusätzlich antreiben – ein Doppelschlag für die Vegetation.
Und diese Entwicklung hat laut CGTN Folgen [4]: In Arizona etwa blühen Kakteen bereits Monate früher als üblich und Colorados größter Stausee Blue Mesa liegt rund 18,9 Meter unter Vollstand [5] (Stand Mitte Mai 2026).
Die hohen VPD-Werte trocknen Gräser und Waldböden so schnell aus, dass Meteorologen vor einer besonders gefährlichen Waldbrandsaison warnen: Feuer entzündet sich leichter, breitet sich schneller aus und ist schwerer zu löschen, weil selbst Löschwasser rascher verdunstet.
Eine in Nature veröffentlichte Studie zeigt, dass der steigende "atmosphärische Durst" weltweit für rund 40 Prozent der zunehmenden Dürreintensität seit 1981 verantwortlich ist, hat Telepolis im vergangenen Jahr berichtet [6]. Von 2018 bis 2022 wuchs demnach die globale von Dürre betroffene Landfläche um 74 Prozent – weit über die Hälfte dieses Zuwachses ging auf die erhöhte Verdunstung zurück.
Für Europa ist das keine abstrakte Ferndiagnose. Meteorologen warnen, dass eine schwache US-Erntesaison die globalen Lebensmittelpreise treiben könnte – zumal ein kräftiger El Niño für Herbst und Winter prognostiziert wird, der Ernten in weiteren Anbauregionen wie Indien beeinträchtigen könnte.
Die Weizenpreise in den USA [7] kletterten bereits Ende April auf 618 US-Cent pro Bushel, und die europäischen Terminmärkte reagieren nervös.
In Deutschland mahnen Wasserbehörden derweil, dass klassische Dürreplanung um den Faktor Verdunstungsnachfrage ergänzt werden muss – die Erfahrungen von 2022 mit Niedrigwasser am Rhein und Ernteausfällen haben gezeigt, wie verwundbar auch Mitteleuropa ist.
Ellis sieht immerhin einen Hoffnungsschimmer: Ein historisch starkes El-Niño-Ereignis im kommenden Winter könnte "theoretisch das Gegenteil der diesjährigen La Niña bewirken". Ob das reicht, die aufgelaufenen Defizite auszugleichen, bleibt allerdings fraglich.
URL dieses Artikels:
https://www.heise.de/-11295743
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Die türkische Kamikazedrohne MERKÜT, ausgestattet mit KI-Zielverfolgung, soll in großen Stückzahlen produziert werden.
(Bild: SAVX)
Erstmals wurde eine türkische Kamikaze-Drohne in Stückzahlen von 100.000 bestellt – mit KI-Zielerfassung, die sogar bei GPS-Störung funktionieren soll.
Der türkische Technologiekonzern Pasifik Teknoloji hat auf der Rüstungsmesse SAHA 2026 in Istanbul die Kamikazedrohne MERKÜT vorgestellt und gleichzeitig einen Rahmenvertrag über 100.000 Stück verkündet.
Der Quadrokopter stammt vom Tochterunternehmen SAVX und ist als First-Person-View-Drohne (FPV) mit einem Anti-Personen-Gefechtskopf ausgelegt. Empfänger des Großauftrags soll ein nicht näher benanntes "verbündetes Land" sein.
Das 2,5 Kilogramm schwere System erreicht laut Herstellerangaben [1] eine Höchstgeschwindigkeit von 144 km/h bei einer Reichweite von 10 Kilometern. Die Flugzeit beträgt 20 Minuten mit Gefechtskopf, 30 Minuten ohne Nutzlast.
Erhältlich ist die MERKÜT in drei Varianten – mit elektro-optischer Kamera, mit Wärmebildsensor oder kabelgebunden. Der Hersteller verspricht tageszeit- und wetterunabhängige Einsätze bei Temperaturen zwischen minus 20 und plus 50 Grad Celsius.
Die Besonderheit des Systems liegt in seinem Gefechtskopf und Zündsystem. Der Anti-Personen-Sprengkopf enthält 1.000 Stahlkugeln mit je drei Millimeter Durchmesser, deren gerichtete Splitterwirkung einen Radius von bis zu 20 Metern abdecken soll. Ein einstellbarer Annäherungssensor erlaubt die Detonation in 0,5 bis 12 Metern Entfernung vom Ziel. Der Operator kann diese Distanz noch während des Anflugs anpassen.
Daneben sind auch Aufprall- und manuelle Auslösung möglich. Eine fünfstufige Sicherungsarchitektur – mechanisch, elektronisch und softwarebasiert – soll unbeabsichtigte Detonationen verhindern.
Für die Zielerfassung setzt SAVX auf KI-gestützte visuelle Führung. Nach einer manuellen oder automatischen Zielerkennung verriegelt sich die Drohne auf das Objekt und verfolgt es autonom weiter.
Das Verfahren erinnert an die Follow-Me-Funktion ziviler Drohnen, arbeitet aber laut Hersteller GNSS-unabhängig – soll also auch bei GPS-Störung funktionieren.
Konkrete Details zur eingesetzten Technik – etwa ob klassische Bildverarbeitung oder Deep-Learning-Modelle zum Einsatz kommen – nennt SAVX nicht.
Taktisch interessant ist das Einsatzkonzept über unbemannte Trägerplattformen. Der ebenfalls von TITRA entwickelte Hubschrauber ALPIN kann acht MERKÜT ins Einsatzgebiet transportieren, wie Defense Network beschreibt [2].
Daneben zeigte Zyrone Dynamics auf der Messe den Träger ZD300 für sechs Drohnen. Die Idee: Die Mutterdrohne fliegt deutlich weiter als die 10 Kilometer der MERKÜT und setzt die Kamikazedrohnen erst nahe dem Zielgebiet aus.
Das erweitert die effektive Angriffsreichweite erheblich und professionalisiert einen Ansatz, der im Ukraine-Krieg bislang eher improvisiert praktiziert wird.
Pasifik-Teknoloji-Chef Aykut Ferah erklärte laut Anadolu Ajansı [3] sowie der KAP-Börsenmitteilung vom 4. Mai 2026 [4], nach der Unterzeichnung des Rahmenvertrags über 100.000 Kamikaze-Drohnen sei "das Nachfragepotenzial auf den internationalen Märkten gestiegen".
Neben den MERKÜT-Systemen umfasst der Vertrag demnach 10 ALPIN-Hubschrauber, 25 DUMRUL-Mini-Helikopter, 500 DELİ-Kamikaze-Systeme und 500 KORGAN-Bodeneinheiten.
Ob Pasifik Teknoloji die notwendigen Fertigungskapazitäten für solche Stückzahlen tatsächlich aufbauen kann, bleibt abzuwarten. Auf der Messe unterzeichnete das Unternehmen Kooperationsvereinbarungen mit Altaş Motor und Ege Dinamik zur Lokalisierung der Motorenproduktion – ein Hinweis darauf, dass bislang zumindest Teile importiert werden. Zudem soll Intecro Robotics eine automatisierte Fertigungslinie aufbauen.
Ein Rahmenvertrag dieser Größenordnung dürfte sich realistisch über mehrere Jahre erstrecken.
Im Vergleich zu den häufig improvisierten FPV-Drohnen aus dem Ukraine-Krieg positioniert sich MERKÜT als industriell standardisiertes Massenprodukt mit definierten Leistungsdaten und integrierter Sensorik.
Wie verwundbar das System trotz versprochener GNSS-Unabhängigkeit gegen breitbandiges Jamming der Funkverbindung ist, lässt sich anhand der öffentlichen Daten nicht beurteilen.
URL dieses Artikels:
https://www.heise.de/-11295607
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Bild: Shutterstock.com
ARD und ZDF klagen in Karlsruhe. Länder blockieren Beitragserhöhung. Kann die neue KEF-Empfehlung die Klage zu Fall bringen?
Das lange Warten auf den Termin hat ein Ende: Das Bundesverfassungsgericht hat gestern bekannt gegeben, dass es am 23. Juni über Verfassungsbeschwerden von ARD und ZDF [1] verhandeln werde.
Die öffentlich-rechtlichen Sender hatten im November 2024 Klage erhoben, weil die Bundesländer die ursprünglich von der Kommission zur Ermittlung des Finanzbedarfs der Rundfunkanstalten (KEF) empfohlene Erhöhung von 18,36 Euro auf 18,94 Euro pro Monat zum 1. Januar 2025 blockiert hatten.
ARD und ZDF sehen darin eine Verletzung ihres Grundrechts auf Rundfunkfreiheit [2] nach Artikel 5 des Grundgesetzes.
Im Februar 2026 legte die KEF, wie sich bereits Ende 2025 angedeutet hatte, eine neue, deutlich niedrigere Empfehlung vor: Statt einer Erhöhung auf 18,94 Euro schlägt die Kommission nun nur noch 18,64 Euro vor: ab Januar 2027.
Die KEF begründet dies mit unerwartet hohen Mehreinnahmen von rund 504 Millionen Euro bis 2028 [3], die vor allem durch mehr beitragspflichtige Haushalte und gestiegene Finanzerträge zustande kommen – was allerdings nicht für jeden Sender zutrifft, zu sehen etwa an der Situation des MDR.
"Die Feststellungen des 25. Berichts stellen allerdings die Ergebnisse des 24. Berichts nicht in Frage", erklärte im Februar der Vorsitzende der Kommission zur Ermittlung des Finanzbedarfs der Rundfunkanstalten, Martin Detzel [4].
Die neue Empfehlung hatte eine juristische Debatte ausgelöst. Das Rechtsmagazin Legal Tribune Online [5] bewertete in einem Kommentar vom 23. Februar 2026, der einiges Aufsehen erregte, die Verfassungsbeschwerde von ARD und ZDF als "plötzlich chancenlos".
Der Autor Christian Rath argumentierte: Da die KEF eine Erhöhung erst ab 2027 für erforderlich halte, lasse sich kaum noch für einen gegenwärtigen Finanzierungsverzug für die Jahre 2025 und 2026 argumentieren.
Wenn die Länder den Rundfunkbeitrag erst zum Januar 2027 erhöhen müssen, haben sie bisher auch nichts versäumt, so die Argumentation. Die Verfassungsbeschwerde, dass die Untätigkeit der Länder "gegenwärtig" die Rundfunkfreiheit verletze, habe damit keine Grundlage mehr.
ARD und ZDF widersprachen dieser Einschätzung. "Wir haben Verfassungsbeschwerde erhoben, weil die Länder das verfassungsrechtlich geschützte staatsferne Finanzierungsverfahren nicht eingehalten haben und eine funktionsgerechte Finanzierung des öffentlich-rechtlichen Rundfunks nicht gewährleistet ist", teilte die ARD gegenüber dem Branchenmagazin DWDL.de [6] mit.
"Dieser Verfassungsverstoß ist mit dem Vorliegen des Entwurfs des 25. KEF-Berichts nicht behoben."
Auch die KEF selbst widerspricht der Einschätzung, die Verfassungsbeschwerde sei gegenstandslos geworden. KEF-Geschäftsführer Tim Schönborn erklärte gegenüber DWDL.de [7], die Kommission halte die Verfassungsbeschwerde "nach wie vor für begründet, da die in der ARD zusammengeschlossenen Landesrundfunkanstalten und das ZDF seit dem 1. Januar 2025 nicht ihrem festgestellten Bedarf entsprechend finanziert und daher in ihrem Grundrecht der Rundfunkfreiheit verletzt sind".
Die Begründung: Die KEF betrachtet immer einen vierjährigen Zeitraum. Für die gesamte Beitragsperiode 2025 bis 2028 sei die bedarfsgerechte Finanzierung mit den aktuellen 18,36 Euro nicht gegeben.
Das Bundesverfassungsgericht wird sich in der Verhandlung am 23. Juni mit grundsätzlichen Fragen zur Rundfunkfinanzierung befassen. Es geht unter anderem um die Anforderungen der Rundfunkfreiheit an die Entscheidung über die Höhe des Rundfunkbeitrags und an eine Abweichung vom Beitragsvorschlag sowie darum, wie das Gebot der bedarfsgerechten Finanzierung gewährleistet werden kann.
Ein Urteil wird einige Monate nach der Verhandlung erwartet. Der aktuelle Rundfunkbeitrag beträgt 18,36 Euro monatlich und finanziert mit rund 8,5 Milliarden Euro jährlich ARD, ZDF und Deutschlandradio.
Die politischen Fronten bleiben verhärtet. Auch die neue, geringere Beitragsempfehlung von 18,64 Euro stößt auf Ablehnung. Sachsens Staatskanzleichef Alexander Handschuh, Sprecher der Medienpolitik der Unionsländer, erklärte auch die 28-Cent-Erhöhung für "nicht vermittelbar" [8].
Eine geplante Reform des Rundfunkfinanzierungsstaatsvertrags, die das Einstimmigkeitsprinzip bei der Beitragsfestsetzung kippen sollte, scheiterte Ende 2025 an der fehlenden Unterschrift der Ministerpräsidenten von Bayern, Sachsen-Anhalt und Sachsen.
Für die Beitragszahler bedeutet das vorerst: Der aktuelle Satz von 18,36 Euro bleibt bestehen. Wann eine Erhöhung kommt und wie hoch sie ausfällt, lässt sich weiterhin nicht vorhersagen. Alle Augen richten sich nun auf die Entscheidung des Bundesverfassungsgerichts.
URL dieses Artikels:
https://www.heise.de/-11295553
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Moritz Förster / KI / iX)
Fedora Hummingbird Linux ist eine vollständig Container-basierte Distribution, die auf rpm-ostree und bootc aufbaut.
Neben viel KI und Virtualisierung gab es auf dem Red Hat Summit auch Neuigkeiten im Bereich der Linux-Distribution: Fedora Hummingbird Linux – auch HummingbirdOS genannt – ist da. Hierbei handelt es sich um eine vollständig Container-basierte Distribution. Gleich mehrere bereits bekannte Projekte vereinen sich hier: Zum einen natürlich Software aus dem Fedora-Universum, aber auch rpm-ostree, das von Fedora CoreOS und auch Silverblue bekannt ist.
Statt über einen traditionellen Paketmanager kommen Software-Aktualisierungen über sogenannte Transaktionen in das System. Das ist vergleichbar mit einem Git-Commit mit zwei Zuständen: dem aktuellen und dem nächsten. HummingbirdOS greift ebenfalls auf das bootc-Projekt zurück. Dabei geht es um sogenannte „bootfähige“ Container, die mit einem Linux-Kernel und systemd ausgestattet sind. Sie können als normale Container laufen oder über bootc wie ein klassisches Linux starten.
Die letzte Zutat für das neue Fedora Linux ist das Hummingbird-Projekt [1]. Es stellt minimalistische und gehärtete Container bereit. Letzteres bedeutet, dass es idealerweise keine bekannten ungepatchten Sicherheitslücken bezüglich der installierten Software gibt. Ziel ist, dass jeder Container nur eine Funktion hat.
Fedora Hummingbird Linux ist noch in einem frühen Stadium. Interessierte können sich aber schon ein Abbild aus der Container-Registry der Hummingbird-Community herunterladen. Ferner kann man das System auch als virtuelle Maschine betreiben. Dazu muss man das Container-Abbild per bootc-image-builder umwandeln. Das Resultat ist entweder eine virtuelle Festplatte oder Installations-CD. Erstere bindet der Anwender entweder in den Hypervisor oder Cloud-Account ein. Danach startet HummingbirdOS analog zu den anderen virtuellen Maschinen. Die Installations-CD benutzt das bekannte Werkzeug Anaconda.
Bei den von Red Hat angedachten Anwendungsfällen schließt sich der Bogen zurück zur KI. HummingbirdOS soll laut Ankündigung [2] als Plattform für KI-Agenten dienen. Designbedingt bietet es aktuelle Software mit minimaler Angriffsfläche. Unterstützung für Nutzer ist über den „Cooperative Community Support“ geplant. Hier können zahlende Red-Hat-Kunden auch Hilfe für bestimmte Projekte außerhalb des Enterprise-Umfeldes bekommen.
URL dieses Artikels:
https://www.heise.de/-11295489
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Pincasso / Shutterstock.com)
Die vierte Preview bringt neue Methoden in bestehenden Klassen der .NET-Basisklassenbibliothek sowie eine neue Konfigurationsdatei für Entity Framework Core.
Die vierte Vorschauversion der kommenden .NET-Version 11.0 ist erschienen und steht zum Download bereit [1]. Parallel dazu hat Microsoft auch die Version 11811.120 von Visual Studio 2026 Insiders [2] veröffentlicht, die zum Entwickeln von .NET-11.0-Anwendungen benötigt wird. Alternativ ist eine Arbeit mit Visual Studio Code und dem im SDK mitgelieferten Kommandozeilencompiler möglich.
Die Klasse System.Diagnostics.Process zur Verwaltung von Betriebssystemprozessen gibt es seit Version 1.0 des klassischen .NET Framework aus dem Jahr 2002. Prozesse startet man seitdem, indem man eine neue Instanz der Klasse erzeugt. Seit .NET Framework 2.0 (Jahr 2005) gibt es alternativ die statische Methode Process.Start(). 21 Jahre später ergänzt Microsoft nun weitere alternative statische Methoden zum Prozessstart: Process.Run() und Process.RunAsync() sowie Process.RunAndCaptureText() und Process.RunAndCaptureTextAsync(). Das letztgenannte Pärchen liefert ein ProcessTextOutput-Objekt, mit dem man direkt auf Standardausgabe (ProcessTextOutput), Standardfehlerausgabe (StandardError) und Rückgabewert (ExitStatus.ExitCode) zugreifen kann, mit deutlich weniger Programmcode als dies bei der alten Start()-Methode notwendig ist, siehe Listing.
Ein Abbruch des Kindprozesses ist über ein Cancellation-Token möglich. Anders als bei der Start()-Methode kehren alle neuen Methoden mit „Run“ im Namen erst zum Aufrufer zurück, wenn der Kindprozess beendet ist. Entwicklerinnen und Entwickler können dabei allerdings keine Ausgaben des Prozesses verarbeiten, während er läuft.
FreshRSS CancellationTokenSource cts = new CancellationTokenSource();
ProcessTextOutput result = await Process.RunAndCaptureTextAsync(
"robocopy.exe", [@"t:\Daten", @"t:\Daten_Backup", "/MIR", "/IS"], cts.Token);
CUI.Print("Neuer Prozess mit ID #" + result.ProcessId + " ist beendet!");
CUI.Line("StandardOutput");
CUI.Print(result.StandardOutput);
CUI.Line("StandardError");
CUI.PrintError(result.StandardError);
CUI.Line("ExitStatus");
CUI.Print("Canceled? " + result.ExitStatus.Canceled);
if (result.ExitStatus.HasValue && !result.ExitStatus.IsEmpty) PrintStatus(result.ExitStatus.ExitCode);Listing 1: Einsatz der neuen Methode Process.RunAndCaptureTextAsync()
Eine weitere hinzugefügte Methode zum Prozessstart ist Process.StartAndForget() zum Start eines Prozesses, ohne auf den erfolgreichen Start zu warten und ohne direkte Interaktionsmöglichkeiten mit dem neuen Prozess. Man kann lediglich über die zurückgelieferte Prozess-ID den neuen Prozess von außen überwachen, hat aber keinen Zugriff auf den Rückgabewert des Prozesses.
int processId = Process.StartAndForget(
"robocopy.exe", [@"t:\Daten", @"t:\Daten_Backup", "/MIR", "/IS"]);
CUI.Print("Neuer Prozess mit ID #" + processId + " ist gestartet!");
var p = Process.GetProcessById(processId);
while(!p.HasExited)
{
CUI.BusyIndicator();
Thread.Sleep(500);
}
CUI.Line("Neuer Prozess mit ID #" + processId + " ist beendet!");
// PrintStatus(p.ExitCode); // System.InvalidOperationException: 'Process was not started by this object, so requested information cannot be determined.'Listing 2: Einsatz der neuen Methode Process.StartAndForget()
In der Klasse ProcessStartInfo, die bei Process.Start() verwendet wird, gibt es auch zwei neue Boolean-Optionen: Neu sind zum einen ProcessStartInfo.StartDetached zum Start eines unabhängigen Prozesses mit eigener Konsole, der weiterlebt, auch wenn der startende Prozess beendet wird. Mit ProcessStartInfo.KillOnParentExit erreicht man zum anderen, dass der Kindprozess endet, wenn der startende Prozess endet. Wenn man beide Optionen in Kombination einsetzt, erhält man eine separate Konsole, die aber endet, wenn der startende Prozess endet. Während ProcessStartInfo.StartDetached auf allen Plattformen läuft, meldet ProcessStartInfo.KillOnParentExit aktuell, dass es nur auf Windows funktioniert, denn im Quellcode bei Microsoft steht:
[SupportedOSPlatform("windows")]
public bool KillOnParentExit { get; set; }In einem Blogeintrag [5] findet man schon den Hinweis darauf, dass Implementierungen für Android und Linux in Arbeit sind.
Für mit Process.Start() gestartete Prozesse gibt es auch die neuen Methoden ReadAllText() und ReadAllTextAsync(), mit denen man von einem beendeten Prozess gleichzeitig die Standardausgabe und die Fehlerausgabe erhalten kann:
process.WaitForExit();
(string output, string error) = process.ReadAllText();Im Gegensatz zu dem bisherigen Ansatz
string output = process.StandardOutput.ReadToEnd();
string error = process.StandardError.ReadToEnd();besteht bei den neuen Methoden nicht die Gefahr eines Deadlocks.
In .NET 11.0 Preview 1 [6] hatte Microsoft die Zstandard-Komprimierung ergänzt. Die Klassen ZstandardEncoder und ZstandardDecoder bieten dabei genauso wie die bereits in .NET Core 2.1 eingeführten Klassen BrotliEncoder und BrotliDecoder die Möglichkeit, beim Komprimieren und Dekomprimieren mit den Typen Span<byte> und ReadOnlySpan<byte> zu arbeiten, ohne die aufwendige Speicherallokation bei Streams. Nun liefert Microsoft diese Option auch für die älteren Klassen ZLibEncoder, DeflateEncoder und GZipEncoder sowie die zugehörigen Decoder, siehe Listing.
CUI.H1($"Komprimiere Datei {BIGFILEPATH} via Span<T>");
ReadOnlySpan<byte> sourceSpan = File.ReadAllBytes(BIGFILEPATH);
Console.WriteLine("Länge=" + sourceSpan.Length);
long maxCompressedLength = ZLibEncoder.GetMaxCompressedLength(sourceSpan.Length);
Span<byte> compressedSpan = new byte[maxCompressedLength];
// ZLibEncoder, DeflateEncoder, GZipEncoder, ZstandardEncoder oder BrotliEncoder
using ZLibEncoder encoder = new();
OperationStatus status = encoder.Compress(
sourceSpan, compressedSpan, out int bytesConsumed, out int bytesWritten,
isFinalBlock: true);
PrintStatus(compressedSpan, status);
CUI.H1($"Dekomprimieren aus Span<T>");
// ZLibDecoder, DeflateDecoder, GZipDecoder, ZstandardDecoder oder BrotliDecoder
using ZLibDecoder decoder = new();
byte[] decompressedSpan = new byte[sourceSpan.Length];
OperationStatus decompressStatus = decoder.Decompress(
compressedSpan,
decompressedSpan,
out int compressedBytesConsumed,
out int decompressedBytesWritten);
PrintStatus(decompressedSpan, decompressStatus);Listing 3: Komprimierung und Dekomprimierung mit Span<T>
Die Fließkommazahltypklassen Half, Single und Double können in den Methoden Parse() und TryParse() auch Zeichenketten mit Hexadezimalzahlen auswerten. Dazu müssen Entwicklerinnen und Entwickler aber die Option NumberStyles.HexFloat angeben:
static void TestDouble(double d, string doubleAsString )
{
string hex = d.ToString("X");
Console.WriteLine(hex);
double d1a = double.Parse(hex, NumberStyles.HexFloat);
Console.WriteLine(d1a);
CUI.Success(d1a == d); // True
double.TryParse(hex, NumberStyles.HexFloat, null, out double d1b);
Console.WriteLine(d1b);
CUI.Success(d1b == d); // True
}Die Klassen System.Text.Unicode.Utf8 und System.Text.Unicode.Utf16 bieten nun zwei neue Methoden: IsValid() und IndexOfInvalidSubsequence(). Damit lässt sich nun leichter die Gültigkeit einer Unicode-Zeichenkette prüfen und zumindest die erste fehlerhafte Stelle ermitteln:
ReadOnlySpan<char> chars1 = "Gültiger Text: \uD83D\uDC4D";
Console.WriteLine(chars1);
bool check1 = Utf16.IsValid(chars1); // True
Console.WriteLine(check1);
if (check1) CUI.Success("OK");
else CUI.Warning("Fehler bei Zeichen: " + Utf16.IndexOfInvalidSubsequence(chars1));
ReadOnlySpan<char> chars2 = "Ungültiger Text: \uD83D";
Console.WriteLine(chars2);
bool check2 = Utf16.IsValid(chars2); // False
if (check2) CUI.Success("OK");
else CUI.Warning("Fehler bei Zeichen: " + Utf16.IndexOfInvalidSubsequence(chars2));Bei dem im modernen .NET mitgelieferten JSON-Serialisierer, dem NuGet-Paket System.Text.Json, das auch im klassischen .NET Framework funktioniert, bietet die schon vorher bestehende Methode Reset() in der Klasse Utf8JsonWriter nun eine Überladung, in der man via JsonWriterOptions abweichende Einstellungen festlegen kann. Entwicklerinnen und Entwickler können damit Utf8JsonWriter-Instanzen mit abweichenden Einstellungen wiederverwenden:
using var stream1 = new MemoryStream();
using var writer = new Utf8JsonWriter(stream1, new JsonWriterOptions
{
Indented = true
});
…
using var stream2 = new MemoryStream();
writer.Reset(stream2, new JsonWriterOptions
{
Indented = false
});Im Source Generator innerhalb von System.Text.Json behebt Microsoft einige Schwächen [7].
Die Klasse Microsoft.Extensions.Caching.Memory.MemoryCache bietet nun von Hause aus Metriken für OpenTelemetry an: dotnet.cache.requests (mit Unterscheidung zwischen hit und miss), dotnet.cache.eviction, dotnet.cache.entries und dotnet.cache.estimated_size. Entwicklerinnen und Entwickler müssen dafür in den Optionen MemoryCacheOptions.TrackStatistics = true setzen.
Eine wesentliche Vereinfachung liefert Microsoft Entwicklerinnen und Entwicklern beim Umgang mit den Entity-Framework-Core-Kommandozeilenwerkzeugen: Sie können nun in einer Konfigurationsdatei mit Namen dotnet-ef.json einige Einstellungen hinterlegen, die man sonst in jedem Kommandozeilenbefehl mit den Parametern, zum Beispiel --project, --startup-project und --context, angeben musste, wenn man von Microsofts Standard, dass alles in einem Projekt liegt und es nur eine Kontextklasse gibt, abweichen wollte. Ein Beispiel für eine Datei dotnet-ef.json zeigt das nächste Listing.
{
"framework": "net11.0",
"project": "DA/DA.csproj",
"startupProject": "DA/DA.csproj",
"context": "WwwingsV1EnContext",
"verbose": false,
"noColor": true,
"prefixOutput": false
}Listing 4: dotnet-ef.json
Diese Datei muss ausgehend von der Wurzel der Projektmappe im Ordner /.config liegen. Entwicklerinnen und Entwickler können dann in dem Wurzelordner oder in jedem Unterordner Befehle wie dotnet ef migrations add, dotnet ef migrations remove, dotnet ef database update oder dotnet ef dbcontext optimize ausführen, ohne die in dotnet-ef.json genannten Parameter nochmals angeben zu müssen. Wenn dennoch Parameter verwendet werden, wirken diese stärker als die Einträge in dotnet-ef.json.
Ein Schnelltest ergab, dass die Datei dotnet-ef.json bisher aber nur für die klassischen Kommandozeilenwerkzeuge funktioniert. Die korrespondierenden PowerShell Commandlets wie Add-Migration, Remove-Migration, Update-Database und Optimize-DbContext beachten die neue Datei leider bisher nicht. Ebenso ist bedauerlich, dass Kommentartexte in der Datei nicht erlaubt sind.
Eine weitere Verbesserung betrifft temporale Tabellen [8]. Solche Tabellen mit Datenversionsgeschichte unterstützt Entity Framework Core schon seit der Version 6.0 beim Reverse Engineering [9] und Forward Engineering [10]. Allerdings mussten die Spalten für die Gültigkeitsdauer einer Datensatzversion (meist PeriodStart und PeriodEnd) bisher immer sogenannte Shadow Properties sein, die in den .NET-Klassen nicht auftauchen durften. Seit Entity Framework Core 11.0 Preview 4 können Entwicklerinnen und Entwickler diese nun als normale Properties im Modell führen.
In der folgenden Beispielklasse MeasuringData heißen die Datensatzversionseigenschaften ValidStart und ValidEnd:
[Comment("Measuring Data with Temporal Table")]
public class MeasuringData
{
[Comment("PK")]
public long ID { get; set; }
[Comment("Measuring Value")]
public Decimal Value { get; set; }
[Comment("Measuring Time")]
public DateTime DateTime { get; set; }
[Comment("Measuring Sensor")]
public int Sensor { get; set; }
[Comment("Optional Measuring Note")]
public string Note { get; set; }
// War verboten vor EFCore 11.0: 'Period property ValidStart must be a shadow property.'
[Comment("Temporal Table: Start Time")]
public DateTime ValidStart { get; set; }
// War verboten vor EFCore 11.0: 'Period property ValidEnd must be a shadow property.'
[Comment("Temporal Table: Start End")]
public DateTime ValidEnd { get; set; }
}Die Mapping-Festlegung in der Fluent API in OnModelCreating() mit HasPeriodStart() und HasPeriodEnd() kann nun Lambda-Ausdrücke anstelle von Zeichenketten verwenden, da die Properties in der Klasse vorhanden sind:
modelBuilder.Entity<MeasuringData>()
.ToTable("MeasuringData", "ITVisions")
.ToTable(tb => tb.IsTemporal(ttb =>
{
ttb.UseHistoryTable("MeasuringData_History", "ITVisions");
ttb.HasPeriodStart(p=>p.ValidStart); // oder: "ValidStart"
ttb.HasPeriodEnd(p => p.ValidEnd); // oder: "ValidEnd"
}));Im Webframework Blazor gibt es eine neue Annotation für Parameter: [SupplyParameterFromTempData]:
@code {
[SupplyParameterFromTempData]
public string? Parametername { get; set; }
}Temp Data ist ein Konzept aus dem ASP.NET-Model-View-Controller-Framework (MVC), um auf elegante Weise Daten von einer Seite zu einer anderen weiterzugeben. Im Standard werden die Daten per Cookie weitergeben. Andere Speicherformen (zum Beispiel serverseitige Sessions) sind auch möglich. In Blazor in .NET 11.0 kann man nun auch Temp Data verwenden, was aber nur beim Static Server-Side Rendering (Static SSR) sinnvoll ist, denn in den anderen Blazor-Varianten (Blazor Server, Blazor WebAssembly und Blazor Hybrid) gibt es keine Seitenübergänge.
Bei Blazor Server gibt es eine kontinuierliche Verbindung zwischen Webbrowser und Webserver, die Microsoft Circuit nennt. Seit .NET 10.0 können Entwicklerinnen und Entwickler Circuits via Blazor.pauseCircuit() per JavaScript-Code pausieren und via Blazor.resumeCircuit() den Zustand im RAM oder einer Datenbank persistieren und später wiedererwecken, zum Beispiel um Ressourcen auf dem Server zu sparen, wenn ein Benutzer die Browserregisterkarte mit der Blazor-Anwendung verlässt.
Was bisher nur per JavaScript möglich war, geht ab .NET 11.0 zumindest für das Pausieren auch per C# via neuer Methode RequestCircuitPauseAsync() in der Circuit-Klasse. Entwicklerinnen und Entwickler müssen allerdings selbst eine Dienstklasse schreiben (siehe Listing), die sich die Referenzen auf die geöffneten Circuits merkt, da Microsoft leider keine Liste aller Circuits oder auch nur den Zugriff auf den aktuellen Circuit erlaubt.
using System.Collections.Concurrent;
using Microsoft.AspNetCore.Components.Server.Circuits;
namespace NET11_BlazorServer
{
public class CircuitManager : CircuitHandler
{
private static readonly ConcurrentDictionary<string, Circuit> _circuits = new();
public static IReadOnlyCollection<Circuit> ActiveCircuits => _circuits.Values.ToArray();
public Circuit? Current { get; set; }
public override Task OnConnectionUpAsync(Circuit circuit, CancellationToken cancellationToken)
{
_circuits[circuit.Id] = circuit;
Current = circuit;
return Task.CompletedTask;
}
public override Task OnCircuitClosedAsync(Circuit circuit, CancellationToken cancellationToken)
{
_circuits.TryRemove(circuit.Id, out _);
return Task.CompletedTask;
}
}
}Listing 5: Klasse CircuitManager
An beliebiger Stelle im Programmcode kann man dann Circuits durch den Aufruf der Methode RequestCircuitPauseAsync() pausieren. Das gilt auch für den aktuellen Circuit; wenn man den pausiert, kann man das aktuelle Browserfenster aber nicht mehr bedienen.
@page "/circuitlist"
@using Microsoft.AspNetCore.Components.Server.Circuits;
@inject CircuitManager CircuitManager
@inject ITVisions.Blazor.BlazorUtil util
<h3>CircuitList</h3>
<hr />
<p>Current Circuit: @CircuitManager.Current?.Id</p>
@foreach (var circuit in CircuitManager.ActiveCircuits)
{
<p>@circuit.Id
@if (CircuitManager.Current != null && CircuitManager.Current.Id == circuit.Id)
{
<span class="mx-2 badge bg-primary">Current</span>
}
<button class="btn btn-warning" @onclick="() => PauseCircuit(circuit)">Pause</button></p>
}
@code {
private async Task PauseCircuit(Circuit circuit)
{
util.Log("RequestCircuitPauseAsync: " + circuit.Id);
var ok = await circuit.RequestCircuitPauseAsync();
if (ok)
{
await util.Alert("Circuit paused: " + circuit.Id);
}
else
{
await util.Alert("Failed to pause circuit: " + circuit.Id);
}
}
}Listing 6: CurcuitList.razor
Das .NET SDK liefert nun eine Projektvorlage zum Implementieren eines Servers für das Model Context Protocol (MCP) in C# mit. Die Projektvorlage können Entwicklerinnen und Entwickler in Visual Studio verwenden (siehe Abbildungen) oder via Kommandozeilenbefehl:
dotnet new mcpserver -o MeinMCPServerDie Projektvorlage verwendet das NuGet-Paket ModelContextProtocol für lokale MCP-Server und das Paket ModelContextProtocol.AspNetCore für HTTP-basierte MCP-Server (Auswahl „remote“). In der Startdatei Program.cs findet man den Aufruf .AddMcpServer() gefolgt von .WithStdioServerTransport() oder .WithHttpTransport(). Manuell kann man auch beide Transportwege in einem Projekt kombinieren. Als MCP-Server-Beispiel ist eine Klasse RandomNumberTools in der Projektvorlage enthalten, die ganzzahlige Zufallszahlen liefert.
In .NET 11.0 Preview 3 [11] war es für die neuen Union Types (Discriminated Unions) noch notwendig, eine Klasse System.Runtime.CompilerServices.UnionAttribute in seinem eigenen Programmcode zu schreiben. Dieser Workaround entfällt nun in .NET 11.0 Preview 4, da die .NET-Basisklassenbibliothek selbst diese Implementierung bereits enthält.
In .NET MAUI ist die .NET Core Common Language Runtime [12] (Core CLR) nun die Standardlaufzeitumgebung für alle Betriebssysteme. In .NET 6.0 bis .NET 9.0 liefen .NET für Android und .NET für iOS sowie .NET für Mac Catalyst immer auf der Mono Common Language Runtime [13] (Mono CLR). Seit .NET 10.0 läuft .NET für Android alternativ (experimentell) auch auf der Core CLR.
Microsoft begründet den nun erfolgten Umstieg mit der besseren Performance von Core CLR gegenüber der Mono CLR durch neuere Techniken wie Tiered JIT Compilation [14], ReadyToRun (R2R) Images [15] und Profile-Guided Optimization (PGO) [16], die es in der Mono CLR nicht gibt. Diese Verbesserungen wirken insbesondere positiv auf die Startzeit von Anwendungen. In einem Blogbeitrag [17] räumt Microsoft aber ein, dass es in einigen größeren Android-Anwendungen zu Performanzregressionen bei der Startzeit kommt, die noch nicht geklärt sind.
Weiterer Vorteil der Umstellung auf die Core CLR ist, dass man die Werkzeuge dotnet-trace und dotnet-counters nun auch für .NET-Anwendungen auf Android, iOS und Mac Catalyst einsetzen kann. dotnet-dump funktioniert aber aktuell noch nicht mit diesen Anwendungen.
Zudem plant Microsoft auf Basis der Core CLR auch die Native-AOT-Kompilierung für Anwendungen auf Android zu ermöglichen. iOS- und macOS-Anwendungen verwenden jetzt schon NativeAOT.
Das Debugging und Hot Reloading von MAUI-Anwendungen auf Android, iOS und Mac Catalyst hat noch Schwächen. Entwicklerinnen und Entwickler können daher auf die Mono CLR zurückschalten:
<PropertyGroup>
<UseMonoRuntime>true</UseMonoRuntime>
</PropertyGroup>Die XAML-Syntax in .NET MAUI erlaubt nun C#-Programmcode-Inseln mit <x:Code>, wie man dies aus WPF kennt [18] und wie es auch Blazor mit @code { …} unterstützt:
<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
x:Class="NET11_MAUI.InlineCode">
<x:Code>
<![CDATA[
void OnButtonClicked(object sender, EventArgs e)
{
this.CounterBtn.Text = $"Angeklickt :-)";
}
]]>
</x:Code>
<Button x:Name="CounterBtn" Clicked="OnButtonClicked" Text="Klick mich!" />
</ContentPage>Voraussetzung ist aber das Flag <EnablePreviewFeatures> in der Projektdatei.
Außerdem funktioniert das Kommandozeilenwerkzeug dotnet watch nun besser in .NET-MAUI-Projekten. Entwicklerinnen und Entwickler können damit Projekte für iOS und für Android sowohl für echte Geräte als auch für Emulatoren/Simulatoren mit Hot Reloading starten.
Alle Laufzeitbibliotheken von .NET 11.0 Preview 4 sind nun mit der asynchronen Runtime (mit runtime-async=on) kompiliert, die Microsoft in Preview 2 eingeführt hat [19].
Weitere Neuerungen in .NET 11.0 Preview 4, insbesondere einige Fehlerkorrekturen und interne Verbesserungen (etwa bei der Behandlung von JSON-Spalten in Entity Framework Core), findet man in den Release Notes [20].
.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 drei weiteren Preview-Versionen von Juni 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/-11294727
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: heise medien)
Keine festen Token-Kontingente mehr und ein neuer Max-Tarif für Power-User: GitHub ändert sein Bezahlmodell für Copilot schon wieder.
GitHub stellt sein Abrechnungsmodell für Copilot abermals um. Ab dem 1. Juni setzen sich alle Bezahltarife, die für einzelne Entwicklerinnen und Entwickler konzipiert sind, aus zwei Bestandteilen zusammen: einer festen Menge an Token (den Base Credits) und einem Flex‑Kontingent. Letzteres will GitHub dynamisch an wirtschaftliche Faktoren wie die Modellkosten anpassen.
GitHub hatte bereits Ende April [1] angekündigt, kostenlose Modelle aus den Copilot-Tarifen zu streichen. Jetzt folgt weitere Feinabstimmung, die als Reaktion auf das Feedback der Community zu verstehen ist, wie GitHub zu den Änderungen schreibt [2]. Die Community fragte sich nämlich, ob das in den kostenpflichtigen Tarifen enthaltene Token-Kontingent ausreicht, wenn Anfang Juni die Umstellung auf verbrauchsbasierte Nutzung erfolgt.
Was es mit dem Flex‑Kontingent auf sich hat, beantwortet GitHub folgendermaßen: „Es passt sich an, wenn sich die wirtschaftlichen Rahmenbedingungen für KI verändern, einschließlich Modellpreisen, neuen Modellen und Effizienzverbesserungen.“ Die Base Credits, die sich 1:1 aus dem Abonnementpreis ergeben, bleiben dagegen immer gleich, so der Anbieter.
Das Flex‑Kontingent greift ab dem 1. Juni für die Tarife Pro und Pro+ [3]. Haben Entwicklerinnen und Entwickler die Base Credits ausgeschöpft, können sie aus dem Flex-Kontingent weitere Token beziehen. Beim Pro-Tarif summieren sich 1.000 Base Credits und ein derzeitiges Flex-Kontingent von 500 Credits zu einer monatlichen Gesamtmenge von 1.500 AI Credits. Für den Tarif Pro+ ergeben sich dementsprechend 7.000 AI Credits (3.900 Base + 3.100 Flex).
(Bild: Microsoft)
Das gleiche Abrechnungsschema wendet auch der neue Max-Tarif an, der ebenfalls ab Juni startet. Er richtet sich an diejenigen, die Copilot intensiv nutzen, schlägt mit 100 US-Dollar pro Monat zu Buche und umfasst 10.000 Base Credits sowie ein gleichwertiges Flex-Kontingent von weiteren 10.000 AI Credits.
Wurde der Credit-Rahmen ausgeschöpft, blockiert Copilot bis zum Start des nächsten Abrechnungszeitraums alle Anfragen, die Credits benötigen. Bislang konnte man automatisch auf ein günstigeres Modell zurückfallen, doch diese Möglichkeit entfällt mit dem neuen Tarifmodell [4]. Immerhin lässt GitHub den Free-Tarif weiterhin unangetastet, mit derzeit 50 Premium-Anfragen und 2.000 Code-Vorschlägen pro Monat.
Nutzerinnen und Nutzer der bisherigen monatlichen Tarife müssen nichts weiter tun, die Umstellung erfolgt automatisch. Jährliche Verträge werden nicht auf das neue Modell umgestellt. Sie laufen bis zum Vertragsende noch nach dem bisherigen anfragenbasierten Preissystem, allerdings mit höheren Multiplikatoren für teurere Modelle [5].
URL dieses Artikels:
https://www.heise.de/-11294789
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Trotz einer offiziellen Genehmigung durch die US-Regierung für den Verkauf von H200-KI-Chips an ausgewählte chinesische Unternehmen hat Nvidia bislang noch keine Lieferung getätigt. Wie Reuters exklusiv berichtet, versucht Nvidia-CEO Jensen Huang derzeit persönlich durch Gespräche mit der US- und der chinesischen Regierung, eine Lösung für das Problem zu finden.
Die US-Regierung genehmigte im Dezember 2025 den Verkauf von H200‑Chips an rund zehn chinesische Firmen. Darunter befinden sich Alibaba, Tencent, JD.com und Bytedance. Als Distributoren wurden zudem Foxconn und Lenovo zugelassen.
Jedes der Unternehmen darf Nvidia bis zu 75.000 Chips abnehmen. Allerdings hat die chinesische Regierung trotz früherer Genehmigungen heimische Unternehmen angewiesen, sich beim Kauf zurückzuhalten, um die eigene Chipindustrie zu stärken.
Eine von US-Präsident Donald Trump ausgehandelte Beteiligung am Umsatz der von Nvidia in China verkauften Hardware schürte in China zudem Befürchtungen wegen möglicher Manipulationen an oder versteckter Schwachstellen in der Hardware, da diese für die Gültigkeit der Umsatzbeteiligung über US-Territorium transportiert werden muss.
Hinzu kommen Auflagen, in denen die USA von chinesischen Firmen den Nachweis strenger Sicherheitsverfahren und eine garantierte zivile Nutzung fordern. Die dadurch entstandene Pattsituation zwischen beiden Ländern führte laut Huang dazu, dass der Anteil von Nvidia am chinesischen Markt von ehemals fast 95 Prozent auf nahezu null fiel.
Während seiner Teilnahme an einem Gipfeltreffen mit dem chinesischen Präsidenten Xi Jinping versuchte der Nvidia-Chef, aktiv gegenzusteuern, allerdings ohne nennenswerten Erfolg.
Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.
Eine Soundbar kaufen und dann feststellen, dass der Klang kaum besser ist als der des TV-Lautsprechers, das ist eine Erfahrung, die viele kennen. Günstige Einsteigermodelle klingen dünn, der Bass fehlt, und von echter Räumlichkeit ist keine Spur. Richtig guter Heimkinosound braucht Subwoofer, Rear-Lautsprecher und eine Verarbeitung, die auch bei hoher Lautstärke nicht verzerrt. Die Ultimea Skywave X50 soll hier abliefern: ein vollständiges 5.1.4-System mit Dolby Atmos, 760 Watt Spitzenleistung, einem 8-Zoll-Subwoofer aus Holz und zwei kabellosen Rear-Lautsprechern. Bei Amazon hat das Set heute seinen neuen Bestpreis erreicht: 398,99 Euro statt 559 Euro. Der 90-Tage-Durchschnitt liegt bei 522,72 Euro, der aktuelle Preis ist damit fast 125 Euro günstiger als im Schnitt der vergangenen drei Monate.
- aktueller Preis: 398,99 Euro
- UVP: 559,00 Euro
- 90-Tage-Durchschnittspreis: 522,72 Euro
- 5.1.4 Dolby-Atmos-System mit 760 Watt, 8-Zoll-Subwoofer und 2 kabellosen Rear-Lautsprechern
- GaN-Verstärker mit 98 Prozent Effizienz, Gravus-Bass bis 28 Hz, vollständig kabelloses Setup per dualer 5-GHz-Funkübertragung, HDMI eARC, 4K HDR-Pass-Through
- 4,6 Sterne bei 46 Bewertungen, Bestseller Nr. 1 in der Amazon-Kategorie Heimkinosysteme
Die beiden kabellosen Rear-Lautsprecher sind als 2-Wege-Systeme gebaut: Ein seitlich gerichteter Treiber sorgt für die breite Klangbühne, ein nach oben gerichteter Treiber erzeugt die Höhenkanäle, die bei Dolby-Atmos-Inhalten den Raumklang nach oben erweitern. Regen, der von der Decke fällt, Hubschrauber, die über den Raum schweben, Donner, der durch das Zimmer rollt: Das 5.1.4-Setup macht den Unterschied zu herkömmlichen Soundbars hörbar. Die duale 5-GHz-Funkverbindung sorgt dabei für eine stabile kabellose Übertragung ohne Signalabbrüche, so dass Subwoofer und Rear-Lautsprecher ohne Kabelsalat platziert werden können.
Hinter der Leistung steckt ein GaN-Verstärker, der laut Hersteller 98 Prozent Effizienz erreicht und achtmal schneller reagiert als herkömmliche Siliziumverstärker. Das bedeutet in der Praxis: weniger Wärme, mehr Dynamik und keinen Klangverlust bei maximaler Lautstärke. Die Neuracore Audio Engine verarbeitet das Signal mit einem Triple-Core-DSP in 24-Bit/192-kHz-Auflösung und weniger als 0,5 Prozent Verzerrung. Der 8-Zoll-Subwoofer reicht dank Gravus-Bass-Technologie bis auf 28 Hz hinunter und bleibt dabei auch bei hohen Pegeln kontrolliert und sauber. Über HDMI eARC lässt sich das System direkt mit dem TV verbinden, 4K-HDR-Signale werden ohne Qualitätsverlust durchgeleitet.
Die Ultimea Skywave X50 Soundbar
ULTIMEA Skywave X50 5.1.4 Professionelle Soundbar mit Dolby Atmos
-29%Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.
Für alle, die ein kompakteres Setup ohne Rear-Lautsprecher suchen, bietet die GarageRock-Soundbar
GarageRock Soundbar mit Subwoofer
-40%Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.
Wer das Heimkino-Setup auf echtes Profiniveau heben möchte, findet im Teufel Consono 35 Concept
Teufel CONSONO 35 Concept - 5.1 Surround Soundsystem
-6%Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.
Weitere aktuelle Angebote verschiedener Hersteller rund um das Heimkino bei Amazon
Der Peripheriehersteller Lofree hat eine neue Tastatur im 75-Prozent-Format auf Kickstarter vorgestellt. Untypisch für die Marke: Es handelt sich bei der Hyzen nicht um eine Low-Profile-Tastatur, sondern ein Keyboard in voller Größe.
Außerdem ist die F-Tastenreihe als Touchscreen-Buttons umgesetzt. Mittels Kippschalter an der Seite lässt sich diese Reihe auch zu Funktionstasten umschalten.
Ebenfalls ungewöhnlich: Die Hyzen kann mit magnetischen TMR-Switches oder alternativ auch mit traditionellen mechanischen Schaltern ausgestattet werden. Das PCB untersützt beide Arten von Kontakten. Außerdem arbeitet Lofree mit dem Switch-Hersteller Kailh zusammen. Daraus ist ein Hybrid-Switch entstanden, der eine Kupferfeder und ein magnetisches Element in einem vereint.
Die sogenannten Nexus-Switches sollen sich so wie mechanische Schalter tippen und gleichzeitig diverse Features magnetischer Pendants wie etwa anpassbare Tastenanschläge und Rapid Trigger mittels Software unterstützen. Die Einstellungssoftware wird als Web-App angeboten.
Lofree will zwei Versionen der Hyzen verkaufen, eine kabelgebundene Variante und eine Drahtlosversion mit 2,4-GHz- und Bluetooth-Verbindung. Letztere ist mit 3.130 Gramm auch schwerer als die Kabelvariante (2.520 Gramm), da hier ein 10.000-mAh-Akku verbaut ist. Zudem wird es Varianten mit transparenten und schwarzen Keycaps geben.
Die Hyzen kann aktuell noch auf Kickstarter bestellt werden und kostet dort 160 Euro. Für 180 Euro gibt es die Version mit Drahtlosfunktionalität.
Der Hersteller hat schon mehrere Crowdfunding-Kampagnen abgeschlossen. Das Risiko für Vorbesteller ist also gering. Später wird es die Tastatur auch im Onlineshop des Unternehmens geben – dann allerdings für mehr Geld.
Apple Watch Series 11: Die Series 12 ist auf dem Weg.
(Bild: Apple)
Kein Hardware-Redesign, dafür aber je nach Variante neue Sensoren und mehr: Zur kommenden Apple Watch gibt es einige interessante Spekulationen.
Jedes Jahr im September stellt Apple nicht nur neue iPhone-Modelle vor, sondern in schöner Regelmäßigkeit auch überarbeitete Computeruhren. Davon ist auch in diesem Jahr auszugehen: Neben dem iPhone 18 Pro und Pro Max [1] sowie dem iPhone Ultra [2] erwartet die Gerüchteküche auch eine Apple Watch Series 12 sowie – zumindest möglicherweise – eine Apple Watch Ultra der vierten Generation. Noch früher als mit den neuen Geräten fürs Handgelenk ist mit der Vorstellung des neuen Betriebssystems watchOS 27 zu rechnen: Bereits am 8. Juni zur Entwicklerkonferenz WWDC 2026 [3] werden erste Details erwartet, zusammen mit Infos zu iOS 27, iPadOS 27, macOS 27 sowie visionOS 27 und tvOS 27.
Schon seit einigen Jahren erwarten Beobachter, dass Apple am grundlegenden Design der Apple Watch schrauben wird, doch getan hat sich bislang nichts. Der Hersteller setzt nach wie vor auf den 2015 erstmals eingeführten Look, verbesserte vor allem Details wie etwa den Bildschirm, der nun randloser ist sowie seit einigen Jahren stets leuchtet (Always-on-Display). Bei der Series 12 soll das Design ebenfalls nicht umgeworfen werden, heißt es. Leakern aus China [4] zufolge setzt Apple in diesem Jahr vor allem auf eine verbesserte Akku-Laufzeit – was sehr willkommen wäre, muss man die Uhr doch bei ganztägiger Nutzung immer noch gut alle 24 Stunden aufladen.
Dazu beitragen soll endlich wieder ein neues System-in-a-Package (SiP) mit moderneren Hauptprozessorkernen. Apple hatte bei Series 11, Ultra 3 und SE 3 [5] den S10 aus dem Vorjahr verbaut, der wiederum selbst kaum Veränderungen gegenüber dem S9 zeigte, der wiederum vom A16 abstammt (von 2022). Ein S11 oder – was passender wäre – S12 könnte auf einer neueren Architektur basieren, die dann auch offiziell Apple-Intelligence-fähig [6] wäre, bislang nutzt die Watch KI-Funktionen nur vom iPhone.
Ein sich seit Längerem haltendes Gerücht, vorgetragen unter anderem vom bekannten Analysten Ming-Chi Kuo sowie ersichtlich aus Code-Leaks [7], ist der Einbau eines Touch-ID-Fingerabdrucksensors sowohl in Series 12 als auch Ultra 4. Dieser könnte in der Seitentaste landen, wie dies Apple bei einigen iPads handhabt, und würde für mehr Sicherheit bei sensiblen Transaktionen sorgen. Momentan hat die Apple Watch als biometrisches Merkmal nur die Tatsache, dass sie am Handgelenk eines Menschen angebracht ist – dieser gibt dann einmalig seine PIN ein, um die Watch zu entsperren, danach gilt sie als freigegeben. Erst, wenn die Uhr wieder abgenommen wird, sperrt sie sich. Zuletzt gab es jedoch wieder gegenläufige Meinungen aus der Gerüchteküche: Apple soll unter anderem mit Platzproblemen kämpfen.
An neuen Sensoren für die Apple Watch sind zwar längerfristig echte Blutdruckmessungen [8] (momentan werden nur Veränderungen wahrgenommen) und Blutzucker [9] vorgesehen, doch in diesem Jahr war hierzu nichts Akutes zu vernehmen. Unklar bleibt auch, was Apple konkret bei der Ultra 4 plant. Diese war im letzten Jahr unter anderem mit Satellitenfunk und 5G RedCap [10] ausgestattet worden. Apple könnte unter anderem nun Apple Maps sowie Fotoanzeige in Nachrichten via Satellit auf der Watch ermöglichen. Das wären dann allerdings Features, die auch für ältere Geräte kommen – via watchOS 27.
URL dieses Artikels:
https://www.heise.de/-11289787
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Fahrzeug mit CarPlay (hier ein Rechtslenker): Im App Store tut sich was.
(Bild: Harry Howitt / Shutterstock.com)
Nutzer der iPhone-Fahrzeugintegration sollten einen Blick in den App Store werfen: Mehrere iOS-Tools wurden überarbeitet oder kommen erstmals auf die Plattform.
In den vergangenen Wochen haben Entwickler von iOS-Apps im Hinblick auf die CarPlay-Unterstützung nachgelegt. Bekannte iPhone-Anwendungen wurden für die Fahrzeugintegration verbessert, andere kamen erstmals ins Apple-fähige Auto. Ein Überblick, was sich lohnt und was neu ist.
Siri samt Apple Intelligence [1] sind bekannt dafür, technisch immer noch deutlich schwächer zu sein als das, was die großen KI-Firmen bieten. Apple will das mit iOS 27 zwar ändern [2], doch bis dahin lohnt ein Blick auf die Konkurrenz. Da seit iOS 26.4 Chatbots im Auto [3] nun offiziell per Audioschnittstelle angesprochen werden dürfen, wurde die Situation bei CarPlay deutlich aufgewertet. Mittlerweile steht etwa die offizielle ChatGPT-App auch im Auto [4] zur Verfügung. Damit kann man sowohl auf vorhergehende Chats zugreifen als auch auf „Projekte“, wie OpenAI größere Gesprächseinheiten mit der KI nennt. Die sehr simpel aufgebaute CarPlay-App erlaubt auf Knopfdruck einen neuen Sprachchat, eingestellt wird das meiste jedoch auf dem iPhone.
Ebenfalls für CarPlay verfügbar gemacht wurden zeitnah der Suchagent Perplexity sowie Grok von xAI [5]. Auch hier hat man es mit eher einfachen Anwendungen zu tun, die vor allem schnell zum Sprachchat leiten. Das liegt nicht so sehr an den KI-Firmen selbst, als an Apple, das genaue Vorgaben macht, wie solche Chatbot-Anwendungen umzusetzen sind, damit User während der Fahrt nicht abgelenkt werden. Derzeit fehlen leider sowohl Claude von Anthropic, zu dem es im Hinblick auf CarPlay keine offizielle Ankündigung gibt, als auch Google Gemini. Letzteres soll aber recht bald in Form einer Google-Maps-Integration ins Auto kommen, was eine kluge Platzierung wäre, denn der Kartendienst ist neben Apple Maps die wohl meistgenutzte CarPlay-Anwendung.
Zweite wichtige CarPlay-Kategorie, die in den letzten Wochen einige Verbesserungen verpasst bekam, ist das Thema Kommunikation. Nachdem es Microsofts Teams schon lange auch im Fahrzeug gibt, legte nun Google mit Meet nachher [6]. Die App erlaubt unter anderem den Zugriff auf den Kalender, um sich schnell in Treffen zuschalten zu können. Wie bei Teams sind reine Sprachchats möglich, man sieht seine Mitstreiter also auch in Videokonferenzen nicht. Technisch wäre das sicherlich möglich, doch Apple verbietet es aus Verkehrssicherheitsgründen.
Schließlich hat Meta mit WhatsApp experimentiert [7] und seiner CarPlay-App eine verbesserte Oberfläche verpasst. Statt (fast) nur via Siri nutzbar zu sein, kann man nun unter anderem auf die letzten Chats, Anrufe oder Gruppengespräche zugreifen. Ein neuer Bereich listet zudem Favoriten. All das macht die kostenlose Anwendung im Fahrzeug deutlich nutzbarer.
URL dieses Artikels:
https://www.heise.de/-11294983
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Apple-Tastatur mit Vorhängeschloss: Wie sicher ist macOS?
(Bild: ArtVibe1 / Shutterstock)
Im Rahmen von „Project Glasswing“ arbeitet Anthropic mit Apple am Auffinden von Sicherheitslücken. Nun hat eine Security-Firma das Modell dafür verwendet.
Das mit viel Vorschusslorbeeren und Hype gestartete KI-Modell Claude Mythos [1], das im Rahmen des „Project Glasswing“ zum Auffinden von Sicherheitslücken genutzt werden soll, hat bei macOS angeschlagen – allerdings nicht bei Tests durch Apple, sondern bei einer externen Sicherheitsfirma. Dem Unternehmen Calif aus Palo Alto gelang es demnach, von einer frühen Mythos-Version vorgeschlagene Techniken zu verwenden, um „zwei Bugs und eine Handvoll Verfahren“ zu nutzen, um Speicherfehler zu erreichen. Darüber erlangte Calif dann eine Rechteausweitung. Wie weit Angreifer mit dem Exploit gekommen wären, blieb zunächst unklar.
Details wurden bislang nicht veröffentlicht. Calif sieht das Problem jedoch als derart schwerwiegend an, dass Firmenmitarbeiter am vergangenen Dienstag direkt zu Apple gefahren seien, schreibt das Wall Street Journal. Einen 55 Seiten langen Bericht [2] habe das Team an Apple übergeben. Allein dieser persönliche Besuch (beziehungsweise Apples Einladung dazu) kann als Besonderheit gelten. Details will die Sicherheitsfirma erst veröffentlichen, sobald Apple intern einen Patch getestet und diesen dann implementiert hat. Dies werde vermutlich ziemlich schnell gehen, so Thai Duong von Calif.
Apple gab gegenüber dem Wall Street Journal an, der Konzern untersuche die vorgelegten Informationen jetzt. Sicherheit sei Toppriorität und man nehme potenzielle Lücken sehr ernst. Der Ex-Google-Sicherheitsforscher Michal Zalewski, der den Calif-Exploit untersuchen konnte, gab an, die verwendete Technik sei bemerkenswert, da Apple sich so sehr bemühe, macOS zu schützen. Von außen lässt sich das alles derzeit nur schwer bewerten, weil Calif nicht einmal angegeben hat, in welchem Systembereich die Probleme liegen. Es liegt aber nahe, dass es mit dem neuen Systemschutz Memory Integrity Enforcement (MIE) zu tun hat, der in neueren Apple-Chips einen deutlich verbesserten Speicherschutz [3] ermöglicht.
Anthropic hatte bei Bekanntgabe von Mythos behauptet, in kurzer Zeit unter anderem über 100 schwerwiegende Fehler in Firefox [4] entdeckt zu haben – zahlreiche wurden bereits behoben. Im Rahmen von Project Glasswing wurde Sicherheitsforschern, darunter auch Calif, sowie großen IT-Konzernen wie Apple selbst Zugriff auf die „Cyber“-Fähigkeiten von Mythos gewährt. Nun ist ein Wettrennen ausgebrochen, wer mit dem KI-Modell die meisten Bugs findet.
Anthropic ist damit aber nicht allein: Auch OpenAI und Google arbeiten an entsprechenden Modellen beziehungsweise bieten diese längst an. Der Calif-Exploit ließ sich zudem nicht durch Mythos allein umsetzen. Duong, Chef des Unternehmens, teilte mit, die Arbeit sei nur mit einer „sehr menschlichen Cybersecurity-Expertise“ möglich gewesen. Mythos gelinge es derzeit vor allem, bereits dokumentierte Angriffe zu reproduzieren. Der Exploit soll jetzt aber eine Angriffstechnik darstellen, die neu ist.
URL dieses Artikels:
https://www.heise.de/-11294837
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Alle Details zur Störungsmeldung ansehen Eigene Internetstörung melden
(Bild: amgun/ Shutterstock.com)
Ivanti warnt vor drei Sicherheitslücken im Endpoint Manager (EPM). Sie ermöglichen SQL-Injection oder Rechteausweitung.
Ivanti warnt vor Sicherheitslücken im Endpoint Manager, einer Verwaltungssoftware für Benutzer und Geräte im Netzwerk. Insgesamt geht es um drei Sicherheitslecks – eines verpasst die Einstufung als „kritisch“ nur haarscharf.
In einer Sicherheitsmitteilung erörtert Ivanti [1] die Sicherheitslecks. Eine SQL-Injection-Schwachstelle betrifft die Web-Konsole des Ivanti Endpoint Managers. Authentifizierte Angreifer können dadurch aus dem Netz Schadcode einschleusen und ausführen (CVE-2026-8111, CVSS 8.8, Risiko „hoch“). Falsche Rechtezuweisung im Agenten des Endpoint Managers ermöglicht zudem das Ausweiten der Rechte im System von lokal angemeldeten bösartigen Akteuren (CVE-2026-8110, CVSS 7.8, Risiko „hoch“).
Im Core-Server des Endpoint Managers können angemeldete Angreifer aus dem Netz Zugangsdaten abgreifen, da er eine „exponierte gefährliche Methode“ (exposed dangerous method, CWE-749 [2]) aufweist – Zugriffe darauf sind laut Definition nicht zureichend beschränkt (CVE-2026-8109, CVSS 6.5, Risiko „mittel“). Die zugehörige ZDI-Mitteilung weist [3] einen niedrigeren CVSS-Wert aus und zugleich darauf hin, dass der bestehende Authentifizierungsmechanismus umgehbar ist.
Ivanti gibt an, dass die Software-Version Ivanti EPM 2024 SU6 die Probleme beseitigt. Das Unternehmen erklärt außerdem, dass es keine Kenntnis davon hat, dass die Sicherheitslecks bereits attackiert würden. Daher könne es auch keine Hinweise auf (erfolgreiche) Angriffe (Indicators of Compromise, IOC) liefern. Die Schwachstellen hat demnach die Zero Day Initiative (ZDI) von Trend Micro (inzwischen unter der Marke TrendAI unterwegs) gemeldet. Trotz der Namensähnlichkeit seien die Lücken nicht im Endpoint Manager Mobile (EPMM) zu finden, führt Ivanti weiter aus.
IT-Verantwortliche sollten die Aktualisierung zügig installieren. Schwachstellen in Ivanti-Netzwerk-Verwaltungssoftware sind ein gefundenes Fressen für Cyberkriminelle. Vergangene Woche wurde etwa bekannt, dass Ivanti mit einem Update für EPMM Sicherheitslücken geschlossen hat [4], die bereits im Internet angegriffen wurden.
URL dieses Artikels:
https://www.heise.de/-11294605
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Tatiana Popova/Shutterstock.com)
Die Broadcom-Entwickler haben einen wichtigen Sicherheitspatch für VMware Fusion veröffentlicht.
Nutzen Angreifer eine Schwachstelle in VMware Fusion erfolgreich aus, können sie sich unter bestimmten Bedingungen Root-Nutzerrechte verschaffen. Nun haben die Entwickler die Lücke geschlossen.
Mit VMware Fusion erstellt man unter macOS virtuelle Maschinen. Angreifer können an einer Race-Condition-Schwachstelle (TOCTOU, Time-of-Check to Time-of-Use) ansetzen [--] in einer Binärdatei mit SETUID [1]. In so einem Fall passen Angreifer eine bestimmte Zeitspanne zwischen der Prüfung und Nutzung einer Ressource ab, um die Ressource zu manipulieren und so Schindluder zu treiben.
In diesem Fall können sie sich auf einem nicht näher ausgeführten Weg root-Rechte verschaffen und im Anschluss mit hoher Wahrscheinlichkeit die volle Kontrolle erlangen (CVE-2026-41702 „hoch“). Als Voraussetzung für eine Attacke müssen Angreifer aber bereits authentifiziert sein.
Davon ist die Ausgabe 25H2 von VMware Fusion bedroht. Die Entwickler versichern, die Version 26H1 repariert zu haben. Bislang gibt es keine Berichte über Attacken [2].
URL dieses Artikels:
https://www.heise.de/-11294685
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: heise medien)
Das wöchentliche Chrome-Update schließt insgesamt 79 Sicherheitslücken. Davon gelten 14 als kritisch.
Google hatte zum Mittwoch das wöchentliche Browserupdate für Chrome veröffentlicht. Inzwischen liefern die Entwickler auch die damit geschlossenen Sicherheitslücken nach: 79 an der Zahl, 14 davon bedeuten ein kritisches Risiko.
In der Versionsankündigung reißt Google [1] wie immer kurz an, in welcher Komponente die Schwachstellen zu finden sind und welchen Schweregrad sie haben. Weitere Details finden sich dort nicht, jedoch lassen sich die Schwachstellen im Regelfall durch das Anzeigen manipulierter Webseiten missbrauchen. Die kritischen und hochriskanten Lücken ermöglichen im Regelfall das Ausführen von Schadcode, das Ausbrechen aus der Sandbox oder das Abgreifen sensibler und anderweitig missbrauchbarer Informationen.
Alleine acht der kritischen Lecks basieren auf „Use-after-free“, also dem Zugreifen auf Ressourcen, nachdem sie bereits freigegeben wurden, wodurch ihr Inhalt undefiniert ist und oft Codeschmuggel erlaubt. Dazu kommen zwei Integer-Überläufe, ein Heap-basierter Pufferüberlauf, einmal unzureichende Prüfung von nicht vertrauenswürdigen Nutzereingaben, einmal ein Problem mit einem Objekt-Lebenszyklus sowie eine Race Condition ausgerechnet in der Payments-Komponente, die zum automatischen Ausfüllen dient und Google Pay und die darin gespeicherten Kreditkarteninformationen einbindet.
Weitere 37 Lücken stufen Googles Entwickler als Risiko „hoch“ ein, 28 immerhin noch als „mittleres“. Immerhin: Google erwähnt nicht, dass eine davon in freier Wildbahn attackiert würde. Dennoch sollten Nutzer und Nutzerinnen von Chrome und auf dem Chromium-Projekt basierenden Browsern zügig prüfen, ob die Updates inzwischen angewendet wurden.
Google gibt an, dass Chrome 148.0.7778.167 für Android, 148.0.7778.166 für iOS, 148.0.7778.167 für Linux und 148.0.7778.167/168 für macOS und Windows die zahlreichen sicherheitsrelevanten Fehler ausbügeln. Das Update liefert etwa der Versionsdialog aus, der sich durch Öffnen des Browser-Menüs und den weiteren Klick-Pfad über „Hilfe“ zu „Über <Browser-Name>“ öffnet. Unter Linux ist in der Regel die distributionseigene Softwareverwaltung aufzurufen. Auf Mobilgeräten finden sich die Updates im jeweiligen App-Store – oftmals jedoch mit deutlicher Verzögerung.
Auf Chromium basierende Browser wie Microsofts Edge dürften in Kürze ebenfalls Sicherheitsupdates liefern. Allerdings steht insbesondere für Edge zum Meldungszeitpunkt noch kein entsprechender Hinweis auf Microsofts Auflistung der Sicherheitsupdates [2].
In der vergangenen Woche hatten Googles Programmierer sogar noch mehr Sicherheitslücken behandelt, insgesamt 127 Stück [3]. Da waren allerdings lediglich drei als kritisches Risiko eingestuft.
Siehe auch:
URL dieses Artikels:
https://www.heise.de/-11294547
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Der c't-Datenschutz-Podcast widmet sich diesmal dem vermeintlichen Signal-Hack und einer brisanten Datensammlung bei Europol.
In Episode 159 des c't-Datenschutz-Podcasts vertreten Sylvester Tremmel aus der c't-Redaktion und der freie Journalist Falk Steiner [1] Joerg Heidrich an der Seite von Holger Bleich. Zum Auftakt berichtet Steiner aus Berlin von der Vorstellung des Tätigkeitsberichts der Bundesdatenschutzbeauftragten [2] – und davon, wie wenige Journalistinnen und Journalisten zu diesem Termin erschienen sind; für ihn ein bedenkliches Signal in Zeiten, in denen Vorhaben wie Vorratsdatenspeicherung oder Gesichtserkennung beim BKA auf der politischen Agenda stünden, der Datenschutz aber kaum noch Beachtung finde.
Beim Bußgeld der Woche geht es um eine spanische Fondsgesellschaft, die einen mit Microsoft Teams aufgezeichneten internen Call später als offizielles Protokoll an externe Investoren weitergegeben hatte. Die spanische Datenschutzbehörde AEPD wertete die pauschale Einwilligung zur Aufzeichnung der Teilnehmenden als unzureichend und verhängte 3000 Euro Bußgeld (Begründung in spanischer Sprache [3]). Die Diskutanten loben die Praxis der spanischen Behörde, auch kleinere Fälle konsequent zu verfolgen und damit Klarheit über die Auslegung der DSGVO zu schaffen.
Breiten Raum nimmt der sogenannte Signal-"Hack" [4] ein, bei dem hochrangige Politikerinnen und Politiker, darunter Bundestagspräsidentin Julia Klöckner, Ziel einer Phishing-Kampagne wurden. Tremmel stellt klar, dass es sich nicht um einen technischen Angriff auf den Messenger handelte: Die mutmaßlich aus Russland gesteuerten Angreifer gaben sich als Signal-Support aus und brachten ihre Opfer dazu, ihre PIN preiszugeben oder ein fremdes Gerät zu verknüpfen.
Steiner schildert anschaulich, wie schwierig sichere Kommunikation in der politischen Realität ist, wo eine einzelne Person wie die Bundestagspräsidentin in zahlreichen Rollen unterwegs ist und über verschiedenste IT-Umgebungen hinweg kommunizieren muss. Die nun empfohlene Nutzung der Messenger-Plattform Wire löse das Grundproblem nicht [5], solange offene Messenger nötig blieben.
Zuguterletzt stellt Tremmel eine Recherche von Correctiv, Computer Weekly und Solomon zum sogenannten "Pressure Cooker" bei Europol [6] vor. In diesem Datensystem soll die EU-Polizeibehörde über Jahre hinweg mehr als zwei Petabyte an Daten angehäuft haben – ohne saubere Rechtsgrundlage, ohne funktionierendes Rechtemanagement und am europäischen Datenschutzbeauftragten vorbei. Steiner ordnet ein, warum gerade jetzt, da die EU-Kommission Europol mit mehr Personal und Befugnissen ausstatten will, ein genauer Blick auf diese Praxis besonders wichtig ist.
Episode 159:
Hier geht es zu allen bisherigen Folgen:
URL dieses Artikels:
https://www.heise.de/-11293465
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: EleCrow)
Display, Tastatur und Akku im Notebook-Format: Das CrowView Note soll Arduino UNO Q mobiler machen.
Lapdocks für Smartphones, Raspberry Pis und andere Einplatinenrechner gibt es schon seit Jahren. Die Idee dahinter ist simpel: Bildschirm, Tastatur, Touchpad und Akku werden in ein Notebook-ähnliches Gehäuse gepackt, während die eigentliche Rechenarbeit ein über USB-C angeschlossenes Gerät übernimmt. Mit dem CrowView Note versucht Elecrow nun allerdings, das Prinzip stärker auf Maker zuzuschneiden.
Das CrowView Note ist ein 14-Zoll-Lapdock [1] mit IPS-Panel und einer Auflösung von 1920 × 1080 Pixeln und 60 Hz bei 100 % sRGB-Abdeckung. Das Gerät integriert Tastatur, Touchpad, Lautsprecher, Mikrofon und einen Akku mit 5000 beziehungsweise 6000 mAh, je nach Angabe im Datenblatt. Angeschlossen werden kompatible Geräte über USB-C. Darüber laufen gleichzeitig Stromversorgung, Audio, Video und Eingaben.
Speziell wird das CrowView Note durch das Bundle mit dem Arduino UNO Q. Dabei handelt es sich nicht um ein klassisches Arduino-Board mit kleinem Mikrocontroller allein, sondern um eine Kombination aus Qualcomm Dragonwing QRB2210 und STM32U585. Das System setzt also auf zwei getrennte Recheneinheiten. Der Qualcomm-Chip übernimmt Linux, Netzwerkfunktionen, Videoverarbeitung und KI-Anwendungen, während sich der STM32-Mikrocontroller um Echtzeitaufgaben kümmert.
Der Linux-Teil läuft mit einem Quad-Core-Prozessor mit bis zu 2 GHz, Adreno-GPU und 4 GByte RAM. Dazu kommen zwei ISPs für Kameraverarbeitung. Laut Hersteller eignet sich das Board dadurch für lokale KI-Anwendungen wie Objekterkennung oder Gestensteuerung. Das ist für Maker interessant, weil viele KI-Projekte sonst schnell bei Cloud-Diensten landen oder zusätzliche Hardware benötigen. Hier läuft die Verarbeitung direkt auf dem Gerät.
Zum Bundle gehört außerdem eine USB-Kamera mit 640 × 480 Pixeln. Die Auflösung wirkt im Jahr 2026 zwar eher wie Steinzeit, reicht aber für einfache Computer-Vision-Projekte oder Objekterkennung aus.
Das CrowView Note selbst besitzt neben mehreren USB-C-Anschlüssen auch Mini-HDMI sowie zwei USB-A-Ports. Unterstützt werden neben dem Arduino UNO Q auch Raspberry Pi 5, Raspberry Pi Zero, Jetson Nano, Orange Pi, Rock Pi oder LattePanda. Damit eignet sich das Gerät im Prinzip als universeller Entwicklungsmonitor für viele SBC-Projekte.
Interessant ist auch die Smartphone-Unterstützung. Android-Geräte mit Desktop-Modus lassen sich direkt anschließen und auf dem 14-Zoll-Display nutzen. Unterstützt werden im Apple-Bereich nur iPhones mit USB-3-fähigem Anschluss, also die Pro-Modelle neuerer Generationen. Die normalen iPhone-Varianten mit USB 2.0 bleiben außen vor.
Für Maker könnte das CrowView Note vor allem bei mobilen Projekten spannend werden. Wer beispielsweise an einem Roboter arbeitet, ein KI-Projekt auf Basis eines Jetson Nano testet oder unterwegs Sensorik debuggen möchte, bekommt mit dem Gerät eine kompakte Entwicklungsumgebung. Gerade bei Workshops, Messen oder Feldtests spart das zusätzliche Monitore und Eingabegeräte. Auch als portables Dashboard für Home-Assistant- oder Raspberry-Pi-Projekte wäre das Gerät denkbar.
Das Bundle mit Arduino UNO Q und Kamera wird für 259,90 US-Dollar angeboten. Für Maker könnte das Gerät weniger ein Notebook-Ersatz sein, sondern eher eine Art universeller „Werkstatt-Bildschirm zum Zusammenklappen“.
Wer mehr über den UNO Q erfahren will, findet alles dazu in unserem Test [2].
URL dieses Artikels:
https://www.heise.de/-11294367
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Logos von Intel und Apple: Eine neue Partnerschaft?
(Bild: nikkimeel / Shutterstock.com)
Nach Berichten über ein Aufleben der Kooperation von Apple und Intel bei Chips gibt es nun Infos über erste Kleinserien, so ein bekannter Marktbeobachter.
Seit zehn Jahren setzt Apple bei der Produktion von iPhone-Prozessoren nur noch auf den Lieferanten TSMC aus Taiwan. Zwar versucht der derzeit, auch in den USA eine Produktion [1] einzurichten, doch Apple wünscht sich mehr Diversifizierung – auch aus politischen Gründen [2]. Ein zweiter Partner ist nun angeblich gefunden: Es soll der alte Mac-Prozessoren-Lieferant Intel sein. Die Kooperation wurde zwar bislang nicht offiziell bestätigt, es gibt jedoch glaubhafte Berichte von Bloomberg [3] und Wall Street Journal [4]. Nun kommentiert auch ein bekannter Analyst das Geschehen: Ming-Chi Kuo von TF International Securities aus Taiwan will vernommen haben [5], dass Intel mittlerweile eine kleine Probeproduktion für verschiedene Apple-Chips gestartet hat. Er gilt in Apples Lieferkette als hervorragend vernetzt.
In einem ersten Schritt machte es Apple Intel dabei angeblich eher einfach: Die Herstellung von Legacy- beziehungsweise Low-End-Apple-Silicon-Chips ist demnach der Beginn. Intel verwende dafür eine verfeinerte Version seines aktuellen Fertigungsprozesses 18A, 18A-P genannt [6]. Interessant: Es soll sich nicht nur um iPhone-Prozessoren handeln, sondern auch um solche für iPad und Mac. Das „Small-Scale Testing“ (Kuo) beginne jetzt, geplant sind 80 Prozent iPhone-Chips, der Rest iPad und Mac, was dem aktuellen Verhältnis bei den Verkaufszahlen entspricht. Nach den Tests in diesem Jahr soll die Produktion 2027 hochfahren und 2028 weiter ausgebaut werden. 2029 könnte Apple die Herstellung dann gegebenenfalls wieder verringern.
Welche konkreten Apple-Silicon-Chips Intel zuerst herstellen wird, gibt Kuo nicht an. Apple sei aber zusätzlich dabei, auch neuere kommende Intel-Prozesse zu testen. Der Umfang der ersten Bestellung ist bislang unklar. Yield-Ziele, also wie viele der produzierten Chips tatsächlich lauffähig sind, soll Intel bei 50 bis 60 Prozent (oder höher) festgelegt haben. TSMC soll jedoch mit weitem Abstand größter Lieferant bleiben, Kuo spekuliert über 90 Prozent des Gesamtbedarfs.
Pikant: Laut Kuo sieht Intel die Zusammenarbeit mit Apple intern derzeit noch mit gemischten Gefühlen. Die Börse hatte die Berichte für den einstigen Chip-König des x86-Zeitalters jedoch positiv goutiert. Kuo wiederholte die Information, dass Apple schon seit Längerem mit Intel verhandelt – angeblich deutlich vor den aktuellen Lieferproblemen bei TSMC [7], die die große Nachfrage nach lukrativen KI-Chips ausgelöst hat.
Apple plane, Intel langfristig als wichtigen Lieferanten zu etablieren. Es werde aber Jahre dauern, bis dort die Bestellungen für fortschrittliche Chips landen, so Kuo weiter. Zudem gilt Apple als sehr herausfordernder Kunde mit hohen Ansprüchen. TSMC bleibt laut Kuo zumindest in den kommenden Jahren klar die Nummer eins für Apple Silicon.
URL dieses Artikels:
https://www.heise.de/-11294793
Links in diesem Artikel:
Copyright © 2026 Heise Medien
OpenAI-Boss Sam Altman.
(Bild: FotoField / Shutterstock.com)
ChatGPT ist eigentlich tief in iOS und Co. integriert. Doch OpenAI glaubt, dass Apple das Feature nicht wie vereinbart bewirbt – und plant, Anwälte zu schicken.
OpenAI profitiert einer Meldung der Finanznachrichtenagentur Bloomberg zufolge nicht ausreichend von einem großen Deal mit Apple – und erwägt nun sogar, Juristen loszuschicken. Dabei geht es um die seit Einführung von Apple Intelligence [1] im Oktober 2024 bestehende Partnerschaft, mit der Nutzer sehr leicht (und bis zu einer bestimmten Grenze kostenlos) auch auf ChatGPT [2] zugreifen können, wenn Apples KI-System nicht weiterweiß.
Angeblich sieht man bei OpenAI die erhofften „Benefits“ durch die Kooperation nicht und wirft Apple gar Vertragsbruch vor. Der Grund: Apple soll die Funktionen in seinen Betriebssystemen iOS, iPadOS und macOS nicht ausreichend bewerben und sogar „verstecken“. Das deutet darauf hin, dass OpenAI nicht die erhoffte Nutzungsintensität durch die Milliarden Apple-Nutzer feststellen kann.
Die gesamte Partnerschaft gilt demnach als belastet. Die Anwälte bei OpenAI arbeiteten nun aktiv an einem rechtlichen Vorgehen, das sogar in einer Klage münden könnte. In einem ersten Schritt ist laut Bloomberg [3] aber erst ein „blauer Brief“ geplant, in dem Apple darauf aufmerksam gemacht wird, dass es Vertragsbruch betreibe. Um mit dem Problem umzugehen, hat sich OpenAI dem Bericht zufolge in den letzten Tagen auch Hilfe von externen Anwälten geholt.
Dass überhaupt ein Vorgehen auf juristischer Ebene geplant wird, deutet darauf hin, dass die Kooperation offenbar zerrüttet ist. Ob es dann letztlich zu einer tatsächlichen Klage kommt, ist aber noch unklar. OpenAI hatte sich unter anderem erhofft, durch die Partnerschaft mehr Abonnenten zu erhalten, die bereit sind, mindestens knapp 23 Euro im Monat [4] für ChatGPT zu zahlen, was dem geplanten Börsengang helfen würde. Doch das soll so nicht passiert sein. Dafür macht OpenAI offenbar Apple verantwortlich. Dort habe man sich eine tiefere Integration in den Apple-Apps sowie eine bessere Platzierung bei der Sprachassistentin Siri erhofft. OpenAI findet, dass ChatGPT nicht leicht genug aufzufinden ist.
Apple soll unterdessen intern Bedenken gegenüber einer tieferen ChatGPT-Integration gehabt haben. Das Unternehmen zweifelt daran, dass OpenAI die Nutzerdaten adäquat schützt. Tatsächlich lässt sich ChatGPT unter iOS, iPadOS und macOS auch anonym nutzen, Apple hat dazu eine Art Proxy implementiert. Seit der Bekanntgabe der Partnerschaft, für die Apple angeblich kein Geld zahlt (OpenAI aber auch nicht), gab es jedoch eine ganze Reihe von Änderungen an der Situation zwischen den beiden Unternehmen. So hat sich Apple entschieden, Googles Gemini als offiziellen KI-Partner [5] in seine Systeme zu holen, um etwa Siri endlich schlauer [6] zu machen. Dabei bekommt Apple tiefen Zugriff auf das Modell und kann es zum Teil auch in eigenen Rechenzentren ausführen, was mit OpenAI nie möglich war.
Weiterhin entwickelt sich der ChatGPT-Macher zum direkten Apple-Konkurrenten: Nach Anwerbung von Ex-Apple-Designboss Jony Ive soll der Konzern an KI-Gadgets [7] beziehungsweise zuletzt gar an einem eigenen Smartphone gearbeitet haben. All das kann Apple nicht schmecken und dürfte die Beziehung belasten. Laut Angaben von Bloomberg will OpenAI jedoch erst dann gegen Apple klagen (sollte es tatsächlich dazu kommen), wenn ein langwieriger Prozess zwischen OpenAI und Elon Musk [8] beendet ist, bei dem es letztlich um die Herrschaft über OpenAI geht.
URL dieses Artikels:
https://www.heise.de/-11294733
Links in diesem Artikel:
Copyright © 2026 Heise Medien
