En 2008, Linus Torvalds a déclaré dans une interview que "OS X est en quelque sorte pire que Windows à programmer. Leur système de fichiers est complet et complètement nul, ce qui est effrayant." J'ai cherché plus de détails sur les raisons pour lesquelles il ressent ce point de vue sur le système de fichiers OS X (HFS + probablement), mais je n'ai rien trouvé.
Linus n'aime certainement pas le modèle de base du système de fichiers Unix, et je doute qu'il déteste HFS + pour être insensible à la casse. Et malgré la façon dont son commentaire est provocateur, je doute que ce soit complètement sans mérite. Étant donné que le commentaire était dans le contexte de la programmation pour OS X, je soupçonne que son opinion peut être basée sur les performances, la robustesse, l'interface du système d'exploitation ou quelque chose du genre. Quelqu'un sait-il quelles plaintes Linus de l'ère 2008 pourrait avoir eu avec le HFS + de l'ère 2008?
la source
Réponses:
Une transcription de la session «Q&A» au cours de laquelle Linus a fait le commentaire est disponible, mais il semble qu'il n'ait pas été invité à élaborer. Je ne sais pas si une analyse plus approfondie de son opinion sur HFS + a été écrite ailleurs.
Pour l'analyse de la question par quelqu'un d'autre, vous pouvez consulter les critiques de Mac OS X de John Siracusa. En particulier celui pour Mac OS X Lion qui a une section intitulée " Qu'est-ce qui ne va pas avec HFS + ". Je pense que le bit le plus saillant est (soulignement le mien):
Le point important ici est que Mac OS X utilise un système de fichiers qui n'a même pas été conçu pour un système Unix, il a été conçu pour Mac OS classique et corrigé pour implémenter les fonctionnalités de Mac OS X 10.0 tout en maintenant la compatibilité descendante. Apple a par la suite implémenté les fonctionnalités supplémentaires dont il dispose désormais dans Mac OS X 10.7 (journalisation, métadonnées, événements de système de fichiers ...) en utilisant la même approche de correction plutôt qu'une approche de «conception à partir de zéro». Je ne sais pas comment expliquer cela de manière non technique, mais vous pourriez dire que toutes ces fonctionnalités supplémentaires reposent sur une fondation Mac OS classique qui n'a jamais été conçue pour les prendre en charge. Cela signifie que la solution n'est pas aussi bonne qu'elle pourrait l'être. L'exemple que Siracusa poursuit en discutant est que la solution qu'Apple a dû utiliser pour les liens durs tout en travaillant dans les limites de HFS + est trop sensible aux pannes matérielles, ce qui est aggravé par le fait que HFS + n'a jamais été conçu pour se préoccuper des données intégrité. Bien sûr, le maintien de la compatibilité avec Mac OS classique était une limitation souhaitable dans Mac OS X 10.0 mais ce n'est vraiment plus le cas dans Mac OS X 10.7.
la source
bswapinstruction x86 est très rapide. Cela rend le code plus gros et plus laid, mais le maintien de la compatibilité sur le disque est un gros problème. Linux XFS stocke toujours toutes les métadonnées big-endian (sauf native-endian dans le journal), en raison de son origine chez SGI sur les CPU MIPS. Ce n'est pas une situation idéale, mais XFS n'est pas retenu par elle.Bien que je ne sois pas un expert du système d'exploitation et que je viens de commencer à utiliser OSX après être venu de Windows, je me considère comme un PowerUser sous Windows et assez compétent sous Linux. Venant de ce contexte, j'ai été surpris de constater que dans un système d'exploitation assez moderne comme OSX, le système de fichiers a des bizarreries telles que la façon dont les noms des fichiers sont "mungled".
Je comprends que les problèmes de Linus avec HFS + proviennent du même point: d'après ce que j'ai trouvé en recherchant le problème, HFS + stocke les noms des fichiers en utilisant Unicode, mais quand un fichier utilise des caractères "étendus" ou NON ASCII (comme á, é, í, ó, ú, ñ de l'espagnol ou des choses comme le ü en allemand), pour lesquels Unicode fournit 2 façons de coder le nom, OSX "normalise" silencieusement le codage au moment du stockage ... Pas un vrai problème lorsque le Le fichier a été créé et consommé dans OSX, mais lorsque vous partagez des informations avec des utilisateurs d'autres systèmes d'exploitation, le fait que le nom du fichier change, entraîne toutes sortes de comportements étranges ...
Exemple: j'ai suivi mes "artefacts" de travail (fichiers, documents, etc.) dans Subversion au cours des 8 dernières années. Lors du passage à Mac, j'ai obtenu le client SVN pour Mac, et après avoir effectué une vérification de mes répertoires pertinents, j'ai constaté que tous les fichiers qui avaient des accents semblaient manquer, et un nouveau fichier avec le même nom apparaît comme non versionné. En creusant, le problème est que le fichier DANS le système de fichiers est encodé par Apple, tandis que les données dans le référentiel utilisent un autre encodage Unicode (parfaitement valide et légitime) ...
C'est, je pense, une grossière "mutilation" de mes données. Apple comprend les deux formats d'encodage du nom de fichier (accéder à un partage dans Windows ou utiliser une clé USB à partir de Windows affiche les noms de fichiers appropriés, etc.) mais au moment de la création du fichier, il est décidé "qu'il sait mieux" et renomme simplement les fichiers. ..
Encore une fois, la plupart des utilisateurs ne remarqueront rien - jusqu'à ce qu'ils fassent une copie d'un fichier, ou le renomment, et le remettent à l'endroit où se trouvait l'original et se retrouvent avec deux fichiers qui sont apparemment les mêmes !!!)
la source
John Siracusa et Dan Benjamin discutent de certains inconvénients de HFS + dans Hypercritical # 56 .
Ils corrigent la corruption de données dans HFS + et prennent en compte certaines des fonctionnalités de ZFS.
la source