Dank des letzten Artikels haben wir nun ein laufendes Linux. Der nächste logische Schritt für mich ist es nun, das Thema Softwareinstallation genauer zu betrachten. Da es auch hier linuxüblich mal wieder verschiedene Möglichkeiten gibt, wird sich dieser Artikel primär um die Installation von nativer Linux-Software drehen. Aber natürlich geht es nicht nur um die Betrachtung als Selbstzweck, sondern wir agieren, wie auch bisher, zielorientiert. Im ersten Artikel habe ich ja geschrieben, dass neben Browser und (Libre)Office mindestens am Ende folgende Anwendungen funktionieren sollen: Steam, Heroic Games Launcher, Blender, Marmoset Toolbag 5, Affinity Suite, Godot, Unreal Engine 5, Substance 3D Designer, Substance 3D Painter und div. Programmiertools (Python, Rust, C#, C++ und Kotlin). Also gilt es, zusätzlich herauszufinden, von welcher Software es eigene Linux-Versionen gibt und wie diese “am besten” installiert werden.

Bevor es wirklich losgeht, hier wie gewohnt die Übersicht über alle bislang erschienen Artikel dieser Serie:

1. Linux? Was zum Pinguin!?
2. Grundlegende Installation der Linux Distribution
3. Installation von nativer Linux-Software

Installationsmöglichkeiten

Bevor ich zu den verschiedenen Installationsmöglichkeiten komme, werde ich zuerst auf die Unterschiede zwischen Windows und Linux bei dieser Thematik eingehen.

In der Windows-Welt war es lange Zeit üblich, dedizierte Installationsprogramme für Software auszuführen, und viele Menschen handhaben dies immer noch so. Früher waren die Quellen Disketten, CDs oder DVDs, doch in den letzten Jahrzehnten wird das Internet zur primären Bezugsquelle geworden sein. Das heißt, die Vorgehensweise war bzw. ist, über mehr oder weniger vertrauenswürdige Quellen ein Installationsprogramm zu bekommen, welches dann für die korrekte Ausführung meist Administratorrechte benötigt. Auch wenn seit Windows 8 der Microsoft Store (bzw. bis Oktober 2017 Windows Store) ein fester Bestandteil von Windows ist, habe ich ihn persönlich noch nie benutzt und weiß auch von keiner Person, die ihn benutzt. Mit Chocolatey und ähnlichen Projekten gibt es seit 2011 auch einen Paketmanager für die Kommandozeile, aber auch dabei vermute ich, dass sich diese Lösungen außerhalb von Entwicklerkreisen nicht durchsetzen konnten.

Wirklich verwunderlich finde ich das mittlerweile nicht. Die Windows-Welt fühlt sich für mich sehr oft wie “friss oder stirb” an. Jedes Programm liefert in der Regel alle notwendigen Bibliotheken mit (Windows-Bibliotheken mal außen vor). Größere Hersteller haben teilweise sogar eigene Launcher, um De- / Installation, Aktualisierung und Konfiguration zu übernehmen und versuchen so, ihr eigenes (Unter-) Ökosystem zu etablieren.

Unter Linux ist dies traditionell deutlich anders. Jede Distribution bringt direkt einen Paketmanager mit, welcher, wie der Name schon sagt, für die Verwaltung (De-/ Installation und Aktualisierung) der Pakete zuständig ist und die primäre Bezugsquelle darstellt. Bei den Paketmanagern lassen sich auch Paketquellen konfigurieren, deren Inhalte vom Paketmanager gecached werden. Ursprünglich befanden sich die Paketquellen überwiegend auf Datenträgern (bspw. Installationsmedien der Distribution), die für die Erstellung des Caches ausgelesen wurden. Dank des Caches konnte man auch ohne eingelegten Datenträger die zur Verfügung stehenden Pakete sehen. Auch in der heutigen Zeit, in der die Paketquellen überwiegend über das Netzwerk / Internet genutzt werden, ist der Cache sehr sinnvoll, da es weiterhin performanter ist, den optimierten Cache abzufragen, als auf die Antworten diverser Server zu warten.

Ich spreche in diesem Zusammenhang bei Linux immer explizit von Paketen, welche die unterschiedlichsten Dinge beinhalten können. Auch wenn Software und Bibliotheken vermutlich die häufigsten Vertreter von Paketen sind, können es im Fall von Themes auch Konfigurationen und / oder Grafiken sein. Natürlich sind auch Bibliotheken Software, aber da Bibliotheken wiederum von anderer Software benötigt werden, also Abhängigkeiten darstellen, sollte man sie einzeln betrachten. So können sich mehrere Pakete Abhängigkeiten teilen und so Speicherplatz sparen, da die Abhängigkeiten jeweils nur einmal installiert sein müssen. Man sieht also unter Linux traditionell einen sehr kooperativen Ansatz.

Der traditionelle Ansatz, die Softwareverwaltung über den Paketmanager zu lösen, hat leider nicht immer nur Vorteile. Wie ich bereits erwähnt habe, ist der eigentliche Ansatz unter Linux ein kooperativer. Leider funktioniert dieser Ansatz aber nur, solange sich alle Pakete mit gleichen Abhängigkeiten auf eine bestimmte Version dieser Abhängigkeiten geeinigt haben oder aber die gemeinsamen Abhängigkeiten eine entsprechend lange Abwärtskompatibilität sicherstellen. Ein weiteres Problem kann sich ergeben, wenn man die aktuellste Version einer Software nutzen möchte, welche es in den Paketquellen der gewählten Distribution noch nicht gibt. Und spätestens wenn wir über kommerzielle Software sprechen, werden wir über alternative Verteilungswege nachdenken müssen, da kaum ein Hersteller bereit ist, passende Pakete für alle Distributionen bereitzustellen. Ein weiterer Grund, nicht die offiziellen Paketquellen zu nutzen, kann sein, dass man eine Software in einer bestimmten Version oder vielleicht sogar die gleiche Software in unterschiedlichen Versionen parallel nutzen können möchte.

Manchmal bieten Hersteller, vor allem von kommerzieller Software, auch für Linux Installer an. Als ich das letzte Mal CrossOver benutzt habe, wurde neben distributionsspezifischen .rpm und .deb Paketen auch ein generischer Installer angeboten, den man dann in der Kommandozeile ausführen konnte.

Wenn Software alle notwendigen Abhängigkeiten direkt mitliefert, also wie es meist eher in der Windows-Welt üblich ist, bekommt man die Software teilweise einfach als Archiv zum Download angeboten. Dieses muss dann nur an die gewünschte Stelle entpackt werden und schon kann man die Software starten. JetBrains handhabt dieses Verfahren für die Linux-Versionen der verschiedenen IDEs.

Ein Ansatz, der versucht, es Benutzern noch einfacher zu machen, ist das sogenannte AppImage. Dabei ist die gesamte Software in einer einzelnen ausführbaren Datei “gepackt”.

Alle bislang vorgestellten Möglichkeiten haben einen gemeinsamen Nachteil. Sie unterstützen kein Sandboxing. Das hat zur Folge, dass die Software, solange sie ausgeführt wird, auf alles zugreifen kann, worauf der ausführende Benutzer Zugriff hat. Das stellt zwar eigentlich auf allen Desktop-Betriebssystemen den Standardfall dar, aber bedeutet im Gegenzug, dass Nutzer der Software entsprechendes Vertrauen entgegenbringen müssen.

Für alle, die zumindest für bestimmte Software, höhere Sicherheitsansprüche haben, gibt es auch Projekte, die Sandboxing unterstützen, sodass die Software dann weniger weitgreifende Rechte hat. Die beiden bekanntesten Projekte / Technologien in diesem Bereich sind:

Flatpak

• OpenSource-Projekt, welches ursprünglich von einem RedHat Entwickler intiiert wurde
• Fokus auf Desktopanwendungen
• Sandboxing über Kernel Namespaces (ähnlich wie bei Containern)
• Benötigt keine Hintergrunddienste
• Wird von sehr vielen Distributionen unterstützt
• Oftmals schneller als Snap-Versionen, da weniger Overhead vorhanden
• Keine integrierten automatischen Updates
• Installation von Flatpaks benötigt keine Adminrechte
• Aufwendiger, als Entwickler Pakete zu erstellen
• Flathub bietet 1000+ Anwendungen an

Snap

• Initiiert von Canonical, also dem Unternehmen hinter Ubuntu
• War ursprünglich für IoT-Einsatzzwecke gedacht, kann aber mittlerweile auch mit GUI-Anwendungen umgehen
• Sandboxing über AppArmor
• Benötigt snapd als Hintergrunddienst
• Wird eigentlich nur im Ubuntu-Ökosystem eingesetzt
• Meist langsamer als die Flatpak-Versionen
• Automatische Updates
• Installation von Snaps benötigt Adminrechte
• Einfacher, als Entwickler Snaps (Pakete) zu erstellen
• Snap Store bietet 100!? Anwendungen an

Installation

So, genug der grauen Theorie und Hintergrundinformationen. Setzen wir das bislang Gelernte nun endlich in die Praxis um. Dabei habe ich versucht, die Beispiele so zu wählen, dass wir auch die besprochenen Installationsmöglichkeiten betrachten können.

GPU-Treiber

Eines der ersten Dinge, die ich nach der Installation des Grundsystems überprüft habe, war, wie es um die GPU-Treiber bestellt ist. Am schnellsten geht es mit dem Programm lspci in der Kommandozeile:

> lspci -k | grep VGA -A3
0000:00:02.0 VGA compatible controller: Intel Corporation Alder Lake-HX GT1 [UHD Graphics 770] (rev 0c)
        DeviceName: Onboard - Video
        Subsystem: Micro-Star International Co., Ltd. [MSI] Device 13cf
        Kernel driver in use: i915
--
0000:01:00.0 VGA compatible controller: NVIDIA Corporation AD106M [GeForce RTX 4070 Max-Q / Mobile] (rev a1)
        Subsystem: Micro-Star International Co., Ltd. [MSI] Device 13cf
        Kernel driver in use: nvidia
        Kernel modules: nouveau, nvidia_drm, nvidia

lspci listet generell alle angeschlossenen PCI-Geräte auf. Durch die Option -k werden zusätzlich die aktiven Kerneltreiber aufgelistet. Damit wir selbst nicht die gesamte Hardwareliste durchsuchen müssen, wird durch | die Befehlsausgabe an den darauffolgenden Befehl weitergeleitet. In unserem Fall ist dies der Befehl grep, welcher Ausgaben oder Dateien nach bestimmten Mustern, in diesem Fall nach der Zeichenfolge VGA, durchsucht. Durch die Option -A3 zeigt grep zu jeder gefundenen Zeile zusätzlich die darauffolgenden 3 Zeilen an.

Erfreulicherweise kann man an dem Ausgabeergebnis sehen, dass sowohl für die integrierte Intel-GPU als auch für die dedizierte NVIDIA-GPU Treiber geladen sind. Das bedeutet, dass CachyOS meine Hardware nicht nur korrekt erkannt hat, sondern auch direkt die zugehörigen Treiber installiert hat.

Woher weiß Linux nun, wann welche GPU verwendet werden soll? Um diese Frage zu beantworten, gibt es eine passende Wiki-Seite von CachyOS. Dort erfährt man, dass alle Vorbereitungen automatisch von CachyOS getroffen wurden und man bei Nutzung des proprietären NVIDIA-Treibers, also wie in meinem Fall, nun durch Setzen passender Umgebungsvariablen bestimmen kann, dass die dedizierte GPU genutzt werden soll. Wenn euch das zu aufwendig ist, könnt ihr auch einfach das Programm prime-run nutzen, welches das Setzen der Umgebungsvariablen übernehmen kann.

Auf der Wiki-Seite werden noch weitere Möglichkeiten aufgezeigt, die wir uns im Fall von Lutris und Steam auch noch ansehen werden.

Wir haben hier nur bedingt etwas installiert, daher gab es bisher auch keine sinnvolle Möglichkeit, über die verschiedenen Installationsmöglichkeiten nachzudenken, aber selbst wenn, würde ich an dieser hardwarenahen Stelle möglichst immer den Weg über den Paketmanager wählen, da so in der Regel auch gewährleistet wird, dass die Treiber bzw. Pakete bei einer Systemaktualisierung ebenfalls aktualisiert werden.

LibreOffice

LibreOffice ist meiner Erfahrung nach für die meisten Anwendungsfälle eine adäquate Alternative zu Microsoft Office. Auf der Website gibt es Unterseiten für die Installation über RPM- oder DEB-Pakete, AppImage, Flatpak und Snap. Zusätzlich stellt eigentlich auch jede Distribution passende Pakete über den Paketmanager bereit.

Da ich kein PowerUser von Office-Anwendungen bin und somit nicht auf spezielle Versionen angewiesen bin, empfinde ich die Installation über den Paketmanager am einfachsten, da so auch (Sicherheits-) Updates über die normale Systemaktualisierung behandelt werden. Um es auch weniger kommandozeilenaffinen Menschen nicht unnötig schwer zu machen, wähle ich dieses Mal das Programm Octopi. Octopi wird standardmäßig von CachyOS mitinstalliert und bietet eine grafische Oberfläche für die Paketverwaltung. Generell gibt es zwei Versionen von LibreOffice:

• libreoffice-fresh: Aktuellste stabile Version
• libreoffice-still: Ausgiebig getestete Version

Ich habe mit libreoffice-fresh nie Probleme feststellen können, daher installiere ich es auch dieses Mal. Sofern US-Englisch nicht die gewünschte Sprache darstellt, sollte man passend zum Hauptpaket der gewünschten LibreOffice-Version, auch das gewünschte Sprachpaket mitinstallieren, in meinem Fall installiere ich also libreoffice-fresh-de mit.

Blender

Blender wird ebenfalls über diverse Kanäle angeboten, z.B. über die Website als Archiv oder auch als Snap oder über Steam. Dazu kommt, wie so oft bei OpenSource-Software, die Verfügbarkeit über den Paketmanager.

Da es immer mal wieder vorkommt, dass ich für bestimmte Projekte fest definierte Versionen von Blender nutzen muss, nutze ich dafür immer den Archiv-Download. Das Archiv lässt sich einfach in einen bestimmten Ordner entpacken, so kann ich auch unterschiedliche Blender-Versionen parallel nutzen.

Substance 3D Designer (Steam-Version)

Den einen oder anderen wird es vielleicht wundern, aber Substance 3D Designer hat eine native Linux-Version. Das dürfte, wie generell die Verfügbarkeit über Steam und die ewige Lizenz, ein weiteres Überbleibsel aus der Zeit vor der Übernahme von Allegorithmic durch Adobe sein. Das wird auch der Grund sein, warum man diese mit Linux kompatible Version nur über Steam bekommt, zumal die Adobe Creative Cloud meines Wissens nicht unter Linux läuft.

Sofern man die Steam-Version von Substance 3D Designer besitzt, funktioniert die Installation so, wie man es von Steam gewohnt ist. Weitere Schritte waren bei mir nicht notwendig. Sogar der explizite Start mit Hilfe von prime-run war nicht notwendig, um Zugriff auf die dedizierte NVIDIA-GPU zu haben.

Substance 3D Painter (Steam-Version)

Bei Substance 3D Painter gilt die gleiche Einleitung wie bei Designer. Die grundlegende Installation funktioniert ebenfalls wie von Steam gewohnt.

Leider gibt es aktuell aber noch ein paar Kompatiblitätsprobleme, die ein paar Nacharbeiten erfordern. Freundlicherweise sind die Entwickler sich dessen nicht nur bewusst und wollen die Probleme bald beheben, sondern haben auch entsprechende Workarounds dokumentiert. Der erste Schritt dafür ist es, die Kompatiblität für Substance 3D Painter auf “Legacy Runtime 1.0” zu setzen (siehe Screenshot).

Im zweiten Schritt müssen wir noch die Pakete xcb-util-cursor und libtiff5 installieren. Anschließend sollte Painter starten.

Unreal Engine

Unreal Engine für Linux wird nicht über den Epic Games Launcher installiert. Meiner Meinung nach ist es Fluch und Segen gleichzeitig, da ich den Launcher für langsam und schlecht umgesetzt halte, auch wenn er die Installation inkl. Fab-Assets an einer Stelle bündelt. Generell sollte ich an dieser Stelle vielleicht erwähnen, dass man, sollte man UE 4 einsetzen wollen / müssen, die Linux-Version selbst kompilieren muss. Aber da die Verbreitung von UE 4 nachlässt und ich aktuell selbst ebenfalls kein Projekt dafür habe, erspare ich uns die Beschreibungen hier. Sollte es dennoch jemand benötigen, so finden sich entsprechende Anleitungen dafür in der zugehörigen Dokumentation.

Nachdem man das knapp 25 GB große Zip-Archiv an die gewünschte Stelle entpackt hat, kann man den UnrealEditor starten. Die ausführbare Datei UnrealEditor findet man unterhalb von Engine/Binaries/Linux und startet dann die Projektauswahl, wie man es auch unter Windows gewohnt ist. Sollten die Tooltips oder die Oberfläche generell zu groß wirken, ist die Unterstützung für “High DPI” aktiviert und sollte deaktiviert werden. Die deaktivierten Editor-Einstellungen seht ihr auch nochmal im Screenshot.

Damit ist die grundlegende Installation abgeschlossen. Das Fab-Plugin findet ihr übrigens ebenfalls auf der Downloadseite. Viel mehr Erfahrung habe ich mit der Unreal Engine unter Linux auch noch nicht sammeln können. Aber das wird sich wohl in nächster Zeit dann ändern.

Aber einen kleinen abschließenden Tipp habe ich dann doch noch: Wenn ihr die Houdini Engine für UE unter Linux nutzen wollt, solltet ihr diesem Beitrag folgen. Da ich selbst nicht mit Houdini arbeite, so faszinierend ich die Software auch finde, konnte ich es selbst nicht nachvollziehen.

Ausblick

Im nächsten Artikel widme ich mich der Installation von Windows-Software unter Linux. Als Beispiele werden dann erst einmal Marmoset Toolbag 5 und die Affinity Suite 2 dienen. Aber keine Angst, auch das Thema Gaming mit Proton folgt noch, wo dann auch der Heroic Games Launcher, Lutris und Steam noch detailliert betrachtet werden.