- Feature Articles
- CodeSOD
-
Error'd
- Most Recent Articles
- Stop Poking Me!
- Operation Erred Successfully
- A Dark Turn
- Nothing Doing
- Home By Another Way
- Coast Star
- Forsooth
- Epic
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
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.
Admin
Note to self: Order more hard drives.
Admin
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!
Admin
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?[:$]
Admin
Mmmmmmmmmmm, 1000 yottabytes of hot dogs. <drool/><font color="#006400"></font>
Admin
Wow. That's a yotta data.
Admin
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.
Admin
Forward thinking like this would have prevented the Y2K crisis.
Admin
Dude, wouldn't the floppies melt when they get close to the Sun?
dZ.
Admin
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.
Admin
HAHA, dZ, you're pragmatism has no bounds.
Admin
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!
Admin
I would write that in just for fun, just so I could type "yottabyte" in my code.
Admin
A large part of Y2K was that sort of thinking.
<font size="2">http://www.j-paine.org/singularity.html</font>
Sincerely,
Gene Wirchenko
Admin
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.
Admin
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. :)
Admin
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.
Admin
1000 yottabytes is absurd. 640 yottabytes should be enough for anyone.
Admin
I think it's worse than that; I think they meant to write
rather thanAdmin
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.
Admin
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.
Admin
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
Admin
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.
Admin
"Do or do not, there is no try." -- yotta
Admin
<FONT face="Courier New" size=2>a poodle whose hair has been died pink is appropriately called "kibi". [<:o)]</FONT>
Admin
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.
Admin
Read next time. We all make mistakes.
Perhaps this was the bug that Outlook was persistantly trying to fix? ;P
Admin
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.
Admin
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...
Admin
Oh, and since I can't edit my posts, apt-get > yum
Admin
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
Admin
Depends on the Sun. At least the older SparcStations ran pretty cool. (Despite their name.)
Admin
Admin
Admin
[Ok, something is wrong with the msg board code, sorry about the garbled posts (they showed up just right in the preview)]
Admin
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.
Admin
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.
Admin
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?
Admin
LOL - Now that's usability/user friendlyness in only 9+ easy steps ;)
-E
Admin
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.
Admin
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.
Admin
Shame on me. Haven't slept for >36 hours, perhaps that explains it.
Admin
Every time I see "yotta" I think of those Japanese singers with the figleaf underwear that sing that song.
Admin
Don't they mean... Yatta?
Admin
Admin
ROFLMAO!!!!
Man, that one goes into my sig.
Admin
<bockequote>
</bockequote>Isn't the code wrong? That last line should be:
Also, the code would be a lot simpler if it checked for overflow while looping:
Admin
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.
Admin
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 = 103 meter
1 kg = 103 gram
1 megaton = 106 ton
1 ml = 1/103 liter
:
<insert your favorite unit here>
:
1 KB = 210 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.
Admin
Looks like Tim the Toolman Taylor just joined in...