• (nodebb)

    Of course, the worst mistake is that FILENOTFOUND is never considered.

  • Hanzito (unregistered)

    And the annoying inconsistency of using a semicolon in two out of the three statements (the weird spacing in the first line could be attributed to a copy/paste error). Whoever did this had no right to change something so central to core functionality.

  • (nodebb)

    We can set aside conspiracy theories about HDD and RAM manufacturers lying to us about sizes by using MiB in marketing

    For sure we can, because you have the conspiracy theories backwards. HDD manufacturers have long and long and longer than that used decimal K/M/G/T rather than binary Ki/Mi/Gi/Ti, presumably because it makes the numbers bigger (+2.4% for K, +4.8% for M, +7.4% for G, +10% for T). But equally, they never used anything else, and it's pedantically correct to use K/M/G/T for 1 000, 1 000 000, etc.

    Where it all goes wrong is 3.5" high density floppies, called "1.44 MB", except that they weren't. They had 2880 half-KiB sectors, which is 1440 KiB, which is 1.44 thousand KiB, result 1.44 KKiB. (MB would be KKB, and MiB would be KiKiB...)

  • A.N.O Nymos (unregistered)

    The real problem is that computers use K, M, G and T when they mean Ki, Mi, Gi andTi. When a computer says a file is 2 MB, what it means is 2 MiB. Maybe MS can win back some users if they can get Windows to use the proper units. And while we're dreaming, might as well see if we can storage manufactures (HDD, RAM, GFX cards, etc) to note sizes in both formats (e.g.: 2 TB / 1.86 TiB).

  • RLB (unregistered)

    No, the real problem is that computer geeks have always used K/M/G to mean powers of 2 because that is more useful in the computer world; then salespeople hack pfthui decided that it would be more profitable for them to use the smaller value (and yes, this happened after KB = 1024B was already commonplace); and then the insufferable nerds in the Office Of Measurements and Statistics or whatever it's called opined that this wasn't nerdy and dorky enough and invented the unspeakable BiBiBits. Which I shall never use.

  • 516052 (unregistered)

    Honestly I do not see why it matters. And I say this as someone with a formal education in computer science and decades of work in the field.

    All these squabbles about units are ultimately meaningless to the end user. And this includes the vast majority of us developers as well. Unless you are doing low level work and actually need to employ binary arithmetic it's all just magic numbers whose only utility is to be compared to other magic numbers. And for that the only thing that matters is ensuring that all the units used are consistent.

    If my system is telling me I have 12.5215 out of 153.87211 units of something remaining it does not particularly matter where those two numbers come from, what number systems they are in etc. etc. The only thing that matters is that I know for a fact my new file which is precisely 13.1213151 units in size won't fit. But it will if I delete that other file that's 23.1231 units large. What the unit in question is hardly matters.

    As for it all being a scam I really do not see it as such. It's just expressing the same number in a different unit system. And as long as all file sizes as displayed in the system are in that same unit system the end user will not be able to perceive the difference.

    You could build an OS that denotes all memory values entirely in oranges and as long as all the hardware and software is labeled to work with it 99% of real world use cases would not be effected.

  • 516052 (unregistered)

    PS. Just in case anyone is wondering I am of course talking about the metric orange which is 0.73 pears and not the american customary orange that is 0.84 pears. Although I suppose either will do for the purposes of the example.

  • peter (unregistered)

    our files are measured in furlongs per fortnight on 2 lightyear drives. of course we have a dev/nul cold storage backup unit

  • Anon (unregistered)
    Comment held for moderation.
  • Tim (unregistered)

    "...this doesn't correctly declare baseValue, which JavaScript is pretty forgiving about"

    That's not really true. if JavaScript lets you declare a variable like this then (a) you're not using strict mode, which you should be because it's not 2010 anymore, and (b) you have just created a global variable, which I really hope isn't what you wanted.

  • Daniel Orner (github)

    In addition, the original line used "falsey" condition checks (in other words, if useSI was 0, or undefined, or an empty string, it would still set it to 1000). This would leave it as 1024. So in fact the only way that we'd ever get a value of 1000 is if useSI is set to the exact value "false". The rest of the code is useless.

  • Richard Brantley (unregistered) in reply to 516052

    "All these squabbles about units are ultimately meaningless to the end user."

    Tell that to the guy working at Best Buy when he has to explain to an irate customer why the new laptop he just bought with a 512GB hard drive is showing 420GB of free space out of 480 total when he darn well paid for 512.

  • (nodebb) in reply to Richard Brantley

    "explain to an irate customer"

    Oh, that's easy: Sir, every laptop we sell has special hidden security software to keep your data safe. That's what is taking up the 32 GB you can't see. No, you can't remove it, and it wouldn't be safe to. We want you to be safe, sir.

  • Greg (unregistered) in reply to Steve_The_Cynic
    Comment held for moderation.

Leave a comment on “Terned Backwards”

Log In or post as a guest

Replying to comment #691521:

Log Out

« Return to Article