Quelle que soit l'organisation choisie, cela rendra certaines choses plus faciles et d'autres plus difficiles.
Organisation des fichiers par types, comme Unix (en bin, man, lib/python, ...), il est plus facile d'utiliser des fichiers. Si vous souhaitez exécuter une commande, vous savez où la trouver, quel que soit le package qui la fournit. Si vous souhaitez rechercher dans la documentation, tout est au même endroit. Si un programme fournit un module de mise en évidence de la syntaxe Vim, une fonction d'achèvement zsh ou des liaisons Python, le fichier correspondant sera à un endroit où vim / zsh / python pourra le trouver.
Unix organise également les fichiers par modèles d'utilisation. Les fichiers de configuration entrent /etc, les fichiers qui ne changent pas en fonctionnement normal entrent /usret les fichiers qui changent entrent automatiquement /var. Les données des utilisateurs tombent sous /home. Ceci est très utile pour la gestion de la configuration (gérez le contenu /etcet la liste des packages installés). Il est également utile de définir des stratégies de sauvegarde: ce qui est /etcet /homeest d'une importance cruciale, tandis que ce qui est /usrpeut être facilement téléchargé à nouveau.
Le principal coût de la méthode Unix est que l'installation d'un logiciel est répartie sur de nombreux répertoires. Cependant, les systèmes Unix modernes ont quand même des gestionnaires de paquets; la gestion des fichiers dans de nombreux répertoires n'est de loin pas la chose la plus complexe qu'ils font (le suivi des dépendances est très utile et plus difficile).
Comparez cela avec Windows. Windows a commencé sans gestion de package et chaque application a créé son propre répertoire quelque part. Tous les fichiers se trouveraient normalement dans ce répertoire: programmes, données statiques, données utilisateur,… Sauf parfois pour les bibliothèques dont les programmes tomberaient dans un répertoire système commun sans tenir compte des conflits («DLL hell»). Au fil du temps, Windows est devenu multi-utilisateur, nécessitant la séparation des répertoires utilisateur des répertoires système. Windows a également créé un emplacement central pour les fichiers de configuration (Unix /etc) et certaines données système (Unix/var), le registre. Il s'agit davantage d'un artefact historique en grande partie dû au manque de gestion des packages et aux débuts de l'histoire en tant que système mono-utilisateur. L'approche Windows a de nombreuses limites: elle ne permet pas aux packages logiciels d'interagir facilement. Par exemple, la plupart des logiciels installés ne se retrouvent pas sur le chemin de recherche de commandes par défaut, ils interagissent donc mal avec toute forme de script. Les installateurs fournissent généralement une icône de menu dans un cas spécial - déposée dans un répertoire système distinct (à la Unix!).
Une limitation de l'approche Unix est qu'elle ne permet pas facilement la coexistence de plusieurs versions d'un package, ce qui est particulièrement problématique lors de la mise à niveau du package. Un moyen de tirer le meilleur parti des deux mondes serait de décompresser chaque package dans son propre répertoire (une /optstructure) et de créer des forêts de liens symboliques des répertoires des packages vers une /usrstructure. C'est ce que fait un logiciel comme stow .
En résumé, l'approche Unix facilite l'utilisation des fichiers, la gestion des fichiers et l'interaction des packages; il nécessite un logiciel de gestion de paquets, mais c'est quand même souhaitable. L'approche Windows facilite la gestion manuelle des packages, mais doit virer vers le modèle Unix pour obtenir des fonctionnalités utiles.