Sounds pretty real to me and the theory behind it is written up very nicely.
I wonder: would this work the other way round? Take a (stereo) recording of thunder and an exact time measurement between the flash and the first sound and plot the flash from that. If that worked, you wouldn't need a huge high speed camera mounted on a truck in order to record how a flash propagates...
Besides issues like temperature, you'd need to to control for interference from geographic features like hills and valleys. It might work in wide open flat spaces like the prairies of the American mid-west.
If you're interested in this, there was a very good program on PBS's science show Nova a month or two back, called 'the edge of space' or something similar, which involved photography of lightning at altitude and later from the space station, resulting in confirmation that lightning interacts with the upper atmosphere as well as the ground.
The biggest gotcha with a time-based measurement of the thunder is the variability of the speed of sound with temperature - about 0.6 m/s per degree Celsius. Given that thunderstorms tend to involve pretty significant temperature shifts, the temperature can vary significantly along the path length.
I am not familiar with hackermonthly but they seem to "reprint" material that was popular on HN. Is all that content actually correctly licensed to be used in that way? Just wondering how those logistics are working... contacting all the individual authors, working out the terms &c.
With Hacker Monthly, I believe all authors are contacted and for permission. I think compensation is even provided, perhaps in the form of a free subscription?
Yes, it was all projected. (also the side walls of the theatre). Some 20+ projectors pushing 300 million pixels/sec. The intro to the keynotes was pretty amazing as well, meshing the projection with light effects and live performance: http://www.youtube.com/watch?v=VrDPgUjqTQ8&feature=relat...
I have no idea how the US tax system works. But how about this thought: from saying you are taxable if running servers in some state, it wouldn't be a big leap saying "your javascript code runs in browsers on computers that are in our state and you are therefore taxable"...
A server is, arguably, a physical location serving products. Javascript running in a browser is the product served. Going with a tried-and-true car analogy, a state can't tax a car manufacturer because the cars drive on their roads, but they can tax them if they produce or sell cars in that state.
The fact that Macs are statistically less likely to be infected by malware does not mean they are immune. It just means, that most malware-authors are more interested in windows because of the larger number of potential victims.
(Who came up with the idea to spin the fact that Macs are less attractive to black-hats into Macs being more secure anyway?)
This wasn't so much aimed as a direct response to the joke but rather a general comment towards the fact that there are actually people who want to believe that Macs are actually more secure then any other computer. Sorry for being so unclear.
This little thread illustrates nicely that the smart thing to do is not to implement list or string functions yourself but to use a library that has been tried and tested. Spend your brain cycles on the important stuff.
I find it much more interesting to ask people when and why they would choose a linked or an array/buffer based list...
Yes, or the library of the nearest university will be likely to grant you access for a small fee even if you are not a student there, plus you will also get access to their books.
"3D movies" is a very inaccurate tag applied to the current steroscopic productions and equipment. It is, in a sense, a pragmatic extension of both traditional film-making and film watching.
When the technology for producing and watching in real 3d (e.g. volumetric display technology and corresponding recording technology) becomes available, the entire process of producing a movie will be radically different from how it is today. Currently, everything is controlled at production time. Once you get real 3D, the "camera position" is controlled by the viewer. That should be quite a change for directors and editors. Once you get real 3D, you will probably not sit still while watching a production. you will want to move around, explore it. This will have interesting effects when a lot of people are watching a production together and people flock around because they discovered something interesting in the back. Or maybe there will be a controller for moving the camera position, that would take fights for the remote to a whole new level ;)
Also, acting might become quite different from what it is today, because recording a movie might no longer be done with a photographic process but may be based purely on motion capturing. Actors would become puppeteers. (Some are today: think Gollum)
What I'm trying to say. Real 3D will be much more revolutionary for cinematography. What we are seeing today is just a gimmick. Nothing more.
I think he is comparing apples to oranges here. Using HTMl as the "rendering device" works on a different (higher) level of abstraction. The additional layer of abstraction in HTML has already solved the complexity of doing efficient partial redraws based on changes to a subset of a scene graph. This isn't something that the canvas API was meant to handle. If one were to use a scene graph (or display list) abstraction on top of canvas, it would shield the application developer from this complexity just as well as the HTML does now. However, the HTML abstraction, although more general, is implemented in native code while a canvas based scene-graph would need to go through java-script, so it is at a disadvantage as to how far it can be optimized. Basically, what he needs is SVG. :-)
Yes. It's incredibly frustrating that we can't rely on embedding SVG in HTML. (Last I looked--about 2.5 years ago, admittedly--only Firefox could do it, and only with XHTML.)
You should check out http://raphaeljs.com/ , which basically unifies the SVG API in a cross-browser way. In IE, it translates everything to VML on the fly. You need to transcode your SVG to Raphael's JSON-based format, but it's not hard to do.
