The main impediment to the strategic force upgrade is a process called "nuclear surety". It's what you think it is: a very comprehensive testing process to ensure that the system can't be accidentally triggered (missiles launched.) Surety is as comprehensive as it can be conceived, which means that no process is ever perfect, but this one has a lot of history behind it such that the probability of an accidental or forced launch is very, very low.
Surety costs significant money, about 65-80% of the cost of upgrading the system. Add to that the general cautiousness of changing the system in any way, and you get the "Holy Cow! You're still using 1960's technology?"
It's not a question of software engineering or identifying a failing project, it's the Federal Acquisition Rules or FAR. Basically, once a project starts to fail, processes start taking over, on top of the processes that were running the project, with processes to replan the milestones, with processes that define processes that augment processes to assist processes that eventually result in executing a process that produces software.
Sure, it's easy to play Monday morning quarterback on how to fix the healthcare.gov website. Then reality sets in when the savant garde in Silicon Valley actually have to work according to the FAR's framework and contracting processes.
Yes, we do need people who can articulate an idea, even if they use passive voice or "run on" sentences. Every so often, the so-called "clerical" or "average" jobs require the ability to actually form and communicate an idea.
I once had a customer nicknamed "Five Slide Jan". People supporting her thought that her requirement that briefings be five slides in length was onerous, but she had a point: Make your point in five slides. That forces one to be succinct and on target. Unfortunately, there were always the additional 20 or so backup charts, but, still, it changed the organization to focus on the message being delivered.
No, the likelihood of getting bricked is really small, although the likelihood of misaligned or damaged equipment failure is much greater.
"Bricking" is really small because there is always a known, good image that preceded the update. In the case of a failure, these spacecraft go into a "safe hold" mode (there are actually several different safe hold levels). The lowest safe hold level ensures that the operator always has access to a low-level monitor. This monitor allows the operator to select which image is booted, so there's always a way to get back to a known, good state.
The operator can really brick the vehicle if instruments and antennae get misaligned, but that's a cascade failure (multiple things have to go wrong) that could be fixed by a higher safe hold level.
Is it me, or do the vast majority of environmental activists seem to be stuck in an Armageddon scenario infinite loop? To be sure, nuclear energy presents issues, like everything else, but I'm not sure that engaging in maximalist interpretations of all events is helpful.
Consider the United States Navy's nuclear program. Other than the Thresher incident, the USN's nuclear program has had remarkably few incidents or major mishaps (caveat: these reactors are designed to generate power, not weapons material.)
When I install a Linux distro, I generally just adapt to the default desktop environment, although my preference tends to be KDE.
My largest problem with GNOME is not its modularity or architecture, but the shear bulk of repitition of doing a single task. GNOME has become its own worst enemy and a victim of its own success -- open source (check!), lots of options (check! check!), even more options because someone forked (check! check! check! check! check!)...
My customers ask this question all of the time -- who's better? The answer isn't which is better, but which CAP properties do you want. You want consistency -- go with SQL and get the data model right to optimize performance. You have situations where availability and partitionability are important -- let's develop a matrix of noSQL solutions based on what data you're going to ingest. XML, you say? mongodb is probably the best fit? Trawling over metadata? Key-value stores are better. Etc. Etc.
The one place where there is a substantial difference is geospatial indexing -- noSQL databases appear to do this a lot better than the SQL databases. YMMV, though.
The software wasn't written by the USG, it was written under contract to be delivered to the USG. Subtle difference, but no, the software is not in the public domain because it wasn't written by the USG. See the "Software System Acquisition 101" post below...
Joe Taxpayer doesn't get access to the GWA software or source code as the result of how the FAR rights and data rights work. Moreover, Bo Zhang committed theft from his employer, not Joe Taxpayer.
Software is acquired from a contractor, so the Federal Acquisition Rules and various tailored versions, e.g., DFARS, apply. It is not developed by the USG, unless specifically talking about something that a USG civilian employee (__not__ a contractor) authored.
The government purchases systems, writes contracts to acquire systems. Source code is considered data -- so the applicable FARS and DFARS are technical rights to data. Data rights are negotiated separately from software (system) rights and source code is delivered as part of a separate contract deliverable requirement list (CDRL) item, if the source code is even delivered. In 99.999% of contracts I've seen, source code is never delivered and when it is delivered, the most restrictive data rights are applied.
A lot, though, is changing through the DoD's Open Architecture initiatives (formerly the Navy's Open Architecture Program). Source code is expected to be delivered as a CDRL item with unrestricted rights as the default. And it turns out that the GPL is a version of a unrestricted license (I know because I spent a week with the SFLC and a Navy IP attorney collecting the information), so there's some hope on the horizon.
Bad news for those of you hoping to get a major weapons system's source code: The USG is the owner of the conveyed executable, so only the USG gets the source code.
Software is acquired from a contractor, so the Federal Acquisition Rules and various tailored versions, e.g., DFARS, apply.
The government purchases systems. Source code is considered data -- so the applicable FARS and DFARS are technical rights to data. Data rights are negotiated separately from software (system) rights and source code is delivered as part of a separate contract deliverable requirement list (CDRL) item, if the source code is even delivered. In 99.999% of contracts I've seen, source code is never delivered and when it is delivered, the most restrictive data rights are applied.
A lot, though, is changing through the DoD's Open Architecture initiatives (formerly the Navy's Open Architecture Program). Source code is expected to be delivered as a CDRL item with unrestricted rights as the default. And it turns out that the GPL is a version of a unrestricted license (I know because I spent a week with the SFLC and a Navy IP attorney collecting the information), so there's some hope on the horizon.
Bad news for those of you hoping to get a major weapons system's source code: The USG is the owner of the conveyed executable, so only the USG gets the source code.
Even if the sub reaches crush depth, the reactor itself is very heavily protected. Note that I'm not saying that exposing the reactor core to seawater is impossible, but given all of the safeguards, it's highly unlikely.
Sure, uranium could leach into the ocean. But at what concentration? And at what expected half life?
Uranium has a long half life, so the risk is tolerable. Estimates have been that more uranium is in sea water than will ever be mined. Good reason for some people to stay put of the water, More space for the rest of us to play, I guess.
I'm always surprised at the number of people who think that long lived isotopes are more dangerous than short lived ones.
Clearly you don't understand Ayn Rand or you only understand the usual dizinformatsia. She never said that one shouldn't care or be empathetic to others. What she said was that one needs to take care of oneself first before helping others. Living in a society or culture where others' needs come before mine (altruism) means that I must cede my self determination to the whim of the collective.
As much as Steve Jobs wanted to be countercultural, without the uniquely American version of self determination, he would have never achieved the success that is Apple.
Heck, you can find any number of Ayn Rand fans who also do a lot of philanthropic work -- but you have to have the personal means to be philanthropic first.
Disclaimer: I'm an Ayn Rand fan and Freemason (yes, for you objectivists, that's a contradiction -- but where do you think the ideas that became the United States came from?)
If you live in California, it's at least five years before you can get past most environmental impact statements, convince local governments that you're really going to benefit them economically, get appropriate blessing from various air quality mangement districts, and break ground. The regulations are very imposing. Add to that the new CO_2 regulations in CA, and one can get into a real nightmare.
Consider solar energy plants in the high desert -- lots of land, lots of sun, lots of panels. No way to get the energy back to the consumer because as soon as a shovel hit the dirt, environmental groups sued over the transport lines that would have to cross the desert back to population.
Although I'm not entirelt convinced that labor costs are small in comparison to total product cost. Lee Ioccoca pointed out that even in the 90s, Blue Cross became Chrysler's #2 supplier. It's those indirect costs of labor (approx. 2.5x salary) that eventually make US manufacturing unappealing.
Have you looked at ways to implement load linked, store conditional (LL/SC)? Even though you'll need a layer for the various types of CAS implementations, you might be better off writing the recovery code when you find that you're out of sync. Just a thought...
While it's probably too late to sign up for the general-purpose GPU tutorial at Supercomputing '06, there may still be time to get to the "General-Purpose GPU Computing: Practice and Experience" workshop (assuming you're going to Supercomputing to begin with.) Workshop's web page is http://www.gpgpu.org/sc2006/workshop/
The workshop itself has turned into a kind of "GPU and multi-core" forum, with lots of great speakers. NVIDIA's Ian Buck and ATI's Mark Segal will both be speaking to the Wired article's material. And IBM and Los Alamos will be talking about Cell and Roadrunner, among other things. </shameless plug>
So, I wonder what Dinesh Manocha will be talking about at the workshop... Hmmm....
In another Queue article, IBM researchers published the difficulties they encountered while trying to determine "context". Good example is someone using PowerPoint. Heuristic was that if someone was talking and PPT was active, they were presenting to a group. Except for the fact that someone might be talking with PPT active but merely rehearsing. Or one person could be reading through slides while someone else was talking, but that didn't necessarily mean that the person was reading and could be interrupted.
Really, what they were trying to do was not guess "context", but intuit (divine?) through the minimal use of relevant variables what the user's activity was. Context may be a certain number of instantiated variables or attributes that semantically determine an action, but getting those variables right without overwhelming the variable space is a daunting problem.
Readback from graphics memory is becoming more of an issue as GPUs are being used for general-purpose computing, e.g., Havok's GPU-basedphysics module that computes game physics. But, if all you're doing is rendering, then, you're right, it's not an issue.
Technically, though, if game physics is being computed, the dev should be using the SPEs/SPUs.
Slashdot Mirror
The main impediment to the strategic force upgrade is a process called "nuclear surety". It's what you think it is: a very comprehensive testing process to ensure that the system can't be accidentally triggered (missiles launched.) Surety is as comprehensive as it can be conceived, which means that no process is ever perfect, but this one has a lot of history behind it such that the probability of an accidental or forced launch is very, very low.
Surety costs significant money, about 65-80% of the cost of upgrading the system. Add to that the general cautiousness of changing the system in any way, and you get the "Holy Cow! You're still using 1960's technology?"
It's not a question of software engineering or identifying a failing project, it's the Federal Acquisition Rules or FAR. Basically, once a project starts to fail, processes start taking over, on top of the processes that were running the project, with processes to replan the milestones, with processes that define processes that augment processes to assist processes that eventually result in executing a process that produces software.
Sure, it's easy to play Monday morning quarterback on how to fix the healthcare.gov website. Then reality sets in when the savant garde in Silicon Valley actually have to work according to the FAR's framework and contracting processes.
For once!
Yes, we do need people who can articulate an idea, even if they use passive voice or "run on" sentences. Every so often, the so-called "clerical" or "average" jobs require the ability to actually form and communicate an idea.
I once had a customer nicknamed "Five Slide Jan". People supporting her thought that her requirement that briefings be five slides in length was onerous, but she had a point: Make your point in five slides. That forces one to be succinct and on target. Unfortunately, there were always the additional 20 or so backup charts, but, still, it changed the organization to focus on the message being delivered.
Gravity slingshots and curvature. It's very ineffecient to travel in a straight line from Earth to Mars.
No, the likelihood of getting bricked is really small, although the likelihood of misaligned or damaged equipment failure is much greater.
"Bricking" is really small because there is always a known, good image that preceded the update. In the case of a failure, these spacecraft go into a "safe hold" mode (there are actually several different safe hold levels). The lowest safe hold level ensures that the operator always has access to a low-level monitor. This monitor allows the operator to select which image is booted, so there's always a way to get back to a known, good state.
The operator can really brick the vehicle if instruments and antennae get misaligned, but that's a cascade failure (multiple things have to go wrong) that could be fixed by a higher safe hold level.
There's a lot of redundancy on these vehicles.
Is it me, or do the vast majority of environmental activists seem to be stuck in an Armageddon scenario infinite loop? To be sure, nuclear energy presents issues, like everything else, but I'm not sure that engaging in maximalist interpretations of all events is helpful.
Consider the United States Navy's nuclear program. Other than the Thresher incident, the USN's nuclear program has had remarkably few incidents or major mishaps (caveat: these reactors are designed to generate power, not weapons material.)
When I install a Linux distro, I generally just adapt to the default desktop environment, although my preference tends to be KDE.
My largest problem with GNOME is not its modularity or architecture, but the shear bulk of repitition of doing a single task. GNOME has become its own worst enemy and a victim of its own success -- open source (check!), lots of options (check! check!), even more options because someone forked (check! check! check! check! check!)...
Glass-Steagall was repealed at the end of the Clinton administration. It's effects were felt during the Bush-43 administration.
My customers ask this question all of the time -- who's better? The answer isn't which is better, but which CAP properties do you want. You want consistency -- go with SQL and get the data model right to optimize performance. You have situations where availability and partitionability are important -- let's develop a matrix of noSQL solutions based on what data you're going to ingest. XML, you say? mongodb is probably the best fit? Trawling over metadata? Key-value stores are better. Etc. Etc.
The one place where there is a substantial difference is geospatial indexing -- noSQL databases appear to do this a lot better than the SQL databases. YMMV, though.
The software wasn't written by the USG, it was written under contract to be delivered to the USG. Subtle difference, but no, the software is not in the public domain because it wasn't written by the USG. See the "Software System Acquisition 101" post below...
Joe Taxpayer doesn't get access to the GWA software or source code as the result of how the FAR rights and data rights work. Moreover, Bo Zhang committed theft from his employer, not Joe Taxpayer.
Software is acquired from a contractor, so the Federal Acquisition Rules and various tailored versions, e.g., DFARS, apply. It is not developed by the USG, unless specifically talking about something that a USG civilian employee (__not__ a contractor) authored.
The government purchases systems, writes contracts to acquire systems. Source code is considered data -- so the applicable FARS and DFARS are technical rights to data. Data rights are negotiated separately from software (system) rights and source code is delivered as part of a separate contract deliverable requirement list (CDRL) item, if the source code is even delivered. In 99.999% of contracts I've seen, source code is never delivered and when it is delivered, the most restrictive data rights are applied.
A lot, though, is changing through the DoD's Open Architecture initiatives (formerly the Navy's Open Architecture Program). Source code is expected to be delivered as a CDRL item with unrestricted rights as the default. And it turns out that the GPL is a version of a unrestricted license (I know because I spent a week with the SFLC and a Navy IP attorney collecting the information), so there's some hope on the horizon.
Bad news for those of you hoping to get a major weapons system's source code: The USG is the owner of the conveyed executable, so only the USG gets the source code.
Software is acquired from a contractor, so the Federal Acquisition Rules and various tailored versions, e.g., DFARS, apply.
The government purchases systems. Source code is considered data -- so the applicable FARS and DFARS are technical rights to data. Data rights are negotiated separately from software (system) rights and source code is delivered as part of a separate contract deliverable requirement list (CDRL) item, if the source code is even delivered. In 99.999% of contracts I've seen, source code is never delivered and when it is delivered, the most restrictive data rights are applied.
A lot, though, is changing through the DoD's Open Architecture initiatives (formerly the Navy's Open Architecture Program). Source code is expected to be delivered as a CDRL item with unrestricted rights as the default. And it turns out that the GPL is a version of a unrestricted license (I know because I spent a week with the SFLC and a Navy IP attorney collecting the information), so there's some hope on the horizon.
Bad news for those of you hoping to get a major weapons system's source code: The USG is the owner of the conveyed executable, so only the USG gets the source code.
Even if the sub reaches crush depth, the reactor itself is very heavily protected. Note that I'm not saying that exposing the reactor core to seawater is impossible, but given all of the safeguards, it's highly unlikely.
Closed loop system. Never exposed to outside water sources.
Sure, uranium could leach into the ocean. But at what concentration? And at what expected half life?
Uranium has a long half life, so the risk is tolerable. Estimates have been that more uranium is in sea water than will ever be mined. Good reason for some people to stay put of the water, More space for the rest of us to play, I guess.
I'm always surprised at the number of people who think that long lived isotopes are more dangerous than short lived ones.
Clearly you don't understand Ayn Rand or you only understand the usual dizinformatsia. She never said that one shouldn't care or be empathetic to others. What she said was that one needs to take care of oneself first before helping others. Living in a society or culture where others' needs come before mine (altruism) means that I must cede my self determination to the whim of the collective.
As much as Steve Jobs wanted to be countercultural, without the uniquely American version of self determination, he would have never achieved the success that is Apple.
Heck, you can find any number of Ayn Rand fans who also do a lot of philanthropic work -- but you have to have the personal means to be philanthropic first.
Disclaimer: I'm an Ayn Rand fan and Freemason (yes, for you objectivists, that's a contradiction -- but where do you think the ideas that became the United States came from?)
If you live in California, it's at least five years before you can get past most environmental impact statements, convince local governments that you're really going to benefit them economically, get appropriate blessing from various air quality mangement districts, and break ground. The regulations are very imposing. Add to that the new CO_2 regulations in CA, and one can get into a real nightmare.
Consider solar energy plants in the high desert -- lots of land, lots of sun, lots of panels. No way to get the energy back to the consumer because as soon as a shovel hit the dirt, environmental groups sued over the transport lines that would have to cross the desert back to population.
Although I'm not entirelt convinced that labor costs are small in comparison to total product cost. Lee Ioccoca pointed out that even in the 90s, Blue Cross became Chrysler's #2 supplier. It's those indirect costs of labor (approx. 2.5x salary) that eventually make US manufacturing unappealing.
Have you looked at ways to implement load linked, store conditional (LL/SC)? Even though you'll need a layer for the various types of CAS implementations, you might be better off writing the recovery code when you find that you're out of sync. Just a thought...
Google "Dominik Goeddeke" and read his GPGPU tutorial. It's excellent, as far as tutorials go, and helped me bootstrap.
Ok, ok, here's the link...
While it's probably too late to sign up for the general-purpose GPU tutorial at Supercomputing '06, there may still be time to get to the "General-Purpose GPU Computing: Practice and Experience" workshop (assuming you're going to Supercomputing to begin with.) Workshop's web page is http://www.gpgpu.org/sc2006/workshop/
The workshop itself has turned into a kind of "GPU and multi-core" forum, with lots of great speakers. NVIDIA's Ian Buck and ATI's Mark Segal will both be speaking to the Wired article's material. And IBM and Los Alamos will be talking about Cell and Roadrunner, among other things.
</shameless plug>
So, I wonder what Dinesh Manocha will be talking about at the workshop... Hmmm....
In another Queue article, IBM researchers published the difficulties they encountered while trying to determine "context". Good example is someone using PowerPoint. Heuristic was that if someone was talking and PPT was active, they were presenting to a group. Except for the fact that someone might be talking with PPT active but merely rehearsing. Or one person could be reading through slides while someone else was talking, but that didn't necessarily mean that the person was reading and could be interrupted.
Really, what they were trying to do was not guess "context", but intuit (divine?) through the minimal use of relevant variables what the user's activity was. Context may be a certain number of instantiated variables or attributes that semantically determine an action, but getting those variables right without overwhelming the variable space is a daunting problem.
Readback from graphics memory is becoming more of an issue as GPUs are being used for general-purpose computing, e.g., Havok's GPU-basedphysics module that computes game physics. But, if all you're doing is rendering, then, you're right, it's not an issue.
Technically, though, if game physics is being computed, the dev should be using the SPEs/SPUs.
Tell me that this is the only reason you can't/won't use *BSD... if it is, it's pretty weak.
ATM just sucks. Yes. Yes it does. I worked on ATM, I worked on various ATM deployments. It sucks. I have the scars to proove it.
TokenRing, which is a neat graduate network course topic, is largely irrelevant, even it's cheap.
Can't you think of a better reason to **not** use BSD?