1. Estructura del directorio
Esto debería estar cubierto en el Estándar de jerarquía del sistema de archivos (2.3 PDF)
/bin/ Essential command binaries that need to be available in single user mode;
for all users, e.g., cat, ls, cp
/sbin/ Essential system binaries, e.g., init, ip, mount.
/usr/bin/ Non-essential command binaries (not needed in single user mode);
for all users
/usr/sbin/ Non-essential system binaries, e.g. daemons for various network-services.
/usr/local/ Tertiary hierarchy for local data, specific to this host.
Typically has further subdirectories, e.g., 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 es posible que deba 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 administradores de paquetes pueden instalar desde RPM (por ejemplo, yum install oddity.rpm )
Si está compilando desde el código 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, p. yum remove packagename
La alternativa es mantener una buena documentación sobre todas las actividades de administrador de sistemas realizadas (de todos modos, mantengo un diario en un archivo de texto)
Las cosas en todos los directorios */sbin tienden a ser útiles solo 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 tienen más sentido si tiene un sistema grande y diferentes particiones. Recuerda que muchos de estos hábitos se crearon en los años 80 y 90, cuando los sistemas eran un poco diferentes.
/sbin tiende a ser muy pequeña. Estas son las utilidades que necesita cuando está realmente agotado. Pondría esto en una partición raíz mínima con /root y /lib. Las cosas en /sbin solían estar vinculadas estáticamente, ya que si su partición /usr está regada, cualquier aplicación vinculada dinámicamente es inútil. fsck está aquí y vinculado estáticamente. Si tiene una dependencia de /usr, obviamente no puede fsck /usr/. Por supuesto, si la partición raíz está regada, 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 usando muy pocos bloques aquí.
/usr/sbin Los archivos binarios son herramientas generales de administración de sistemas en las que 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 en /partición) y /usr también tienen más sentido cuando recuerda 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/local puede ser un sistema de archivos de red. Por lo tanto, las herramientas de administración de sistemas escritas localmente que se pueden compartir entre muchas máquinas a veces van a /usr/local/sbin. Obviamente, ninguna herramienta de reparación de red puede ir allí.
Nuevamente, muchas cosas tenían más sentido en máquinas grandes en un entorno de red en máquinas administradas con múltiples volúmenes, menos 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 todos lados apesta. Es por eso que 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 apt y muchos otros formatos de paquetes. Mantenga las cosas en los lugares correctos (/usr/bin, /usr/lib) según corresponda, pero permita agregarlas y quitarlas fácilmente.
Para la fuente, solía haber herramientas que le permitían configurar e instalar en un subdirectorio de /usr/local y manejaba 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 en /opt/nombre del paquete y mantener todo junto allí. Lo bueno:todo está en un directorio y la desinstalación es rm -rf /opt/packagename . Las desventajas de esto son tener que agregar /opt/packagename/bin a la RUTA 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.