Daniel Bauer schrieb:
Ich wollte eigentlich nichts dazu schreiben, aber bei soviel Novitäten-Skepsis wie ich die hier gelesen habe, muss ich dann doch mal.
Ich wollte auch nicht, und ich glaube auch nicht, dass eine Disusion hier irgendwelchen Einfluss auf das hat, was dann wirlich kommt.
Ich auch nicht, aber trotzdem kann man ja drüber diskutieren. Man wird ja nicht dümmer dabei.
Der Trend zu den Containern - den sehe ich sehr positiv.
Wird es dann nicht so ein, dass die gleiche Funktion/Library eventuell in verschiedenen Containern in unterschiedlichen Versionen vorliegt, halt abhängig davon, wann der Container von wem gemacht wurde? Dass ich also, wenn ich mehrere Programme laufen habe, unterschiedliche Verhalten/Bugs einer Funktion haben werde?
... dass dann ein Programm Videos zeigen, Musik abspielen kann und ein anderes nicht, weil es nicht die die packman-Versionen enthält? Wie kommen die packman libraries in einen opensuse-container, der diese aus rechtlichen Gründen nicht enthalten kann?
... dass wesentlich erhöhter Memory-Bedarf besteht, weil die gleiche library xmal geladen werden muss? Memory ist ja nicht gerade billig und manche Motherboards erlauben auch nicht besonders viel...
... dass das Laden eines Programms wesentlich länger dauern wird, weil jedesmal ein ganzes Paket von libraries geladen werden muss, die eventuell eigentlich "schon da" wären?
... dass Schwierigkeiten bestehen werden, wenn z.B. ein Programm ein anderes aufrufen will. Ich erinnere mich an einen Digikam-Container, der ein Bild nicht an gewisse andere auf meinem System vorhandene Programme mit "öffnen mit..." übergeben konnte, während die RPM-Version von digikam das sehr wohl kann?
Vermutlich alles davon irgendwie schon. Wobei schon die Frage ist, ob das mehrfach verwendete "wesentlich" zutreffend ist. Die Bedenken sind aber im Grunde zutreffend. Eine Container-Software könnte aber auch hergehen und z.B. eine gewisse Deduplizierung vornehmen, auch im Hauptspeicher (und ja, vielleicht vergrößert das dann wieder die Angriffsfläche für einen böswilligen Ausbruch aus dem Container). Wenn die Container mal so den richtigen Durchbruch erleben, wird es sicherlich Lösungen geben, die alle diese Bedenken etwas "mildern".
Effektiv ist es doch schon so, dass professionelle Software, sofern sie unter Linux überhaupt existiert, sich sowieso schon alle Libraries mitbringt, weil alle Distris ihr eigenes Süppchen kochen und sich kein Software-Hersteller drauf verlassen kann, welche Libraries denn grade auf dem System drauf sind. Und genau deswegen sind die professionellen Pakete ja alle so groß.
Ist es nicht so, dass ein RPM Angaben dazu enthält, welche Libraries es benötigt und dann ggf. mit installiert, falls nicht vorhanden?
Ja, diese Angaben sind da, wenn auch RPM nur "meckert", wenn sie nicht erfüllt sind. zypper kann sie auflösen (und fragt noch mal nach). Aber darum ging es mir nicht, daher will ich das gerne noch mal erklären. Eine professionelle Software wie - ich bleibe bei meinem Beispiel - ein Video-Konferenz-Client braucht ETLICHE Libraries. In der Regel bringt sie ja eine GUI mit, muss also irgendwie mit der Xlib arbeiten und noch einem Dutzend Libraries aus diesem Umfeld. Sie benutzt auch etliche standardisierte Dienste im Internet, z.B. WebRTC als bestes Beispiel. Dafür braucht man dann auch wieder Libraries bzw. man greift im wesentlichen auf Browser bzw. *deren* Libraries zurück (heutzutage meistens Chrome). Und hier geht das Problem los. Es gibt Abhängigkeiten der Libraries *untereinander*. Jede Distri installiert unterschiedliche Versionen der Libraries, manchmal sogar mit unterschiedlichen Config-Optionen. Und mit neueren Versionen von Libraries ändern sich auch noch manchmal die Abhängigkeiten der Libraries untereinander (meist kommt noch was dazu). Manche Libraries bringen die Distris gar nicht mit, weil sie keine Open-Source-Software sind, z.B. Chrome. Und ständig bringen die Distris Updates raus, wo sich die Abhängigkeiten wieder ändern. Wenn ich nun einen Video-Konferenz-Client schreiben will, auf welche Library soll ich mich beziehen? Auf eine 5 Jahre alte, nur weil irgendeine konservative Distri die installiert? Nur selbst dann ist nie ganz sicher, ob es auch mit neueren Versionen geht. In der Regel wird der Entwickler zu den neuesten Versionen greifen. Nur dann ist nicht sicher, ob die auch installiert ist. Also bleibt ihm nichts anderes übrig, als die selbst mitzubringen. Und das geht dann über die komplexe Abhängigkeitskette weiter. D.h. "durch die Hintertür" haben wir es bei solcher Software EH SCHON, dass viele Libraries mehrfach installiert werden. Deswegen sind die RPMs für professionelle Software ja auch so groß. Man kann ja mal reinschauen, was da alles so drin ist. Man wird immer mal wieder erstaunt sein. Dies würde durch Container nicht schlechter, sondern besser. Weil nicht jede Anwendung sich selbst überlegen muss, wie sie "ihre Version" der Libraries "einbringt", sondern es gibt ein Standard-Verfahren, eben die Container, die sich um all die Nuancen kümmern, die dabei auftreten.
Nein, das gehört unter Linux systematisiert, statt hundert eigene Süppchen. Und Container existieren und sie sind hier die Lösung. Und dann werden auch kommerzielle Firmen Linux besser unterstützen.
Eventuell (wahrscheinlich?) verstehe ich etwas grundsätzlich falsch. Aber ist es nicht so, dass gerade in den Containern jeder sein eigenes Süppchen kocht, während mit den "normalen" Libraries so etwas wie ein Standard besteht?
Wie oben schon geschrieben, es kocht sowieso (fast) jeder sein eigenes Süppchen und erfindet dazu das Rad neu...
Und für den Anwender ändert sich erst mal gar nichts. Der Taschenrechner wird wohl auch weiterhin eine "normale" Applikation sein (eventuell auch Teil eines Desktop-Containers), schon der Browser nicht, und das mit Recht. Der ist doch DAS Einfalls-Tor für Malware. Ab in den Container und Ruhe ist. Und für Downloads über den Browser wird es schon eine standardisierte Lösung geben - weil Container ja eben ein Standard-Weg sind und kein Anwendungs-spezifischer Sonderschnitz. Wird vielleicht etwas umständlicher, aber viel, viel sicherer.
Warum ist ein Container sicherer? Die Programme in Container müssen sich ja mit meinen Disks, meinem Memory, meinem Grund-System... unterhalten und wenn die da was ändern möchten, dann können sie das doch, wenn sie es können, egal ob aus einem Container heraus oder "direkt".
Die Container sind ja erst mal abgeschottet, erst mal genau so wie bei chroot. "Richtige" Container erlauben dann DEFINIERTE "Ausbrüche" aus dem Container. Eine "traditionelle" Software hat uneingeschränkten Zugriff auf das ganze System, zumindest mit den Rechten des Users. Das ist schon ein Unterschied.
Wenn ich es recht verstehe, was wohl nicht der Fall ist, dann wäre doch die Gefahr grösser, wenn ich statt einer Library aus einem offiziellen Repo, x Versionen dieser Library in x Containern habe, oder nicht?
Selbst wenn da eine vulnerable Version der Library drin wäre, wäre ja erst mal "nur" der Container angreifbar. Und wenn eine Schwachstelle in der Library im Container entdeckt wird, muss sich eben der Maintainer des Containers drum kümmern (also auch das Fingerpointing wird minimiert). Versionshaltung ist auch bei den meisten Container-Lösungen Bestandteil des Container-Systems, ebenso wie das Deployment.
Mir persönlich wird sowieso nichts anderes übrig bleiben, als dann halt zu nehmen, was kommt. Auf Windows zu wechseln ist für mich nach 20 Jahren Linux keine Alternative.
So kann man es auch sehen... Nein, Windows ist wirklich keine Alternative, das hat andere Schwächen, vor allen Dingen, dass es "zu vernagelt" ist. Und auch ansonsten sehe ich persönlich keine echten Alternativen. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel