It seems much more likely that it was a single body that split up into multiple smaller bodies, much as Shoemaker-Levy did, where one hit Mars and a much larger one hit Earth. The timing (both about the same time) does make for a strong case that the collisions are related, but a game of astral pinball, with the object riccocheting off Mars to hit Earth, seems unlikely to me. Given that, then, what are the possibilities? Well, one, as I said, is that the object simply fragmented (say by passing too close to Jupiter) and different sized fragments hit the different planets.
A second option, though this seems much less likely, is that the object striking the Earth partially survived. The Earth had been pretty much mulched and a moon thrown off from outer crust materials (which is why it has such a low density), but it's possible to imagine a dense core surviving from the original object. Provided it was on an outward trajectory, this body, having passed through Earth in effect, could have gone on to strike Mars. This has the same problems as an object striking Mars then Earth.
Third up would be a double planetoid (similar to Pluto/Charon) or a planet with a large moon having its orbit disturbed, where one sruck Earth and the other struck Pluto. This retains the basic idea of #1 without needing as large of a force to get the same results.
Having ionized server in the atmosphere should increase the level of air pollution substantially.
Re:Given that...
on
Terminal Chaos
·
· Score: 2, Insightful
You can't reach zero crashes with software (Turing's "Halting Problem") and that's a controlled, mathematically perfect environment that is not subject to birdstrikes, metal fatigue, component failure, short-circuits, tyre bursts, fuel tank ruptures, air pockets, windsheer, fuel contamination, St. Elmo's Fire, volcanic dust, collisions, engine fires, drunk/asleep pilots, or any of the other things that have taken aircraft out of the skies over the years.
(Computers may be subject to some of those, but the software itself is not. You can failover software, it's much harder to failover to another aircraft if yours drops out the sky.)
True, if you never use it, it's never actually claimed by the OS. However, the software can't tell that, it has the memory as far as it is concerned. In effect, the memory is wholly virtual. There is no meaningful difference as far as the physical memory is concerned between not claiming it in physical memory and having the unused memory paged out onto some external device of zero size. (Since unused memory all has the same contents, you can swap as much of it as you like onto the same external location.)
To be "complete", you'd have the malloc debugger add dynamic probes to the OS' page tables and to the OS' swap system, to track actual page usage (both internal and external) by the program. Not only would this be substantially harder to manage, it risks changing the environment too much unless swap pages are of equal size and of equal fragmentation to memory pages, although if you've a large enough machine you could do it. I'd not like to try this level of monitoring under Windows, though. Linux, Solaris and OS/X would be fine, so you could use this to accurately track Firefox, Opera and Konqueror.
...it doubles the WoW bill. If that's still cheaper than prozac or lorazapam, then I guess it's ok. In either case, though, the "correct" treatment is to tackle the underlying issue, not let it stagnate. Stagnant problems are no different from stagnant pools - they will only improve as far as bloodsucking vermin are concerned.
Smaller value?
on
Terminal Chaos
·
· Score: 2, Insightful
Let's take a look at the numbers. From the article, we have.032 hull losses per 1 million departures vs..049, which is equal to 32 hpb vs. 49 hpb. If we are measuring in absolute terms, the actual increase is extremely small. If we subtract out some baseline value, however, then the effective increase becomes much larger. (An increase of 1 to 2 is a doubling. An increase of 10 to 11 is a change of 1/10th. The fact that they are both +1 is irrelevent.)
Can flight be made totally safe? No. Machines have a statistical probability of failure, and that will never be zero. In the case of an aircraft, you have a very complex machine, where each part and the various assemblies of parts right up to the complete system each has a probability of failure. You can make a computer program bug-free long before you can make an aircraft fault-free, because computers are not subject to mechanical issues. The logic of a given statement will always produce the same result for the same input, no matter how many times it is run. (The output may be different - a malloc may discover that memory is exhausted - but the logic, the mathematical postcondition, is fixed and immutable.) Even if you spent an infinite amount of money, and took an infinite amount of care, the risks involved in anything physical is going to be non-zero.
Therefore, we can subtract this non-zero value from our totals. The totals become "smaller" only if you think in absurd absolute terms. If you look at how many orders of magnitude above the theoretical minimum you are, you are no longer talking in billionths, but in terms of hundreds, thousands or even millions, depending on the complexity of the aircraft and on pure maths modelling of complexity. Notice not only the change in the number of zeros, but where the decimal point is.
17 per billion flights is a tiny difference in failures. 53% greater risk is a hell of a lot bigger. But if we subtract a baseline value, that percentage goes UP, not down.
Raytracing is superior to doing nothing, but conetracing, non-uniform conetracing and wavetracing are all superior to raytracing, and all but wavetracing benefit from adding in radiosity. The advantages of raytracing over all other methods are that it is totally parallelizable and can be implemented using a fairly simple set of algorithms, potentially allowing for a truly gigantic number of compute elements on a single die. One big headache, though, is that to get a significant visual improvement, you have to cast a large number of rays per pixel (or you can't do scatter properly) and you need multiple generations (ie: secondary light sources), where each generation needs to be processed twice - once for direct reflection, once for refraction. This would be fine, but it means different rays will take a different length of time to complete, which in turn means that to get smooth motion, you have to calculate the time for the slowest possible path and synchronize to that.
Typically, however, games manufacturers do NOT mean "raytracing" when they say "raytracing". They mean basic rendering. ie: Applying of shaders and other simple colouring techniques. Renderman, the rendering package used to produce movies like Finding Nemo, uses rendering, not raytracing. Rendering is popular with movie producers because it's fast and "good enough". (Audiences differ on the subject, with plenty of people preferring model-based special-effects because the lighting is real and the reflections are correct - well, they'd better be!) My fear is that true raytracing and physically correct lighting models will be totally overlooked in favour of things that will be cheaper to produce and therefore make more money.
Re:The explanation is obvious
on
Terminal Chaos
·
· Score: 2, Insightful
Mostly true, but for how much longer? The Dreamliner is selling surprisingly well, given that it's so tiny, and the Airbus 400 generally isn't. This indicates that the trend towards increased volume has started to reverse. The pressure on airports like Heathrow to add runways is an indication that airliners are aiming to increase the number of flights rather than the number of overall passengers. This is Not Good, for many reasons (air pollution, noise pollution, increased collision risks, etc).
..."hull loss" generally means either "we are picking up fragments of the aircraft with tweezers" or "ooops, was that the end of the runway?", any achievable value is higher than you'd like. In fact, as a function of overall system quality, the measured value will be asymtotic to some non-zero value that is the practical "best" you can theoretically achieve. You will never reach this "best" value, it is only theoretical, but you can get as close to it as you like. Since this is the "best", however, the metric should be relative to it and not to zero. It's senseless to measure relative to a value substantially lower than the achievable limit. It's like talking about negative degrees kelvin, it has no meaning.
Rendering, in terms of ray-tracing, is considered trivially parallel - everything can be done in parallel with no interaction. Radiosity, where there is interaction, is potentially much more interesting.
A variant on the rendering theme: Instead of simulating rays, simulate light wavelets and the modern theory of light. You should have enough compute power there to render reasonable scenes using such a technique.
Fluid dynamics: This is a popular one, and NASA offer source codes for free for subsonic, supersonic and even hypersonic flows. In fact, they offer quite a number of subsonic ones. They're also not the only source. There's several open-source CFD packages, ranging from river simulations to aircraft simulations.
Supernovae simulation: There are packages (freeish, rather restricted in access) that allow you to simulate thermonuclear and supernovae explosions within stars. The restrictions are for rather obvious reasons, even though the odds of anyone nasty obtaining a star is, well, unlikely.
COLOSSUS: There are still a couple of ENIGMA ciphers that have never been broken, which can be obtained along with the algorithm Colossus used in World War II to crack such codes. You could complete the set and maybe discover some lost secret (yeah, right).
BLAST: Other posters have suggested renting out the computer time, but that just transfers the problem of what to run, rather than solving it. BLAST, or one of the MPI-based variants thereof, is an exceedingly popular tool for examining nucleotide sequences, but as the databases grow ever-larger, the demand for ever-more information also increases, creating a need for significant compute power to produce the volume of results desired.
I don't know about these guys, but since most of these will be dynamically linked files, I'd probably be looking for ways to trap the malloc library calls, in much the same way as most of the debug malloc implementations do for various Unixes. If you track the maximum usage and the unfreed total, you can determine the memory consumption and memory leakage without relying on any system-specific interpretation of what memory is.
...is that it is a true HPC clustering environment. They demoed the 2003 cluster edition at SC|05, and frankly I was not impressed. Nor were most other people, it was not a highly-popular stand. That could be because they were demonstrating things like Excel on the Cluster Edition. A clustered spreadsheet?! Oh, and the version of MPI they are using is derived from MPICH. For those who are unfamiliar with clustering and message passing, MPI is pretty horrible at the best of times, and MPICH is a nasty implementation of it. MPICH is great as proof-of-concept, is very portable, and superb as a teaching tool, but it's slow, lacks many of the features found in more modern implementations, and exists in a million different variants because it's really not very pluggable.
However, MPI itself has serious issues. The master copy of the program starts/stops slave programs vis SSH, although some implementations also support inetd-style starts. Messages sent to multiple machines are sent sequentially, rather than via a reliable multicast, wasting bandwidth and wasting CPU cycles.
It's the coolest name for a celestial object yet! And you just know that they'll try to slide it into a future Doctor Who. I can't wait to see David Tarrent try to keep a straight face whilst talking about the Vishnish aliens inhabiting the local Voorwerp.
It used 24 bit address space, expandable to 32, so although it only physically posessed 32 words of memory, it could easily have supported a modern operating system if the memory had been built for it. And you didn't mind the response times.
I did my best to vote it down, but obviously enough people disagreed. Press releases actually do have a place, IMHO, but only when it's something that is genuinely interesting and, well, genuine. Intel's 80 core CPU press release may or may not have qualified, as we can't know for sure if the wafer held up had 80 cores. ASUS' press release of using Linux in the BIOS was a real thing, so qualified for discussion.
...is that the photograph is taken before he presses the shutter. However, you can never know this for certain, as his finger now weighs an almost an infinite amount (albeit as an imaginary mass), which will result in the camera undergoing gravitational collapse into the finger.
Actually, I'd heard they did nickname it the Norwegian Blue, even though it was found in Denmark, on the grounds that it probably existed in Denmark as well. This story has been out for several weeks now - I posted it to the queue the moment the BBC covered it, and they're not always the first on the science stuff - so there may be more information out there. Congratulatons, btw, to the submitter who made it through the queue, it's a better writeup than the one I did and the front page is better for it.
Microsoft have already been found guilty. However, the e-book containing permissable sentences for the crime cannot be loaded unser Vista at this time. When an upgrade becomes available...
I wouldn't say thoroughly, although it was very strong. However, this special operations manual DOES warrant a close look at the death of thhe chief weapons scientist in Britain, Dr. Kelly, found dead from apparent suicide after being outed by Tony Blair's government for whistleblowing. The suicide theory was questioned at the time, but as there was no better evidence, was the one generally accepted. This special operations manual is basically a license to remove such people. Permanently. That doesn't mean that that is what happened or that they planned to (in his case), but it does mean we have concrete evidence that they planned to commit such acts when doing so would allow for the control public opinion. Public opinion was indeed in the balance at that time, and the lack of a scientist willing to credibly contradict the Government certainly helped the Government's cause.
I don't know if/how this is connected, but the psychological ops guy in charge of Gitmo interrogations at one point was also the guy responsible for LSD research, psychic powers research, and other such stuff. A real fruitcake, and a dangerous one.
Slashdot Mirror
A second option, though this seems much less likely, is that the object striking the Earth partially survived. The Earth had been pretty much mulched and a moon thrown off from outer crust materials (which is why it has such a low density), but it's possible to imagine a dense core surviving from the original object. Provided it was on an outward trajectory, this body, having passed through Earth in effect, could have gone on to strike Mars. This has the same problems as an object striking Mars then Earth.
Third up would be a double planetoid (similar to Pluto/Charon) or a planet with a large moon having its orbit disturbed, where one sruck Earth and the other struck Pluto. This retains the basic idea of #1 without needing as large of a force to get the same results.
Having ionized server in the atmosphere should increase the level of air pollution substantially.
(Computers may be subject to some of those, but the software itself is not. You can failover software, it's much harder to failover to another aircraft if yours drops out the sky.)
To be "complete", you'd have the malloc debugger add dynamic probes to the OS' page tables and to the OS' swap system, to track actual page usage (both internal and external) by the program. Not only would this be substantially harder to manage, it risks changing the environment too much unless swap pages are of equal size and of equal fragmentation to memory pages, although if you've a large enough machine you could do it. I'd not like to try this level of monitoring under Windows, though. Linux, Solaris and OS/X would be fine, so you could use this to accurately track Firefox, Opera and Konqueror.
...it doubles the WoW bill. If that's still cheaper than prozac or lorazapam, then I guess it's ok. In either case, though, the "correct" treatment is to tackle the underlying issue, not let it stagnate. Stagnant problems are no different from stagnant pools - they will only improve as far as bloodsucking vermin are concerned.
Can flight be made totally safe? No. Machines have a statistical probability of failure, and that will never be zero. In the case of an aircraft, you have a very complex machine, where each part and the various assemblies of parts right up to the complete system each has a probability of failure. You can make a computer program bug-free long before you can make an aircraft fault-free, because computers are not subject to mechanical issues. The logic of a given statement will always produce the same result for the same input, no matter how many times it is run. (The output may be different - a malloc may discover that memory is exhausted - but the logic, the mathematical postcondition, is fixed and immutable.) Even if you spent an infinite amount of money, and took an infinite amount of care, the risks involved in anything physical is going to be non-zero.
Therefore, we can subtract this non-zero value from our totals. The totals become "smaller" only if you think in absurd absolute terms. If you look at how many orders of magnitude above the theoretical minimum you are, you are no longer talking in billionths, but in terms of hundreds, thousands or even millions, depending on the complexity of the aircraft and on pure maths modelling of complexity. Notice not only the change in the number of zeros, but where the decimal point is.
17 per billion flights is a tiny difference in failures. 53% greater risk is a hell of a lot bigger. But if we subtract a baseline value, that percentage goes UP, not down.
Typically, however, games manufacturers do NOT mean "raytracing" when they say "raytracing". They mean basic rendering. ie: Applying of shaders and other simple colouring techniques. Renderman, the rendering package used to produce movies like Finding Nemo, uses rendering, not raytracing. Rendering is popular with movie producers because it's fast and "good enough". (Audiences differ on the subject, with plenty of people preferring model-based special-effects because the lighting is real and the reflections are correct - well, they'd better be!) My fear is that true raytracing and physically correct lighting models will be totally overlooked in favour of things that will be cheaper to produce and therefore make more money.
Mostly true, but for how much longer? The Dreamliner is selling surprisingly well, given that it's so tiny, and the Airbus 400 generally isn't. This indicates that the trend towards increased volume has started to reverse. The pressure on airports like Heathrow to add runways is an indication that airliners are aiming to increase the number of flights rather than the number of overall passengers. This is Not Good, for many reasons (air pollution, noise pollution, increased collision risks, etc).
..."hull loss" generally means either "we are picking up fragments of the aircraft with tweezers" or "ooops, was that the end of the runway?", any achievable value is higher than you'd like. In fact, as a function of overall system quality, the measured value will be asymtotic to some non-zero value that is the practical "best" you can theoretically achieve. You will never reach this "best" value, it is only theoretical, but you can get as close to it as you like. Since this is the "best", however, the metric should be relative to it and not to zero. It's senseless to measure relative to a value substantially lower than the achievable limit. It's like talking about negative degrees kelvin, it has no meaning.
A variant on the rendering theme: Instead of simulating rays, simulate light wavelets and the modern theory of light. You should have enough compute power there to render reasonable scenes using such a technique.
Fluid dynamics: This is a popular one, and NASA offer source codes for free for subsonic, supersonic and even hypersonic flows. In fact, they offer quite a number of subsonic ones. They're also not the only source. There's several open-source CFD packages, ranging from river simulations to aircraft simulations.
Supernovae simulation: There are packages (freeish, rather restricted in access) that allow you to simulate thermonuclear and supernovae explosions within stars. The restrictions are for rather obvious reasons, even though the odds of anyone nasty obtaining a star is, well, unlikely.
COLOSSUS: There are still a couple of ENIGMA ciphers that have never been broken, which can be obtained along with the algorithm Colossus used in World War II to crack such codes. You could complete the set and maybe discover some lost secret (yeah, right).
BLAST: Other posters have suggested renting out the computer time, but that just transfers the problem of what to run, rather than solving it. BLAST, or one of the MPI-based variants thereof, is an exceedingly popular tool for examining nucleotide sequences, but as the databases grow ever-larger, the demand for ever-more information also increases, creating a need for significant compute power to produce the volume of results desired.
I don't know about these guys, but since most of these will be dynamically linked files, I'd probably be looking for ways to trap the malloc library calls, in much the same way as most of the debug malloc implementations do for various Unixes. If you track the maximum usage and the unfreed total, you can determine the memory consumption and memory leakage without relying on any system-specific interpretation of what memory is.
However, MPI itself has serious issues. The master copy of the program starts/stops slave programs vis SSH, although some implementations also support inetd-style starts. Messages sent to multiple machines are sent sequentially, rather than via a reliable multicast, wasting bandwidth and wasting CPU cycles.
And this would be worse than ME, Vista or XP Service Pack 3, how?
...is that I get a chance to dupe my bad joke about it being German-speaking Martians with their sun-loungers.
It's the coolest name for a celestial object yet! And you just know that they'll try to slide it into a future Doctor Who. I can't wait to see David Tarrent try to keep a straight face whilst talking about the Vishnish aliens inhabiting the local Voorwerp.
It used 24 bit address space, expandable to 32, so although it only physically posessed 32 words of memory, it could easily have supported a modern operating system if the memory had been built for it. And you didn't mind the response times.
I did my best to vote it down, but obviously enough people disagreed. Press releases actually do have a place, IMHO, but only when it's something that is genuinely interesting and, well, genuine. Intel's 80 core CPU press release may or may not have qualified, as we can't know for sure if the wafer held up had 80 cores. ASUS' press release of using Linux in the BIOS was a real thing, so qualified for discussion.
...is that the photograph is taken before he presses the shutter. However, you can never know this for certain, as his finger now weighs an almost an infinite amount (albeit as an imaginary mass), which will result in the camera undergoing gravitational collapse into the finger.
Actually, I'd heard they did nickname it the Norwegian Blue, even though it was found in Denmark, on the grounds that it probably existed in Denmark as well. This story has been out for several weeks now - I posted it to the queue the moment the BBC covered it, and they're not always the first on the science stuff - so there may be more information out there. Congratulatons, btw, to the submitter who made it through the queue, it's a better writeup than the one I did and the front page is better for it.
No, if there'd been Nazis there, Wallace and Grommit would have seen evidnce. Besides, what would Nazis do with all that cheese?
An' Basement Cat meleted it.
Microsoft have already been found guilty. However, the e-book containing permissable sentences for the crime cannot be loaded unser Vista at this time. When an upgrade becomes available...
The white things were Martian beach loungers. And as they were there first, I strongly suspect they were German-speaking Martians.
I don't know if/how this is connected, but the psychological ops guy in charge of Gitmo interrogations at one point was also the guy responsible for LSD research, psychic powers research, and other such stuff. A real fruitcake, and a dangerous one.
The music probably killed him. But what would you expect from such a scratchy rendition? It's almost as bad as the Formula 1 car engine version.