Warum Tools als eigenständige statische Binärdateien ausgeliefert werden sollten

• Wenn Tools als eigenständige statische Binärdateien ausgeliefert werden, können Nutzer sie ohne separate Installation einer Entwicklungsumgebung oder Toolchain sofort verwenden
• Der Kompilierungsprozess dient als zusätzliche Sicherheitsbarriere, die die Wahrscheinlichkeit verringert, dass fehlerhafter Code ausgeliefert wird
• Tools auf Basis interpretierter Sprachen verursachen einen hohen Wartungsaufwand, etwa durch die Installation zahlreicher Abhängigkeiten und verschwendeten Speicherplatz sowie wiederholte Neuinstallationen bei Upgrades
• Je mehr Abhängigkeiten vorhanden sind, desto größer werden Sicherheitslücken und die Angriffsfläche, wodurch leichter Hacking-Risiken oder Wartungsprobleme entstehen
• Statische Binärdateien auf Basis kompilierter Sprachen sind von Veränderungen der externen Umgebung nicht betroffen und gewährleisten deshalb auch nach der Auslieferung eine stabile Nutzbarkeit

---

Vorteile der Auslieferung eigenständiger statischer Binärdateien

Sofort nutzbar ohne Installation

• Wie im Fall von OpenAI, das Codex in Rust neu aufgebaut und TypeScript aufgegeben hat, können Nutzer bei der Auslieferung einer einzelnen Binärdatei aus einer kompilierten Sprache diese sofort ausführen, ohne zusätzliche Toolchains installieren zu müssen
• Der größte Vorteil ist nicht Geschwindigkeit oder Effizienz, sondern dass das Tool ohne Installation direkt genutzt werden kann

Der Compiler als zusätzliche Sicherheitsbarriere

• Prüfungen während des Kompilierens verringern die Wahrscheinlichkeit, dass fehlerhafter Code ausgeliefert wird
• Als Beispiel wurde die Google Cloud CLI auf Python-Basis mehrfach in einem nicht ausführbaren Zustand ausgeliefert
• Selbst große Teams können solche Probleme kaum vermeiden; für kleine Teams ist es noch schwieriger, Tools auf Basis interpretierter Sprachen stabil auszuliefern

Keine Toolchain-Abhängigkeiten erforderlich

• Tools auf Basis kompilierter Sprachen müssen nur als einzelne Binärdatei ausgeliefert werden, während Tools in interpretierten Sprachen wie Python, Ruby oder TypeScript zwingend die jeweilige Entwicklungsumgebung benötigen
• Wie bei mdl (Markdown-Linter), das in Ruby geschrieben ist, ist eine Neuinstallation nötig, sobald die Entwicklungsumgebung (Ruby) aktualisiert wird
• Bei der Nutzung von markdownlint auf JavaScript-Basis müssen npm und mehr als 44 Abhängigkeiten installiert werden

Problem des verschwendeten Speicherplatzes

• Der beliebte FOSS-Coding-Assistent aider ist in Python geschrieben und installiert bei der Installation über Homebrew zusätzlich 51 Pakete
• Der tatsächliche Speicherverbrauch steigt dadurch um mehr als 3 GiB, was größer ist als der Umfang der meisten Linux-Distributionen
• Dagegen lässt sich der in Rust geschriebene Paketmanager uv allein mit einer 35 MiB großen Binärdatei installieren; weder Rust selbst noch rustup sind nötig

Mehr Sicherheitslücken

• Je mehr Abhängigkeiten ein Tool hat, desto größer werden die Angriffsfläche und die Wahrscheinlichkeit, Sicherheitslücken ausgesetzt zu sein
• Das Codex-Paket von OpenAI hat 24 direkte und 184 indirekte Abhängigkeiten
• Selbst wenn OpenAI alle Abhängigkeiten prüft, sind die Versionsstände nicht festgeschrieben, sodass durch spätere Updates Probleme wie Sicherheitslücken, bösartige Pakete oder Funktionsausfälle entstehen können

Einfachere Wartung

• Tools auf Basis interpretierter Sprachen wie JavaScript, TypeScript oder Python funktionieren nicht mehr, wenn Abhängigkeiten entfernt werden
• Wie der left-pad-Vorfall zeigte, kann schon das Entfernen eines einzelnen Pakets große Services und Tools lahmlegen
• Kompilierte Sprachen benötigen Abhängigkeiten nur zum Build-Zeitpunkt, sodass das Tool auch dann weiterhin normal funktioniert, wenn externe Repositories später verschwinden

Erfahrungen des Autors

• Der Autor hat früher Tools wie adb-enhanced in Python entwickelt, später jedoch verschiedene Tools wie gabo und wp2hugo in Go als Open Source veröffentlicht
• Die Entwicklung eigenständiger Tools in Python, TypeScript und ähnlichen Sprachen wird nicht mehr in Betracht gezogen
• Empfohlen wird die Nutzung von Sprachen, mit denen sich statisch gelinkte Binärdateien ausliefern lassen (Rust, Go, C++ usw.)

Fazit

• Eigenständige Tools sollten in kompilierten Sprachen wie Rust, Go oder C++ entwickelt werden
• Sie sollten als statische Binärdateien mit möglichst wenigen externen Abhängigkeiten ausgeliefert werden

[rikko]

Dem Problem der Verschwendung von Speicherplatz kann ich ziemlich gut nachempfinden ...
Ich betreibe AKS, und jedes Mal, wenn ich eine Python-App mit einem Container-Image von über 1 GB sehe, bekomme ich Kopfschmerzen.
Im Moment nehme ich mir einfach das Dockerfile, reduziere die Größe selbst und lade es dann hoch; wenn ich es nicht unter 500 MB bekomme, gebe ich einfach auf, haha

[eususu]

Es gibt ein Paket, dessen Abhängigkeiten von pytorch+cuda sich nur in der Version unterscheiden … wirklich ein Trauerspiel.
Obwohl das Ding kaum Funktionen hat, werden für jeden kleinen Daemon fast 2 GB an Abhängigkeiten installiert …

[rikko]

Wenn es sich um eine CPU-Laufzeit nur für einfache Inferenz handelt, ist die Lage noch etwas besser, aber wegen der heute geforderten LLM-Dienste steigen sowohl der Traffic als auch die benötigte Kapazität immer weiter, sodass einem bei der Kostenkalkulation echt das Fluchen kommt lol