Have you read the CAIB report? The issues are managerial and frighteningly similar. I direct you to Chapter 8 of the report, summarized in the table of contents thus:
8. History as Cause: Columbia and Challenger 8.1 Echoes of Challenger 8.2 Failures of Foresight: Two Decision Histories and the Normalization of Deviance 8.3 System Effects: The Impact of History and Politics on Risky Work 8.4 Organization, Culture, and Unintended Consequences 8.5 History as Cause: Two Accidents. 8.6 Changing NASA?s Organizational System
The report is excellently written and present and organized and available as free download.
why don't they have an option to route the recovered signal verbatim to the main transmitter and send that to earth
The big dish they use to transmit to Earth is also the dish that will be used to pick up Huygen's signal -- it can't be pointing in two places at once.
I find it insulting that people expect perfection from NASA. Getting into space, travelling through it, and getting back to Earth safely are *incredibly* hard work
No-one is expecting perfection. What we do expect, and have a right to do so, is to expect a management structure that does not actively prevent already learnt solutions to known problems being applied.
There's a difference between doing something risky and simply being reckless.
I'm uptight because its annoying when you work on an article and people comment without bothering to read it -- yes, I know that's endemic to/., but it's still a pain in the ass.
The point is that we dug up an aspect of the story you're not going to see any where else, let alone a general overview program, but a really cool story of a guy who deserves a lot of credit, Boris Smeds. I would hate for anyone to not bother to find out about him because a related program on the telly happened to be braodcast the night before/. decided to post the story.
Re:Dont Bother Reading Long Article
on
Saving Huygens
·
· Score: 5, Insightful
Sure, everyone knows that a)something Doppler related went wrong with Huygens and b) they fixed it with "fancy flying", but that's like saying don't bother to read a history of World War II because everyone knows a) Hitler started it and b) the Allies won.
The point of the story was to explain the problem with a level of accuracy and detail that was simply missing from most report and to tell the story of some stone-cold great work by an engineer, something of interest to most engineers, and I would hazard, to most slashdotters.
As far as I am aware, no-one else has told the story of how Boris Smeds pushed through the comms test that showed something was wrong, despite intial rejection and then later, modified it on the fly to reveal the problem was Doppler related, saving months of delay. Learning about his example of how to be a great engineers is the article's real utility, not teaching Spectrum readers how to fix Titan landers.
Disclaimer -- I edited this story for IEEE Spectrum
But if I may point out, to all those BBC viewers yawning "old news", this story was published by us on October 1st. (I actually submitted it at the time but the/. Gods rejected it).
That's nice. Did they actually explain how the Doppler shift affected the BPS coding used in the Huygen's telemetry, or describe how the problem was missed, or tell the story of Boris Smeds pushed through his test and ended up modifying it on the fly? And does every reader of IEEE Spectrum get the BBC on their TV? (hint, Spectrum has a global circulation)
-- disclaimer, I edited (and did some reporting for) this story.
They did test the accelerometers, using a centrifuge. But the test harness was wired backward too. Didn't read the article did you?
There's certainly a balance to be found between too much testing and too little. But -- as the Columbia Accident Investigation Board report harshly criticised -- at NASA, the pendulum had swung too far from physical testing towards simulation, extrapolation, and pure guess-work.
Let the NASA-bashing thread continue.
NASA does appear to be working on its management issues. But until it proves it has succeded in making significanct progress, it has, sadly, lost the benefit of the doubt. NASA is a public program, and if NASA management or Congress won't provide the requisite oversight, then we should be grateful that people like Oberg (a 22-year NASA veteran) are holding NASA's feet to the fire.
What Oberg is objecting to (and its one of the the things the Columbia Accident investigation board objected too as well) is that NASA has a long history of forgetting lessons learned.
That is why he is holding managements feet to the fire here, as did the CAIB.
And NASA doesn't test everything. In fact, NASA's relience on simulation and extrapolation and just plain guess work was harshly criticized in CAIB report, which is free for anyone to read.
As I posted elsewhere, but I belive it bears repeating:
We're talking about a class of errors that have happened before. We already know about them, they've already been detected. And yet, because of management failure, they continue to persist. The Columbia Accident Board identified this failure as NASA's key problem, not the weakeness of Reinforced Carbon Carbon leading wing edges.
Unknown errors are unavoidable, but ignoring solutions to known errors is unforgivable.
During his 22-years at Mission Control, Oberg's helped design real missions. And just because you think its "nagging" doesn't mean that anyone who gives a damn about the space program, or just good engineering, should ever let up for a second in their demands for engineering and managerial excellence.
Except the problems Oberg describes, including the proximate cause of the Genesis crash, have absolutely nothing to do with environmental conditions in space or anywhere else, but everything to do with mistakes made in nice clean rooms here on Earth, and magnified by poor management, again here on Earth.
Except that Oberg is a 22-year veteran of Mission Control.
Except that everything he's saying here is an echo of what the Columbia Accident Investigation Board said about NASA's manned space program.
Except that, if you'd bother to read the article, you'd see that the criticism is not of "engineer's efforts", but of management.
Except that "are human, and they will do stupid things" is the whole point of Oberg's article, and he's talking about the failure of NASA to provide oversight to catch these inevitable screw-ups.
For anyone wanting to yack about poor performance... put your money where your mouth is. I just get sick of all the constant nagging.
Oberg's helped design real missions. And just because you think its "nagging" doesn't mean that anyone who gives a damn about the space program, or just good engineering, should ever let up for a second in their demands for engineering and managerial excellence.
No-one, least of all Oberg (a 22-year veteran of mission control), is asking NASA to have a 100% success rate. Space is harsh, unknown unkowns lurk, etc.
What is is calling for is a management structure that allows solutions to problems that have occured before to be implemented properly. Columbia was destroyed for almost the same root causes that were exposed after Challanger. I don't think it's unreasonable to expect people to have elimiated those problems, and kept them eliminated.
The Columbia Accident Board had some harsh things to say about "Cheaper, Faster, Better" and NASA technical oversight in general, you should read their report.
No need to sniff derisively in the direction of NASA's "middle management".
We're not talking about some unknown unknowns that crop up as the inevitable residue of your halting problem analogy.
We're talking about a class of errors that have happened before. We already know about them, they've already been detected. And yet, because of management failure, they continue to persist. The Columbia Accident Board identified this as NASA's key problem, not the weakeness of Reinforced Carbon Carbon leading wing edges.
Unknown errors are unavoidable, but ignoring solutions to known errors is unforgivable.
This is hindsite at its best, and is the classic comment by beareaucrats who have no concept of what cutting edge design is about.
You only get to play the hindsight card the first time this kind of screw-up happens. If you actually read the article you'll see that Oberg (who isn't a beauracract but a 22-year veteran of mission control and one of the world'd experts on the Russian space program) is indicting NASA for having a management structure that leads to technical amnesia: the same type of oversight failure keeps happening again and again.
Oberg is not alone in this. The Columbia Accident Report despairingly noted the similities between Columbia and Challanger: both accidents where caused by poor management but what was worse with Columbia was that NASA had failed to really internalise the lessons of Challanger, or heed the warning flags about management and technical problems put up by countless internal and external reports.
Sure, space is hard. But it's not helped by an organization that has institutionalised technical amnesia and abandoned many of its internal checks and balances (at least this was the case at the time of the Columbia report, maybe things have changed).
And if you really want to compare against other agencies, NASA's astronaut bodycount does not compare favorably against the cosmonuat bodycount...
Sadly, your post is a classic comment by slashdotters who have no concept what effective technical management of risky systems looks like. (Hint: not all cutting edge designs get managed the same way. There's a difference between building racing sailboats and spaceships. This is detailed in the Columbia accident report. Read it and get a clue).
Re:interesting but it's not really true
on
Murphy's Law Rules NASA
·
· Score: 2, Interesting
from scattered teams that all only check their parts rather than having fully qualified teams that go over the entire vehical.
Your sentiment is correct, but your details are a little off. For example the Saturn V rocket was built by "scattered teams" (and committees were heavily involved, despite the mythology around Von Braun)-- the first stage was built by Boeing, the second by North American, the third by Douglas Aircraft, the Instrument Unit (the control system) by IBM, the LEM by Grumman and the CSM by North American, and so on, all the way down a huge chain of sub-contractors. But Apollo had brilliant technical management: it was pricey, but did do an amazing job of system integration.
It's when you try for cheaper missions that having one team take a spacecraft from design through operation is important: this was done on the Mars Pathfinder mission to great success, but wasn't done on other "Faster, Cheaper, Better" missions, to great falure, as demonstrated by, well, take your pick.
It's easer to administer content based on what you pay. For example, say you want to pay for HBO. All you have to do is call up TWC and subscribe to it. From there, you will instantly have access and will not need a cable guy to come to your home. It's a win-win for everyone.
As a TWC customer in NYC, I could do exactly that when I had an analogue cable box too. Digital had nothing to with it.
Even though you acknowledge the overall statistics, you then rely on one person's experiences for choosing not to wear a seatbelt in many circumstances to overrule the statistics.
To see why this is crazy, imagine asking a 1000 people all across the country to toss (fair and balanced) coins. Ask the 500 or so people who get heads to toss again. Ask the 250 or so people who get heads that time to toss again. And so on, through 125, 62, 31, 15, 7, 3, till you're left with 1 person. Now this 1 person has tossed a coin 10 times and it's come up heads every time! [1]
Now if you didn't know much about coin tossing, except a statistic that said they come up tails about 50% of the time, and you only knew that one person, should you believe her if she says "Well, the statistics say tails comes up 50% of the time, but from what I've seen, it's heads all the way!"?
Unless you know of a broad survery of many accident investigators who detect a tendancy for low-speed or low-traffic density accident injuries to be increased in either number or severity because of seat belts, then you must take what you're hearing with a hefty grain of salt, even if what they are saying is 100% true[2]. (By the way, I fail to see the difference in between accidently wrapping oneself around a telephone pole on a busy road vs. a quiet road.)
Don't forget there's an obvious potentail for observer's bias here too: you're not seeing his formal reports, but just the stories he's choosing to share with you in an environment which encourages entertaining conversation, not neccessarily statistically accurate conversation.
In the absence of such of survey, perhaps the best thing is to consider the failure mode you're really concerened about: it's not that wearing a seat belt is bad during the accident, but that you may be trapped afterwards. Put a box cutter or similar within reach, say in the door drawer. If you can't operate the cutter because of unconsciousness or severe injury, well, in your condition, you weren't getting of that car anyway.
[2] The furor over silicone breast implants is another good example: a lot of women honestly reported problems after breast implants, but when all was said and done, their problems were coincidental.
Start with lots of funny, put your serious emotional stuff in right at the optimal time nearer the end, and go out funny.
I think you're onto something: Both, say, Scrubs and The Office (two dissimilar comedy shows that are noted for paying attention to the emotional landscape) have this structure.
Where are you getting your definition of Ethernet? You're not allowed to redefine it to "the definition that makes me right" The actual standard includes the physical layer specifications.
Here's the abstract for 802.3 aka, Ethernet (if you care to bother, you can download the full standard for free, and I've added emphasis here):
IEEE Std 802.3: CSMA/CD Access Method and Physical Layer Specifications. Abstract: The media access control characteristics for the Carrier Sense Multiple Access with Collision Detection (CSMA/CD) access method for shared medium local area networks are described. The control characteristics for full duplex dedicated channel use are also described. Specifications are provided for MAU types 1BASE5 at 1 Mb/s; Attachment Unit Interface (AUI) and MAU types 10BASE5, 10BASE2, FOIRL (fiber optic inter-repeater link), 10BROAD36, 10BASE-T, 10BASE-FL, 10BASE-FB, and 10BASE-FP at 10 Mb/s; Media Independent Interface (MII) and PHY types 100BASE-T4, 100BASE-TX, 100BASE-FX, and 100BASE-T2 at 100 Mb/s; and the Gigabit MII (GMII) and 1000BASE-X PHY types, 1000BASE-SX, 1000BASE-LX, and 1000BASE-CX, which operate at 1000 Mb/s (Gigabit Ethernet) as well as PHY type 1000BASE-T. Repeater specifications are provided at each speed. Full duplex specifications are provided at the Physical Layer for 10BASE-T, 10BASE-FL, 100BASE-TX, 100BASE-FX, 100BASE-T2, and Gigabit Ethernet. System considerations for multisegment networks at each speed and management information base (MIB) specifications and additions to support Virtual Bridged Local Area Networks (VLANs) as specified in IEEE P802.1Q are also provided. Also specified is an optional Link Aggregation sublayer which multiple physical links to be aggregated together to form a single logical link.
Thus, just as a protocol which fits the specifications in 802.3 is known as an "Ethernet protocol", a physical cable which also meets the given specs is correctly known as an "Ethernet cable." Ethernet can not run on "any type of cable" and still be Ethernet. To quote the standard: communication by way of the ISO/IEC 8802-3 [IEEE Std 802.3] Local Area Network requires complete compatibility at the Physical Medium interface (that is, the physical cable interface). The standard describes a number of ways of physical cabling a network together (co-ax, twisted pair, fibre optic), but these must all meet the specs and so be "Ethernet cables."
Now, if you can quote something more authorative than the standard, I love to see it.
Actually, pedant boy, the IEEE 802.3 standard better known as Ethernet, specifies both the physical layer and the transport layer. So to say "Ethernet cable" is perfectly correct, both from the standpoint of commonly accepted usage and the standpoint of people who actually know what they're talking about.
Slashdot Mirror
Have you read the CAIB report? The issues are managerial and frighteningly similar. I direct you to Chapter 8 of the report, summarized in the table of contents thus:
8. History as Cause: Columbia and Challenger
8.1 Echoes of Challenger
8.2 Failures of Foresight: Two Decision Histories and the Normalization of Deviance
8.3 System Effects: The Impact of History and Politics on Risky Work
8.4 Organization, Culture, and Unintended Consequences
8.5 History as Cause: Two Accidents.
8.6 Changing NASA?s Organizational System
The report is excellently written and present and organized and available as free download.
why don't they have an option to route the recovered signal verbatim to the main transmitter and send that to earth
The big dish they use to transmit to Earth is also the dish that will be used to pick up Huygen's signal -- it can't be pointing in two places at once.
I find it insulting that people expect perfection from NASA. Getting into space, travelling through it, and getting back to Earth safely are *incredibly* hard work
No-one is expecting perfection. What we do expect, and have a right to do so, is to expect a management structure that does not actively prevent already learnt solutions to known problems being applied.
There's a difference between doing something risky and simply being reckless.
Thanks for the link to the transcript: Smeds, who saved the Huygens mission, isn't mentioned once.
It is so nice when someone actually bothers to read the bloody article. Thank you!
Disclaimer: I edited this story for IEEE Spectrum
As far as I know they didn't.
I'm uptight because its annoying when you work on an article and people comment without bothering to read it -- yes, I know that's endemic to /., but it's still a pain in the ass.
/. decided to post the story.
The point is that we dug up an aspect of the story you're not going to see any where else, let alone a general overview program, but a really cool story of a guy who deserves a lot of credit, Boris Smeds. I would hate for anyone to not bother to find out about him because a related program on the telly happened to be braodcast the night before
Sure, everyone knows that a)something Doppler related went wrong with Huygens and b) they fixed it with "fancy flying", but that's like saying don't bother to read a history of World War II because everyone knows a) Hitler started it and b) the Allies won.
The point of the story was to explain the problem with a level of accuracy and detail that was simply missing from most report and to tell the story of some stone-cold great work by an engineer, something of interest to most engineers, and I would hazard, to most slashdotters.
As far as I am aware, no-one else has told the story of how Boris Smeds pushed through the comms test that showed something was wrong, despite intial rejection and then later, modified it on the fly to reveal the problem was Doppler related, saving months of delay. Learning about his example of how to be a great engineers is the article's real utility, not teaching Spectrum readers how to fix Titan landers.
Disclaimer -- I edited this story for IEEE Spectrum
As soon as proper electronic paper comes out, I promise we're going to have video so good it'll make your eyes melt out of their sockets.
But if I may point out, to all those BBC viewers yawning "old news", this story was published by us on October 1st. (I actually submitted it at the time but the /. Gods rejected it).
Disclaimer -- I work for IEEE Spectrum.
That's nice. Did they actually explain how the Doppler shift affected the BPS coding used in the Huygen's telemetry, or describe how the problem was missed, or tell the story of Boris Smeds pushed through his test and ended up modifying it on the fly? And does every reader of IEEE Spectrum get the BBC on their TV? (hint, Spectrum has a global circulation)
-- disclaimer, I edited (and did some reporting for) this story.
They did test the accelerometers, using a centrifuge. But the test harness was wired backward too. Didn't read the article did you?
There's certainly a balance to be found between too much testing and too little. But -- as the Columbia Accident Investigation Board report harshly criticised -- at NASA, the pendulum had swung too far from physical testing towards simulation, extrapolation, and pure guess-work.
Let the NASA-bashing thread continue.
NASA does appear to be working on its management issues. But until it proves it has succeded in making significanct progress, it has, sadly, lost the benefit of the doubt. NASA is a public program, and if NASA management or Congress won't provide the requisite oversight, then we should be grateful that people like Oberg (a 22-year NASA veteran) are holding NASA's feet to the fire.
What Oberg is objecting to (and its one of the the things the Columbia Accident investigation board objected too as well) is that NASA has a long history of forgetting lessons learned.
That is why he is holding managements feet to the fire here, as did the CAIB.
And NASA doesn't test everything. In fact, NASA's relience on simulation and extrapolation and just plain guess work was harshly criticized in CAIB report, which is free for anyone to read.
As I posted elsewhere, but I belive it bears repeating:
We're talking about a class of errors that have happened before. We already know about them, they've already been detected. And yet, because of management failure, they continue to persist. The Columbia Accident Board identified this failure as NASA's key problem, not the weakeness of Reinforced Carbon Carbon leading wing edges.
Unknown errors are unavoidable, but ignoring solutions to known errors is unforgivable.
During his 22-years at Mission Control, Oberg's helped design real missions. And just because you think its "nagging" doesn't mean that anyone who gives a damn about the space program, or just good engineering, should ever let up for a second in their demands for engineering and managerial excellence.
Except the problems Oberg describes, including the proximate cause of the Genesis crash, have absolutely nothing to do with environmental conditions in space or anywhere else, but everything to do with mistakes made in nice clean rooms here on Earth, and magnified by poor management, again here on Earth.
Except that Oberg is a 22-year veteran of Mission Control.
Except that everything he's saying here is an echo of what the Columbia Accident Investigation Board said about NASA's manned space program.
Except that, if you'd bother to read the article, you'd see that the criticism is not of "engineer's efforts", but of management.
Except that "are human, and they will do stupid things" is the whole point of Oberg's article, and he's talking about the failure of NASA to provide oversight to catch these inevitable screw-ups.
For anyone wanting to yack about poor performance... put your money where your mouth is. I just get sick of all the constant nagging.
Oberg's helped design real missions. And just because you think its "nagging" doesn't mean that anyone who gives a damn about the space program, or just good engineering, should ever let up for a second in their demands for engineering and managerial excellence.
No-one, least of all Oberg (a 22-year veteran of mission control), is asking NASA to have a 100% success rate. Space is harsh, unknown unkowns lurk, etc.
What is is calling for is a management structure that allows solutions to problems that have occured before to be implemented properly. Columbia was destroyed for almost the same root causes that were exposed after Challanger. I don't think it's unreasonable to expect people to have elimiated those problems, and kept them eliminated.
The Columbia Accident Board had some harsh things to say about "Cheaper, Faster, Better" and NASA technical oversight in general, you should read their report.
No need to sniff derisively in the direction of NASA's "middle management".
We're not talking about some unknown unknowns that crop up as the inevitable residue of your halting problem analogy.
We're talking about a class of errors that have happened before. We already know about them, they've already been detected. And yet, because of management failure, they continue to persist. The Columbia Accident Board identified this as NASA's key problem, not the weakeness of Reinforced Carbon Carbon leading wing edges.
Unknown errors are unavoidable, but ignoring solutions to known errors is unforgivable.
This is hindsite at its best, and is the classic comment by beareaucrats who have no concept of what cutting edge design is about.
You only get to play the hindsight card the first time this kind of screw-up happens. If you actually read the article you'll see that Oberg (who isn't a beauracract but a 22-year veteran of mission control and one of the world'd experts on the Russian space program) is indicting NASA for having a management structure that leads to technical amnesia: the same type of oversight failure keeps happening again and again.
Oberg is not alone in this. The Columbia Accident Report despairingly noted the similities between Columbia and Challanger: both accidents where caused by poor management but what was worse with Columbia was that NASA had failed to really internalise the lessons of Challanger, or heed the warning flags about management and technical problems put up by countless internal and external reports.
Sure, space is hard. But it's not helped by an organization that has institutionalised technical amnesia and abandoned many of its internal checks and balances (at least this was the case at the time of the Columbia report, maybe things have changed).
And if you really want to compare against other agencies, NASA's astronaut bodycount does not compare favorably against the cosmonuat bodycount...
Sadly, your post is a classic comment by slashdotters who have no concept what effective technical management of risky systems looks like. (Hint: not all cutting edge designs get managed the same way. There's a difference between building racing sailboats and spaceships. This is detailed in the Columbia accident report. Read it and get a clue).
from scattered teams that all only check their parts rather than having fully qualified teams that go over the entire vehical.
Your sentiment is correct, but your details are a little off. For example the Saturn V rocket was built by "scattered teams" (and committees were heavily involved, despite the mythology around Von Braun)-- the first stage was built by Boeing, the second by North American, the third by Douglas Aircraft, the Instrument Unit (the control system) by IBM, the LEM by Grumman and the CSM by North American, and so on, all the way down a huge chain of sub-contractors. But Apollo had brilliant technical management: it was pricey, but did do an amazing job of system integration.
It's when you try for cheaper missions that having one team take a spacecraft from design through operation is important: this was done on the Mars Pathfinder mission to great success, but wasn't done on other "Faster, Cheaper, Better" missions, to great falure, as demonstrated by, well, take your pick.
It's easer to administer content based on what you pay. For example, say you want to pay for HBO. All you have to do is call up TWC and subscribe to it. From there, you will instantly have access and will not need a cable guy to come to your home. It's a win-win for everyone.
As a TWC customer in NYC, I could do exactly that when I had an analogue cable box too. Digital had nothing to with it.
The plural of "anecdote" is not data!
.
Even though you acknowledge the overall statistics, you then rely on one person's experiences for choosing not to wear a seatbelt in many circumstances to overrule the statistics.
To see why this is crazy, imagine asking a 1000 people all across the country to toss (fair and balanced) coins. Ask the 500 or so people who get heads to toss again. Ask the 250 or so people who get heads that time to toss again. And so on, through 125, 62, 31, 15, 7, 3, till you're left with 1 person. Now this 1 person has tossed a coin 10 times and it's come up heads every time! [1]
Now if you didn't know much about coin tossing, except a statistic that said they come up tails about 50% of the time, and you only knew that one person, should you believe her if she says "Well, the statistics say tails comes up 50% of the time, but from what I've seen, it's heads all the way!"?
Unless you know of a broad survery of many accident investigators who detect a tendancy for low-speed or low-traffic density accident injuries to be increased in either number or severity because of seat belts, then you must take what you're hearing with a hefty grain of salt, even if what they are saying is 100% true[2]. (By the way, I fail to see the difference in between accidently wrapping oneself around a telephone pole on a busy road vs. a quiet road.)
Don't forget there's an obvious potentail for observer's bias here too: you're not seeing his formal reports, but just the stories he's choosing to share with you in an environment which encourages entertaining conversation, not neccessarily statistically accurate conversation.
In the absence of such of survey, perhaps the best thing is to consider the failure mode you're really concerened about: it's not that wearing a seat belt is bad during the accident, but that you may be trapped afterwards. Put a box cutter or similar within reach, say in the door drawer. If you can't operate the cutter because of unconsciousness or severe injury, well, in your condition, you weren't getting of that car anyway
[1] There's actually a well known stock-market scam which operates in very much this fashion.
[2] The furor over silicone breast implants is another good example: a lot of women honestly reported problems after breast implants, but when all was said and done, their problems were coincidental.
Start with lots of funny, put your serious emotional stuff in right at the optimal time nearer the end, and go out funny.
I think you're onto something: Both, say, Scrubs and The Office (two dissimilar comedy shows that are noted for paying attention to the emotional landscape) have this structure.
Where are you getting your definition of Ethernet? You're not allowed to redefine it to "the definition that makes me right" The actual standard includes the physical layer specifications.
Here's the abstract for 802.3 aka, Ethernet (if you care to bother, you can download the full standard for free, and I've added emphasis here):
IEEE Std 802.3: CSMA/CD Access Method and Physical Layer Specifications. Abstract: The media access control characteristics for the Carrier Sense Multiple Access with Collision Detection (CSMA/CD) access method for shared medium local area networks are described. The control characteristics for full duplex dedicated channel use are also described. Specifications are provided for MAU types 1BASE5 at 1 Mb/s; Attachment Unit Interface (AUI) and MAU types 10BASE5, 10BASE2, FOIRL (fiber optic inter-repeater link), 10BROAD36, 10BASE-T, 10BASE-FL, 10BASE-FB, and 10BASE-FP at 10 Mb/s; Media Independent Interface (MII) and PHY types 100BASE-T4, 100BASE-TX, 100BASE-FX, and 100BASE-T2 at 100 Mb/s; and the Gigabit MII (GMII) and 1000BASE-X PHY types, 1000BASE-SX, 1000BASE-LX, and 1000BASE-CX, which operate at 1000 Mb/s (Gigabit Ethernet) as well as PHY type 1000BASE-T. Repeater specifications are provided at each speed. Full duplex specifications are provided at the Physical Layer for 10BASE-T, 10BASE-FL, 100BASE-TX, 100BASE-FX, 100BASE-T2, and Gigabit Ethernet. System considerations for multisegment networks at each speed and management information base (MIB) specifications and additions to support Virtual Bridged Local Area Networks (VLANs) as specified in IEEE P802.1Q are also provided. Also specified is an optional Link Aggregation sublayer which multiple physical links to be aggregated together to form a single logical link.
Thus, just as a protocol which fits the specifications in 802.3 is known as an "Ethernet protocol", a physical cable which also meets the given specs is correctly known as an "Ethernet cable." Ethernet can not run on "any type of cable" and still be Ethernet. To quote the standard: communication by way of the ISO/IEC 8802-3 [IEEE Std 802.3] Local Area Network requires complete compatibility at the Physical Medium interface (that is, the physical cable interface). The standard describes a number of ways of physical cabling a network together (co-ax, twisted pair, fibre optic), but these must all meet the specs and so be "Ethernet cables."
Now, if you can quote something more authorative than the standard, I love to see it.
Actually, pedant boy, the IEEE 802.3 standard better known as Ethernet, specifies both the physical layer and the transport layer. So to say "Ethernet cable" is perfectly correct, both from the standpoint of commonly accepted usage and the standpoint of people who actually know what they're talking about.