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

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

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

HummingbirdOS ausprobieren

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

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

(fo)

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

Viel Neues für den Prozessstart

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

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

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

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

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 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.

(De)-Komprimierung mit Span

In .NET 11.0 Preview 1 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 und ReadOnlySpan 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");
 
ReadOnlySpan sourceSpan = File.ReadAllBytes(BIGFILEPATH);
Console.WriteLine("Länge=" + sourceSpan.Length);
long maxCompressedLength = ZLibEncoder.GetMaxCompressedLength(sourceSpan.Length);
Span 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");
 
// 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

Parsen von Hex-Werten

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
}

Prüfung auf Gültigkeit bei UTF8 und UTF16

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 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 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));

Utf8JsonWriter mit abweichenden Einstellungen wiederverwenden

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.

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

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

Neue Architektur trennt Tracks und Codecs

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

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

Weniger Kopien, mehr Metadatenformate

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

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

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

Neu geschriebene Demuxer und SIMD ab Werk

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

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

Genauere Formaterkennung und neue MSRV-Policy

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

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

(fo)