¿Cuál es la razón de ser del directorio '/ usr'?

88

¿Cuál es la razón de ser de los "recursos del sistema Unix" o del directorio /usr , como se describe aquí , que duplica muchos de los nombres de directorio en el directorio raíz / ?

Mi propósito: estoy instalando Oracle JDK por enésima vez y esta vez lo dejé en /home/user y estoy leyendo un poco para ver si es una mala idea en una sola máquina de usuario .

    
pregunta H2ONaCl 02.05.2012 - 18:46

1 respuesta

135

Están la versión corta y la versión larga de tu respuesta ...

Versión corta:

Como su enlace ya dijo, /usr es un lugar para todo el sistema , archivos de solo lectura . Entonces, todo su software instalado va allí. No duplica ningún nombre de / excepto /bin y /lib , pero, originalmente, con un propósito diferente: /bin, /lib es solo para binarios y bibliotecas requeridas para arrancar , mientras que /usr/bin, /usr/lib es para todos los demás ejecutables y bibliotecas. (ahora sé un buen chico y no preguntes por /sbin , esta es la versión corta después de todo)

Hoy en día, la distinción entre "requerido para el arranque" ha disminuido, ya que la mayoría de las distribuciones modernas, incluida Ubuntu, no pueden arrancar correctamente sin varios archivos de /usr . Y es por eso que hay un fuerte movimiento hacia la fusión de /usr/bin y /bin , por lo que probablemente en el futuro cercano (¿Ubuntu 12.10 quizás?)% Co_de% será un enlace simbólico a /bin .

¿Pero tal vez estás confundiendo /usr/bin y /usr ? Porque sí, hay (y debería haber) un lote de nombres de directorio duplicados. Más sobre eso más tarde ...

Versión larga:

En los años 70, en Unix (sí, Unix, mucho antes de Linux), los disquetes tenían poco espacio (no HD, ¿recuerdas?) y en un punto dado los binarios del sistema crecían demasiado en número y tamaño a un punto no cabían en un solo disco, y los desarrolladores tenían que dividirlos en varios medios y así crear nuevos puntos de montaje para ellos. /usr/local filesystem estaba lleno, por lo que instalaron los nuevos binarios en ... /bin . Y /usr/bin era, en ese momento, su ... usuario directorio!

Después de que ocurriera la división (casi vergonzosa y a menudo contada como una broma / saber), comenzaron a crear justificaciones (y criterios) "artificiales" para decidir qué pasaría a /usr y qué pasaría a /bin . La regla informal era: cosas "esenciales" van a /usr/bin , "el resto" va a /bin . Lo mismo con /usr/bin . No pasó mucho tiempo antes de que /lib se llenara de directorios relacionados con el sistema, mezclados con user-dirs. Así nació /usr , para mantener todos los directorios relacionados con el usuario y mantener /home limpio para el sistema "cosas" solamente.

Esto fue mucho antes de que existiera FHS. Cuando se creó, adoptó (y formalizó) la tradición actual y mantuvo el nombre /usr , aunque en ese momento ya no tenía nada que ver con "usuario". Así que sí, los nombres sofisticados " U NIX s hacen r epository" o " U NIX s sistema r recursos son todos nombres inventados, y es demasiado tarde para cambiarle el nombre de todos modos. (pero no es demasiado tarde para fusionar /usr con él)

"Ok, ¿qué pasa con /bin ?" , preguntas. Maldita sea, esperaba que lo hubieras olvidado. Ok ... /usr/sbin es para comandos que solo pueden ser (o solo son significativos cuando) ejecutados por el usuario /usr/sbin , como root y mount .

"¿Pero no es casi lo mismo que fdisk ?" . Sí, claro, pero ...

"Espera, ¿por qué hay un /bin también? ¡No tiene sentido!" . Bueno, eso es por ... err .. humm ..

¡Mira, un mono de 3 cabezas detrás de ti!

Bien, con suerte, te distrajeras lo suficiente. Avanzando ...

(si crees que estoy haciendo trampa, sí, estás en lo cierto. Pero la respuesta "oficial" también es "comandos esenciales que solo pueden ejecutarse por root y deben estar disponibles incluso antes de montar /sbin "). La verdad es que la línea es realmente borrosa, y hay muchos nombres heredados que simplemente "se estancaron" y ahora es bastante difícil deshacerse de ellos.

Más información sobre el caso del / merge , del /usr docs:

  

La justificación histórica para / bin, / sbin y / lib separada de / usr ya no se aplica hoy. Se dividieron para tener herramientas seleccionadas en un disco duro más rápido (que era pequeño, porque era más caro) y para contener todas las herramientas necesarias para montar la partición / usr más lenta. En la actualidad, el initramfs ya debe montar una partición / usr separada durante el inicio temprano, lo que justifica un debate discutible. Además, muchas herramientas en / bin y / sbin en el status quo ya perdieron la capacidad de ejecutarse sin un / usr preinstalado. Ya no hay una razón válida para que el sistema operativo se extienda por múltiples jerarquías, perdió su propósito.

Y una lectura sorprendente sobre la división systemd y su razón de ser, por Rob Landley:

Comprender bin, sbin, usr / bin, usr / sbin split

Hoy en día

Actualmente, con respecto a los directorios de instalación, su mejor forma de entender es pensar de esta manera:

  • /usr - todos los archivos de solo lectura del sistema instalados por (o provistos por) el sistema operativo

  • /usr - archivos de solo lectura y de todo el sistema instalados por el administrador local (generalmente, usted). Y es por eso que la mayoría de los nombres de directorio de /usr/local están duplicados aquí.

  • /usr - una atrocidad destinada a software para todo el sistema, de solo lectura y autónomo . Es decir, el software que no divide sus archivos en /opt , bin , lib , share como software de buen comportamiento debería.

  • include - la contraparte por usuario de ~/.local , es decir: software instalado por (y para) cada usuario

  • /usr/local - la contraparte por usuario de ~/.local/opt

Entonces, ¿dónde instalar el software?

La lista anterior ya es la mitad de la respuesta de tu pregunta Oracle JDK, al menos da varias pistas. La lista de verificación para "¿Dónde debo instalar el software X?" pasa:

  • ¿Es un software de directorio único completamente autónomo, como Eclipse IDE y otras aplicaciones java descargadas, y desea que esté disponible para todos los usuarios? Luego instálelo en /opt

  • Igual que el anterior, ¿pero no le importan los demás usuarios y solo quiero instalarlo para su usuario? Luego instálelo en /opt

  • ¿Sus archivos se dividen en varios directorios, como ~/.local/opt y bin , como el software tradicional compilado e instalado con share , y deberían estar disponibles para todos los usuarios? Luego instálelo en ./configure && make && sudo make install

  • Igual que arriba, pero solo para su usuario? Luego instálelo en /usr/local

  • Software instalado por el sistema operativo, o a través de gestores de paquetes (como Software Center) y, lo que es más importante, que cualquier modificación local puede sobreescribirse cuando el administrador de actualizaciones la actualice a una nueva versión ? Va a ~/.local

Notas:

  • Esto explica por qué el prefijo de instalación predeterminado para el software compilado es /usr , y por qué debería cambiarlo a /usr/local al instalar software solo para su propio usuario

  • Puede haber notado que todos los directorios anteriores son de solo lectura (excepto, por supuesto, cuando instala / quita el software). Los archivos modificables (como los archivos de configuración) generalmente van a ./configure --prefix=$HOME/.local (para software de todo el sistema) y /etc (para configuraciones por usuario). Aunque muchos programas heredados (y, desafortunadamente, también algunos modernos) usan ~/.config , saturan su carpeta de inicio con miles de millones de directorios y archivos.

  • ~/.<software-name> y ~/.local no son parte de la especificación FHS. FHS no se ocupa de la carpeta de inicio del usuario. Son un intento de XDG, otra organización estándar orientada a entornos de escritorio (como Gnome, KDE y Unity), para tratar de establecer algunas convenciones con respecto a la estructura del hogar del usuario. No todo el software se adhiere a él (por ejemplo, ~/.config no está en el ~/.local/bin predeterminado del usuario, mientras que lógicamente debería) , y ningún usuario está obligado a seguirlo, pero ambos ganan muchos beneficios de interoperabilidad si lo hacen.

Espero que esto ayude a aclarar un poco las cosas. ¡No dude en preguntar cualquier cosa para que pueda mejorar la respuesta!

(y también espero que los puristas no me maten por un lenguaje y una explicación tan informal. Fue intencional, y seguramente tiene muchas imprecisiones, pero creo que es una buena manera de hacer un recién llegado tiene una breve descripción general sobre la racionalización de los directorios de instalación)

    
respondido por el MestreLion 11.05.2012 - 22:49

Lea otras preguntas en las etiquetas