Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #275930 > unrolled thread
| Started by | "Roy J. Tellason, Sr." <roy@rtellason.com> |
|---|---|
| First post | 2024-12-21 18:50 +0100 |
| Last post | 2024-12-22 17:20 +0100 |
| Articles | 20 on this page of 132 — 31 participants |
Back to article view | Back to linux.debian.user
new computer arriving soon "Roy J. Tellason, Sr." <roy@rtellason.com> - 2024-12-21 18:50 +0100
Re: new computer arriving soon "Andrew M.A. Cater" <amacater@einval.com> - 2024-12-21 20:30 +0100
Re: new computer arriving soon Joe <joe@jretrading.com> - 2024-12-21 21:20 +0100
Re: new computer arriving soon "Roy J. Tellason, Sr." <roy@rtellason.com> - 2024-12-22 02:20 +0100
Re: new computer arriving soon "Roy J. Tellason, Sr." <roy@rtellason.com> - 2024-12-22 02:20 +0100
UEFI, Export from Virtualbox [WAS Re: new computer arriving soon] "Andrew M.A. Cater" <amacater@einval.com> - 2024-12-22 09:50 +0100
Re: new computer arriving soon "Roy J. Tellason, Sr." <roy@rtellason.com> - 2024-12-26 20:40 +0100
Re: new computer arriving soon David Christensen <dpchrist@holgerdanske.com> - 2024-12-26 23:40 +0100
Re: new computer arriving soon David Wright <deblis@lionunicorn.co.uk> - 2024-12-27 17:30 +0100
Re: new computer arriving soon Marc Shapiro <marcnshap@gmail.com> - 2024-12-31 05:10 +0100
Re: new computer arriving soon gene heskett <gheskett@shentel.net> - 2024-12-31 05:40 +0100
Re: new computer arriving soon "Andrew M.A. Cater" <amacater@einval.com> - 2024-12-31 19:00 +0100
Re: new computer arriving soon gene heskett <gheskett@shentel.net> - 2024-12-31 23:00 +0100
Re: new computer arriving soon "Andrew M.A. Cater" <amacater@einval.com> - 2025-01-01 00:00 +0100
Re: new computer arriving soon gene heskett <gheskett@shentel.net> - 2025-01-01 01:00 +0100
Re: new computer arriving soon pocket@homemail.com - 2025-01-01 15:00 +0100
Re: new computer arriving soon Frank Guthausen <fg.debian@shimps.de> - 2025-01-01 15:30 +0100
Re: new computer arriving soon pocket@homemail.com - 2025-01-01 15:40 +0100
Re: new computer arriving soon Michael Stone <mstone@debian.org> - 2025-01-01 16:40 +0100
Re: new computer arriving soon pocket@homemail.com - 2025-01-01 17:20 +0100
Re: new computer arriving soon Michael Stone <mstone@debian.org> - 2025-01-01 18:00 +0100
Re: new computer arriving soon pocket@homemail.com - 2025-01-01 18:00 +0100
Re: new computer arriving soon Max Nikulin <manikulin@gmail.com> - 2025-01-02 03:10 +0100
Re: new computer arriving soon pocket@homemail.com - 2025-01-02 03:40 +0100
Re: new computer arriving soon Charles Curley <charlescurley@charlescurley.com> - 2025-01-01 17:30 +0100
Re: new computer arriving soon Michael Stone <mstone@debian.org> - 2025-01-01 18:20 +0100
Re: new computer arriving soon gene heskett <gheskett@shentel.net> - 2025-01-01 22:00 +0100
Re: new computer arriving soon Joe <joe@jretrading.com> - 2025-01-01 19:50 +0100
Re: new computer arriving soon gene heskett <gheskett@shentel.net> - 2025-01-01 22:50 +0100
Re: new computer arriving soon Andy Smith <andy@strugglers.net> - 2025-01-02 14:50 +0100
Re: new computer arriving soon gene heskett <gheskett@shentel.net> - 2025-01-03 04:00 +0100
Re: new computer arriving soon gene heskett <gheskett@shentel.net> - 2025-01-03 17:30 +0100
Re: new computer arriving soon Andy Smith <andy@strugglers.net> - 2025-01-03 13:10 +0100
Re: new computer arriving soon Max Nikulin <manikulin@gmail.com> - 2025-01-02 03:30 +0100
Re: new computer arriving soon pocket@homemail.com - 2025-01-02 03:40 +0100
Re: new computer arriving soon Max Nikulin <manikulin@gmail.com> - 2025-01-02 04:30 +0100
Re: new computer arriving soon pocket@homemail.com - 2025-01-02 04:50 +0100
Re: new computer arriving soon Max Nikulin <manikulin@gmail.com> - 2025-01-02 16:40 +0100
Re: new computer arriving soon pocket@homemail.com - 2025-01-02 17:10 +0100
Re: new computer arriving soon Max Nikulin <manikulin@gmail.com> - 2025-01-04 05:00 +0100
Re: new computer arriving soon gene heskett <gheskett@shentel.net> - 2025-01-04 11:20 +0100
Gene and networkmanager (was: Re: new computer arriving soon) Max Nikulin <manikulin@gmail.com> - 2025-01-05 04:50 +0100
Re: Gene and networkmanager (was: Re: new computer arriving soon) gene heskett <gheskett@shentel.net> - 2025-01-05 17:20 +0100
/dev/serial/by-id (was: Re: new computer arriving soon) Max Nikulin <manikulin@gmail.com> - 2025-01-05 05:00 +0100
Re: /dev/serial/by-id (was: Re: new computer arriving soon) gene heskett <gheskett@shentel.net> - 2025-01-05 17:30 +0100
Re: /dev/serial/by-id Max Nikulin <manikulin@gmail.com> - 2025-01-06 03:30 +0100
Re: /dev/serial/by-id gene heskett <gheskett@shentel.net> - 2025-01-06 08:20 +0100
Re: /dev/serial/by-id Max Nikulin <manikulin@gmail.com> - 2025-01-07 04:20 +0100
Re: /dev/serial/by-id gene heskett <gheskett@shentel.net> - 2025-01-07 10:00 +0100
Re: /dev/serial/by-id gene heskett <gheskett@shentel.net> - 2025-01-07 14:50 +0100
Mass storage sizes (was: /dev/serial/by-id) Stefan Monnier <monnier@iro.umontreal.ca> - 2025-01-07 16:10 +0100
Re: Mass storage sizes (was: /dev/serial/by-id) Dan Purgert <dan@djph.net> - 2025-01-07 16:50 +0100
Re: Mass storage sizes eben@gmx.us - 2025-01-07 17:10 +0100
Re: Mass storage sizes <tomas@tuxteam.de> - 2025-01-07 17:40 +0100
Re: Mass storage sizes eben@gmx.us - 2025-01-07 18:00 +0100
Re: Mass storage sizes Stefan Monnier <monnier@iro.umontreal.ca> - 2025-01-07 20:40 +0100
Re: Mass storage sizes <tomas@tuxteam.de> - 2025-01-08 06:30 +0100
Re: Mass storage sizes (was: /dev/serial/by-id) Michael Stone <mstone@debian.org> - 2025-01-07 17:10 +0100
Re: Mass storage sizes (was: /dev/serial/by-id) Michael Stone <mstone@debian.org> - 2025-01-07 17:30 +0100
Re: Mass storage sizes (was: /dev/serial/by-id) Dan Purgert <dan@djph.net> - 2025-01-07 18:10 +0100
Re: Mass storage sizes (was: /dev/serial/by-id) Nicholas Geovanis <nickgeovanis@gmail.com> - 2025-01-09 04:10 +0100
Re: Mass storage sizes (was: /dev/serial/by-id) Michael Stone <mstone@debian.org> - 2025-01-09 05:50 +0100
Re: Mass storage sizes Stefan Monnier <monnier@iro.umontreal.ca> - 2025-01-09 16:30 +0100
Re: Mass storage sizes Dan Purgert <dan@djph.net> - 2025-01-09 18:10 +0100
Re: Mass storage sizes (was: /dev/serial/by-id) Nicolas George <george@nsup.org> - 2025-01-09 21:50 +0100
Re: Mass storage sizes (was: /dev/serial/by-id) Michael Stone <mstone@debian.org> - 2025-01-10 00:50 +0100
Re: Mass storage sizes (was: /dev/serial/by-id) Jeffrey Walton <noloader@gmail.com> - 2025-01-10 01:10 +0100
Re: Mass storage sizes (was: /dev/serial/by-id) Timothy M Butterworth <timothy.m.butterworth@gmail.com> - 2025-01-10 02:10 +0100
Re: Mass storage sizes (was: /dev/serial/by-id) Dan Purgert <dan@djph.net> - 2025-01-10 11:00 +0100
Re: Mass storage sizes (was: /dev/serial/by-id) gene heskett <gheskett@shentel.net> - 2025-01-10 15:10 +0100
Re: Mass storage sizes (was: /dev/serial/by-id) <tomas@tuxteam.de> - 2025-01-10 07:30 +0100
Re: Mass storage sizes John Hasler <john@sugarbit.com> - 2025-01-10 15:50 +0100
Re: Mass storage sizes eben@gmx.us - 2025-01-10 21:40 +0100
Re: Mass storage sizes gene heskett <gheskett@shentel.net> - 2025-01-11 01:50 +0100
Re: Mass storage sizes Jeffrey Walton <noloader@gmail.com> - 2025-01-11 01:40 +0100
Re: Mass storage sizes (was: /dev/serial/by-id) Heriberto Avelino <heriberto.avelino@gmail.com> - 2025-01-10 01:30 +0100
Re: Mass storage sizes Kushal Kumaran <kushal@locationd.net> - 2025-01-07 20:20 +0100
Re: Mass storage sizes Nicolas George <george@nsup.org> - 2025-01-07 21:10 +0100
Re: Mass storage sizes Michael Stone <mstone@debian.org> - 2025-01-07 23:10 +0100
Re: Mass storage sizes Urs Thuermann <urs@isnogud.escape.de> - 2025-01-10 03:00 +0100
Re: Mass storage sizes Michael Stone <mstone@debian.org> - 2025-01-10 05:30 +0100
Re: Mass storage sizes Stefan Monnier <monnier@iro.umontreal.ca> - 2025-01-10 15:40 +0100
Re: Mass storage sizes Charles Curley <charlescurley@charlescurley.com> - 2025-01-07 23:10 +0100
Re: Mass storage sizes gene heskett <gheskett@shentel.net> - 2025-01-08 00:30 +0100
Re: Mass storage sizes "Thomas Schmitt" <scdbackup@gmx.net> - 2025-01-07 17:40 +0100
Re: Mass storage sizes Stefan Monnier <monnier@iro.umontreal.ca> - 2025-01-07 20:30 +0100
Re: Mass storage sizes (was: /dev/serial/by-id) Jeffrey Walton <noloader@gmail.com> - 2025-01-09 08:40 +0100
Re: /dev/serial/by-id Max Nikulin <manikulin@gmail.com> - 2025-01-08 04:00 +0100
Re: /dev/serial/by-id Max Nikulin <manikulin@gmail.com> - 2025-01-08 04:10 +0100
Re: /dev/serial/by-id Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2025-01-07 11:20 +0100
Specific mdadm instructions for Gene [WAS Re: new computer arriving soon] "Andrew M.A. Cater" <amacater@einval.com> - 2025-01-02 17:00 +0100
Re: Specific mdadm instructions for Gene [WAS Re: new computer arrivingsoon] gene heskett <gheskett@shentel.net> - 2025-01-02 23:10 +0100
Re: Specific mdadm instructions for Gene [WAS Re: new computer arrivingsoon] Andy Smith <andy@strugglers.net> - 2025-01-02 23:20 +0100
Re: Specific mdadm instructions for Gene [WAS Re: new computer arrivingsoon] Nicolas George <george@nsup.org> - 2025-01-02 23:30 +0100
Re: Specific mdadm instructions for Gene [WAS Re: new computer arrivingsoon] Michael Stone <mstone@debian.org> - 2025-01-03 00:10 +0100
Re: Specific mdadm instructions for Gene [WAS Re: new computer arrivingsoon] Jeffrey Walton <noloader@gmail.com> - 2025-01-03 04:00 +0100
Re: Specific mdadm instructions for Gene [WAS Re: new computerarrivingsoon] gene heskett <gheskett@shentel.net> - 2025-01-03 05:00 +0100
Re: Specific mdadm instructions for Gene [WAS Re: new computerarrivingsoon] Andy Smith <andy@strugglers.net> - 2025-01-03 14:00 +0100
Re: Specific mdadm instructions for Gene [WAS Re: new computer arrivingsoon] Max Nikulin <manikulin@gmail.com> - 2025-01-03 03:40 +0100
Re: Specific mdadm instructions for Gene [WAS Re: new computerarrivingsoon] gene heskett <gheskett@shentel.net> - 2025-01-03 05:10 +0100
Re: Specific mdadm instructions for Gene [WAS Re: new computerarrivingsoon] Max Nikulin <manikulin@gmail.com> - 2025-01-04 04:30 +0100
Re: Specific mdadm instructions for Gene [WAS Re: newcomputerarrivingsoon] gene heskett <gheskett@shentel.net> - 2025-01-04 04:50 +0100
sgdisk missing under Armbian for Gene [WAS Specific mdadm instructions for Gene] "Andrew M.A. Cater" <amacater@einval.com> - 2025-01-03 12:40 +0100
Re: sgdisk missing under Armbian for Gene [WAS Specific mdadm instructions for Gene] Nicolas George <george@nsup.org> - 2025-01-03 12:50 +0100
Re: sgdisk missing under Armbian for Gene [WAS Specific mdadminstructions for Gene] gene heskett <gheskett@shentel.net> - 2025-01-03 17:40 +0100
Re: new computer arriving soon Max Nikulin <manikulin@gmail.com> - 2025-01-02 04:00 +0100
Re: new computer arriving soon gene heskett <gheskett@shentel.net> - 2025-01-02 05:30 +0100
Re: new computer arriving soon George at Clug <Clug@goproject.info> - 2025-01-02 08:30 +0100
Re: new computer arriving soon Michael Stone <mstone@debian.org> - 2025-01-02 23:40 +0100
Re: new computer arriving soon fxkl47BF@protonmail.com - 2025-01-02 23:50 +0100
Re: new computer arriving soon George at Clug <Clug@goproject.info> - 2025-01-03 00:00 +0100
Re: new computer arriving soon Michael Stone <mstone@debian.org> - 2025-01-03 00:20 +0100
Re: new computer arriving soon George at Clug <Clug@goproject.info> - 2025-01-03 00:50 +0100
Re: new computer arriving soon "Roy J. Tellason, Sr." <roy@rtellason.com> - 2025-01-03 17:00 +0100
Re: new computer arriving soon Michael Stone <mstone@debian.org> - 2025-01-03 17:20 +0100
Re: new computer arriving soon David Wright <deblis@lionunicorn.co.uk> - 2025-01-10 05:50 +0100
Re: new computer arriving soon Greg Wooledge <greg@wooledge.org> - 2025-01-03 00:10 +0100
Re: new computer arriving soon George at Clug <Clug@goproject.info> - 2025-01-03 00:00 +0100
Re: new computer arriving soon Michael Stone <mstone@debian.org> - 2025-01-03 00:00 +0100
Re: new computer arriving soon George at Clug <Clug@goproject.info> - 2025-01-03 00:40 +0100
Re: new computer arriving soon Andy Smith <andy@strugglers.net> - 2025-01-03 00:50 +0100
Re: new computer arriving soon "Roy J. Tellason, Sr." <roy@rtellason.com> - 2025-01-03 17:00 +0100
Re: new computer arriving soon Max Nikulin <manikulin@gmail.com> - 2025-01-02 16:30 +0100
Re: new computer arriving soon Frank Guthausen <fg.debian@shimps.de> - 2024-12-31 20:20 +0100
Re: new computer arriving soon Max Nikulin <manikulin@gmail.com> - 2025-01-02 04:10 +0100
Re: new computer arriving soon Michael Stone <mstone@debian.org> - 2025-01-02 23:50 +0100
Re: new computer arriving soon Marc Shapiro <marcnshap@gmail.com> - 2025-01-06 06:10 +0100
Re: new computer arriving soon "Roy J. Tellason, Sr." <roy@rtellason.com> - 2024-12-27 20:20 +0100
Re: new computer arriving soon George at Clug <Clug@goproject.info> - 2024-12-22 00:40 +0100
Re: new computer arriving soon "Roy J. Tellason, Sr." <roy@rtellason.com> - 2024-12-22 02:30 +0100
Re: new computer arriving soon George at Clug <Clug@goproject.info> - 2024-12-22 05:50 +0100
Re: new computer arriving soon songbird <songbird@anthive.com> - 2024-12-22 17:20 +0100
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | Nicholas Geovanis <nickgeovanis@gmail.com> |
|---|---|
| Date | 2025-01-09 04:10 +0100 |
| Subject | Re: Mass storage sizes (was: /dev/serial/by-id) |
| Message-ID | <K2R5L-6Mzo-1@gated-at.bofh.it> |
| In reply to | #276394 |
[Multipart message — attachments visible in raw view] — view raw
On Tue, Jan 7, 2025, 1:27 PM Dan Purgert <dan@djph.net> wrote: > > > TB is about 10% larger. One of the worst crimes in computer history > > was ever talking about storage in powers of 2, I really wish it would > > just go away. It has properties that nobody wants and has been the > > source of endless confusion, for really no benefits whatsoever. This makes no sense. The number has the same value no matter which base is chosen. These are integers, there is no fractional part, so there is no "uncertainty" about its value. People who need to work with binary integers usually choose to calculate with them in base 8 or base 16 then convert them back to base 2. Which does not require calculation just copying.
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2025-01-09 05:50 +0100 |
| Subject | Re: Mass storage sizes (was: /dev/serial/by-id) |
| Message-ID | <K2SEx-6Nqh-3@gated-at.bofh.it> |
| In reply to | #276424 |
On Wed, Jan 08, 2025 at 09:04:09PM -0600, Nicholas Geovanis wrote: > > TB is about 10% larger. One of the worst crimes in computer history > > was ever talking about storage in powers of 2, I really wish it would > > just go away. It has properties that nobody wants and has been the > > source of endless confusion, for really no benefits whatsoever. > >This makes no sense. The number has the same value no matter which base is >chosen. These are integers, there is no fractional part, so there is no >"uncertainty" about its value. People who need to work with binary integers >usually choose to calculate with them in base 8 or base 16 then convert them >back to base 2. Which does not require calculation just copying. For example...let's take the 18000000000000B drive discussed earlier. That's 18TB or 16TiB. Annoying, but ok. Now that's also 18000MB but 16763MiB. And it's 18000000MB or 17166137MiB. So if you have a display in MB and you want to know the value in TB you move the decimal 6 places. But if you move the decimal 6 places to get from MiB to TiB you get...the wrong answer. Does this actually happen? Yes. All the freaking time. (A classic mashup is 1024k blocks expressed with power of 10 M and G.) Now this next part is important: no normal human working with files and disk space and trying to communicate with other normal humans calculates the values in base 8 or base 16. Communication of numbers between ordinary people generally happens in base 10. SI prefixes are base 10. And when you munge up some stupid base 2 units with what people want and expect to be base 10, mistakes and confusion happen. And the benefit of all that confusion and increased cognative load is: absolutely nothing.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-01-09 16:30 +0100 |
| Subject | Re: Mass storage sizes |
| Message-ID | <K32DT-6VZ7-13@gated-at.bofh.it> |
| In reply to | #276425 |
> For example...let's take the 18000000000000B drive discussed earlier. That's
> 18TB or 16TiB. Annoying, but ok. Now that's also 18000MB but 16763MiB. And
> it's 18000000MB or 17166137MiB. So if you have a display in MB and you want
> to know the value in TB you move the decimal 6 places. But if you move the
> decimal 6 places to get from MiB to TiB you get...the wrong answer. Does
> this actually happen? Yes. All the freaking time. (A classic mashup is 1024k
> blocks expressed with power of 10 M and G.)
🙂
A related problem is when writing code which displays such sizes in
a human readable way, for example a "speedometer" displaying the number
of bytes per second with a limited amount of space. A common choice is
to use 3 chars for the number plus a unit, i.e. things like "254 kB/s"
or "1.5 MB/s". Now, if you use the "1024" multiplier, you get a funny
quirk when the current speed is, say 1003 kB/s, because "1003 kB/s" uses
one char too many, yet we haven't reached "1.0 MB/s" either.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2025-01-09 18:10 +0100 |
| Subject | Re: Mass storage sizes |
| Message-ID | <K34cF-6YxD-1@gated-at.bofh.it> |
| In reply to | #276433 |
[Multipart message — attachments visible in raw view] — view raw
On Jan 09, 2025, Stefan Monnier wrote: > > For example...let's take the 18000000000000B drive discussed earlier. That's > > 18TB or 16TiB. Annoying, but ok. Now that's also 18000MB but 16763MiB. And > > it's 18000000MB or 17166137MiB. So if you have a display in MB and you want > > to know the value in TB you move the decimal 6 places. But if you move the > > decimal 6 places to get from MiB to TiB you get...the wrong answer. Does > > this actually happen? Yes. All the freaking time. (A classic mashup is 1024k > > blocks expressed with power of 10 M and G.) > > 🙂 > > A related problem is when writing code which displays such sizes in > a human readable way, for example a "speedometer" displaying the number > of bytes per second with a limited amount of space. A common choice is > to use 3 chars for the number plus a unit, i.e. things like "254 kB/s" > or "1.5 MB/s". Now, if you use the "1024" multiplier, you get a funny > quirk when the current speed is, say 1003 kB/s, because "1003 kB/s" uses > one char too many, yet we haven't reached "1.0 MB/s" either. Thankfully, networking stuck with base-10 numbers for bitrates. -- |_|O|_| |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860
[toc] | [prev] | [next] | [standalone]
| From | Nicolas George <george@nsup.org> |
|---|---|
| Date | 2025-01-09 21:50 +0100 |
| Subject | Re: Mass storage sizes (was: /dev/serial/by-id) |
| Message-ID | <K37Dz-75oL-9@gated-at.bofh.it> |
| In reply to | #276433 |
Michael Stone (12025-01-08): > For example...let's take the 18000000000000B drive discussed earlier. That's > 18TB or 16TiB. Annoying, but ok. Now that's also 18000MB but 16763MiB. And > it's 18000000MB or 17166137MiB. So if you have a display in MB and you want > to know the value in TB you move the decimal 6 places. But if you move the > decimal 6 places to get from MiB to TiB you get...the wrong answer. Does > this actually happen? Yes. All the freaking time. (A classic mashup is 1024k > blocks expressed with power of 10 M and G.) Now this next part is important: > no normal human working with files and disk space and trying to communicate > with other normal humans calculates the values in base 8 or base 16. > Communication of numbers between ordinary people generally happens in base > 10. SI prefixes are base 10. And when you munge up some stupid base 2 units > with what people want and expect to be base 10, mistakes and confusion > happen. And the benefit of all that confusion and increased cognative load > is: absolutely nothing. The thing is, for people who _expect_ rather than _know_ about this, 10% accuracy is plenty enough. Especially since, as has been pointed, a lot of factors will conspire to reduce the space available in practice. For the people who need exact figures, on the other hand, binary units are much more convenient, not just to measure the size of memory modules: alignment requirements, maximum sizes of files and devices, size of stripes, they are all based on powers of two. Stefan Monnier (12025-01-09): > A related problem is when writing code which displays such sizes in > a human readable way, for example a "speedometer" displaying the number > of bytes per second with a limited amount of space. A common choice is > to use 3 chars for the number plus a unit, i.e. things like "254 kB/s" > or "1.5 MB/s". Now, if you use the "1024" multiplier, you get a funny > quirk when the current speed is, say 1003 kB/s, because "1003 kB/s" uses > one char too many, yet we haven't reached "1.0 MB/s" either. Well, “1.5” is too few significant digits in the first place. So, you start: 100 M 999 M 1000 M 1024 M 1.59 G 9.99 G 10.0 G 99.9 G 100 G 999 G 1000 G The switch to the next prefix does not have to be as soon as the mantissa is greater than one. Notice that the heights of mountains are in meters, not in kilometers, even for the Himalaya. It is better to go to 9999 M and only then switch to 9.77 G: more significant digits, not less readable. (Also, the people who designed the symbols for the prefixes really dropped the ball with k instead of K, but that predates memory units by a long time.) -- Nicolas George
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2025-01-10 00:50 +0100 |
| Subject | Re: Mass storage sizes (was: /dev/serial/by-id) |
| Message-ID | <K3arL-79TY-1@gated-at.bofh.it> |
| In reply to | #276436 |
On Thu, Jan 09, 2025 at 09:47:11PM +0100, Nicolas George wrote: >For the people who need exact figures, on the other hand, binary units >are much more convenient, not just to measure the size of memory >modules: alignment requirements, maximum sizes of files and devices, >size of stripes, they are all based on powers of two. Baloney. People who need to worry about those things are/should be doing that programatically and absolutely do not "need" GiB for anything at all, certainly not for display. For everyone else, basically all the time and in every situation, power of ten units make more sense. The entire computing world has been saddled with this "but a computer kilobyte is really" nonsense far too long, and it actively hurts UX for everyone other than the vanishingly small set of people who won't shut up about how important it is to keep that anachronism.
[toc] | [prev] | [next] | [standalone]
| From | Jeffrey Walton <noloader@gmail.com> |
|---|---|
| Date | 2025-01-10 01:10 +0100 |
| Subject | Re: Mass storage sizes (was: /dev/serial/by-id) |
| Message-ID | <K3aL7-7aJ4-3@gated-at.bofh.it> |
| In reply to | #276437 |
On Thu, Jan 9, 2025 at 6:45 PM Michael Stone <mstone@debian.org> wrote: > > On Thu, Jan 09, 2025 at 09:47:11PM +0100, Nicolas George wrote: > >For the people who need exact figures, on the other hand, binary units > >are much more convenient, not just to measure the size of memory > >modules: alignment requirements, maximum sizes of files and devices, > >size of stripes, they are all based on powers of two. > > Baloney. People who need to worry about those things are/should be doing > that programatically and absolutely do not "need" GiB for anything at > all, certainly not for display. For everyone else, basically all the > time and in every situation, power of ten units make more sense. The > entire computing world has been saddled with this "but a computer > kilobyte is really" nonsense far too long, and it actively hurts UX for > everyone other than the vanishingly small set of people who won't shut > up about how important it is to keep that anachronism. Or it could be precision of terms. Powers of two precisely describes the storage, sans what is held back for swapping bad sectors. I've never seen powers of 10 marketing literature describe a drive as 465.661 GB (500 GiB). The marketing literature will round up, call it GB, and then say actual size may be less than advertised. Jeff
[toc] | [prev] | [next] | [standalone]
| From | Timothy M Butterworth <timothy.m.butterworth@gmail.com> |
|---|---|
| Date | 2025-01-10 02:10 +0100 |
| Subject | Re: Mass storage sizes (was: /dev/serial/by-id) |
| Message-ID | <K3bHb-7cFX-1@gated-at.bofh.it> |
| In reply to | #276437 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, Jan 9, 2025 at 6:45 PM Michael Stone <mstone@debian.org> wrote: > On Thu, Jan 09, 2025 at 09:47:11PM +0100, Nicolas George wrote: > >For the people who need exact figures, on the other hand, binary units > >are much more convenient, not just to measure the size of memory > >modules: alignment requirements, maximum sizes of files and devices, > >size of stripes, they are all based on powers of two. > > Baloney. People who need to worry about those things are/should be doing > that programatically and absolutely do not "need" GiB for anything at > all, certainly not for display. For everyone else, basically all the > time and in every situation, power of ten units make more sense. The > entire computing world has been saddled with this "but a computer > kilobyte is really" nonsense far too long, and it actively hurts UX for > everyone other than the vanishingly small set of people who won't shut > up about how important it is to keep that anachronism. > It takes 8 bits to make one byte, should we change that to 10 too.... -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄⠀⠀
[toc] | [prev] | [next] | [standalone]
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2025-01-10 11:00 +0100 |
| Subject | Re: Mass storage sizes (was: /dev/serial/by-id) |
| Message-ID | <K3jY5-7tuQ-7@gated-at.bofh.it> |
| In reply to | #276441 |
[Multipart message — attachments visible in raw view] — view raw
On Jan 09, 2025, Timothy M Butterworth wrote: > On Thu, Jan 9, 2025 at 6:45 PM Michael Stone <mstone@debian.org> wrote: > > > On Thu, Jan 09, 2025 at 09:47:11PM +0100, Nicolas George wrote: > > >For the people who need exact figures, on the other hand, binary units > > >are much more convenient, not just to measure the size of memory > > >modules: alignment requirements, maximum sizes of files and devices, > > >size of stripes, they are all based on powers of two. > > > > Baloney. People who need to worry about those things are/should be doing > > that programatically and absolutely do not "need" GiB for anything at > > all, certainly not for display. For everyone else, basically all the > > time and in every situation, power of ten units make more sense. The > > entire computing world has been saddled with this "but a computer > > kilobyte is really" nonsense far too long, and it actively hurts UX for > > everyone other than the vanishingly small set of people who won't shut > > up about how important it is to keep that anachronism. > > > > It takes 8 bits to make one byte, should we change that to 10 too.... Please no, 8b10b encoding is hard enough. :) -- |_|O|_| |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2025-01-10 15:10 +0100 |
| Subject | Re: Mass storage sizes (was: /dev/serial/by-id) |
| Message-ID | <K3nS2-7Bd5-3@gated-at.bofh.it> |
| In reply to | #276447 |
On 1/10/25 04:50, Dan Purgert wrote: > On Jan 09, 2025, Timothy M Butterworth wrote: >> On Thu, Jan 9, 2025 at 6:45 PM Michael Stone <mstone@debian.org> wrote: >> >>> On Thu, Jan 09, 2025 at 09:47:11PM +0100, Nicolas George wrote: >>>> For the people who need exact figures, on the other hand, binary units >>>> are much more convenient, not just to measure the size of memory >>>> modules: alignment requirements, maximum sizes of files and devices, >>>> size of stripes, they are all based on powers of two. >>> Baloney. People who need to worry about those things are/should be doing >>> that programatically and absolutely do not "need" GiB for anything at >>> all, certainly not for display. For everyone else, basically all the >>> time and in every situation, power of ten units make more sense. The >>> entire computing world has been saddled with this "but a computer >>> kilobyte is really" nonsense far too long, and it actively hurts UX for >>> everyone other than the vanishingly small set of people who won't shut >>> up about how important it is to keep that anachronism. >>> >> It takes 8 bits to make one byte, should we change that to 10 too.... > Please no, 8b10b encoding is hard enough. :) Wider bytes were tried early on, flopped. I was once gifted a thing made by NCR in 1985 whose cpu , about 18" square was all TTL stuff. Stripped of memory, I recall its byte was 12 bits. Now of course memory bandwidth is obtained by 128 bit wide busses with 256 in the higher end servers. Useless to me, I built a ups for my full house Amiga 2000 out of motorcycle batteries in its box. That, like the Amiga eventually was, was a failure. Another time and place. > > Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2025-01-10 07:30 +0100 |
| Subject | Re: Mass storage sizes (was: /dev/serial/by-id) |
| Message-ID | <K3gGR-7nkJ-1@gated-at.bofh.it> |
| In reply to | #276437 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, Jan 09, 2025 at 06:44:30PM -0500, Michael Stone wrote: [...] > Baloney [...] "Baloney" == "things I don't like" (FWIW I'd prefer binaries in the computer context, but hey). Human communication is messy. Both multipliers come from different sources which were well established at the moment they "clashed". Heck, the "disk people" themselves are schizophrenic, since they bunch their blocks in binary too (512, 4k -- uh 4kiB), rumours have it that SSD erase blocks are also powers-of-two sized. So... The best we can do at the moment is to use the iB suffix in cases where the context doesn't help enough (in most cases it does: human language is like that). Past experience shows that we'll live with this for a while (watch the US still on their Imperial measures, while the UK has, mostly, switched to metrics -- oh, the irony). One rant is OK, but repeatedly whining about it just will annoy people :) Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | John Hasler <john@sugarbit.com> |
|---|---|
| Date | 2025-01-10 15:50 +0100 |
| Subject | Re: Mass storage sizes |
| Message-ID | <K3ouK-7Cnn-17@gated-at.bofh.it> |
| In reply to | #276446 |
Tomas writes:
> Past experience shows that we'll live with this for a while (watch
> the US still on their Imperial measures,
Pedanticism: The US is not and never has been on the Imperial system.
We use both SI ("metric") and US Customary (the latter predates
Imperial).
--
John Hasler
john@sugarbit.com
Elmwood, WI USA
[toc] | [prev] | [next] | [standalone]
| From | eben@gmx.us |
|---|---|
| Date | 2025-01-10 21:40 +0100 |
| Subject | Re: Mass storage sizes |
| Message-ID | <K3tXs-7LJd-3@gated-at.bofh.it> |
| In reply to | #276451 |
On 1/10/25 15:30, mick.crane wrote:
> On 2025-01-10 14:39, John Hasler wrote:
>> Tomas writes:
>>> Past experience shows that we'll live with this for a while (watch
>>> the US still on their Imperial measures,
>>
>> Pedanticism: The US is not and never has been on the Imperial system.
>> We use both SI ("metric") and US Customary (the latter predates
>> Imperial).
> wasn't a defect in the Hubble telescope mirror caused by a misunderstanding
> between US/UK what units they were working in?
I'd heard it was a failure to account for the effects of non-gravity on the
main mirror. The Mars Climate Observer was doomed by one team using
imperial instead of metric, and applying the wrong impulse because of it.
--
Friendship is born at that moment when one person says to another:
"What! You too? I thought I was the only one."
-- C. S. Lewis
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2025-01-11 01:50 +0100 |
| Subject | Re: Mass storage sizes |
| Message-ID | <K3xRn-7O6x-1@gated-at.bofh.it> |
| In reply to | #276453 |
On 1/10/25 15:40, eben@gmx.us wrote:
> On 1/10/25 15:30, mick.crane wrote:
>> On 2025-01-10 14:39, John Hasler wrote:
>>> Tomas writes:
>>>> Past experience shows that we'll live with this for a while (watch
>>>> the US still on their Imperial measures,
>>> Pedanticism: The US is not and never has been on the Imperial system.
>>> We use both SI ("metric") and US Customary (the latter predates
>>> Imperial).
>> wasn't a defect in the Hubble telescope mirror caused by a misunderstanding
>> between US/UK what units they were working in?
> I'd heard it was a failure to account for the effects of non-gravity on the
> main mirror. The Mars Climate Observer was doomed by one team using
> imperial instead of metric, and applying the wrong impulse because of it.
That is not what they told us on this side of the pond, it was an error,
less than a human hair in the parabola they polished it to. So they
designed an eye piece of sorts to correct it. Likely at the expense of
some wide field loss. But we've sure gotten our moneys worth since. That
is the last thing this planet has put up that sees visible light. And
now with the shuttle shut down, its low orbit will eventually bring it
down. The shuttle has been used to give it an orbit raising gentle push
at least once but now the giro's are wearing out. They aim it.
> --
> Friendship is born at that moment when one person says to another:
> "What! You too? I thought I was the only one."
> -- C. S. Lewis
>
> .
Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
[toc] | [prev] | [next] | [standalone]
| From | Jeffrey Walton <noloader@gmail.com> |
|---|---|
| Date | 2025-01-11 01:40 +0100 |
| Subject | Re: Mass storage sizes |
| Message-ID | <K3xHH-7O2O-3@gated-at.bofh.it> |
| In reply to | #276451 |
On Fri, Jan 10, 2025 at 5:57 PM mick.crane <mick.crane@gmail.com> wrote:
>
> On 2025-01-10 14:39, John Hasler wrote:
> > Tomas writes:
> >> Past experience shows that we'll live with this for a while (watch
> >> the US still on their Imperial measures,
> >
> > Pedanticism: The US is not and never has been on the Imperial system.
> > We use both SI ("metric") and US Customary (the latter predates
> > Imperial).
> wasn't a defect in the Hubble telescope mirror caused by a
> misunderstanding between US/UK what units they were working in?
Also see <https://en.wikipedia.org/wiki/Gimli_Glider>. The plane took
off with too little fuel due to a conversion error. The error was
introduced using a value converted from pounds/litre instead of
kilograms/litre.
I also seem to recall Airbus had a problem with engine wiring
harnesses due to conversions and rounding errors, but I can't find a
reference.
Jeff
[toc] | [prev] | [next] | [standalone]
| From | Heriberto Avelino <heriberto.avelino@gmail.com> |
|---|---|
| Date | 2025-01-10 01:30 +0100 |
| Subject | Re: Mass storage sizes (was: /dev/serial/by-id) |
| Message-ID | <K3b4t-7bhM-3@gated-at.bofh.it> |
| In reply to | #276436 |
[Multipart message — attachments visible in raw view] — view raw
I agree it is important, may be a precision on the more general idea is helpful: "Communication of numbers between ordinary people generally happens in base 10." It turns out that the diversity of the notion of numerosity among *homo sapiens* is way far richer than the base-10. See https://wals.info/chapter/131 Indeed, humans have developed base-8 counting systems. Avelino, Heriberto (2006). "The typology of Pame number systems and the limits of Mesoamerica as a linguistic area" <http://linguistics.berkeley.edu/~avelino/Avelino_2006.pdf> (PDF). *Linguistic Typology*. *10* (1): 41–60. doi <https://en.wikipedia.org/wiki/Doi_(identifier)>:10.1515/LINGTY.2006.002 <https://doi.org/10.1515%2FLINGTY.2006.002> On Thu, Jan 9, 2025 at 2:47 PM Nicolas George <george@nsup.org> wrote: > Michael Stone (12025-01-08): > > For example...let's take the 18000000000000B drive discussed earlier. > That's > > 18TB or 16TiB. Annoying, but ok. Now that's also 18000MB but 16763MiB. > And > > it's 18000000MB or 17166137MiB. So if you have a display in MB and you > want > > to know the value in TB you move the decimal 6 places. But if you move > the > > decimal 6 places to get from MiB to TiB you get...the wrong answer. Does > > this actually happen? Yes. All the freaking time. (A classic mashup is > 1024k > > blocks expressed with power of 10 M and G.) Now this next part is > important: > > no normal human working with files and disk space and trying to > communicate > > with other normal humans calculates the values in base 8 or base 16. > > Communication of numbers between ordinary people generally happens in > base > > 10. SI prefixes are base 10. And when you munge up some stupid base 2 > units > > with what people want and expect to be base 10, mistakes and confusion > > happen. And the benefit of all that confusion and increased cognative > load > > is: absolutely nothing. > > The thing is, for people who _expect_ rather than _know_ about this, 10% > accuracy is plenty enough. Especially since, as has been pointed, a lot > of factors will conspire to reduce the space available in practice. > > For the people who need exact figures, on the other hand, binary units > are much more convenient, not just to measure the size of memory > modules: alignment requirements, maximum sizes of files and devices, > size of stripes, they are all based on powers of two. > > > Stefan Monnier (12025-01-09): > > A related problem is when writing code which displays such sizes in > > a human readable way, for example a "speedometer" displaying the number > > of bytes per second with a limited amount of space. A common choice is > > to use 3 chars for the number plus a unit, i.e. things like "254 kB/s" > > or "1.5 MB/s". Now, if you use the "1024" multiplier, you get a funny > > quirk when the current speed is, say 1003 kB/s, because "1003 kB/s" uses > > one char too many, yet we haven't reached "1.0 MB/s" either. > > Well, “1.5” is too few significant digits in the first place. > > So, you start: > > 100 M > 999 M > 1000 M > 1024 M > 1.59 G > 9.99 G > 10.0 G > 99.9 G > 100 G > 999 G > 1000 G > > The switch to the next prefix does not have to be as soon as the > mantissa is greater than one. Notice that the heights of mountains are > in meters, not in kilometers, even for the Himalaya. It is better to go > to 9999 M and only then switch to 9.77 G: more significant digits, not > less readable. > > (Also, the people who designed the symbols for the prefixes really > dropped the ball with k instead of K, but that predates memory units by > a long time.) > > -- > Nicolas George > >
[toc] | [prev] | [next] | [standalone]
| From | Kushal Kumaran <kushal@locationd.net> |
|---|---|
| Date | 2025-01-07 20:20 +0100 |
| Subject | Re: Mass storage sizes |
| Message-ID | <K2nhn-6tz5-5@gated-at.bofh.it> |
| In reply to | #276388 |
On Tue, Jan 07 2025 at 11:05:11 AM, Michael Stone <mstone@debian.org> wrote: > On Tue, Jan 07, 2025 at 10:44:00AM -0500, Dan Purgert wrote: >>On Jan 07, 2025, Stefan Monnier wrote: >>> > 8 TB is not that big. I have a external 18 TB drive. It is 18 TB in name >>> > only though! After fromating it with ext4 it only had 15TB of usuable >>> > space. >>> >>> 18TB "on paper" is usually 18 * 1000^4 bytes, so if you convert this >>> into "computer units" is ~16.37 * 1024^4 bytes. If you then make an >>> ext4 filesystem on it with the customary 5% reserved for root, that gets >>> you down to 15.5TB, to which you also have to remove the space used by >>> inodes, so yes, probably about 15TB and of course, once you start >>> putting actual files ion the drive, additional space will be used by >>> directories and metadata. >> >>Now now, let's not derail a rant with facts :) >> >>That being said, I thought the variance from TB -> TiB was 10%; or have >>I gotten it backwards? > > TB is about 10% larger. One of the worst crimes in computer history > was ever talking about storage in powers of 2, I really wish it would > just go away. It has properties that nobody wants and has been the > source of endless confusion, for really no benefits whatsoever. I point people to http://www.tarsnap.com/GB-why.html which is where I was first enlightened. -- regards, kushal
[toc] | [prev] | [next] | [standalone]
| From | Nicolas George <george@nsup.org> |
|---|---|
| Date | 2025-01-07 21:10 +0100 |
| Subject | Re: Mass storage sizes |
| Message-ID | <K2o3L-6u9j-5@gated-at.bofh.it> |
| In reply to | #276395 |
Kushal Kumaran (12025-01-07): > I point people to http://www.tarsnap.com/GB-why.html which is where I > was first enlightened. Mostly something anybody should learn in junior high school physics, freshman high-school at worst. Except for one point: “this is a special case”. Except they are wrong about where the special case: it would be absurd for the same unit to mean something different depending on what it measures, so if you accept that one giga-octet of RAM is 1024^3 octets, you have to accept it everywhere of be ridiculously inconsistent with bad practical consequences. -- Nicolas George
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2025-01-07 23:10 +0100 |
| Subject | Re: Mass storage sizes |
| Message-ID | <K2pVU-6vir-9@gated-at.bofh.it> |
| In reply to | #276395 |
On Tue, Jan 07, 2025 at 02:59:47PM -0700, Charles Curley wrote: >Mr. Tarsnap forgets something. The reason disks are addressed in powers >of two has to do with mathematics. Every hard and floppy disk out there >has flaws. To get around that, data is divided into sectors, and >checksums calculated. Done right, this allows for error correction for >small flaws. The math works out better if you do it in chunks that are >integer powers of two. So floppy disks have sectors of 256 octets, and >their attendant checksums. Modern hard drives schlep data in chunks of >4096 (2^12) octets. And bytes these days are eight bits. The thing is, nobody cares about all that. It's an implementation detail that matters not to any normal person. Normal people care about things like "when I just look at the first couple of numbers of the size in bytes, is it the same thing as the size in <insert large unit> or do I need to do a bunch of math to answer a simple question?" >GB or GiB? I don't care, just be clear which one you are using. Which nobody is. The right answer is to stop using power of two units because they are pointless.
[toc] | [prev] | [next] | [standalone]
| From | Urs Thuermann <urs@isnogud.escape.de> |
|---|---|
| Date | 2025-01-10 03:00 +0100 |
| Subject | Re: Mass storage sizes |
| Message-ID | <K3ctz-7e56-1@gated-at.bofh.it> |
| In reply to | #276407 |
Michael Stone <mstone@debian.org> writes: > On Tue, Jan 07, 2025 at 02:59:47PM -0700, Charles Curley wrote: > >Mr. Tarsnap forgets something. The reason disks are addressed in powers > >of two has to do with mathematics. Every hard and floppy disk out there > >has flaws. To get around that, data is divided into sectors, and > >checksums calculated. Done right, this allows for error correction for > >small flaws. The math works out better if you do it in chunks that are > >integer powers of two. So floppy disks have sectors of 256 octets, and > >their attendant checksums. Modern hard drives schlep data in chunks of > >4096 (2^12) octets. And bytes these days are eight bits. > > The thing is, nobody cares about all that. It's an implementation > detail that matters not to any normal person. Normal people care about > things like "when I just look at the first couple of numbers of the > size in bytes, is it the same thing as the size in <insert large unit> > or do I need to do a bunch of math to answer a simple question?" > > >GB or GiB? I don't care, just be clear which one you are using. > > Which nobody is. The right answer is to stop using power of two units > because they are pointless. No matter how often you repeat this, it's still wrong. Using power of two units is quite useful. For example, my computers had 5.12 kB, 65.356 kB, 16.777216 MB, 67.108864 MB, 268.435456 MB, 1.073741824 GB, and 8.589934592 GB of RAM. Perfectly correct, but I prefer to say they had 5 kiB, 64 kiB, 16 MiB, 64 MiB, 256 MiB, 1 GiB, and 8 GiB of RAM. Because of technical reasons, rows and columns with m RAS and n CAS select lines, sizes of RAM chips are almost always 2**m * 2**n bytes, i.e. powers of 2. RAM modules for the RAM slots of your mainboard also are sized in powers of 2, because otherwise it would be extremely hard to decode a memory address from the CPU into module slot number and offset inside the module. Block devices like floppy disks, hard disks, SSDs, etc. also have block sizes which are powers of 2, like 256, 512, and 4096 bytes. This is not because of checksumming as was suggested in this thread, but because it makes it easier (e.g. for DMA controllers) to copy from/to pages of RAM. Therefore, my floppy disks had exacty 170.75 kiB, 720 kiB, and 1.44 MiB --- or as you would like to put it --- 174.848 kB, 737.280 kB, and 1.47456 MB. So again: Are kiB, MiB, GiB, and TiB really pointless? This is not really confusing, except for people who are too dumb to understand units and their conversions. Granted, some confusion came from using k, M, G for the power-of-2 based units. Back in the days when we had only kilobytes this didn't matter too much since 2**10 is so close to 1000 (only 2.4% more) that it was just practical to use uppercase K to mean "a little more than k", i.e. 2**10, but still speak of kilobytes. When we reached sizes of megabytes, we couldn't use a "larger than M letter", so M was simply used for both, 10**6 and 2**20, but it was usually clear from the context, what was meant. Some confusion started, when some marketing people switched from using the then common binary units to using decimal units because it made their drives look larger than the competitor's drives. Only much much later someone invented the ki, Mi, Gi, ... prefixes to fix this and which I think helped a lot. Only, when talking I never hear anyone saying kibi, mebi, gibi, tebi. so you still need to take the context into account to understand. urs
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | linux.debian.user
csiph-web