• pete (unregistered)

    It also contains a bug.  They divide by 1024 to get the number of (mega|giga|whatever)bytes, but if there are more than 1000 yottabytes they multiply by 999 to get back to Yb.

  • (cs) in reply to pete

    Note to self:  Order more hard drives.

  • (cs)

    LOL ... I use yum all the time and I find it very good. It is an RPM based package management system for Linux, it comes as standard with Fedora Core.

    Basically if I want to install FireFox I don't go lookign round the web for it I just run:
    yum install firefox

    Or, better still, if I want to update ALL the apps on my computer to the latest version I just run:
    yum update

    Yum is a very nice product, mind you this little snippet of code is exceptionally entertaining, I know it is good to future proof your code but I think yum will be LONG dead before we start needed yotta bytes of info from it!

  • Jonathan "Project X" Thompson (unregistered)

    Well, I must say: this developer is optimistic when it comes to data sizes!  While what was written in isolation isn't a WTF but rather an optimistic hope (or fear) for dataset size does bring up the likely WTF in regards to other issues within the application.  What are these?

    1.  What's the size manageable by the filesystem and file libraries used?  Can it cope?

    2.  Let's assume a very optimistic system will exist before this code is no longer used, that can transfer 1 terabyte of data per second (SATA1,000,000,000, anyone?) which will still require more than 31,688,087.814028950237026896848937 years to transfer 1000 yottabytes, which is alotta bytes. Somewhere or other, I'd expect file data stamps to be assigned, leading to the logical question: is the software Y20M compliant, and beyond?

     

    And of course, I had to pop out this question a woman might ask a guy:

    Is that a yottabyte of storage in your pocket, or are you just happy to see me?[:$]

  • (cs)

    Mmmmmmmmmmm, 1000 yottabytes of hot dogs.  <drool/><font color="#006400"></font>

  • marijne (unregistered)

    Wow. That's a yotta data.

  • Mr Smith (unregistered) in reply to Jonathan &quot;Project X&quot; Thompson
    Anonymous:
    Somewhere or other, I'd expect file data stamps to be assigned, leading to the logical question: is the software Y20M compliant, and beyond?

    I think Y10K is the next big one... certainly that's where 4-digit dates die out. Maybe this app uses rfc2550 dates... it would be interesting to see a real world app which does.
  • (cs)

    Forward thinking like this would have prevented the Y2K crisis.

  • (cs)
    Alex Papadimoulis:

    A stack of 3.5" floppy discs with 1,000 yottabytes would be tall enough to make it to the sun. 14 Million times. But still ... just in case ...



    Dude, wouldn't the floppies melt when they get close to the Sun?

        dZ.

  • Mike (unregistered) in reply to Sean

    It's a funny comment but the check itself is probably a good thing.  If 'number' came from direct user input, a file, or some other untrusted source it needs to be checked rather than blindly running off the end of the symbol array.

  • (cs) in reply to DZ-Jay
    DZ-Jay:
    Alex Papadimoulis:

    A stack of 3.5" floppy discs with 1,000 yottabytes would be tall enough to make it to the sun. 14 Million times. But still ... just in case ...



    Dude, wouldn't the floppies melt when they get close to the Sun?

        dZ.



    HAHA, dZ, you're pragmatism has no bounds.
  • Ben Cooke (unregistered) in reply to Mr Smith

    I think we should be more concerned about the various points in the not-so-distant future where various timestamp formats will overflow a 32-bit integer. UNIX timestamps only have 27 years left!

  • Eddie (unregistered)

    I would write that in just for fun, just so I could type "yottabyte" in my code.

  • (cs) in reply to voyager
    voyager:
    Yum is a very nice product, mind you this little snippet of code is exceptionally entertaining, I know it is good to future proof your code but I think yum will be LONG dead before we start needed yotta bytes of info from it!


    A large part of Y2K was that sort of thinking.

    <font size="2">http://www.j-paine.org/singularity.html</font>

    Sincerely,

    Gene Wirchenko

  • Anonymous Coward (unregistered) in reply to pete
    Anonymous:
    It also contains a bug.  They divide by 1024 to get the number of (mega|giga|whatever)bytes, but if there are more than 1000 yottabytes they multiply by 999 to get back to Yb.


    Incorrect. This is so it'll overflow into the next unit of measure before hitting one -- they want you to see 0.99 GB instead of 1,023 MB.
  • (cs)

    Very nice.  This programmer takes the "no arbitrary limits" philosophy seriously.  I like it.

    As for neccessity:  Moores law, although it doesn't directly apply to storage, has shown to parallell storage capacity pretty well as a general rule of thumb.  Since 2^10=1024, we can expect to hit the next "depth" every 10 Moore's cycles, or 15 years.  I regularly deal with terabytes of data now, in 2005.  Using Moore's law as a rough guide, I can expect to be dealing with 1000 yottabytes (1 nonabyte) in 60 Moore's cycles, or approximately 90 years.  So, in 2085 this software would most likely break occassionally if it had an arbitrary limit.  By 2100 I would expect it to break fairly regularly.  That is not to say that it won't break eventually, as word length seems to grow linearly, but I'd say he bought himself an extra 40 years or so with this adjustment.  I would fully trust this code to operate until 2115.  It's not THAT far away.

    And to put the storage into perspective, 1 yottabyte is about 2 moles of bytes, which given 1 molecule per bit storage would fit rather handily in something weighing 16-32 grams.  And that is just conventional storage.  We haven't even entered the world of overlapping quanta, so in reality, these sizes are not unbelievable... I just wouldn't try fitting them on a CD-R. :)

  • Ulf (unregistered) in reply to procyon112

    Is that assuming hydrogen (proton) storage? You may need to multiply those grams by a factor for different elements.

    All of this is moot, of course, as we know that in the future all computers and robots will be positronic.

  • Trev (unregistered)

    1000 yottabytes is absurd.  640 yottabytes should be enough for anyone.

  • Ran (unregistered) in reply to pete
    Anonymous:
    It also contains a bug.  They divide by 1024 to get the number of (mega|giga|whatever)bytes, but if there are more than 1000 yottabytes they multiply by 999 to get back to Yb.

    I think it's worse than that; I think they meant to write 

    number = number * 1024diff
    rather than 
    number = number * threshdepth

  • EvanED (unregistered) in reply to Ulf

    It's something very small. One molecule of hydrogen per bit would yield about 16 grams.

    By contrast 1 mole of iron is about 55 grams. Double that and you're at 110.

    But that's if there was one iron atom for each BYTE, not bit. Multiply by 8 and you're at about 900 grams, or about 2 lb. (1.97 if you carry through all numbers accurately.

  • (cs) in reply to procyon112

    procyon112:
    Very nice.  This programmer takes the "no arbitrary limits" philosophy seriously.  I like it.

    As for neccessity:  Moores law, although it doesn't directly apply to storage, has shown to parallell storage capacity pretty well as a general rule of thumb.  Since 2^10=1024, we can expect to hit the next "depth" every 10 Moore's cycles, or 15 years.  I regularly deal with terabytes of data now, in 2005.  Using Moore's law as a rough guide, I can expect to be dealing with 1000 yottabytes (1 nonabyte) in 60 Moore's cycles, or approximately 90 years.  So, in 2085 this software would most likely break occassionally if it had an arbitrary limit.  By 2100 I would expect it to break fairly regularly.  That is not to say that it won't break eventually, as word length seems to grow linearly, but I'd say he bought himself an extra 40 years or so with this adjustment.  I would fully trust this code to operate until 2115.  It's not THAT far away.

    And to put the storage into perspective, 1 yottabyte is about 2 moles of bytes, which given 1 molecule per bit storage would fit rather handily in something weighing 16-32 grams.  And that is just conventional storage.  We haven't even entered the world of overlapping quanta, so in reality, these sizes are not unbelievable... I just wouldn't try fitting them on a CD-R. :)

    Sure, conceptually we could address that much data but having a place to put that much data and actually having the data to fill it are two completely different matters.

  • Johnboy (unregistered) in reply to Trev

    I find your analogies troublsome in helping me comprehend the size of a yottabyte, problably because my standards of comparison date from before the cdrom / 3 1/4" floppy disk.

    Can you translate your measurments into the much more standard 'pages of typewriten paper' and 'libraries of congress'?

    Thanks
    Vic-20 Guy

  • (cs)

    This is the biggest Not-a-WTF posted yet.  The extra code to make it support Yottabytes is minimal, and I do not think it would degrade performance (it's not likely to be the root cause of a lot of cache misses or page faults).

    I admit it is future-proofing to the extreme, but there's no harm from doing that.

    For those who disagree, where would be a better place to stop?  Terabytes?  We're almost there for common hard drive sizes (I give it three years), so it may be best to move on to Petabytes for a maximum theoretical number that will work for the forseeable future.

    But Petabytes is a rather arbitrary choice, isn't it?  So why not just go as high as we have consistant names for and be done with it forever, and never have to revisit the code again.  At least he acknowledges how silly such a number would be.  And if a server reports a file that big, at least it won't overflow the space allocated to display the size.

    Admittedly I've become more fond of referring to such units as "Kibibytes" instead of "Kilobytes," but use of either style of unit is not a WTF unless you choose to mix 1000-based and 1024-based unites.

    Furthermore, I wish I could compare the YUM source code to the Windows Udpate code.

    What about the "feature" on Windows Update that causes it to bug me to install the same Outlook Express patch every 30 minutes, even though I've installed it 10 times already, and I don't even use Outlook Express for email anymore!!!

    Or how about the code that bugs you until you reboot, interrupting your workflow until you're forced to reboot and take an early break?

    Windows Update is a big WTF.  My minimal experience with YUM has been quite pleasant, and if I saw an update that was 1000 Yottabytes, I would think twice about downloading it, and then laugh because there's probably an error on the server side.  At least the program won't crash.

  • (cs)

    "Do or do not, there is no try." -- yotta

  • (cs) in reply to TheMuuj

    TheMuuj:

    Admittedly I've become more fond of referring to such units as "Kibibytes" instead of "Kilobytes," but use of either style of unit is not a WTF unless you choose to mix 1000-based and 1024-based unites.

    <FONT face="Courier New" size=2>a poodle whose hair has been died pink is appropriately called "kibi". [<:o)]</FONT>

  • (cs) in reply to TheMuuj
    Or how about the code that bugs you until you reboot, interrupting your workflow until you're forced to reboot and take an early break?


    I assume you're talking about the nag dialog that pops up after an update is completed for Windows.  You can increase the nag timer or completely disable it if you so choose.

    As for the code being a WTF, Alex was actually complementary on the code, but I think everyone can agree that by the time Yottabytes are spoken with respect to computer storage, Yum  will have more of a chance to be in a computer history book than in actual use any more.
  • Kiriai (unregistered) in reply to TheMuuj

    TheMuuj:
    This is the biggest Not-a-WTF posted yet.  The extra code to make it support Yottabytes is minimal, and I do not think it would degrade performance (it's not likely to be the root cause of a lot of cache misses or page faults).

    Alex Papadimoulis :
    Now, there's nothing really wrong with the code. It's actually researched, written well, and commented. But none the less, I found it pretty entertaining ...

    Read next time.  We all make mistakes. 


    TheMuuj:
    I don't even use Outlook Express for email anymore!!!

    Perhaps this was the bug that Outlook was persistantly trying to fix?  ;P

  • (cs) in reply to TheMuuj
    TheMuuj:
    This is the biggest Not-a-WTF posted yet.  The extra code to make it support Yottabytes is minimal, and I do not think it would degrade performance (it's not likely to be the root cause of a lot of cache misses or page faults).

    I admit it is future-proofing to the extreme, but there's no harm from doing that.

    For those who disagree, where would be a better place to stop?  Terabytes?  We're almost there for common hard drive sizes (I give it three years), so it may be best to move on to Petabytes for a maximum theoretical number that will work for the forseeable future.

    But Petabytes is a rather arbitrary choice, isn't it?  So why not just go as high as we have consistant names for and be done with it forever, and never have to revisit the code again.  At least he acknowledges how silly such a number would be.  And if a server reports a file that big, at least it won't overflow the space allocated to display the size.

    Admittedly I've become more fond of referring to such units as "Kibibytes" instead of "Kilobytes," but use of either style of unit is not a WTF unless you choose to mix 1000-based and 1024-based unites.

    Furthermore, I wish I could compare the YUM source code to the Windows Udpate code.

    What about the "feature" on Windows Update that causes it to bug me to install the same Outlook Express patch every 30 minutes, even though I've installed it 10 times already, and I don't even use Outlook Express for email anymore!!!

    Or how about the code that bugs you until you reboot, interrupting your workflow until you're forced to reboot and take an early break?

    Windows Update is a big WTF.  My minimal experience with YUM has been quite pleasant, and if I saw an update that was 1000 Yottabytes, I would think twice about downloading it, and then laugh because there's probably an error on the server side.  At least the program won't crash.


    Agreed, except on the point about this not being a WTF.  I got to the point about yottabytes, and went 'WTF?  who on earth would have a need to store data of that magnitude?  Err. wait.. is it even possible to store that much?

    Now, with that said, just because you see something in code that makes you go WTF?, don't take that to automatically be crappy code.  I've seen plenty of things that made me go WTF m8! but followed good coding practice and standards. 

    Remember the tagline here:  'Curious Perversions in Information Technology'.  It says nothing about all shitty code, all the time.
  • EvanED (unregistered) in reply to Ytram
    Ytram:
    I assume you're talking about the nag dialog that pops up after an update is completed for Windows.  You can increase the nag timer or completely disable it if you so choose.


    Howhowhowhow? I too find that so annoying.

    I generally drag it so that it's sitting with just a few pixels of the window sitting over the corner of the system tray, the rest off screen, but disableing it would be nicer...
  • (cs) in reply to JThelen

    Oh, and since I can't edit my posts, apt-get > yum

  • (cs) in reply to EvanED
    Anonymous:
    Ytram:
    I assume you're talking about the nag dialog that pops up after an update is completed for Windows.  You can increase the nag timer or completely disable it if you so choose.


    Howhowhowhow? I too find that so annoying.

    I generally drag it so that it's sitting with just a few pixels of the window sitting over the corner of the system tray, the rest off screen, but disableing it would be nicer...


    Start -> Run -> gpedit.msc -> Local Computer Policy -> Computer Configuration -> Administrative Templates -> Windows Components -> Windows Update -> Re-prompt for restart with scheduled installations.

    Credit for this info goes to one of the commentors in this Coding Horror blog post:
    http://www.codinghorror.com/blog/archives/000294.html


  • Icarus (unregistered) in reply to DZ-Jay
    DZ-Jay:
    Alex Papadimoulis:

    A stack of 3.5" floppy discs with 1,000 yottabytes would be tall enough to make it to the sun. 14 Million times. But still ... just in case ...



    Dude, wouldn't the floppies melt when they get close to the Sun?

    Depends on the Sun. At least the older SparcStations ran pretty cool. (Despite their name.)

  • Icarus (unregistered) in reply to DZ-Jay
    Alex Papadimoulis:
    Dude, wouldn't the floppies melt when they get close to the Sun?
    Depends on the Sun. At least the older SparcStations ran pretty cool. (Despite their name.)
  • (cs) in reply to Icarus
    Anonymous:
    Alex Papadimoulis:
    Dude, wouldn't the floppies melt when they get close to the Sun?

    Depends on the Sun. At least the older SparcStations ran pretty cool. (Despite their name.)

  • Icarus (unregistered) in reply to DZ-Jay

    [Ok, something is wrong with the msg board code, sorry about the garbled posts (they showed up just right in the preview)]

    Dude, wouldn't the floppies melt when they get close to the Sun?

    Depends on the Sun. At least the older SparcStations ran pretty cool. (Despite their name.)

  • (cs) in reply to Icarus
    Anonymous:
    [Ok, something is wrong with the msg board code, sorry about the garbled posts (they showed up just right in the preview)]

    > Dude, wouldn't the floppies melt when they get close to the Sun?

    Depends on the Sun. At least the older SparcStations ran pretty cool. (Despite their name.)


    AVOID THE PREVIEW at all costs.  Switching from "Design" to "HTML" and back also results in garbled output.  Stick to the "Post" button and it'll be alright.

        dZ.
  • Kiriai (unregistered) in reply to DZ-Jay

    DZ-Jay:
    Anonymous:
    [Ok, something is wrong with the msg board code, sorry about the garbled posts (they showed up just right in the preview)]

    > Dude, wouldn't the floppies melt when they get close to the Sun?

    Depends on the Sun. At least the older SparcStations ran pretty cool. (Despite their name.)


    AVOID THE PREVIEW at all costs.  Switching from "Design" to "HTML" and back also results in garbled output.  Stick to the "Post" button and it'll be alright.

        dZ.

    I find the Captcha for unregistered users (which this time arround is Register-- there is also a very limited set of them ) also changes when you preview, which is amusing.

  • (cs)

    It's written in Python, and I don't know Python, but:


    From a Python Quick Reference:

    Floats (type float) are implemented with C doubles.

    Long integers (type long) have unlimited size (only limit is system resources).


    From Wikipedia:

    Modern computers with 32-bit stores (single precision) provide 64-bit double precision. Double precision floating point is an IEEE 754 standard for encoding floating point numbers that uses 8 bytes.


    Also from Wikipedia:
    yottabyte     YB     10^24 (or 2^80)

    Now even if the number passed in is a "long integer with unlimited size", after the first division by the float 1024.0 (see original code) it would have to fit into a 64-bit C double.

    So when exactly will it actually print out yottabytes? (Or even: when will the fallback with the funny comment ever be used?)

    Or did I miss something?

    cu

    ps: OK, I know what I missed: at the time we use zettabytes regularly we will have 256bit-CPUs. Sure?

  • -E (unregistered) in reply to Ytram
    Ytram:
    Anonymous:
    Ytram:
    I assume you're talking about the nag dialog that pops up after an update is completed for Windows.  You can increase the nag timer or completely disable it if you so choose.


    Howhowhowhow? I too find that so annoying.

    I generally drag it so that it's sitting with just a few pixels of the window sitting over the corner of the system tray, the rest off screen, but disableing it would be nicer...


    Start -> Run -> gpedit.msc -> Local Computer Policy -> Computer Configuration -> Administrative Templates -> Windows Components -> Windows Update -> Re-prompt for restart with scheduled installations.

    Credit for this info goes to one of the commentors in this Coding Horror blog post:
    http://www.codinghorror.com/blog/archives/000294.html




    LOL - Now that's usability/user friendlyness in only 9+ easy steps ;)

    -E
  • (cs) in reply to eagle
    eagle:

    Now even if the number passed in is a "long integer with unlimited size", after the first division by the float 1024.0 (see original code) it would have to fit into a 64-bit C double.


    A 64-bit C double is perfectly capable of holding a number larger than 2^80 or even 2^1000 - don't see the problem you're referring to.
  • (cs) in reply to Maurits
    Maurits:
    eagle:

    Now even if the number passed in is a "long integer with unlimited size", after the first division by the float 1024.0 (see original code) it would have to fit into a 64-bit C double.


    A 64-bit C double is perfectly capable of holding a number larger than 2^80 or even 2^1000 - don't see the problem you're referring to.


    Not to mention that I doubt a yottabyte is even addressable in either memory or on file systems with current hardware.  The reason for no arbitrary limits in software is so that when you port to larger word lengths and larger hardware accessability you won't have to go back and rewrite your code for the new platform.  You just recompile and go.
  • (cs) in reply to Maurits
    Maurits:
    eagle:

    Now even if the number passed in is a "long integer with unlimited size", after the first division by the float 1024.0 (see original code) it would have to fit into a 64-bit C double.


    A 64-bit C double is perfectly capable of holding a number larger than 2^80 or even 2^1000 - don't see the problem you're referring to.


    Shame on me. Haven't slept for >36 hours, perhaps that explains it.
  • cowbert (unregistered)

    Every time I see "yotta" I think of those Japanese singers with the figleaf underwear that sing that song.

  • Drew R (unregistered)

    Don't they mean... Yatta?
  • Joshua Norman (unregistered) in reply to marijne
    Anonymous:
    Wow. That's a yotta data.
    Oh God, I think my spleen just ruptured. ><
  • (cs) in reply to Trev

    Anonymous:
    1000 yottabytes is absurd.  640 yottabytes should be enough for anyone.

    ROFLMAO!!!!

    Man, that one goes into my sig.

  • Kannan Goundan (unregistered)

    <bockequote>

    It's actually researched, written well, and commented. But none the less, I found it pretty entertaining ...
    </bockequote>


    Isn't the code wrong?  That last line should be:



       number = number * (1024**diff)


    Also, the code would be a lot simpler if it checked for overflow while looping:



       depth = 0
       max_depth = len(symbols) - 1
    


       while number > thresh and depth < max_depth:
          depth  = depth + 1
          number = number / 1024

  • Anon (unregistered)

    Because it is an open source application, it is very likely that this code was put in there to "joke" with other programmers. It wouldn't degrade performance at all, and it is still funny to read. Inside jokes like this are common in many open source applications, it keeps developing a little more lighthearted.

  • (cs) in reply to TheMuuj

    Am I the only one that thinks 'kibibytes', 'mibibytes', 'gibibytes' and what, 'tebibytes'(?) sound absurdly childish? It makes me think of the Teletubbies (HORROR!). I strongly object to this 10x scheme of 'a kilobyte is 1000 bytes', no matter how many IEEE, ISO and marketing committees they throw at it. And the SI not an argument either. A bit has two possible values, not ten.

    1 km = 10    3 meter
    1 kg = 103 gram
    1 megaton = 10    6 ton
    1 ml = 1/103 liter
      :
    <insert your favorite unit here>
      :
    1 KB = 2    10 bytes

    Notice a pattern? I think it's obvious, when we say byte, we mean base 2, when we say any other unit (except for time), we're dealing in base 10. It wasn't confusing until those KiBiBytes came along. Now you have to wonder whether a person would say KiBiByte to find out if they mean 1024 or 1000 by kilobyte.

  • Anonymous (unregistered) in reply to marijne
    Anonymous:
    Wow. That's a yotta data.


    Looks like Tim the Toolman Taylor just joined in...

Leave a comment on “Just In Case It's Needed”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article