It seems like a serious parody, i.e. someone's cashing in by selling junk as audio gear. Junk with "subtle effects", mind you, so customers can't really complain.
That is actually a very good keyboard.
It also makes your personal computer truly personal. (GF/littlebrother-proof). In addition, it is a free everyday dementia test. That pesky brain damage cannot sneak up on you. And when it does, you won't be able to post about it!
And that routine is used regardless, if you think for a just a little longer. The difference is with the prefixes, not the string of decimal numbers. So why are base-2 prefixes correct for filesystems again?
Slashdot isn't that popular though, at least when compared to some other massive sites, so the theory still holds. Besides, slashdot does not actually possess popularity attributes, slashdot has tenure.
AFAIunderstand, if all your shared objects are immutable, then you don't need to use locks at all. Only mutable shared objects need to be synchronised.
First of all, 32-bit addressing means that 2^32 bytes can be addressed. But memory is a different design and circumstance than disk space, so I don't think it's comparable. Also, there's not really any confusion about RAM size, now is there?
Second, "counting in base 2" is a bit of a misnomer, since we're really counting in decimal, except with powers-of-2 prefixes. It's mixed counting, in other words.
Third, and most important, the whole issue is about how to express the length of a file, and how to express the length of a filesystem and the underlying block device. We're talking specifically about length here, there aren't really any other dimensions in filesystems of today. The hardware itself may have some structure to it that rely on powers of two, like 512-byte sectors, but that is a hardware issue. Likewise for filsystems.
The whole thing boils down to the user interface: do you divide by 1000 or 1024 when presenting the numbers? Does either way provide any advantages, or disadvantages?
Here's a disadvantage for using 2^n prefixes: try calculating 10 GiB - 500 MiB. How long did it take? Contrast this with 10^n prefixes, i.e. 10 GB - 500 MB. 10^n prefixes are easier to grasp and figure out. Are there any particular situations where using 2^n prefixes is an advantage?
That's still not a reason for using powers of two. I'm looking for a logical, sound argument why powers of two are better for bytes and filesizes than powers of 10.
As long as people who want to cheat you don't lie to you then a person
could go their entire life working with computers and not know what
the decimal representation of a megabyte looks like. That doesn't mean base-2 representation was ever a good idea to begin with.
You say in your sig:
SI units are meant to be computationally convenient, not arbitrarily assigned. So which is computationally more convenient, counting in base 2 or counting in base 10? Provide an example if you can. Note that computers don't care which base you use for representing numbers, only other humans do, so we're talking about convenient for humans.
If you listen to Google's captcha, you'll see that it is filled with nonsense voices as well as the real voice. You can still make out the real voice, but it's not entirely trivial. A great improvement, like TFA suggests, would be to use complete words rather than numbers, which turns it into a full voice-recognition problem for an attacker. Also, some manner of distortion in both time and frequency domain should thwart this attack. The only problem is that distorting in the frequency domain isn't all that easy, if you want the voice to be understandable..
Ok, just to clarify then: suppose we start using computers that have trits as their fundamental unit. Three states of each "bit", 100 follows 022, three voltage levels, etc. Would it then make sense to count filesizes in base three?
Or suppose we use septs: 100 follows 066, seven voltage levels... would it then make sense to count filesizes in base seven?
No, of course not. All countables make sense to count in one base, and that base is 10 by convention. Bits, bytes, digits and apples are all countables, regardless of their internal representation.
I duly note that I still haven't seen an argument for using base two.:)
You're confusing two things in your argument there: the amount of information, and the shape of the information. The shape is the base, which is two for bits. But the amount of information is the number of bits, which makes sense to count in base ten, since everything else we count, we count in base 10. Furthermore, for hard disks we use bytes, which are a specific number of bits long (8 today) which is not binary. The byte itself happens to have a range of 0-255, which corresponds to 2^8 since it's composed of bits (and not trits), but that's still not relevant to the total number of bytes.
Cue posts on block sizes, sector sizes, which are still not relevant to the number of bytes in a file.
The fact is after nearly ten years IEC has failed to get their standard adopted by the majority so it loses. You're right, it loses, but it shouldn't. There's no logical reason whatsoever why we should use powers of two, except tradition. If it causes confusion and isn't useful, why keep doing it?
It seems a lot of geeks try to "defend" using powers of two, as if it were somehow the "correct" way, without thinking whether or not it is really correct and logical (*).
(*)Yes, it makes sense for memory, but nobody's confused about memory either.
Statistics is not a game, and it is not a joke. It is a choice, a field of mathematics, and it is also 87 percent false. I am asking you to remove your percentage from circulation out of respect for the millions of consumers who have undergone Marketing-Convulsive Advertising.
That's frequently too much to bother with. The best is to provide good defaults, with particular emphasis on plurality. A single set of good defaults can only make a fraction of everyone happy, and even some of those who are content with it don't realise that it could be better (for them).
This reminds me very much of the talk by Malcolm Gladwell on "The pursuit of happiness", where he reaches the conclusion (via spaghetti sauce) that there is no perfect solution, or perfect recipe that works for everyone.
I must say I did notice that I couldn't enlarge the text area, which annoyed me at first, but I didn't realise there was a feature behind it. Now that I tried filling it up though, it seems like a better idea to me. Let the computer handle the interface look as much as possible, I say. It just makes it easier for the human in the end. In other words, I think this fork is childish all the way through.
Slashdot Mirror
It seems like a serious parody, i.e. someone's cashing in by selling junk as audio gear. Junk with "subtle effects", mind you, so customers can't really complain.
Then it can be taken a step further by providing a function for that expectation: when the user clicks a highlighted row, all other rows are ghosted.
Why does VS do that? Did he forget to turn off debugging symbols or something?
The point is that you can't control the laws of physics, only understand and work around them.
AFAIK, in this case, getting the manufacturing process under better control implies getting the laws of physics under better control.
What explanatory voiceovers? I can't remember anything like that.
And that routine is used regardless, if you think for a just a little longer. The difference is with the prefixes, not the string of decimal numbers. So why are base-2 prefixes correct for filesystems again?
That's because you used a digital pen as suggested in TFA, when you really should use a cigar.
Slashdot isn't that popular though, at least when compared to some other massive sites, so the theory still holds. Besides, slashdot does not actually possess popularity attributes, slashdot has tenure.
AFAIunderstand, if all your shared objects are immutable, then you don't need to use locks at all. Only mutable shared objects need to be synchronised.
Second, "counting in base 2" is a bit of a misnomer, since we're really counting in decimal, except with powers-of-2 prefixes. It's mixed counting, in other words.
Third, and most important, the whole issue is about how to express the length of a file, and how to express the length of a filesystem and the underlying block device. We're talking specifically about length here, there aren't really any other dimensions in filesystems of today. The hardware itself may have some structure to it that rely on powers of two, like 512-byte sectors, but that is a hardware issue. Likewise for filsystems.
The whole thing boils down to the user interface: do you divide by 1000 or 1024 when presenting the numbers? Does either way provide any advantages, or disadvantages?
Here's a disadvantage for using 2^n prefixes: try calculating 10 GiB - 500 MiB. How long did it take? Contrast this with 10^n prefixes, i.e. 10 GB - 500 MB. 10^n prefixes are easier to grasp and figure out. Are there any particular situations where using 2^n prefixes is an advantage?
SI units are meant to be computationally convenient, not arbitrarily assigned. So which is computationally more convenient, counting in base 2 or counting in base 10? Provide an example if you can. Note that computers don't care which base you use for representing numbers, only other humans do, so we're talking about convenient for humans.You say in your sig:
If you listen to Google's captcha, you'll see that it is filled with nonsense voices as well as the real voice. You can still make out the real voice, but it's not entirely trivial. A great improvement, like TFA suggests, would be to use complete words rather than numbers, which turns it into a full voice-recognition problem for an attacker. Also, some manner of distortion in both time and frequency domain should thwart this attack. The only problem is that distorting in the frequency domain isn't all that easy, if you want the voice to be understandable..
Or suppose we use septs: 100 follows 066, seven voltage levels... would it then make sense to count filesizes in base seven?
No, of course not. All countables make sense to count in one base, and that base is 10 by convention. Bits, bytes, digits and apples are all countables, regardless of their internal representation.
I duly note that I still haven't seen an argument for using base two.
Cue posts on block sizes, sector sizes, which are still not relevant to the number of bytes in a file.
I don't see how any of that relates to the common use of MB, GB, and so forth, which is used and free disk space.
It seems a lot of geeks try to "defend" using powers of two, as if it were somehow the "correct" way, without thinking whether or not it is really correct and logical (*).
(*)Yes, it makes sense for memory, but nobody's confused about memory either.
Statistics is not a game, and it is not a joke. It is a choice, a field of mathematics, and it is also 87 percent false. I am asking you to remove your percentage from circulation out of respect for the millions of consumers who have undergone Marketing-Convulsive Advertising.
That's frequently too much to bother with. The best is to provide good defaults, with particular emphasis on plurality. A single set of good defaults can only make a fraction of everyone happy, and even some of those who are content with it don't realise that it could be better (for them).
In a sense, all of mankind is just one very long discussion thread.
Many times I've felt I almost ran over a bird, both on bike and in car. I never thought it was actually possible...
This reminds me very much of the talk by Malcolm Gladwell on "The pursuit of happiness", where he reaches the conclusion (via spaghetti sauce) that there is no perfect solution, or perfect recipe that works for everyone.
I must say I did notice that I couldn't enlarge the text area, which annoyed me at first, but I didn't realise there was a feature behind it. Now that I tried filling it up though, it seems like a better idea to me. Let the computer handle the interface look as much as possible, I say. It just makes it easier for the human in the end. In other words, I think this fork is childish all the way through.