If this were true, it would be a great place to keep offsite backups.
However, I can't help but think that this is a mistake. Providing a terabyte of storage space per user is not only pointless, it's pretty much impossible.
I remember some Discovery piece about another giant meteor hitting around area of the Yucatan several hundred million years ago. I could swear that they were using that crator as evidence of the great die off too.
You're confusing the "great dying" of 250m years ago with the extinction of the dinosaurs 65m years ago. The Yucatan meteor has long been used as a possible explanation of the latter. This new crater off the coast of Australia is now seen as a possible explanation of the former.
How would these sensors know the difference between hikers and wildlife? I think that most of the data collected by these sensors will be false hits, and therefore I question how useful this data could really be.
I do hope they choose to go down... I wanna see what that ripply stuff at the bottom of the crater is made out of.
I suspect that it's just wind-blown sand/dust. I also suspect that the guys at NASA suspect that, and are aren't particularly interested in it. I also suspect that they'll specifically avoid going that far down into the crater because that stuff looks real easy to get stuck in.
Unfortunately, Kodak stopped making gold CD-Rs a few years ago. I used to use them exclusively until they did. I guess the market demand wasn't high enough for them. People would rather pay 5 cents less for a disk than have a more reliable medium.
The only other gold CD-Rs I'm aware of are Mitsumi Gold, and I was shocked to hear that these are no longer made either (as of just a few months ago)! Doh!
If anybody knows of any other gold CD-Rs on the market, please let me know! In the meantime, I guess I'll just have to be very diligent with my backups.
I remember seeing buried deep a Star Trek compendium that there was an episode called 'Twilight Zone' that was yanked from syndication due to anti-Japanese sentiments expressed in the episode. However, I've never been able to find confirmation of this anywhere else. Is it true?
I used to be quite a knowledgeable Trek fan, and I've never heard of such an episode. Perhaps such an episode made it as far as a script, but I'm pretty sure it wasn't filmed. (But IANLAKTF, so I could be wrong.)
Aw, I just thought you were being clever by using the word shoes in a "no new characters whose shoes must be filled" context. I guess that seems like a silly interpretation now, but it never ceases to amaze me how the mind manages to weave sense into things.
That's easy to fix. Replace one of those lines with GOTO 12000, then put all that stuff at 12000, ending with a GOTO pointed at the line after GOTO 12000. The first time I had to do that, my first thought was "this is going to turn out badly". It turned out I was right.
When I encountered this problem for the first time, I decided to use a GOSUB instead. My first thought was "this is going to turn out badly". It turned out that I was wrong; I had just discovered structured programming.
The only difference is that Bill forsees getting rid of the intermediate step of writing code to represent the visual system. Which is not, inherently, a bad idea, as that's the step that introduces the most bugs.
Yeah, but that happens to also be the step that introduces the details of the logic! These details can't be magically derived. They must be crafted by a programmer. If that involves drawing lots of highly detailed pictures within pictures at the "design" level, then fine, but it wouldn't make anything less complex or less bug-ridden. For the most part, the complexity of programming is inherent. Abstraction and the use of building-block libraries help tremendously, of course, but these techniques work just as well in the written-programming-language world as they do in the design-by-drawing-pictures world.
This is something I've always wondered about... Why do I see Ms. Pac Man games everywhere, but hardly ever the original Pac Man? Back in their days, Pac Man was immensly more popular than Ms. Pac Man. Why, then, do I not see more original Pac Man games around? I'd especially expect to see it at an exhibition like this! But no, it's Ms. Pac Man again. WTF?
Sorry, I don't care what tools are available, parsing a comma delimited file when the records are reasonably simple in structure will always be easier. XML is really only usefull when the data resists structure.
I have to slightly disagree with you there. Even if you start with a simple structure that can be handled okay by a simple comma-delimited set of values, things tend to evolve. What will happen to your encoding when a decision is made to add a bit more structure to the data in the future, such as allowing some parameterization on the items, or allowing tuples of items, etc.? More importantly, what will happen to the existing codebase that has been hardcoded to parse the simple comma-separated list? Using XML for even simple structures allows for more structure to be added in the future while allowing existing applications to read through it. That's been my experience, anyways.
In all of the discussion of this technology and similar technologies, I have yet to see an actual example of an image that was constructed in this way. Does anybody know of any examples? I'd really like to see how well hi-res information can be mined from low-resolution pans (or slightly-offset low-resolution images).
I suspect that certain space telescopes do something like this. I wonder if, for example, the images we have of Pluto are constructed by taking multiple photos that are slightly offset and mining higher-resolution data from them.
I hate it when people use extreme amounts of decimal precision when talking about irrational numbers. Really, is 1.6180339887 (or 1.6180339887498948482045868343656) much more informative than 1.618? If you're going to do calculations with it, use the exact value:
1/2 * (sqrt(5) + 1)
and sort out the irrational bits at the end, rather than introduce rounding errors at the beginning.
This is sound advice for hand calculations, but of course it doesn't apply for floating-point calculations performed on a computer. The two statements:
a * (sqrt(5) + b)
and:
a * (2.23606797749978969640 + b)
are exactly equivalent computationally using double-precision floating-point arithmetic on a 32-bit processor. In fact, the second statement will execute more quickly because there's no need to perform an expensive sqrt() operation.
The reason that these statements are equivalent is that floating-point calculations can't deal with irrational numbers. Heck, they can't even deal with most rational numbers. A lot of people don't realize this, but the even simple fraction 1/3 can't be represented exactly as a floating point number. All the function call sqrt(5) does is calculate the floating-point number that's closest in value to the square root of 5. If you can provide that to the program as a constant, then you save an unnecessary computation step.
Obviously for readability you'd define a named constant (e.g., SQRT5) rather than just using the number in place explicitly, but my point is that you're still better off defining the value of that constant as 2.23606797749978969640 rather than as sqrt(5).
Can anyone explain to me why the horizon of the hi-res images is bitmapped?
Every single pixel in the sky is exactly 0xD6A57A, which is very extraordinarily unlikely in a CCD-produced image. The only obvious answer is that the sky in this particular image was painted out for some reason. The sharp pixels on the horizon are a side-effect of this. (Side note: they could have done a better job of this by alpha-blending a couple of pixels down.) Why they did this, I don't know. I'm sure it wasn't to deceive. It was probably just to remove the ugly striping that usually results from stitching a number of images together into a single panoramic image.
FYI, up until very recently, the kermit protocol was still being shipped with Red Hat Linux, via the gkermit application. It looks like a fairly recent implementation, too. It doesn't look like it exists in Red Hat 9, though.
"The image "http://www.tawbaware.com/maxlyons/gigapixel_strip.jpg" cannot be displayed, because it contains errors"
Some jpeg limitation in Mozilla or plain slashdotting or what?
xv handles it okay (although doesn't let you pan it at its full resolution - an issue xv always has with larger-than-screen images).
As a side note, I have xv hooked into my browser because I like the flexibility it provides me when viewing images. Unfortunately, Mozilla doesn't allow this, due to bug #58554, so I'm stuck using Netscape 4.7 until this bug is resolved.
So what the writeup is saying is that there's a whole lotta data, which is a problem, and that 92% of that data probably won't survive that long, which is a problem. It sounds like these two problems cancel each other out! (That is, as long as the 8% that does survive is the useful stuff.)
It was the last computer I ever programmed that you could understand top to bottom.
Same here. I think we grew up in a very unique generation. Children today don't stand a chance in hell of understanding computers in their entirety, of being able to visualise the running of a program right from the op-codes pushing the bits through the registers to the end product of what they see on the screen. There's no choice today but to specialize on a certain aspect of computers and remain naive about the other aspects. Of course, even our generation has to specialise when working with modern computers, but we have the unique advantage of understanding in a very real sense the framework in which our specialization sits. That, I believe, makes us (in general) better programmers, because it gives us the intuition that a lot of newcomers lack.
When I have children I'd love to be able to teach them 6502 assember because I think it'd give them a good appreciation of how computers work, but realistically I know they're not going to give a damn, and they probably can't afford to give a damn if they're going to be useful as higher-level programmers in tomorrow's world.
As an aside, those of you that still have a working C=64 or VIC-20 (or an emulator), check out the Connect-4 game I wrote in assembler about six years ago. It's very lean (only 1520 bytes), and plays quite well. The source code is here, and the load-and-run executables for the C=64 and unexpanded VIC-20 are here and here respectively.
The company has also indicated, however, that should it lose such a case, there are no provisions for refunding IP license fees.
Is this legal? I mean, can they get away with this once the courts decide that they're full of shit? If a person buys an IP license fee and then the courts decide that no such IP license exists, wouldn't he or she be legally entitled to a refund?
Also, The Gimp doesn't handle 16-bits-per-sample images. You need a special hacked version of The Gimp called "Film Gimp" for that. WTF? Also, how about a simple red-eye reduction mechanism?
Don't get me wrong, I use The Gimp almost exclusively for my photo-editing needs. (Although in some simple situations xv or the pbmplus utilities suffice). But it does lack a few very important things (IMHO) that Photoshop provides.
Slashdot Mirror
However, I can't help but think that this is a mistake. Providing a terabyte of storage space per user is not only pointless, it's pretty much impossible.
You're confusing the "great dying" of 250m years ago with the extinction of the dinosaurs 65m years ago. The Yucatan meteor has long been used as a possible explanation of the latter. This new crater off the coast of Australia is now seen as a possible explanation of the former.
Holy shmokes! Imagine a beowulf cluster of these!
How would these sensors know the difference between hikers and wildlife? I think that most of the data collected by these sensors will be false hits, and therefore I question how useful this data could really be.
I suspect that it's just wind-blown sand/dust. I also suspect that the guys at NASA suspect that, and are aren't particularly interested in it. I also suspect that they'll specifically avoid going that far down into the crater because that stuff looks real easy to get stuck in.
The only other gold CD-Rs I'm aware of are Mitsumi Gold, and I was shocked to hear that these are no longer made either (as of just a few months ago)! Doh!
If anybody knows of any other gold CD-Rs on the market, please let me know! In the meantime, I guess I'll just have to be very diligent with my backups.
I used to be quite a knowledgeable Trek fan, and I've never heard of such an episode. Perhaps such an episode made it as far as a script, but I'm pretty sure it wasn't filmed. (But IANLAKTF, so I could be wrong.)
Aw, I just thought you were being clever by using the word shoes in a "no new characters whose shoes must be filled" context. I guess that seems like a silly interpretation now, but it never ceases to amaze me how the mind manages to weave sense into things.
When I encountered this problem for the first time, I decided to use a GOSUB instead. My first thought was "this is going to turn out badly". It turned out that I was wrong; I had just discovered structured programming.
Yeah, but that happens to also be the step that introduces the details of the logic! These details can't be magically derived. They must be crafted by a programmer. If that involves drawing lots of highly detailed pictures within pictures at the "design" level, then fine, but it wouldn't make anything less complex or less bug-ridden. For the most part, the complexity of programming is inherent. Abstraction and the use of building-block libraries help tremendously, of course, but these techniques work just as well in the written-programming-language world as they do in the design-by-drawing-pictures world.
Is it just me, or does it look like there are footprints in this image? Hmmm....
This is something I've always wondered about... Why do I see Ms. Pac Man games everywhere, but hardly ever the original Pac Man? Back in their days, Pac Man was immensly more popular than Ms. Pac Man. Why, then, do I not see more original Pac Man games around? I'd especially expect to see it at an exhibition like this! But no, it's Ms. Pac Man again. WTF?
Betcha you'd watch the female teams!
I suspect that certain space telescopes do something like this. I wonder if, for example, the images we have of Pluto are constructed by taking multiple photos that are slightly offset and mining higher-resolution data from them.
a * (sqrt(5) + b)
and:
a * (2.23606797749978969640 + b)
are exactly equivalent computationally using double-precision floating-point arithmetic on a 32-bit processor. In fact, the second statement will execute more quickly because there's no need to perform an expensive sqrt() operation.
The reason that these statements are equivalent is that floating-point calculations can't deal with irrational numbers. Heck, they can't even deal with most rational numbers. A lot of people don't realize this, but the even simple fraction 1/3 can't be represented exactly as a floating point number. All the function call sqrt(5) does is calculate the floating-point number that's closest in value to the square root of 5. If you can provide that to the program as a constant, then you save an unnecessary computation step.
Obviously for readability you'd define a named constant (e.g., SQRT5) rather than just using the number in place explicitly, but my point is that you're still better off defining the value of that constant as 2.23606797749978969640 rather than as sqrt(5).
Every single pixel in the sky is exactly 0xD6A57A, which is very extraordinarily unlikely in a CCD-produced image. The only obvious answer is that the sky in this particular image was painted out for some reason. The sharp pixels on the horizon are a side-effect of this. (Side note: they could have done a better job of this by alpha-blending a couple of pixels down.) Why they did this, I don't know. I'm sure it wasn't to deceive. It was probably just to remove the ugly striping that usually results from stitching a number of images together into a single panoramic image.
FYI, up until very recently, the kermit protocol was still being shipped with Red Hat Linux, via the gkermit application. It looks like a fairly recent implementation, too. It doesn't look like it exists in Red Hat 9, though.
xv handles it okay (although doesn't let you pan it at its full resolution - an issue xv always has with larger-than-screen images).
As a side note, I have xv hooked into my browser because I like the flexibility it provides me when viewing images. Unfortunately, Mozilla doesn't allow this, due to bug #58554, so I'm stuck using Netscape 4.7 until this bug is resolved.
So what the writeup is saying is that there's a whole lotta data, which is a problem, and that 92% of that data probably won't survive that long, which is a problem. It sounds like these two problems cancel each other out! (That is, as long as the 8% that does survive is the useful stuff.)
Same here. I think we grew up in a very unique generation. Children today don't stand a chance in hell of understanding computers in their entirety, of being able to visualise the running of a program right from the op-codes pushing the bits through the registers to the end product of what they see on the screen. There's no choice today but to specialize on a certain aspect of computers and remain naive about the other aspects. Of course, even our generation has to specialise when working with modern computers, but we have the unique advantage of understanding in a very real sense the framework in which our specialization sits. That, I believe, makes us (in general) better programmers, because it gives us the intuition that a lot of newcomers lack.
When I have children I'd love to be able to teach them 6502 assember because I think it'd give them a good appreciation of how computers work, but realistically I know they're not going to give a damn, and they probably can't afford to give a damn if they're going to be useful as higher-level programmers in tomorrow's world.
As an aside, those of you that still have a working C=64 or VIC-20 (or an emulator), check out the Connect-4 game I wrote in assembler about six years ago. It's very lean (only 1520 bytes), and plays quite well. The source code is here, and the load-and-run executables for the C=64 and unexpanded VIC-20 are here and here respectively.
Is this legal? I mean, can they get away with this once the courts decide that they're full of shit? If a person buys an IP license fee and then the courts decide that no such IP license exists, wouldn't he or she be legally entitled to a refund?
That's exactly why it's seen as such a good media for advertisements. The ads can literally be "in your face".
Don't get me wrong, I use The Gimp almost exclusively for my photo-editing needs. (Although in some simple situations xv or the pbmplus utilities suffice). But it does lack a few very important things (IMHO) that Photoshop provides.