¿Por qué no hay README en la jerarquía del sistema de archivos de Linux?

La jerarquía del sistema de archivos de Linux ( FHS ) contiene muchos directorios importantes. Por ejemplo, acabo de descubrir /sys/class/inputmientras jugaba con la configuración de mi teclado PS / 2.

Pero todos esos directorios importantes están documentados en otros lugares, por lo man /sys/class/inputque no funciona explicar lo que sucede en un momento determinado.

¿Por qué no colocar READMEarchivos en la jerarquía para que sea más fácil para las personas aprender lo que está sucediendo en ciertos niveles y jugar con los contenidos? Sería realmente increíble si los dispositivos pudieran incluso montar sus propios READMEs.

documentation fhs

— anatoly techtonik
fuente

¿Quizás porque la mayoría de la gente no quiere aprender lo que está sucediendo en esos diferentes niveles? Solo quieren que trabajen, para que puedan realizar cualquier tarea que necesiten / quieran hacer. Alguien tendría que escribir todos esos archivos README, y agregarían más hinchazón a un sistema de archivos ya sobrecargado con cosas (como gran parte de / usr / share) que la mayoría de la gente nunca usará.

— jamesqf

@jamesqf porque la mayoría de la gente no quiere aprender qué está pasando en esos diferentes niveles? Solo quieren que trabajen, para que puedan realizar cualquier tarea que necesiten / quieran hacer ¿ Y qué pasa si mi tarea está relacionada con el sistema de archivos, como parece ser el OP? Además, ¿has conocido a un usuario de Linux? Nosotros sí queremos aprender. Este es un argumento terrible.

— kaqqao

La diferencia fundamental entre Linux y Windows / Mac, en caso de que no lo hayas notado, es que Linux sabe que dejaste el útero ya sabiéndolo todo. Por lo tanto, un archivo README sería redundante.

— user541686

@kaqqao: Bueno, soy un usuario de Linux, y lo he sido prácticamente desde que había un Linux. Y antes de eso, un usuario de Unix, ya que se ejecutó en el PDP-11 de mi escuela. No me importa particularmente cómo funcionan cosas como el sistema de archivos, solo (en este momento) quiero que funcione mi código de tomografía sísmica. Tampoco me importa / sys / class / input, siempre que mi teclado y mi trackball funcionen. Para la pequeña minoría que está interesada en estas cosas, existe una herramienta útil llamada Google, accesible desde la mayoría de los navegadores web :-)

— jamesqf

Hay man hier.

— el.pescado

Respuestas:

Para usar su ejemplo: /sys/no contiene archivos "reales", pero el núcleo lo proporciona por completo. ¿Desea que todos los README se vuelvan parte del núcleo? Probablemente no lo hagas.

La documentación está adentro /usr/share/doc. Que contiene archivos normales en su disco duro. Parte de la documentación sobre /sysy /procestá en la fuente del núcleo, que está en /usr/src/linux/Documentation(si instaló la fuente del núcleo y realizó el enlace simbólico para su núcleo actual).

— dirkt
fuente

sysfs y procfs son sistemas de archivos completamente virtuales que no tienen almacén de respaldo. Todo lo que hay allí es sintetizado sobre la marcha por el núcleo. Si los README no están almacenados en la memoria, ¿de dónde más vendrían?

— Jörg W Mittag

@ JörgWMittag: Obviamente, el núcleo podría sintetizar enlaces simbólicos a /use/share/doc.

— MSalters

El núcleo ya es una pieza de software grande y complicada, y "facilitar el aprendizaje de las personas" no se encuentra entre los objetivos principales de sus desarrolladores. No es que difícil ir a /usr/share/docsu lugar.

— Federico Poloni

@MSalters: eso significaría que el kernel tiene que: a) escanear todo el sistema de archivos para encontrar esos archivos y crear enlaces simbólicos a ellos, b) debe tener una carga de opciones de configuración para decirle al kernel dónde están esos archivos para que pueda crear enlaces simbólicos a ellos, o c) tiene que prescribir las ubicaciones de esos archivos a los mantenedores de distribución (lo que violaría la máxima n. ° 1 de Linus de que la política pertenece al espacio de usuario, solo el mecanismo pertenece al núcleo). Además, ¿cómo se asegura de que los archivos coincidan con la versión actual del kernel? ¿Qué pasa con las distribuciones que tienen su ...

— Jörg W Mittag

@FedericoPoloni: el FHS solo es obligatorio para las distribuciones de Linux que se ajustan al LSB. La mayoría no lo hace. En particular, hay una serie de distribuciones que se fundaron específicamente para limpiar (lo que perciben como) ruina histórica, que en muchos casos incluye explícitamente el FHS.

— Jörg W Mittag

Porque Unix y Linux tienen una tradición de décadas de documentar con manpáginas (y, en sistemas GNU, infoarchivos ...). Ver man (1) , man (7) , páginas de manual (7) . Por cierto, el mancomando y las páginas son opcionales (y no las instalará en todos los sistemas Unix).

La jerarquía del sistema de archivos se describe en hier (7) .

Está definido por el Estándar de jerarquía del sistema de archivos disponible en https://wiki.linuxfoundation.org/lsb/fhs

Varios sistemas de archivos, en particular /proc/(ver proc (5) ) y /sys/(ver sysfs (5) ) son sistemas de pseudofile proporcionados por el código del kernel. No desea inflar el núcleo con código adicional que produce tales README-s (que es inútil para la gran mayoría de los usuarios). Incluso el archivo de configuración del núcleo solo está disponible opcionalmente, ya /proc/config.gzque a menudo está deshabilitado en la mayoría de las configuraciones del núcleo. Y muchos sistemas Linux son sistemas embebidos (por ejemplo, su teléfono inteligente, su dispositivo inteligente o dispositivo IoT, su RaspberryPI) donde los recursos son lo suficientemente escasos como para evitar su desperdicio.

Notablemente /sys/es principalmente útil para los administradores de sistemas y para los desarrolladores que escriben utilidades de bajo nivel, y se supone que ambos pueden encontrar la documentación de manera adecuada.

¿Por qué no colocar READMEarchivos en la jerarquía para que sea más fácil para las personas saber qué está pasando?

Si realmente desea tales READMEs, escriba su propio módulo de kernel cargable proporcionándolos, o configure algunos unionfs para proporcionarlos. No creo que valga la pena el esfuerzo (y una unión /sysprobablemente desaceleraría todo su sistema).

Recuerde que el código del núcleo consume RAM (nunca se pagina y se encuentra en la memoria física , no en la memoria virtual), incluso si no se usa. Por lo tanto, tiene sentido evitar hincharlo.

— Basile Starynkevitch
fuente

¿Entonces puedo escribir un paquete que documente todas esas rutas sin tocar el kernel o hacerlo hinchado?

— anatoly techtonik

Podría, pero el uso de un unionfs en /sysralentizaría su sistema. No creo que valga la pena perder su tiempo de esa manera. La vida es corta ... Y

— pasarás