Wenn Sie eine ausführbare Datei erstellen, die auf einer aktuellen Windows-Version funktioniert, wird diese ausführbare Datei wahrscheinlich noch viele Jahre auf neueren Windows-Versionen funktionieren. Microsoft unternimmt große Anstrengungen, um dies sicherzustellen.
Bei Linux wird vorausgesetzt, dass Sie den Quellcode der von Ihnen verwendeten Software haben. Daher ist es in Ordnung, die Binärkompatibilität zu brechen, solange Sie die Quellkompatibilität beibehalten. Dies führt dazu, dass Distributionen alte Bibliotheksversionen ausmustern und regelmäßig Dinge kaputt machen, die früher funktioniert haben.
Für jemanden, der Linux als Spieleplattform verwendet, ist das ein Problem, da Spiele normalerweise nur in binärer Form verteilt werden. Es lässt Linux-Ports schlecht aussehen, wenn sie kaputt gehen, aber ich habe das Gefühl, dass es produktiver wäre, zu versuchen, dieses Problem allgemein zu lösen, anstatt von jedem zu erwarten, dass er seine Ports aktualisiert.
Gibt es Distributionen, die versuchen, die Binärkompatibilität zu bewahren, nicht unbedingt dadurch, dass alle alten Versionen beibehalten werden, aber zumindest dadurch, dass alte Sonames beibehalten werden, sodass eine Binärdatei, die mit Release n funktioniert, auch mit Release n+1 funktionieren sollte?
Das Nächstliegende, was ich finden kann, ist „Steam Runtime“ von Valve, eine binäre Kompatibilitätsschicht, die nur für über Steam vertriebene Programme verfügbar ist.
Antwort1
Im Wesentlichen läuft es darauf hinaus:Sie können die Binärkompatibilität nicht aufrechterhalten und neue Funktionen einführen, da diese Dinge in den meisten Aspekten direkt gegeneinander verstoßen. Wenn Sie wichtige neue Funktionen einführen,müssenÄndern Sie die ABI (normalerweise kurz nach den Änderungen in der API). Jetzt können Sie versionierte Symbole haben (wie zum Beispiel Glibc), aber dadurch werden die Bibliotheken größer (und es kann auch zu Leistungseinbußen beim Laden einer Binärdatei in den Speicher kommen) und Entwickler möchten sie sicherlich nicht in allgemeinen Bibliotheken behalten (der Legacy-Code enthält Fehler, an deren Behebung niemand interessiert ist).
Auf der Vertriebsseite kann man dies normalerweise auf zwei Arten umgehen:
Ändern Sie die Versionen nicht – dies ist typisch für Enterprise-Distributionen wie (in alphabetischer Reihenfolge) RedHat und SUSE sowie für einige andere (Debian, Slackware, Ubuntu LTS und wahrscheinlich deren Klone).
ermöglichen die gleichzeitige Installation verschiedener Versionen einer Bibliothek.
Auf dem Anwendungsverteiler wird dies auf dieselbe Weise gehandhabt wie unter Windows: alles, was benötigt wird, wird in das Verteilungspaket gepackt. Ja, so wird es unter Windows häufig gemacht – dies ist auch einer der Gründe dafür, dass typische Windows-Systeme bei gleicher Funktionalität normalerweise einen mehrfach höheren Speicherplatzbedarf haben als Linux – die Anwendungen teilen einfach nur sehr wenig untereinander und haben irgendwo ihre eigenen Kopien. Sie können es sich so vorstellen, als ob jede GTK/Qt-Anwendung mit ihrem eigenen GTK/Qt-Stapel käme. Dies kann einige Vorteile haben, hat aber auch viele Nachteile. Aus Sicherheitssicht ist es beispielsweise in Technicolor TM ein Albtraum . Wenn die Binärdateien statisch verknüpft sind, ist es sogar in Full HD.