Microsoft kündigt eine Desktop-Umgebung für die Softwareentwicklung mit Künstlicher Intelligenz an. Nachdem der kleine Ausblick auf das kommende Surface Laptop Ultra auf der Computex bereits für Aufsehen gesorgt hat, legt Microsoft jetzt mit einer Desktop-Variante auf Grundlage des neuen RTX Spark von Nvidia nach: Surface RTX Spark Dev Box.

„Traummaschine für Entwickler“

„Wir haben uns gesagt, lass uns diese Architektur bis an die Grenzen ausreizen und eine Maschine für Entwickler bauen”, sagte Microsoft-CEO Satya Nadella am Mittwochabend zum Auftakt der Entwicklerkonferenz Build in San Francisco. „Das ist wirklich eine Traummaschine.”

Die Traummaschine stellt sich einem kurzen Video in einem schwarzen Gehäuse mit einer Gitterstruktur vor. Über die inneren Werte verrät Microsoft bisher noch nicht viel. „Sie hat 1 Petaflop Rechenkapazität für KI und verfügt über 20 CPU-Kerne sowie 128 Gigabyte geteilten Speicher”, verriet Nadella. Die Dev Box kommt mit Windows 11 Pro und diversen vorinstallierten Entwicklerwerkzeugen.

Die Surface RTX Spark Dev Box soll wie das Surface Laptop Ultra im Herbst erhältlich sein. Weitere Einzelheiten wie mögliche Modellvarianten oder Preise gibt es noch nicht. Interessenten können sich bei Microsoft auf eine Warteliste eintragen lassen, sagte Nadella.

Grep kommt ins Terminal

Abgesehen von schicker Hardware will Microsoft den Entwicklern auch die Arbeit mit Windows erleichtern – und den Umstieg, wie Nadella bemerkte. Über 70 klassische Kommandozeilen-Tools aus der Linux-Welt wie grep halten Einzug ins Terminal. Auch einige Anwendungen wie Homebrew, die man von macOS kennt, sind künftig im Terminal verfügbar. Das Terminal in Windows werde mit eingebautem Copilot zu einem „intelligenten Terminal”, so Nadella.

(vbr)

Die Entwickler von uutils/coreutils haben Version 0.9.0 ihrer in Rust geschriebenen Neuimplementierung der GNU Core Utilities veröffentlicht. Das Release bringt vor allem Sicherheitsverbesserungen nach einem externen Audit, weniger unsafe-Code und schnellere I/O-Pfade durch Zero-Copy-Verfahren. Zudem erweitert die neue Version die Unterstützung für WebAssembly, Windows und Cygwin.

uutils/coreutils setzt die klassischen GNU Core Utilities in Rust neu um. Das Projekt liefert zahlreiche Standardwerkzeuge von Unix- und Linux-Systemen, darunter ls, cp, mv, rm, cat und sort. Ziel ist eine möglichst hohe Kompatibilität zu den GNU-Pendants – bei gleichzeitig besserer Speichersicherheit und Wartbarkeit durch Rust.

Sicherheitsaudit deckt TOCTOU-Schwachstellen auf

Im Mittelpunkt des Releases stehen Sicherheitsverbesserungen, die auf ein Audit der Firma Zellic zurückgehen. Die Prüfer fanden vor allem TOCTOU-Schwachstellen (Time of Check, Time of Use) und Probleme bei Randfällen im Dateisystem. Bei TOCTOU-Lücken handelt es sich um Race Conditions: Der Zustand einer Datei kann sich zwischen einer Prüfung und ihrer tatsächlichen Verwendung ändern – und genau diese Lücke lässt sich ausnutzen.

Die Maintainer betonen, dass die dabei vergebenen 44 CVEs keine klassischen Speicherfehler beschreiben. Das Audit habe vielmehr Verhaltensunterschiede zu GNU Coreutils aufgedeckt, die in bestimmten Situationen sicherheitsrelevant werden können. Version 0.9.0 schließt nach Projektangaben einen Großteil dieser Befunde.

Dafür führt das Projekt ein neues Modul namens uucore::safe_copy ein, das Kopiervorgänge gegen TOCTOU-Angriffe absichert. Auch die rekursiven Operationen von cp, mv und chmod erhalten entsprechende Schutzmechanismen. rm geht robuster mit problematischen Pfadangaben wie . und .. um. nohup legt die Datei nohup.out nun mit den restriktiven Zugriffsrechten 0600 an. Und chroot löst Benutzer- und Gruppen-IDs bereits auf, bevor es in die neue Wurzelumgebung wechselt.

Weniger unsafe-Code, Umstieg auf rustix

Parallel dazu reduziert das Team weiter den Anteil an unsafe-Code. Zahlreiche Stellen in Werkzeugen, Tests und gemeinsamen Bibliotheken kommen jetzt ohne unsichere Speicher- oder Systemzugriffe aus. In vielen Bereichen ersetzt das Projekt zudem die bisher genutzten Bibliotheken nix und libc durch rustix. Diese stellt Systemaufrufe über stärker typisierte Rust-Schnittstellen bereit und vermeidet so eine Reihe typischer Fehlerquellen. Die Umstellung betrifft unter anderem id, tr, timeout, sort, wc, tail, cp und who.

Für mehr Tempo sorgen neue Zero-Copy-Datenpfade unter Linux. Mehrere Werkzeuge nutzen jetzt verstärkt die Syscalls splice(), tee() und pipe(), um Daten direkt zwischen Kernel-Puffern zu übertragen. Da die Daten dabei nicht mehr durch den Adressraum des Prozesses wandern, sinken Speicherzugriffe und CPU-Last. Profitieren sollen unter anderem cat, wc, head, tail, cp, tee, yes und unexpand. Für unexpand nennen die Entwickler einen Geschwindigkeitsgewinn von rund 7,5 Prozent. Auch cp und tee arbeiten beim Verarbeiten von Pipe-Daten spürbar schneller.

GNU-Kompatibilität: neue Referenz, mehr Tests

An der GNU-Kompatibilität arbeitet das Projekt weiter intensiv. Als Referenz dient nun GNU Coreutils 9.11 statt 9.10. Die Zahl der fehlschlagenden Tests in der GNU-Testsuite steigt dadurch von 21 auf 56 – laut Projekt jedoch ohne Regressionen. Die Ursache liegt in 25 neuen Tests, die GNU der Suite hinzugefügt hat und die uutils noch nicht vollständig besteht. Weitere Kompatibilitätskorrekturen betreffen numfmt, date, tr, cksum, factor, head, stat und sort.

Besonders umfangreich fallen die Änderungen an numfmt aus. Das Werkzeug formatiert numerische Werte jetzt präziser, weist wissenschaftliche Notation zurück und beachtet die Locale-Einstellung LC_NUMERIC für das Dezimaltrennzeichen. Hinzu kommen Anpassungen bei Rundung, Vorzeichen und der Verarbeitung mehrbytiger Suffixe.

Auch ls erhält mehrere Korrekturen und Erweiterungen. Sie betreffen symbolische Links, die Versionssortierung und die rekursive Verzeichnisauflistung. Zudem haben die Entwickler den Code so umgebaut, dass andere Programme ls als Bibliothek einbinden können, ohne dessen Ausgabe zwingend auf die Standardausgabe umzuleiten. Als Beispiel nennt das Projekt die Shell Nushell.

Mehr Plattformen, mehr Locales

Beim Plattformsupport legt Version 0.9.0 ebenfalls zu. Die Werkzeuge ln, dd, mktemp und tty laufen jetzt auch unter dem WebAssembly System Interface (WASI), das WebAssembly-Anwendungen außerhalb des Browsers standardisierten Zugriff auf Betriebssystemfunktionen erlaubt. Daneben verbessern die Entwickler die Unterstützung für Windows, MSYS2 und Cygwin und arbeiten weiter an der Portierung auf OpenBSD. Schließlich berücksichtigen jetzt auch numfmt und du regionale Einstellungen für das Dezimaltrennzeichen über LC_NUMERIC.

Alle Details zum Update finden sich in den Release Notes auf der GitHub-Projektseite.

(fo)

Im heutigen Beitrag meines C++-Blogs möchte ich auf die statische Reflexion in C++26 eingehen. Einer der großen Vorteile von Reflexion ist, dass wir die neue Funktion bereits ausprobieren können, da mit Clang ein Compiler verfügbar ist, der alle Facetten implementiert. Und auch der jüngst erschienene GCC 16 implementiert das Feature bereits.

Anhand meiner typischen Anwendungsfälle habe ich untersucht, welche Aufgaben sich mit Reflexion besser lösen lassen. Eine Aufgabe, die mich den größten Teil meiner Karriere beschäftigt hat, war das Lesen und Schreiben von Daten, die über eine Netzwerkverbindung kamen. Die Definition von „Netzwerk“ war zu verschiedenen Zeiten unterschiedlich. Gemeinsam war jedoch, dass alles, was gesendet wurde, in Netzwerk-Byte-Reihenfolge (Big-Endian) verschickt wurde, und alles, was empfangen wurde, ebenfalls in Netzwerk-Byte-Reihenfolge ankam. Für manche Systeme machte das keinen Unterschied, da sie bereits Big-Endian-Maschinen waren. Aber nicht immer. Vor allem ARM setzte auf Little-Endian. Bei einem Teil der Systeme mussten die Daten beim Empfangen oder Senden daher byteweise vertauscht werden.

Wie tauscht man Daten?

Das Problem hier (war), wie tauscht man die Daten? Jeder Datentyp, der größer als ein Byte ist, muss jedes Mal getauscht werden. C++23 hat uns std::byteswap gegeben, wodurch POSIX-Funktionen wie htons überflüssig geworden sind. Das bedeutet zumindest eine Verbesserung im Hinblick auf Sicherheit.

Fangen wir mit einem Beispiel an. Der folgende Code zeigt die Datenstrukturen, die ich heute verwende.

enum class Color16 : uint16_t
{
};

struct RGB48 {
  Color16 red;
  Color16 green;
  Color16 blue;

  auto operator<=>(const RGB48&) const = default;
};

struct LEDState {
  bool  state;
  RGB48 rgbColor;

  auto operator<=>(const LEDState&) const = default;
};

struct LEDStateMessage {
  uint32_t messageId;
  LEDState state;

  auto operator<=>(const LEDStateMessage&) const = default;
};

Wie du sehen kannst, ist die letzte Struktur LEDStateMessage später die Wurzel. Diese Struktur enthält eine Struktur, die wiederum eine Struktur enthält. Wir gehen es heute also rekursiv an.

Alle structs verfügen über einen Dreiwege-Vergleichsoperator – das erleichtert die Überprüfung.

Was ich erreichen möchte, sieht in etwa so aus:

LEDStateMessage msg{.messageId = 3,
                    .state{.state = true,
                           .rgbColor{.red   = Color16{0x5u},
                                     .green = Color16{0x28u},
                                     .blue  = Color16{0x40u}}}};

Serialize(msg);

Die Daten sollten ausgetauscht oder besser noch an Ort und Stelle serialisiert werden. Ich gehe von einem System mit Speicherbeschränkungen aus, bei dem ich es mir nicht leisten kann, doppelt so viel Speicher zu verbrauchen.

Denke jetzt mal einen Moment darüber nach, wie viel Mühe du dir in der Vergangenheit gegeben hast, damit Serialize funktioniert. Ich für meinen Teil kann sagen, dass es mich viele Stunden gekostet hat.

Reflexion zur Rettung

Bist du bereit? Okay, hier kommt es:

template
requires(not std::is_pointer_v) and std::is_trivially_copyable_v
constexpr void Serialize(T& data)
{
  if constexpr(std::is_array_v) {  // #A
    for(int i{}; i < std::size(data); ++i) { Serialize(data[i]); }

  } else if constexpr(std::is_enum_v) {  // #B
    data = static_cast(std::byteswap(std::to_underlying(data)));

  } else if constexpr(not std::is_class_v) {  // #C
    data = std::byteswap(data);

  } else {  // #D
    static constexpr auto members =
      std::define_static_array(std::meta::nonstatic_data_members_of(
        ^^T, std::meta::access_context::current()));

    template for(constexpr auto& mem : members) { Serialize(data.[:mem:]); }
  }
}

Die Implementierung von Serialize besteht aus vier Teilen. In Abschnitt #A prüft Serialize, ob es sich um ein Array handelt. Wenn der Datentyp passt, ruft die Implementierung Serialize für jedes Element des Arrays auf.

Als Nächstes prüft die Implementierung in #B, ob der Datentyp ein enum ist. In diesem Fall wird C++23s std::to_underlying zusammen mit std::byteswap verwendet, um die Bytes tatsächlich zu vertauschen.

Nun wird in #C, falls dieser Datentyp kein Klassentyp ist, std::byteswap auf die Daten angewendet.

So weit, so gut. Bisher ist das alles generischer Code, den du schon vor C++26 so schreiben konntest. Der knifflige Teil sind die Datenelemente von Klassentypen. Genau das wird in #D behandelt.

Dank der Reflexion-Fähigkeiten durchläuft die Implementierung alle Datenelemente der Klasse und ruft für jedes davon Serialize auf. Et voilà, ein hervorragender erster Entwurf einer generischen Serialisierungsfunktion.

(Matthias Parbel)