Den großen Nachteil einer statisch gelinkten Datei hat Valle natürlich tunlichst verschwiegen: die
LGPL.
Nicht verschwiegen, aber vergessen, ja.
Hmm, da habe ich Vorsatz unterstellt wo es keinen gab. Verzeihung
Der Standpunkt von RMS ist mir leidlich bekannt. Die Frage ist nur in der Tat, wie man kurz und bündig von einem Linuxkernel mit GNU-Userland spricht und dies gleichzeitig von nicht GNU-basierten Systemen abgrenzt? Android läuft ja auch auf einem Linuxkernel, aber mit eigener C-Laufzeitbibliothek (Bionic) und einer Menge Komponenten die nicht unter
GPL stehen oder dem GNU-Projekt unterstellt sind.
Dem Wikipediaartikel entnehme ich auch keine endgültige Entscheidung in die eine oder andere Richtung. Aber wir können uns ja einigen, daß wir da einfach verschiedener Ansicht sind was wann sinnvoll ist
... hab ich kein Problem mit.
Für mich bedeutet Rückwärtskompatibilität mehr Arbeitsaufwand. Die Kompatibilität erhält sich leider meist nicht von selbst. Mehr Arbeit und das "Herumschleppen" alten Codes sind für mich Nachteile. Auch
sich daraus ergebene APIs tendieren dazu, weniger schön zu werden. Das bedeutet nicht, dass es nicht notwendig sei. Manchmal will man gern alten Kram über Board werfen, aber das geht nun mal nicht immer.
Für mich bedeutet das Erstellen von x Varianten desselben Projekts viel mehr Aufwand als einmal (wir sprachen ja über glibc) eine Lösung zu erarbeiten und diese konsequent einzusetzen. Oft läuft es ja auch darauf hinaus alte Distros vorzuhalten zu denen man nicht einmal mehr Medien bekommt. Denn jede Variante will getestet sein. Wenn aber nicht nur die C-Laufzeit, sondern auch andere Bibliotheken ins Spiel kommen, kann es zugegebenermaßen schnell unübersichtlich werden überhaupt eine Rückwärtskompatibilität herzustellen (wie in deinem Beispiel mit
MySQL). Zum Glück habe ich dieses Problem nur mit der glibc [1] und nicht mit anderen Bibliotheken.
[1] und dann kann man mit musl-libc oft selbst statisch gelinkte Dateien kleiner bekommen als dynamisch gegen die glibc gelinkten.