Tipps zur Strukturierung des Home-Verzeichnisses (2023)

 (unixdigest.com)
2 Punkte von GN⁺ 2024-04-21 | 1 Kommentare | Auf WhatsApp teilen

Tipps zur Struktur des Home-Verzeichnisses

  • Das Strukturieren oder Aufräumen von Verzeichnissen unterscheidet sich nicht wesentlich vom Strukturieren oder Aufräumen anderer Dinge; entscheidend ist, es auf die Weise zu tun, die für einen selbst am logischsten ist.
  • Wenn es um Organisation geht, kann sehr schnell alles außer Kontrolle geraten.
  • Das Hauptziel von Ordnung ist Effizienz: Man sollte das, was man finden möchte, einfach und schnell finden können, und das, was man speichern muss, einfach und schnell ablegen können.

Versteckte Standarddateien und -verzeichnisse

  • In meinem Home-Verzeichnis befinden sich alle üblichen versteckten Standarddateien moderner Unix-Betriebssysteme wie .config, .aliases, .profile, .gnupg, .mozilla usw.
  • Ich würde es bevorzugen, wenn alle Anwendungen XDG_CONFIG_HOME respektieren würden, aber ich mische mich nicht zu sehr ein und mache mir auch nicht allzu viele Gedanken darum.
  • Früher habe ich $HOME mit Git verwaltet, und das ist eine hervorragende Methode, Dotfiles zu organisieren.
  • Ich lege weiterhin alle Dotfiles in Git ab, um die Änderungshistorie zu bewahren, lasse aber nur die Dotfiles unverändert, die auf den verschiedenen von mir genutzten Systemen identisch funktionieren.
  • Dotfiles für einzelne Konfigurationen bewahre ich im Verzeichnis dotfiles auf und verwende symbolische Links.

Allgemeine Organisation von Dateien und Verzeichnissen

  • Allgemeine Dateien und Verzeichnisse organisiere ich hauptsächlich auf zwei Arten: nach „Kategorie“ und nach „Datum“.
  • Grundlegende Verzeichnisstruktur:
    • bin
    • data
    • edata
    • mnt
    • usr/dotfiles
  • Die Verzeichnisse Desktop und Downloads lasse ich unverändert bestehen (weil die meisten Anwendungen das offenbar erzwingen).
  • Im Verzeichnis bin speichere ich Shell-Skripte und persönliche binäre ausführbare Dateien (ausgenommen alles, was über den Paketmanager installiert wurde).
  • Das Verzeichnis mnt nutze ich für verschiedene Mount-Punkte wie SD-Karten, USB-Laufwerke und gemeinsam genutzten Storage im Homelab.
  • Ich verwende niemals automatisches Mounten, sondern Shell-Skripte zum Mounten.
  • Das Verzeichnis usr/dotfiles wird zusammen mit allgemeinen Dotfiles wie .aliases per Git verwaltet und verwendet symbolische Links auf die zugehörigen Dateien im Verzeichnis dotfiles.

Organisation der Datenverzeichnisse

  • Die Verzeichnisse data und edata sind die beiden Hauptverzeichnisse, in denen ich sämtliche Materialien speichere.
  • Diese beiden Verzeichnisse sind ZFS-Datasets, die in einem gespiegelten Festplatten-Pool laufen, getrennt von der Root-Installation.
  • Mithilfe von ZFS sichere ich sie einfach auf Network Storage, indem ich regelmäßig Snapshots sowie ZFS send und receive nutze.
  • Der Unterschied zwischen data und edata besteht darin, dass edata ein standardmäßig verschlüsseltes ZFS-Dataset ist.
  • Verschlüsselung ist gut für die Privatsphäre, aber sie ist eine schreckliche zusätzliche Komplexitätsschicht über einer ohnehin schon komplexen Dateisystem-Hierarchie, und ZFS-Verschlüsselung hat Bugs.
  • Es wird dringend empfohlen, wichtige Daten immer auf mehrere unterschiedliche Speicherlösungen und an mehreren Orten zu sichern.
  • Cloud Storage wird nicht für wichtige Dinge verwendet.

Zusätzliche Tipps

  • Die Grundregel beim Benennen von Dateien und Verzeichnissen lautet, dass man allein am Namen leicht erkennen können sollte, worum es sich handelt.
  • Wenn man nicht erkennen kann, worum es in einer Datei geht, ohne sie zu öffnen, sollte man sie sofort öffnen und ihr einen aussagekräftigeren Namen geben, damit der Dateiname beim nächsten Mal sinnvoller ist.
  • Wenn man Dateien und Verzeichnisse nicht organisiert und einfach liegen lässt, wird es später sehr schwierig, das zu korrigieren.
  • Ich verwende bei Bedarf Dateinamen mit langen Beschreibungen, damit ich den Inhalt einer Datei verstehen kann, ohne sie zu öffnen.

Meinung von GN⁺

  • Dieser Artikel bietet praktische Tipps dazu, wie man Verzeichnisstrukturen aufräumt und organisiert. Besonders interessant ist die Methode, ZFS-Datasets zu nutzen und in verschlüsselte und unverschlüsselte Verzeichnisse getrennt zu verwalten.

  • Ich persönlich halte es für sinnvoll, wichtige Daten verschlüsselt zu speichern. Allerdings gibt es auch Nachteile wie Leistungsabfall oder erhöhte Komplexität durch Verschlüsselung, daher scheint ein selektiver Einsatz je nach Situation sinnvoll zu sein.

  • Außerdem halte ich es für wichtig, den Zugang zu verschlüsselten Daten mit Familienmitgliedern zu teilen. So lässt sich vermeiden, dass Daten verloren gehen, falls man selbst durch einen Unfall oder aus anderen Gründen nicht mehr darauf zugreifen kann.

  • Für das Management persönlicher Daten ist es sehr wichtig, wie der Autor eine systematische Backup-Strategie zu etablieren. Dabei kann es eine gute Methode sein, der 3-2-1-Backup-Regel zu folgen und statt Cloud Storage physisch verteilte lokale Speicher zu nutzen.

  • Nützliche Open-Source-Tools für die Verwaltung persönlicher Daten sind unter anderem Syncthing oder Nextcloud. Wenn man solche Tools gut nutzt, dürfte eine systematische und sichere Verwaltung persönlicher Daten möglich sein.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-04-21
Hacker-News-Kommentare

  • Ich hasse es, wenn das Home-Verzeichnis zugemüllt wird, besonders wenn Apps meinen, sie müssten im Home ein nicht einmal verstecktes Verzeichnis anlegen.
    Am meisten ärgert mich ~/go, das Standardverzeichnis für Go-Module. Ich hasse das so sehr, dass ich jahrelang die Installation oder Entwicklung von Go-Apps gemieden habe, musste es dann aber schließlich doch nutzen. Man kann es zwar über GOPATH ändern, aber als Default ist es miserabel.

    • Am schlimmsten sind CLI-Tools, die auf dem Mac entstanden sind und XDG ignorieren. Dort ist das kein geläufiges Konzept, daher müllt jedes Tool mit eigenen Dotfile-Verzeichnissen wie .rustup, .mix, .npm, .yarn herum.
      Aber das Home-Verzeichnis zu verschmutzen, ohne wenigstens die Höflichkeit zu besitzen, es wie ~/go zu verstecken, ist wirklich unverschämt.
    • Ich halte GOPATH selbst für ein schlechtes Design. Statt wie andere Sprachen pro Projekt eine unabhängige Verzeichnisstruktur zu haben, zwingt es Dinge aus völlig unabhängigen Projekten in dieselbe Verzeichnisstruktur.
      Das passt so gar nicht dazu, wie ich Projekte organisiere, und ist der Hauptgrund, warum ich mich nicht für Go interessiert habe. Für Leute, die gern mehrere unabhängige Projekte in einem Monorepo sammeln, mag es besser passen, aber mein Geschmack ist es nicht.
    • Tipp: Leg deine eigenen Dateien nicht in $HOME ab. $HOME ist der Ort, den Apps zumüllen; deine Dateien kannst du buchstäblich irgendwo anders ablegen.
    • Die Vorstellung eines sauberen Home-Verzeichnisses habe ich schon vor langer Zeit aufgegeben. Alles Wichtige liegt in Synchronisationsverzeichnissen wie pCloud oder Dropbox innerhalb des Home-Verzeichnisses, und dort ist alles perfekt organisiert.
      .vimrc und .gitconfig sind als Symlinks auf ein Git-Repository gesetzt. Dann kann der Rest des Home-Verzeichnisses kompletter Müll sein, und selbst wenn die Maschine stirbt, bin ich auf einer anderen Maschine in wenigen Minuten wiederhergestellt.
    • Es wäre schön gewesen, wenn Unix von Anfang an standardmäßig getrennt hätte zwischen „Home-Verzeichnis, in das Apps alles legen, was sie wollen“ und „Home-Verzeichnis, in das Nutzer ihre eigenen Dateien legen“.

  • xdg-ninja hat dabei geholfen, das Problem zu verringern, dass die meisten Apps Dateien ins Home-Verzeichnis kippen.
    Kurz gesagt scannt es installierte Programme und zeigt, ob sie so konfiguriert werden können, dass sie den XDG-Standard einhalten. Es funktioniert nicht für alles, aber viele Apps haben solche Optionen.
    https://github.com/b3nj5m1n/xdg-ninja

  • Ich will nicht nur Ordnung, sondern auch knapp und sauber sichern und zwischen Maschinen übertragen können.
    Der Ordner .config ist bei strategischen Backups ein großes Ärgernis, weil Apps dort mehrere Gigabyte an Sitzungsdaten ablegen.
    „Sitzungsdaten“ sind keine „Konfiguration“. Die „Konfiguration“ einer App kann doch nicht mehrere Gigabyte groß sein.

    • Solange man ein Programm nicht ausdrücklich auffordert, dauerhafte Einstellungen zu ändern, sollte .config auch schreibgeschützt funktionieren können.
    • Stimme voll zu. Ich weiß nicht, warum Apps .config wie einen Speicherort für App-Daten verwenden. Für so etwas gibt es .local und .cache.

  • Das ist so individuell, dass die Lösung des Autors für mich nutzlos ist und meine Lösung anderen vermutlich auch nicht viel hilft.
    Mein Home-Verzeichnis ist fast leer. Alle Arbeitsdateien liegen in OwnCloud, und die eigentliche Frage ist, wie die Verzeichnisstruktur innerhalb von OwnCloud aussieht. Lokale Git-Repositories liegen auf einer komplett separaten Partition.
    Da KeepassXC inzwischen SSH-Keys verwaltet, sind auch die Keys aus .ssh in die Keepass-Datei in OwnCloud gewandert. Es ist enorm simpel geworden, und im Home-Verzeichnis gibt es jetzt wirklich kaum noch etwas, um das man sich kümmern müsste.

    • Wichtig sind nur Portabilität beim Systemwechsel und die Trennung zwischen Arbeits- und privater Umgebung.
      Nach dem Login sollte ich mit einem Befehl genau den Dateisatz synchronisieren können, der dazu passt, ob die aktuelle Umgebung Linux ist, beruflich oder privat genutzt wird, Desktop oder Server ist.
      Umgebungsvariablen wie ein Home-Vault-Endpunkt oder bestimmte Tokens möchte ich zum Beispiel niemals auf ein Arbeitssystem exportieren.
      Ich bin kürzlich zu home-manager aus dem NixOS-Projekt gewechselt, und das wirkt ziemlich vielversprechend. Die Nix-Sprache ist komplex, aber ihre Abstraktion zum Definieren verschiedener Umgebungen war genau das, was ich brauchte, und per Git-Branch kann man Inhalte für Arbeits- und private Dateien trennen.
    • Trotzdem liegen .vimrc und .bashrc/.zshrc bei mir im Home-Verzeichnis.

  • Die Idee ist in Ordnung, aber mir gefällt nicht, Medien in eine familienartige Struktur aufzuteilen. Später hat man offenbar jede Menge doppelte Dateien und bearbeitete Duplikate, die leicht durcheinandergeraten, sodass man die bearbeitete Version verlieren kann.
    Fotos sollte man meiner Meinung nach besser über EXIF-Keywords organisieren. Man speichert die Metadaten im Foto selbst, vielleicht im MIME-Type, und versieht sie bei Familienbezug mit Tags wie #family oder #personx. Die Fotos liegen dann in Ordnern, etwa nach Datum, und den Rest erledigt man mit Programmen wie Adobe Bridge, um Keywords zu bearbeiten.
    Für die Struktur von Dokumentdateinamen habe ich sowohl Date then Description.txt als auch Keyword Title or Description and then Date.txt verwendet. Für das Datum nutze ich zur Sortierung ein ISO-Datum im Format YYYY-MM-DD-hhmm, wobei -hhmm optional ist.
    Manchmal möchte man nach Thema sortieren, also nach Keyword oder Titel; wenn aber wie bei einem Log wichtiger ist, wann etwas erfasst wurde, ist es besser, das Datum nach vorn zu stellen.
    Es mag überflüssig wirken, weil das Datum auch im System gespeichert ist, aber beim Verschieben von Dateien ändern sich Datumswerte irgendwann, und durch Fehler noch leichter. Das Datum im Dateinamen dagegen ändert sich nicht und hilft außerdem beim Sortieren von Listen.

    • Ein content-adressierter Speicher je Medientyp scheint für dieses Problem die richtige Richtung zu sein. Idealerweise wäre das eine Overlay-Schicht, die nur referenziert, ohne die bestehende Verzeichnisstruktur oder Dateiorganisation zu verändern.
      photoprism und photostructure scheinen sich nicht besonders um Verzeichnisstruktur oder Organisation zu kümmern, aber paperless (einschließlich neuerer Varianten wie -ngx) ist berüchtigt dafür, sehr eigensinnig bei der Ablage zu sein und bestehende Strukturen nicht respektieren zu wollen.
      Eine Zeit lang habe ich für Fotos camlistore/perkeep verwendet, aber Google Photos hat eine überwältigende Fähigkeit zu erkennen, wer auf allen Fotos zu sehen ist, sogar unter Berücksichtigung von Altersunterschieden. Meine beiden Söhne, acht Jahre auseinander, sahen sich im ähnlichen Alter wirklich sehr ähnlich, und trotzdem unterscheidet es genau, wer wer ist. Ich weiß nicht, ob es Gesichtsanalyse oder Fotometadaten nutzt, aber es hat sie nie verwechselt. Allerdings gibt es keine vernünftige Möglichkeit, diese Tag-Informationen aus Google Photos herauszubekommen, obwohl ich dafür bezahle.
      Ich glaube, es ist Zeit, mir das wieder anzusehen. Ich erinnere mich nicht, ob photostructure oder photoprism Gesichtserkennung versuchen, aber selbst wenn noch nicht, werden sie vermutlich bald ein ähnliches Niveau wie Google Photos erreichen oder zumindest gut genug werden, um die Google-Abhängigkeit zu beenden.
      Dokumente und Fotos/Videos sind die eine Sache, aber wie sieht es mit Musik aus? Im Guten wie im Schlechten habe ich seit mindestens etwa zehn Jahren keine Musiksammlung mehr direkt als Dateien verwaltet. Gibt es heutzutage für Musik Library-Systeme, die wie paperless oder photoprism stärker in den Inhalt integriert sind als bloße „Dateien auf der Festplatte“?
    • Für die Verwaltung beliebiger Datei-Tags lohnen sich TagSpaces https://www.tagspaces.org/ oder TMSU https://tmsu.org/. Das ist nicht auf EXIF- oder ID3-Dateien beschränkt.

  • Meine Methode sieht so aus:
    GUI-bezogene Dinge schreibe ich groß, CLI-bezogene klein. Ich bevorzuge zwar Varianten wie ~/documents, aber da die GUI-Leute auf Großschreibung bestehen, akzeptiere ich es einfach. Da ich beides fast nie mischen muss, ist das kein großes Problem.
    ~/dotfiles ist mein mit Git verwaltetes Dotfiles-Verzeichnis. Ich lege symbolische Links wie ~/.zshrc -> dotfiles/zshrc an. Ich verwende keine separate Verwaltungssoftware, sondern erstelle einfach Links. Früher habe ich ~/.dotfiles benutzt, aber ich finde, es ergibt mehr Sinn, es sichtbar zu lassen.
    ~/projects ist mein Projektverzeichnis. ~/projects/test sind einmalige Testprojekte zum Ausprobieren, ~/projects/my sind persönliche Projekte, ~/projects/company sind Projekte des Unternehmens, für das ich derzeit arbeite. Da ich manchmal freiberuflerähnlich mit mehreren Firmen arbeite, ist die Trennung nötig.
    ~/tmp ist das Verzeichnis für alle einmaligen Arbeiten. Ich habe eine Shell-Funktion namens mkcdtmp, die ein Verzeichnis mit dem aktuellen Datum wie ~/tmp/240419 erstellt und anschließend dorthin wechselt. Das ist wirklich großartig. Ich kaufe lieber eine große Festplatte und lasse Müll einigermaßen geordnet liegen, daher räume ich fast nie auf. Wenn ich etwas von gestern oder vom letzten Monat brauche, weiß ich, wo es ist; das war das Hilfreichste überhaupt, um temporäre Arbeit zu organisieren. Bei Bedarf kann ich auch ~/tmp/whatever anlegen, und am Ende ist ohnehin alles Wegwerfzeug.
    ~/Desktop benutze ich nicht. ~/Documents benutze ich ebenfalls kaum und muss dafür noch eine Ordnung finden. Kurze Notizen werfe ich in das GitHub-Repository, aus dem meine persönliche Website gebaut wird. Ich habe verschiedene Notiz-Apps ausprobiert, aber eine schlichte Website in Markdown passt für mich am besten.
    Es ist mir nie gelungen, meine Arbeit sehr strukturiert zu organisieren. Es bewegen sich immer Müllhaufen herum, die am Ende zu irgendetwas Brauchbarem werden; statt gegen mich selbst zu kämpfen, habe ich beschlossen, diesen Müll zu organisiertem Müll zu machen.
    Im Grunde ist mein Computer Verbrauchsmaterial. Alles in ~/projects liegt in Git, und ~/tmp ist eher Cache oder wegwerfbare Arbeit, die nicht besonders wichtig ist. Ich versuche, alles so zu organisieren, dass eine Wiederherstellung aus einem sauberen Zustand nicht lange dauert. Ich installiere das OS häufig von Grund auf neu und wechsle auch oft Betriebssystem und Laptop; diese Methode passt dafür am besten.

    • Ich hasse es wirklich, Dinge großzuschreiben. Ich weiß, es ist nur eine Taste mehr, aber es ist furchtbar lästig.

  • Eine meiner großen Beschwerden am Dateisystem ist, dass zu viele Verzeichnisse mit D anfangen.
    Desktop, Dev, Downloads, Documents, Dropbox und so weiter.
    Ich habe überlegt, etwas daran zu ändern, aber wie der Autor sagt, sind viele Anwendungen in dieser Hinsicht ziemlich stur.

    • Um dieses Problem zu vermeiden, verwende ich /src.

  • Ich verwende eine ziemlich einfache Struktur, die für mich aber gut funktioniert
    Unter projects/ lege ich Jahresordner wie 2023/, 2024/ an, und jedes Projekt bekommt ein Präfix aus Monat+Tag, etwa 0000-something/, 0312-other-project/, 0419-hn-comment/
    Jedes Jahr lege ich einen Jahresordner an; wenn ich langfristige Projekte weiter oben anzeigen möchte, setze ich 0000 davor oder lasse beim Datum nur 00 stehen
    Einfach und funktioniert auf jedem OS. Unter Linux nutze ich allerdings ein paar Hilfsskripte
    Außerdem ist es leicht, schnell ein Verzeichnis zu erstellen, in das man Dateien aus dem Download-Ordner verschiebt, und wenn man die Verschachtelung auf nur eine Ebene beschränkt, bleibt alles leicht auffindbar. Ich finde das besser als Muster wie YYYY/MM/DD, bei denen noch eine zusätzliche Monatsebene entsteht

    • Ich nutze einen ähnlichen Ansatz, wenn ich zusammengehörige Ordner chronologisch organisiere
      Im obersten Verzeichnis liegt meistens das, woran ich gerade arbeite. Also so etwas wie „heute“ oder „diese Woche“
      Wenn ich Dinge außerhalb dieses Zeitfensters archiviere, lege ich zum Beispiel für heute einen Ordner im Format 041924 an und verschiebe alle an diesem Tag erstellten Dateien dorthin
      Auf die Lebenszeit eines Menschen betrachtet halte ich Strings wie 2024 normalerweise nicht für nötig. Ich werde wohl kaum bis 2100 leben, und alles vor 2000 ist irrelevant, also reicht 24
      Die Zeit läuft immer weiter, daher wächst die Zahl der Archivordner, aber sie sind klein und leicht zu durchsuchen. Das passt besonders gut, wenn man täglich eher nicht sehr einzigartige Standarddateien erzeugt
    • Warum nicht das Änderungsdatum des Ordners verwenden? Dann könnte man doch sortieren
      projects/ | 01.01.2017
      something/ | 01.01.2024
      other-project/ | 01.01.2023
      hn-comment/ | 01.01.2022
    • Ich bin ebenfalls zu einer Variante dieses Ansatzes übergegangen, ergänzt um eine Ordnerstruktur mit eher „prozesshaftem“ Charakter. Es wird zwar mehr doppelte Daten geben, aber es schont die mentale Gesundheit

  • Zum Thema Backups: Ich wollte einmal einen neuen Mac aus einem Time-Machine-Backup einrichten, aber der Mac konnte im Time-Machine-Backup gar nichts sehen
    Als ich den Apple Support kontaktierte, erfuhr ich, dass es einen seltenen Bug gibt, bei dem der Installationsprozess manchmal statt der Installation aus dem Backup das Time-Machine-Backup initialisiert
    Zum Glück hatte ich Backblaze eingerichtet und war gerettet, aber das Wiederherstellen von mehreren Hundert Gigabyte hat sehr lange gedauert
    Inzwischen nutze ich Time Machine, Backblaze und iCloud-Backups, und gelegentlich packe ich alles als .tgz und lade es nach S3 hoch

  • Bei Datei- und Verzeichnisnamen stimme ich bei der Wahl zwischen Bindestrichen und Unterstrichen voll und ganz für Bindestriche
    Beim Navigieren im Terminal sind Bindestriche so praktisch, dass sie meiner Meinung nach Standard sein sollten. Das ist viel besser, als jedes Mal zusätzliche Eingaben machen zu müssen, um Dateinamen mit Unterstrichen auszuwählen, oder Leerzeichen zu behandeln

    • Das ist eine der Kleinigkeiten, die ich an Lisp mag. Man kann Variablen foo-bar-baz nennen und muss beim Tippen nicht die Umschalttaste drücken