Schwarzatal.org


Hauptseite > Technik > EDV

openSUSE

Linux-Schummelzettel (Basis: openSUSE)

Die meisten Hinweise lassen sich direkt auch auf andere Distributionen übertragen. Die Inhalte stammen überwiegend aus ChatGPT-Ausgaben und wurden hier übernommen, da der visuelle Editor von MediaWiki damit zuverlässig umgehen kann. Es ist jedoch zu beachten, dass Sprachmodelle Informationen aus verschiedenen Quellen mischen und nicht immer den aktuellen Stand wiedergeben. Fehler oder veraltete Angaben können daher vorkommen. Mit kritischer Prüfung und eigenem Nachdenken lassen sich diese Unschärfen jedoch in der Regel problemlos erkennen und korrigieren.





Speicherorte wichtiger Dateien und Ressourcen in openSUSE

Einleitung:

openSUSE – wie andere Linux-Distributionen auch – verwendet eine klar strukturierte Hierarchie für Konfigurations- und Ressourcendateien. Abhängig vom Kontext werden Dateien entweder systemweit (unter /usr/, /etc/, /usr/share/) oder benutzerspezifisch (unter ~/.config/, ~/.local/) gespeichert.


Home-Verzeichnis (~/)

Alles, was nur den eigenen Benutzer betrifft:

  • ~/Desktop/ – Dateien/Verknüpfungen auf dem Desktop
  • ~/Downloads/ – Heruntergeladene Dateien
  • ~/Documents/, ~/Pictures/, ~/Music/, ~/Videos/ – Eigene Daten
  • ~/.config/ – Programm- und Systemeinstellungen (neuere Programme)
  • ~/.local/share/ – Benutzer-Apps, Symbole, Themes
  • ~/.local/bin/ – Eigene Programme/Skripte
  • ~/.cache/ – Zwischenspeicher, kann gelöscht werden
  • ~/.bashrc – Einstellungen für die Shell (z. B. Aliase, PATH)
  • ~/.ssh/ – SSH-Keys und Einstellungen


Systemweite Konfiguration (/etc)

Wirkt für alle Benutzer, Änderungen brauchen Root-Rechte:

  • /etc/passwd, /etc/shadow, /etc/group – Benutzer- und Gruppenverwaltung
  • /etc/fstab – Welche Partitionen/Datenträger automatisch eingebunden werden
  • /etc/hostname, /etc/hosts – Rechnername, lokale Namensauflösung
  • /etc/resolv.conf – DNS-Server
  • /etc/systemd/ – Systemdienste (Start/Stop/Autostart)
  • /etc/zypp/ – Paketquellen für zypper / YaST
  • /etc/X11/ – Einstellungen für grafische Oberfläche (falls nötig)


Systemdaten (/usr, /var, /opt)

  • /usr/bin/ – Programme (Binaries)
  • /usr/share/ – Gemeinsame Daten: Symbole, Hintergründe, Themes, .desktop-Dateien
  • /usr/lib/ – Systembibliotheken
  • /var/log/ – Protokolle (Logs, Fehleranalyse)
  • /opt/ – Zusatzsoftware, oft proprietär


Nützlich für Anpassungen

  • Symbole/Icons:
    • systemweit: /usr/share/icons/
    • benutzerspezifisch: ~/.local/share/icons/
  • Desktop-Dateien:
    • systemweit: /usr/share/applications/
    • benutzerspezifisch: ~/.local/share/applications/
  • Themes:
    • systemweit: /usr/share/themes/
    • benutzerspezifisch: ~/.local/share/themes/
  • Hintergründe:
    • KDE: /usr/share/wallpapers/
    • GNOME: /usr/share/backgrounds/


Kurzregel für Neulinge

  • Alles Persönliche → liegt in ~/
  • Alles fürs ganze System → liegt in /etc/, /usr/, /var/
  • Nichts in /bin, /sbin, /lib anfassen – außer man weiß genau, was man tut




1. Desktop-Dateien (.desktop)

Dateien, die Programme im Menü oder auf dem Desktop sichtbar machen.

  • Systemweit:
    • /usr/share/applications/ → Standard-Speicherort für Desktop-Dateien installierter Programme.
  • Benutzerspezifisch:
    • ~/.local/share/applications/ → Hier können eigene oder überschreibende .desktop-Dateien abgelegt werden.


2. Symbole und Icons

Grafische Symbole für Programme, Dateitypen, Systemindikatoren.

  • Systemweit:
    • /usr/share/icons/ → Enthält Icon-Themes (z. B. Breeze, Adwaita).
  • Benutzerspezifisch:
    • ~/.icons/ (älter, traditionell)
    • ~/.local/share/icons/ (aktueller Standard nach XDG-Spezifikation)


3. Hintergrundbilder (Wallpapers)

Hintergrundbilder für Desktop-Umgebungen wie KDE Plasma oder GNOME.

  • Systemweit:
    • KDE Plasma: /usr/share/wallpapers/
    • GNOME: /usr/share/backgrounds/
  • Benutzerspezifisch:
    • ~/.local/share/wallpapers/ (falls selbst angelegt)
    • Beliebige Orte im Home-Verzeichnis, wenn direkt über die Desktop-Umgebung ausgewählt.


4. Konfigurationsdateien

  • Systemweit:
    • /etc/ → Zentrale Konfigurationsdateien für Systemdienste und Programme.
  • Benutzerspezifisch:
    • ~/.config/ → Hauptort für Programmkonfigurationen (XDG-Standard).
    • ~/.<programmname> → Viele ältere Programme speichern direkt im Home-Verzeichnis versteckte Ordner/Dateien.


5. Themes und Oberflächenanpassungen

  • Systemweit:
    • /usr/share/themes/ → GTK-Themes.
    • /usr/share/plasma/desktoptheme/ → KDE Plasma Themes.
  • Benutzerspezifisch:
    • ~/.themes/ oder ~/.local/share/themes/.


6. Fonts (Schriften)

  • Systemweit:
    • /usr/share/fonts/
  • Benutzerspezifisch:
    • ~/.fonts/ (älter, wird noch unterstützt)
    • ~/.local/share/fonts/ (aktueller XDG-Pfad).


Übersichtstabelle

Ressourcentyp Systemweit Benutzerspezifisch
Desktop-Dateien /usr/share/applications/ ~/.local/share/applications/
Symbole/Icons /usr/share/icons/ ~/.local/share/icons/, ~/.icons/
Hintergrundbilder /usr/share/wallpapers/, /usr/share/backgrounds/ ~/.local/share/wallpapers/
Konfiguration /etc/ ~/.config/, ~/.<programmname>
Themes /usr/share/themes/, /usr/share/plasma/desktoptheme/ ~/.local/share/themes/, ~/.themes/
Fonts /usr/share/fonts/ ~/.local/share/fonts/, ~/.fonts/


Unsicherheiten

  • Manche Programme oder Desktop-Umgebungen verwenden abweichende Verzeichnisse.
  • Übergang von älteren Standards (~/.icons/, ~/.fonts/) zu XDG-Pfaden ist noch nicht vollständig abgeschlossen.
  • openSUSE-spezifische Abweichungen sind gering; die Struktur folgt weitgehend der allgemeinen Linux/XDG-Konvention.


Fazit

Die wichtigsten Speicherorte in openSUSE orientieren sich am XDG Base Directory Standard. Systemweite Dateien liegen unter /usr/share/ oder /etc/, benutzerspezifische Varianten im Home-Verzeichnis unter ~/.local/share/ oder ~/.config/. Damit lassen sich Anpassungen und Erweiterungen konsistent vornehmen, ohne in Konflikt mit Paketupdates zu geraten.





XDG

Frage

Was ist „XDG“ im weiteren Kontext des UNIX- und Unix-ähnlichen (Unixoid-)Ökosystems, und wie lässt sich das für Einsteiger verständlich erklären?


Kontext

Das UNIX-Ökosystem umfasst eine Vielzahl von Betriebssystemen, die auf der ursprünglichen UNIX-Architektur basieren oder von ihr inspiriert sind: klassische UNIX-Derivate (BSDs, Solaris, AIX), moderne GNU/Linux-Distributionen sowie macOS. Ein gemeinsames Kennzeichen dieser Systeme ist die Orientierung an klaren Konventionen für Verzeichnisse, Prozesse und Benutzerumgebungen.

Historisch war die Handhabung von Konfigurations- und Benutzerdaten uneinheitlich: Programme legten Dateien direkt im Home-Verzeichnis (~/) ab, oft als sogenannte „Dotfiles“ (~/.bashrc, ~/.vimrc). Dies führte mit wachsender Zahl an Programmen zu Unübersichtlichkeit.

Um Ordnung zu schaffen, hat die Community freedesktop.org – ein Projekt zur Vereinheitlichung von Standards im Desktop-Linux-Bereich – die XDG-Spezifikationen entwickelt.


Erläuterung für Einsteiger

  1. Grundidee von UNIX-Dateisystemen
    • Alles ist eine Datei: Konfiguration, Programme, Geräte.
    • Verzeichnisse strukturieren diese Dateien.
    • Beispiel:
      • /etc/ → systemweite Konfiguration
      • /usr/ → Programme
      • /home/<user>/ → persönliche Daten und Einstellungen
  2. Problem vor XDG
    • Jeder Entwickler entschied selbst, wo Programme ihre Dateien ablegen.
    • Ergebnis: hunderte versteckte Dateien (.config, .mozilla, .viminfo) im Home-Verzeichnis.
    • Für Anfänger wirkt das chaotisch und schwer nachvollziehbar.
  3. Lösung durch XDG
    • Die XDG Base Directory Specification legt fest, dass Programme bestimmte Umgebungsvariablen beachten:
      • $XDG_CONFIG_HOME (Standard: ~/.config/) für Einstellungen
      • $XDG_DATA_HOME (Standard: ~/.local/share/) für Programmdaten
      • $XDG_CACHE_HOME (Standard: ~/.cache/) für temporäre Daten
    • Die XDG User Directories Specification definiert standardisierte Benutzerordner: Documents, Downloads, Pictures, usw.
    • Dadurch können Programme benutzerfreundlicher und konsistenter arbeiten.
  4. Bezug zu Flatpak und moderner Software
    • Flatpak nutzt die XDG-Spezifikationen, um Zugriffe auf Benutzerverzeichnisse klar und sicher zu regeln.
    • Beispiel: statt fest ~/Downloads anzusprechen, verweist eine App auf xdg-download – unabhängig davon, ob der Ordner beim Nutzer Downloads, Descargas oder Herunterladen heißt.
    • Für Einsteiger: Das System kümmert sich um Lokalisierung und Pfade, man muss nur das Schlüsselwort kennen.


Unsicherheiten und Grenzen

  • Nicht alle UNIXoide Systeme implementieren XDG vollständig.
    • macOS nutzt eigene Standards (Library-Ordner), manche Linux-Programme ignorieren XDG noch immer.
  • Auf Server-Systemen (z. B. BSD ohne Desktop) sind die User-Dirs oft irrelevant.


Fazit

Im gesamten Unixoid-Ökosystem steht XDG für den Versuch, Ordnung in die Dateistruktur des Benutzerbereichs zu bringen. Während UNIX traditionell viele verstreute Konfigurationsdateien kennt, bietet XDG ein einheitliches Schema: Konfiguration, Daten, Cache und Benutzerordner sind klar voneinander getrennt. Das erleichtert sowohl Einsteigern die Orientierung als auch Entwicklern die Portabilität ihrer Programme.


Vergleichstabelle: Klassische UNIX-Verzeichnisse vs. XDG-Standardpfade

Bereich Klassische UNIX/Unixoid-Verzeichnisse XDG-Spezifikation (typischer Standardwert) Nutzen für Einsteiger
Systemweite Konfiguration /etc/ (XDG nicht zuständig – bleibt bei /etc/) Einheitlicher Ort für alle Benutzer, Admin-Pflege
Benutzer-Konfiguration ~/.bashrc, ~/.vimrc, ~/.appconfig $XDG_CONFIG_HOME → ~/.config/ Übersichtlicher: alle Programme in einem Verzeichnis
Benutzerdaten (Programme) ~/ mit versteckten Ordnern wie ~/.mozilla $XDG_DATA_HOME → ~/.local/share/ Vermeidet Datenmüll im Home-Verzeichnis
Benutzer-Cache unterschiedlich: ~/.cache, ~/tmp $XDG_CACHE_HOME → ~/.cache/ Klare Trennung von temporären Dateien
Systemweite Daten /usr/share/, /usr/local/share/ $XDG_DATA_DIRS (z. B. /usr/local/share:/usr/share) Einheitliche Pfadsuche für Anwendungen
Systemweite Konfig /etc/ $XDG_CONFIG_DIRS (z. B. /etc/xdg) Zentrale Orte für Vorgaben an alle User
Dokumente ~/Documents (nicht standardisiert) xdg-documents → ~/Documents Sprach- und systemunabhängig zugreifbar
Downloads ~/Downloads (lokale Konvention) xdg-download → ~/Downloads Einheitlich, auch bei lokalisierter Namensgebung
Bilder ~/Pictures xdg-pictures → ~/Pictures Einheitliche Schnittstelle für Bildprogramme
Videos ~/Videos xdg-videos → ~/Videos Konsistenz für Mediaplayer
Musik ~/Music xdg-music → ~/Music Einheitlich für Audioplayer
Desktop ~/Desktop xdg-desktop → ~/Desktop Einheitliche Erreichbarkeit für GUI-Programme


Erläuterung für Einsteiger

  • UNIX-Systeme hatten historisch feste Konventionen, aber keine zentrale Norm für Benutzerordner.
  • XDG standardisiert, wo Programme Daten und Einstellungen ablegen sollen.
  • Vorteil: Aufgeräumtes Home-Verzeichnis, konsistente Benutzererfahrung, weniger Chaos durch verstreute Dotfiles.
  • Für Anwendungen wie Flatpak sind die XDG-Bezeichner (xdg-documents, xdg-download usw.) praktisch, da sie Sprach- und Systemunterschiede abstrahieren.


Frage

Was bedeutet „XDG“ im Kontext von Flatpak und Dateisystem-Berechtigungen?

Kontext

„XDG“ ist eine Abkürzung für die freedesktop.org XDG Base Directory Specification. Sie definiert standardisierte Umgebungsvariablen und Pfade für Benutzerverzeichnisse und Konfigurationsdateien unter Linux. Ziel ist, dass Anwendungen plattformübergreifend einheitliche Orte für Dokumente, Konfiguration und Cache verwenden, statt willkürlich in $HOME zu schreiben.


Argumente

  1. XDG Base Directory Specification
    • Definiert Verzeichnisse wie:
      • $XDG_CONFIG_HOME (typisch: ~/.config)
      • $XDG_DATA_HOME (typisch: ~/.local/share)
      • $XDG_CACHE_HOME (typisch: ~/.cache)
    • Anwendungen sollen Konfiguration, Daten und Caches dort ablegen.
  2. XDG User Directories
    • Erweiterung, die Standardordner für Benutzerdateien festlegt:
      • xdg-desktop → ~/Desktop
      • xdg-documents → ~/Documents
      • xdg-download → ~/Downloads
      • xdg-music → ~/Music
      • xdg-pictures → ~/Pictures
      • xdg-videos → ~/Videos
    • Diese sind über die Datei ~/.config/user-dirs.dirs und Befehle wie xdg-user-dirs-update verwaltbar.
  3. Flatpak-Bezug
    • Flatpak verwendet die XDG-Verzeichnisse als Schlüsselwörter in den Berechtigungen (--filesystem=xdg-…).
    • Vorteil: Portabilität. Egal, wo die Verzeichnisse tatsächlich liegen, Flatpak weiß durch die XDG-Spezifikation, wohin sie zeigen.


Unsicherheiten

  • Unterschiedliche Distributionen können abweichende Standardpfade setzen (z. B. lokalisierte Namen wie ~/Bilder statt ~/Pictures).
  • Manche ältere Software ignoriert die XDG-Spezifikation noch immer.


Fazit

XDG ist ein freedesktop.org-Standard für einheitliche Verzeichnisse und Konfigurationspfade unter Linux. In Flatpak dienen die Kürzel wie xdg-documents oder xdg-download als abstrakte Platzhalter für die tatsächlich beim Benutzer vorhandenen Ordner. Dadurch bleiben Anwendungen unabhängig von Sprache, Distribution und individueller Verzeichnisstruktur konsistent.





Flatpak

Frage

Wie funktionieren Dateisystem-Berechtigungen bei Flatpak, und wie können sie kontrolliert bzw. verändert werden?


Kontext

Flatpak isoliert Anwendungen standardmäßig in einer Sandbox. Der Zugriff auf das Host-Dateisystem ist stark eingeschränkt, um Sicherheit und Reproduzierbarkeit zu erhöhen. Anwendungen sehen nur ihr internes Verzeichnis (~/.var/app/<APP-ID>/). Zugriff auf weitere Teile des Dateisystems ist nur möglich, wenn Berechtigungen gesetzt werden – entweder durch den Entwickler im Manifest oder nachträglich durch den Benutzer.


Argumente

  1. Standard-Zugriffsmodell
    • Jede Flatpak-App hat ihr eigenes Datenverzeichnis: ~/.var/app/<APP-ID>/.
    • Zugriff auf das restliche Home-Verzeichnis ist nicht automatisch erlaubt.
    • Einige Verzeichnisse können per Portalschnittstelle oder Berechtigungen zugänglich gemacht werden (z. B. xdg-documents, xdg-download).
  2. Explizite Berechtigungen
    • Flatpak kennt die Option --filesystem=<PATH/Bezeichner>.
    • Typische Werte:
      • home → gesamtes Home-Verzeichnis
      • xdg-download → Download-Ordner
      • /some/path → beliebiger Pfad
      • host → komplettes Host-Dateisystem
    • Schreibrechte können eingeschränkt werden: :ro nur lesend.
  3. Kontrolle und Änderung durch den Nutzer
    • Über CLI:
      • Anzeigen: flatpak info --show-permissions <APP-ID>
      • Ändern: flatpak override --filesystem=<PFAD> <APP-ID>
      • Beispiel: flatpak override --filesystem=xdg-documents:ro org.mozilla.firefox
    • Über GUI-Tools wie Flatseal: visuelle Oberfläche zum Setzen von Berechtigungen.
  4. Sicherheitsimplikationen
    • Je weiter der Zugriff, desto schwächer die Sandbox.
    • Zugriff auf / oder host sollte vermieden werden.
    • Granulare Freigaben (z. B. nur xdg-pictures) sind vorzuziehen.


Unsicherheiten

  • Unterschiedliche Flatpak-Versionen oder Distributionen können Details leicht variieren.
  • Manche Apps implementieren zusätzliche Portalschnittstellen, die Zugriff regeln, auch wenn keine explizite Berechtigung gesetzt wurde.


Fazit

Flatpak trennt Anwendungen grundsätzlich vom Host-Dateisystem. Zugriff ist nur über definierte Berechtigungen (--filesystem) möglich und kann sowohl vom Entwickler als auch vom Nutzer gesetzt werden. Zur Kontrolle eignen sich die Befehle flatpak info und flatpak override oder Tools wie Flatseal. Minimaler, granularer Zugriff ist sicherheitsbest practice.


Übersicht der wichtigsten --filesystem-Optionen in Flatpak

Option Bedeutung Bemerkungen / Risiken
home gesamtes Home-Verzeichnis sehr weitgehend, meist unnötig
host gesamtes Host-Dateisystem bricht Sandbox-Isolation fast vollständig
/pfad/zum/verzeichnis bestimmter Pfad selektive Freigabe, sicherer als home
xdg-download Download-Ordner oft nötig für Browser
xdg-documents Dokumente-Ordner eingeschränkter, aber gezielter Zugriff
xdg-pictures Bilder-Ordner für Bildbearbeitung sinnvoll
xdg-videos Video-Ordner für Media-Player sinnvoll
xdg-music Musik-Ordner für Audio-Player sinnvoll
xdg-desktop Desktop-Ordner Achtung: enthält oft viele Dateien
xdg-config/<App> spezifische Konfigurationsverzeichnisse z. B. für Zugriff auf bestehende Einstellungen
xdg-cache/<App> Cache-Verzeichnisse meist unkritisch
xdg-run/<Socket> Laufzeit-Sockets oder Dienste fortgeschrittene Nutzung
:ro nur Lesezugriff Sicherheitsgewinn, wenn Schreibrechte unnötig
:create legt Verzeichnis an, falls nicht vorhanden praktisch für persistente Speicherpfade

Flatpak Dateisystem-Berechtigungen – Cheatsheet


1. Berechtigungen anzeigen

flatpak info --show-permissions <APP-ID>

Beispiel:

flatpak info --show-permissions org.mozilla.firefox


2. Berechtigungen setzen / erweitern

flatpak override --filesystem=<OPTION> <APP-ID>

Beispiele:

  • Lesezugriff auf Dokumente:

flatpak override --filesystem=xdg-documents:ro org.mozilla.firefox

Zugriff auf eigenes /mnt/data:

flatpak override --filesystem=/mnt/data org.videolan.VLC

Mehrere gleichzeitig:

flatpak override --filesystem=xdg-download --filesystem=xdg-videos org.mozilla.firefox


3. Berechtigungen zurücksetzen

flatpak override --reset <APP-ID>


4. Übersicht wichtiger Optionen

Option Zugriff auf
home gesamtes Home-Verzeichnis
host gesamtes Host-Dateisystem
/pfad beliebiges Verzeichnis
xdg-download Download-Ordner
xdg-documents Dokumente-Ordner
xdg-pictures Bilder-Ordner
xdg-videos Video-Ordner
xdg-music Musik-Ordner
:ro nur lesend
:create Verzeichnis anlegen falls fehlt


5. GUI-Alternative

  • Flatseal: grafisches Tool zum Setzen von Berechtigungen. Installation:

flatpak install flathub com.github.tchx84.Flatseal






Desktop-Dateien

Einführung

In openSUSE (wie auch in anderen Linux-Distributionen) werden Desktop-Dateien (.desktop) verwendet, um Anwendungen im Menüsystem, im Launcher oder auf dem Desktop darzustellen. Sie sind einfache Textdateien, die dem XDG Desktop Entry Specification-Standard folgen und Meta-Informationen über ein Programm enthalten: Name, Icon, Befehl, Kategorien.

Eine .desktop-Datei kann sowohl systemweit (/usr/share/applications/) als auch benutzerspezifisch (~/.local/share/applications/) abgelegt werden.


Aufbau einer .desktop-Datei

Die Datei besteht aus einer Kopfzeile und Schlüssel-Wert-Paaren. 

[Desktop Entry]
Version=1.0
Type=Application
Name=Mein Programm
Comment=Kurze Beschreibung
Exec=/usr/bin/meinprogramm %U
Icon=meinicon
Terminal=false
Categories=Utility;Application;


Erklärung der Felder

Schlüssel Bedeutung
[Desktop Entry] Obligatorische Kopfzeile, markiert Beginn.
Version= Spezifikations-Version (optional, meist 1.0).
Type= Typ des Eintrags (häufig Application, alternativ Link oder Directory).
Name= Anzeigename im Menü.
Comment= Beschreibung, Tooltip-Text.
Exec= Auszuführender Befehl. Platzhalter möglich (%f, %u, %U).
Icon= Name oder Pfad zum Symbol.
Terminal= true oder false → ob das Programm in einem Terminal gestartet wird.
Categories= Komma- oder Semikolon-getrennte Kategorien (z. B. Utility;System;).
MimeType= (optional) Zuordnung zu Dateitypen.
StartupNotify= true/false → ob Startbenachrichtigung angezeigt wird.



Wichtige Platzhalter in Exec=

Platzhalter Bedeutung
%f einzelne Datei
%F mehrere Dateien
%u einzelne URL
%U mehrere URLs
%i Icon
%c Name
%k Pfad zur .desktop-Datei


Minimalbeispiel

[Desktop Entry]
Type=Application
Name=Firefox
Exec=firefox %u
Icon=firefox
Terminal=false
Categories=Network;WebBrowser;

Fazit

Eine .desktop-Datei ist ein Start- und Metadateneintrag für Programme. Sie verbindet den Ausführungsbefehl mit Name, Icon und Kategorien, sodass Desktop-Umgebungen Programme konsistent darstellen können.


Vorlage für eine .desktop-Datei

[Desktop Entry]
Version=1.0
Type=Application
Name=MeinProgramm
Comment=Kurze Beschreibung des Programms
Exec=/pfad/zum/programm %U
Icon=meinicon
Terminal=false
Categories=Utility;
StartupNotify=true

Anpassen musst du:

  • Name= → Der Name, der im Menü/Launcher angezeigt wird
  • Comment= → Kurzbeschreibung (erscheint oft als Tooltip)
  • Exec= → Befehl oder absoluter Pfad zum Programm
  • Icon= → Name eines Icons (wenn im Icon-Theme vorhanden) oder absoluter Pfad zu einer Bilddatei
  • Categories= → Kategorie(n), z. B. Utility;Network;AudioVideo;System;


Speicherort

  • nur für dich: ~/.local/share/applications/meinprogramm.desktop
  • systemweit: /usr/share/applications/meinprogramm.desktop

Damit die Datei im Menü angezeigt wird, muss sie ausführbar sein:


chmod +x ~/.local/share/applications/meinprogramm.desktop

(oder einfach Rechte-Maustaste auf die Datei > Eigenschaften > Ausführbar...)





Mehrere Desktop-Umgebungen nebeneinander installieren

Einleitung

GNOME, KDE Plasma und Xfce sind die drei großen Platzhirsche unter den Linux-Desktopumgebungen.

  • GNOME verfolgt ein modernes, reduziertes Bedienkonzept.
  • KDE Plasma ist hochgradig anpassbar und bringt viele Werkzeuge von Haus aus mit.
  • Xfce setzt auf klassische Desktop-Metaphern mit geringem Ressourcenverbrauch.

Viele andere Desktopumgebungen existieren, oft als Forks oder Weiterentwicklungen des alten GNOME 2, nachdem GNOME mit Version 3 einen radikalen Neuanfang wagte. Projekte wie MATE oder Cinnamon entstanden genau aus diesem Bruch heraus. Manche Umgebungen richten sich auch an bestimmte Distributionen (z. B. Budgie bei Solus, Pantheon bei elementaryOS).

Bei openSUSE wird in vielen Dokumentationen GNOME vor KDE genannt – nicht aus inhaltlichen Gründen, sondern schlicht wegen der alphabetischen Reihenfolge. Historisch allerdings war openSUSE (bzw. früher SUSE Linux) traditionell stark KDE-fokussiert, da SUSE schon in den 1990er Jahren eng mit KDE-Entwicklern verbunden war. Heute sind beide gleichberechtigte First-Class-Desktops in Tumbleweed und Leap.

Persönliche Vorlieben spielen die entscheidende Rolle:

  • Wer lieber GNOME nutzt, kann sich KDE-Komponenten so konfigurieren, dass sie „wie GNOME“ wirken.
  • Umgekehrt kann man GNOME auch um Funktionen erweitern, die KDE standardmäßig mitbringt.

Ein zentraler technischer Unterschied ist die Passwort- und Schlüsselverwaltung:

  • Fast alle Desktopumgebungen nutzen im Hintergrund den GNOME-Keyring über das Secret Service API.
  • Nur KDE Plasma setzt standardmäßig auf ein eigenes System, den KWallet.
  • Dadurch ist es einfacher, zusätzliche Desktopumgebungen an ein GNOME-basiertes System „anzudocken“, als ausgehend von KDE Plasma alles auf GNOME-Keyring umzustellen.

Eine Besonderheit bei openSUSE:

  • Es wird immer auch ein Minimal-Desktop wie IceWM mitinstalliert.
  • Das dient als Rettungsumgebung, falls eine große Desktopumgebung beschädigt wird. Man hat so immer ein minimales grafisches System, um etwa einen Browser zu starten und Reparaturanleitungen nachzuschlagen.


Warum nur ein Pattern installieren?

Wir installieren nur das GNOME-Pattern (und keine weiteren Desktop-Patterns), aus mehreren Gründen:

  1. Vollständigkeit:
    • Das GNOME-Pattern stellt sicher, dass alle notwendigen Komponenten, Hintergrunddienste und Integrationen vorhanden sind.
    • Man muss nicht manuell jedes Paket suchen, das GNOME ausmacht.
  2. Klarheit:
    • Würde man zusätzlich das KDE-Pattern, Xfce-Pattern oder andere aktivieren, ziehen diese jeweils hunderte weiterer Pakete nach, die oft in Konkurrenz stehen (z. B. mehrere Display-Manager, mehrere Secret-Service-Daemons, doppelte Konfigurationswerkzeuge).
    • Das erhöht das Risiko von Konflikten bei zypper dup und beim täglichen Betrieb.
  3. Erweiterbarkeit:
    • Von einer sauberen GNOME-Basis aus kann man zusätzliche Desktop-Sessions (Plasma, Xfce, MATE, Cinnamon, LXQt, Sway, Hyprland) minimal hinzufügen.
    • Diese bestehen nur aus den Session-Paketen und bringen keine eigenen kompletten Frameworks zur Passwortverwaltung oder eigene Systemdienste mit.
  4. Stabilität beim Upgrade:
    • Tumbleweed ist ein Rolling Release. Upgrades sind am stabilsten, wenn nur ein vollständiges Pattern gepflegt wird.
    • Weitere DEs ohne Pattern bedeuten: du hast sie zwar wählbar im GDM, sie beeinflussen aber nicht die Paketabhängigkeiten des Basissystems.
  5. Fallback-Sicherheit:
    • Sollte GNOME durch eine fehlerhafte Installation oder ein Update beschädigt werden, stehen immer noch IceWM oder eine der anderen leichtgewichtigen DEs zur Verfügung, so ist immer ein minimaler grafischer Desktop vorhanden, um z. B. einen Browser zu starten und Reparaturanleitungen nachzuschlagen.


Fazit

GNOME dient als vollständige, getestete Hauptumgebung.

Weitere Desktopumgebungen werden minimal ergänzt, damit man sich in ihnen einloggen und Programme testen kann, ohne dass sie das System durch ihre eigenen Patterns aufblähen oder destabilisieren.

So bleibt das System stabil, upgrade-sicher und flexibel – mit GNOME-Keyring als einheitlicher Basis für die Passwortverwaltung und IceWM als garantierte Rettungsebene.



openSUSE mit GNOME-Pattern installiert

Alles klar – du hast also GNOME bereits vollständig installiert (über Pattern) und kannst nach dem Boot ins GNOME YaST → Softwareverwaltung öffnen.

Jetzt willst du die anderen Desktop-Umgebungen (Sway, Hyprland, Plasma, Xfce, MATE, Cinnamon, LXQt) minimal, ohne Patterns hinzufügen.

Hier die vollständige Liste, sortiert nach DE.

Einfach die Namen in YaST suchen und anhaken – keine Patterns verwenden.


Sway (wie „openSUSEway“, aber ohne Pattern)

  • sway – Window-Manager (Wayland-basiert)
  • swaylock – Bildschirmsperre
  • swayidle – Idle-Handler
  • waybar – Panel & Systemanzeige
  • wofi – Anwendungsstarter (rofi-ähnlich für Wayland)
  • alacritty – Terminal
  • grim – Screenshots
  • slurp – Auswahlwerkzeug für Screenshots
  • mako – Benachrichtigungsdaemon
  • xdg-desktop-portal-wlr – Portal-Integration für wlroots
  • xdg-desktop-portal – generische Portal-Schnittstelle


Hyprland

  • hyprland – Window-Manager (Wayland, dynamisch/tiling)
  • hyprpaper – Hintergrundbilder
  • hyprlock – Bildschirmsperre
  • waybar – Panel & Systemanzeige
  • wofi – Anwendungsstarter
  • alacritty – Terminal
  • mako – Benachrichtigungen
  • grim – Screenshots
  • slurp – Auswahlwerkzeug für Screenshots
  • xdg-desktop-portal-hyprland – Portal-Integration für Hyprland
  • xdg-desktop-portal – generische Portal-Schnittstelle


KDE Plasma (minimal Session, ohne kwallet)

  • plasma5-session – Sitzungsverwaltung
  • plasma-workspace – Basis-Arbeitsfläche
  • ksmserver – Session-Manager
  • kde-cli-tools – essentielle Tools

(Optional: dolphin als Dateimanager. kwalletmanager nicht installieren, wenn nur gnome-keyring genutzt werden soll.)


Xfce (minimal)

  • xfce4-session – Sitzungsverwaltung (startet und beendet XFCE)
  • xfce4-settings – zentrale Settings + xfsettingsd
  • xfwm4 – Fenstermanager (sonst kein Fensterrahmen/Steuerung)
  • xfce4-panel – Panel + Startmenü
  • xfdesktop – Hintergrund/Icons
  • xfconf – Konfigurations-Backend
  • garcon – Menü-Backend (braucht das Panel)

(Optional: thunar als Dateimanager und xfce4-terminal als Terminal.)


MATE (minimal)

  • mate-session – Sitzungsverwaltung
  • mate-control-center – zentrale Systemeinstellungen
  • mate-settings-daemon – Hintergrunddienste (z. B. Tastatur, Sound)
  • caja – Dateimanager


Cinnamon (minimal)

  • cinnamon-session – Sitzungsverwaltung
  • cinnamon-control-center – zentrale Systemeinstellungen
  • muffin – Fenstermanager (sonst keine Fensterrahmen)


LXQt (minimal)

  • lxqt-session – Sitzungsverwaltung
  • lxqt-panel – Panel & Startmenü


Hilfspakete für Wayland / Multimedia / Hardware

Diese sind sinnvoll für Sway + Hyprland + alle anderen DEs:

  • pipewire – moderner Audio/Video-Dienst
  • pipewire-pulse – PulseAudio-Kompatibilität
  • wireplumber – Session-Manager für PipeWire
  • alsa-utils – Grundpakete für ALSA
  • pulseaudio-utils – Tools für Audioverwaltung
  • udisks2 – Laufwerksverwaltung
  • polkit – Berechtigungsverwaltung
  • cups – Druckdienste
  • avahi – Netzwerkdienste (mDNS/Bonjour)



Vorgehen in YaST

  1. YaST → Softwareverwaltung → Suche.
  2. Jeden Block nacheinander ins Suchfeld kopieren (z. B. „sway“, dann alle markieren, dann übernehmen).
  3. Bei Abhängigkeitsdialogen nur erforderliche Abhängigkeiten akzeptieren, Empfehlungen kannst du abwählen, wenn du minimal bleiben willst.
  4. Nach Abschluss rebooten.
  5. Im GDM (das bleibt dein Standard-Login-Manager) → Zahnradsymbol → Session auswählen: GNOME, Sway, Hyprland, Plasma, Xfce, MATE, Cinnamon, LXQt.


Ergebnis

  • GNOME bleibt vollständig.
  • Alle genannten DEs starten minimal, genug um dich ein- und abmelden zu können.
  • Du kannst jede DE später gezielt ausbauen (Dateimanager, Terminal, Tools) – ohne Patterns, nur durch Paketnachinstallationen.





Display Manager


Display-Server und Display-Manager – Grundlagen

Display-Server

Der Display-Server ist die Software, die die grafische Ausgabe steuert und Eingaben von Tastatur, Maus oder Touchscreen verarbeitet.

  • Klassisch: X.Org (X11), seit Jahrzehnten Standard unter Linux.
  • Modern: Wayland, schlanker, sicherer, Nachfolger von X11.
  • Beide werden weiterhin parallel genutzt, je nach Desktopumgebung und Anwendungskompatibilität.

Der Display-Server bildet also die Basis, auf der eine Desktopumgebung überhaupt erst laufen kann.

Display-Manager (Login-Manager)

Der Display-Manager (DM) ist das grafische Login-Programm, das nach dem Booten erscheint. Er übernimmt:

  • Starten des Display-Servers (X11 oder Wayland)
  • Anzeige des Anmeldebildschirms (Benutzerauswahl, Passwort)
  • Starten der gewählten Desktopumgebung (GNOME, KDE, Xfce usw.)

Bekannte Display-Manager sind:

  • GDM (GNOME Display Manager)
  • SDDM (Simple Desktop Display Manager, Standard bei KDE)
  • LightDM (leichtgewichtig, oft bei Xfce oder LXQt)
  • greetd (modern, minimal, oft bei Wayland-basierten Setups wie Sway oder Hyprland)

Man kann immer nur einen Display-Manager gleichzeitig aktiv haben, da dieser den Startprozess der grafischen Sitzung steuert.


Verbindung zum GNOME-Keyring

Der GNOME-Keyring ist ein Secret-Service-Daemon, der Passwörter und Schlüssel verwaltet (z. B. WLAN-Passwörter, SSH-Keys, Anwendungs-Passwörter).

Damit er korrekt funktioniert, braucht er eine Integration mit dem Login-Prozess:

  1. Über den Display-Manager:
    • Wenn du dich mit GDM einloggst, wird dein Benutzerpasswort automatisch verwendet, um den GNOME-Keyring zu entsperren.
    • Das passiert transparent, d. h. du musst dein Passwort nicht noch einmal eingeben.
  2. Andere Display-Manager:
    • SDDM oder LightDM entsperren den GNOME-Keyring nicht von Haus aus. Dann erscheint nach dem Login eine zusätzliche Passwortabfrage, um den Schlüsselbund zu öffnen.
    • Das wirkt störend, ist aber funktional kein Problem.
  3. KDE Plasma und KWallet:
    • Plasma nutzt standardmäßig KWallet als eigenes System.
    • Anwendungen, die libsecret/gnome-keyring erwarten, können dadurch zusätzliche Anpassungen erfordern.
    • Deshalb ist ein GNOME-basiertes System (mit GDM und gnome-keyring) die einfachste gemeinsame Basis, um viele Desktopumgebungen parallel zu nutzen.


Weitere wichtige Punkte

  • Secret Service API
    • Einheitliche Schnittstelle, über die Anwendungen Passwörter ablegen und abrufen können.
    • GNOME-Keyring implementiert diese API, KWallet teilweise.
    • Fast alle modernen Anwendungen nutzen diese Schnittstelle.
  • XWayland
    • Brücke, die es X11-Anwendungen erlaubt, in einer Wayland-Sitzung zu laufen.
    • Praktisch unverzichtbar, da viele Programme noch nicht native Wayland-Clients sind.
  • Sitzungs-Manager (Session Manager)
    • Verantwortlich für das Starten und Beenden aller Prozesse einer Desktopumgebung.
    • Beispiele: gnome-session, plasma5-session, xfce4-session.
    • Diese Session-Manager werden jeweils vom Display-Manager gestartet.
  • Fallback-Sitzungen
    • Selbst wenn keine große Desktopumgebung funktioniert, bleibt z. B. IceWM als einfache X11-Sitzung verfügbar.
    • Das ist ein wichtiger Rettungsanker bei Systemproblemen.


Fazit

  • Display-Server = Fundament (X11 oder Wayland).
  • Display-Manager = Login- und Sitzungsstarter (GDM, SDDM, LightDM …).
  • Session-Manager = Startet die eigentliche Desktopumgebung.
  • GNOME-Keyring hängt direkt am Login-Prozess des Display-Managers → nur mit GDM ist die Integration reibungslos.

Darum ist es sinnvoll, GNOME samt GDM als Basis zu nehmen, andere Desktopumgebungen minimal hinzuzufügen, und den GNOME-Keyring als einheitliches Secret-Service-System für alle Sessions zu nutzen.





Multimedia

Das openSUSE Projekt unterstützt nur freie und quell offene Software in ihrer Distribution. Das gilt für Anwendungen aller Art, so auch für Multimediaanwendungen. Ausgenommen sind hier Verkaufsversionen die zusätzliche Pakete enthalten die von Drittanbietern Lizenziert ist und somit Urheberrechten unterliegen.

Hierunter fallen auch Multimedia Codecs & Bibliotheken, von denen manche frei und andere unter Eingeschränkten Lizenzbedingungen verwendet werden dürfen.


Quelle: https://de.opensuse.org/Portal:Multimedia


Multimediafähigkeiten erweitern

📖 https://de.opensuse.org/SDB:Multimediaf%C3%A4higkeiten_erweitern

📖 https://en.opensuse.org/SDB:Installing_codecs_from_Packman_repositories

Abgerufen von „https://schwarzatal.org/index.php?title=OpenSUSE&oldid=12765“