Primero, un descargo de responsabilidad por adelantado sobre conflictos de interés: soy un desarrollador de GoboLinux desde hace mucho tiempo.
En segundo lugar, un reclamo inicial de experiencia en el dominio: soy un desarrollador de GoboLinux desde hace mucho tiempo.
Hay algunas estructuras diferentes en el uso actual. GoboLinux tiene uno, y herramientas como GNU Stow , Homebrew , etc., usan algo bastante similar (principalmente para programas de usuario). NixOS también utiliza una jerarquía no estándar para programas y filosofía de vida. También es un experimento LFS razonablemente común.
Voy a describir todo eso y luego comentaré por experiencia cómo funciona en la práctica ("factibilidad"). La respuesta corta es que sí, es factible, pero realmente debes desearlo .
GoboLinux
GoboLinux tiene una estructura muy similar a la que usted describe. El software se instala en /Programs: /Programs/ZSH/5.0.8contiene todos los archivos que pertenecen a ZSH 5.0.8, en los directorios habituales bin/ lib/ ... Las herramientas del sistema crean enlaces simbólicos a esos archivos bajo una /System/Linksjerarquía, que se asigna a /usr¹. La PATHvariable contiene solo el directorio ejecutable unificado único y LD_LIBRARY_PATHno se utiliza. Pueden coexistir varias versiones de software a la vez, pero solo un archivo con un nombre de pila ( bin/zsh) se vinculará activamente a la vez. Puede acceder a los demás por sus caminos completos.
También existe una serie de enlaces simbólicos de compatibilidad, por lo que /biny /usr/binasignar al directorio de archivos ejecutables unificado, y así sucesivamente. Esto facilita la vida del software en tiempo de ejecución. Un parche del kernel, GoboHide, permite que esos enlaces simbólicos de compatibilidad se oculten de las listas de archivos (pero aún se puedan atravesar).
Contra otra respuesta, no necesita modificar el código del kernel: GoboHide es puramente cosmético y el kernel no depende de las rutas de espacio de usuario en general². GoboLinux tiene un sistema de inicio a medida, pero tampoco es necesario hacerlo.
El lema siempre ha sido "el sistema de archivos es el administrador de paquetes", pero hay herramientas de administración de paquetes razonablemente ordinarias en el sistema. Usted puede hacer todo el uso cp, rmy ln, sin embargo.
Si quieres usar GoboLinux, eres bienvenido. Sin embargo, notaré que se trata de un pequeño equipo de desarrollo, y es probable que descubras que parte del software que deseas no está empaquetado si nadie ha querido usarlo antes. La buena noticia es que generalmente es bastante fácil crear un programa para el sistema (una "receta" estándar tiene aproximadamente tres líneas de largo); La mala noticia es que a veces es desagradablemente complicado, que cubriré más a continuación.
Publicaciones
Hay algunas "publicaciones". Realicé una presentación en linux.conf.au 2010 sobre el sistema en su conjunto que cubre todo en general, que está disponible en video: ogv mp4 (también en su espejo local de Linux Australia); También escribí mis notas en prosa. También hay algunos documentos más antiguos, incluido el famoso " No tengo ni idea ", en el sitio web de GoboLinux , que aborda algunas objeciones y problemas. Creo que todos estamos un poco menos entusiastas en estos días, y sospecho que una versión futura se adoptará /usrcomo la ubicación base para los enlaces simbólicos.
NixOS
NixOS coloca cada programa instalado en su propio directorio /nix/store. Esos directorios se denominan algo así /nix/store/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-firefox-3.5.4/: hay un hash criptográfico que representa todo el conjunto de dependencias y configuraciones que conducen a ese programa. Dentro de ese directorio están todos los archivos asociados, con ubicaciones más o menos normales a nivel local.
También le permite tener varias versiones a la vez y usar cualquiera de ellas. NixOS tiene toda una filosofía asociada con la configuración reproducible: esencialmente tiene un sistema de gestión de configuración integrado desde el principio. Se basa en alguna manipulación ambiental para presentar el mundo correcto de los programas instalados al usuario.
LFS
Es bastante sencillo pasar por Linux From Scratch y configurar exactamente la jerarquía que desea: simplemente haga los directorios y configure todo para instalar en el lugar correcto. Lo he hecho varias veces al construir experimentos de GoboLinux, y no es sustancialmente más difícil que el LFS simple. Necesitas hacer los enlaces simbólicos de compatibilidad en ese caso; de lo contrario es sustancialmente más difícil, pero el uso cuidadoso de los montajes de unión probablemente podría evitarlo si realmente lo desea.
Siento que hubo una pista de LFS sobre exactamente eso en un punto, pero parece que no puedo encontrarlo ahora.
Sobre la viabilidad
Lo que pasa con el FHS es que es un estándar, es muy común y refleja ampliamente el uso existente en el momento en que se escribió. La mayoría de los usuarios nunca estarán en un sistema que no siga ese diseño en esencia. El resultado de eso es que gran parte del software tiene dependencias latentes de él que nadie se da cuenta, a menudo sin querer.
¿Todos esos guiones con #!/bin/bash? No es bueno si no tienes Bash allí. Es por eso que GoboLinux tiene todos esos enlaces simbólicos de compatibilidad; Es solo práctico. Una gran cantidad de software no funciona en tiempo de compilación o en tiempo de ejecución en un diseño no estándar, y luego requiere parches para corregir, a menudo de manera bastante intrusiva.
Su programa básico de Autoconf generalmente se instalará felizmente donde lo diga, y es bastante fácil automatizar el proceso de pasarlo correctamente --prefix. Otros sistemas de compilación no siempre son tan agradables, ya sea al hornear intencionalmente en la jerarquía o por autores líderes para escribir configuraciones no portátiles. CMake es un delincuente importante en la última categoría. Eso significa que si quieres vivir en este mundo tienes que estar preparado para hacer mucho trabajo por adelantado en los sistemas de construcción de otras personas. Es una verdadera molestia tener que parchear dinámicamente los archivos generados durante la compilación.
El tiempo de ejecución es otra cosa otra vez. Muchos programas tienen suposiciones sobre dónde se encuentran sus propios archivos, o los archivos de otra persona, ya sea en relación con ellos o absolutamente. Cuando comienzas a usar enlaces simbólicos para presentar una vista consistente, muchos programas tienen errores que los manejan (o, a veces, posiblemente un comportamiento correcto que no es útil para ti). Por ejemplo, una herramienta foobarpuede esperar encontrar el bazejecutable al lado, o en ../sbin. Dependiendo de si lee o no su enlace simbólico, esos pueden ser dos lugares diferentes, y ninguno de ellos puede ser correcto de todos modos.
Un problema combinado es el /usr/sharedirectorio. Es para archivos compartidos, por supuesto, pero cuando pones cada programa en su propio prefijo, ya no se comparten. Eso lleva a que los programas no puedan encontrar iconos estándar y similares. GoboLinux se ocupó de esto de una manera bastante fea: en el momento de la compilación, $prefix/shareera un enlace simbólico y $prefix/Shared, después de compilar, el enlace apuntaba al sharedirectorio global . Ahora utiliza el sandboxing en tiempo de compilación y el movimiento de archivos para tratar share(y los otros directorios), pero los errores de tiempo de ejecución de los enlaces de lectura aún pueden ser un problema.
Las suites de múltiples programas son otro problema. GoboLinux nunca ha conseguido que GNOME funcione por completo, y tampoco creo que NixOS lo haya hecho, porque las interdependencias de diseño son tan complicadas que es intratable curarlas a todas.
Entonces, sí, es factible , pero:
- Hay mucho trabajo involucrado en hacer que las cosas funcionen.
- Es posible que algunos programas nunca funcionen.
- La gente te mirará divertido.
Todo eso puede o no ser un problema para usted.
Uses Utiliza la versión 14.01 /System/Index, que se asigna directamente a /usr. Sospecho que una versión futura puede eliminar la jerarquía de Enlaces / Índice y usarla en /usrtodos los ámbitos.
² Requiere /bin/shexistir por defecto.