Soy un usuario de Linux desde hace mucho tiempo durante más de 15 años, pero una cosa que odio con pasión es la estructura de directorios obligatoria. No me gusta que /usr/bines el vertedero de los binarios o librerías en /usr/lib, /usr/lib32, /usr/libx32, /lib, /lib32etc ... cosas azar /usr/share, etc Es mudo y confuso. Pero a algunos les gusta y los gustos difieren.
Quiero una estructura de directorio donde cada paquete esté aislado. Imagine, en cambio, si el dragón del reproductor multimedia tuviera su propia estructura:
/software/dragon
/software/dragon/bin/x86/dragon
/software/dragon/doc/README
/software/dragon/doc/copyright
/software/dragon/lib/x86/libdragon.so
O:
/software/zlib/include/zlib.h
/software/zlib/lib/1.2.8/x86/libz.so
/software/zlib/lib/1.2.8/x64/libz.so
/software/zlib/doc/examples/...
/software/zlib/man/...
Tú entiendes. ¿Cuáles son mis opciones? ¿Hay alguna distribución de Linux que use algo como mi esquema? ¿Se puede modificar alguna distribución para que funcione como lo quiero (Gentoo ??) o necesito LFS? ¿Existe alguna técnica anterior en esta área? ¿Le gustan las publicaciones sobre si el esquema es factible o inviable?
No busco OS X. :) Pero inspirado en OS X está totalmente bien.
Editar : No tengo idea de cómo PATH, LD_LIBRARY_PATHy otras variables de entorno que dependen de un pequeño conjunto de rutas deberían funcionar. Estoy pensando que si tengo instalado el editor de KDE Kate,/software/kate/bin/x86/bin/kate entonces estoy de acuerdo con tener que escribir la ruta completa al binario para iniciarlo. Cómo debería funcionar para bibliotecas dinámicas y dlopenllamadas, no lo sé, pero no puede ser un problema de ingeniería sin solución.
fuente
/softwaresolo lectura, para obtener los mismos beneficios e inconvenientes que hacer/usrsolo lectura en FHS.Respuestas:
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 habitualesbin/lib/ ... Las herramientas del sistema crean enlaces simbólicos a esos archivos bajo una/System/Linksjerarquía, que se asigna a/usr¹. LaPATHvariable contiene solo el directorio ejecutable unificado único yLD_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,rmyln, 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 elbazejecutable 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 alsharedirectorio global . Ahora utiliza el sandboxing en tiempo de compilación y el movimiento de archivos para tratarshare(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:
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.fuente
Tanto GoboLinux (que mencionó F.sb) como GNU guix son distribuciones que usan una estructura de directorio por paquete junto con enlaces simbólicos para apuntar a la versión "actual" de un binario.
GoboLinux parece ser la mejor apuesta si quieres un sistema estable. GNU guix dice explícitamente que aún no está listo para la producción. GoboLinux ha existido por años. Yo tampoco lo he intentado nunca.
fuente
revisa el GoboLinux .
si desea que se modifique la estructura del directorio, debe cambiar el código del kernel, el proceso de arranque, los niveles de ejecución del directorio basados en archivos rc y el administrador de paquetes, luego la estructura del directorio.
fuente
Linux FHS se basa en lo que Sun y otras compañías de UNIX decidieron a fines de la década de 1980.
Un cambio importante en ese momento fue abandonar
/usr/local/e introducir/opt// {bin!lib!man! ...}Si está buscando la razón por la cual / usr / bin se usa hoy como vertedero, creo que GNOME es uno de los proyectos más responsables.
Lo que sucedió con las bibliotecas de 32 bits frente a 64 bits parece ser causado por FHS.
Solaris introdujo subdirectorios específicos de plataforma en
/lib/usr/biny/usr/lib. Desee cómo Sun mejoró el concepto base a partir de 1988.fuente
Si cada paquete tuviera su propia parte del sistema de archivos, necesitaría variables de entorno extremadamente grandes y difíciles de manejar
PATH,LD_LIBRARY_PATHy similares.Por supuesto, puede instalar paquetes usted mismo de esta manera, y luego usar algo como Módulos GNU para administrar si están en su entorno o no, y esto es lo que hacemos para el software científico donde trabajo, pero no lo hacemos para software del sistema.
fuente