Conseils pour structurer son répertoire personnel (2023)

Conseils pour structurer son répertoire personnel

• Structurer ou ranger des répertoires n’est pas très différent du fait de structurer ou ranger d’autres choses ; l’essentiel est d’adopter la méthode qui a le plus de sens pour soi.
• Quand on gère de l’organisation, la situation peut très vite devenir incontrôlable.
• Le but principal du rangement est l’efficacité : il faut pouvoir trouver facilement et rapidement ce qu’on cherche, et enregistrer facilement et rapidement ce qu’on doit stocker.

Fichiers et répertoires cachés par défaut

• Dans mon répertoire personnel, il y a tous les fichiers cachés par défaut qui font partie des systèmes d’exploitation Unix modernes, comme .config, .aliases, .profile, .gnupg, .mozilla, etc.
• Je préférerais que toutes les applications respectent XDG_CONFIG_HOME, mais je n’interviens pas trop là-dessus et je ne m’en préoccupe pas excessivement.
• Par le passé, je maintenais $HOME avec Git, et c’est une excellente manière de gérer ses dotfiles.
• Je mets encore tous mes dotfiles dans Git pour conserver l’historique des modifications, mais je ne laisse tels quels que ceux qui fonctionnent de la même manière sur les différents systèmes que j’utilise.
• Les dotfiles spécifiques à une configuration sont conservés dans un répertoire dotfiles et j’utilise des liens symboliques.

Organisation générale des fichiers et répertoires

• Les fichiers et répertoires ordinaires sont principalement organisés de deux façons : par « catégorie » et par « date ».
• Structure de répertoires de base :
  • bin
  • data
  • edata
  • mnt
  • usr/dotfiles
• Je laisse les répertoires Desktop et Downloads tels quels (la plupart des applications semblent les imposer).
• Le répertoire bin sert à stocker les scripts shell et les exécutables binaires personnels (à l’exclusion de ce qui est installé via le gestionnaire de paquets).
• Le répertoire mnt sert à divers points de montage, comme les cartes SD, les disques USB ou le stockage partagé utilisé dans mon homelab.
• Je n’utilise jamais le montage automatique et j’emploie des scripts shell dédiés au montage.
• Le répertoire usr/dotfiles est géré avec Git avec les dotfiles généraux comme .aliases, et utilise des liens symboliques vers les fichiers correspondants du répertoire dotfiles.

Organisation des répertoires de données

• Les répertoires data et edata sont les deux principaux répertoires qui contiennent toutes les données.
• Ces deux répertoires sont des datasets ZFS exécutés sur un pool de disques en miroir, distinct du système racine.
• Grâce à ZFS, les snapshots ainsi que les opérations d’envoi et de réception ZFS sont utilisés régulièrement pour sauvegarder facilement les données vers un stockage réseau.
• La différence entre data et edata, c’est que edata est un dataset chiffré natif de ZFS.
• Le chiffrement est bon pour la confidentialité, mais il ajoute une couche de complexité pénible sur une hiérarchie de système de fichiers déjà complexe, et le chiffrement ZFS comporte des bugs.
• Il est fortement recommandé de toujours sauvegarder les données importantes sur plusieurs solutions de stockage et emplacements différents.
• Je n’utilise pas le cloud storage pour les éléments importants.

Conseils supplémentaires

• La règle de base pour nommer les fichiers et répertoires est qu’on doit pouvoir identifier facilement de quoi il s’agit rien qu’en voyant le nom.
• Si l’on ne peut pas savoir de quoi parle un fichier sans l’ouvrir, il faut l’ouvrir immédiatement puis le renommer de façon plus parlante la prochaine fois qu’on verra son nom.
• Si l’on laisse les fichiers et répertoires s’accumuler sans les organiser, ils deviennent ensuite très difficiles à remettre en ordre.
• J’utilise des noms de fichiers contenant de longues descriptions quand c’est nécessaire afin de pouvoir comprendre le contenu d’un fichier sans l’ouvrir.

L’avis de GN⁺

• Cet article fournit des conseils pratiques sur la manière de ranger et d’organiser une structure de répertoires. L’idée d’utiliser des datasets ZFS pour séparer la gestion entre répertoires chiffrés et non chiffrés est particulièrement intéressante.

• Personnellement, je pense qu’il est préférable de stocker les données importantes sous forme chiffrée. Mais comme le chiffrement a aussi des inconvénients, comme une baisse de performances ou une complexité accrue, il semble préférable de l’utiliser de manière sélective selon le contexte.

• Il me semble aussi important de partager avec sa famille la manière d’accéder aux données chiffrées. Ainsi, même en cas d’accident ou d’impossibilité d’y accéder soi-même, on évite de perdre les données.

• Pour la gestion des données personnelles, il est très important d’établir une stratégie de sauvegarde systématique comme celle de l’auteur. Suivre la règle de sauvegarde 3-2-1, tout en privilégiant des stockages locaux physiquement répartis plutôt que le cloud storage, paraît aussi être une bonne approche.

• Parmi les outils open source utiles pour organiser ses données personnelles, on peut citer Syncthing ou Nextcloud. Bien utilisés, ces outils peuvent permettre une gestion des données personnelles à la fois structurée et sûre.

[GN⁺]

Avis de Hacker News

• Je déteste quand mon répertoire personnel devient un bazar, surtout quand une app estime devoir créer dans mon home un répertoire qui n’est même pas caché.
  Le plus rageant, c’est ~/go, le répertoire par défaut des modules Go. Je déteste tellement ça que j’ai évité pendant des années d’installer des apps Go ou de développer en Go, mais j’ai fini par devoir m’y mettre ; on peut le changer avec GOPATH, mais comme valeur par défaut c’est lamentable.

  • Le pire, ce sont les outils CLI créés sur Mac qui ignorent XDG. Comme ce n’est pas un concept courant dans cet univers, chaque outil salit les dotfiles avec son propre répertoire, du genre .rustup, .mix, .npm, .yarn.
    Mais polluer le répertoire personnel sans même avoir la décence de se cacher, comme ~/go, c’est vraiment impoli.
  • Je considère que GOPATH lui-même est une mauvaise conception. Au lieu d’avoir, comme dans d’autres langages, une structure de répertoires indépendante par projet, il pousse à mélanger dans la même arborescence des éléments de projets sans rapport entre eux.
    C’est tellement contraire à ma façon d’organiser mes projets que c’est la principale raison pour laquelle je ne me suis pas intéressé à Go. Ça peut mieux convenir à ceux qui préfèrent regrouper plusieurs projets sans lien dans un seul monorepo, mais ce n’est pas mon goût.
  • Astuce : ne mettez pas vos fichiers dans $HOME. $HOME est l’endroit que les apps salissent ; mes fichiers peuvent littéralement aller n’importe où ailleurs.
  • J’ai abandonné depuis longtemps l’idée d’un répertoire personnel propre. Tout ce qui compte est dans des répertoires synchronisés à l’intérieur du home, comme pCloud ou Dropbox, et là-dedans tout est parfaitement rangé.
    .vimrc et .gitconfig sont des liens symboliques vers un dépôt Git. Comme ça, le reste du répertoire personnel peut être une poubelle complète, ça n’a pas d’importance ; et si la machine meurt, je peux récupérer sur une autre en quelques minutes.
  • J’aurais aimé qu’Unix sépare dès le départ, de façon standard, le « répertoire personnel où les apps mettent tout ce qu’elles veulent » et le « répertoire personnel où l’utilisateur met ses propres fichiers ».

• xdg-ninja m’a aidé à réduire le problème de la plupart des apps qui déversent des fichiers dans le répertoire personnel.
  En résumé, il scanne les programmes installés et indique s’ils peuvent être configurés pour respecter le standard XDG. Ça ne marche pas pour tout, mais beaucoup d’apps ont ce genre d’option.
  https://github.com/b3nj5m1n/xdg-ninja

• Je veux non seulement de l’ordre, mais aussi pouvoir sauvegarder et transporter proprement mon environnement entre machines.
  Le dossier .config est un énorme casse-tête pour les sauvegardes stratégiques, parce que des apps y mettent des gigaoctets de données de session.
  Les « données de session » ne sont pas des « paramètres ». Les « paramètres » d’une app ne devraient pas peser plusieurs gigaoctets.

  • Tant qu’on ne demande pas explicitement à un programme de modifier durablement sa configuration, .config devrait pouvoir fonctionner en lecture seule.
  • Totalement d’accord. Je ne comprends pas pourquoi les apps utilisent .config comme stockage de données applicatives. Pour ça, il y a .local et .cache.

• C’est tellement personnel que la solution de l’auteur ne me sert à rien, et je doute que la mienne aide beaucoup quelqu’un d’autre.
  Mon répertoire personnel est quasiment vide. Tous mes fichiers de travail sont dans OwnCloud, et la vraie question est donc la structure de répertoires à l’intérieur d’OwnCloud. Mes dépôts Git locaux sont sur une partition totalement séparée.
  Maintenant que KeepassXC gère les clés SSH, les clés de .ssh sont elles aussi passées dans le fichier Keepass stocké dans OwnCloud. C’est devenu extrêmement simple, et il n’y a presque plus rien dans mon home qui mérite vraiment de l’attention.

  • Ce qui compte, c’est la portabilité quand on change de système, et la séparation entre environnements pro et perso.
    Après connexion, je dois pouvoir synchroniser d’une seule commande l’ensemble de fichiers adapté à l’environnement où je me trouve : Linux ou non, professionnel ou personnel, desktop ou serveur.
    Par exemple, je ne veux absolument pas exporter vers un système professionnel des variables d’environnement comme l’endpoint de mon coffre-fort maison ou certains tokens.
    Je suis récemment passé à home-manager du projet NixOS, et ça semble assez prometteur. Le langage Nix est complexe, mais son abstraction pour définir différents environnements correspond exactement à ce dont j’avais besoin, et je peux séparer le contenu des fichiers pro/perso avec des branches Git.
  • Je garde quand même .vimrc et .bashrc/.zshrc dans le home.

• L’idée est bonne, mais je n’aime pas la façon de découper les médias selon une structure de type familial. À terme, on risque de se retrouver avec plein de fichiers en double et de copies modifiées, facilement mélangés, au point de perdre les versions retouchées.
  À mon avis, il vaut mieux organiser les photos avec des mots-clés EXIF. On stocke les métadonnées dans la photo elle-même, éventuellement dans le type MIME, et si c’est lié à la famille, on ajoute des tags comme #family ou #personx. Les photos restent donc dans des dossiers par date, par exemple, et le reste se gère en éditant les mots-clés avec un programme comme Adobe Bridge.
  Pour la structure des noms de fichiers de documents, j’ai essayé à la fois Date then Description.txt et Keyword Title or Description and then Date.txt. Pour la date, j’utilise une date ISO au format YYYY-MM-DD-hhmm afin de faciliter le tri, avec -hhmm en option.
  Parfois, on veut trier par sujet, c’est-à-dire par mot-clé ou par titre, mais quand le moment de l’enregistrement compte davantage, comme pour un journal, il vaut mieux mettre la date au début.
  La date peut sembler inutile puisqu’elle est aussi stockée par le système, mais quand on déplace des fichiers, elle finit par changer, et elle change encore plus facilement en cas d’erreur. En revanche, la date dans le nom de fichier ne change pas, et elle aide aussi au tri des listes.

  • Un stockage adressé par contenu pour chaque type de média me semble être la bonne direction pour ce problème. Idéalement, ce serait une sorte d’overlay qui ne modifie pas la structure de répertoires existante ni l’organisation des fichiers, mais se contente d’y faire référence.
    photoprism et photostructure ne semblent pas trop se soucier de la structure des répertoires ou de l’organisation, mais paperless (et ses variantes récentes comme -ngx) est tristement célèbre pour son approche très dogmatique de l’organisation et son refus de respecter les structures existantes.
    J’ai utilisé camlistore/perkeep pendant un temps pour mes photos, mais Google Photos a une fonctionnalité écrasante : il identifie qui figure sur toutes les photos, même en tenant compte des différences d’âge. Mes deux fils ont huit ans d’écart et, à certains âges, ils se ressemblent vraiment beaucoup, mais il les distingue correctement. Je ne sais pas s’il utilise l’analyse faciale ou les métadonnées des photos, mais il ne s’est jamais trompé. Le problème, c’est qu’il n’existe pas de moyen raisonnable d’exporter ces tags hors de Google Photos, même en payant.
    Il est probablement temps que j’y jette de nouveau un œil. Je ne me souviens plus si photostructure ou photoprism tentent la reconnaissance faciale, mais même si ce n’est pas encore le cas, ils devraient bientôt atteindre un niveau proche de Google Photos, ou au moins devenir assez bons pour se passer de Google.
    Pour les documents et les photos/vidéos, admettons. Mais qu’en est-il de la musique ? Pour le meilleur ou pour le pire, cela fait au moins une dizaine d’années que je n’ai plus géré directement une collection musicale sous forme de fichiers. Existe-t-il aujourd’hui des systèmes de bibliothèque musicale plus profondément intégrés au contenu que de simples « fichiers sur disque », à la manière de paperless ou photoprism ?
  • Pour gérer des tags arbitraires sur des fichiers, TagSpaces https://www.tagspaces.org/ ou TMSU https://tmsu.org/ valent le détour. Ce n’est pas limité aux fichiers EXIF ou ID3.

• Ma méthode est la suivante.
  Les éléments liés à l’interface graphique sont en majuscules, ceux liés au CLI en minuscules. Je préfère des chemins comme ~/documents, mais comme les gens du monde GUI tiennent aux majuscules, je l’accepte. Il est rare que je doive mélanger les deux, donc ce n’est pas un gros problème.
  ~/dotfiles est mon répertoire de dotfiles géré avec Git. Je crée des liens symboliques comme ~/.zshrc -> dotfiles/zshrc. Je n’utilise pas de logiciel de gestion dédié, seulement des liens. Avant, j’utilisais ~/.dotfiles, mais je trouve plus logique de le laisser visible.
  ~/projects est mon répertoire de projets. ~/projects/test contient des projets de test ponctuels, ~/projects/my mes projets personnels, et ~/projects/company les projets de l’entreprise pour laquelle je travaille actuellement. Comme il m’arrive de travailler avec plusieurs entreprises, un peu comme en freelance, j’ai besoin de les séparer.
  ~/tmp est mon répertoire pour tous les travaux jetables. J’ai une fonction shell appelée mkcdtmp qui crée un répertoire avec la date du jour, comme ~/tmp/240419, puis s’y déplace. C’est vraiment une excellente méthode. Je préfère acheter de gros disques et laisser les déchets derrière moi, mais dans un état à peu près organisé, donc je fais rarement le ménage. Si j’ai besoin de quelque chose d’hier ou du mois dernier, je sais où le trouver, et c’est ce qui m’a le plus aidé à organiser mon travail temporaire. Si nécessaire, je peux aussi créer ~/tmp/whatever, et de toute façon tout cela est destiné à être jeté.
  Je n’utilise pas ~/Desktop. J’utilise aussi très peu ~/Documents, et je dois encore trouver comment l’organiser. Pour les petites notes, je les mets dans le dépôt GitHub qui génère mon site web personnel. J’ai essayé plusieurs applications de notes, mais un site web ordinaire en Markdown est ce qui me convient le mieux.
  Je n’ai jamais réussi à organiser mon travail de manière très structurée. Il y a toujours des tas de déchets qui traînent et finissent par devenir quelque chose d’utile, alors au lieu de lutter contre moi-même, j’ai décidé de transformer ces déchets en déchets organisés.
  Fondamentalement, mon ordinateur est un consommable. Tout ce qui se trouve dans ~/projects est dans Git, et ~/tmp ressemble plutôt à un cache peu important ou à du travail jetable. J’essaie d’organiser les choses de façon à pouvoir repartir d’un état propre sans que la restauration prenne longtemps. Je réinstalle souvent l’OS depuis zéro et je change aussi souvent de système d’exploitation et d’ordinateur portable ; cette méthode est celle qui me convient le mieux.

  • Je déteste vraiment mettre quoi que ce soit en majuscules. Je sais que ce n’est qu’une touche de plus à appuyer, mais c’est horriblement pénible.

• L’une de mes grandes frustrations avec les systèmes de fichiers, c’est qu’il y a trop de répertoires qui commencent par D.
  Desktop, Dev, Downloads, Documents, Dropbox, etc.
  J’ai pensé à changer quelque chose, mais comme le dit l’auteur, beaucoup d’applications sont assez obstinées sur ce point.

  • Pour éviter ce problème, j’utilise /src.

• J’utilise une structure assez simple, mais qui me convient bien
  Sous projects/, je crée des dossiers par année comme 2023/, 2024/, et chaque projet reçoit un préfixe mois+jour, par exemple 0000-something/, 0312-other-project/, 0419-hn-comment/
  Je crée un dossier d’année chaque année, et quand je veux faire remonter un projet de longue durée, je mets 0000 devant, ou je laisse simplement le jour à 00
  C’est simple et ça marche sur n’importe quel OS. Sous Linux, j’utilise quand même quelques scripts d’appoint
  C’est aussi facile de créer rapidement un répertoire où déplacer des fichiers depuis le dossier Téléchargements, et si l’on garde l’imbrication à un seul niveau, c’est facile à retrouver. Je trouve ça mieux qu’un schéma comme YYYY/MM/DD, qui ajoute un niveau supplémentaire pour le mois

  • J’utilise une approche similaire quand j’organise des dossiers liés dans l’ordre chronologique
    Dans le répertoire racine, je mets généralement ce sur quoi je travaille actuellement. C’est l’idée de « aujourd’hui » ou « cette semaine »
    Quand je sors de cette fenêtre temporelle et que j’archive, par exemple aujourd’hui je crée un dossier au format 041924, puis j’y déplace tous les fichiers créés ce jour-là
    À l’échelle d’une vie humaine, je ne pense généralement pas qu’il soit nécessaire d’utiliser une chaîne comme 2024. Je doute de vivre jusqu’en 2100, et ce qui précède 2000 n’est pas pertinent, donc 24 suffit
    Le temps continue de passer, donc le nombre de dossiers d’archive augmente, mais ils restent petits et faciles à retrouver. Ça marche particulièrement bien quand on crée chaque jour des fichiers standard pas vraiment uniques
  • Pourquoi ne pas utiliser la date de modification des dossiers ? On pourrait trier dessus
    projects/ | 01.01.2017
something/ | 01.01.2024
other-project/ | 01.01.2023
hn-comment/ | 01.01.2022
  • Moi aussi, j’ai évolué vers cette approche en y ajoutant une structure de dossiers à caractère « processus de traitement ». Ça augmente les données dupliquées, mais ça préserve la santé mentale

• À propos des sauvegardes, il m’est arrivé de vouloir installer un nouveau Mac à partir d’une sauvegarde Time Machine, et que le Mac ne voie absolument rien dans cette sauvegarde
  Après avoir contacté l’assistance Apple, on m’a dit qu’il existait un bug rare où le processus d’installation, au lieu d’installer depuis la sauvegarde, réinitialise la sauvegarde Time Machine
  Heureusement, j’avais configuré Backblaze, ce qui m’a sauvé, mais restaurer plusieurs centaines de gigaoctets a pris énormément de temps
  Maintenant, j’utilise à la fois Time Machine, Backblaze et les sauvegardes iCloud, et de temps en temps je compresse le tout en .tgz pour l’envoyer sur S3

• Pour les noms de fichiers et de répertoires, entre traits d’union et underscores, je suis entièrement d’accord pour les traits d’union
  Utiliser des traits d’union quand on se déplace dans le terminal est tellement pratique que je pense que ça devrait être la norme. C’est bien mieux que de devoir taper des caractères en plus à chaque fois pour sélectionner des noms avec underscores, ou que de gérer des espaces

  • C’est un petit détail que j’aime bien dans Lisp. On peut nommer les variables comme foo-bar-baz, sans avoir besoin d’appuyer sur Shift en tapant