Posts by joka63

Quote from kim88

Immutable Linux ist längst Alltag

Immutable Linux ist meiner Meinung nach schon längst im Alltag angekommen. Für normale Nutzer:innen gibt es mit Fedora Silverblue oder Aeon OS hervorragende Systeme, die stabil, modern und sehr wartungsarm sind. Wer einfach einen verlaesslichen Desktop moechte, ist dort heute schon sehr gut aufgehoben.

Ich nutze seit Fedora 40 Silverblue und bin im Großen und Ganzen zufrieden. Insbesondere Updates und Fedora-Upgrades sind sehr entspannt durch das einfache Rollback.

Quote from kim88

Das Problem fängt oft dann an, wenn man nicht nur konsumiert, sondern entwickelt.

Warum immutable für Entwickler oft nervt

Als Entwickler habe ich immutable Distros bisher oft als frustrierend erlebt. Die Theorie ist super, die Praxis aber häufig mühsam. Man möchte Docker nutzen, verschiedene IDEs ausprobieren, CLI-Tools installieren oder spezielle Abhängigkeiten benötigen. Und plötzlich fängt man an, Workarounds zu bauen, Container für alles zu nutzen oder das Basissystem doch wieder zu verbiegen.

Kurz gesagt: Immutable und Entwickler-Alltag haben sich für mich oft wie ein Pain in the Ass angefühlt. Nicht unlösbar, aber unnötig kompliziert. Genau an diesem Punkt habe ich bisher oft wieder aufgegeben und bin zu klassischen Distros zurückgekehrt.

Ernsthaft versucht mal unter Fedora Silverblue, "Docker" und "ddev" so zu installieren, dass diese Tools funktionieren und auch so, dass sie wartbar sind.

Ich möchte ohne Docker auskommen und somit ist auch ddev kein Thema für mich. Allgemin halte ich Tools, die stark ins System und in den Kernel eingreifen, wie z.B. VirtualBox, für Show-Stopper. Wenn aber ein stabiles System Priorität hat, dann mache ich lieber einen großen Bogen um solche Tools.

Quote from kim88

Aurora OS und der Entwickler-Fokus

Aurora OS fühlt sich in diesem Punkt anders an. Sehr anders sogar. Mein Eindruck nach kurzer Zeit ist, dass Aurora von Anfang an mit Entwickler:innen im Kopf gebaut wurde. Docker bzw. Podman, VS Code, JetBrains-Tools und ähnliche Werkzeuge sind nicht etwas, das man sich irgendwie zurechtbiegen muss, sondern sie sind klar Teil des Konzepts.

PyCharm läuft bei mir sehr zufriedenstellend in einer (Podman)-Toolbox. Der Versuch VSCode in einer Toolbox zu starten, scheiterte bei mir daran, dass VSCode auf den (GNOME-)Schlüsselbund zugreifen will und sich beendet, wenn das nicht klappt. Da ich nicht verstehe, warum VSCode den Schlüsselbund lesen will, will ich das auch nicht mehr benutzen. ZED-Editor ist dann meine alternative IDE, die auf dem Host läuft.

Quote from kim88

Was mir besonders gefällt: Viele typische Entwickler-Tools lassen sich direkt ins Image integrieren oder sind sauber vorbereitet, ohne dass man das System gegen seine eigene Philosophie benutzen muss. Das fühlt sich nicht nach Bastellösung an, sondern nach einem durchdachten Workflow. Ich verbringe weniger Zeit damit, mein System arbeitsfähig zu machen, und mehr Zeit damit, tatsächlich zu arbeiten.

Wie Bazzite Linux basiert Auorora OS auf Universal Blue - daher auf Fedora. Mit RPM Paketen und dem DNF Paketmanager kommt man aber nicht in Kontakt. Das Base System direkt sollte man nicht selber manipulieren - sondern nur die vordefinierten Optionen nehmen die einem ujust zur Verfügung stellt. Software installiert man über Flatpak und Hombrew (Ein Paketmanager den man vor allem von Mac OS kennt aber auch problemlos auf Linux läuft).

Es ist häufig ein Vorteil von kleinen Distros, die auf die großen wie Debian, Ubuntu, Arch oder Fedora aufsetzen, dass häufig nachgefragte Tools vorinstalliert und vorkonfiguriert sind.

Aurora OS basiert wie die anderen Bluefin-Projekte auf bootc (bootfähige Container) statt rpm-ostree. Mir ist nicht klar, ob bootc im Moment das "local layering", also die Installation von RPMs mit rpm-ostree install/override unterstützt. Jedenfalls rät die Bluefin-Dokumentation davon ab. Somit hat man nur die (zugegebenermaßen große) Auswahl zwischen vorkonfigurierten Images. Mir ist es persönlich lieber, die Kontrolle über Systempakte zu behalten und bei Bedarf nachzuinstallieren oder zu ersetzen. Ein triviales Beispiel ist das Ersetzen von nano durch vim: rpm-ostree override remove nano-default-editor --install vim-default-editor.

Der Hinweis auf Homebrew ist übrigens eine nützliche Anregung. Das habe ich heute gleich auf meinem Silvberblue-System nachinstalliert.

Obsidian auf Linux- und Mac-Desktops. Synchronisiert wird via Syncthing

Simplenote für schnelle Notizen unterwegs auf IPhone oder IPad, sowie zuhause auf Linux-Desktops

Beruflich: TiddlyWiki-Plugin für Firefox, MS-Todo App auf Android (wird mit Outlook synchronisiert)

Quote from HKaufmann

Müssen die Dateien so heißen oder kann ich docker durch podman ersetzen? Dann muß natürlich in den Bash Dateien diese angepasst werden.

Kann ich in der docker-compose.yml den port so übernehmen?

Ja, weil Podman bzw. Podman-compose möglichst kompatibel zu Docker bzw. Docker-Compose sein wollen.

Normalerweise ja. Der Port 8000 darf nicht durch eine andere Applikation blockiert sein. Sonst in Zeile 37 einen anderen Port, z.B. 8888 einfügen:
- "127.0.0.1:8888:8000"

Quote from HKaufmann

Können Sie einen Tip geben wie ich Paperless unter Podman installieren kann.

Es werden 3 Dateien benötigt: docker-compose.yml, docker-compose.env und .env

Diese Dateien müssen in ein Verzeichnis z.B. ~/.local/share/paperless kopiert werden. Zusätzlich noch zwei Verzeichnisse ~/Dokumente/Eingangskorb und ~/.local/share/paperless/export sowie ~/.local/share/paperless/media anlegen, dann mit docker-compose pull und up -d die Container starten. Die Pfade sind Beispiele, die zu meiner Konfiguration passen. Importierte Dokumente landen später im ./media-Verzeichnis:

mkdir -p ~/.local/share/paperless/export ~/.local/share/paperless/media
mkdir -p ~/Dokumente/Eingangskorb/
cd ~/.local/share/paperless
# cp docker-compose.yml docker-compose.env  .env .
# podman-compose Kommandos immer im Verzeichnis ausführen, wo die 3 Dateien oben liegen
podman-compose pull
podman-compose up -d

Dann im Browser http://localhost:8000 aufrufen.

Meine (anonymisierte und leicht vereinfachte) Konfiguration sieht wie folgt aus.

docker-compose.yml:

# Docker Compose file for running paperless from the Docker Hub.
# This file contains everything paperless needs to run.
# Paperless supports amd64, arm and arm64 hardware.
#
# All compose files of paperless configure paperless in the following way:
#
# - Paperless is (re)started on system boot, if it was running before shutdown.
# - Docker volumes for storing data are managed by Docker.
# - Folders for importing and exporting files are created in the same directory
#   as this file and mounted to the correct folders inside the container.
# - Paperless listens on port 8000.
#
# SQLite is used as the database. The SQLite file is stored in the data volume.
#
# To install and update paperless with this file, do the following:
#
# - Copy this file as 'docker-compose.yml' and the files 'docker-compose.env'
#   and '.env' into a folder.
# - Run 'podman compose pull'.
# - Run 'podman compose up -d'.
#
# For more extensive installation and update instructions, refer to the
# documentation.
name: paperless
services:
 broker:
   image: docker.io/library/redis:8
   restart: unless-stopped
   volumes:
     - redisdata:/data
 webserver:
   image: ghcr.io/paperless-ngx/paperless-ngx:latest
   restart: unless-stopped
   depends_on:
     - broker
   ports:
     - "127.0.0.1:8000:8000"
   volumes:
     - data:/usr/src/paperless/data
     - ./media:/usr/src/paperless/media:z
     - ./export:/usr/src/paperless/export:z
     - "${HOME}/Dokumente/Eingangskorb:/usr/src/paperless/consume:z"
   env_file: docker-compose.env
   environment:
     PAPERLESS_REDIS: redis://broker:6379
volumes:
 data:
 redisdata:

docker-compose.env

USERMAP_UID=0
USERMAP_GID=0
PAPERLESS_TIME_ZONE=Europe/Berlin
PAPERLESS_OCR_LANGUAGE=deu
PAPERLESS_SECRET_KEY='LCm;{WAX0]?(?}.2<j{FYsdt5J<O>.pf(Pa#2y3<M<VL3|k>e2ImTJsM?pmpGxgc'

.env

COMPOSE_PROJECT_NAME=paperless
HOME=/home/joka63

Wichtig sind die Werte von USERMAP_UID=0 und USERMAP_GID=0. Ohne diese Einstellung würde der paperless-Service mit Podman nicht laufen. HOME ist der Pfad zum Homeverzeichnis (nicht vergessen, den anzupassen!). Der PAPERLESS_SECRET_KEY ist einfach eine zufällige, lange Zeichenfolge. Das Standard-Installationsskript von Paperless-ngx nutzt hierfür folgendes Kommando.

LC_ALL=C tr -dc 'a-zA-Z0-9!#$%&()*+,-./:;<=>?@[\]^_`{|}~' < /dev/urandom | dd bs=1 count=64 2>/dev/null

Die Original-Installationsanleitung für Docker bzw. Docker-Compose gibt es hier: https://docs.paperless-ngx.com/setup/

Quote from HKaufmann

Jetzt geht es. Habe als Änderung nur die Rechte vom Dokumenten Ordner auf alles gesetzt.

In den Dokumenten Ordner wird die Datei aber mit einem nicht wieder auffindbaren Name abgelegt. Man kann also das Dokument nur in Papra wiederfinden.

Suche ein Program wo man auch normal suchen kann ohne das Program.

Das geht mit Paperless-ngx, wo man den Dateinamen und Speicherpfad importierter Dokumente anhand von eigenen Regeln selber konfigurieren kann.

Zu paperless-ngx gibt es schon eine Reihe von Threads im Linuxguides-Forum. Es läuft auch in 2-4 Containern (je nach Konfiguration), sollte also mit docker-compose oder podman-compose konfiguriert werden. Für Podman wären aber auch einige schlecht dokumentierte Anpassungen nötig.

Ich kann den Fehler in einer ZorinOS18-Box (vermutlich) nachstellen, wenn ich das Skript von ResidentAlex aus Post #42 verwende.

Er hat wohl den Ordner papra-data/documents/ vergessen, wo hochgeladene Dokumente gespeichert werden. Der Ordner muss auch angelegt sein und für alle les- und schreibbar sein. Deswegen gibt es wohl den Import-Fehler.

Allerdings finde ich es sehr unbefriedigend, wenn möglicherweise vertrauliche Dokumente "für alle" les- und schreibbar abgelegt werden und dass man diese Dokumente dann nur als Root bzw. mit sudo lesen und ggf. löschen kann.

Das eigentliche Problem ist Podmans Userid-Mapping von rootless-Containers, das sich von dem in Docker unterscheidet. Standardmäßig wird der root-User im Container auf die gleiche Userid des Nutzers abgebildet. Andere User bekommen zufällige Ids Somit hätte nur der root-User im Container das Recht, Dateien des Users auf dem Host zu lesen und schreiben. Oftmals, wie in Papra auch, möchte man aber, dass der User im Container auf die gleiche Userid wie der Aufrufer abgebildet wird und damit die Rechte hat, (geteilte) Dateien in dessen Homeverzeichnis zu lesen und zu schrieben. Dafür braucht man noch eine Extra-Option --userns=keep-id:

podman stop papra
sudo chown -R $(id -u):$(id -g) papra-data
podman run -d --replace --name papra --userns=keep-id --cgroup-manager=cgroupfs   --user $(id -u):$(id -g)   -p 1221:1221   -v $(pwd)/papra-data:/app/app-data:Z   -e APP_BASE_URL=http://localhost:1221   -e AUTH_SECRET="$AUTH_SECRET"   ghcr.io/papra-hq/papra:latest

In einer docker-compose.yml Datei müsste man folgende Option einfügen:

    userns_mode: keep-id

Falls dir das alles viel zu kompliziert ist: warum möchtest du podman statt docker verwenden? Die Papra-Dokumentation bezieht sich ja auf die Installation mit Docker und nicht auf Podman.

Quote from HKaufmann

Bei mir kommt keine Nummer heraus sondern mein Name.

Ändere die podman-compose Datei.

Ich habe es gerade mit ZorinOS (basierend auf Ubuntu 24.04 LTS) probiert. Die alte Version 9.4 von id unterstützt tatsächlich noch nicht das -n (numeric) Flag. Also einfach "id" in ein Terminal eingeben und die Nummern nach uid= bzw. gid= in die Zeile nach user: kopieren.

Quote from HKaufmann

In meiner Podman Compose steht das drin:

YAML

services:
  papra:
    container_name: papra
    image: ghcr.io/papra-hq/papra:latest
    restart: unless-stopped
    ports:
      - 1221:1221
    environment:
      - AUTH_SECRET=lUCZeFoD6adkge1a6lud411MAFAituNitJDh5YVUtzu2CKSb
      - APP_BASE_URL=http://localhost:1221
    volumes:
      - /home/"user"/pCloudDrive/Daten/DBank/Papra-Daten/app-data:/app/app-data
    user: 1000:1000

Display More

Wie kann ich testen welche UID mein Nutzer hat? Ich habe wirklich keine Ahnung.

Das ist das erste Mal das ich einen Container nutze.

Ich nehme mal an, dass dein Nutzername nicht "user" heißt. Deswegen würde der Pfad unter volumes: nicht funktionieren. Wenn du podman-compose (oder docker-compose) nutzt, musst du sowieso den Container von dem Verzeichnis aus starten, in dem deine docker-compose.yml Datei liegt. Also halte dich einfacher an die offizielle Dokumentation* und nutze relative Pfade so wie hier:

services:
 papra:
   image: ghcr.io/papra-hq/papra:latest
   container_name: papra
   restart: unless-stopped
   ports:
     - 1221:1221
   environment:
     - AUTH_SECRET=AkrQnYYYYYYYYYYYYYYYYHXXXXXXXXXXXXXXXXX
     - APP_BASE_URL=http://localhost:1221
   volumes:
     - ./app-data:/app/app-data:z
   user: "${UID}:${GID}"

Dies ist die docker-compose.yml-Datei, die ich gerade probeweise zum Installieren von Papra verwendet habe.
Das Flag :z ist nur auf Systemen mit aktiviertem SELinux nötig (also Fedora).

UID ist normalerweise als Umgebungsvariable gesetzt. Wenn nicht: Deine numerische Userid kannst du in einem Terminal mit "id -un" abfragen, deine Groupid mit "id -gn". In dem Fall diese Nummern nach "user:" eintragen, zum Beispiel:

     user: 1001:1001

P.S.: Nach jeder Änderung der docker-compose.yml-Datei solltest du den Padra-Container stoppen, löschen und neu starten mit:

cd .../Papra-Daten # Verzeichnis, wo die docker-compose.yml Datei liegt
podman-compose down
podman-compose up -d

______________

*) Du hast ja schon herausgefunden, dass man im Environment eine Zeile beginnend mit AUTH_SECRET eintragen muss, wie man sie in Padras "Docker Compose Generator" erzeugen kann.

Du kannst den Text aus den Podman-Desktop Logs per Copy&Paste in einen Codeblock kopieren.

Nach meiner Erfahrung kann man den Fehler mit Exit-Code 125 ignorieren. Das Kommando "podman compose up -d" startet den oder die Container im Hintergrund und beendet sich dann; der Exit-Code 125 scheint ein bekannter Bug in podman-compose zu sein. Kontrolliere z.B. mit Podman-Desktop, ob die Papra-Container laufen und dann ob deren Webinterface mit dem Browser erreichbar ist. Falls nicht, schau mit Podman-Dektop in den Container-Logs nach, ob es da hilfreiche Hinweise gibt.

Es gibt eine App Podman-Desktop als Flatpak. Das unterstützt auch die Installation der podman-Software. Bin mir aber nicht sicher, ob es dann die aktuelle Version oder die von der Distro installieren würde.

Nach meiner Erfahrung mit ZorinOS 18, das auch auf Ubuntu 24.04 LTS basiert, ist die Version 4.9 für die normalen Anwendungsfälle aktuell genug. Ich habe damit z.B. paperless-ngx und immich installiert.

Das myapps-RPM funzt auch unter Fedora 42 Workstation mit Starter und Hell-/Dunkel-Umschaltung.

Technisch funktioniert jetzt MyApps auch unter Fedora 42 Workstation (als git clone), auch die Filterung nach Zeichenketten ist recht flott. Allerdings muss man daran denken, dass virtuelle Python-Environment mit der Option --system-site-packages zu erzeugen oder eine Zeile

include-system-site-packages = true

in venv/pyvenv.cfg einzutragen.

Anfangen kann ich damit aber recht wenig, und ich denke Anfänger auch nicht: es werden nach Filterung von (über 3.500) Systempaketen immer noch über 1500 Pakete aufgelistet. Es sollten also noch die Pakete ausgeblendet werden, die nur aufgrund von Abhängigkeiten installiert wurden, so ähnlich wie es GNOME-Software macht (wenn auch längst nicht perfekt) - das zumindest als Option.

Fedora Workstation 42 mit GNOME Desktop und Wayland:

Ich musste tkinter nachinstallieren:

sudo dnf install python3-tkinter python3-pillow python3-pillow-tk

Aber auch dann friert die GUI nach dem Start in diesem Zustand ein:

Letzter Logeintrag:

2025-12-23 12:05:41,929 - src.myapps.filters - INFO - 3069 System-Pakete gefiltert, 1535 User-Apps übrig

P.S.: Gleiches Verhalten, wenn ich die App mit git clone und wie im Readme beschrieben starte. Die GUI hängt sich beim Aufruf von

self.list_inner_frame.update_idletasks()

in gui.py:404 auf.

Warum verwendest du für MyApps Tk statt Gtk oder Qt wie in deinen anderen Projekten?

Quote from TuxNix

Ich hatte gedacht ein Klon wäre eine exakte Kopie der Quellplatte und hatte angenommen wenn ich den Rechner starte und mit der Taste F11 in das BIOS Bootmenü komme sollte dort dann neben der Systemplatte welche auf einem nvm SSD ist daneben noch den Klon als Festplatte aber auf Datentrger WD HD angezeigt werden. Sticks werde dort ja auch angezeigt. Ich hatte gedacht das der Klon dort auftaucht und dann audwählen kann von welchem Datenträger das System gestartet wird.

Das sollte eigentlich schon funktionieren, wenn auf der externen Festplatte Rescuezilla korrekt installiert ist und die Festplatte bootfähig ist. Wie hast du denn den Klon erstellt? Dafür hättest du auch schon Resuezilla von der Festplatte über das BIOS Bootmneü starten müssen.

Quote from Gonzo-3004

Öhm, ich glaube du verwechselst da was. Wenn irgendwas im Bootmenü erscheinen soll dann sind das Wiederherstellungspunkte die mit Timeshift erstellt werden. Dazu müssen deine Platten aber mit Btrfs formatiert sein.

Und die Systempartition muss Subvolumes nach einem zu Timeshift passenden Schema enthalten, was man ohne größeren Aufwand nur während der Installation einrichten kann. Original-Debian bietet das nicht (selbst wenn man BTRFs für die Systempartition gewählt hat), das auf Debian basierende GuideOS unterstützt das (dafür wird kein KDE sondern nur Cinnamon angeboten - man kann halt nicht alles haben).

Quote from TuxNix

Ich neben den Installationen konfiguriere ich meine System und habe auch gesehen das im Linux Bereich sich das auf viele Dateien bezieht. Demnach siche ich eine einfache Lösung das System einfach wieder her zu stellen. Die Images die ich auf den Windows Systemen mit und DiskImage gemacht habe ist im Grunde ein Klon in einem Archiv verpackt. Demnach denke wenn es funktioniert evtl Die Systemplatte klonen.
Kann ich mir das vorstellen das man von dem Klon dann auch booten kann?
Wäre eine wiederherstellung von einem Klon möglich?

Für all das ist Clonezilla bzw. Rescuezilla (ein Clonezilla mit GUI) gedacht. Du müsstest allerdings Clonezilla als Live-System von einem Stick oder externe Festplatte booten. Deswegen ist es für regelmäßige Sicherungen mMn weniger geeignet.

Timeshift und Snapper können Wiederherstellungspunkte im laufenden Betrieb regelmäßig sichern. Für die Wiederherstellung darf das Linux-System allerdings nicht so kaputt sein, dass es nicht mehr booten kann.

Letztes Jahr wurden im Thread Installierbares Abbild erstellen noch andere Möglichkeiten diskutiert, ein installierbares Abbild des Systems zu erstellen. Eines der Tools war Penguin's Egg. Das hatte ich für meine Debian-Installation auf meiner alten HDD probiert. Hat aber nicht funktioniert: das Tool konnte zwar ein bootbares Live-System erstellen; das hing sich aber beim Aufbau des Desktops auf, ich vermute mangels genügend Hauptspeicher (8GB).

Quote from koelnyeti

Hallo, ich nutze Zorin OS 18 und habe mir das AppImage von pCloud geladen habe dis in einem Ordner für ausführbare Programme abgelegt, würde jetzt gerne eine Verknüpfung auf dem Desktop anlegen, was soweit auch geht beim versuch pCloud zu starten geht der Softwaremanager auf mit einer kurzen Fehlermeldung im unteren rand (Installation nicht möglich Dateityp wird nicht unterstützt. Wie kann ich das Problem Lösen? Achtung Anfänger

Achtung, bin kein guter Didakt!

Ich kann das beschriebene Verhalten auf meiner Zorin OS 18 Installation nachvollziehen.

Ich nehme an, du hast in "Dateien" mit "Verknüpfung erstellen" einen symbolischen Link erzeugt und den per Maus auf den Schreibtisch geschoben. Nach einem Doppelklick wird tatsächlich eine Warnung ausgegeben und die Software-Applikation gestartet.

Die Verknüpfung zum Appimage-File hat aber ein Kontextmenü (rechte Maustaste) mit einem Eintrag "Run as program". Damit kann man die pcloud-App starten.

Wenn du das Appimage-File "pcloud" in einen Ordner ~/.local/share/appimages ablegst, dann erzeugt Zorin automatisch einen Eintrag ins Startmenü. Dann hast du die Optionen, den Starter "zum Desktop hinzuzufügen" oder ihn ans "Dash anzuheften", d.h. in die Anwendungsleiste unten.

Das alles sieht mir sehr Zorin OS speziell aus. Zorin OS ist ja ein aufpolierter GNOME-Desktop. Technisch funktioniert das mit GNOME-Erweiterungen, von denen es in ZorinOS eine ganze Reihe gibt, wie z.B. "Zorin Menu", "Zorin Desktop Icons", "Zorin Taskbar", die alle Anpassungen von unter anderen Namen bekannten GNOME-Erweiterungen sind (ArcMenu, "Gtk4 Desktop Icons", "Dash to Panel").

Quote from Frostlike8343

Also ich arbeite seit Anbeginn unter Linux mit Brave und der Netflix-Erweiterung unter verschiedensten Distributionen. Wobei Zorin nicht darunter war, weil mir diese zu restriktiv aufgebaut ist.

Seit einigen Jahren nutze ich Netflix mit Firefox unter Fedora oder MacOS, ohne Probleme und besondere Einstellungen.

Auch unter Zorin OS 18 in einer Boxes-VM funktioniert Netflix mit Brave, sogar als Webapp mit eigenem Menüeintrag. Brave und die Netflix-Seite bieten die Installation der Widedevine-Erweiterung an.

Wie man auf die Idee kommen kann, unter Linux dafür eine netflix.exe-Datei aufzurufen, kann ich auch nicht nachvollziehen. Vielleicht ist das das Problem von Zorin OS, dass das möglich, wenn auch sinnlos ist.

Wie hast du Dolphin installiert? Als Flatpak von Flathub oder als Paket von den Zorin OS Quellen?

Die Flatpak-Version läuft in einer Sandbox und hat nicht (ohne weiteres) alle Rechte, die der Dateimanager für System- und Netzwerkdateien braucht.