¿Cuál es el beneficio de la forma en que Linux organiza los archivos de los programas instalados? [cerrado]

En Windows, la unidad del sistema C:tiene un directorio program_files, bajo el cual cada programa tiene su propio directorio.

En Linux, debajo /usr/y /usr/local/, hay /bin, /etc, /share, /src, etc.

Entonces, en Windows, todos los archivos de cada programa se agrupan en el mismo directorio, mientras que en Linux, los archivos del mismo tipo de todos los programas.

Creo que la forma en que Windows organiza los programas instalados es más lógica que la forma de Linux, y por lo tanto, los programas instalados son más fáciles de administrar manualmente.

¿Cuál es el beneficio de la forma en que Linux organiza los archivos de los programas instalados? Gracias.

Tengo esta pregunta cuando tengo el problema de ¿Cómo organizar los programas instalados en $ HOME para que Shell los busque cuando los ejecuta? , donde trato de organizar mis programas en $HOMEla forma de Windows, pero tengo algún problema para especificar las rutas de búsqueda de los programas.

En Linux, las diferentes ubicaciones generalmente, cuando se mantienen bien, reflejan cierta lógica. P.ej.:

• /bin contiene las herramientas más básicas (programas)
• /sbin contiene los programas administrativos más básicos

Ambos contienen los comandos elementales utilizados por el arranque y la resolución de problemas fundamentales. Y aquí ves la primera diferencia. Algunos programas no están destinados a ser utilizados por usuarios habituales.

Entonces echa un vistazo /usr/bin. Aquí debería encontrar una mayor selección de comandos (programas), generalmente más de 1000 de ellos. Son herramientas estándar, pero no tan esenciales como las de /biny /sbin.

/usr/bincontiene los comandos, mientras que los archivos de configuración residen en otro lugar. Esto separa las entidades funcionales (programas) y su configuración y otros archivos, pero en términos de funcionalidad del usuario, esto es útil, ya que tener los comandos no entremezclados con nada más permite el uso simple de la PATHvariable que apunta a los ejecutables. También introduce claridad. Lo que sea debe ser ejecutable.

Echar un vistazo a mi PATH,

$ echo "$PATH" | perl -F: -anlE'$,="\n"; say @F'
/home/tomas/bin
/usr/local/bin
/usr/bin
/bin
/usr/local/games
/usr/games

Hay exactamente seis ubicaciones que contienen los comandos que puedo llamar directamente (es decir, no por sus rutas, sino por los nombres de sus ejecutables).

• /home/tomas/bin es mi directorio privado en mi carpeta de inicio para mis ejecutables privados.
• /usr/local/bin Explicaré por separado a continuación.
• /usr/bin se describe arriba.
• /bin También se describe arriba.
• /usr/local/gameses una combinación de /usr/local(que se explicará a continuación) y juegos
• /usr/gamesSon juegos. No deben mezclarse con ejecutables de utilidad, tienen sus ubicaciones separadas.

Ahora a /usr/local/bin. Este es algo resbaladizo, y ya se explicó aquí: ¿Qué es / usr / local / bin? . Para comprenderlo, debe saber que la carpeta /usrpuede ser compartida por muchas máquinas y montada desde una ubicación de red. Los comandos allí no son necesarios en el arranque, como se señaló anteriormente, a diferencia de los que se encuentran allí /bin, por lo que la ubicación se puede montar en etapas posteriores del proceso de arranque. También se puede montar de forma de solo lectura. /usr/local/bin, por otro lado, es para los programas instalados localmente y debe poder escribirse. Entonces, si bien muchas máquinas de red pueden compartir el /usrdirectorio general , cada una de ellas tendrá su propia /usr/localmontada dentro del común /usr.

Finalmente, eche un vistazo a PATHmi usuario root:

# echo "$PATH" | perl -F: -anlE'$,="\n"; say @F'
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/bin

Contiene estos:

• /usr/local/sbin, que contiene los comandos de administrador del tipo /usr/local
• /usr/local/bin, que son las mismas que puede usar el usuario habitual. Nuevamente, su tipo se puede describir como /usr/local.
• /usr/sbin son las utilidades administrativas no esenciales.
• /usr/bin son la administración no esencial y las utilidades de usuario habituales.
• /sbin son las herramientas administrativas esenciales.
• /bin son las herramientas esenciales de administrador y usuario habitual.

En la actualidad, creo que esta es una herencia histórica del clásico UNIX.

En las primeras versiones de UNIX, los programas no eran tan grandes como en la actualidad. Los programas a menudo consistían en un archivo ejecutable que usaba bibliotecas del sistema. Entonces, nadie pensó en programas que consistirían en un par de bibliotecas propias. La biblioteca principal era la biblioteca C y cada programa conocía su ubicación.

Además, el entorno UNIX se consideraba como producto terminado (para preparar la documentación). Por lo tanto, las rutas de acceso a todas las herramientas fueron corregidas

Algunos de los beneficios de las rutas fijas en los días de HDD (unidad de disco duro) están presentes en la actualidad. Si FSH (Jerarquía del sistema de archivos) se divide en particiones de disco separadas y coloca particiones con binarios y bibliotecas cerca de los sectores primarios de HDD, el tiempo de inicio del programa será un poco más rápido.

Lo que ves como un sistema moderno similar a Unix no es realmente tradicional.

Normalmente, no sería bastante mínima /y /usrjerarquías con las utilidades del sistema justo, y los programas se instalan por separado en un subdirectorio de /usr/local, y luego puesto a disposición mediante la creación de enlaces simbólicos.

Una configuración muy típica para el software GNU era compilar e instalar con

./configure
make
make install prefix=/usr/local/DIR/program-1
cd /usr/local/DIR
stow program-1

La utilidad de almacenamiento de GNU crea enlaces simbólicos para hacer que el software esté disponible en la ruta estándar, sin tener que agregar ningún directorio a la variable PATH (como lo hace Windows, y cruft tiende a acumularse allí).

Sin embargo, las distribuciones modernas de Linux envían todo como paquetes preparados, por lo que los programas se han convertido en parte del "sistema". Debido a que el administrador de paquetes se encarga de la instalación, no hay necesidad de enlaces simbólicos, y la separación de programas no sirve para ningún propósito útil (pero ralentizaría el inicio del programa ya que tendrían que escanearse muchos directorios pequeños).

Si desea instalar software en su directorio de inicio, le sugiero que use GNU stow también para eso, esto le permitirá mantener sus programas separados, lo cual es sensato si no está usando un administrador de paquetes.

Mi configuración tradicional para eso es un directorio en el ~/software/DIRque instalo programas, luego uso stow inside DIRpara crear ~/software/bin, ~/software/shareetc. Esto significa que solo tengo que agregar ~/software/bina la variable PATH para obtener todo mi software instalado.

Utilizar:

./configure --prefix=~/software
make
make install prefix=~/software/DIR/program-1
cd ~/software/DIR
stow program-1

instalar si el programa sigue las convenciones de GNU.

Parece estar hablando del estilo de dividir archivos individuales por propósito ( /usr/binpara ejecutables, /usr/libpara bibliotecas) en lugar de por paquete de aplicación (compilador de C ++ en un directorio, programas de edición de imágenes en otro). Mientras que en los sistemas Unix, la razón de este histórico es importante, también hay fuerzas actuales que tienden a hacer que los sistemas tipo Unix se inclinen hacia esto: los administradores de paquetes que administran la mayoría de los programas en un sistema.

En Windows, históricamente y todavía bastante, las aplicaciones han sido responsables de proporcionar su propio instalador y, especialmente, el desinstalador, e incluso ahora con frecuencia no se registran en ninguna lista central de aplicaciones. En una situación como esta, generalmente es mejor que una aplicación tenga su "propio" directorio para tantos archivos como sea posible. Esto ayuda a evitar conflictos con otras aplicaciones, aunque esto no siempre funciona (especialmente en el caso de las DLL ).

Los sistemas Unix, por otro lado, desde los años 90 generalmente tenían un solo administrador de paquetes aceptado y un grupo que proporcionaba una gran cantidad de software de uso común a través de este administrador de paquetes. (Los administradores de paquetes oficiales para varios Unices incluyen yumy aptpara sistemas Linux, pkgsrcpara NetBSD y portspara FreeBSD. A menudo, los sistemas comerciales de Unix también terminan con un administrador de paquetes no oficial pero ampliamente aceptado, como brewMacOS).

Estos administradores de paquetes tienen la ventaja de que pueden rastrear y hacen un seguimiento de cada archivo en el sistema en los diversos subdirectorios que "poseen". Debido a que un solo grupo está asignando el nombre y la ubicación de cada archivo aquí, todos pueden usar un pequeño conjunto de directorios compartidos entre ellos. Esto ofrece varias ventajas, especialmente en las áreas de compartir archivos entre aplicaciones y mantener baja la cantidad de rutas que necesita para buscar bibliotecas y archivos ejecutables.

Dicho esto, también hay una larga tradición de instalación de "directorio separado por aplicación" en Unix, generalmente bajo el /optdirectorio.