Who here on/. has not yet figured out that the only ones who seriously and pejoratively use the word "fanboi" are the "fanbois" from the other side, whatever the pissing match may be about?
Grow up, people... It's a consumer product, not a cult (for most of us, anyway).
Even EBCDIC will be readable in 2070. Character sets are simple substitution ciphers (albeit some with variable length characters), most of which are exceptionally well documented both electronically and in real books. Not only that, but as long as the language of interest is not mutilated beyond statistical recognition and the details of said mutilation lost in the mists of time, text of any moderate length in a character-stream format will always be readable without historical record of the encoding used. Character substitution ciphers are dead easy - elementary school kids can crack them if you can hold their interest long enough.
You could make up your own character set and never tell anyone how it works and a determined historian (at least some of whom would necessarily be passably competent with ciphers in 2070) would almost certainly crack it, at least for the letters in whatever languages you use.
Maybe you missed the "Idle" tag. I'm *not* gonna research an "Idle" story. If they can't put it in the article, I'll make it up like everyone else will.
Update: I see from elsewhere in the comments that the previous/. article had that info. It was a 4 GB stick, so assuming it had about 3900 MB of data, the data rate was about 512 kilobytes per second.
Huh? You can't send pigeons both ways at the same time? As far as I know, you can pipeline pigeons too. I guess if you're talking about the one pigeon it's not gonna "home" both ways, but one data packet doesn't go both ways on an electronic network either.
Replacing "speed" with "data rate" and making a few other substitutions, we have a question I find interesting. "What was the data rate of that particular laden African swallow?"
The story is missing an absolutely critical piece of info though - how much data there was. Without that knowledge, the story is pretty meaningless. If I transport 30 GB of data by thumb drive physically (whether by pigeon or car or whatever) in an hour, I can get it there far faster than my home cable modem. If it was 1 MB of data, it's a very different story.
Judging by the fact that the time "including download" to the destination system was about an hour longer than the time it took for the pigeon to fly, I'd say it very well could have been at least a few GB.
For sake of a wild-ass guess, giving, say, 20 min overhead for fumbling around with the data card, putting it on and off the pigeons leg, etc., and dividing the remaining time by two (1 transfer onto and 1 transfer off of the device), that puts each transfer at around 15-18 min. At 20 MB/sec, it could have been around 18 to 21 GB of data being transferred. That translates (under the aforementioned massive and barely justifiable set of assumptions) to about 2.3 to 2.8 megabytes per second moved by pigeon (20-ish GB moved in 7617 seconds).
I'm not going to waste (more) time analyzing sensitivity to changes in my assumptions, but at a guess I'd say the result is moderately sensitive to changes in both pigeon-to-computer transfer time and pigeon-to-computer data rates. In other words, take the numbers above with a pretty big grain of salt.
The inconsistency is only annoying if you're one of the poor schmucks whose browser developers thought having a feature was invariably better than not having said feature. In fact, there's a whole slough of other "features" I've wished weren't in my browser throughout the years, too. Audio, for one.
Actually, your blog paints a picture of your readership. Agreed, 99.997% is probably made-up. After, all, 99.997% of all statistics are made up on the spot;). But (and I mean no offense when I say this as I don't know the first thing about you or your blog) I really doubt that your blog is representative of the market as a whole.
Lots of engineering problems have been solved. What's your point? I'm not normally one to defend MS, but honestly - designing an XBox (even one called "360") to withstand rotation while reading a disc is really not necessary. Not every device needs protection from every possible mode of failure. Not only that, but in this particular case your examples do not demonstrate a solution to the problem because they do not involve the same kind and amount of motion.
A discman spins its disc much more slowly ("1X" in the old-skool models, typically around 500RPM according to wikipedia) than a DVD drive, and thus gyroscopic precession is much less violent. I haven't checked, but I'd also suspect the read head is not as close to the disc due to less stringent focusing requirements. A car CD player is positioned so that the axis is vertical so that the disc experiences very little precession (the axis of the disc's rotation does not change much, ever), AND it also typically spins at around 1X. An XBox may or may not be resilient to the type of shock a jogger or a pothole would give a CD player, I don't know, but shock is not the cause of the scratch in the OP's story.
Neither of those examples demonstrates resilience to the situation described in the OP - a small plastic disc spinning at around 6000 RPM (12x DVD) undergoing a 90 degree change of axis in the span of maybe around 3/4 of a second. Neither a discman or a car CD or DVD player ever faces that situation. Honestly, I'd be a bit surprised if a cheap solution for that particular engineering challenge exists on today's market. And any solution that is not cheap would be wasteful over-engineering for an XBox, because it's just not something an XBox needs to be able to do.
A bigger issue, for me, is why the stupid Finder reports file sizes based on blocks! This makes no sense. I can plug in a flash drive, and the Finder will report that a 12KB file, copied to the desktop, is now a 16KB file. This isn't rocket science, FIX IT already, Apple!!
Well, given an 8k or 16k block size, a 12k file *DOES* consume 16k of usable disk space. Plus 600-700 bytes for the inode and directory entry. Plus more if there's any magic Apple-y metadata associated with the file.
For what reason do you expect any filesystem browser to report the exact number of bytes in a file? I'm almost always more interested in knowing how much disk space is used by the file - 16k in your example. In a filesystem like JFS that dynamically allocates inodes, I might even expect it to report the space used by the inode. FWIW, 'du' will report 16k in your example as well. Is 'du' wrong too?
Also, what should it report for directories? Taking a directory of the source of GHC 6.10.4 on my computer as an example (lots and lots of smallish source code files):
$ find . -type f -exec cat {} \; | wc -c
29776950 $ du -sk . 35036 .
Those numbers don't match (taking into account the conversion between bytes in the first case and kb in the second), but I can't see a reason ever to care about the first one. It's not even a very good indicator of what size an uncompressed tar file would be.
Finally, I just went and took a look at a small file on the desktop of my mac. "Get Info" tells me:
Size: 8 KB on disk (782 bytes)
So it *does* report the number of bytes in the file, as well as the disk usage, clearly labeled. Now I really don't exactly know what you're whining about.
Sounds like we need a/. poll on this. Personally, I'd have to rate "Scrum" as a worse name than "Extreme Programming", though they're both way up there.
I would not be surprised if the rates have not changed significantly. The problem is not the phones, the problem is the people who do not have enough respect for the 1 million or so Joules of kinetic energy in their control. People have always had things that could have distracted them.
Slashdot Mirror
If it's obscure and someone can make a cool popular product out of it, then they have innovated, no matter how old the component technologies may be.
Who here on /. has not yet figured out that the only ones who seriously and pejoratively use the word "fanboi" are the "fanbois" from the other side, whatever the pissing match may be about?
Grow up, people... It's a consumer product, not a cult (for most of us, anyway).
I don't think I'd worry too much about modern education doing anything of the sort...
Sounds to me more like our moral framework as such never existed.
"Deity" is spelled similarly to the non-word "diety". I'm pretty sure that's all he's on about.
I dunno, how did your brother turn out?
I tried playing soccer inside a few times. It's just not a good idea.
The one at Alexandria would've benefitted from more offsite backup.
Meanwhile, the cost of each 9 is exponentially higher than the last one was.
And its value is exponentially smaller.
I don't even use cursive in my signature.
Even EBCDIC will be readable in 2070. Character sets are simple substitution ciphers (albeit some with variable length characters), most of which are exceptionally well documented both electronically and in real books. Not only that, but as long as the language of interest is not mutilated beyond statistical recognition and the details of said mutilation lost in the mists of time, text of any moderate length in a character-stream format will always be readable without historical record of the encoding used. Character substitution ciphers are dead easy - elementary school kids can crack them if you can hold their interest long enough.
You could make up your own character set and never tell anyone how it works and a determined historian (at least some of whom would necessarily be passably competent with ciphers in 2070) would almost certainly crack it, at least for the letters in whatever languages you use.
Maybe you missed the "Idle" tag. I'm *not* gonna research an "Idle" story. If they can't put it in the article, I'll make it up like everyone else will.
Update: I see from elsewhere in the comments that the previous /. article had that info. It was a 4 GB stick, so assuming it had about 3900 MB of data, the data rate was about 512 kilobytes per second.
Huh? You can't send pigeons both ways at the same time? As far as I know, you can pipeline pigeons too. I guess if you're talking about the one pigeon it's not gonna "home" both ways, but one data packet doesn't go both ways on an electronic network either.
What's the speed of an unloaden African swallow?
Replacing "speed" with "data rate" and making a few other substitutions, we have a question I find interesting. "What was the data rate of that particular laden African swallow?"
The story is missing an absolutely critical piece of info though - how much data there was. Without that knowledge, the story is pretty meaningless. If I transport 30 GB of data by thumb drive physically (whether by pigeon or car or whatever) in an hour, I can get it there far faster than my home cable modem. If it was 1 MB of data, it's a very different story.
Judging by the fact that the time "including download" to the destination system was about an hour longer than the time it took for the pigeon to fly, I'd say it very well could have been at least a few GB.
For sake of a wild-ass guess, giving, say, 20 min overhead for fumbling around with the data card, putting it on and off the pigeons leg, etc., and dividing the remaining time by two (1 transfer onto and 1 transfer off of the device), that puts each transfer at around 15-18 min. At 20 MB/sec, it could have been around 18 to 21 GB of data being transferred. That translates (under the aforementioned massive and barely justifiable set of assumptions) to about 2.3 to 2.8 megabytes per second moved by pigeon (20-ish GB moved in 7617 seconds).
I'm not going to waste (more) time analyzing sensitivity to changes in my assumptions, but at a guess I'd say the result is moderately sensitive to changes in both pigeon-to-computer transfer time and pigeon-to-computer data rates. In other words, take the numbers above with a pretty big grain of salt.
The inconsistency is only annoying if you're one of the poor schmucks whose browser developers thought having a feature was invariably better than not having said feature. In fact, there's a whole slough of other "features" I've wished weren't in my browser throughout the years, too. Audio, for one.
Actually, I'd say he described (not exemplified) the disaster that is humanity.
Actually, your blog paints a picture of your readership. Agreed, 99.997% is probably made-up. After, all, 99.997% of all statistics are made up on the spot ;). But (and I mean no offense when I say this as I don't know the first thing about you or your blog) I really doubt that your blog is representative of the market as a whole.
Lots of engineering problems have been solved. What's your point? I'm not normally one to defend MS, but honestly - designing an XBox (even one called "360") to withstand rotation while reading a disc is really not necessary. Not every device needs protection from every possible mode of failure. Not only that, but in this particular case your examples do not demonstrate a solution to the problem because they do not involve the same kind and amount of motion.
A discman spins its disc much more slowly ("1X" in the old-skool models, typically around 500RPM according to wikipedia) than a DVD drive, and thus gyroscopic precession is much less violent. I haven't checked, but I'd also suspect the read head is not as close to the disc due to less stringent focusing requirements. A car CD player is positioned so that the axis is vertical so that the disc experiences very little precession (the axis of the disc's rotation does not change much, ever), AND it also typically spins at around 1X. An XBox may or may not be resilient to the type of shock a jogger or a pothole would give a CD player, I don't know, but shock is not the cause of the scratch in the OP's story.
Neither of those examples demonstrates resilience to the situation described in the OP - a small plastic disc spinning at around 6000 RPM (12x DVD) undergoing a 90 degree change of axis in the span of maybe around 3/4 of a second. Neither a discman or a car CD or DVD player ever faces that situation. Honestly, I'd be a bit surprised if a cheap solution for that particular engineering challenge exists on today's market. And any solution that is not cheap would be wasteful over-engineering for an XBox, because it's just not something an XBox needs to be able to do.
A bigger issue, for me, is why the stupid Finder reports file sizes based on blocks! This makes no sense. I can plug in a flash drive, and the Finder will report that a 12KB file, copied to the desktop, is now a 16KB file. This isn't rocket science, FIX IT already, Apple!!
Well, given an 8k or 16k block size, a 12k file *DOES* consume 16k of usable disk space. Plus 600-700 bytes for the inode and directory entry. Plus more if there's any magic Apple-y metadata associated with the file.
For what reason do you expect any filesystem browser to report the exact number of bytes in a file? I'm almost always more interested in knowing how much disk space is used by the file - 16k in your example. In a filesystem like JFS that dynamically allocates inodes, I might even expect it to report the space used by the inode. FWIW, 'du' will report 16k in your example as well. Is 'du' wrong too?
Also, what should it report for directories? Taking a directory of the source of GHC 6.10.4 on my computer as an example (lots and lots of smallish source code files):
$ find . -type f -exec cat {} \; | wc -c
29776950
$ du -sk .
35036 .
Those numbers don't match (taking into account the conversion between bytes in the first case and kb in the second), but I can't see a reason ever to care about the first one. It's not even a very good indicator of what size an uncompressed tar file would be.
Finally, I just went and took a look at a small file on the desktop of my mac. "Get Info" tells me:
Size: 8 KB on disk (782 bytes)
So it *does* report the number of bytes in the file, as well as the disk usage, clearly labeled. Now I really don't exactly know what you're whining about.
Sounds like we need a /. poll on this. Personally, I'd have to rate "Scrum" as a worse name than "Extreme Programming", though they're both way up there.
I would not be surprised if the rates have not changed significantly. The problem is not the phones, the problem is the people who do not have enough respect for the 1 million or so Joules of kinetic energy in their control. People have always had things that could have distracted them.
And it's for an architecture you don't have.
). Captured your post! You've been parenthesized!
If you seed it long enough to reach a 1:1 up/down ratio, then it has in turn been stolen from you, giving no taxable net gain on your part, right? ;)