Anwendung wie bei MacOSX

L

Lance

Well-Known Member
Warum wird es eigentlich nicht so gemacht wie beim OSX, nämlich das Apps mitsamt Abhängigkeiten geliefert werden? Z.B. habe ich auf Mavericks ein Spiel mittels Wineskin erstellt und kann dieses ohne Probleme unter Elcapitan ausführen. Wieso muss es bei FreeBSD (genauso wie bei Linux) diesen Mist mit den Abhängigkeiten geben? Habe ich bis heute nicht verstanden, zumal ja Ubuntu mit Snappy ja in die Richtung gehen will.

VG Lance
 
Sollte einer der Abhängigkeiten eine Sicherheitslücke haben, bist du auf den Hersteller angewiesen diese zu fixen.Das Problem haben sehr viele Anwendungen in OS X und Windows, gerade bei den letzten Sachen wie OpenSSL.
 
PC-BSD hatte dieses Konzept mit dem PBI einst verfolgt. Sie haben es aufgegeben.
 
Ich würde das auch nicht befürworten. 10 Programme hängen von XY ab. Warum sollte XY 10x mit ausgeliefert werden? Und dann womöglich noch mit unterschiedlichen Versionen aber dem selben Installationspfad? Nein danke. :)
 
Man kann software einfach statisch linken. Das ist eine gute Option für kommerzielle Anbieter, die Binaries ausrollen wollen.

So gemurkse wie Docker gibt es nur weil die GPL statisches Linken meist (nicht technisch aber rechtlich) unmöglich macht.
 
Statisch linken ist aber nach meinen Erfahrungen noch schlimmer.

Gerade bei Steam hab ich immer wieder Probleme, dass die mitgelieferten Libraries zu alt sind. Die glibc muss ich regelmäßig löschen, weil sonst die neusten Grafiktreiber nicht funktionieren. Dann muss ich auch die OpenAL und ALSA-Bibliotheken löschen, weil ich sonst keinen Sound habe.

Wenn der Kram jetzt statisch gelinkt wäre, dann hätte ich ja gar keine Möglichkeit hier irgendwas zu tun. Das mag bei den 08/15 Server-Anwendungen möglich sein, aber bitte nicht bei Sachen die etwas mehr mit dem System interagieren.
 
-Nuke- schrieb:
Wenn der Kram jetzt statisch gelinkt wäre, dann hätte ich ja gar keine Möglichkeit hier irgendwas zu tun. Das mag bei den 08/15 Server-Anwendungen möglich sein, aber bitte nicht bei Sachen die etwas mehr mit dem System interagieren.
Zum Vergrößern anklicken....
Man muss sich halt vorher überlegen was man statisch mitlinkt und was nicht. So zeug wie OpgenGL, OpenAL usw. Bibliotheken sollte man so oder so nicht mitliefern. Wenn die auf dem Zielsystem nicht vorhanden sind dann läuft es sowieso nicht.
 
Ich glaube, dass einer wesentlichen Gründe für Linux großen Erfolg und sein Verdrängen fast aller anderen (kommerziellen) Unixe ab Mitte der 90er war, dass 1994 Debian mit dpkg das vollautomatische Dependency Tracking einführte. Auf einmal wurde das Installieren von Software zum Kinderspiel, vorher war jedes kleine Update ein nervtötendes Gebastel und hinterher nur noch ein unspektakuläres Kommando. Zusammen mit dem gleichzeitig aufkommenden ELF konnte man das ganze System dynamisch linken, was (gemessen an damaligen Festplattengrößen) endlos Speicherplatz und durch die Integration in die virtuelle Speicherverwaltung bedeutende Mengen RAM sparte. Als später das Internet und damit das Dauersecurityproblem kam, wurde das eine zentrale Kommando für Systemupdates zur Killeranwendung.

Zumindest mich nervt es unter Windows jedes mal tierisch, dass direkt nach dem Start erst einmal gefühlte 30 Updater loslaufen. Es frisst Systemressourcen ohne Ende, es ist nicht nachvollziehbar, was genau passiert und ich kann nie sicher sein, ob ich wirklich alle Updates habe. Zu meinen Mac-Zeiten war es unter OS X bald noch schlimmer, da die wenigstens Apps Updater hatten und man manuell suchen musste. Das mag sich aber geändert haben. Ich habe daher auch recht wenig Verständnis dafür, dass einige Distributionen versuchen, das zentrale Paketmanagement durch eine krude Mischung aus zentraler Verwaltung und vollintegrierter Pakete ähnlich wie PBI zu ersetzen. Ubuntu versucht es zum Beispiel gerade, bzw. experimentiert in der Richtung herum.

Zum Thema dynamisch vs. statisch: Ich würde immer dynamisch linken. Schon allein, damit der Anwender die Möglichkeit hat, in einigen Jahren die dann veralteten Blibliotheken auszutauschen. Ich lege allerdings grundsätzlich alle benötigten Bibliotheken bei und verpasse meiner Binary einen entsprechenden RPATH.
 
Die damals (TM) bei den Unixen bekannte "dependency hell" ist finde ich heute wirklich gut geloest, bei eigentlich fast alle Linux Distribution und *BSD. Der SAT Solver bei FreeBSDs pkg loest selbst auf alten Systemen, wo noch eine vorzeitliche Version lief alles erstaunlich gut, so gut das ich nun Produktivsysteme automatisch update. Hier und da gibts bei Desktopsystemen einige Probleme, die aber meistens mit den Paketen selbst zu tun haben (wie irgendeine obskur geaenderte Gnome Version, die ueber alte Einstellung der User stolpert o.ae.). Meistens alles nicht so wild.

Speicherplatz ist heute sicher nicht mehr der Hauptgrund gegen statisches Linken, aber wie der Name schon andeutet sind shared libs deutlich/ueberhaupt flexibel, was das Austauschen der Libraries angeht. Besonders wenn die kommerziellen Hersteller fuer wirklich alte Systeme Binaries ausliefen und die Produkte dann eingestellt haben, die aber dynamisch gelinkt sind bringt das ein gewisses Einflusspotential mit. ;)
 
Das Problem beim dynamischen Linken ist, dass ständig die binären Schnittstellen gebrochen werden, besonders schlimm wenn C++ im Spiel ist. Und gerade an Windows ohne automatische Abhängigkeitsverwaltung sieht man, wie man wunderschön die gröbsten Nachteile des statischen Linkens mit denen des dynamischen Linkens kombiniert: extrem viele Programme bringen ihre eigenen dynamischen Bibliotheken mit und kippen sie in das gleiche Verzeichnis wie das eigentliche Programm, so dass dieses diese Bibliotheken zur Laufzeit lädt. So könnte man sich auch das ganze Theater zur Laufzeit sparen können und gleich statisch linken, da eh immer nur die eigene, private Bibliothek verwendet wird.

Unter modernen Unices gibt es inzwischen quasi immer eine zentrale Abhängigkeitsverwaltung, aber im Umkehrschluss ist man immer auf die Versionen der offiziellen Repositories festgenagelt. Das Problem haben wir ja im Trinity-Thread gesehen, sobald ein Programm oder eine Bibliothek nicht mit dem Repository synchron ist fängt der Ärger an.

Daher halte ich gerade bei proprietären Programmen das statische Linken für die bessere Idee, sofern es eben stabile ABIs gibt. Wenn nicht, dann hat man so oder so verloren.

Beim Löschen irgendwelcher mitgelieferten Dateien kann man Glück haben, wenn die ABI kompatibel ist, insgesamt halte ich das aber für einen Hack, der mehr schlecht als recht funktioniert.
 
Ich bin nicht sicher, dass ich dieses Problem voll verstehe.
Deshalb möchte ich mal etwas laienhaft ausdrücken: wenn ich ein Programm als selbstständige Funktionseinheit einspiele, die unabhängig von meinem Rest-System laufen kann und dann zum Beispiel nur Daten über bekannte Schnittstellen austauscht, wie etwa den X-Server, dann wäre doch solch ein Programm immer lauffähig. Quasi würde jedes solche Programm sein "eigenes System" mitbringen, möglicherweise bis hinab zum Kernel und so wie eine virtuelle Maschine in der Umgebung des Systems, aber ohne Zugriff auf dessen Bibliotheken zuverlässig laufen können. Alles müsste in eigenen Pfaden installiert sein, aber das wäre doch kein grundsätzliches Problem.

Es leuchtet mir ein, dass das ein nicht vertretbarer Aufwand für sehr kleine Programme ist und dass ich wohl einige Einbußen an möglicher Performance hätte, aber solche Programme wären dann vielleicht sehr einfach auf unterschiedliche Systeme portierbar und in sich immer konsistent und lauffähig.
Über definierte Schnittstellen wäre nicht nur der Datenaustausch zum Grundsystem möglich, sondern Systemweite Parameter könnten von vorher festgelegten Orten gelesen werden und so systemweite Gültigkeit erlangen, ohne dass jedes einzelne Programm wieder komplex konfiguriert werden müsste.

Es ist ist mir klar, dass heute kein Hersteller sein System so ausrichtet, aber das ist für mich mehr eine Frage des Designs, als der mangelnden Realisierbarkeit. Heute denken wir uns Programme immer als Bestandteile des installierten Systems und bauen die zusätzliche SW in die bestehende Installation ein. Das ist ein Schaffensprozess, der ein komplettes, individuell zugeschnittenes System als Endprodukt sieht, in dem möglichst Ressourcen (vor allem Plattenplatz) -sparend vorgegangen wird. Ich liebe diesen Ansatz! Aber ich sehe auch, dass der andere Ansatz, der Programme als selbstständige Funktionseinheiten auf einem fertig installierten System betreibt einige Vorteile haben könnte und wegen der geänderten Voraussetzung hinsichtlich der verfügbaren Ressourcen vielleicht nicht mehr so abwegig erscheint.

Neben Fragen der Technik würden so vielleicht auch Fragen hinsichtlich der Lizenz ganz neu zu überdenken sein. Die SW funktioniert für sich in einem entsprechend lizenzierten Umfeld und tauscht mit dem umgebenden System lediglich Daten aus. Das dürfte keinerlei Lizenz-Bedenken aufwerfen, glaube ich, wie wir sie heute gelegentlich sehen. Im Grunde hasse ich es aber, bei jeder möglichen Frage gleich so zu denken, als sei ich gerne Anwalt geworden!

Wenn ich das richtig sehe, macht OS-X mit seinen Sandboxen und wir mit unseren Jails ja schon beinahe so etwas ähnliches. Wir implementieren da keine vollständig lauffähigen Programme, aber wir stellen Programmen "eine lauffähige Kopie" des installierten Systems in einem abgeschlossenen Raum zur Verfügung.
Vielleicht sollte die nächste Entwicklung in der Richtung so weit gehen, Programme mit solchen kompletten Umgebungen zu versehen.
 
Docker wurde schon innerhalb dieses Themas genannt. Anstelle von Jails meinst du vermutlich Jetpack, oder soll es gar Qubes-OS sein?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben