Do you have any idea how many orbiter specific safety problems remain with the Shuttle system?
The main engines are still cranky, though probably an order of magnitude better than the early Shuttle launches.
The hydrazine APUs are an issue.
Aging of the reinforced carbon-carbon leading edge panels is still not as well understood as we thought a few years ago, and may leave them much more vulnerable than we would like.
These are just the ones at the top of my head; last rundown I saw including all the age-related stuff they would need to recertify for flight past 2010 had several hundred crit-1 items.
Concur. I use spreadsheets; typically, a page per definable project or service area, and then a central tracking sheet with weekly or monthly updates of original estimate, current estimate, spent to date, etc for each project. You can see where you are in the spend, where the estimated total per project has gone pretty easily.
MS Project Server can certainly do this, but is pretty much overkill.
I don't know of any open-source domain specific tool for IT budgeting. You could, of course, use a spreadsheet other than Excel if that's your preference. Spreadsheets is pretty much spreadsheets.
The final printed copies of the proposals are due tomorrow at 2pm Houston time, though CD-ROMs were due last Friday; estimates by various surveys of the Vendors Expressing Interest list is that something like 25 proposals from prime contractors are expected. Many of those will probably not address all 4 capabilities NASA was inquiring about (A. Unpressurized cargo; B. Pressurized cargo; C. Pressurized cargo and return of equipment to Earth; D. ISS crew rotation).
Presumably more press coverage will be out tomorrow afternoon. So far, SpaceX has announced they submitted Dragon as a propopsal; Space Dev has strongly hinted they submitted Dream Chaser. Several other companies have said they were working on it. My company submitted our capsule.
When NASA held the industry briefing day, the hotel conference room probably had 200 seats set up in it, and it was nearly standing room only. Most of those companies were subcontractors rather than prime contractor candidates, but that's a lot of interest.
I believe I am highly but not uniquely qualified to answer this particular question. I spent the last month writing my company's NASA COTS proposal.
The Service Requirements Document (NC3P-1000) was an entirely appropriate and comparatively svelte 23 pages (thank you for a reasonable sized SRD, C3PO). The Interface Requirements Document was a slightly chunkier 130 pages, which was basically a summary of the Applications docs listed below for ISS Visiting Vehicles.
There were 49 "ISS Applications" specification documents, many into the hundreds of pages, 206 megabytes total, mixed PDF and.doc . 13 files and about another 138 megs of "ISS Familiarization". 16 docs and 66 megs of cargo data. Another 30 megs of human rating docs.
The FAA human rating docs are about 36 pages long, in 3 documents.
The COTS program office are doing a good job of minimizing paperwork requirements. The existing body of prior NASA specifications and requirements are excessive.
If you disagree, we can do a little test. I'll drop a stack of printouts of all the NASA docs listed above (one copy, single sided) on your foot, and you can drop a stack of printouts of the FAA regs (one copy, single sided) which apply to commercial spaceflight on my foot.
Actually, the lifting body and Boeing's original proposed design are both off the table; the NASA internal concept Apollo on Steroids version is being designed by both vendors to the same general specification of size, weight, etc.
If you need something like a terabit of bandwidth between the US east and west coasts, consider how many peer to peer link chains across the country will be saturated carrying it.
One of the major problems right now in the commercial ISP backbone environment is what happens if there's an outage; what's called route flapping, where routes dissapear and reappear, and all the routers affected have to recalculate how to get to various endpoints, can already saturate the router CPU logic for big, industrial grade room-full-of-racksize-router backbone facilities. Going to a more diffuse network at high bandwidth requirements exponentially makes this worse.
You want MOSIS. Providing small volume chip fab services (via short ganged-mask wafer runs at flexible mainstream fab houses) for decades now, Mosis is exactly what you want if FPGA and a programmable microcontroller aren't what you really need.
Third the advice on Art of the Start. There's a copy 24 inches left of my head right now. It's not just the business plan, it's all the "ok, go from zero to real business as fast as the business has to happen" advice.
Second everything said here. I'd boost it with a mod point but it's already at 5. It's fairly easy to store cold in insulated water tanks, chill them at night when the thermal environment is in your favor, and then turn the AC off in the middle of the day / peak electrical period. The other methods all work, too.
My response is to rubbish the assertions made by a whining ex-employee of NASA who feels compelled to justify how NASA dropped the ball
I can't imagine that you actually read the article and then said that with a straight face.
Even if you didn't know Jim, and I do, reading the article should make it clear to any reasonable open minded human being that Jim's not covering up or justifying what NASA did wrong with Challenger.
It's important to get it right and understand what NASA both did wrong and didn't do wrong regarding why Challenger was lost. Focusing on the things that myth says they did wrong but fact says they didn't leads to wasted effort trying to fix nonproblems. We (the spaceflight industry) have a hard enough time fixing real factual problems without going around in circles doing stuff that the general public is wrongly convinced are serious problems.
That I know of, no such distraction from Challenger was a causal issue in why Columbia was lost later. However, I do know that National Transportation Safety Board airliner investigations and effort are in several cases being effectively wasted on following up on one-in-a-million bad luck incidents, where there are larger problems which are systematic and not receiving enough attention, because the public isn't as interested in them for random reasons.
No, actually it involved a small pyrotechnics project and gasoline that got deposited onto an unexpectedly hot object and vaporized / evaporated. It wasn't natural gas or propane. I have an extra-healthy respect for gasoline vapor as a result...
Again we have semantics being put forth as fact. Most people would find little discrepancy between a person being subjected to violent trauma, going unconscious or into extreme shock, and dying within a minute and dying instantly. Nothing happens instantly anyway.
The crew were not subjected to particularly violent trauma from the breakup. Nor did the breakup knock them unconscious. All evidence available to us indicates that the cabin was generally intact, didn't get torn apart, wouldn't have tumbled violently enough to cause serious injury to properly strapped in seated astronauts. They went unconscious, we presume, because it had been damaged enough that the air leaked out, and they were at 65,000 feet by the time they started back down again, and you pass out if you breathe air at 65,000 foot pressure levels.
We don't know if everyone eventually passed out; the emergency air packs they had might have kept them conscious, and some of those were turned on. And they all might have woken back up on the way down as air pressure increased again. But we really don't know. The flight recorder stopped when the power went off in the breakup.
We know the breakup didn't kill them all, or knock them all unconscious, because if it had then they couldn't have turned on the air packs.
The design of the booster, while possessing flaws subject to improvement, was neither especially dangerous if operated properly, nor the result of political interference.
This statement is complete poppy-cock. Any rational person would recognise the inherent danger in strapping themselves to the side of an enormous tank of liquid oxygen and lighting it.
The LOX tank didn't kill anyone. And you don't light the LOX tank.
Jim was referring to the solid rocket boosters.
Replacement of the original asbestos-bearing putty in the booster seals was unrelated to the failure.
unrelated? surely this is the wrong word to use for a part that has been proven by more than one panel of highly respected scientists to be inherently flawed.
The putty seal problems existed before the change in materials was made. The problem was unrelated to that change happening. It is a myth that the problems appeared after the change.
Please read more carefully.
There were pressures on the flight schedule, but none of any recognizable political origin.
This is simply delusional, and requires no further comment
Claims were repeatedly made that the White House pushed on NASA to get them to launch in time for Reagan to do a live linkup chat as part of the State of the Union.
Phone logs, extensive interviews both with the White House staff and the NASA staff, repeated inquiries have shown that there is no factual evidence or ancedotal claim by anyone inside either the WH or the NASA program or its contractors that there was any such WH pressure.
If it happened, they erased all the evidence.
Things which are alledged and have no evidence are at best a myth or conspiracy theory. Calling it a myth, when it's been specifically repeatedly proven to have no factual evidence on the record anywhere, is a prefectly fair claim.
Your entire response seems to boil down to I believe these myths so they must be true!. The irony is astounding.
The wikipedia article took that text straight from the MSNBC article. It was added by Wikipedia user Gene Nyygard, today after Jim Oberg's article came out, and has a correct reference link to the MSNBC article attributing it.
That kind of sounds like an explosion to me. Maybe to a demolitions expert it doesn't meet some specialized technical definition of "explosion", but I don't see how that's really relavent. Talking about how the actual orbiter didn't explode is really starting to split hairs here.
1) Before the propellants had completely spilled, and long before (in terms of how fast the accident happened) they ignited and the visible fireball started, Challenger had already pitched up and immediately broken up. The fireball happened around the pieces of the orbiter after it broke up, and had nothing to do with the breakup happening.
2) The fireball had minimal pressure and a low enough temperature that it did not significantly damage either the already broken up pieces of the orbiter (no burn damage or crush damage from the fireball) or the solid rocket boosters.
If someone waved an industrial sized propane torch at you for one second, the kind they use to dry paint rapidly, you'd get mildly burned but it wouldn't kill you. If you were sitting inside your car when it was waved at you from outside, you wouldn't notice, unless it bubbled the paint a bit.
Not everything that looks big and bright and explosion-like kills and destroys everything inside it. I personally survived a small gas vapor fire where my body was essentially entirely inside the fireball, with only a few burnt hairs and what was functionally no worse than a bad sunburn on the parts of my skin not covered by clothing, and the clothes didn't catch on fire. I really don't recommend you try it yourself, but it won't kill you.
The myths are fairly common. Newcomers post them to space related websites and newsgroups and talk about them on talk shows and such all the time.
Regarding exploded, I have to disagree. Cars don't explode in accidents, though they often get pretty badly mangled and have pieces break off. It's reasonable to say that a lot of things which aren't detonations are explosions... a pressurized cannister of gas say, if it has a structural failure... or a boiler. But Challenger wasn't pushed apart by any sort of internal force. It pitched up rapidly at twice the speed of sound, and like any airplane suddenly tragically flown out to several times its structural design margins, broke into pieces.
It's particularly hard to make this point as what people saw as an explosion... the fireball... in fact had minimal overpressure and thermal density, and essentially didn't damage either the pieces of the Shuttle (which had already broken up) or the solid boosters. People always think that the fireball caused, or somehow was related to, the deaths. It was completely unrelated. If the external tank had been filled with perfectly inert water, and the shuttle came up off the stack as it did, the breakup of Challenger and eventual deaths of the astronauts would have been exactly the same.
You may think it's nitpicking, but it often matters for people to understand exactly which part of something caused deaths or destruction. Katrina didn't devastate New Orleans because it was a Cat 5 storm; Katrina pulled in a water surge which damaged levees which flooded the city. If there had been no Katrina, and random liquefaction caused a levee failure on a clear day without a storm in sight, New Orleans would have been just as badly damaged. That's not true for a lot of surrounding areas though, where Katrina floodwaters from the storm surge did directly cause the damage, and the New Orleans levee breaks later were irellevant.
I'm designing manned spacecraft now, and the details of what can go wrong during launch, in space, and during reentry matter. There are a lot of things which can go wrong and may look spectacularly bad, but shouldn't kill the crew. I am more concerned about the ones which could kill the crew, some of which don't look all that dangerous to the naked eye. Soyuz 10's crew died because one small valve failed and let all the air out as the capsule was coming down. Columbia's crew died because small pieces of foam falling off tanks got to be routine, and eventually after 100 missions a big one fell off and hit probably the single worst place on the whole Orbiter.
Silicon On Insulator; see the silicon on insulator wikipedia entry for a high level summary, or google the phrase for more details.
Basically, instead of a solid slab of silicon on which you fab chip components, you put a solid slab of an insulator (sapphire / alumina for example; see silicon on sapphire wikipedia entry) down and then an insulating silicon oxide layer, and then a thin layer of silicon on which you fab the parts. Since what's under the parts is insulator, rather than more semiconductor, it reduces the energy of switching and reduces the time to switch a transistor. Also reduces radiation effects on the semiconductor and other good stuff.
Unlike other fields, production ramps in semiconductor manufacturing are pretty easy to spot... the amount of new machinery and construction associated with a new process being deployed to a facility are hard to hide, and it's all over the trade press 18 months before stuff starts shipping typically.
AMD has traditionally been behind Intel on the bleeding edge fab stuff. Intel's dominated the fab tech race by six months or so for years and years. That is not changing here, as far as anyone I know of can see. AMD using SOI sort of blurs the line here, but in terms of process shrinks and the like Intel's ahead.
AMD's chips being better performers despite being behind some in chip fab is an important feature. But roadmaps based on imaginary pixie dust, in an industry where fabs cost $4 billion or so, are a waste of time even on slashdot.
I beg of you to show me an environment where performance is a necessity, and they use RAID 0+1. IT IS NOT USED IN PRODUCTION. The only place where 0+1 or 1+0 is used is at the consumer level.
I'm sorry, but your statement is profoundly ignorant.
I have worked for major system integrations, system vendors, and VARs, and I have architected and installed and benchmarked major storage systems on and off for 10 years. I've installed more full-rack-plus sized equipment than I can conveniently count, including work with Hitachi 9900 series and smaller stuff, EMC, Sun, Storagetek, IBM, as well as NAS gear from NetApp and some exposure to BlueArc.
When I say RAID 1+0 is in use in production, I mean it, because I've architected and built and operated it. At major ecommerce websites. At banks and financial institutions. At retail companies. At ASPs. At biotech companies.
When you work for a bank, you have racks and racks of hard drives, and they heads they are connected to use one of RAID 4, 5 or 6, or Netapp's vastly superior RAID DP. These filers are specially designed to be used by thousands of end-users, and they all use SCSI for the highest performing models. If they want to back data to tapeless backup, they will use ATA drives, but if this was really an environment where performance is required above a certain level as you suggested, then they would use SCSI.
Up until a couple of years ago, large customers used either A) direct connect fiberchannel drives, with FC RAID controllers, and large SAN environments, or B) large NAS systems with a wide variety of RAID configurations. NAS was cheaper but lower performance. For highest performing models you buy Fiber Channel, period. Claiming that SCSI was what the highest performing models use indicates you've never worked with true high end enterprise equipment.
Now, SATA drives connected to FC raid controllers in SANs are where the action's at, but all the major vendors still sell FC drives and SCSI drives for applications where the command tag queuing matters (though SATA 3 will eventually make that common across the technologies).
Unlike you, I actually have experience , so I know what I'm talking about and more importantly, what technology is suited for which type of environment. I don't talk out my ass like you do, giving bullshit statements, dropping misnomers like performance when it is obvious that RAID 5's performance characteristics won't make a bit of a difference to someone who is asking about the difference between SCSI and SATA for a home file server.
I really don't think someone who didn't even think of FC systems or SANs is in any position to be lecturing me about RAID performance.
I know how RAID 5 and RAID 10 perform; I've been working with them continuously since the hardware vendor I was working for started building RAID boxes based on the Mylex DAC-960 controller back in 1995-6 and I got to both write performance benchmark code and use standards like SPEC's LADDIS SFS93. I've talked code with the RAID controller vendors. I've been building RAID systems since 4 gig SCSI drives were brand new, and I use both SANs and SAN attached SATA storage in bulk today.
There are people more expert than I am in this stuff; I haven't built a large storage system using the highest end stuff in a couple of years, and there are clearly people at integrators/VARS/vendors who live and breathe storage every day and are tip-top current experts. But I know what I'm talking about.
There's a flip side to that, though; if the company doesn't help out, then people self train, get resentful, and walk away taking all those skills with them.
As a manager, your job is to try and ensure that you have a) bodies with b) specific required skills and c) enough experience in your specific environment to work effectively on board at all times. If you aren't paying attention to how many bodies you need, you're not doing your job. If you aren't paying attention to what specific skills are required, you're not doing your job. If you aren't trying to retain people with the required environment-specific experience, you're not doing your job.
Skills don't just appear on trees to be picked. If people have to self-teach, then expect them to take a while, perhaps miss some important stuff to know, and resent you for it if you didn't support them right.
The side you pointed out, that people who develop themselves are the ones who generally move forwards and have more successful careers, is true. But there are plenty of people who geek out and up and then burn out as well, and a career that lasts 10 years before you have to exit the profession isn't really all that successful either. If you aren't balancing your life to stay happy as well as productive and learning, you lose. And with a family, they lose too.
There is no single right answer, because people learn at different rates, have different backgrounds coming to specific problems, have different tolerance points for overwork, have different social interaction comfort levels, have different family lives, etc. Really top notch people, who can overwork, still teach themselves, and still have good outside lives, are extremely rare, and anyone whose idea of IT management assumes all their employees are top tier is abusing nearly all of the employees. You have to be realistic about how good people are.
Being the one or one of the very few IT people in small companies is particularly stressful, because if things start to get overwhelming it's so hard to convince managers that more resources are required. This plays particularly badly into the negatives I mentioned earlier. If you find an unsupportive boss without enough resources in a small company situation, my advice is to move on. If they don't have enough resources but understand the issues, they will make something happen (or, they should move on, as should you). IT is a cost center, but IT done wrong has both financial and organization productivity impacts across the company. If the company can't afford or won't afford enough to make IT work successfully... bail out to somewhere big enough that you aren't caught between the rock and the hard place.
The fact that you mentioned RAID 0+1 shows that you really don't know anything about true storage. That is probably the most inefficient way to go, congratulations!
0+1 is a mistake, but 1+0 isn't. 0+1 loses the data set if any one arbitrary drive fails in both sides of the mirror; 1+0 only if you lose both disks in a single mirror pair.
RAID 5 is noticably slower disk performance for writes, and radically slower performance for reads and writes if you lose a disk. In many cases, the performance during a failure for RAID 5 can reduce system capacity below the required level, and thus RAID 5 is simply not an acceptable technology for those environments.
If just sticking more data on disk is the requirement, and you don't care how slow it gets if you have a drive fall over, then RAID 5 is great. But real world enterprise environments exist where losing half your disk throughput will cause the company's service to go down, and then you're out of business. Those guys don't RAID 5 if they know what's good for them.
All that proves is that the screen and the piece of paper say the same thing. How do either of those relate to the actual value recorded as the vote?
By itself, nothing.
As part of a spot-check quality control process, however, it is pretty damn foolproof.
You make it a requirement to, on the day after the election or whenever, go back through say 1-5% of the total machines in any county or city, plus any machines with exceptional results, and read all the paper vote results off the internal record, and compare to the electronic copy. The results should be identical. If they aren't identical for any sample, throw a red flag and freeze the results, and then go compare a much larger sample, and if necessary test them all by reading out all the paper results in the area.
Basic statistics indicates that for large enough numbers, even spot checks of a few percent will almost certainly catch any attempts to do widespread (i.e., statistically significant) manipulation or fraud within the computer mechanism.
No single level of security at any level can possibly catch all voter fraud. You have to check redundantly, you have to check at multiple levels (computers all agree, but 2x as many recorded votes as registered voters, anyone?). It is possible for multiple levels of checks to make it very very hard for any conspiracy to statistically affect the results.
Slashdot Mirror
Do you have any idea how many orbiter specific safety problems remain with the Shuttle system?
The main engines are still cranky, though probably an order of magnitude better than the early Shuttle launches.
The hydrazine APUs are an issue.
Aging of the reinforced carbon-carbon leading edge panels is still not as well understood as we thought a few years ago, and may leave them much more vulnerable than we would like.
These are just the ones at the top of my head; last rundown I saw including all the age-related stuff they would need to recertify for flight past 2010 had several hundred crit-1 items.
He meant normal as in at right angles to.
Flames are supposed to come out the bottom, sometimes downwards out of side nozzles, but not out of the side of the rocket.
Please cite.
I've typoed it in the past, but I haven't seen any official Sun stuff which did, going back to the introduction of SPARC.
Concur. I use spreadsheets; typically, a page per definable project or service area, and then a central tracking sheet with weekly or monthly updates of original estimate, current estimate, spent to date, etc for each project. You can see where you are in the spend, where the estimated total per project has gone pretty easily.
MS Project Server can certainly do this, but is pretty much overkill.
I don't know of any open-source domain specific tool for IT budgeting. You could, of course, use a spreadsheet other than Excel if that's your preference. Spreadsheets is pretty much spreadsheets.
Perhaps you should take a closer look at the Delta IV Medium configuration at http://www.boeing.com/defense-space/space/delta/pr oduct_card/pc_d4_tech_print.pdf (PDF)
There are no solids there, on the low end model.
The final printed copies of the proposals are due tomorrow at 2pm Houston time, though CD-ROMs were due last Friday; estimates by various surveys of the Vendors Expressing Interest list is that something like 25 proposals from prime contractors are expected. Many of those will probably not address all 4 capabilities NASA was inquiring about (A. Unpressurized cargo; B. Pressurized cargo; C. Pressurized cargo and return of equipment to Earth; D. ISS crew rotation).
Presumably more press coverage will be out tomorrow afternoon. So far, SpaceX has announced they submitted Dragon as a propopsal; Space Dev has strongly hinted they submitted Dream Chaser. Several other companies have said they were working on it. My company submitted our capsule.
When NASA held the industry briefing day, the hotel conference room probably had 200 seats set up in it, and it was nearly standing room only. Most of those companies were subcontractors rather than prime contractor candidates, but that's a lot of interest.
I believe I am highly but not uniquely qualified to answer this particular question. I spent the last month writing my company's NASA COTS proposal.
.doc . 13 files and about another 138 megs of "ISS Familiarization". 16 docs and 66 megs of cargo data. Another 30 megs of human rating docs.
The Service Requirements Document (NC3P-1000) was an entirely appropriate and comparatively svelte 23 pages (thank you for a reasonable sized SRD, C3PO). The Interface Requirements Document was a slightly chunkier 130 pages, which was basically a summary of the Applications docs listed below for ISS Visiting Vehicles.
There were 49 "ISS Applications" specification documents, many into the hundreds of pages, 206 megabytes total, mixed PDF and
The FAA human rating docs are about 36 pages long, in 3 documents.
The COTS program office are doing a good job of minimizing paperwork requirements. The existing body of prior NASA specifications and requirements are excessive.
If you disagree, we can do a little test. I'll drop a stack of printouts of all the NASA docs listed above (one copy, single sided) on your foot, and you can drop a stack of printouts of the FAA regs (one copy, single sided) which apply to commercial spaceflight on my foot.
One of us will walk away, one will limp at best.
Actually, the lifting body and Boeing's original proposed design are both off the table; the NASA internal concept Apollo on Steroids version is being designed by both vendors to the same general specification of size, weight, etc.
If you need something like a terabit of bandwidth between the US east and west coasts, consider how many peer to peer link chains across the country will be saturated carrying it.
One of the major problems right now in the commercial ISP backbone environment is what happens if there's an outage; what's called route flapping, where routes dissapear and reappear, and all the routers affected have to recalculate how to get to various endpoints, can already saturate the router CPU logic for big, industrial grade room-full-of-racksize-router backbone facilities. Going to a more diffuse network at high bandwidth requirements exponentially makes this worse.
P2P across a city? Not ridiculous.
P2P across the world? Baaad idea.
You want MOSIS. Providing small volume chip fab services (via short ganged-mask wafer runs at flexible mainstream fab houses) for decades now, Mosis is exactly what you want if FPGA and a programmable microcontroller aren't what you really need.
Third the advice on Art of the Start. There's a copy 24 inches left of my head right now. It's not just the business plan, it's all the "ok, go from zero to real business as fast as the business has to happen" advice.
Not if I'm remotely possibly going to be a crewmember...
Second everything said here. I'd boost it with a mod point but it's already at 5. It's fairly easy to store cold in insulated water tanks, chill them at night when the thermal environment is in your favor, and then turn the AC off in the middle of the day / peak electrical period. The other methods all work, too.
Even if you didn't know Jim, and I do, reading the article should make it clear to any reasonable open minded human being that Jim's not covering up or justifying what NASA did wrong with Challenger.
It's important to get it right and understand what NASA both did wrong and didn't do wrong regarding why Challenger was lost. Focusing on the things that myth says they did wrong but fact says they didn't leads to wasted effort trying to fix nonproblems. We (the spaceflight industry) have a hard enough time fixing real factual problems without going around in circles doing stuff that the general public is wrongly convinced are serious problems.
That I know of, no such distraction from Challenger was a causal issue in why Columbia was lost later. However, I do know that National Transportation Safety Board airliner investigations and effort are in several cases being effectively wasted on following up on one-in-a-million bad luck incidents, where there are larger problems which are systematic and not receiving enough attention, because the public isn't as interested in them for random reasons.
We don't know if everyone eventually passed out; the emergency air packs they had might have kept them conscious, and some of those were turned on. And they all might have woken back up on the way down as air pressure increased again. But we really don't know. The flight recorder stopped when the power went off in the breakup.
We know the breakup didn't kill them all, or knock them all unconscious, because if it had then they couldn't have turned on the air packs.
The LOX tank didn't kill anyone. And you don't light the LOX tank.Jim was referring to the solid rocket boosters.
The putty seal problems existed before the change in materials was made. The problem was unrelated to that change happening. It is a myth that the problems appeared after the change.Please read more carefully.
Claims were repeatedly made that the White House pushed on NASA to get them to launch in time for Reagan to do a live linkup chat as part of the State of the Union.Phone logs, extensive interviews both with the White House staff and the NASA staff, repeated inquiries have shown that there is no factual evidence or ancedotal claim by anyone inside either the WH or the NASA program or its contractors that there was any such WH pressure.
If it happened, they erased all the evidence.
Things which are alledged and have no evidence are at best a myth or conspiracy theory. Calling it a myth, when it's been specifically repeatedly proven to have no factual evidence on the record anywhere, is a prefectly fair claim.
Your entire response seems to boil down to I believe these myths so they must be true!. The irony is astounding.
The wikipedia article took that text straight from the MSNBC article. It was added by Wikipedia user Gene Nyygard, today after Jim Oberg's article came out, and has a correct reference link to the MSNBC article attributing it.
Duuuuude.
Learn to read and check references...
2) The fireball had minimal pressure and a low enough temperature that it did not significantly damage either the already broken up pieces of the orbiter (no burn damage or crush damage from the fireball) or the solid rocket boosters.
If someone waved an industrial sized propane torch at you for one second, the kind they use to dry paint rapidly, you'd get mildly burned but it wouldn't kill you. If you were sitting inside your car when it was waved at you from outside, you wouldn't notice, unless it bubbled the paint a bit.
Not everything that looks big and bright and explosion-like kills and destroys everything inside it. I personally survived a small gas vapor fire where my body was essentially entirely inside the fireball, with only a few burnt hairs and what was functionally no worse than a bad sunburn on the parts of my skin not covered by clothing, and the clothes didn't catch on fire. I really don't recommend you try it yourself, but it won't kill you.
Regarding exploded, I have to disagree. Cars don't explode in accidents, though they often get pretty badly mangled and have pieces break off. It's reasonable to say that a lot of things which aren't detonations are explosions... a pressurized cannister of gas say, if it has a structural failure... or a boiler. But Challenger wasn't pushed apart by any sort of internal force. It pitched up rapidly at twice the speed of sound, and like any airplane suddenly tragically flown out to several times its structural design margins, broke into pieces.
It's particularly hard to make this point as what people saw as an explosion... the fireball... in fact had minimal overpressure and thermal density, and essentially didn't damage either the pieces of the Shuttle (which had already broken up) or the solid boosters. People always think that the fireball caused, or somehow was related to, the deaths. It was completely unrelated. If the external tank had been filled with perfectly inert water, and the shuttle came up off the stack as it did, the breakup of Challenger and eventual deaths of the astronauts would have been exactly the same.
You may think it's nitpicking, but it often matters for people to understand exactly which part of something caused deaths or destruction. Katrina didn't devastate New Orleans because it was a Cat 5 storm; Katrina pulled in a water surge which damaged levees which flooded the city. If there had been no Katrina, and random liquefaction caused a levee failure on a clear day without a storm in sight, New Orleans would have been just as badly damaged. That's not true for a lot of surrounding areas though, where Katrina floodwaters from the storm surge did directly cause the damage, and the New Orleans levee breaks later were irellevant.
I'm designing manned spacecraft now, and the details of what can go wrong during launch, in space, and during reentry matter. There are a lot of things which can go wrong and may look spectacularly bad, but shouldn't kill the crew. I am more concerned about the ones which could kill the crew, some of which don't look all that dangerous to the naked eye. Soyuz 10's crew died because one small valve failed and let all the air out as the capsule was coming down. Columbia's crew died because small pieces of foam falling off tanks got to be routine, and eventually after 100 missions a big one fell off and hit probably the single worst place on the whole Orbiter.
Basically, instead of a solid slab of silicon on which you fab chip components, you put a solid slab of an insulator (sapphire / alumina for example; see silicon on sapphire wikipedia entry) down and then an insulating silicon oxide layer, and then a thin layer of silicon on which you fab the parts. Since what's under the parts is insulator, rather than more semiconductor, it reduces the energy of switching and reduces the time to switch a transistor. Also reduces radiation effects on the semiconductor and other good stuff.
AMD has traditionally been behind Intel on the bleeding edge fab stuff. Intel's dominated the fab tech race by six months or so for years and years. That is not changing here, as far as anyone I know of can see. AMD using SOI sort of blurs the line here, but in terms of process shrinks and the like Intel's ahead.
AMD's chips being better performers despite being behind some in chip fab is an important feature. But roadmaps based on imaginary pixie dust, in an industry where fabs cost $4 billion or so, are a waste of time even on slashdot.
I have worked for major system integrations, system vendors, and VARs, and I have architected and installed and benchmarked major storage systems on and off for 10 years. I've installed more full-rack-plus sized equipment than I can conveniently count, including work with Hitachi 9900 series and smaller stuff, EMC, Sun, Storagetek, IBM, as well as NAS gear from NetApp and some exposure to BlueArc.
When I say RAID 1+0 is in use in production, I mean it, because I've architected and built and operated it. At major ecommerce websites. At banks and financial institutions. At retail companies. At ASPs. At biotech companies.
Up until a couple of years ago, large customers used either A) direct connect fiberchannel drives, with FC RAID controllers, and large SAN environments, or B) large NAS systems with a wide variety of RAID configurations. NAS was cheaper but lower performance. For highest performing models you buy Fiber Channel, period. Claiming that SCSI was what the highest performing models use indicates you've never worked with true high end enterprise equipment.Now, SATA drives connected to FC raid controllers in SANs are where the action's at, but all the major vendors still sell FC drives and SCSI drives for applications where the command tag queuing matters (though SATA 3 will eventually make that common across the technologies).
I really don't think someone who didn't even think of FC systems or SANs is in any position to be lecturing me about RAID performance.I know how RAID 5 and RAID 10 perform; I've been working with them continuously since the hardware vendor I was working for started building RAID boxes based on the Mylex DAC-960 controller back in 1995-6 and I got to both write performance benchmark code and use standards like SPEC's LADDIS SFS93. I've talked code with the RAID controller vendors. I've been building RAID systems since 4 gig SCSI drives were brand new, and I use both SANs and SAN attached SATA storage in bulk today.
There are people more expert than I am in this stuff; I haven't built a large storage system using the highest end stuff in a couple of years, and there are clearly people at integrators/VARS/vendors who live and breathe storage every day and are tip-top current experts. But I know what I'm talking about.
And, clearly, you don't.
As a manager, your job is to try and ensure that you have a) bodies with b) specific required skills and c) enough experience in your specific environment to work effectively on board at all times. If you aren't paying attention to how many bodies you need, you're not doing your job. If you aren't paying attention to what specific skills are required, you're not doing your job. If you aren't trying to retain people with the required environment-specific experience, you're not doing your job.
Skills don't just appear on trees to be picked. If people have to self-teach, then expect them to take a while, perhaps miss some important stuff to know, and resent you for it if you didn't support them right.
The side you pointed out, that people who develop themselves are the ones who generally move forwards and have more successful careers, is true. But there are plenty of people who geek out and up and then burn out as well, and a career that lasts 10 years before you have to exit the profession isn't really all that successful either. If you aren't balancing your life to stay happy as well as productive and learning, you lose. And with a family, they lose too.
There is no single right answer, because people learn at different rates, have different backgrounds coming to specific problems, have different tolerance points for overwork, have different social interaction comfort levels, have different family lives, etc. Really top notch people, who can overwork, still teach themselves, and still have good outside lives, are extremely rare, and anyone whose idea of IT management assumes all their employees are top tier is abusing nearly all of the employees. You have to be realistic about how good people are.
Being the one or one of the very few IT people in small companies is particularly stressful, because if things start to get overwhelming it's so hard to convince managers that more resources are required. This plays particularly badly into the negatives I mentioned earlier. If you find an unsupportive boss without enough resources in a small company situation, my advice is to move on. If they don't have enough resources but understand the issues, they will make something happen (or, they should move on, as should you). IT is a cost center, but IT done wrong has both financial and organization productivity impacts across the company. If the company can't afford or won't afford enough to make IT work successfully... bail out to somewhere big enough that you aren't caught between the rock and the hard place.
RAID 5 is noticably slower disk performance for writes, and radically slower performance for reads and writes if you lose a disk. In many cases, the performance during a failure for RAID 5 can reduce system capacity below the required level, and thus RAID 5 is simply not an acceptable technology for those environments.
If just sticking more data on disk is the requirement, and you don't care how slow it gets if you have a drive fall over, then RAID 5 is great. But real world enterprise environments exist where losing half your disk throughput will cause the company's service to go down, and then you're out of business. Those guys don't RAID 5 if they know what's good for them.
As part of a spot-check quality control process, however, it is pretty damn foolproof.
You make it a requirement to, on the day after the election or whenever, go back through say 1-5% of the total machines in any county or city, plus any machines with exceptional results, and read all the paper vote results off the internal record, and compare to the electronic copy. The results should be identical. If they aren't identical for any sample, throw a red flag and freeze the results, and then go compare a much larger sample, and if necessary test them all by reading out all the paper results in the area.
Basic statistics indicates that for large enough numbers, even spot checks of a few percent will almost certainly catch any attempts to do widespread (i.e., statistically significant) manipulation or fraud within the computer mechanism.
No single level of security at any level can possibly catch all voter fraud. You have to check redundantly, you have to check at multiple levels (computers all agree, but 2x as many recorded votes as registered voters, anyone?). It is possible for multiple levels of checks to make it very very hard for any conspiracy to statistically affect the results.