Ce n’est pas vraiment que ca arrangeait les constructeurs de disques dur, mais c’est Windows qui a un bug: Sur les autres OS on a bien les bonnes données constructeurs d’affiches.
Ah ben bug de cache du forum et grilled 50 fois
C’est facile à dire à posteriori aujourd’hui. Mais c’est pas du tout comme ça que ça c’est passé en réalité.
Historiquement dans le monde informatique, TOUT LE MONDE comptait par 1024. Et ce bien avant Windows. Parce que les capacités étaient naturellement des multiples de 1024, parce que ça nécessitait aussi moins de puissance pour diviser par 1024 que par 1000 (on parle d’une époque où certains CPU n’avaient même pas d’instruction pour faire une division, alors que diviser par 1024 c’est juste un shift de 10 bits) et parce que sur des petites capacités, l’écart entre diviser par 1000 ou 1024 était pas bien grand.
Même les fabricants de disques durs et de disquettes comptaient comme ça (oui oui, reprend des vieux disques durs de l’époque où ça se comptait en Ko, tu verras…). Et TOUS les OS comptaient comme ça.
Ensuite, dans les années 80-90 les fabricants de stockage de masse se sont mis à diviser par 1000 pour le passage des Ko aux Mo (et initialement uniquement pour lui… les Ko étaient au début toujours comptés à 1024 octets, parce que ça faisait 2 secteurs => ils divisaient le nombre de secteurs par 2000 pour donner la capacité en Mo°), parce que ça donnait des chiffres plus gros. Pour les disques optiques, le passage à une division par 1000 est arrivé encore plus tard, avec les DVD, alors que les CD avaient bien une capacité calculée en divisant par 1024 (sauf quelques fabricants rusés qui affichaient 680/730 Mo contre 650/700 Mo chez les concurrents).
Puis le CEI s’en est mêlé en introduisant les préfixes binaires, en 1999, parce qu’avec les capacités qui se comptaient désormais en Go, l’écart entre les deux modes de calcul n’était plus du tout négligeable. Mais c’est relativement récent donc…
Jusqu’à l’arrivée des préfixes binaires, TOUS les OS calculaient en 1024 et étaient donc « faux » au sens des préfixes SI (mais pour rappel, l’octet n’est pas une unité du SI…). Et ils ont encore mis une décennie avant de changer.
Ce n’est qu’une dizaine d’années après l’intervention du CEI que les OS ont commencé à changer. Sur macOS, c’est en 2009 (10.6) que le changement a été fait, en gardant les préfixes SI et en calculant avec un facteur 1000 au lieu de 1024. Ce qui a perturbé pas mal de monde (j’ai bien suivi la transition, j’étais sur Mac à l’époque), parce que du jour au lendemain, en mettant simplement à jour l’OS, toutes les tailles de fichiers ont « augmenté »… Mais ce changement ne concerne que le stockage de masse. Pour la RAM, les informations système de macOS continuent à calculer en divisant par 1024 et à afficher le préfixe SI, pas le préfixe binaire… Apple a encore eu besoin de 7 ans de plus pour passer à la division par 1000 sur iOS (iOS 10, 2016) et utilise encore la division par 1024 sur watchOS (cf le site d’Apple).
Et côté Linux, c’est aussi à peu près à cette période que ça a été modifié… Sauf que là c’est le bordel, parce que multiplicité des communautés encadrant les différents composants oblige, il n’y a plus aucune cohérence… Tu en as qui sont allés au plus simple, ils ont gardé les divisions par 1024 et mis les préfixes binaires (par exemple, les commandes top, free, lscpu…), tu en as qui sont restés sur l’ancien mode par souci de compatibilité (par exemple, sur mon Ubuntu 20.04, du -h, df -h ou ls -l --block-size=K font des divisions par 1024), tu en as, plus rares, qui sont passés à une division par 1000 (pas d’exemple qui me vienne directement…). Bref, c’est un joyeux bordel, finalement bien pire que le statu quo de Microsoft…
4 commandes de base de l’OS, 3 affichages différents (une qui affiche l’unité « complète » avec préfixe binaire, une qui affiche uniquement le préfixe binaire sans l’unité, sauf quand il n’y a pas de préfixe, deux qui affichent uniquement le préfixe non binaire, mais qui calculent quand même en divisant par 1024).
C’est là qu’on se rend compte qu’il n’y a pas de solution idéale, et que tout changement, qu’il soit dans le mode de calcul ou dans les unités affichées risque de perturber l’utilisateur, mais aussi de provoquer des dysfonctionnement (imagine un script qui parse la sortie d’une commande pour récupérer une info… si la commande de base change son mode de calcul ou l’unité, ça peut foutre en l’air le script). Ce qui peut expliquer la décision de Microsoft de ne toucher à rien…
Alors résumer ça à « Windows qui a un bug », c’est vraiment excessivement réducteur, c’est oublier tout ce qu’il s’est passé des années 60 aux années 2000, mais aussi oublier les incohérences qu’on trouve sur les autres OS : certes Windows n’affiche pas les bons préfixes, mais c’est le seul à utiliser TOUJOURS le même mode de calcul, et pas l’un ou l’autre selon le type d’espace de stockage qu’on mesure ou selon l’humeur de celui qui a développé tel ou tel composant du système.
° exemple flagrant avec les disquettes 3.5" : les disquettes « double densité » avaient 2 faces de 80 pistes de 9 secteurs de 512 octets, soit 737 280 octets, vendus par les constructeurs comme faisant 720 Ko, donc en divisant par 1024, tandis que les « haute densité » exactement le double, en passant à 18 secteurs par piste, mais étaient vendus comme faisant 1.44 Mo, donc en divisant par 1024 puis par 1000…
2 « J'aime »