Distributionsfremde Software
Natürlich hat keine Distribution jede Software, die unter Linux läuft und auch nicht jede Version jeder Software, die unter Linux läuft.
Der Standardweg bei paketbasierten Distributionen ist, sich eine Paketquelle zu suchen, die die gewünschte Software in der richtigen Version enthält, um die auf dem eigenen System installieren zu können. Diese Quellen werden häufig als "Fremdquellen" referenziert und sind häufig (nicht immer) ein Grund, dass auf dem eigenen System etwas nicht (mehr) rund läuft.
Meine Erfahrung lehrt mich, dass ich gerne weitestgehend auf solche Fremdquellen verzichten möchte.
Über die Fremdquellen hinaus, gibt es noch eine Reihe an Möglichkeiten, die Software auf das eigene System zu bekommen.
- Selbst übersetzen: Den Quelltext herunterladen und über einen mehr oder weniger einfachen Weg, die Software zu compilieren und zu installieren. Darauf verzichte ich, weil es selten eine Möglichkeit gibt, die Software wieder zu deinstallieren und weil man bei jedem Update von benutzten Bibliotheken oder des Compilers neu übersetzen müsste.
- Static Binary: Das ist eine Programmdatei, die alleine lauffähig ist und keine weiteren Dinge benötigt. Solche Binaries setze ich ein und installiere sie zumeist nach
~/.local/bin, was ich auch im Pfad habe. Static Binaries lade ich via Chezmoi herunter, zum testen via eget. - Tarballs oder Archive: Setze ich ebenfalls ein, aber überwiegend bei Webanwendungen. Dort habe ich die Release-Seite von GitHub, GitLab oder Codeberg abonniert und installiere sie frühestens drei Tage nach Erscheinen, da es häufig noch Bugfixes gibt. Dafür erstelle ich mir einen Task in meiner Aufgabenverwaltung.
- AppImages: Sind ähnlich wie static Binaries - in einer Datei ist alles enthalten - wird aber von mir nicht benutzt.
- Flatpaks: Benutze ich, das sind gekapselte Anwendungen, die in einer Sandbox laufen und sich leicht installieren und auch wieder rückstandsfrei deinstallieren lassen.
- Snaps: Setze ich gar nicht ein. Funktionieren ähnlich wie Flatpak, nur das ein Daemon im Hintergrund läuft.
- Container: Setze ich mit Podman ein, zum Teil für "normale" Anwendungen aber auch für Serverdienste. Ich setze dabei auf Podman und auch podman-compose.
- Container: Wenn die Software für ein anderes Betriebssystem verfügbar ist, nutze ich Distrobox, um die Software mir lokal ins Userland zu holen (Beispielsweise binde ich den Citrix-Client mit einem Ubuntu-Container in meinem System ein).
Und Ihr so?
Trackbacks
Keine Trackbacks
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
liegeradler am :
Dirk Deimeke am :
Stefan am :
Um die proprietären Snaps mache ich auch einen Bogen.
Flatpaks präferiere ich, die laufen gut und sind in Programme wie KDE Discover eingebunden. Über flatpak-builder lassen sich viele Programme auch recht komfortabel kompilieren und man kann auch die drölfzig Entwicklerpakete verzichten.
Dirk Deimeke am :
Michael am :
Seit ich appman (https://github.com/ivan-hc/AppMan) kennengelernt habe, bin iuch auch ein grosser Freund von Appimages geworden.
Dirk Deimeke am :
https://www.chezmoi.io/reference/special-files/chezmoiexternal-format/
Ein "chezmoi update" mache ich jeden Tag.
Appman ist ein guter Tipp, in Shelly (CachyOS) gibt es auch so etwas.
Oliver Kraitschy am :
Dirk Deimeke am :
Aber damit habe ich gar keine Erfahrungen.
Robert am :
Ansonsten verwende ich einige Flatpaks sowie AppImages. Um AppImages aktuell zu halten, verwende ich seit einiger Zeit "bin": https://github.com/marcosnils/bin
Dirk Deimeke am :
Danke für den Tipp!
Tredup am :
Firefox unter Windows zum Beispiel.
Stefan am :
Ich finde die zentralen Systeme wie Paketmanager und Flatpaks dem "Windows-Konzept" mehrere Jahrzehnte voraus. Da muss man jeder App quasi täglich manuell auf Updates über prüfen. Einzeln! Unter Linux drückt man einen Knopf und alles wird aktualisiert. 👍
Dirk Deimeke am :
Stefan am :
Klar, für manuell kompilierte Programme und AppImages gilt das nicht. Bei ersterem ergibt es Sinn, weil... wie? Bei Letzterem ist es ein Fail des Konzepts. Aber auch da gibt es Drittanwendungen, die das meinen zu lösen. Keine Ahnung, ich mache einen Bogen um AppImages.
Dirk Deimeke am :
Dirk Deimeke am :
Aber: Distributionen kuratieren neue Releases und nehmen sie erst auf, wenn sie auf der Distribution getestet wurden. Die Gefahr, dass etwas nicht funktioniert, wird damit minimiert.
Zusätzlich ist es so, dass Linux (oder Unix im Allgemeinen) das Konzept von Shared Libraries kennt. Das bedeutet, dass Bibliotheken, die mehrere Anwendungen verwenden, nur einmal installiert werden müssen. Das macht das Testen etwas aufwendiger.
Ansonsten gilt das von Stefan Gesagte. Ich kann unter Linux mit einem Kommando System UND Anwendungen aktualisieren. Also komplett.
Norbert Tretkowski am :
Dirk Deimeke am :
Mittlerweile hat die Distribution einen Weg genommen, der mir nicht mehr ganz so gut gefällt.
Jörg am :
wie viele hier bevoruge ich Software aus den Paketquellen meiner Distribution. Dazu kommen einzelne Fremdquellen, die sich über die Jahre als stabil genug erwiesen haben.
AppImages und Flatpaks benutze ich ebenfalls. Häufig ist der Grund dafür, eine GUI-Anwendung in der gleichen Version auf verschiedenen Distributionen nutzen zu können. Oder es gibt sie in den Paketquellen schlicht nicht mehr.
Noch relativ neu in meinem Fundus sind toolbox container. Diese nutze ich ähnlich wie Dirk Distrobox, um Anwendungen zu nutzen, die für das Userland einer anderen Distribution gebaut und getestet wurden. Für die Ausführung der Container verwende ich Podman und podman-compose.
Viele Grüße
Jörg
Dirk Deimeke am :
Jörg am :
Ich bin mir des Risikos der Fremdquellen ja durchaus bewusst. Es hilft, wenn man einen guten Draht zu der Person hat, die die Quelle betreut.
An die Lesenden an den Datensichtgeräten daheim: "Nicht nachmachen."
Dirk Deimeke am :
Auf meinem CachyOS läuft gerade das ProtonVPN nicht mehr, Versionskonflikt mit Python ... sollte eigentlich nicht passieren.