Ein Plädoyer für schlanke Software im Jahr 2024

• In einer Realität, in der selbst für einfache Funktionen Tausende Abhängigkeiten und zig Millionen Zeilen Code eingesetzt werden, ist die Aufblähung von Software selbst eine große Ursache von Sicherheitslücken
• Sicherheit hängt nicht nur von der Bug-Dichte ab, sondern auch von der Gesamtmenge des Codes, den Angreifer erreichen können; eine unnötig große Angriffsfläche kann zu realen Kompromittierungen führen
• Die Ökosysteme rund um Electron JS, Node.js, Docker-Images sowie npm- und PyPI-Abhängigkeiten verschleiern Menge und Herkunft des ausgelieferten Codes, sodass selbst an einer Garagentor-App mehr als 50 Millionen Zeilen aktiven Codes beteiligt sein können
• Rust, Sanitizer und Fuzzer verbessern die Codequalität, doch logische Designfehler wie das automatische Ausführen von Code in Dokumenten lassen sich allein durch das Entfernen von Bugs nur schwer verhindern
• Trifecta bietet Bildfreigabe mit 1.600 Zeilen neuem Code, rund 5 Kernabhängigkeiten und insgesamt 3 MB und zeigt damit, dass sich moderne Software auch mit begrenztem Code und wenigen Abhängigkeiten bauen lässt

---

Der gefährliche Zustand der Softwaresicherheit

• Der jüngste Zustand der Softwaresicherheit ist sehr schlecht
  • In im Markt etablierten Produkten wie Ivanti, MOVEit, Outlook, Confluence, Barracuda Email Security Gateway und Citrix NetScaler ADC·NetScaler Gateway kam es im vergangenen Jahr zu schweren Sicherheitsvorfällen
  • Selbst ressourcenstarke Unternehmen wie Apple und Google begingen Sicherheitsfehler, die Kunden in Gefahr brachten
• Weil Software als zu riskant wahrgenommen wird, ist der Rat verbreitet, sie nicht direkt auszuführen, sondern X as a service oder der Cloud zu überlassen
• Auch die Annahme, dass die Cloud unsichere Software vertrauenswürdig mache, gerät ins Wanken
  • Die E-Mail-Plattform von Microsoft wurde kompromittiert, darunter vertrauliche Regierungs-E-Mails
  • Es bleiben Bedenken hinsichtlich der Sicherheit der Azure Cloud
  • Okta erlitt innerhalb von zwei Jahren den zweiten Sicherheitsvorfall, worauf verdächtig viele Hacks bei Okta-Nutzern folgten
• Die EU treibt drei Gesetzesvorhaben voran, um Softwaresicherheit zu adressieren
  • NIS2: für kritische Dienste
  • Cyber Resilience Act: für nahezu alle kommerziellen Softwareprodukte und elektronischen Geräte
  • Product Liability Directive: erweitert die Haftung auf Software

Schwachstellen entstehen aus Codequalität und Codemenge

• Softwaresicherheit hängt von zwei Achsen ab
  • der Dichte von Sicherheitsproblemen im Quellcode
  • der Menge an Code, auf die Hacker zugreifen können
• Je mehr Code vorhanden ist, desto größer wird das Risiko
  • Selbst bei niedriger Bug-Dichte lassen sich in Millionen Zeilen Code ausnutzbare Lücken finden
• Das Beispiel iMessage zeigt, welche Probleme eine vergrößerte Angriffsfläche schafft
  • Selbst unerwünschte iMessages werden auf dem iPhone sofort verarbeitet, um eine Vorschau zu erzeugen
  • Apple unterstützte zahlreiche Bildformate und verarbeitete sogar PDFs mit ungewöhnlich komprimierten Schriftarten
  • Diese alten Formate enthielten faktisch Programmiersprachen, über die Angreifer weitere Schwächen des Telefons erkunden konnten
• Apple hätte die Vorschau auf deutlich weniger Bildformate oder ein einziges „bekannt gutes“ Format beschränken und so die Angriffsfläche verkleinern können
• Auch der EU Cyber Resilience Act schreibt ausdrücklich vor, dass Anbieter die Angriffsfläche minimieren sollen

Besserer Code allein reicht nicht aus

• Es gibt bereits Bestrebungen, die Codequalität zu verbessern
  • speichersichere Sprachen wie Rust
  • Härtungswerkzeuge wie AddressSanitizer
  • Fuzzer, die Eingaben automatisch variieren, um Schwachstellen und Bugs zu finden
• Viele Sicherheitsprobleme entstehen jedoch nicht durch Bugs im Code selbst, sondern durch die zugrunde liegende Logik
• Die E-Mail-Schwachstelle bei Barracuda entstand, weil eine Drittanbieterbibliothek, die Excel-Tabellen zur Virenprüfung scannen sollte, tatsächlich Code ausführte
• Die Entscheidung, eine Funktion zum automatischen Ausführen von Code in Dokumenten einzubauen, lässt sich nicht lösen, selbst wenn alle Bugs im Code beseitigt würden

Nicht zu wissen, was man ausliefert

• Moderne Software ist so groß geworden, dass sich kaum noch erkennen lässt, was tatsächlich ausgeliefert wird
• Niklaus Wirth kritisierte bereits 1995 in „A Plea for Lean Software“, dass Software auf Megabyte-Größe angewachsen sei
  • Sein Betriebssystem Oberon war einschließlich Editor und Compiler 200 KB groß
  • Heute gibt es Projekte, deren Konfigurationsdateien allein schon mehr als 200 KB umfassen
• Eine typische App von heute kann auf Electron JS basieren
  • Electron JS enthält Chromium und Node.js
  • Node.js ermöglicht Zugriff auf Zehntausende JavaScript-Pakete
  • Schon durch den Einsatz von Electron JS können einschließlich Abhängigkeiten schätzungsweise mindestens 50 Millionen Zeilen Code einfließen
• Apps ziehen Hunderte bis Tausende Hilfspakete nach sich, und Abhängigkeiten bringen wiederum weitere Abhängigkeiten mit
  • Was genau in einem Build enthalten ist, kann sich täglich ändern
  • Manche Pakete können Nutzer standardmäßig Werbetreibenden oder Datenhändlern aussetzen
• Eine App zur Steuerung von Geräten im Haus kann zusätzlich an den Software-Stack von Amazon angebunden sein, der wiederum Node.js und zahlreiche Abhängigkeiten nutzt
• Im Ergebnis können selbst zum Öffnen eines Garagentors über mehrere Betriebssystem-Images und mehrere Server hinweg mehr als 50 Millionen Zeilen aktiven Codes laufen

Die Last von Containern und der Abhängigkeits-Lieferkette

• Früher wurden Compiler-Ausgaben oder Bündel interpretierter Dateien verteilt, und bei Installation und Konfiguration musste man darüber nachdenken, was im Paket enthalten war
• Heute werden oft per Container nicht nur die Software, sondern auch Betriebssystemdateien für die passende Laufzeitumgebung mit ausgeliefert
  • De facto wird häufig ein vollständiges Festplatten-Image eines Computers verteilt
  • Auf Docker Hub gibt es viele Images mit mehr als 350 MB
• Container können sinnvoll eingesetzt werden, doch je nach Nutzung die Menge des ausgelieferten Codes stark erhöhen
• Es ist zudem unklar, ob Sicherheitsupdates von Abhängigkeiten überhaupt bis in die finale App durchgereicht werden
  • Ob Bildverarbeitungsbugs, für die Google und Apple eilig Updates auslieferten, in Electron-Apps noch vorhanden sind, lässt sich nur schwer feststellen
• Das npm-Ökosystem hat eine Vorgeschichte mit übernommenen Paket-Repositories, Hijacking und der Wiederbelebung gleichnamiger Pakete
• Auch PyPI kämpft mit ähnlichen Problemen
• Abhängigkeiten müssen geprüft werden, doch es ist unrealistisch zu erwarten, dass Tausende davon regelmäßig kontrolliert werden
• Alles selbst neu zu implementieren ist ebenfalls keine Lösung; es gibt gute Module wie SQLite, die wahrscheinlich sicherer sind als selbst geschriebene Alternativen

Trifecta: Ein Bildfreigabe-Tool mit wenig Code

• Trifecta ist eine minimalistische, aber tatsächlich nutzbare eigenständige Software zur Bildfreigabe
• Bilder lassen sich im Browser per Drag-and-Drop einfach teilen
• Wer imgur nutzt, installiert viele Cookies und Tracker im Browser, und auch Betrachtern freigegebener Bilder können Tracker aufgezwungen werden
• Auch selbst gehostete Bildfreigabe-Tools basieren oft auf großen Frameworks und erschienen deshalb nicht vertrauenswürdig genug
• Trifecta wurde bewusst so klein gebaut, dass sich der gesamte Code in wenigen Stunden prüfen lässt
  • 1.600 Zeilen neuer Quellcode
  • etwa 5 wichtige Abhängigkeiten
  • 3 MB gesamte Codegröße
• Eine als Vergleich herangezogene andere Bildfreigabe-Lösung wird als 288-MB-Docker-Image ausgeliefert
• Eine weitere Node-basierte Foto-Sharing-Lösung brachte es auf 1.600 Abhängigkeiten und mehr als 4 Millionen Zeilen JavaScript
• Trifecta ist nicht für öffentliche Websites gedacht, auf denen beliebige Personen Bilder hochladen, sondern eher für Unternehmen oder den privaten Einsatz geeignet

Wenn Komplexität mit Stärke verwechselt wird

• Eine häufige Reaktion auf Trifecta war der Vorschlag, es als Amazon Web Services-Bündel bereitzustellen
  • Das geht am Ziel einer eigenständigen Software vorbei, die nicht von externen Diensten abhängt
• Es gab auch Kritik, Docker werde unfair behandelt, doch es wird anerkannt, dass Container sinnvoll eingesetzt werden können
• Niklaus Wirth wies schon 1995 darauf hin, dass Menschen dazu neigen, Komplexität mit Raffinesse zu verwechseln
• Nach Tony Hoare gibt es zwei Arten von Softwaredesign
  • Programme so einfach zu machen, dass sie offensichtlich keine Fehler enthalten
  • oder sie so kompliziert zu machen, dass sie offensichtlich keine Fehler zu enthalten scheinen
• Wirth sah Zeitdruck als eine Hauptursache für aufgeblähte Software
  • Zeitdruck behindert sorgfältige Planung
  • Er führt dazu, dass schnell ergänzt und geändert wird, statt akzeptable Lösungen zu verbessern
  • Er untergräbt schleichend die Qualitätsmaßstäbe und den Anspruch auf Vollendung von Ingenieuren
• Die Explosion der Softwaregröße ist kein Naturgesetz, sondern etwas, das Softwareingenieure verringern sollten

Weniger Code als Sicherheitsmaßnahme

• Die Welt liefert derzeit zu viel Code aus
  • Der Großteil stammt von Dritten
  • Ein Teil wird unbeabsichtigt mitgeliefert
  • Das meiste wird nicht ausreichend geprüft
• Das Ergebnis ist eine enorme Angriffsfläche, in der große Mengen an nur durchschnittlichem Code exponiert sind
• Bemühungen zur Verbesserung der Codequalität gehen weiter, doch viele Angriffe beruhen auf logischen Fehlschlägen, und bei deren Erkennung gibt es vergleichsweise wenig Fortschritt
• Schon die bloße Reduktion der Menge an Code, die der Welt ausgesetzt wird, kann eine große Verbesserung bringen
• Die Markteinführung von Produkten könnte sich verzögern, doch die kommende Gesetzgebung könnte Anbieter dazu zwingen, Sicherheit ernster zu nehmen
• Trifecta und Oberon zeigen, dass sich auch mit begrenztem Code und wenigen Abhängigkeiten viel Funktionalität bereitstellen lässt

[GN⁺]

Hacker-News-Kommentare

• In Vernor Vinges A Deepness in the Sky hat sich die Menschheit allein mit unterlichtschneller Technologie zwischen den Sternen ausgebreitet, und die Raumschiffe zwischen den Sternen zeigen eine Mischung aus alter Technik aus vielen Sternsystemen und Zivilisationen
  Auch die Computersysteme haben sich so lange weiterentwickelt, dass praktisch niemand den Großteil des Codes noch versteht; man benutzt ihn einfach weiter und stapelt neue Schichten darauf
  Besonders eine Figur ist ein uralter Systemingenieur aus früheren Zeiten, der durch lange Phasen aus Stillstand und Reisen zu den ältesten noch lebenden Menschen gehört; in einer Zukunft, in der alle immer mehr Schichten darauf aufbauen, ist sein Wissen darüber, wie die Systeme seiner Zeit funktionierten und wo ihre Schwachstellen lagen, plötzlich ein großer Vorteil
  Ich denke, Vinge hat da etwas sehr genau getroffen

  • Es gibt zwei Arten von „niemand weiß es“: „Niemand weiß, wie man Halbleiter bei Raumtemperatur herstellt“ und „Niemand weiß, warum meine Waschmaschine kaputtgegangen ist“
    Ersteres ist ein echtes Rätsel, das moderne Wissenschaft und sehr kluge Leute lösen müssen, letzteres ist eher eine Frage mangelnden Interesses
    Wenn man genug Geld bezahlt, könnte ein fähiger Ingenieur die Waschmaschine zerlegen und den genauen Defekt finden, aber niemand zahlt diese Kosten; man wirft sie einfach weg und kauft eine neue
    Altes Softwarewissen gehört klar zur zweiten Kategorie. Wenn man tief genug einsteigt, kann man jeden Teil letztlich vollständig verstehen, aber meistens ist es viel billiger und praktischer, ihn zu ignorieren oder noch eine weitere Schicht darüberzulegen
  • Das erinnert mich an Asimovs eher schwache Kurzgeschichte The Feeling of Power
    Darin hat die Menschheit der Zukunft die Grundrechenarten vergessen, und als jemand sie wiederentdeckt, wollen die Mächtigen sie für den Krieg nutzen; ich verstehe die Aussage, aber das Setting wirkt so unrealistisch und unfreiwillig komisch, dass es seine Wirkung verliert
  • Vinge lag definitiv richtig. Ich mag den Titel Programmer Archaeologist, weil er sehr gut beschreibt, was wir tatsächlich jeden Tag tun
    Wer weiter darüber diskutieren will, siehe http://lambda-the-ultimate.org/node/4424
  • Das erinnert mich an den Software-Archäologen in einem Roman von Alastair Reynolds. Ich glaube, es ging um Tau Ceti, und er war ein Spezialist, der sich durch Hunderte Jahre alten Code grub
    Wir haben dieses Problem schon heute. Mein Onkel, inzwischen in den Sechzigern, wartet alte Lkw-Speditionssoftware in COBOL, und solche Jobs mit Alttechnik gibt es tatsächlich. Wenn jemand Interesse hat, kann ich den Kontakt herstellen
    Das Grundproblem ist dasselbe wie beim left-pad-Vorfall. Man macht sich über Junior-Ingenieure ohne Aufsicht lustig, die Abhängigkeiten gedankenlos installieren, aber über Jahrzehnte und mehrere Generationen von Entwicklern hinweg stützt sich am Ende fast jede Software zumindest teilweise auf undurchsichtige Abhängigkeiten
    Stell dir vor, du müsstest im Jahr 2100 ein Update ausrollen. Das würde dann über das jeweilige npm-Abhängigkeitsmanagementsystem verteilt werden. Gleichzeitig gäbe es vielleicht im gesamten Sonnensystem abhängige Geräte, die Sicherheitsupdates brauchen, dazu Billionen von Geräten und Zwischen-Caches, bei denen niemand sicher weiß, ob sie aktuell sind. Ich kann mir nicht vorstellen, wie ein solcher Abhängigkeitsbaum dann aussehen würde
  • Wenn man an die Gatekeeping-artige Einstellungspraxis in unserer Gesellschaft denkt, wäre so jemand womöglich fast nicht einstellbar. So nach dem Motto: „Keine Erfahrung mit dem XYZ-Framework? Raus.“
    Es ist auch frustrierend, in einer Umgebung zu arbeiten, in der man sich erst durch Framework-Code graben muss, um zum eigentlichen Kern vorzudringen. Das fühlt sich wie Zeitverschwendung an

• Aufblähung sieht man bei den meisten Bibliotheken im npm-Ökosystem. Die Autoren kennen kein gutes Design und wollen, dass jede Bibliothek alles kann.
  Eine Bibliothek zur Umwandlung von Zeichenkodierungen packt dann Dateiladen, Speichern, Internet-Downloads und sogar ein Kommandozeilen-Tool ins gleiche Repository. Eine Bibliothek sollte genau ihre eine Aufgabe erledigen und den Rest dem Nutzer überlassen.
  Bei Rust sieht es nicht besser aus. Wenn man versucht, an der Rust-Dokumentation etwas zu verbessern, sieht man plötzlich, wie ungefähr 1000 Crates installiert werden.
  Das Problem ist nicht die Sprache, sondern dass jeder Bibliotheken hochladen kann — und das auch tatsächlich jeder tut. Leute, die „einfach nur fertig werden wollen“, wählen die Bibliothek mit den meisten Funktionen und wollen noch mehr Features, weil sie keinen Code schreiben möchten, den man außerhalb der Bibliothek in drei Zeilen lösen könnte. So nach dem Motto: „Könnt ihr auch noch PDF-Rendering hinzufügen?“
  Ich kenne die Lösung nicht, aber ich habe über eine Interessenvertretung und ein Badge für Low Dependency nachgedacht, damit Bibliotheksautoren dieses Badge haben wollen und Nutzer beim Auswählen von Bibliotheken danach suchen.

  • Das klingt, als würdest du geringe Abhängigkeiten und geringe Aufblähung vermischen. Wenn man nicht aufgeblähte Bibliotheken will, holt man sich wahrscheinlich viele kleine Bausteine ins Projekt, die für sich genommen nicht viel tun.
    Wenn man dagegen Bibliotheken mit wenigen Abhängigkeiten will, nimmt man eher ein paar größere, die viel erledigen.
    Aus meiner Sicht sind leicht dickere Bibliotheken mit wenigen Abhängigkeiten besser, wenn sie von Autoren kommen, denen ich vertraue. Lodash ist groß, aber die ES6-Modulversion unterstützt Tree Shaking und fungiert im Grunde als Standardbibliothek, die JavaScript nie hatte. date-fns ist für Date ähnlich. Um die Lücken der JavaScript-Kernbibliothek zu schließen, nehme ich diese beiden in fast jedes Projekt standardmäßig auf.
  • Dem stimme ich wirklich zu.
    Früher hatte ich einen Ruby-on-Rails-Vertrag, bei dem die Performance-Probleme so schlimm waren, dass wir im Release-Modus entwickelt haben. Der Server konnte Änderungen an Dateien nicht einmal zuverlässig erkennen und automatisch neu laden.
    Irgendwann hatte ich genug und bin tiefer eingestiegen, und ich weiß nicht einmal mehr, wie viele Gems da hineingezogen wurden. Eines davon war wirklich ein Gem, das drei Zeilen Code sparen sollte.
    Danach habe ich mich von der RoR-Community ferngehalten. Vor Kurzem habe ich nach einigen Jahren wieder einen RoR-Vertrag übernommen; es ist nicht mehr so schlimm wie früher, aber immer noch nicht gut.
    Manche Communities respektieren die Risiken, die Abhängigkeiten mit sich bringen, überhaupt nicht.
  • Deshalb sind Go und die Standardbibliothek so gut. Außer bei riesigen Bibliotheken für sehr spezielle Zwecke heißt es meistens eher: „Mach es selbst“, und wenn eine kleine Bibliothek nur etwas Einfaches tut, ist es meist besser, es direkt mit der Standardbibliothek zu bauen. Fast alle Bausteine sind schon da.
    Andererseits ist es wirklich praktisch, dass jedes Git-Repository eine Go-Bibliothek hosten kann und jeder sie unter dieser URL verwenden kann.
  • Das Problem kommt von beiden Seiten.
    Erstens wollen Paketautoren daraus eine Karriere machen, und Aufmerksamkeit bekommt man nur, indem man unzählige Pakete baut. Also erstellen sie immer weiter Pakete, die von anderen eigenen Paketen abhängen, und versuchen, ein oder zwei nützliche Pakete davon in fremden Code hineinzubekommen.
    Zweitens gibt es Leute, die glauben, Problemlösung bedeute immer, ein neues Paket einzubinden. Wie viele Abhängigkeiten das erzeugt oder wie schwierig das eigentliche Problem ist, interessiert sie nicht. Statt zu lernen, wie man Probleme löst, lernen sie die API eines Wrappers mit vier GitHub-Sternen.
  • Die Antwort „Lasst uns eine Blackbox-KI hinzufügen, die Unmengen an Ressourcen frisst, um den Abhängigkeitsbaum aufzuräumen“ ist tragisch, aber wahrscheinlich genau die Antwort, die wir bekommen werden. Trotzdem könnte sie besser sein als das jetzige Chaos.
    Im Idealfall würde so ein Tool in mühsamer Kleinarbeit unnötige Pakete wegschneiden, die Verantwortlichkeiten jedes Pakets minimieren, die Umgebung vernünftig ordnen und dann unabhängig cachen, sodass die LLM-Abhängigkeit entfällt. Nur wenn etwas schiefgeht, würde man einen Update-Prüfer oder Kurator hinzuziehen.
    Ehrlich gesagt ist das eines der schlimmsten Probleme moderner Software, und ich denke, es macht mehr als 50 % eines Projekts unbrauchbar. Es ist langweilig, aber lösbar — also genau passend für einen ordentlichen LLM-Agenten — und wäre, wenn es ihn gäbe, eine große Hilfe.

• „Hast du jemals ein modernes Flugzeug gesehen? Hast du verfolgt, wie sich seine Linie Jahr für Jahr entwickelt? Und nicht nur beim Flugzeug, sondern bei allem, was der Mensch erschafft — hast du jemals darüber nachgedacht, dass menschliche industrielle Anstrengung, Berechnung und die Nächte über Zeichnungen letztlich in einem einzigen, herrschenden Prinzip münden: äußerste Einfachheit?
  Es ist, als gäbe es ein Naturgesetz, das befiehlt, dass mehrere Generationen von Handwerkern experimentieren müssen, um die Kurven eines Möbelstücks, den Kiel eines Schiffs oder den Rumpf eines Flugzeugs so lange zu verfeinern, bis sie sich der ursprünglichen Reinheit der Kurven einer menschlichen Brust oder Schulter annähern. Vollkommenheit scheint nicht dann erreicht zu sein, wenn man nichts mehr hinzufügen kann, sondern wenn man nichts mehr wegnehmen kann.“
  — Antoine de Saint Exupéry, Terre des Hommes

  • Zum ersten Mal sehe ich den Kontext dieses Zitats. Wenn man weiß, dass der Autor Pilot war, ergibt es viel mehr Sinn.

• Wenn man schreibt: „Es kann mehr als 50 Millionen Zeilen aktiven Codes und die Betriebssystem-Images mehrerer Server brauchen, um ein Garagentor zu öffnen“, wirkt das wirklich völlig verrückt.
  Wenn ich daran denke, wie viel Code auf der Maschine läuft, auf der ich das hier tippe, wird mir schwindlig. Ich habe ihn nie geprüft, und wahrscheinlich ist vieles davon auch nie ernsthaft geprüft worden.
  Tja, ich gehe dann mal wieder npm-Abhängigkeiten installieren.

  • Trotzdem funktioniert es. Wiederverwendbare Schichten und Abstraktionen haben die Ausbreitung der Computing-Anwendungsfälle ermöglicht, die wir heute erleben.

• „Software gilt inzwischen als so gefährlich, dass man Menschen direkt davon abrät, sie selbst auszuführen. Stattdessen solle man sie einem Anbieter von ‚X as a service‘ oder einfach der ‚Cloud‘ überlassen. Man stelle sich als Vergleich eine fiktive Situation vor, in der Autos so oft in Flammen aufgehen, dass geraten wird, nicht selbst zu fahren, sondern das Fahren Experten zu überlassen, denen ständig professionelle Feuerwehrleute folgen“ – das ist eine Analogie, die ich fast wörtlich übernehmen möchte

  • Wenn das Auto erst 2024 erfunden worden wäre, hätte man der breiten Öffentlichkeit das Fahren niemals erlaubt. Schon wenn durch ein neues Produkt nur ein paar Menschen sterben, gäbe es einen Aufschrei; von 40.000 Toten pro Jahr ganz zu schweigen
  • Das sagen Cloud-Anbieter. Und ebenso deren Angestellte, deren Vergütungsstruktur man auch nicht anders verstehen sollte
  • Die meisten Nutzer, die ich kenne, stehen am Rand des Abgrunds und kurz davor, alles zu verlieren, was sie bisher getan haben. Das heißt nicht, dass man seine Seele an einen SaaS-Anbieter verkaufen sollte. Zur Einordnung: Ich arbeite bei so einem Anbieter, und bei manchen wäre es womöglich besser, die Daten zu verbrennen, statt sie ihnen anzuvertrauen
    Meine Ex-Freundin misstraute der „Cloud“ aus nachvollziehbaren Gründen, weil sie im ehemaligen Ostblock aufgewachsen ist. Die Alternative war jedoch nur zu hoffen, dass sie ihr billig gekauftes HP-Notebook nicht verliert. Nach ein wenig Schulung war sie zumindest in diesem Punkt beruhigt
    Das Problem ist der allgemeine Mangel an Bildung und das fehlende Nachdenken über seine Folgen. Am Ende muss man entweder das Risiko akzeptieren, es selbst lernen oder sich auf SaaS- und Cloud-Anbieter verlassen. Ich habe viele Tränen gesehen und nur selten erlebt, dass Menschen es selbst lernen
    Es ist eine Frage persönlicher Verantwortung, aber weil niemand diese Verantwortung übernehmen will, kann es die weniger schlechte Lösung sein, es Experten zu überlassen, statt auf sich selbst zu vertrauen. Die richtige Antwort ist Bildung, aber das ist hoffnungslos schwierig
  • Als hier einmal jemand sehr entschieden widersprach, dass Halluzinogene nur für medizinische Zwecke und nur mit fachlicher Begleitung verwendet werden sollten, habe ich fast dieselbe Auto-Analogie benutzt

• Software kann nicht noch schlanker werden. Dafür braucht es Zeit, Können und teure Fachkräfte, nicht bloß Leute, die 12 Beispiele aus unterschiedlichen Tech-Stacks zusammenkleben und daraus ein Frankenstein-Kostüm machen
  Ich bin unabhängiger Entwickler, aber jemand, der letztes Jahr node.js gelernt hat, unterbietet mich immer, indem er node.js, Container, irgendeinen gehosteten AWS-Datenbankdienst, Lambda, Objektspeicher, Cloudflare, YAML, React, Vite und weitere Abhängigkeiten innerhalb eines Tages zu einer schablonenhaften, aber immer noch verwundbaren Web-App zusammensetzt
  Software, die schlank, schnell, im Betrieb günstig und auch in der Wartung billiger ist, ist langfristig zwar günstiger, lässt sich aber schwer profitabel entwickeln

  • Genau. Das ist kein Wahrnehmungsproblem, sondern ein Problem der ökonomischen Struktur. Wenn man für nicht nachhaltige Software bezahlt, werden die Leute sie bauen

• Früher gab es den Traum, dass standardisierte Hooks und Routinen des Systems für Dinge wie Benutzeroberflächen von allen genutzt würden. Man denke an die Macintosh Toolbox oder QuickDraw
  Die Hauptaufgabe des Entwicklers sollte darin bestehen, die Programmlogik zu schreiben, und Änderungen oder Ergänzungen sollten transparent sein. Systemaufrufe würden dieselbe Aufgabe reibungslos erfüllen, auch wenn sich der interne Code änderte, und neue Funktionen wären Obermengen bestehender Funktionen, sodass alter Code weiter problemlos kompiliert oder läuft, während neue Software mehr Fähigkeiten bekommt
  Man glaubte, das würde die Wartung erleichtern, Schnittstellen normieren und den Code schlanker machen, weil er stark auf Systemaufrufe setzt. Externe Bibliotheken galten eher als etwas, das man vermeiden sollte
  Dieser Traum zerfiel schnell; man denke nur an DLLs. Vieles an heutigem Paketmanagement und Packaging scheint eher darauf hinauszulaufen, sicherzustellen, dass die richtigen Bibliotheken überhaupt vorhanden sind
  Damals steckte groß angelegte Softwareentwicklung noch fast in den Kinderschuhen, daher ist verständlich, dass es nicht so lief wie erhofft. Heute gibt es viel gesammelte Erfahrung mit solchen Problemen, und ich frage mich, ob man zu dem Schluss gekommen ist, dass dieser Traum bei klarem Verstand nicht umsetzbar ist, oder ob gerade die ausgiebige Erfahrung mit dem aktuellen chaotischen Zustand zu einem modernen neuen Versuch führt
  Wenn man schnelle, schlanke, stabile und sichere Software will, bekommt man wahrscheinlich nicht alle vier Eigenschaften gleichzeitig, aber ich bin mir nicht sicher, ob die aktuelle Lage überhaupt in diese Richtung geht

  • Es gibt einen ständigen Druck, Funktionen in tiefere Schichten zu verlagern. Frühes Unix tat nur sehr wenig, aber moderne BSDs werden in ziemlich „vollständigem“ Zustand ausgeliefert
    Frühes Lisp packte nur sehr wenig in die Sprache, aber Raku drückt selbst Kleinigkeiten in die Sprachspezifikation, die sonst als npm-Bibliothek durchgehen würden
    C ließ einen selbst entscheiden, wie man Code baut, aber die meisten neueren kompilierten Sprachen liefern in irgendeiner Form gleich ein Build-Tool mit
    In dieser Landschaft gibt es durchaus wirksame Dinge, aber sie entstehen außerhalb des Kontexts „du, die Maschine, das neue Projekt“, der Wirths Arbeit geprägt hat. Das Problem ist, dass damit oft die Einstiegshürde gewaltiger Abhängigkeiten wie Datenbanken oder Browser-Engines einhergeht, und wenn einem nicht gefällt, wie diese Abhängigkeiten gebaut wurden, endet man am Ende unglücklich

• Das ist genau das, was ich immer wieder über Rust sage
  Wenn 70 % der alten C++-Schwachstellen tatsächlich mit Speicher zusammenhängen, dann kann es gut sein, dass es pro Codezeile 70 % weniger Schwachstellen gibt als in C++
  Aber wenn man sich in Rust Hunderte Pakete hereinzieht und die Codebasis dadurch zehnmal so groß wird, sieht die Sache anders aus
  30 % von 100.000 Zeilen sind in der Gesamtmenge mehr als 100 % von 10.000 Zeilen

  • Die Anzahl der Crates zu zählen und mit der Zahl der C++-Bibliotheken zu vergleichen, ist ein ontologischer Fehler. In Rust teilt ein Team ein Projekt normalerweise in mehrere Crates auf
    Wenn so etwas wie QT in Rust geschrieben wäre, bestünde es intern wohl aus Hunderten von Crates, aber der Codeumfang und das eingegangene Risikoniveau wären exakt gleich
  • Niemand zwingt einen dazu, Bibliotheken zu verwenden. Man kann den Software-Stack auch einfach selbst schreiben
    Das größere Problem sind aber Schwachstellen. Ist es besser, einen Fehler in einer gemeinsam genutzten Bibliothek zu beheben und damit Hunderte Bibliotheken zu reparieren, oder Hunderte Bibliotheken einzeln zu korrigieren?
  • Ich frage mich, ob es überhaupt Belege dafür gibt, dass Rust-Programme tatsächlich zehnmal so viel Code ausführen wie C++-Programme. Das klingt für mich sehr unplausibel. Die meisten C++↔Rust-Übersetzungen, die ich gesehen habe, lagen eher bei ungefähr 30 % Unterschied
    Dass Rust es leicht macht, viele kleine statt einiger weniger riesiger Abhängigkeiten hereinzuziehen, ist dabei unerheblich. Es heißt nicht, dass man mehr Code schreibt
    Zählt man zum Beispiel Rusts regex-Crate als Abhängigkeit? In C++ ist das Teil der Standardbibliothek
    Zählt man Boost in C++ als eine Abhängigkeit? In Rust entspräche das eher rund 30 separaten Crates
  • Speicherbezogene Schwachstellen gehören oft zu den schlimmsten Arten, etwa Remote Code Execution. Remote Code Execution ist weit gravierender als andere Schwachstellen wie Denial of Service
    Wie viele Fälle von Remote Code Execution gab es bei Rust-Programmen im Vergleich zu C++? Die Häufigkeit von Remote Code Execution in C++ dürfte weit mehr als 70 % über der von Rust liegen

• Obwohl Apps heutzutage meist mit Electron JS gebaut werden, scheint vielen nicht ausreichend bewusst zu sein, dass man auch die nativen Web-Controls der jeweiligen Plattform verwenden und auf das Bündeln von Electron verzichten kann
  Dann kann die ausgelieferte App nur noch kilobytegroß sein. Dieser Ansatz gibt einem die Freiheit, jede beliebige Backend-Sprache oder jeden beliebigen Tech-Stack zu verwenden, solange man mit der Web-View kommunizieren kann

  • Dann dauert der App-Start ein paar Sekunden, alles ist langsam, und weil Nutzer die native WebView nicht als Hauptbrowser verwenden, verbraucht das am Ende sogar mehr RAM als Electron
  • „Schlanke Software“ bedeutet nicht nur Download-Größe
  • Ich frage mich, wo aktuell die Lücken bei PWAs liegen
    Sollte PWA heutzutage nicht für einen ziemlich großen Anteil der Anwendungen machbar sein?
    Ich weiß es nicht genau, aber könnte selbst Discord nicht eher eine PWA sein statt einer Electron-App?
    Die größte Lücke dürfte wohl irgendein starkes Gegenstück zu SQLite und der Unterschied zu IndexedDB sein, aber trotzdem brauchen die meisten Apps vermutlich nicht zwingend eine höherwertige Abfragesprache als das B-Tree-Modell von IndexedDB

• Noch ein Hoch auf die suckless-Philosophie. Hurra.
  [0 ]https://suckless.org/