Aclaremos todas las carpetas bin y sbin (del estándar de jerarquía del sistema de archivos):

• /bin es para binarios a nivel de sistema
• /sbin es para otros binarios de nivel de sistema principalmente para el gestor de arranque y los administradores del sistema
• /usr/bin es para binarios no esenciales
• /usr/sbin- Aquí es donde comienza el desorden, ¿no son herramientas esenciales para los administradores de sistemas? Qué significa eso? Para los experimentos?
• /usr/local/bin - ni una palabra sobre esta carpeta
• /usr/local/sbin- Programas de administración del sistema instalados localmente. ¿Otra vez? ¿Qué tal /usr/sbin?

Entonces la pregunta es: ¿Por qué hay tantos directorios y cuáles son los significados de /usr/sbin, /usr/local/sbiny /usr/local/bin?

Muchos programas se distribuyen a través de archivos y tenemos que construirlos desde el código fuente. Por lo general, tienen un archivo MAKE, por lo que es bastante fácil. Este proceso implica crear archivos en usr / local / lib, usr / local / bin ... usr / local / lo que sea sin crear carpetas específicas para un programa determinado.

¿Por que es esto entonces?

Creo que no está bien porque si necesitamos eliminar el programa tenemos que eliminar manualmente todos sus archivos si el creador del programa no se ocupó de ello.

1. Estructura del directorio

Esto debería estar cubierto en el Estándar de Jerarquía del Sistema de Archivos ( 2.3 PDF )

/ bin / Binarios de comandos esenciales que deben estar disponibles en modo de usuario único;
            para todos los usuarios, por ejemplo, cat, ls, cp

/ sbin / Binarios esenciales del sistema, por ejemplo, init, ip, mount.

/ usr / bin / Binarios de comandos no esenciales (no necesarios en modo de usuario único); 
            para todos los usuarios

/ usr / sbin / Binarios del sistema no esenciales, por ejemplo, demonios para varios servicios de red.

/ usr / local / Jerarquía terciaria para datos locales, específicos de este host. 
            Normalmente tiene subdirectorios adicionales, por ejemplo, bin /, lib /, share /

2. Instalación

Uso un administrador de paquetes siempre que sea posible (por ejemplo, yum o apt-get). Esto es posible para una gran cantidad de aplicaciones, en algunos casos puede que tenga que agregar un repositorio. Mi segunda opción serían los paquetes de nivel inferior, como RPM, y la compilación desde la fuente sería mi último recurso (pero algunas personas prefieren esto)

Algunos gestores de paquetes pueden instalar desde RPM (por ejemplo yum install oddity.rpm)

Si está compilando desde la fuente, probablemente no sea un gran paso crear su propio paquete para que el instalador del sistema sepa lo que ha hecho.

Entonces su problema se reduce a, por ejemplo, yum remove packagename

La alternativa es mantener una buena documentación sobre todas las actividades de sysadmin realizadas (de todos modos mantengo un diario en un archivo de texto)

Las cosas en todos los directorios * / sbin tienden a ser solo útiles para los administradores del sistema. Puede mantenerlos fuera de su RUTA si es un usuario normal.

Los diferentes directorios no tienen mucho sentido si tiene una sola máquina Unix en un solo disco, pero tiene más sentido si tiene un sistema grande y particiones diferentes. Recuerde que muchos de estos hábitos se hicieron en los años 80 y 90 cuando los sistemas eran un poco diferentes.

/sbintiende a ser muy pequeño Estas son las utilidades que necesita cuando está realmente conectado. Pondría esto en una partición raíz mínima con / root y / lib. Las cosas en / sbin solían estar todas vinculadas estáticamente, ya que si su partición / usr está alojada, cualquier aplicación vinculada dinámicamente es inútil. fsck está aquí y está estáticamente vinculado. Si tiene una dependencia de / usr, obviamente no puede fsck / usr /. Por supuesto, si la partición raíz está manguera, estás muy jodido. Es por eso que esta es una partición tan pequeña: reduzca las probabilidades de un bloque de disco defectuoso utilizando muy pocos bloques aquí.

/usr/sbinLos archivos binarios son herramientas generales de administrador de sistemas donde al menos puede acceder al modo de usuario único y montar todos sus volúmenes. Se les permite vincularse dinámicamente.

Las particiones separadas para / sbin (bueno, / sbin on / division) y / usr también tienen más sentido cuando recuerdas que la copia de seguridad era muy costosa tanto en tiempo como en cinta. Si estuvieran en particiones separadas, podría programarlas de manera diferente.

/usr/localpuede ser un sistema de archivos de red. Por lo tanto, las herramientas sysadmin escritas localmente que se pueden compartir en muchas máquinas a veces van a / usr / local / sbin. Obviamente, ninguna utilidad de reparación de red puede ir allí.

Nuevamente, muchas cosas tenían más sentido en máquinas grandes en un entorno en red en máquinas administradas con múltiples volúmenes, menos aún con una máquina Linux en una sola partición raíz.

Realmente debería tener su segunda pregunta como una pregunta separada aquí en Superusuario. No está relacionado con el primero.

Sí, tener archivos por todas partes apesta. Por eso hay muchas soluciones de embalaje. RedHat creó RPM que se usa en todas partes. Solaris tenía su formato de paquete. HP / UX tenía el suyo, y hay formatos aptos y muchos otros paquetes. Mantenga las cosas en los lugares correctos (/ usr / bin, / usr / lib) según corresponda, pero permita una fácil adición y eliminación.

Para la fuente, solía haber herramientas que le permitirían configurar e instalar en un subdirectorio de / usr / local y manejaría los enlaces simbólicos a / usr / local / bin por usted. Debido a la gran proliferación de herramientas de paquetes, esto es menos necesario y olvidé sus nombres.

A algunas personas les gusta instalar / opt / packagename y mantener todo junto allí. Lo bueno: todo está en un directorio y hay una desinstalación rm -rf /opt/packagename. Las desventajas de esto son tener que agregar / opt / packagename / bin a PATH de todos, y el hecho de que las personas generalmente no colocan / opt en una partición separada, y usted llena la partición raíz.

Mi opinión sobre los significados de los directorios (por experiencia con Debian GNU Linux) es la siguiente:

Primera distinción: ses para superusuario

santes de que un bindirectorio indique que contiene herramientas que normalmente solo son útiles para los administradores. Tenga en cuenta que, por ejemplo, ifconfigtambién pertenece a esta categoría y me gusta invocar ifconfigcomo usuario habitual (para verificar si obtuve una dirección IP / conectividad de red), lo que hace que esta distinción no sea tan difícil como parece.

Segunda distinción: locales para "Datos locales"

En la práctica, la distinción más importante aquí es que los administradores de paquetes del sistema operativo (como APT) instalan paquetes en la /usrestructura normal y /usr/localno se ven afectados. Esto permite que los paquetes compilados localmente o los scripts internos de la compañía proporcionados por el administrador del sistema se coloquen /usr/localdonde nunca interferirán con los archivos correctamente empaquetados.

Es discutible si /usr/localdebe anular los archivos existentes de la /usrestructura normal , consulte ¿Es peligroso tener / usr / local / bin delante de / usr / bin en la RUTA de uno? para algunos detalles sobre esto.

Tercera distinción: El nivel superior /biny los /sbindirectorios.

En Debian, en realidad hay un llamado UsrMerge . Solía ​​haber una diferencia /biny /sbinestaban disponibles en el proceso de arranque antes (piense en /usrestar en un dispositivo de red o en una partición diferente, RAID, etc.), pero hoy en día pocos sistemas Linux arrancan bien, sin lo /usrcual es por lo que consideraría la distinción entre nivel y /usrdirectorios serán en gran medida de interés histórico para Linux.

Finalmente: los méritos y problemas de los archivos de "dispersión".

Realmente no hay una "verdadera" respuesta a esto. Las ventajas del sistema de archivos dispersos de Linux son estas:

• Todos los archivos binarios residen en pocos directorios. Esto significa que puede llamar a todos los programas desde el shell. Compare Windows, donde siempre se necesita editar la %PATH%variable de entorno para agregar cualquier programa de interés. He visto entornos de rutas muy largas en Windows.

• Todas las bibliotecas residen en un lugar central. Esto significa que no necesitan instalarse dos veces cuando lo usan varias aplicaciones.

• Como Linux está diseñado para que la mayoría de los archivos del sistema sean rastreados por un administrador de paquetes de todos modos, no es necesario mantener una visión general de los archivos desde el punto de vista del usuario.

• Debido a FHS normalización, documentación también reside en lugares centrales que permiten sistemas como man, infoy los archivos README de apoyo para el trabajo como se esperaba.

• Es más fácil confiar en un programa que se instala en un lugar fijo. Todo el mundo escribe #!/bin/sh -eo similar al comienzo de los guiones y simplemente funciona . Considere un sistema donde el shell iría a un directorio diferente: ¿Cómo podría uno saber qué nombre tomará? Si está interesado, verifique las diversas formas de instalar Perl o LaTeX en Windows para ver qué tan complicado puede ser ...

Las desventajas que he encontrado hasta ahora son estas:

• Normalmente, es más difícil ejecutar aplicaciones "portables" en el sentido de "aplicaciones portátiles para Windows". En Linux, no es tan fácil simplemente copiar el programa a otra computadora ... uno necesita tener el paquete (que requiere permisos de root) o tratar LD_LIBRARY_PATHde apuntar las aplicaciones a diferentes rutas de búsqueda para las bibliotecas requeridas.

• La instalación de múltiples versiones del mismo programa debe ser soportada explícitamente, mientras que en los sistemas con "un directorio por programa" esto a menudo es un problema menor.

• Administrar los archivos sin un administrador de paquetes es propenso a errores (como ya se mencionó).

Para responder a su segunda pregunta: por lo
general, los programas se distribuyen con un denominado administrador de paquetes . Un administrador de paquetes generalmente obtiene paquetes binarios (software compilado para una determinada plataforma) y lo arroja alrededor de directorios (hay algunos que descargan el código fuente, lo compilan en su máquina y lo instalan). Por lo tanto, el administrador de paquetes sabe dónde residen los archivos que pertenecen a cierto "programa" (paquete), y cuando desea eliminar el paquete, el administrador de paquetes se encarga de limpiar todo.
Incluso cuando compila el código fuente por su cuenta con

make

e instalarlo con

make install

normalmente puedes hacer

make uninstall

que elimina los archivos del sistema de archivos.