Not if that keeps the fan quiet until I run a 3 minute build in JavaCC, when it will clock up again. If I force it down, the same build will take 10 minutes. And, of course, if I check the clock speed in some software that's not designed to properly react to SpeedStep, I can get values like 209 MHz.
It's like the belief that a lot of free memory is a good thing. A lot of memory that doesn't have to be paged out is a good thing, but "free" memory is just as useful as idle cycles due to a high frequency -- it shows that you could do better in some way.
Like pclminion wrote, assigning responsibility here is a quite complicated thing. But, more importantly, there is not that much reason to assume that a small body is really part of some stable arrangement. Maybe we are saving that far-off solar system by moving an asteroid a little?
Date__(UT)__HR:MN delta deldot 1-way_LT 399_ins_LT
2029-Apr-13 21:50 0.0004284247 0.00152 0.003563 0.000000
These data are from the high-accuracy ephermis link at the jpl site right now. It's possibly using old data or doing bad rounding compared to the impact risk page, but I want you to have a look yourselves. In short, both the delta and 1-way-LT numbers here basically say the same thing: The distance in the nominal orbit will be slightly more than 64.000 kilometers, far closer than Luna, for example. In fact, it seems to be about the same height as the current Hubble Space Telescope orbit.
Once again, I just put in the numbers and this is what I got. I think this is closer than any number I saw before for the distance and to rule out a collision if it gets this close, I would imagine that they would be extremely sure of the orbit. If you add columns for the sigma for angle it freaks out and gives very high numbers, which I guess could indicate that the position is not that sure.
And that was already done before the 1 in 300 post was made. They even apologized for this taking unusually long, as some data seemed wrong. In addition, the dates are not mysteriously deleted, they simply are below 10^-10 now. There is no absolute cutoff, if they should list every possible impact it should include the possibility that every single observation is incorrect and that 2004 MN4 will actually be knocking on your door tomorrow morning, 8 AM. Do you want that listed, too?
I noticed this too... looks like NASA discarded some inaccurate observations (--> smaller number of observations), and found some old photographs of 2004 MN4 in their archive (--> longer baseline) - they must have been searching their archives for existing older sightings as soon as the impact risk started to look real bad.
The strange thing is that they seemed to use just about all observations up to two days ago. They better be sure of having a positive identification back in those March shots... The fact that they have to eliminate this many to get it to match seems a bit strange.
I tracked back the observations to the version I had in cache in my laptop. Back when the last used observation by JPL was Dec 26.14032 and the probability was 0.022, JPL reported 169 observations used. http://cfa-www.harvard.edu/mpec/K04/K04Y64.html, MPEC 2004-Y64, also lists around 160 observations in total, ending on that date. Obviously, just about every observation was used until this calculation.
Anyway, if the identification on March 15 is reasonably correct, even a hundred missing observations from the last few days shouldn't do much of a difference, if randomly chosen (not chosen just to fit the identification in March). Most of the accuracy is from the position at a certain date, not from the added precision of more measurements at just about the same time.
Nope. There are only about 20 new ones in Y71. More importantly, Y71 had not been released yet when they posted that number of 169 observations used to calculate the impact risk. I fully understand that they can't possibly use the very latest data, but eliminating data from a previous prediction is a completely different matter.
Regarding number 2, that's not really true. They have identified the object in pictures from March 2004. The thing is that by just confirming the old nominal orbit, which all along was on target to miss Earth by at least ten Earth radii, the probability of impact can go down significantly.
If you wonder, the distance between the nominal path and impact on Earth is Stretch LOV times Sigma LOV. The current predicted impats are far more off than before and it's only by the fact that the true path is hard to predict that they, too, are not eliminated.
All this said, what I really want to know is why a lot of observations have disappeared from the projections. It would be nice with some information on this, and maybe NEODyS confirming the new numbers. (They haven't performed any rerun as of yet.)
(Credit to magnuss for one of the links.)
http://www.hohmanntransfer.com/news.htm mentions that the object was found in images from March 15th. I find this odd in no way in itself, it's quite natural that the determined orbit has been back-stepped to verify where the object was before its discovery in June, as any such data would improve the accuracy far more than more observations made today. Obviously, it seems they succeeded.
The raw data linked from that site has 243 observations in total. Maybe the newest JPL data is filtering to only use observations from certain telescopes, or they're aggressively filtering out "junk" data. I would welcome some kind of explanation like "ooops, a lot of people looked at another rock" or something along those lines. Another note is that the size estimation is up again to 430 meters instead of 390. Not a big change in the light (pun intended) of the fact that this is based on the measured intensity in the data, nothing else.
2: They have said all along that the most likely outcome was to eliminate this chance. Torino 4 only means that the current data is putting it down to a quite limited range giving a high probability. Now, the orbit hasn't changed very much, BUT, it's changed enough to almost rule out the possibility of the orbit actually reaching Earth. As the nominal orbit was never that close, this is not surprising. They've been quite clear on the fact that the most likely solution was not centered on Earth. The closest nominal approach does not equate the most likely impact, as the positions for different years are possible to determine with different accuracy.
The only good way to eliminate a lot of data was a longer data arc, and that was provided by backtracking the object to March. The whole point here is that we are good at estimating position in the sky, but that our abilities to determine the distance is far worse. Several observations a large amount of time apart makes it possible to triangulate the real position. As the object also moves during that time, it's not as simple as normal triangulation, but similar principles apply.
I, for one, welcome our "publish everything" astronomical overlords.
(That said, I would still be happy to know why the number of observations is down to 160.)
You can also notice yourself in the page that the first listed observation is already in March this year. Obviously, the object was tracked back to an older photo. I can't explain the lowered number of observations, though. Eliminating that many as obvious measuring errors would be a bit surprising, if no special explanation is provided.
Interestingly enough, the first observation has been lowered to March, instead of June, and the total number of observations is down to 118 from around 170.
This seems to mean they identified this object in old shots from March and from that data could eliminate quite a lot. This is confirmed in your source. BUT, it also seems to mean that they in the process threw out 50 observations as faulty?! Some kind of later explanation of this lowered total number would surely be interesting. Was the wrong celestial body observed by some people? Or is the identification of the object in March more certain than a lot of more recent observations? Any insights?
Yeah, that's exactly why they took those extra months and implemented a lot of those security enhancements, big and small, into the codebase. That's why they let the main Windows development group handle the service pack, delaying Longhorn and the like, instead of just letting a smallar maintenance team include the necessary hotfixes and fix a few other blatant bugs.
Remember that many of these are protective measures. If I'm writing code that will only be called by trusted clients, I can know that there is a possible buffer overflow, but why should I care? The code calling me already has the appropriate permissions. OR, I can decide that the calling code could also be buggy and that I should add param checking. I can recompile everything with basic stack-protection in the compiler to detect overflows. The list goes on. This has protected them from quite a few bugs in SP2 the last few months, but that doesn't mean that those specific bugs were known during the development of SP2.
Hm... I think you answered to the wrong post. I was just wondering if one could rule out some orbits, because they would have meant that a collision should already have taken place. I've already seen the cloud, and I suppose most of the uncertainty here comes from the unknown parameters of the asteroid right now. It's just as easy to back-step as forward-stepping and then it would be possible to check if at least a few of the possible orbits would have resulted in a previous collision. A few of the approaches in the page I linked to are almost as close as the one in 2029, if I'm able to interpret the distance numbers correctly.
IANAA, but it seems like my cross referencing idea with the fact that previous approaches didn't result in impact could be worth investigating. One thing I currently can't understand is why the listed "minimum possible distance" is a few magnitudes more than an Earth radius for the 2029 encounter. Maybe that's the mean trajectory fit with the current observations, but what's nominal distance, then?
One could even wonder if the minimum possible distance gets listed incorrectly if it's on the opposite side of the Earth compared to the nominal distance. (If the mean trajectory crosses it on one side and the one farthest away actually crosses the Earth on the other side.)
The most important point in all this -- will we be able to play Duke Nukem Forever while awaiting our Doom?
What I started to wonder is if they make any attempts to backsteg from the current position. If we look at the list of possible impacts, it's obvious that there is a long series of at least somewhat probable ones in April starting in 2029. What one possibly could do for each and every possible orbit (or a Monte Carlo selection of them) is to determine if they would have already crossed Earth (or maybe the moon as we have to simulate that properly, too, anyway) at some not too distant point in time that has already passed. If that would be the case, then that orbit is obviously not the correct one, if the stepping method used for simulations is correct enough.
I doubt this could really be used to rule out the possibility of an impact, but it would be interesting to know when the last time was with a long series of more or less likely (like > 1e-8) impacts.
This doesn't have to apply to kernel stuff. A lot of Windows apps rely on for example the "common controls" API. It handles toolbars, tooltips, listviews and so on. Quite a lot of UI goodies. Most of those are implemented without any kernel side, they're normal user mode controls/"windows" with their own drawing.
Now to the point: This DLL was updated quite a few times with Internet Explorer 3, 4 and 5. The versions in Windows 98, 2000 and XP are/were directly related to the matching (sub-)version of Internet Explorer. If you wrote an app for Win-95 and wanted to use one of those common controls, the recommended redistribution scenario was redistributing IE.
If they simply ripped out anything that is officially part of the "IE codebase", it's completely true that quite a few apps would fail.
This is of course even more true of some of other APIs with a more apparent connection to Internet Explorer, like WinInet for interacting with HTTP/FTP without doing sockets yourself (and using the IE cache and other stuff) or employing the IE HTML/XML parsing and possibly rendering hosted in another application. I chose common controls because they're very frequently used, and some quite significant updates were introduced through IE. These updates are still there in "Win98 lite" and whatever you would do to a Windows system to rip out IE, but retain a reasonable level of compatibility. Just because it's part of the OS and a frequently used API doesn't mean it's kernel mode. And very little IE related code is *in the kernel*.
Now to the point: LoadImage is quite a low level function. Display drivers are allowed to use it on their own and modify its functionality. That makes it belong in kernel mode. Even if they moved back some more UI stuff from the kernel, stuff like this probably belongs there, if you buy the concept of placing display drivers in kernel mode at all.
Oh, I love this privacy concept. Then we'll see google ads adapt to our latest queries and you'll just be happy if they restrict that to Paris Hilton for p, too.
I'm fine with Google acquiring huge amounts of data, but with the wealth of possible info, I think I at least should be able to see a "clean" web, too. Sometimes I don't want to see only the search hits I've been likely to click on in the past. Giving me at least an option to see "unbiased" hits would be nice.
The real benefit of true multitasking is of course that you don't have to lock it down. The use of multitasking user mode processes would be quite limited if you only could use it to assign locked processor affinities. Likewise, the ideal situation here would be to let both OSes share both CPUs, with only maybe some additions in the idle loop and perharps an arbitrator driver in each OS. Strictly speaking, I guess an arbitrator would not be needed, but wouldn't it be nice if the OSes could auto-schedule processes of different priorities with each other?
So what? The pages mapped into each Windows process are not unique.
For example: I just rdesktoped (very handy tool if you use Windows systems sometimes) to a machine serving a few GUI sessions and other stuff. Total memory use of 611 K.
If you sum the memory usage for all processes (as reported by tasklist.exe) you'll get 2220 K.
Pages of code, and data, are shared to a very high degree -- especially if you start two identical processes. Looking at the delta of total memory usage on a Windows system is certainly not without flaws, but that would in this case probably give a more accurate number.
Slashdot Mirror
Not if that keeps the fan quiet until I run a 3 minute build in JavaCC, when it will clock up again. If I force it down, the same build will take 10 minutes. And, of course, if I check the clock speed in some software that's not designed to properly react to SpeedStep, I can get values like 209 MHz.
It's like the belief that a lot of free memory is a good thing. A lot of memory that doesn't have to be paged out is a good thing, but "free" memory is just as useful as idle cycles due to a high frequency -- it shows that you could do better in some way.
Like pclminion wrote, assigning responsibility here is a quite complicated thing. But, more importantly, there is not that much reason to assume that a small body is really part of some stable arrangement. Maybe we are saving that far-off solar system by moving an asteroid a little?
No, GNU/Linux is not Unix.
And Neodsys confirms this. They seem to be very sure of the position, the stretching is very small. But it will be visible to the naked eye!
(Used a <pre> tag and didn't preview, sorry...)
Date__(UT)__HR:MN delta deldot 1-way_LT 399_ins_LT 2029-Apr-13 21:50 0.0004284247 0.00152 0.003563 0.000000
These data are from the high-accuracy ephermis link at the jpl site right now. It's possibly using old data or doing bad rounding compared to the impact risk page, but I want you to have a look yourselves. In short, both the delta and 1-way-LT numbers here basically say the same thing: The distance in the nominal orbit will be slightly more than 64.000 kilometers, far closer than Luna, for example. In fact, it seems to be about the same height as the current Hubble Space Telescope orbit.
Once again, I just put in the numbers and this is what I got. I think this is closer than any number I saw before for the distance and to rule out a collision if it gets this close, I would imagine that they would be extremely sure of the orbit. If you add columns for the sigma for angle it freaks out and gives very high numbers, which I guess could indicate that the position is not that sure.
Ok, now build a conspiracy theory on this!
And that was already done before the 1 in 300 post was made. They even apologized for this taking unusually long, as some data seemed wrong. In addition, the dates are not mysteriously deleted, they simply are below 10^-10 now. There is no absolute cutoff, if they should list every possible impact it should include the possibility that every single observation is incorrect and that 2004 MN4 will actually be knocking on your door tomorrow morning, 8 AM. Do you want that listed, too?
I noticed this too ... looks like NASA discarded some inaccurate observations (--> smaller number of observations), and found some old photographs of 2004 MN4 in their archive (--> longer baseline) - they must have been searching their archives for existing older sightings as soon as the impact risk started to look real bad.
The strange thing is that they seemed to use just about all observations up to two days ago. They better be sure of having a positive identification back in those March shots... The fact that they have to eliminate this many to get it to match seems a bit strange.
I tracked back the observations to the version I had in cache in my laptop. Back when the last used observation by JPL was Dec 26.14032 and the probability was 0.022, JPL reported 169 observations used. http://cfa-www.harvard.edu/mpec/K04/K04Y64.html, MPEC 2004-Y64, also lists around 160 observations in total, ending on that date. Obviously, just about every observation was used until this calculation.
Anyway, if the identification on March 15 is reasonably correct, even a hundred missing observations from the last few days shouldn't do much of a difference, if randomly chosen (not chosen just to fit the identification in March). Most of the accuracy is from the position at a certain date, not from the added precision of more measurements at just about the same time.
Nope. There are only about 20 new ones in Y71. More importantly, Y71 had not been released yet when they posted that number of 169 observations used to calculate the impact risk. I fully understand that they can't possibly use the very latest data, but eliminating data from a previous prediction is a completely different matter.
(Y70 seems to have 243 observations in total...)
Regarding number 2, that's not really true. They have identified the object in pictures from March 2004. The thing is that by just confirming the old nominal orbit, which all along was on target to miss Earth by at least ten Earth radii, the probability of impact can go down significantly.
If you wonder, the distance between the nominal path and impact on Earth is Stretch LOV times Sigma LOV. The current predicted impats are far more off than before and it's only by the fact that the true path is hard to predict that they, too, are not eliminated.
All this said, what I really want to know is why a lot of observations have disappeared from the projections. It would be nice with some information on this, and maybe NEODyS confirming the new numbers. (They haven't performed any rerun as of yet.)
(Credit to magnuss for one of the links.) http://www.hohmanntransfer.com/news.htm mentions that the object was found in images from March 15th. I find this odd in no way in itself, it's quite natural that the determined orbit has been back-stepped to verify where the object was before its discovery in June, as any such data would improve the accuracy far more than more observations made today. Obviously, it seems they succeeded.
The raw data linked from that site has 243 observations in total. Maybe the newest JPL data is filtering to only use observations from certain telescopes, or they're aggressively filtering out "junk" data. I would welcome some kind of explanation like "ooops, a lot of people looked at another rock" or something along those lines. Another note is that the size estimation is up again to 430 meters instead of 390. Not a big change in the light (pun intended) of the fact that this is based on the measured intensity in the data, nothing else.
2: They have said all along that the most likely outcome was to eliminate this chance. Torino 4 only means that the current data is putting it down to a quite limited range giving a high probability. Now, the orbit hasn't changed very much, BUT, it's changed enough to almost rule out the possibility of the orbit actually reaching Earth. As the nominal orbit was never that close, this is not surprising. They've been quite clear on the fact that the most likely solution was not centered on Earth. The closest nominal approach does not equate the most likely impact, as the positions for different years are possible to determine with different accuracy.
The only good way to eliminate a lot of data was a longer data arc, and that was provided by backtracking the object to March. The whole point here is that we are good at estimating position in the sky, but that our abilities to determine the distance is far worse. Several observations a large amount of time apart makes it possible to triangulate the real position. As the object also moves during that time, it's not as simple as normal triangulation, but similar principles apply.
I, for one, welcome our "publish everything" astronomical overlords.
(That said, I would still be happy to know why the number of observations is down to 160.)
Posted in another thread: http://www.hohmanntransfer.com/news.htm.
You can also notice yourself in the page that the first listed observation is already in March this year. Obviously, the object was tracked back to an older photo. I can't explain the lowered number of observations, though. Eliminating that many as obvious measuring errors would be a bit surprising, if no special explanation is provided.
Interestingly enough, the first observation has been lowered to March, instead of June, and the total number of observations is down to 118 from around 170.
This seems to mean they identified this object in old shots from March and from that data could eliminate quite a lot. This is confirmed in your source. BUT, it also seems to mean that they in the process threw out 50 observations as faulty?! Some kind of later explanation of this lowered total number would surely be interesting. Was the wrong celestial body observed by some people? Or is the identification of the object in March more certain than a lot of more recent observations? Any insights?
Yeah, that's exactly why they took those extra months and implemented a lot of those security enhancements, big and small, into the codebase. That's why they let the main Windows development group handle the service pack, delaying Longhorn and the like, instead of just letting a smallar maintenance team include the necessary hotfixes and fix a few other blatant bugs.
Remember that many of these are protective measures. If I'm writing code that will only be called by trusted clients, I can know that there is a possible buffer overflow, but why should I care? The code calling me already has the appropriate permissions. OR, I can decide that the calling code could also be buggy and that I should add param checking. I can recompile everything with basic stack-protection in the compiler to detect overflows. The list goes on. This has protected them from quite a few bugs in SP2 the last few months, but that doesn't mean that those specific bugs were known during the development of SP2.
Shrinking the track size doesn't seem to be the way to make the machine larger to me.
Hm... I think you answered to the wrong post. I was just wondering if one could rule out some orbits, because they would have meant that a collision should already have taken place. I've already seen the cloud, and I suppose most of the uncertainty here comes from the unknown parameters of the asteroid right now. It's just as easy to back-step as forward-stepping and then it would be possible to check if at least a few of the possible orbits would have resulted in a previous collision. A few of the approaches in the page I linked to are almost as close as the one in 2029, if I'm able to interpret the distance numbers correctly.
http://newton.dm.unipi.it/cgi-bin/neodys/neoibo?ob jects:2004MN4;main lists previous close approaches, too.
IANAA, but it seems like my cross referencing idea with the fact that previous approaches didn't result in impact could be worth investigating. One thing I currently can't understand is why the listed "minimum possible distance" is a few magnitudes more than an Earth radius for the 2029 encounter. Maybe that's the mean trajectory fit with the current observations, but what's nominal distance, then?
One could even wonder if the minimum possible distance gets listed incorrectly if it's on the opposite side of the Earth compared to the nominal distance. (If the mean trajectory crosses it on one side and the one farthest away actually crosses the Earth on the other side.)
The most important point in all this -- will we be able to play Duke Nukem Forever while awaiting our Doom?
Good explanation.
What I started to wonder is if they make any attempts to backsteg from the current position. If we look at the list of possible impacts, it's obvious that there is a long series of at least somewhat probable ones in April starting in 2029. What one possibly could do for each and every possible orbit (or a Monte Carlo selection of them) is to determine if they would have already crossed Earth (or maybe the moon as we have to simulate that properly, too, anyway) at some not too distant point in time that has already passed. If that would be the case, then that orbit is obviously not the correct one, if the stepping method used for simulations is correct enough.
I doubt this could really be used to rule out the possibility of an impact, but it would be interesting to know when the last time was with a long series of more or less likely (like > 1e-8) impacts.
This doesn't have to apply to kernel stuff. A lot of Windows apps rely on for example the "common controls" API. It handles toolbars, tooltips, listviews and so on. Quite a lot of UI goodies. Most of those are implemented without any kernel side, they're normal user mode controls/"windows" with their own drawing.
Now to the point: This DLL was updated quite a few times with Internet Explorer 3, 4 and 5. The versions in Windows 98, 2000 and XP are/were directly related to the matching (sub-)version of Internet Explorer. If you wrote an app for Win-95 and wanted to use one of those common controls, the recommended redistribution scenario was redistributing IE.
If they simply ripped out anything that is officially part of the "IE codebase", it's completely true that quite a few apps would fail.
This is of course even more true of some of other APIs with a more apparent connection to Internet Explorer, like WinInet for interacting with HTTP/FTP without doing sockets yourself (and using the IE cache and other stuff) or employing the IE HTML/XML parsing and possibly rendering hosted in another application. I chose common controls because they're very frequently used, and some quite significant updates were introduced through IE. These updates are still there in "Win98 lite" and whatever you would do to a Windows system to rip out IE, but retain a reasonable level of compatibility. Just because it's part of the OS and a frequently used API doesn't mean it's kernel mode. And very little IE related code is *in the kernel*.
Now to the point: LoadImage is quite a low level function. Display drivers are allowed to use it on their own and modify its functionality. That makes it belong in kernel mode. Even if they moved back some more UI stuff from the kernel, stuff like this probably belongs there, if you buy the concept of placing display drivers in kernel mode at all.
Oh, I love this privacy concept. Then we'll see google ads adapt to our latest queries and you'll just be happy if they restrict that to Paris Hilton for p, too.
I'm fine with Google acquiring huge amounts of data, but with the wealth of possible info, I think I at least should be able to see a "clean" web, too. Sometimes I don't want to see only the search hits I've been likely to click on in the past. Giving me at least an option to see "unbiased" hits would be nice.
The real benefit of true multitasking is of course that you don't have to lock it down. The use of multitasking user mode processes would be quite limited if you only could use it to assign locked processor affinities. Likewise, the ideal situation here would be to let both OSes share both CPUs, with only maybe some additions in the idle loop and perharps an arbitrator driver in each OS. Strictly speaking, I guess an arbitrator would not be needed, but wouldn't it be nice if the OSes could auto-schedule processes of different priorities with each other?
So what? The pages mapped into each Windows process are not unique.
For example: I just rdesktoped (very handy tool if you use Windows systems sometimes) to a machine serving a few GUI sessions and other stuff. Total memory use of 611 K.
If you sum the memory usage for all processes (as reported by tasklist.exe) you'll get 2220 K.
Pages of code, and data, are shared to a very high degree -- especially if you start two identical processes. Looking at the delta of total memory usage on a Windows system is certainly not without flaws, but that would in this case probably give a more accurate number.
It's rather important to remember the difference between workset, used address space and real (delta) memory usage.