¿Por qué hay una combinación de enlaces simbólicos y enlaces duros en / bin?

Entiendo la diferencia técnica entre enlaces simbólicos y enlaces duros, esta es una pregunta sobre su uso en la práctica, particularmente tengo curiosidad por saber por qué ambos se usan en condiciones aparentemente similares: el /bindirectorio.

Aquí hay un fragmento de su listado en mi sistema:

~$ ls -lai /bin
total 10508
32770 drwxr-xr-x  2 root root    4096 Jun 14 11:47 .
    2 drwxr-xr-x 28 root root    4096 Sep  6 13:15 ..
  119 -rwxr-xr-x  1 root root  959120 Mar 28 22:02 bash
   2820 -rwxr-xr-x  3 root root   31112 Dec 15  2011 bunzip2
  127 -rwxr-xr-x  1 root root 1832016 Nov 16  2012 busybox
   2820 -rwxr-xr-x  3 root root   31112 Dec 15  2011 bzcat
 6191 lrwxrwxrwx  1 root root       6 Dec 15  2011 bzcmp -> bzdiff
 5640 -rwxr-xr-x  1 root root    2140 Dec 15  2011 bzdiff
 5872 lrwxrwxrwx  1 root root       6 Dec 15  2011 bzegrep -> bzgrep
 3520 -rwxr-xr-x  1 root root    4877 Dec 15  2011 bzexe
 6184 lrwxrwxrwx  1 root root       6 Dec 15  2011 bzfgrep -> bzgrep
 5397 -rwxr-xr-x  1 root root    3642 Dec 15  2011 bzgrep
   2820 -rwxr-xr-x  3 root root   31112 Dec 15  2011 bzip2
 2851 -rwxr-xr-x  1 root root   10336 Dec 15  2011 bzip2recover
 6189 lrwxrwxrwx  1 root root       6 Dec 15  2011 bzless -> bzmore
 5606 -rwxr-xr-x  1 root root    1297 Dec 15  2011 bzmore

Sangué los enlaces duros al mismo inodo para una mejor visibilidad. Así están los enlaces simbólicos utilizados en el caso de bzcmp, bzegrep, bzfgrep, bzlessy en el caso de los enlaces duros bzip2, bzcat, bunzip2?

Todos son archivos normales (no directorios), residen dentro de un sistema de archivos, son utilidades del sistema e incluso están diseñados para trabajar con lo mismo: archivos bzip. ¿Las razones para el uso de enlaces / enlaces simbólicos en este caso particular son puramente históricas o me falta algo?

Aclaración de mi pregunta:

Estoy no preguntar sobre:

• Las diferencias técnicas entre enlaces simbólicos y enlaces duros
• Las ventajas y desventajas teóricas de cada una de ellas.

Estas preguntas se han abordado en otros hilos en SO. Estoy tratando de entender por qué se tomaron diferentes decisiones en un caso específico: para un grupo de utilidades del sistema relacionadas. Técnicamente, todos podrían haber sido enlaces simbólicos o todos podrían haber sido enlaces duros, ambas opciones funcionarían (y en ambos casos un programa aún puede descubrir cómo se ha invocado a través de argv[0]). Quiero entender la intención aquí si hay alguna.

Relacionado:

• ¿Por qué existen enlaces duros?

¿Por qué usar enlaces duros versus enlaces simbólicos?

Existen principalmente 3 ventajas de usar enlaces duros sobre enlaces simbólicos en este escenario.

Enlaces duros

1. Con un enlace duro, el enlace apunta al inodo directamente.
2. Los enlaces duros son como tener múltiples copias del ejecutable pero solo usando el espacio en disco de uno.
3. Puede cambiar el nombre de cualquier rama del enlace duro sin romper nada.

Enlaces simbólicos

1. El enlace apunta al objeto (que a su vez apunta al inodo).
2. Pueden abarcar sistemas de archivos, mientras que los enlaces duros no.

Ventajas de vincular en general

Estos enlaces existen porque muchos ejecutables se comportan de manera diferente en función de cómo se llamaron. Por ejemplo, los 2 comandos bzlessy bzmoreson en realidad un único ejecutable, bzmore. El ejecutable se comportará de manera diferente dependiendo de qué nombres se usaron para invocarlo.

Esto se hace por una variedad de razones. Estos son algunos de los más obvios:

1. Es más fácil desarrollar un solo ejecutable que muchos
2. Ahorra espacio en disco
3. Más fácil de implementar

¿Por qué se usan ambos?

La elección de cualquiera, en esta aplicación particular, es discutible. Cualquiera de los dos puede facilitar la función de actuar como un alias para que un solo ejecutable pueda sobrecargarse. Esa es realmente la característica clave que los desarrolladores de los diversos programas están aprovechando aquí.

Al observar el FHS (Estándar de jerarquía del sistema de archivos) incluso lo especifica de esta manera, puede ser cualquiera.

extracto

Si / bin / sh no es un verdadero shell Bourne, debe ser un enlace rígido o simbólico al comando real del shell.

La razón detrás de esto es porque sh y bash no necesariamente se comportan de la misma manera. El uso de un enlace simbólico también permite a los usuarios ver fácilmente que / bin / sh no es un verdadero shell Bourne.

...

...

Si existen los programas gunzip y zcat, deben ser enlaces simbólicos o duros a gzip. / bin / csh puede ser un enlace simbólico a / bin / tcsh o / usr / bin / tcsh.

Referencias

• ¿Por qué los enlaces simbólicos de reinicio, apagado y apagado de systemctl?

Parece que está tratando de averiguar, a partir de la práctica existente, si existe una regla no técnica que le indique qué tipo de enlace debe usar. (Digo no técnico porque ya conoces los motivos técnicos para usar uno sobre el otro).

La respuesta es que no hay otra regla. Este ejemplo que ha señalado en el bzip2paquete de Ubuntu solo muestra que muchos desarrolladores los mezclan sin mucha previsión. Esto se debe a que no hay una guía sólida aparte de las diferencias técnicas, y esas diferencias son pequeñas.

Personalmente, prefiero usar enlaces simbólicos, siempre, porque estoy dispuesto a pagar sus pequeños gastos a cambio de su naturaleza autodocumentada.

Otros desarrolladores elegirán enlaces duros por las pequeñas eficiencias que proporcionan.

Este problema se parece mucho a espacios versus pestañas o escritura dinámica frente a estática o Emacs frente a vi , salvo que no es lo suficientemente interesante como para desencadenar una guerra santa . Al igual que las batallas más interesantes, hay razones para elegir cualquiera de las opciones, pero a menos que alguien te diga cuál usar, puedes elegir la que tenga más sentido para ti.