So neu ist das nicht das gibt es schon lange unter Windows! PC-BSD gibt es auch schon länger, woher willst du wissen ob ROX eher war? Trotzdem man sieht ja an Windows das, das nicht so gut sein kann, mehr Speicherplatz wird dadurch sowieso benötigt!
Also erstens mal kann man das schon lange unter linux machen und es wird auch von kommerzieller software sehr häufig gemacht und zweitens mal ist das auch unter Windows kein Standard sondern sehr schlechter Stil. Auch unter Windows gibt es ja DLLs im Systemverzeichnis, die Probleme die dabei immer mal wieder auftreten sind allerdings grundsätzlich dem Programmierer zuzuschreiben, denn die Versionierung funktioniert genau gleich wie unter Linux, BSD etc. Im Prinzip funktioniert die sogar besser, denn die kleinen "Schweinereien" mit symlinks die manche Distros unter Linux veranstalten würden unter windows NICHT funktionieren. Unter Linux werden die ".so" rein nach Namen unterschieden, neue API = neuer Name. Kann man natürlich austricksen indem man zur Datei /usr/lib/libvte.so.9.1.6 den Symlink /usr/lib/libvte.so.5 setzt. Das dumme Linux denkt dann da wäre tatsächlich eine libvte.so.5 mit entsprechender API. Funktioniert auch recht häufig leider nicht immer und ist sehr unsauber. Unter windows gibt es GUIDs mit denen man Bibliotheken eindeutig kennzeichnen kann, was normalerweise auch geschieht. Also lieber mal ein bisschen Fachwissen bringen statt endloser Polemik.
Und bei Sicherheitslücken in einer Bibliothek müssen alle Programme, welche diese Bibliothek mitliefern, komplett geupdatet werden, anstatt nur der einzelnen dynamisch linkbaren Bibliothek, wie es unter Unix eigentlich üblich ist.
Wer erinnert sich eigentlich noch an die GDI-Lücke in Windows? An diesem Beispiel sieht man, wohin dieses Vorgehen führen kann.
Von schokokruemmel am Di, 2. Januar 2007 um 13:04 #
Habt ihr euch das mal "live" angeschaut?
Jedes PBI-Paket beinhaltet die notwendigen Bibliotheken und "Abhängigkeiten". Wird ein per PBI installiertes Programm "geupdatet" (schönes Wort *g), so betrifft das Update auch nur dieses eine Programm.
Logo, es werden sicherlich ein paar *libs doppelt und dreifach angelegt - aber - bei den heutigen Monsterfestplatten macht das nicht soooo viel. Ausserdem kann man ja die klassische Portsammlung nutzen - wo ist nun eigentlich das Negative .... ???
Einen Vergleich mit der "GDI-Lücke" würde ich nicht an dieser Stelle nicht anführen.
> Logo, es werden sicherlich ein paar *libs doppelt und dreifach angelegt - aber - bei den heutigen Monsterfestplatten macht das nicht soooo viel.
Die Festplattenbedarf ist ja auch nicht relevant. Die Bibliotheken liegen mehrfach im Arbeitsspeicher und der ist wesentlich begrenzter. Außerdem ist dieses Vorgehen sehr schlecht, was Sicherheitsupdates betrifft. Anstatt beispielsweise ein zlib Update zu machen, muß von jeder Anwendung, die zlib inkludiert, ein Update erfolgen. Das können eine ganze Menge Anwendungen sein; die Wahrscheinlichkeit das eine inkludierte Bibliothek übersehen, das System somit anfällig für Black Hats wird, ist dementsprechend groß.
Um es kurz zu machen: Der Ansatz, der hinter PBI (u.ä.) steht, ist komplett dümmlich. Von dem Verlust der anderen Vorteile, die der FHS-Ansatz bietet mal abgesehen.
Fang bloß nicht mit Windows an. Als ich mit damit noch beschäftigt habe (beschäftigen mußte), konnte ich in den seltensten Fällen eine Software spurlos vom System entfernen. Irgendwelcher Müll (Registry-Einträge, vereinzelte Dateien) blieb immer zurück. Selbst die diversen Deinstallationshilfen mit Installations-Überwachungsfunktion bekamen das nicht immer hin. Ich kann mir denken, daß das System von PC BSD mit Sicherheit NICHT schlechter ist. Es gibt auch einige Linux-Distributionen, die ein vergleichbares System einsetzen. Und dort ist die RESTLOSE Entfernnung von Programmen gewährleistet. Außerdem soll PC BSD ja auch noch das klassische Ports-System unterstützen, für alle, die dem neuen System mißtrauen...
funktioniert denn da dann die gemeinsame Nutzung von Bibliotheken durch unterschiedliche Programme (zum einen bei gleichen Versionen zum anderen bei kompatiblen Versionen) oder lädt jedes Programm seine eigen Version der Bibliothek ?
(selbst wenn Festplatten immer mehr Platz bieten Arbeitsspeicher ist meist sehr viel weniger verfügbar)
Wenn die Bibiliothek tatsächlich im applikationseigenen Verzeichnis liegt dann wird sie jeweils einzeln geladen und belegt doppelten bzw. dreifachen Speicher. Ist also völliger Unsinn vor allem weil ja nur selten wirklich die ganze Lib benötigt wird. Wenn schon denn schon dann doch lieber statisch linken, was allerdings nicht immer geht (stichwort dynamisches laden von modulen zur laufzeit wie das gtk+2 macht).
Habe gerade Vista getestet, der Prozessor und die GrafikOnboard auf meinem Testrechner sind ihm zu langsam, daher keine Installation möglich. Vielen Dank
So neu ist das nicht. Gibt es bereits seit längerem unter ROX.
PC-BSD gibt es auch schon länger, woher willst du wissen ob ROX eher war?
Trotzdem man sieht ja an Windows das, das nicht so gut sein kann, mehr Speicherplatz wird dadurch sowieso benötigt!
recht hat er
zur Datei /usr/lib/libvte.so.9.1.6
den Symlink /usr/lib/libvte.so.5 setzt. Das dumme Linux denkt dann da wäre tatsächlich eine libvte.so.5 mit entsprechender API. Funktioniert auch recht häufig leider nicht immer und ist sehr unsauber. Unter windows gibt es GUIDs mit denen man Bibliotheken eindeutig kennzeichnen kann, was normalerweise auch geschieht.
Also lieber mal ein bisschen Fachwissen bringen statt endloser Polemik.
Wer erinnert sich eigentlich noch an die GDI-Lücke in Windows? An diesem Beispiel sieht man, wohin dieses Vorgehen führen kann.
Jedes PBI-Paket beinhaltet die notwendigen Bibliotheken und "Abhängigkeiten". Wird ein per PBI installiertes Programm "geupdatet" (schönes Wort *g), so betrifft das Update auch nur dieses eine Programm.
Logo, es werden sicherlich ein paar *libs doppelt und dreifach angelegt - aber - bei den heutigen Monsterfestplatten macht das nicht soooo viel. Ausserdem kann man ja die klassische Portsammlung nutzen - wo ist nun eigentlich das Negative .... ???
Einen Vergleich mit der "GDI-Lücke" würde ich nicht an dieser Stelle nicht anführen.
Sollte natürlich nur einmal "nicht" dastehen ....
Die Festplattenbedarf ist ja auch nicht relevant. Die Bibliotheken liegen mehrfach im Arbeitsspeicher und der ist wesentlich begrenzter. Außerdem ist dieses Vorgehen sehr schlecht, was Sicherheitsupdates betrifft. Anstatt beispielsweise ein zlib Update zu machen, muß von jeder Anwendung, die zlib inkludiert, ein Update erfolgen. Das können eine ganze Menge Anwendungen sein; die Wahrscheinlichkeit das eine inkludierte Bibliothek übersehen, das System somit anfällig für Black Hats wird, ist dementsprechend groß.
Um es kurz zu machen: Der Ansatz, der hinter PBI (u.ä.) steht, ist komplett dümmlich. Von dem Verlust der anderen Vorteile, die der FHS-Ansatz bietet mal abgesehen.
Wahrscheinlichkeit, daß...
Lern Deutsch Lan!
Korrekt ist ",die die zlib enthält" oder stilistisch besser ",welche die zlib enthält"
Mir muskelkatert von anfälliger Lachung!
Als ich mit damit noch beschäftigt habe (beschäftigen mußte), konnte ich in den seltensten Fällen eine Software spurlos vom System entfernen. Irgendwelcher Müll (Registry-Einträge, vereinzelte Dateien) blieb immer zurück. Selbst die diversen Deinstallationshilfen mit Installations-Überwachungsfunktion bekamen das nicht immer hin.
Ich kann mir denken, daß das System von PC BSD mit Sicherheit NICHT schlechter ist.
Es gibt auch einige Linux-Distributionen, die ein vergleichbares System einsetzen. Und dort ist die RESTLOSE Entfernnung von Programmen gewährleistet.
Außerdem soll PC BSD ja auch noch das klassische Ports-System unterstützen, für alle, die dem neuen System mißtrauen...
MfG
(selbst wenn Festplatten immer mehr Platz bieten Arbeitsspeicher ist meist sehr viel weniger verfügbar)
Gruß, Fusselbär