Von Anonymous Coward am Mo, 11. November 2019 um 13:24 #
Spiele verwenden 3D-Grafik-APIs wie Vulkan und OpenGL, und deren Implementierungen sind notwendigerweise stark hardwarespezifisch. Bei einem Container werden aber alle Bibliotheken mitgeliefert, also auch die OpenGL- oder Vulkan-Implementierung. Wie soll also ein solcher Container langfristig lauffähig bleiben, wo doch ständig neue 3D-Chips auf den Markt kommen?
Spiele verwenden 3D-Grafik-APIs wie Vulkan und OpenGL, und deren Implementierungen sind notwendigerweise stark hardwarespezifisch.
Äh … nein?
Genau das ist doch gerade der Sinn einer solchen Grafik API, dass man eben nicht hardwarespezifisch entwickeln muss. Bei Vulkan natürlich sehr hardware-nah, aber solange die HW den entsprechenden Standard (+ ggf. Erweiterungen, die man aber gezielt abfragen kann) unterstützt sollte das auch funktionieren.
Genau aus dem Grund funktionieren DX9 (oder älter) Spiele ja auch noch wunderbar mit neueren Grafikkarten. Wenn es an etwas scheitert, dann eher an anderen Stellen, nicht aber der Grafik API.
Naja die Implementierung dieser APIs basiert aber auf dem Treiber bzw. die API wird von diesem Implementiert. Da hat der OP schon Recht.
Allerdings gibt es Lösungen wie z.B. Docker-NVIDIA, die dynamisch die auf dem Host installierten Userspace-Bibliotheken des Treibers reinladen. Also handelt es sich um ein bereits gelöstes Problem.
Bei mir läuft Steam via Flatpak. Nach jedem System-Update führe ich noch einmal `flatpak update` aus, beim ersten Start von Steam danach macht das auch noch meist einmal irgendwas, aber dann kann wieder gezockt werden, ohne das Steam mit seinen ganzen 32-Bit- und Treiberabhängigkeiten das System zumüllt.
Wird bestimmt lustig, wenn Steam jetzt auch noch selbst mit Containern anfängt ...
Viel wichtiger wäre mir, dass der Steamclient selbst in Containern läuft.
Und dass alte Spiele nun auch in Containern eher weiterlaufen werden ist zwar auf der einen Seite schön zu hören, aber auf der anderen Seite bedeutet das auch, dass sich niemand um die Sicherheitslücken in den verwendeten Bibliotheken innerhalb der Container kümmern wird.
Wenn man so ein Spiel also online in vielen Jahren spielen sollte, dann kann eine Sicherheitslücke in einer alten Bibliothek, die man nicht updaten kann, zum Problem werden. Und es ist leider nicht so, dass ein Container ein 100 % iger Schutz sei, denn das ist er nicht, er erhöht lediglich das Sicherheitslevel ein bisschen.
Wenn du da Zeit und Lust hast, kannst du die Ausführung von Steam in einem Container auch selbst nachrüsten: http://ludiclinux.com/Nspawn-Steam-Container/
Deutlich einfacher und auch in irgendeiner Form gesandboxt, wäre die Installation von Steam über Flatpak. Ich kann aber nicht beurteilen, wie weit diese Sandbox aufgespannt ist. Auf's /home-Verzeichnis kann Steam dann wohl schon mal nicht mehr zugreifen, wie ich hier gerade in einem definitiv vertrauenswürdigen Kommentar im Internet gelesen habe. Am besten selbst nachlesen, wie's um die Sicherheit von Flatpak so aussieht.
Spiele verwenden 3D-Grafik-APIs wie Vulkan und OpenGL, und deren Implementierungen sind notwendigerweise stark hardwarespezifisch. Bei einem Container werden aber alle Bibliotheken mitgeliefert, also auch die OpenGL- oder Vulkan-Implementierung. Wie soll also ein solcher Container langfristig lauffähig bleiben, wo doch ständig neue 3D-Chips auf den Markt kommen?
Genau das ist doch gerade der Sinn einer solchen Grafik API, dass man eben nicht hardwarespezifisch entwickeln muss.
Bei Vulkan natürlich sehr hardware-nah, aber solange die HW den entsprechenden Standard (+ ggf. Erweiterungen, die man aber gezielt abfragen kann) unterstützt sollte das auch funktionieren.
Genau aus dem Grund funktionieren DX9 (oder älter) Spiele ja auch noch wunderbar mit neueren Grafikkarten.
Wenn es an etwas scheitert, dann eher an anderen Stellen, nicht aber der Grafik API.
Naja die Implementierung dieser APIs basiert aber auf dem Treiber bzw. die API wird von diesem Implementiert. Da hat der OP schon Recht.
Allerdings gibt es Lösungen wie z.B. Docker-NVIDIA, die dynamisch die auf dem Host installierten Userspace-Bibliotheken des Treibers reinladen. Also handelt es sich um ein bereits gelöstes Problem.
Bei mir läuft Steam via Flatpak. Nach jedem System-Update führe ich noch einmal `flatpak update` aus, beim ersten Start von Steam danach macht das auch noch meist einmal irgendwas, aber dann kann wieder gezockt werden, ohne das Steam mit seinen ganzen 32-Bit- und Treiberabhängigkeiten das System zumüllt.
Wird bestimmt lustig, wenn Steam jetzt auch noch selbst mit Containern anfängt ...
Offenbar hast Du nicht verstanden, was der Unterschied zwischen einer API und ihrer Implementierung ist.
Viel wichtiger wäre mir, dass der Steamclient selbst in Containern läuft.
Und dass alte Spiele nun auch in Containern eher weiterlaufen werden ist zwar auf der einen Seite schön zu hören, aber auf der anderen Seite bedeutet das auch, dass sich niemand um die Sicherheitslücken in den verwendeten Bibliotheken innerhalb der Container kümmern wird.
Wenn man so ein Spiel also online in vielen Jahren spielen sollte, dann kann eine Sicherheitslücke in einer alten Bibliothek, die man nicht updaten kann, zum Problem werden.
Und es ist leider nicht so, dass ein Container ein 100 % iger Schutz sei, denn das ist er nicht, er erhöht lediglich das Sicherheitslevel ein bisschen.
> leider nicht so, dass ein Container ein 100 % iger Schutz
Insbesondere, wenn der Docker daemon als root läuft – man sollte dringend user namespaces verwenden:
Sicherheit durch namespaces
Wenn du da Zeit und Lust hast, kannst du die Ausführung von Steam in einem Container auch selbst nachrüsten: http://ludiclinux.com/Nspawn-Steam-Container/
Deutlich einfacher und auch in irgendeiner Form gesandboxt, wäre die Installation von Steam über Flatpak. Ich kann aber nicht beurteilen, wie weit diese Sandbox aufgespannt ist. Auf's /home-Verzeichnis kann Steam dann wohl schon mal nicht mehr zugreifen, wie ich hier gerade in einem definitiv vertrauenswürdigen Kommentar im Internet gelesen habe. Am besten selbst nachlesen, wie's um die Sicherheit von Flatpak so aussieht.