« HFS+ est certainement le pire système de fichiers » selon Linus Torvalds
« Franchement, HFS+ est certainement le pire système de fichiers jamais créé. Dieu que c'est de la merde. » Linus Torvalds ne mâche pas ses mots pour dire combien il déteste le système de fichiers d'OS X.
Tout est parti d'un message sur Google+ annonçant une mise à jour de sécurité importante pour Git, un logiciel de gestion de versions mis au point par Torvalds. Le patch comble une vulnérabilité de Git sur les systèmes insensibles à la casse. Un malandrin pouvait en effet créer un arbre Git malveillant avec une casse différente, comme .Git ou .GIT, qui écrase le contenu du dossier original .git/. L'attaquant pouvait ensuite exécuter des commandes arbitraires sur la machine (les détails techniques sur ce blog). D'où le courroux de l'inventeur de Linux :
L'insensibilité à la casse est tout simplement une idée horriblement mauvaise, et Apple aurait pu la réparer. Ils ne l'ont pas fait. À la place, ils ont mis les bouchées doubles sur cette mauvaise idée et l'ont étendu activement à Unicode.
Torvalds note que NTFS, le système de fichiers de Windows, a eu les mêmes problèmes avec UTF-8, mais ils ont été résolus. « Les problèmes d'OS X semblent être fondamentaux », estime cet utilisateur de MacBook Air (avec une distribution Linux).
Ce qui est effrayant avec HFS+, ce n'est pas qu'il s'agit d'un "système de fichiers pas terrible", mais comment il a été activement conçu pour être un mauvais système de fichiers par des personnes qui pensaient qu'elles avaient de bonnes idées. (le gras est de Torvalds, ndr)
Torvalds ne préconise pas pour autant de remplacer HFS+ par ZFS, un système prometteur qu'Apple a projeté d'utiliser pendant un temps (lire : ZFS : chronique d'un abandon). « Il y a beaucoup de bonnes raisons de ne pas passer à ZFS », notamment pour des questions de licence, « mais ils auraient pu pousser les gens vers HFS+ sensible à la casse, ce qui aurait rendu ensuite beaucoup plus facile (sur le long terme) la migration vers quelque chose de plus sain. »
À vrai dire, la sensibilité à la casse n'est pas tout à fait étrangère à HFS+. Depuis Tiger, OS X sait prendre en compte la casse, « mais Apple cache délibérément [cette option] et ne la maintient pas », admoneste Torvalds. L'activer revient par ailleurs à déclencher des bugs dans une flopée de logiciels qui n'ont pas prévu ce cas de figure (certains logiciels Adobe et Apple, pour ne citer qu'eux, s'accomodent très mal de cette option).
Pour le développeur et journaliste John Siracusa, qui connait bien les entrailles d'OS X, cette prise en charge seulement optionnelle n'est pas le plus gros défaut du système de fichiers. Il pense par ailleurs qu'iOS a toujours utilisé une version de HFS+ sensible à la casse.
Non, pour Siracusa il manque avant tout des fonctions modernes à ce système de fichiers vieux de 17 ans (il était déjà présent dans Mac OS). Apple l'a bien amélioré au fil du temps, mais il accuse toujours le poids des années. Schématiquement, il ne tire pas pleinement parti des SSD maintenant largement répandus ni des processeurs multicœurs qui sont devenus la norme... sans compter le problème de corruption de données qui peut rendre illisible un disque entier. « En 26 ans d'utilisation du Mac, la cause majeure de pertes de mes données a été et continue d'être la corruption du système de fichiers. »
« HFS+ a bien rendu service à Apple, et certainement pendant bien plus longtemps que ses concepteurs ne l'avaient imaginé. Mais comme les produits et technologies Apple qui rentrent dans cette description (par exemple Classic, Carbon, PowerPC), il arrive un moment où ces choses qui furent précieuses doivent disparaître de ce monde », écrivait Siracusa en 2011, au moment de la sortie de Lion. Quatre ans plus tard, on en est toujours au même point.
Mais si jamais Apple voudrait remplacer le HFS+, qu'est ce qui pourrais le remplacer ?
@Dark-mac :
Ext4 ?
Ouais c'est vrai que sa pourrais être une alternative
Non.
ext4 ne peut pas;, ou alors vous allez faire exploser la compatibilité avec encore une fois le duo de l'enfer : Adobe et Microsoft.
(sans parler de la cohorte de logiciels inconnus qui vont "subitement" devenir vitaux)
Ext4 ne gère pas un concept qui est encore vivace dans Os X : le multiple flux de données, data fork et ressource fork.
Ext4 est aussi un système de fichier vieillissant qui ne répond pas aux exigences des erreurs d'écriture/lecture du matériel face à des données gigantesques.
BTRFS est un better file system, heu un meilleur système de fichier :)
@Dark-mac :
Ext 4 ou btrfs ?
btrfs
mais apple vous ferait la grimace si vous leur dites ça car GPL.
GNU BASH est intégré à OS X et est sous GPLv3... C'était aussi le cas de GCC.
L'implémentation Btrfs de Linux est sous GPLv2. Mais je n'ai pas trouvé de source sur la licence de Btrfs en tant que modèle/concept.
@ RyDroid : « GNU BASH est intégré à OS X et est sous GPLv3... C'était aussi le cas de GCC. »
Oui. Il n’y a pas de problème à intégrer des logiciels distribués sous licence GPL… à partir du moment où on les intègre sous forme de logiciels exécutables indépendants. Heureusement, là GPL n’est pas (encore ?) assez extrémiste pour interdire ça.
Mais pour un système de fichiers, ce n’est évidemment pas une approche envisageable. Même pour GCC, Apple a laissé tombé car cette approche montrait vite ses limites en matière d’intégration.
La GPL et la AGPL n'interdisent pas l'intégration de logiciels non "exécutables indépendants". Le copyleft fort, utilisé dans la GPL et la AGPL (mais pas dans la LGPL), contamine les travaux dérivés et les utilisation de ressources sous copyleft fort. Le but de la FSF et des gens du projet GNU n'est pas d'être intégré partout à tout prix, leur premier but est la liberté des utilisateurs, la popularité est vu par eux comme une satisfaction secondaire. https://www.gnu.org/copyleft/copyleft.html https://www.gnu.org/philosophy/why-not-lgpl.html
Dans le cas du noyau Linux, tous les logiciels utilisant un système de fichiers géré par le noyau ne sont pas soumis au copyleft fort de la GPLv2 (utilisé par le noyau Linux). Donc Apple devrait pouvoir faire la même chose sans libérer beaucoup plus que le code du système de fichiers.
Pour ce qui est de GCC, ce n'est pas un problème de licence en ce qui concerne l'intégration. J'ai lu que le code de GCC était vieux et trop monolithique, il a été pensé pour être un compilateur, mais pas pour donner des "API pour des résultats intermédiaires". De plus, GDB (GNU Debugger), qui est sous GPLv3+, est utilisé par Eclipse qui sous licence Eclipse Public License incompatible avec la GPL. https://fr.wikipedia.org/wiki/Eclipse_Public_License
@ RyDroid : « La GPL et la AGPL n'interdisent pas l'intégration de logiciels non "exécutables indépendants". »
Elles ne l’interdisent pas — elles la rendent juste impossible à réaliser, nuance. ;-)
« leur premier but est la liberté des utilisateurs »
Non. C’est la liberté du code — obtenue justement par quelques restrictions de la liberté de l’utilisateur (par rapport à la liberté quasi-totale que permet entre autres la licence BSD).
Supposition est fait que cette liberté du code est ensuite bénéfique à l’utilisateur.
« Donc Apple devrait pouvoir faire la même chose sans libérer beaucoup plus que le code du système de fichiers. »
Non.
« Pour ce qui est de GCC, ce n'est pas un problème de licence en ce qui concerne l'intégration. J'ai lu que le code de GCC était vieux et trop monolithique, il a été pensé pour être un compilateur, mais pas pour donner des "API pour des résultats intermédiaires". »
C’est là que le problème de licence intervenait : si GCC n’avait pas été sous GPL, il aurait été plus facile pour Apple d’aller taper directement où il fallait dans le code pour récupérer les informations qu’elles voulait, sans pour autant avoir à passer Xcode en GPL.
Tandis que la contrainte de devoir se limiter à la communication avec l’exécutable GCC rendait ça beaucoup moins faisable.
Ce n’était bien sûr pas le seul problème (le fait que GCC est développé pour énormément plus de choses que ce qu’Apple en faisait limitait beaucoup les possibilités d’Apple en matière de modifications), mais c’était bel et bien un problème.
Problème qu’on rencontre régulièrement avec les logiciels publiés sous GPL.
« De plus, GDB (GNU Debugger), qui est sous GPLv3+, est utilisé par Eclipse qui sous licence Eclipse Public License incompatible avec la GPL. »
Oui, de la même façon qu’il était utilisé par Xcode : en lançant l’exécutable GDB, et non en allant s’intégrer avec son code.
@Dark-marc
ZFS
Evidemment, ZFS...
Apple a déjà essayé il me semble, mais je sais pas pourquoi ils ont abandonné le projet... On parlait même du ZFS sur iOS il me semble...(je n'avais pas encore lu toute la news ;-)
Mais Linus a raison...
En fait le propos de Linux Torvald est de signaler que les logiciel qu'il contribue à écrire ne fonctionnent pas correctement sur des systèmes de fichiers insensibles à la casse (défaut pour NTFS depuis Windows NT et HFS+ pour Mac), et ne tournent correctement que sur un OS très peu répandu (GNU/Linux), prouvant qu'il a une méconnaissance totale de ce qu'est la notion de portabilité:
Ce n'est pas que tous les OS fonctionnent comme GNU/Linux pour que SES logiciels fonctionnent, mais que SES logiciels (à commencer par GIT) soient écrit correctement pour supporter les filesystem insensibles à la casse, ou qui ne supportent pas tous les systèmes d'encodages de chaînes de caractères.
En parlant de caractère, il est caractériel, mais des fois il devrait réfléchir un peu :)
GNU/Linux très peu rependu... OK cet OS est juste sur :
- 90% des serveurs Web du monde
- 3/4 des smartphones du monde
- sur la plus parts des supercalculateur du monde
- la majorité des box Internet/TV/NAS/...
- la plus part des robots aspirateurs
- Les smartTV
- les smartwatch
- beaucoup de console de jeux alternatives
- une bonne moitié des serveurs qui sont acheté dans le monde (je suis ingénieur système je vois bien Linux grignoter Solaris et Windows).
... je dois oublier beaucoup de choses
Quand on sait pas, on parle pas !
Et sur combien de ces ordinateurs spécialisés est utilisé effectivement GIT, en dehors des postes de développements, largement sous OS X ou Windows (et rarement sous Linux ou en VM) ?!? lol!
GIT est utilitaire pour le développement, initialement développé par Linus et une équipe pour le Kernel Linux et maintenant utilisé bien plus largement.
A noter que GNU/Linux supporte AUSSI des systèmes fichiers insensibles à la casse d'ailleurs, que comme tous les OS modernes (Windows NT jusqu'à Windows 10, OS X, BSD) on peut charger le filesystem qu'on souhaite utiliser, et que donc ça touche GNU/Linux AUSSI!
Quand on sait pas, on parle pas!
Bravo la mauvaise fois, je vous cite : "et ne tournent correctement que sur un OS très peu répandu (GNU/Linux)"
Ma réponse tout ce qui a de plus claire ne concerne que cette phrase : Linux est bel et bien l'OS largement le plus répandu actuellement largement devant Windows !
Concernant GIT, je n'ai pas d'avis particulier à exprimer.
Donc Android est GNU/Linux selon toi? Bonjour la mauvaise foi :)
Laisse tomber, tu n'as pas répondu sur le fond: la portabilité de GIT sous GNU/Linux, lorsqu'il utilise un système de fichier insensible à la casse (ou paramétré comme tel!). Juste un FAIL de Linus!
Ah.... et bien si ! Android est bel un bien un OS tournant sur un noyau GNU/Linux, ce n'est pas moi qui le dit, c'est Google : https://source.android.com/devices/
Linux Kernel
For the most part, developing your device drivers is the same as developing a typical Linux device driver. Android uses a specialized version of the Linux kernel with a few special additions such as wakelocks, a memory management system that is more agressive in preserving memory, the Binder IPC driver, and other features that are important for a mobile embedded platform like Android. These additions have less to do with driver development than with the system's functionality. You can use any version of the kernel that you want as long as it supports the required features, such as the binder driver. However, we recommend using the latest version of the Android kernel. For the latest Android kernel, see Building Kernels.
" Android est bel un bien un OS tournant sur un noyau GNU/Linux"
Pour être pointilleux, le noyau c'est Linux, pas GNU/Linux. GNU c'est un système d'exploitation sans noyau, développé par Stallman et ses potes.
La combinaison du système GNU et du noyau Linux (de Linus Torvalds) a donné un OS complet.
+1
Pour ceux voulant en savoir plus :
https://www.gnu.org/gnu/linux-and-gnu.html
https://www.gnu.org/philosophy/android-and-users-freedom.html
Le vrai fail c'est la fiabilité de ce système de fichier. Aujourd'hui j'ai trois sauvegardes différentes de mon Mac. D'après vous @iapx, si j'en suis là, c'est que j'ai jamais eu de plantage de mon système de fichiers ?
Quand au fait de ne pas tenir compte de la casse, à l'heure actuelle et vue la quantité d'informations et de développements, c'est juste une aberration. Aberration qui pose problème aux développeurs des logiciels que vous utilisez. Car git est utilisé par un nombre de développeurs extrêmement important (et pas seulement pour le noyau Linux, loin s'en faut).
Ne serait-ce que lorsque vous naviguez sur Internet, vous êtes un utilisateur indirect de ce logiciel.
Est-ce si difficile que cela d'accepter un point de vue différent du sien ? Ne serait-ce que parce qu'il nous fait avancer...
@ buluhab : « Quand au fait de ne pas tenir compte de la casse, à l'heure actuelle et vue la quantité d'informations et de développements, c'est juste une aberration »
Et pourquoi donc ?
Il est vraiment temps que certains développeurs modernisent leur vision du monde et des chaînes de caractères. Le temps de l’ASCII est loin (ou devrait l’être).
Oulah, au pire informe toi avant? Le noyau d'android n'est autre que linux.
Et puis, où est le mal à admettre avoir dit une bêtise, au passage?
"- 90% des serveurs Web du monde
…
- sur la plus parts des supercalculateur du monde"
Environ 17% sur les serveurs toutes utilisations confondues.
environ 33% sur les serveurs web (64% des serveurs web sont sous OS de type Unix, Linux compris).
Plus de 95% des supercalculateurs du TOP500 sont sous Linux.
interprétation de mauvaise foi.
-
L'insensibilité à la casse d'os X pour respecter l'héritage de os 9 est un problème inhérent de sécurité informatique.
Mais Apple a toujours réussi à s'en sortir parce que ce n'est pas un véritable vecteur de bug pour piratage avec Os X.
Non, le problème de HFS+ est qu'il est INADAPTE à la nouvelle réalité de l'information FAMILIALE : On stocke des documents et fichiers GIGANTESQUES
(les gens manipulant allègrement des des espaces en TERA maintenant, pour des fichiers faisant facilement des dizaines ou centaines de mo)
cela a des conséquences, car le matériel lui n'a pas réellement évolué en fiabilité.
je parle de fiabilité en fonctionnement quotidien, pour un matériel de qualité sans défaut de fabrication : il est fonctionnel, bien comme prévu : il fait quand même des fautes régulièrement, dans sa marge prévue. même un infime % d'erreur devient maintenant TROP !
Car on utilise BEAUCOUP plus le stockage numérique pour des besoins BEAUCOUP plus grands pour des choses BEAUCOUP plus importantes qu'il y a 15 ans. Et ça s'accélère.
Le système de fichier doit le prévoir et gérer l'erreur matérielle et avoir des moyens de corrections sophistiqués ET automatiques.
Pages