OpenSUSE

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

Wir nehmen also GNOME als einziges vollständiges Pattern:

• Damit ist das Basissystem vollständig und upgrade-sicher.
• Zusätzliche Desktop-Umgebungen werden nur als minimale Sessions installiert, ohne dass sie ihre eigenen vollen Ökosysteme und Konflikte mitbringen.
• GNOME-Keyring bleibt der gemeinsame Unterbau für Passwort- und Schlüsselverwaltung.
• openSUSE liefert mit IceWM automatisch eine zusätzliche Rettungsebene.

So hast du ein stabiles Grundsystem und zugleich die Freiheit, andere Desktopumgebungen auszuprobieren, ohne dir das System unnötig aufzublähen oder Abhängigkeitskonflikte zu riskieren.

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

swaylock

swayidle

waybar

wofi

alacritty

grim

slurp

mako

xdg-desktop-portal-wlr

xdg-desktop-portal

Hyprland

hyprland

hyprpaper

hyprlock

waybar

wofi

alacritty

mako

grim

slurp

xdg-desktop-portal-hyprland

xdg-desktop-portal

KDE Plasma (minimal Session, ohne kwallet)

plasma5-session

plasma-workspace

ksmserver

kde-cli-tools

(Optional: dolphin als Dateimanager, falls du im Plasma-Login sofort Dateien managen willst. kwalletmanager NICHT installieren, wenn du nur gnome-keyring nutzen willst.)

Xfce (minimal)

mate-session-manager

mate-settings-daemon

caja

(Optional: thunar und xfce4-terminal für Dateimanager & Terminal.)

MATE (minimal)

mate-session-manager

mate-settings-daemon

caja

Cinnamon (minimal)

cinnamon-session

cinnamon-control-center

LXQt (minimal)

lxqt-session

lxqt-panel

Hilfspakete für Wayland / Multimedia / Hardware

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

pipewire

pipewire-pulse

wireplumber

alsa-utils

pulseaudio-utils

udisks2

polkit

cups

avahi

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.

• Eingeschränkte Media Formate
  • MPEG-2
  • MP-3

• Multimedia Formate ergänzen
  • Multimediafähigkeiten erweitern
  • "1-Klick-Install" Codecs & Bibliotheken

• Weiteres zu Codecs & Bibliotheken
  • Wikipedia:Videoformat

• • Wikipedia:Audioformat

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