Quelles sont les alternatives à la FHS?

Tout d'abord, un avertissement de conflit d'intérêts initial: Je suis un développeur GoboLinux de longue date.

Deuxièmement, une revendication d'expertise de domaine: je suis un développeur GoboLinux de longue date.

Il y a quelques structures différentes en usage courant. GoboLinux en a un, et des outils comme GNU Stow , Homebrew , etc., utilisent quelque chose de très similaire (principalement pour les programmes user). NixOS utilise également une hiérarchie non standard pour les programmes et la philosophie de la vie. C'est aussi une expérience LFS raisonnablement commune.

Je vais décrire tous ces éléments, puis commenter l'expérience sur la façon dont cela se déroule dans la pratique («faisabilité»). La réponse courte est que oui, c'est faisable, mais vous devez vraiment le vouloir .

GoboLinux

GoboLinux a une structure très similaire à ce que vous décrivez. Le logiciel est installé sous /Programs : /Programs/ZSH/5.0.8 contient tous les files appartenant à ZSH 5.0.8, dans les directorys habituels bin / lib / …. Les outils système créent des liens symboliques vers ces files sous une hiérarchie /System/Links , qui se connecte à /usr ¹. La variable PATH contient uniquement le seul directory exécutable unifié et LD_LIBRARY_PATH n'est pas utilisé. Plusieurs versions de logiciels peuvent coexister simultanément, mais un seul file par un nom donné ( bin/zsh ) sera lié en même time. Vous pouvez accéder aux autres par leurs paths complets.

Un set de liens symboliques de compatibilité existe également, donc /bin et /usr/bin mappent vers le directory des exécutables unifiés, etc. Cela facilite la vie du logiciel lors de l'exécution. Un patch de kernel, GoboHide, permet à ces liens symboliques de compatibilité d'être cachés des lists de files (mais toujours traversable).

Contre une autre réponse, vous n'avez pas besoin de modifier le code du kernel: GoboHide est purement cosmétique, et le kernel ne dépend pas des paths de l'espace user en général². GoboLinux possède un système d'initialisation sur mesure, mais ce n'est pas non plus nécessaire.

Le slogan a toujours été «le système de files est le gestionnaire de packages», mais il existe des outils de gestion de packages raisonnablement ordinaires dans le système. Vous pouvez tout faire en utilisant cp , rm et ln , cependant.

Si vous voulez utiliser GoboLinux, vous êtes les bienvenus. Je noterai cependant qu'il s'agit d'une petite équipe de développement et que vous constaterez probablement que certains logiciels que vous voulez ne sont pas emballés si personne n'a voulu l'utiliser auparavant. Les bonnes nouvelles sont qu'il est généralement assez facile de build un programme pour le système (une «recette» standard est d'environ trois lignes); les mauvaises nouvelles sont que parfois c'est compliqué désagréablement, que je couvrirai plus en bas.

Publications

Il y a quelques "publications". J'ai fait une présentation à linux.conf.au 2010 sur le système dans son set qui couvre tout ce qui est généralement disponible en video: ogv mp4 (également sur votre miroir Linux Australia local); J'ai aussi écrit mes notes en prose. Il y a aussi quelques documents plus anciens, dont le fameux « Je ne suis pas dépourvu de sens », sur le site GoboLinux , qui aborde quelques objections et problèmes. Je pense que nous sums tous un peu less gung-ho ces jours-ci, et je soupçonne qu'une version future adoptera /usr comme location de base pour les liens symboliques.

NixOS

NixOS place chaque programme installé dans son propre directory sous /nix/store . Ces directorys sont nommés comme /nix/store/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-firefox-3.5.4/ – il y a un hachage cryptographique représentant l'set des dependencies et la configuration menant à ce programme. A l'intérieur de ce directory sont tous les files associés, avec des localizations plus ou less normales localement.

Il vous permet également d'avoir plusieurs versions à la fois, et d'utiliser l'un d'entre eux. NixOS a toute une philosophie associée à la configuration reproductible: il a essentiellement un système de gestion de configuration cuit depuis le début. Il s'appuie sur une manipulation environnementale pour présenter le bon monde de programmes installés à l'user.

LFS

Il est assez simple de passer par Linux From Scratch et de configurer exactement la hiérarchie souhaitée: il suffit de créer les directorys et de tout configurer pour l'installer au bon endroit. Je l'ai fait plusieurs fois dans la construction d'expériences GoboLinux, et ce n'est pas beaucoup plus difficile que le LFS ordinaire. Vous devez faire les liens symboliques de compatibilité dans ce cas; sinon il est sensiblement plus difficile, mais l'utilisation prudente des montures de l'union pourrait probablement éviter cela si vous le vouliez vraiment.

Je pense qu'il y a eu un indice LFS à propos de cela à un moment donné, mais je n'arrive pas à le find maintenant.

Sur la faisabilité

La chose au sujet de la FHS est que c'est une norme, c'est très commun, et cela reflète largement l'usage existant au moment où il a été écrit. La plupart des users ne seront jamais sur un système qui ne suit pas cette disposition dans son essence. Le résultat de cela est que beaucoup de logiciels ont des dependencies latentes que personne ne réalise, souvent complètement involontairement.

Tous ces scripts avec #!/bin/bash ? Pas bon si vous n'avez pas Bash là. C'est pourquoi GoboLinux a tous ces liens symboliques de compatibilité; c'est juste pratique. Un grand nombre de logiciels ne fonctionnent pas au moment de la construction ou au moment de l'exécution sous une layout non standard, puis nécessitent un correctif pour corriger, souvent de manière assez intrusive.

Votre programme de base Autoconf s'installera volontiers partout où vous le direz, et il est assez facile d'automatiser le process de transmission du bon --prefix . D'autres systèmes de construction ne sont pas toujours aussi agréables, soit en cochant intentionnellement la hiérarchie, soit en incitant les auteurs à écrire une configuration non portable. CMake est un délinquant majeur dans cette dernière catégorie. Cela signifie que si vous voulez vivre dans ce monde, vous devez être prêt à faire beaucoup de travail fastidieux à l'avant dans les systèmes de construction d'autres personnes. C'est un vrai problème de devoir patcher dynamicment les files générés lors de la compilation.

Le time d'exécution est une autre question à nouveau. De nombreux programmes ont des hypothèses sur l'location de leurs propres files ou des files de quelqu'un d'autre par rapport à eux ou absolument. Lorsque vous commencez à utiliser des liens symboliques pour présenter une vue cohérente, de nombreux programmes ont des bogues qui les manipulent (ou, parfois, un comportement correct qui ne vous aide pas). Par exemple, un outil foobar peut s'attendre à find l'exécutable baz côté d'elle, ou dans ../sbin . Selon qu'il lit ou non son lien symbolique, ceux-ci peuvent être deux endroits différents, et aucun d'eux ne peut être correct de toute façon.

Un problème combiné est le /usr/share . C'est pour les files partagés, bien sûr, mais quand vous placez chaque programme dans son propre préfixe, ils ne sont plus réellement partagés. Cela conduit à des programmes incapables de find des icons standard et autres. GoboLinux a traité cela d'une manière assez laide: au moment de la construction, $prefix/share était un lien symbolique vers $prefix/Shared , et après la construction, le lien était dirigé vers le directory de share global. Il utilise maintenant le sandboxing à la compilation et le déplacement de files pour gérer le share (et les autres directorys), mais les erreurs d'exécution liées à la lecture des liens peuvent toujours poser problème.

Suites de plusieurs programmes sont un autre problème. GoboLinux n'a jamais permis à GNOME de fonctionner pleinement, et je ne crois pas non plus que NixOS en soit, parce que les interdependencies de la layout sont tellement cuites qu'il est tout simplement impossible de les guérir.

Donc, oui, c'est faisable , mais:

• Il y a beaucoup de travail à faire pour que les choses fonctionnent.
• Certains logiciels peuvent ne jamais fonctionner.
• Les gens vont vous regarder drôle.

Tous ceux-ci peuvent ou ne peuvent pas être un problème pour vous.

¹ La version 14.01 utilise /System/Index , qui mappe directement sur /usr . Je soupçonne qu'une version future pourrait supprimer la hiérarchie des liens / index et utiliser /usr travers le tableau.

² Il nécessite /bin/sh pour exister par défaut.

vérifiez le GoboLinux .

si vous voulez modifier la structure du directory, vous devez modifier le code du kernel, le process de démarrage, les niveaux d'exécution des directorys basés sur les files rc et le gestionnaire de packages, puis la structure du directory.

GoboLinux (que F.sb a mentionné) et GNU guix sont des dissortingbutions qui utilisent une structure de directory par package avec des liens symboliques pour pointer vers la version «actuelle» d'un binary.

GoboLinux semble être le meilleur pari si vous voulez un système stable. GNU Guix dit explicitement qu'il n'est pas encore prêt pour la production. GoboLinux existe depuis des années. Je n'ai jamais essayé moi-même.

Linux FHS est basé sur ce que Sun et d'autres entresockets UNIX ont décidé à la fin des années 80.

Un changement important à l'époque était d'abandonner /usr/local/ et d'introduire /opt/ / { bin ! lib ! man ! …}

Si vous cherchez la raison pour laquelle / usr / bin est aujourd'hui utilisé comme dépotoir, je pense que GNOME est l'un des projets les plus responsables.

Ce qui est arrivé avec les bibliothèques 32 bits par rapport aux 64 bits semble être causé par FHS.

Solaris a introduit des sous-directorys spécifiques à la plate-forme dans /lib /usr/bin et /usr/lib . Votre souhait est de savoir comment Sun a amélioré le concept de base à partir de 1988.

Si chaque package avait sa propre partie du système de files, vous auriez besoin de variables d'environnement extrêmement volumineuses et lourdes PATH , LD_LIBRARY_PATH et similaires.

Vous pouvez bien sûr installer les packages vous-même de cette façon, puis utiliser quelque chose comme les modules GNU pour gérer s'ils sont dans votre environnement ou pas, et c'est ce que nous faisons pour les logiciels scientifiques où je travaille, mais nous ne le faisons pas pour logiciel système.