Linus Torvalds y el sistema de files OS X

En 2008, Linus Torvalds dijo en una entrevista que "OS X de alguna manera es peor que Windows para progtwigr, su sistema de files es completo y es una mierda, lo cual es aterrador". 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 sido capaz de encontrar nada.

Linus seguramente no le desagrada el model de sistema de files Unix básico, y dudo que odia a HFS + por ser insensible a mayúsculas y minúsculas. Y a pesar de lo provocativo que es su comentario, dudo que sea completamente sin mérito. Dado que el comentario estaba en el context de la progtwigción para OS X, sospecho que su opinión podría haber estado basada en el performance, la robustez, la interfaz del sistema operativo o algo así. ¿Alguien sabe qué quejas Linus de 2008-era podría haber tenido con HFS + de 2008-era?

  • ¿Cómo puedo cambiar el nombre de un file en git que difiere sólo por caso?
  • No se puede editar / etc / fstab para permitir que las unidades NTFS escriban
  • Mantener los dos files al moverlos a una carpeta diferente?
  • Cómo crear un nuevo file en la carpeta seleccionada con LaunchBar?
  • Shell script para determinar el tamaño del file en una carpeta recursivamente
  • Obtener todos los files que han cambiado más recientemente
  • "Este UPX comprimido binary contiene una cabecera Mach-O no válida y no se puede cargar."
  • ¿Cómo se puede utilizar el command 'mail'?
  • El icono de Dock no se actualiza cuando se cambia el file icns en Yosemite
  • ¿Cómo mapear la esquina inferior derecha de Trackpad para hacer clic con el button derecho del ratón en la progtwigción?
  • Mostrar siempre ocultos en cuadros de dialog Abrir / Guardar
  • ¿Por qué Google Chrome Helper apunta mi CPU?
  • 3 Solutions collect form web for “Linus Torvalds y el sistema de files OS X”

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

    Para el análisis de otra persona del 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 " Lo que está mal con HFS + ". Creo que la parte más destacada es (el subrayado mío):

    La concurrency, los metadatos escritos en el order de bytes correcto, la precisión de la sub-segunda date, la compatibilidad con volúmenes de volumen masivos y el soporte de files escaso son características comunes de los filesystems Unix. Mac OS X, por supuesto, se basa en una base Unix. Cuando HFS + fue portado de Mac OS clásico a Mac OS X, necesitaba extenderse para soportar un set mínimo de características que se esperan de los filesystems Unix .

    Algunas de esas características eran un ajuste fácil, pero otras eran muy difíciles de agregar al sistema de files sin romper la compatibilidad hacia atrás. Un ejemplo especialmente aterrador es la implementación de enlaces duros en HFS +. Para realizar un seguimiento de los enlaces duros, HFS + crea un file independiente para cada enlace duro dentro de un directory oculto en el nivel raíz del volumen. Los directorys ocultos son un poco espeluznantes, pero el verdadero susto viene cuando restrings que Time Machine se implementa usando enlaces duros para evitar la duplicación innecesaria de datos.

    El punto importante aquí es que Mac OS X está utilizando un sistema de files 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. Apple ha implementado posteriormente 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 corrección en lugar de un enfoque de "layout desde abajo". No estoy seguro de cómo explicar esto técnicamente, pero se podría decir que todas estas características adicionales se apoyan en una base clásica de Mac OS que nunca fue diseñada para soportarlos. Esto significa que la solución no es tan buena como podría ser. El ejemplo que Siracusa pasa a discutir es que la solución que Apple tuvo que utilizar para 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 + nunca fue diseñado para preocuparse por datos integridad. Por supuesto, mantener la compatibilidad con el Mac OS clásico era una limitación deseable en Mac OS X 10.0, pero ya no está en Mac OS X 10.7.

    Aunque no soy un experto en sistemas operativos, y acabo de empezar a usar OSX después de venir de Windows, me considero un PowerUser en Windows, y bastante competente en Linux. Viniendo de ese background, me ha sorprendido que en un sistema operativo bastante moderno como OSX, el sistema de files tiene peculiaridades como la forma en que los nombres de los files son "mungled".

    Entiendo que los problemas de Linus con HFS + se derivan del mismo punto: de lo que he encontrado investigando el problema, HFS + almacena los nombres de los files usando Unicode, pero cuando un file utiliza caracteres "extendidos" o NON-ASCII (como á, é, í, ó, ú, ñ del español o cosas como el ü en alemán), para lo que 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 file se ha creado y consumido en OSX, pero cuando está compartiendo información con los usuarios de otros sistemas operativos, el hecho de que el nombre del file cambia, hace que todo tipo de comportamientos extraños …

    Caso en el punto: He estado rastreando mi trabajo "artefactos" (files, documentos, etc) en Subversion para los últimos 8plus años. Al pasar 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 faltar, y un nuevo file con el mismo nombre aparece como no versionado. El problema es que el file IN del sistema de files está codificado en Apple, mientras que los datos del repository utilizan otra encoding Unicode (perfectamente válida y legítima) …

    Esto, creo, es un "mangling" bruto de mis datos. Apple entiende los dos formattings de la encoding del nombre de file (acceder a un recurso compartido en Windows o utilizar una memory USB de Windows muestra los nombres de file adecuados, etc.), pero al momento de crear el file, se decidió "sabe mejor" y acaba de renombrar los files. ..

    Una vez más, no es algo que la mayoría de los usuarios se dará count – hasta que hacen una copy de un file, o cambiar su nombre, y poner de nuevo a donde estaba el original y terminar con dos files que son aparentemente los mismos !!!)

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

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

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