Stuff like Pu, when used as a source of heat on satellites for power, is encased in a capsule that is designed to survive reentry without burning up or cracking open. I work with a fellow that was part of the testing on those capsules. Artillery shells are more easily damaged than these capsules in such an environment.
I just checked the weather radar over the United States and found some interesting results. First, there were three of rapidly-disappearing streaks over the San Joaquin Valley, near Beale AFB, and near Reno, NV, laying parallel to the shuttle's path. Shortly after that, there were two simultaneous streaks north and south of Tuscon, AZ. Shortly thereafter there are also a lot of smaller, very intense echos in the area around Holloman AFB and El Paso, TX. Then a persistent cloud that of the time of this posting is drifting from between Lufkin and Longview, TX toward Alexandria, LA.
If these streaks and point echoes are what I believe them to be, that is, parts of Columbia, she was in trouble before she made landfall in California or very shortly thereafter. The images we've been seeing on TV are several minutes after the first possible indications of trouble and show Columbia badly damaged.
May God bless all who are affected by this tragedy.
If the shoe were on the other foot
on
Ask Kevin Mitnick
·
· Score: 1
and you were the prosecution in your case, how would you have handled it, given that (1) you were to be made an example of and (2) you wouldn't have changed your defense strategy?
I would have agreed with you before the advent of the 9700 series by ATI and the broken product cycle because of the lateness of the FX. Nvidia's off their usual product cycle by about 6 months and no longer has the luxuries of (1) being the current performance leader and (2) having a vastly superior solution in silicon and drivers. ATI's drivers are much, much better than I expected (I'm a Rage Fury owner who has been enraged and infuriated at ATI's lack of drivers more times than I care to count). Nvidia must be in shock over the 9700 series. I don't believe that Nvidia has enough overhead in the FX to play their usual driver games.
My CPA does, and they're fairly reputable. They don't recommend that you upgrade QB or QB Pro; they haven't upgraded theirs since 2000. Convenient, though. Just drop your DB onto media, hand it and a check over, and all your financial worries disappear!
Guess it's time to stir the pot with my accountant and see what they recommend next.
When I worked at Oak Ridge National Laboratory in the late '80s, we had a stand of trees (poplars, I believe) between the main road through the heart of the facility and a research reactor building. I used to walk right by these trees every day to get to the cafeteria. One day, the sidewalk on that side of the road was blocked off, and several men, wearing bunny suits and wielding chainsaws, were hard at work felling the trees. By the next day, even the stumps were gone.
We've had our share of radioactive frogs too, some with some, shall we say, unique anatomy. Once, on that same main road, one of these unfortunate amphibians wandered underneath the tread of one of the facility's vehicles. Again, we see the bunny suits, this time with sprayers full of this black, sticky foam. Down the road every so often, you'd see a bunnyman either spraying or scraping an already-encapsulated piece of frog from the road where the contaminated tire had deposited it.
These modems are frequency hoppers and have multiple scan patterns. They've also got onboard spectrum display capability, so you can find the clearer bands.
They also have a rudimentary form of encryption, not even at the WAP level, but quasi-useful nonetheless.
Don't just look at the "2%". You've got to evaluate the total risk of the situation. If 2% of the time a particular behavior could get you killed is a lot different than 2% where milk comes out your nose.
Risk assessment is the name of the game. I'm glad to see that one of the head spooks wants to include us in the decision making.
I've seen a maddening mix of response times to bugs I've filed in bugzilla, from a matter of hours to a matter of months without the bug even being assigned to a responsible party. I guess it depends upon several factors, such as available time, expertise, level of interface with the package maintainers, etc. The best response times are from those packages that are Red Hat in origin. I suspect/hope that non-RH package bugs are passed along to the responsible parties.
First off, understand that we're reading quotes from John Pike. A little Googling will clearly reveal his politics to be somewhat at odds with the current administration. However, for Pike to admit that these solid-state lasers are moving into the "engineering" phase (second phase of weapons development - research, engineering, and production) is quite revealing. For him to acknowledge publically any high-tech weaponry as making significant advances is, to me, quite shocking.
Also understand that the arms race, which has existed throughout human history, is exactly that: a contest to see who can come up with the most effective weaponry the quickest. In this era of asymmetric warfare, nukes are useless. We've got a rapidly growing asymmetrical threat against which our current best practices and tools are less than ideal. New weapons and tactics are needed to counter such a threat.
As to the open market availability of weapons for terrorists, sure, there's scuds (pun intended) available. As long as there are countries such as Russia and China producing cheap, reliable low-tech weapons, and other countries willing to act as brokers for these groups, there will be a channel. This, however, is a poor argument against transformation of our armed forces to respond to such threats, including development of new weapons that give our military another advantage. And, given the technical sophistication of the level of some of these new weapons systems being developed, it'll be years before opposing forces can produce clones in sufficient quantity to be worrisome. Case in point: look how long it's taken many countries to become nuclear capable. That technology is nearly 60 years old! Lasers have been around since 1954 (microwave, 1960 for an optical laser) and we still haven't been able to weaponize them to any significant degree. And much of laser theory and practice is in the open press, unlike many aspects of the nuclear weapons programs.
The big problems with the Cyrix chips are (1) poor FPU and (2) no out-of-order execution in the core. AFAIK, no OOE on these makes them stand alone in the current x86 marketplace. Alone, and in the dark.
We've got some of these at 550MHz in the Spacewalker SV25s we put out in meteorological monitoring stations across the US. They're reliable, and in the desert southwest, it's a good thing to be low heat generating!
According to a recent.plan of John's, he's already decided to demo Doom III on the Radeon platform. He decided this a few short weeks after doting on the Nvidia stuff, too.
It sounds to me that ATI has some serious card here. Now if they can overcome their pitiful history of sorry drivers...
"The Weather Model, MM5 decends from the early 1970's (Pre FORTRAN 77). It's in Fortran. It's large. It would take a hell of a lot of effort to rewrite it, and nobody is going to do it."
In fact, there is a massive effort underway to do essentially that. Since MM5 and RAMS are so archaic and lack certain critical features for the newer models, a newer model called WRF is being created as a potential replacement for these two older systems. And FORTRAN is the expected language of choice even for this newer atmospheric model.
Type Enforcement is used in SCC's Sidewinder firewall product, IMHO the most secure firewall going bar none. In plainer language than the above, it internally segments the parts of the OS from each other in a way that precludes their access/interference to each other. There is a "root", but it's restricted in its ability to manipulate system services. There are "mini-roots" so to speak that administer the various services such as ftp, www, etc. Each network interface runs in a separate domain, with separate firewall rules for each.
The analogy is that Sidewinder is compartmentalized like a submarine. Breech the hull in one location, and the internal bulkheads contain the damage to just that section. So, for example, if there were a breach or other weakness in the ftp service, this would not automatically lead to a breach in web serving or to any other service on the box.
In practice, this is one tough beast. For a two and a half year period when I managed one of these, we were the only Department of (fill in the blank) site in the area to not be penetrated, including a national laboratory with 25x our budget for computer security. Sidewinder turned away thousands of attacks. The only downside is that it took us about $35K to get the product and the requisite hardware and the basic training necessary to set it up.
isn't the altimeters or weather gear, but the IFF (identify friend or foe) transmitter. Properly coded (which is the hard part), this could prevent friendly forces from being able to automatically target an incoming aircraft from a hostile force, as well as providing a way for a hostile aircraft to approach friendly forces.
You're missing the point of using OSS in this arena. The issue here is not one of open sourced ATC software, or typical OSS developers creating ATC software (which isn't necessarily a bad thing, judging by the quality of many OSS pieces). It's one of the tools of the trade being OSS.
The risk of any glitches that may arise as the result of using OSS as the core building blocks of any mission-critical/life-encapsulating project such as ATC may actually be less than the closed source arena. We've got hundreds of examples where errors in OSS are fixed correctly in a more timely manner than many of their closed source counterparts.
As to the legal liabilities, those rest squarely on the shoulders of the developers of the ATC code, not on the tool creators. The ATC developers, were they to find a heretofore unseen bug in some OSS tool, are in a position to fix it and/or report it to the package maintainers. This would help avoid those nasty little workarounds that lead to nasty code that much harder to maintain/certify.
Do you have a big RS/6000 or two sitting around, or a sizeable Linux cluster(s) connected via fiber to the National Climatic Data Center in Silver Spring, MD, that you can crunch a few dozen gigabytes of data a couple of times a day to help out with?
Speaking as someone who builds clusters to run mesoscale atmospheric models, the amount of data that's required to be passed back and forth between the compute nodes of a cluster requires gigabit bandwidth to keep decent processors happy. I don't see how a WAN-based distributed computing project without massive bandwidth and nearly isochronous data transmissions are going to be of any use in producing a working forecast. Most atmospheric models I've seen require frequent communication between the nodes to keep the processors busy. In an average run for an area the size of a couple of average states for a 36 hour forecast, the traffic on the network in a five node cluster approaches a terabyte.
Slashdot Mirror
Stuff like Pu, when used as a source of heat on satellites for power, is encased in a capsule that is designed to survive reentry without burning up or cracking open. I work with a fellow that was part of the testing on those capsules. Artillery shells are more easily damaged than these capsules in such an environment.
I just checked the weather radar over the United States and found some interesting results. First, there were three of rapidly-disappearing streaks over the San Joaquin Valley, near Beale AFB, and near Reno, NV, laying parallel to the shuttle's path. Shortly after that, there were two simultaneous streaks north and south of Tuscon, AZ. Shortly thereafter there are also a lot of smaller, very intense echos in the area around Holloman AFB and El Paso, TX. Then a persistent cloud that of the time of this posting is drifting from between Lufkin and Longview, TX toward Alexandria, LA.
If these streaks and point echoes are what I believe them to be, that is, parts of Columbia, she was in trouble before she made landfall in California or very shortly thereafter. The images we've been seeing on TV are several minutes after the first possible indications of trouble and show Columbia badly damaged.
May God bless all who are affected by this tragedy.
and you were the prosecution in your case, how would you have handled it, given that (1) you were to be made an example of and (2) you wouldn't have changed your defense strategy?
I would have agreed with you before the advent of the 9700 series by ATI and the broken product cycle because of the lateness of the FX. Nvidia's off their usual product cycle by about 6 months and no longer has the luxuries of (1) being the current performance leader and (2) having a vastly superior solution in silicon and drivers. ATI's drivers are much, much better than I expected (I'm a Rage Fury owner who has been enraged and infuriated at ATI's lack of drivers more times than I care to count). Nvidia must be in shock over the 9700 series. I don't believe that Nvidia has enough overhead in the FX to play their usual driver games.
My CPA does, and they're fairly reputable. They don't recommend that you upgrade QB or QB Pro; they haven't upgraded theirs since 2000. Convenient, though. Just drop your DB onto media, hand it and a check over, and all your financial worries disappear!
Guess it's time to stir the pot with my accountant and see what they recommend next.
When I worked at Oak Ridge National Laboratory in the late '80s, we had a stand of trees (poplars, I believe) between the main road through the heart of the facility and a research reactor building. I used to walk right by these trees every day to get to the cafeteria. One day, the sidewalk on that side of the road was blocked off, and several men, wearing bunny suits and wielding chainsaws, were hard at work felling the trees. By the next day, even the stumps were gone.
We've had our share of radioactive frogs too, some with some, shall we say, unique anatomy. Once, on that same main road, one of these unfortunate amphibians wandered underneath the tread of one of the facility's vehicles. Again, we see the bunny suits, this time with sprayers full of this black, sticky foam. Down the road every so often, you'd see a bunnyman either spraying or scraping an already-encapsulated piece of frog from the road where the contaminated tire had deposited it.
My wife! She forgets NOTHING!
These modems are frequency hoppers and have multiple scan patterns. They've also got onboard spectrum display capability, so you can find the clearer bands.
They also have a rudimentary form of encryption, not even at the WAP level, but quasi-useful nonetheless.
Don't just look at the "2%". You've got to evaluate the total risk of the situation. If 2% of the time a particular behavior could get you killed is a lot different than 2% where milk comes out your nose.
Risk assessment is the name of the game. I'm glad to see that one of the head spooks wants to include us in the decision making.
I've seen a maddening mix of response times to bugs I've filed in bugzilla, from a matter of hours to a matter of months without the bug even being assigned to a responsible party. I guess it depends upon several factors, such as available time, expertise, level of interface with the package maintainers, etc. The best response times are from those packages that are Red Hat in origin. I suspect/hope that non-RH package bugs are passed along to the responsible parties.
Great, just what I need. Incineration by H2 followed by a quick rendering of what's left of me into soap.
At least the wreck scene will be easier to clean!
First off, understand that we're reading quotes from John Pike. A little Googling will clearly reveal his politics to be somewhat at odds with the current administration. However, for Pike to admit that these solid-state lasers are moving
into the "engineering" phase (second phase of weapons development - research, engineering, and production) is quite revealing. For him to acknowledge publically any high-tech weaponry as making significant advances is, to me, quite shocking.
Also understand that the arms race, which has existed throughout human history, is exactly that: a contest to see who can come up with the most effective weaponry the quickest. In this era of asymmetric warfare, nukes are useless. We've got a rapidly growing asymmetrical threat against which our current best practices and tools are less than ideal. New weapons and tactics are needed to counter such a threat.
As to the open market availability of weapons for terrorists, sure, there's scuds (pun intended) available. As long as there are countries such as Russia and China producing cheap, reliable low-tech weapons, and other countries willing to act as brokers for these groups, there will be a channel. This, however, is a poor argument against transformation of our armed forces to respond to such threats, including development of new weapons that give our military another advantage. And, given the technical sophistication of the level of some of these new weapons systems being developed, it'll be years before opposing forces can produce clones in sufficient quantity to be worrisome. Case in point: look how long it's taken many countries to become nuclear capable. That technology is nearly 60 years old! Lasers have been around since 1954 (microwave, 1960 for an optical laser) and we still haven't been able to weaponize them to any significant degree. And much of laser theory and practice is in the open press, unlike many aspects of the nuclear weapons programs.
(4) Green releases patent under GPL.
Please tell me that you don't still have classified info available through telnet. Please tell me you meant ssh or VPN. Wireless or not...
The big problems with the Cyrix chips are (1) poor FPU and (2) no out-of-order execution in the core. AFAIK, no OOE on these makes them stand alone in the current x86 marketplace. Alone, and in the dark.
We've got some of these at 550MHz in the Spacewalker SV25s we put out in meteorological monitoring stations across the US. They're reliable, and in the desert southwest, it's a good thing to be low heat generating!
Since it's an Intel processor, how could you tell that the problem was radiation-induced? ;-)
According to a recent .plan of John's, he's already decided to demo Doom III on the Radeon platform. He decided this a few short weeks after doting on the Nvidia stuff, too.
It sounds to me that ATI has some serious card here. Now if they can overcome their pitiful history of sorry drivers...
"The Weather Model, MM5 decends from the early 1970's (Pre FORTRAN 77). It's in Fortran. It's large. It would take a hell of a lot of effort to rewrite it, and nobody is going to do it."
In fact, there is a massive effort underway to do essentially that. Since MM5 and RAMS are so archaic and lack certain critical features for the newer models, a newer model called WRF is being created as a potential replacement for these two older systems. And FORTRAN is the expected language of choice even for this newer atmospheric model.
I've used Gallery for creations of lesser importance. It seems to have the features you'd want/need to organize a family album.
The Parhelia is Matrox's first attempt at a competitive 3D card. As the process shrinks, the speeds will go up. And the drivers will mature over time.
How much better it'll get is a valid speculative point. Did they hire any of the old 3Dfx crew?
Type Enforcement is used in SCC's Sidewinder firewall product, IMHO the most secure firewall going bar none. In plainer language than the above, it internally segments the parts of the OS from each other in a way that precludes their access/interference to each other. There is a "root", but it's restricted in its ability to manipulate system services. There are "mini-roots" so to speak that administer the various services such as ftp, www, etc. Each network interface runs in a separate domain, with separate firewall rules for each.
The analogy is that Sidewinder is compartmentalized like a submarine. Breech the hull in one location, and the internal bulkheads contain the damage to just that section. So, for example, if there were a breach or other weakness in the ftp service, this would not automatically lead to a breach in web serving or to any other service on the box.
In practice, this is one tough beast. For a two and a half year period when I managed one of these, we were the only Department of (fill in the blank) site in the area to not be penetrated, including a national laboratory with 25x our budget for computer security. Sidewinder turned away thousands of attacks. The only downside is that it took us about $35K to get the product and the requisite hardware and the basic training necessary to set it up.
isn't the altimeters or weather gear, but the IFF (identify friend or foe) transmitter. Properly coded (which is the hard part), this could prevent friendly forces from being able to automatically target an incoming aircraft from a hostile force, as well as providing a way for a hostile aircraft to approach friendly forces.
You're missing the point of using OSS in this arena. The issue here is not one of open sourced ATC software, or typical OSS developers creating ATC software (which isn't necessarily a bad thing, judging by the quality of many OSS pieces). It's one of the tools of the trade being OSS.
The risk of any glitches that may arise as the result of using OSS as the core building blocks of any mission-critical/life-encapsulating project such as ATC may actually be less than the closed source arena. We've got hundreds of examples where errors in OSS are fixed correctly in a more timely manner than many of their closed source counterparts.
As to the legal liabilities, those rest squarely on the shoulders of the developers of the ATC code, not on the tool creators. The ATC developers, were they to find a heretofore unseen bug in some OSS tool, are in a position to fix it and/or report it to the package maintainers. This would help avoid those nasty little workarounds that lead to nasty code that much harder to maintain/certify.
have with running a microphone and/or a camera?
You'd think M$ had something to do with this...
Do you have a big RS/6000 or two sitting around, or a sizeable Linux cluster(s) connected via fiber to the National Climatic Data Center in Silver Spring, MD, that you can crunch a few dozen gigabytes of data a couple of times a day to help out with?
Speaking as someone who builds clusters to run mesoscale atmospheric models, the amount of data that's required to be passed back and forth between the compute nodes of a cluster requires gigabit bandwidth to keep decent processors happy. I don't see how a WAN-based distributed computing project without massive bandwidth and nearly isochronous data transmissions are going to be of any use in producing a working forecast. Most atmospheric models I've seen require frequent communication between the nodes to keep the processors busy. In an average run for an area the size of a couple of average states for a 36 hour forecast, the traffic on the network in a five node cluster approaches a terabyte.