Linus Torvalds y el sistema de archivos OS X

En 2008, Linus Torvalds dijo en una entrevista que "OS X de alguna manera es realmente peor que Windows para programar. Su sistema de archivos es completo y una mierda absoluta, lo que da miedo". He buscado más detalles sobre por qué se siente así con respecto al sistema de archivos OS X (HFS + presumiblemente) pero no he podido encontrar nada.

A Linus seguramente no le desagrada el modelo básico del sistema de archivos Unix, y dudo que odie a HFS + por no ser sensible a mayúsculas y minúsculas. Y a pesar de lo provocativo de su comentario, dudo que sea completamente sin mérito. Dado que el comentario fue en el contexto de la programación para OS X, sospecho que su opinión puede haberse basado en el rendimiento, la solidez, la interfaz del sistema operativo o algo por el estilo. ¿Alguien sabe qué quejas que Linus de la era de 2008 podría haber tenido con HFS + de la era de 2008?

Una transcripción de la sesión de "Preguntas y respuestas" en la que Linus hizo el comentario está disponible, pero parece que no se le pidió que diera más detalles. No estoy seguro de si se ha escrito un análisis más profundo de su opinión sobre HFS + en otro lugar.

Para el análisis de otra persona sobre el asunto, puede echar un vistazo a las revisiones de Mac OS X de John Siracusa. En particular, el de Mac OS X Lion, que tiene una sección titulada " ¿Qué tiene de malo HFS + ?". Creo que el bit más destacado es (énfasis mío):

La concurrencia, los metadatos escritos en el orden de bytes correcto, la precisión de la fecha por debajo del segundo, la compatibilidad con tamaños de volumen masivos y la compatibilidad con archivos dispersos son características comunes de los sistemas de archivos Unix. Mac OS X, por supuesto, está construido sobre una base Unix. Cuando HFS + fue portado de Mac OS clásico a Mac OS X, necesitaba extenderse para admitir un conjunto mínimo de características que se esperan de los sistemas de archivos Unix .

Algunas de esas características se ajustaban fácilmente, pero otras eran muy difíciles de agregar al sistema de archivos sin romper la compatibilidad con versiones anteriores. Un ejemplo particularmente aterrador es la implementación de enlaces duros en HFS +. Para realizar un seguimiento de los enlaces duros, HFS + crea un archivo separado para cada enlace duro dentro de un directorio oculto en el nivel raíz del volumen. Los directorios ocultos son un poco espeluznantes para empezar, pero el verdadero susto llega cuando recuerdas que Time Machine se implementa utilizando enlaces duros para evitar la duplicación innecesaria de datos.

El punto importante aquí es que Mac OS X está utilizando un sistema de archivos que ni siquiera fue diseñado para un sistema Unix, fue diseñado para Mac OS clásico y parcheado para implementar las características de Mac OS X 10.0 manteniendo la compatibilidad con versiones anteriores. Posteriormente, Apple implementó las características adicionales que ahora tiene en Mac OS X 10.7 (registro en diario, metadatos, eventos del sistema de archivos ...) utilizando el mismo enfoque de parcheo en lugar de un enfoque de "diseño desde cero". No estoy seguro de cómo explicar esto de manera no técnica, pero se podría decir que todas estas características adicionales se basan en una base clásica de Mac OS que nunca fue diseñada para admitirlas. Esto significa que la solución no es tan buena como podría ser. El ejemplo que continúa discutiendo Siracusa es que la solución que Apple tuvo que usar para los enlaces duros mientras trabajaba dentro de las limitaciones de HFS + es demasiado sensible a fallas de hardware, lo que se agrava por el hecho de que HFS + tampoco fue diseñado para preocuparse por los datos integridad. Por supuesto, mantener la compatibilidad con Mac OS clásico era una limitación deseable en Mac OS X 10.0, pero ya no lo es en Mac OS X 10.7.

Aunque no soy un experto en sistemas operativos, y acabo de comenzar a usar OSX después de venir de Windows, me considero un PowerUser en Windows y bastante competente en Linux. Partiendo de ese trasfondo, me ha sorprendido que en un sistema operativo bastante moderno como OSX, el sistema de archivos tenga peculiaridades como la forma en que los nombres de los archivos están "mezclados".

Entiendo que los problemas de Linus con HFS + provienen del mismo punto: por lo que descubrí al investigar el problema, HFS + almacena los nombres de los archivos que usan Unicode, pero cuando un archivo usa caracteres "extendidos" o NO ASCII (como á, é, í, ó, ú, ñ (en español o cosas como la ü en alemán), para lo cual Unicode proporciona 2 formas de codificar el nombre, OSX silenciosamente "normaliza" la codificación en el momento del almacenamiento ... No es un problema real cuando El archivo se ha creado y consumido en OSX, pero cuando comparte información con los usuarios de otros sistemas operativos, el hecho de que el nombre del archivo cambie, genera todo tipo de comportamientos extraños ...

Caso en cuestión: He estado rastreando mis "artefactos" de trabajo (archivos, documentos, etc.) en Subversion durante los últimos 8 años. Cuando me mudé a Mac, obtuve el cliente SVN para Mac, y después de hacer un Checkout de mis directorios relevantes, descubrí que todos los archivos que tienen acentos parecen faltar, y un nuevo archivo con el mismo nombre aparece como no versionado. Profundizando en ello, el problema es que el archivo EN el sistema de archivos está codificado en manzana, mientras que los datos en el repositorio usan otra codificación Unicode (perfectamente válida y legítima) ...

Esto, creo, es una gran "destrucción" de mis datos. Apple entiende ambos formatos de codificación de nombre de archivo (el acceso a un recurso compartido en Windows o el uso de una memoria USB de Windows muestra los nombres de archivo adecuados, etc.) pero en el momento de la creación del archivo, se decidió "sabe mejor" y simplemente cambió el nombre de los archivos. ..

Una vez más, no es algo que la mayoría de los usuarios notarán, ¡hasta que hagan una copia de un archivo, o lo renombren, lo vuelvan a colocar donde estaba el original y terminen con dos archivos que aparentemente son iguales!)

John Siracusa y Dan Benjamin discuten algunas desventajas de HFS + en Hypercritical # 56 .

Abordan la corrupción de datos en HFS + y consideran algunas de las características de ZFS.