Was bedeutet es, dass Ubuntu Rust verwendet?

• Die Einführung von Rust bei Ubuntu zeigt, dass Rust sich im Technologie-Adoptionszyklus von den Early Adopters über den Chasm hinweg in Richtung Mainstream bewegt
• Canonical hat Rust als Standardsprache für neue Basis-Software übernommen und ersetzt damit den Einsatz von C, C++ und teilweise Python; zugleich investiert das Unternehmen finanziell und reputativ in die Entwicklung speichersicherer Utilities
• Nutzer der Early Majority wünschen sich „Industriestandard“ und Kompatibilität mit bestehenden Workflows; daher ist der Austausch von Utilities als Drop-in ein zentraler Ansatz, um den Chasm zu überwinden
• Das Thema Erweiterung der Standardbibliothek von Rust rückt erneut in den Fokus; das 2016 abgelehnte Konzept einer „Rust Platform“ könnte für die Early Majority sogar besser geeignet sein
• Eine Struktur, die wachsende Adoption in Investitionen übersetzt, sowie die auf Empathie basierende Offenheit der Open-Source-Community sind essenziell für Rusts nächste Wachstumsphase

---

Rusts „Überschreiten des Chasm“ ist je nach Bereich unterschiedlich

• Ob Rust den Technology Adoption Life Cycle bereits über den Chasm hinweg durchlaufen hat, hängt vom jeweiligen Bereich ab
• Innerhalb von Amazon ist Rust für große Data Planes oder den Bau ressourcenbewusster Agenten fest etabliert, während es für allgemeine Entwicklung weiterhin oft als überdimensioniert gilt
• Im Bereich Safety Critical Software gibt es Erfolgsgeschichten, doch der Großteil der Branche befindet sich weiterhin im Abwartemodus

Die Bedeutung von „Referenzkunden“

• Der Schlüssel zum Überschreiten des Chasm ist die Gewinnung von Referenzkunden (reference customers)
• Early Adopters kaufen den „Change Agent“, die Early Majority will dagegen die Produktivität bestehender Abläufe steigern und Diskontinuitäten minimieren
• Der überzeugendste Faktor für die Einführung neuer Technologie ist, erfolgreiche Beispiele aus Organisationen zu sehen, die der eigenen ähneln
• Der Rust-Erfolg des S3-Teams ist für große Service-Teams überzeugend, hat aber für CRUD-Service-Teams nur begrenzte direkte Überzeugungskraft

Ubuntus (Canonical) Strategie zur Rust-Einführung

• Auf der Rust Nation hielt Canonical-VP of Engineering Jon Seager die Keynote „Rust Adoption At Scale with Ubuntu“
• Canonical hatte seine internen Entwicklungssprachen bislang auf Python, C/C++ und Go beschränkt, hat inzwischen aber Rust hinzugefügt und als Standardsprache für neue grundlegende Arbeiten übernommen
• Ähnlich wie Lars Bergstroms Keynote zur Rust-Einführung bei Google verbindet dieser Ansatz Vision und Pragmatismus zugleich
  • Genau diese Eigenschaften sind nötig, um den Übergang von den Early Adopters zur Early Majority zu schaffen

Investitionen in speichersichere Utilities

• Jon Seager sagte, Ubuntu solle den Aufbau von Utilities auf Basis von Memory Safety im Sinne von „pay it forward“ unterstützen
• Canonical fördert finanziell die Entwicklung von sudo-rs und ntpd-rs der Trifecta Tech Foundation sowie die coreutils-Arbeiten von uutils
• Das Modell besteht darin, dass Ubuntu Neues zuerst ausprobiert und validiert, damit anschließend auch andere Distributionen davon profitieren können
• Drop-in-Utilities, die sich unverändert in bestehende Workflows einfügen, entsprechen dem Wunsch der Early Majority nach minimaler Diskontinuität

Anforderungen neuer Anwender: Erweiterung der Standardbibliothek

• Bei einem Abendessen erklärte Jon Seager, Rust müsse seine Politik einer kleinen Standardbibliothek überdenken
• Diese Forderung taucht seit Jahren immer wieder auf; statt einfach nur eine große Standardbibliothek bereitzustellen, wird als Alternative ein projektartiger Ansatz namens „Battery Packs“ erwogen
• Die 2016 vorgeschlagene Rust Platform — also die Idee, bestimmte Crates als erweiterte Standardbibliothek anzuerkennen — wurde damals von den Early Adopters abgelehnt, könnte aber für die Early Majority passend sein
  • Damals überwog die Ansicht, dass es ausreiche, Abhängigkeiten in Cargo.toml hinzuzufügen

Notwendige Veränderungen für weiteres Wachstum

• Für den Übergang von den Early Adopters zur Early Majority braucht es die Botschaft, dass Rust nicht „state-of-the-art“, sondern „industry standard“ ist
• Rust hat bei der Wahrnehmung in der Branche bereits viel erreicht; nun muss es zur besten Wahl werden, gemessen nicht daran, „was es sein könnte“, sondern „was es tatsächlich ist“
  • Zwischen diesen beiden Perspektiven kann es mitunter Spannungen geben
• Wer Pragmatiker ansprechen will, braucht Geduld, Verständnis für branchenspezifische Themen und Präsenz auf Branchenkonferenzen

Eine Struktur, die Adoption in Investitionen übersetzt

• Eine breitere Rust-Adoption führt zu mehr Nachfrage nach dem Rust-Projekt und seinem Ökosystem
• Für Open-Source-Organisationen wie Canonical sind $$ weniger wichtig als Beziehungsaufbau zwischen Organisationen und Beiträge
  • Die Entwickler von Rust for Linux erhielten anfangs Hilfe von Rust-Maintainern, beheben aber zunehmend selbst Bugs, während die Maintainer stärker in eine Mentorrolle wechseln
• Ein interessanter Trend ist, dass Finanzmittel oft eher von Unternehmen kommen, die Rust noch prüfen, als von solchen, die Rust bereits eingeführt haben
  • Einzelne Early Adopters innerhalb dieser Organisationen treiben die Einführung voran und stellen Budget für „Table-Stakes“-Funktionen bereit
• Laut Alexandru Radovici aus dem Rust Foundation Silver Member Directory verfügen viele Unternehmen im Bereich Safety Critical Software über Mittel, um Lücken in Rust zu schließen, wissen aber nicht, wie sie diese einsetzen sollen

Die Rolle von Open Source und die Bedeutung von Empathie

• Open Source ist eine hervorragende Plattform, um den Chasm zu überwinden, doch Cliquen und „mündliche Traditionen“ können Einstiegshürden schaffen
• Die Verwendung falscher Begriffe kann dazu führen, dass Ideen abgewiesen werden, und schon eine unhöfliche Antwort kann neue Beitragende vertreiben
• Was Rust in seiner nächsten Wachstumsphase am dringendsten braucht, ist Empathy in Open Source
• Entscheidend ist, Orte zu finden, an denen Rust Menschen helfen kann, und dort Unterstützung zu leisten und sie zu befähigen

[GN⁺]

Hacker-News-Kommentare

• Dass Ubuntu Userland ohne GPL-Lizenz nutzt, bedeutet, dass im Linux-Ökosystem mehr TiVoization möglich wird
  In Kombination mit der Richtung, in die Amutable aus dem systemd-Lager steuert, könnten geschlossene Linux-Distributionen entstehen, die Nutzer nicht mehr verändern können
  Aus Unternehmenssicht kann eine geschlossene Umgebung mit vollständiger Signaturprüfung attraktiv sein. Eine Welt, in der selbst „ls“ oder „cd“ Closed Source sind, wirkt auf seltsame Weise apokalyptisch

  • util-linux oder BSD verschwinden deshalb nicht. Wenn dir Ubuntu nicht gefällt, musst du es nicht nutzen. Debian war deutlich stabiler
  • Es gibt schon einen Grund, warum man früher von GNU/Linux sprach. Android/Linux hat ebenfalls kein GPL-Userland, und die meisten Embedded-Konkurrenten auch nicht. Am Ende ist Linux eben nur der Kernel
  • Historisch gesehen bin ich vielleicht naiv, aber ich halte solche Veränderungen nicht zwangsläufig für schlecht. Ich bevorzuge Open-Source-Utilities, aber ich finde es auch okay, wenn es Closed-Source-Alternativen gibt, die die Spezifikation einhalten. Unternehmen könnten auf diesem Weg auch mehr Geld in Open-Source-Projekte stecken
  • Ehrlich gesagt ist Ubuntu für mich eher das Apple der Linux-Welt, das mehr über Marketing als über Qualität gewinnt. Debian-basierte Systeme nutzt man wegen der niedrigen Wartungskosten, und ich persönlich halte Fedora oder OpenSUSE für die Zukunft
  • Wenn durch solche Veränderungen am Ende 95 % der Linux-Nutzer dasselbe OS verwenden, wäre das vielleicht gar nicht so schlecht

• Die echte Kluft (chasm), die Rust überwinden muss, ist Unterstützung für dynamisches Linken mit sicherer ABI
  Erst wenn man eine Bibliothek ändern kann und die Sicherheit dabei erhalten bleibt und zugleich ABI-Stabilität auf C-Niveau erreicht wird, kann Rust im C/C++-Lager wirklich angenommen werden

  • Rust kann bereits über die C-ABI kommunizieren. Es bietet dynamisches Linken auf demselben Niveau wie C++
  • Die ABI-Stabilität von C++ ist ein Hauptgrund dafür, dass sich die Sprache schwer weiterentwickeln kann. Man kann das Klassenlayout der STL nicht ändern, und in Headern implementierte Templates lassen sich später nur schwer optimieren. Rust sollte so eine „stable ABI“ gerade nicht unterstützen
  • Die Effizienz von Rust beruht auf Monomorphisierung zur Compile-Zeit. Für eine ABI müsste man Spezialisierung zur Link-Zeit berücksichtigen. Es reicht nicht, die Code-Erzeugung einfach an den Linker zu verschieben, man muss die „shape“ von Funktionsparametern sorgfältig behandeln
  • Dynamisches Linken ist auch in Debug-Builds hilfreich, um Kompilierzeiten zu verkürzen. Unveränderte Bibliotheken müssen nicht neu gebaut werden, und der Laufzeit-Overhead ist minimal
  • Schade, dass die Rust-Community MIT gegenüber GPL bevorzugt. GPL ist nutzerfreundlich, MIT ist unternehmensfreundlich. Ich finde problematisch, dass sich die „Rewrite-it-in-Rust“-Bewegung mehr auf die Verbreitung der Sprache als auf den Schutz der Nutzer konzentriert

• Größer als die Einführung von Rust bei Ubuntu ist das Problem, dass man für wichtige Builds immer noch curl|bash-Skripte verwendet
  Ein Blick in firefox-snaps snapcraft.yaml macht das klar

  • Bei „curl|bash“ denkt man meist an willkürliche Konfigurationsänderungen oder Änderungen an .bashrc, aber hier wird nur ein Installationsskript für eine statische Toolchain ausgeführt. Das ist sehr 90er, aber vergleichsweise sicher
  • In vielen Distributionen ist die Rust-Version viel zu alt. Das Rust in Debian oder Ubuntu LTS ist hoffnungslos veraltet, daher scheint man statisches Linken nicht zu mögen
  • Selbst wenn man etwas per curl ausführt, ist es okay, solange man die Hash-Prüfung sauber macht

• Dass das Rust-Coreutils-Projekt unter MIT-Lizenz steht, bereitet mir Unbehagen
  Die Philosophie der FSF wird zwar kritisiert, aber die GPL schützt Open Source. Wenn Canonical ganz Ubuntu auf MIT umstellt, ist unklar, was dann passiert

  • Die GPL war früher mächtig, aber inzwischen wird sie dank automatisierter Copyright-Waschsysteme oft in MIT/BSD- oder proprietären Code umgewandelt. Auch die FSF hat dafür keine Lösung
  • Lizenzdebatten enden nie. Die GPL schränkt die Verbreitung ein, MIT ist flexibler. Letztlich hängt alles davon ab, was das Ziel ist — ob man OSS will, das jeder verwenden kann, oder ob man verhindern will, dass Unternehmen ohne Beiträge Profit daraus schlagen
  • Ich frage mich, welche konkreten „bösen Taten“ dadurch überhaupt möglich werden, dass Coreutils unter MIT steht

• Wegen rust-coreutils ließ sich das CUDA Toolkit nicht installieren. Ein zugehöriges Issue gibt es im NVIDIA-Forum

  • Im verlinkten Thread ging es wohl um ein Problem mit gzip. An dd lag es offenbar nicht
  • Ehrlich gesagt hat rust-coreutils keinen Existenzgrund. Nach einer Ubuntu-Installation sollte man als Erstes die echten coreutils und sudo neu installieren

• Das Konzept „Crossing the chasm“ ist interessant. Neben dem Fall der Coreutils in Ubuntu gibt es noch viele andere Kluften, die Rust überwinden will
  Es gibt Rust for Linux oder Rust in der Autoindustrie, aber bislang wirkt das alles noch auf Treiber-Ebene begrenzt

  • Rust expandiert in viele Richtungen. pyo3 (Ersatz für Python-Module), Dioxus (React-ähnliches Web-Framework), Ferrocine (Compiler für die Autoindustrie) sind typische Beispiele. Auch das DARPA-TRACTOR-Projekt beschleunigt die Einführung von Rust
  • Im Dokument zu Rusts Project Goals (Link) sieht man, worauf die Community ihre Investitionen konzentriert
  • Rust selbst ist großartig, aber Teile der Community schreiben bestehende stabile Software nur „in Rust neu“ und kapern damit die Marke. Auch Ubuntu scheint auf so eine Art Virtue Signaling hereinzufallen

• Die Logik, die Standardbibliothek später auszutauschen, ist gefährlich. Nutzer wollen nicht „Klüfte“, sondern stabile Systeme mit hoher Qualität

  • Bei Rust wird die stdlib nicht wirklich „ausgetauscht“, sondern Erweiterungen hinzuzufügen ist leicht. Alle 6 Wochen erscheint ein neues Release, und jedes Mal kommen mehr als 10 Funktionen hinzu. Schon jetzt sind Hunderte Features in der stdlib gelandet

• Die Unreife des Rust-Ökosystems ist ein Hindernis für die Einführung. Viele Crates sind noch vor Version 1.0 oder nur einfache C-Wrapper. Bei Kryptografie ist das okay, aber etwas wie SAML ist schwer zu finden

  • Über pre-1.0-Versionen würde ich mir nicht zu viele Sorgen machen. Wegen der Kultur, SemVer streng einzuhalten, wird die 1.0 oft bewusst hinausgezögert. Bei Crates wie libc, die tief mit APIs verflochten sind, ist eine Versionsanhebung ohnehin schwierig. Ich schaue persönlich oft auf kuratierte Listen wie blessed.rs
  • gettext hat auch erst nach 30 Jahren Version 1.0 erreicht
  • Das Python-Modul cryptography verlangte eine Rust-Toolchain, weshalb es sich unter Termux nicht installieren ließ. Es ist lästig, wenn selbst Python-Projekte durch Rust-Abhängigkeiten schwergewichtig werden

• Es gibt Bewegungen, C++-Code per „Vibe-Translation“ nach Rust zu übertragen und dabei die Lizenz zu ändern. sudo-rs hat zum Beispiel sogar eine schlechtere Sicherheitsbilanz als die C-Version

  • Die Propaganda rund um Rust, KI und Sicherheit ist übertrieben. Anfangs mochte ich Rust sehr, aber die MIT-Lizenzdebatten und das überzogene Marketing ermüden mich zunehmend

• Die riesige Standardbibliothek von .NET ist wirklich angenehm. Die meisten Aufgaben lassen sich auf Standardweg lösen, und wenn es merkwürdige Implementierungen gibt, treibt die Mehrheit meist eine Standardisierung voran

  • Ich halte Rusts kleine stdlib für einen Fehler. Die stdlib ist die einzige Abhängigkeit, die immer vorhanden ist, also sollte sie, auch wenn sie nicht perfekt ist, mehr Werkzeuge enthalten
  • Aus Sicht von Systemprogrammierern ist eine große stdlib aber eher ein Problem. .NET basiert auf GC, da ist das weniger relevant, aber Rust oder C++ müssen auch in Bare-Metal-Umgebungen laufen. Eine große stdlib ist in speicherbeschränkten Umgebungen (<64K) eine Belastung
    Rusts std/core ist schon jetzt so groß, dass man auf Mikrocontrollern Tricks wie weak symbols braucht.
    Eine kleine stdlib ist für API-Stabilität und geringeren Wartungsaufwand im Vorteil. C++ hat unter genau diesem Problem gelitten, daher sollte Rust vorsichtig sein