Linus Torvalds y el sistema de files OS X

En 2008, Linus Torvalds dijo en una entrevista famosa que "OS X de alguna manera es peor que Windows para progtwigr. Su sistema de files está completo y es una mierda, lo que da miedo". He buscado más detalles sobre por qué se siente de esta manera sobre el sistema de files OS X (HFS + presumiblemente), pero no he podido encontrar nada.

Linus seguramente no le desagrada el model básico del sistema de files Unix, y dudo que odie HFS + por ser insensible a las mayúsculas y minúsculas. Y a pesar de lo provocativamente que se expresa su comentario, dudo que sea completamente sin mérito. Como el comentario fue en el context de la progtwigción de OS X, sospecho que su opinión puede haberse basado en el performance, la solidez, la interfaz del sistema operativo o algo similar. ¿Alguien sabe qué quejas Linus de la era 2008 podría haber tenido con HFS + de la era 2008?

  • Evite que OS X 10.11 muestre el post "No se puede leer el disco"
  • ¿Por qué no / proc existe en OS X?
  • ¿Cómo saber qué files están total o parcialmente dentro de una banda de una image de disco de package disperso?
  • ¿Por qué Apple no envía y admite controlleres FOSS para capacidades de escritura NTFS?
  • ¿Es un sistema de files que puede leer / escribir mac y ganar y hacer la máquina del time?
  • ¿Los files pierden su UTI cuando se copyn en otro sistema de files?
  • No podemos crear la carpeta / var
  • ¿Cómo deshabilitar las asociaciones de files a una aplicación antes / después de la installation?
  • 3 Solutions collect form web for “Linus Torvalds y el sistema de files OS X”

    Se encuentra disponible una transcripción de la session de "Q & A" en la que Linus hizo el comentario , pero parece que no se le pidió que elaborara más. No estoy seguro de si se ha anotado un análisis más profundo de su opinión sobre HFS + en otro lugar.

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

    La simultaneidad, los metadatos escritos en el order de bytes correcto, la precisión de la date inferior a la segunda, el soporte para tamaños de volúmenes masivos y el soporte de files dispersos son todas características comunes de los filesystems Unix. Mac OS X, por supuesto, está construido sobre una base Unix. Cuando HFS + se transportaba desde el Mac OS clásico a Mac OS X, era necesario ampliarlo para admitir algunas características mínimas que se esperan de los filesystems Unix .

    Algunas de esas características se ajustaban fácilmente, pero otras eran muy difíciles de agregar al sistema de files 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 file separado para cada enlace duro dentro de un directory oculto en el nivel raíz del volumen. Los directorys ocultos son un poco espeluznantes para empezar, pero el verdadero temor viene cuando restrings 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á usando un sistema de files que ni siquiera fue diseñado para un sistema Unix, fue diseñado para el sistema operativo Mac clásico y parcheado para implementar las características de Mac OS X 10.0 mientras mantiene la compatibilidad con versiones anteriores. Apple posteriormente implementó las características adicionales que ahora tiene en Mac OS X 10.7 (diario, metadatos, events de sistema de files …) utilizando el mismo enfoque de parcheo en lugar de un enfoque de "layout desde cero". No estoy seguro de cómo explicar esto de manera no técnica, pero podría decirse que todas estas características adicionales se basan en una base de Mac OS clásica 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 enlaces duros mientras trabajaba dentro de las limitaciones de HFS + es demasiado sensible a fallas de hardware, lo cual se ve agravado por el hecho de que HFS + nunca fue diseñado para preocuparse por datos integridad. Por supuesto, mantener la compatibilidad con el sistema operativo Mac 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 recién comencé a usar OSX después de venir de Windows, me considero un PowerUser en Windows y bastante competente en Linux. Viniendo de ese trasbackground, me ha sorprendido que en un sistema operativo bastante moderno como OSX, el sistema de files tenga peculiaridades como la forma en que los nombres de los files se "mezclan".

    Entiendo que los problemas de Linus con HFS + surgen del mismo punto: por lo que he encontrado investigando el problema, HFS + almacena los nombres de los files usando Unicode, pero cuando un file usa caracteres "extendidos" o NO ASCII (como á, é, í, ó, ú, ñ del español o cosas como el ü en alemán), para lo cual Unicode proporciona 2 forms de codificar el nombre, OSX silenciosamente "normaliza" la encoding en el time de almacenamiento … No es un problema real cuando el El file se ha creado y consumido en OSX, pero cuando se comparte información con usuarios de otros sistemas operativos, el hecho de que el nombre del file cambie, crea todo tipo de comportamientos extraños …

    Ejemplo: he estado rastreando los "artefactos" de mi trabajo (files, documentos, etc.) en Subversion durante los últimos 8 años más. Cuando me mudé a Mac, obtuve el cliente SVN para Mac, y después de hacer un Checkout de mis directorys relevantes, encontré que todos los files que tienen acentos parecen estar ausentes, y aparece un nuevo file con el mismo nombre que no tiene una versión. Profundizando en él, el problema es que el file EN el sistema de files está codificado en apple, mientras que los datos en el repository usan otra encoding (perfectamente válida y legítima) Unicode …

    Esto, creo, es un gran "mangle" de mis datos. Apple SÍ entiende que ambos formattings de encoding de nombre de file (accediendo a un recurso compartido en Windows, o usando un dispositivo USB de Windows muestra los nombres de file correctos, etc.) pero en el momento de creación del file, se decide "sabe mejor" y acaba de renombrar los files. ..

    De nuevo, no es algo que la mayoría de los usuarios notarán, ¡hasta que hagan una copy de un file, o lo renueven, y lo vuelvan a colocar donde estaba el original y terminen con dos files aparentemente 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.

    Loving Apple Products like poisoning (iPhone, iPad, iMac, Macbook, iWatch).