Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
schon aufgefallen? SnowLeopard zeigt HDD-Größe als 1. OS korrekt an
Apple hat offenbar als erster Betriebssystemmaintainer verstanden, dass Kilo, Mega Giga usw. dezimale Präfixe sind und es auch Quatsch ist, die Bits auf Festplatten, die mit jedem möglichen System adressiert werden können, mit dem Binäürsystem eines Prozessors zu zählen. Deswegen zeigt Mac OS X 10.6 Snow Leopard als erstes OS die festplattengrößen jetzt korrekt an. Snow Leopard fixes disk capacity bug
Was heißt hier Quatsch? Das Binärsystem wird in der Informatik seit Anbeginn der Zeit verwendet. Erst später kamen irgendwelche Technikfremden auf die Idee, die Einheiten unbedingt im 10er System darstellen zu müssen.
Trotzdem ist es sinnvoller, zwischen binären Präfixen und dezimalen zu unterscheiden. Für Technikfremde Appleuser ists sinnvoller wenn sie bei der Angabe KB wie sonst überall auch Basis 10 haben, und technophilen ist es zumutbar Binärpräfixe zu verwenden (so wie es viele OpenSource-Programme mitterweile tun).
Dass in der Informatik die Einheiten eigentlich falsch verwendet wurden, hat nur bisher kaum jemand kritisiert. Erst als bei Festplatten 'richtig' gerechnet wurde, ist das vielen Benutzern aufgefallen, als zB. ihre TByte HD offenbar keinen TByte an Daten fassen konnte.
Schon seinerzeit gab's 1,44er 3,5" Floppy Disks, auf denen bloss 1,38 MByte an Daten Platz fanden ...
Quatsch weil, ich zitiere mal aus dem Kommentar, den ich verlinkt habe:
Robin Harris schrieb:
Main memory is measured in base 2 as well - 1 KB of RAM is actually 1024 bytes - because most processors access memory in base 2 chunks - 8, 16, 32 or 64 bits - and it simplifies the internal math to use the same base 2 that the processor uses.
But disks are just a box of bytes that can be formatted many different ways. For example, a vendor can choose to store data in 20-bit chunks - 16 for data and 4 for extra ECC - which reduces the available capacity but not the raw capacity that disk vendor shipped.
20b ist nicht durch 8 teilbar, hier macht ein dezimales Kilo Sinn.
@ Creshal
Danke für den Hinweis. Hab grad schnell mal gekuckt, und Dolphin zeigt mir eine 500 GB Platte tatsächlich als 465,8 GiB an.
P.S.
Aber auf Linux ist die Soße noch ziemlich inkonsistent, Dolphin und GParted zeigen mir GiB korrekt an, HD Parm kennt die Si-Präfixe nicht und gibt zweimal "GBytes" aus, wobei es einmal die Nennung der Zählweise 1000*1000 und einmal 1024*1024 vorranstellt, Nautilus zeigt die falschen "465 GB" - also ISO Dezimalpräfix für Binärangabe. Das Partitionsverwaltungswerkzeug von mandriva zeigt ebenfalls noch die falschen 465 GB an.
Aber auf Linux ist die Soße noch ziemlich inkonsistent, Dolphin und GParted zeigen mir GiB korrekt an, HD Parm kennt die Si-Präfixe nicht und gibt zweimal "GBytes" aus, wobei es einmal die Nennung der Zählweise 1000*1000 und einmal 1024*1024 vorranstellt, Nautilus zeigt die falschen "465 GB" - also ISO Dezimalpräfix für Binärangabe. Das Partitionsverwaltungswerkzeug von mandriva zeigt ebenfalls noch die falschen 465 GB an.
Gut, bei Linux hängts vom jeweiligen Entwickler ab ob er es korrekt umsetzt oder nicht (ich benutz seit Jahren weder KDE noch Gnome, daher hab ich keine Ahnung wie die das handhaben), aber zumindest die GNU coreutils zeigen es korrekt an (und bieten die Möglichkeit zwischen den Basen zu wechseln).
So wie hdparm? Ich mein, das Programm spuckt einfach beide Zahlen aus und schreibt hinter beide Zahlen "GBytes", schreibt nur umständlich davor "1000*1000" oder "1024*1024".
