curl läuft auf 100 Betriebssystemen

• curl beschränkt Änderungen so, dass es auch in alten Umgebungen weiterhin gebaut und getestet werden kann; auch bei einem aktuellen Pull Request wurde verlangt, die Kompatibilität mit 32-Bit-time_t und Legacy-Plattformen nicht zu brechen
• Entscheidend ist nicht, eine möglichst lange Plattformliste zu pflegen, sondern das Versprechen von ABI/API-Stabilität einzuhalten, damit beim Upgrade der Nutzer alles weiter funktioniert
• Wichtiger als die Zahl der Nutzer eines bestimmten Betriebssystems ist, ob es tatsächlich jemanden gibt, der es betreut und Fehler behebt; solange Maintainer vorhanden sind, können auch Plattformen mit wenigen Nutzern weiter unterstützt werden
• curl und libcurl haben sich durch ein auf Portabilität ausgerichtetes Prinzip verbreitet: über Betriebssysteme, CPU-Architekturen und ungewöhnliche Konfigurationen hinweg in einem Zustand zu bleiben, in dem sie „gebaut werden und laufen“
• Der Hauptgrund, warum alte curl-Befehle scheitern, liegt weniger an Änderungen in curl als an Veränderungen der Internetumgebung, etwa daran, dass Hosts und URLs verschwinden oder HTTP durch HTTPS ersetzt wurde

---

Änderungskriterien, die Legacy-Plattformen nicht brechen

• Bei einem aktuellen Pull Request für curl konnten Änderungen nur dann in das git-Code-Repository gemergt werden, wenn sie Builds oder Tests auf Legacy-Plattformen nicht beschädigten
• Die Änderung betraf den Bereich rund um time_t; curl unterstützt bereits den Typ 32-Bit-time_t, und dieses Verhalten musste erhalten bleiben
• 32-Bit-time_t ist bereits nur noch eingeschränkt nutzbar und dürfte mit dem näher rückenden Jahr 2038 noch stärker limitiert werden, doch viele Legacy-Plattformen verbleiben weiterhin bei der 32-Bit-Version
• Solche Anforderungen machen die Arbeit von Beitragenden schwieriger, werden bei curl aber als Teil des Prozesses verstanden, Änderungen vollständig und sauber umzusetzen

Kompatibilität ist ein größeres Versprechen als die Zahl der Plattformen

• Das curl-Projekt arbeitet kontinuierlich daran, ABI- und API-Stabilität sowie Kompatibilität zu bewahren
• Eine Anwendung, die Mitte der 2000er Jahre libcurl verwendet hat, kann auf eine aktuelle libcurl-Version aktualisiert werden und sich weiterhin gleich verhalten, ohne dass die Anwendung neu kompiliert werden muss
• Auch curl-Skripte, die Anfang der 2000er Jahre geschrieben wurden, sollten mit aktuellen curl-Releases nahezu unverändert funktionieren
• Diese Kompatibilität ist kein bloßer Werbespruch, sondern ein Kernprinzip von curl und libcurl
  • Nutzer können sich auf curl verlassen
  • Selbst wenn ein Release Bugs enthält, soll ein Update auf eine neue Version möglich sein, ohne die üblichen Schmerzen eines Software-Upgrades
• Die Haltung, nichts kaputtzumachen, was bereits gut funktioniert, gehört zu den Wartungskriterien

Maintainer entscheiden über die Unterstützung

• Die Zahl der Nutzer einer bestimmten Plattform ist nicht der Hauptgrund dafür, ob curl diese Plattform weiter unterstützt
• Wichtiger ist, wer die Arbeit übernimmt und ob die tatsächlich notwendige Wartung stattfindet
• Wenn es Beitragende gibt, die sicherstellen, dass curl auf einer Plattform weiter funktioniert, kann curl auch auf Plattformen mit bekanntermaßen geringer Nutzerzahl weiter laufen
• Der Zeitpunkt, an dem eine Plattform faktisch aus curl verschwindet, ist erreicht, wenn der für sie notwendige Code nicht mehr gepflegt wird
  • Auch nicht gepflegter Code kann noch viele Jahre funktionsfähig bleiben
  • Es kann lange dauern, überhaupt festzustellen, dass curl auf einer bestimmten Plattform nicht mehr funktioniert
• Umgekehrt ist selbst eine Plattform mit vielen Nutzern schwer zu erhalten, wenn es an Maintainern fehlt, die den Willen und das Wissen haben, plattformspezifische Probleme zu bearbeiten

Warum curl in so vielen Umgebungen verbreitet ist

• curl und libcurl legen großen Wert darauf, in möglichst vielen Umgebungen gebaut und ausgeführt werden zu können
• Die Haltung, auch einzigartige oder ungewöhnliche Konfigurationen funktionsfähig zu halten, ist einer der Gründe für die Verbreitung über viele Betriebssysteme und CPU-Architekturen hinweg
• Viele Nutzer und Unternehmen verwenden weiterhin alte, nischenhafte oder Legacy-Plattformen
• Für sie ist es aus Sicherheitssicht oft besser, wenn die Transferfunktionen von curl erhalten bleiben, als wenn sie selbst Ersatzimplementierungen bauen
• Wenn es keinen Grund gibt, Funktionalität zu brechen, gilt die Einschätzung, dass es besser ist, bestehende Nutzer weiterhin auf curl vertrauen zu lassen

Das Entfernen von Unterstützung erfolgt langsam und öffentlich

• Auch curl entfernt gelegentlich bestimmte Unterstützung
• Hauptsächlich betrifft das Unterstützung für Drittanbieter-Bibliotheken, deren Nutzung zurückgeht und die allmählich verschwinden, doch auch in anderen Bereichen kann Unterstützung entfernt werden
• Das Einstellen von Unterstützung geschieht langsam, sorgfältig und mit öffentlicher Kommunikation
  • Nutzer, die es wissen wollen, müssen Änderungen im Voraus erfahren können
  • Nutzer sollen sich vorbereiten oder widersprechen können, wenn ihnen ein Vorschlag unangemessen erscheint
• Wenn Nutzer keine Verhaltensänderung feststellen können, wird es nicht als Änderung betrachtet
• curl wird für die Nutzer gemacht, und wenn Nutzer ein bestimmtes Verhalten weiterhin wünschen, sollte dieses Verhalten erhalten bleiben

Der wahre Grund, warum alte Befehle scheitern

• Internetprotokolle und Versionen entstehen und verschwinden im Laufe der Zeit
• Die meisten curl-Befehlszeilen aus dem Jahr 2002 funktionieren heute möglicherweise nicht mehr unverändert
• Der Grund für das Scheitern kann nicht curl selbst sein, sondern dass die damals verwendeten Hostnamen und URLs nicht mehr funktionieren
• Einer der wichtigen Gründe, warum curl-Befehle aus dem Jahr 2002 heute nicht mehr unverändert funktionieren, ist der Wechsel von HTTP zu HTTPS
• Auch wenn es 2002 Websites gab, die TLS oder SSL verwendeten, war das damals nicht üblich; die damals genutzten TLS-Protokollversionen können heute als unsicher gelten
• Moderne TLS-Bibliotheken und curl können Verbindungen zu alten, nicht aktualisierten TLS-Konfigurationen ablehnen
• Selbst wenn man eine curl-Binary aus dem Jahr 2002 aufbewahrt hätte und sie heute ausführen würde, könnte sie sich nicht mit modernen HTTPS-Websites verbinden
  • Das liegt nicht an Änderungen in curl, sondern an Änderungen auf der Transportprotokoll-Schicht

[GN⁺]

Hacker-News-Kommentare

• Eine großartige Leistung. Curl ist wirklich ein Segen als Tool.
  Interessant ist, dass Daniel 32-Bit-time_t als wichtigen Punkt für die Kompatibilität hervorgehoben hat. Wenn das Ziel ist, es auf vielen Betriebssystemen weiter lauffähig zu halten, ergibt das absolut Sinn. Allerdings sind es bis 2038 nur noch 14 Jahre, und das liegt uns heute viel näher als der Zeitpunkt, zu dem curl erstmals erschien. Ich frage mich, ab wann der Aufwand, 32-Bit-Zeit zu unterstützen, nicht mehr als lohnend angesehen wird. Meine Vermutung: etwa 3 Monate nach dem Y2K38-Datum, vielleicht auch noch länger.

• Entwickler lernen etwas, wenn sie näher an den Betrieb heranrücken. Je mehr Abhängige es gibt, desto größer wird die Last. Infrastruktur und zentrale Systeme verlieren ihre Agilität, sobald genug Dinge von ihnen abhängen, und selbst kleine Änderungen werden wirklich schwierig.
  Wenn man in seinem eigenen Dienst mit Backend und Frontend die API zwischen beiden komplett umwerfen will, wen kümmert’s? Man macht es einfach.
  Wenn man aber einen seltsamen Grenzfall in der Standardvorlage entfernen will, weil er „hässlich“ ist, muss man sich noch 20 alte Dienste anschauen, 20 halb modernisierte Dienste, die niemand anfassen will, und weitere 50 Dienste, die das benutzen. Allein um zu verstehen, wie groß diese Änderung ist, braucht man schon so viel Arbeit. Dabei geht es in diesem Stadium noch nicht einmal um die tatsächliche Umsetzung der Änderung oder darum, obskure Geheimnisse per Reverse Engineering zu entschlüsseln.
  Ich würde nicht sagen, dass das glamourös ist, aber alles darunter auszutauschen, ohne dass es jemand bemerkt, und dabei weiter den strahlenden Hauptdarsteller zu tragen, gibt Roadies oder Administratoren durchaus Stolz.

• In der Liste sind auch einige Dinge, für die es seit über 25 Jahren kein Release mehr gab. Werden für SCO, Xenix, OS/2 oder NextStep wirklich noch aktuelle Builds erstellt?
  Ich habe solche Systeme benutzt und weiß, dass es dort curl gibt, aber meiner Erfahrung nach war diese curl-Version immer mindestens 15 Jahre alt.
  Wenn man sagt, man wolle keine Support-Matrix beschädigen, ein großer Teil dieser Matrix aber schon weit über 10 Jahre seit dem letzten Build hinter sich hat, woher weiß man dann, dass sie tatsächlich nicht kaputtgegangen ist?

  • 25 Jahre ist vermutlich noch recht großzügig heruntergerundet.
    Ich weiß nicht, ob man überhaupt noch für Xenix bauen kann. Die neueste GCC-Version, die dort als Ziel in Frage kommt, ist 2.7, und selbst die ist schon uralt. Mit Netzwerkcode gilt das erst recht. Vermutlich ist eher gemeint: „Zu irgendeinem Zeitpunkt lief es auf diesen Systemen.“
  • Im Vergleich dazu ist AmigaOS noch ziemlich lebendig. Das neueste Release kam 2021 heraus.
  • Wenn sich Xenix oder OS/2 nicht verändert haben, warum sollte dann ein alter Curl-Build dort plötzlich kaputtgehen?
  • SkyOS ist auch ein gutes Beispiel. An diesem Punkt wäre es wahrscheinlich sicherer, es zu entfernen, als anzunehmen, dass es tatsächlich noch jemand auf SkyOS ausführt.

• Zu der Aussage „Zahlreiche Nutzer und Unternehmen bestehen auf alten, nischigen, Legacy-Plattformen, und wir können nichts dagegen tun“: Die meisten Leute entwickeln Software, selbst proprietäre Closed-Source-Entwickler, bei der gleich am Anfang der Lizenz etwas steht wie „Dieses Programm wird in der Hoffnung verbreitet, nützlich zu sein, jedoch ohne jede Gewährleistung, auch nicht der stillschweigenden Gewährleistung der Marktgängigkeit oder der Eignung für einen bestimmten Zweck“.
  Das ist billig.
  Einige von uns dagegen, mich eingeschlossen, entwickeln Software mit garantierter Eignung für den vorgesehenen Zweck, bei der die Gewährleistung ausdrücklich und absolut ist.
  Das ist sehr teuer und langsam.
  Wenn beim Ausfall Menschen sterben können, die Umwelt zerstört werden kann oder Schäden in Millionenhöhe entstehen können, dann ergibt es Sinn, weiterhin alte und nischige Plattformen zu verwenden, die 30 bis 40 Jahre lang von sehr langsamen und sorgfältigen Entwicklern gründlich geprüft wurden.
  Zumindest sage ich mir das, wenn ich mir Ada auf INTEGRITY auf PowerPC ansehe.

  • Dieser Satz widerspricht sich in sich selbst.
    Wenn der Tod eines Menschen zu Schäden in Millionenhöhe führen kann, dann sollte man gerade keine Software oder Plattformen einsetzen, deren Entwicklerpool so klein ist wie „die Zahl französischer Jongleure mit Wilson-Krankheit“.

• Ein Grund für diese Popularität dürfte die permissive Lizenz sein. Ich hatte vermutet, es sei die MIT-Lizenz, aber sie scheint leicht anders zu sein [1]. Kann jemand in einfachen Worten sagen, was der wesentliche Unterschied zu MIT ist? Auf der Copyright-Seite steht keine ausführliche Erklärung.
  [1] https://curl.se/docs/copyright.html

  • Verglichen mit der MIT-Lizenz scheint die wichtigste zusätzliche Klausel dieser Teil zu sein:
    „Außer wie in diesem Hinweis enthalten, darf der Name des Urheberrechtsinhabers ohne vorherige schriftliche Genehmigung des Urheberrechtsinhabers nicht verwendet werden, um den Verkauf, die Nutzung oder sonstige Geschäfte mit dieser Software zu bewerben oder zu fördern.“
  • Wie auf der Seite steht, scheint es eine angepasste, von der MIT/X11-Lizenz inspirierte Lizenz zu sein. Der Unterschied zu MIT/X11 scheint nur darin zu bestehen, dass der Teil vor dem Gewährleistungsausschluss kürzer ist. Bei SPDX gibt es dafür einen eigenen Eintrag [1].
    [1] https://spdx.org/licenses/curl.html
  • Es wirkt wie eine MIT-Lizenz mit der dritten Klausel der BSD-3-Clause-Lizenz dazu.

• Ich hätte gedacht, dass es allein fast 100 Linux-Versionen gibt, aber überraschend ist, dass man sogar dann auf 100 kommt, wenn alle Linux-Versionen nur als ein einziges Betriebssystem gezählt werden.

  • Schon, aber wenn man iOS, iPadOS und watchOS als eigene Betriebssysteme zählt, sind es in Wirklichkeit eher 98 Betriebssysteme. Das ist ja nun wirklich nichts Besonderes … das kann jeder …

• Wenn man Code unter Berücksichtigung mehrerer Legacy-Systeme schreibt, wird der Code meiner persönlichen Erfahrung nach meist besser.
  Man hält sich stärker an bekannte Coding-Praktiken wie Benennung, Typen und Modularisierung, und auch die Standardkonformität wird besser, außer an klar markierten Stellen. Abstraktionen werden robuster, Bugs nehmen vor allem auf modernen Plattformen ab, und auch das Build-System wird belastbarer. Dadurch wird man automatisch mit zukünftigen Plattformen kompatibel oder kann es zumindest sehr leicht kompatibel machen.
  Wenn man allerdings nur ein paar Legacy-Systeme als Ziel hat, muss das nicht gelten, weil man sich dann mit einer Kombination aus seltsamen Flickwerken und Hacks durchmogeln kann.

• Es ist seltsam, FreeDOS, DR-DOS und MS-DOS als getrennte Betriebssysteme aufzulisten. Sie sind einander sehr ähnlich und im Gegensatz zu verschiedenen Unix-Varianten praktisch ABI-kompatibel.

  • Fast. Wie allgemein bekannt ist, waren DR-DOS, MS-DOS und PC-DOS zu etwa 99 % kompatibel, und das Problem trat auf, wenn man unglücklicherweise genau auf dieses 1 % stieß. DR-DOS war ein Reverse-Engineering von MS-DOS, und selbst IBMs Lizenz für PC-DOS gab Microsoft nicht automatisch Zugriff auf alles, was in MS-DOS gemacht wurde.
  • DR-DOS ist ein direkter Nachfahre von CP/M mit ABI-Kompatibilität zu MS/PC-DOS und damit eindeutig ein eigenes Betriebssystem. Das gilt ebenso für FreeDOS. Intern gibt es jeweils genug Unterschiede.
  • OPENSTEP und NeXTSTEP werden dort auch als getrennte Betriebssysteme aufgeführt …

• Und trotzdem wollen Leute das in Rust neu schreiben. Kann Rust all diese Architekturen und Betriebssysteme überhaupt realistisch als Ziel unterstützen?

  • Warum sollte überhaupt jemand curl neu schreiben wollen? Was ist denn so schlimm daran, C zu verwenden?

• Verwandte Lektüre: ein Text darüber, wie curl entstanden ist und welche Geschichte es hatte (1)
  (1) https://daniel.haxx.se/blog/2023/03/20/twenty-five-years-of-...