Saying the Atari Jaguar was "powered" by the 68K is like saying my computer is only 8 bits, because the 8042 controller that talks to the keyboard is 8 bits.
The 68K was an I/O processor - the main processors in the system WERE 64 bits.
And the 68K family were 32 bits from the get-go: address registers, program counter, and data registers were all 32 bits. True, the external bus interface to the world was a 16 bit wide datapath and 24 bit wide address path on the 68000, but the 68020 was a full 32/32 path. And even the 68K itself still used that 16 bit bus to fetch 32 bits of data (2 operations per word).
Do you classify the 386SX a 16 bit part? - because it had the exact same sort of interface to the world - 16 bit data bus, 24 bit address bus.
True, many of the modern video cards incorrectly call themselves 128 or 256 bit devices when the largest single numerical value they can work with is 32 bits or less, but do try to be accurate in what you complain about.
Yes, I do need a 4GHz 64 bit chip for my embedded app.
I do signal processing in communications - I routinely deal with processing signals digitized at anywhere from 300 kSamples/sec to 30MSamples/sec. I have to do parametric calculations (error vector magnitude, modulation fidelity, etc.) that require hundreds of floating point operations per sample - so a 300 kSample/sec stream can burn over 30MFLOPS, and a 30 MSample/sec signal can burn over 3GFLOPS.
And that's just for starters. Then I have to display it, do the protocol analysis, and run the demodulation codecs.
Just because in your limited world you cannot conceive of a need for a chip, do not presume to know the industry - that cell phone you are drooling over needs more processing power than your home town contained ten years ago, and it is only going to get worse.
My point exactly - the only uses of the 68K family are embedded applications - set top boxes, and PDAs - and even the PDAs are moving away from the Dragonball to the StrongArm derivitives.
You DON'T see the 68K being used in computers anymore.
It is such a shame to see good CPU architechtures die, and crap live on.
The Motorola 68K family were a joy to work with - lots of registers, and a very orthoginal instruction set - you could use any A register for pointers, any D register for data - none of this "ECX is for loops, EDI for destination pointer, ESI for source pointer" crap of the x86.
It's dead now, save for use as a microcontroller.
The Alpha was a ass-kicking, name-taking monster. While I never seriously programmed on it, it was 64 bits long before anybody else knew how to spell it - it had well established software and compiler technology. It is STILL one of the leaders.
But for all intents and purposes, it's dead, Jim. Yet Itanic, with an unproven design concept, is flourishing (sorry, having worked with DSPs that implemented the VLIW idea, I have doubts about the real-world performance of VLIW in a multitasking environment).
I was thinking about this on my drive into work this morning, and I came to the conclusion that what we need to do is to change the C style stack usage to use two or three stacks.
Consider: C uses the stack for three types of information: call/return information, parameter passing, and local variable storage. I assert that this is the cause of most of the stack problems in C - you are using the same thing for three different needs.
Let me discuss each of the three uses in turn. I will use x86 terminology for this discussion because that is the primary architecture used for Linux and because that is what I am most familiar with, but you should be able to generalize my points without much problem.
First, you have the call/return stack. This needs to the be CPU stack so that normal CALL/RET operations work. The only things that should be stored here are the actual return addresses, as well as possibly register saves (esp. for interrupt routines). However, in a unified stack design it is possible for the bad guys to modify the return address. Thus, even in a non-executable stack environment I can still change the return address to point to a function, say exec().
Second, you have the parameter passing stack. Ideally the only thing on this stack would be parameters passed down to the function from the caller. However, in a unified stack design, I can modify this stack to contain data - thus I can create a pointer to the string "/bin/bash" on the stack. With this and with the call/return modification above, I can cause the current function to "return" to exec(), with "/bin/bash" as the arg. Boom. Remote shell.
Third, you have local variable storage. If this space were seperate from the other two stacks, then overflowing a local buffer, while still bad, would not be able to modify the return address nor would it be able to create parameters. Ideally, every subroutine would be given its own sparely mapped local space - thus boundary errors would likely throw a page fault (granted, the cost of setting such a mapping up for each subroutine call would be prohibitive, so it is unlikely to happen without some form of hardware acceleration. Perhaps a low/high limit register could be added to the various index functions, such that an access relative to EBP, ESI, EDI would fault if it went out of range.)
However, consider just seperating the stack into three areas, widely seperated. ESP would point to the hardware stack. EBP to the local storage area, and ESI to the parameter block (with EDI pointing to "this" for C++). Now, a bad programmer has a buffer in local storage and doesn't range check it. A would-be exploiter still cannot modify the return address nor can he modify the parameter stack. The most he could do would be to hose the local variable storage (granted, that might still allow him to corrupt the local vars for some other function and perhaps get an exploit that way, but it would be even more difficult).
Granted, to do what I just suggested means throwing out *all* standard libraries, tools, compilers, and so forth - I am not actually suggesting that the x86 family do this! However, for new architectures like Sledgehammer et. al, this might be the time to make such a break.
It is not Apple's fault that there is no quick time for Linux. Sorenson Media control the codec...
Not quite true. Everytime Sorenson has been approached to release their codec for Linux, Sorenson's response has been "Sorry, but our contract with Apple states they have an exclusive right to the codec. You will have to get Apple to agree to a change before we could release it."
Then when you approach Apple, the response is "But it isn't our codec, it is Sorenson's. You will have to talk to them."
In other words, it is a fine game of "Go ask your mother" - each party says that the other party is the one you must ask.
Furthurmore, were Apple to release a binary only Quicktime player, they could work around the whole mess. They have not done so.
While Apple is quite happy to use Free Software where it benefits Apple, they are quite UNWILLING to do anything that does not benefit Apple. Currently, if you want to reliably play Quicktime formatted videos, you must run either Windows or MacOS. Removing that barrier to Linux would create another competitor for the ABM (anything but Microsoft) crowd, which Apple currently has a lock on.
The time_t type must be signed, so that you can represent negative time differences. If you make time_t unsigned, when you try to do things like saying "if this file is older than that file" you will get a very large positive time, rather than a negative time. Not good.
We are seeing problems with off_t growing from 32 to 64 bits. We are also going to see this when we start going to a 64 bit time_t, as well (albeit not as badly - off_t is probably used more than time_t is.)
However, the pain is coming - remember we have only about 35 years before a 64 bit time_t is a MUST.
I'd like to see the major distro venders just "suck it up" and say "off_t and time_t are 64 bits. Get over it."
Sure, it will cause a great deal of disruption. So did the move from aout to elf, the move from libc to glibc, etc.
OK, perhaps I need more coffee this morning, but I cannot see how TRACE would be used to cause harm - perhaps somebody can post this in simple terms.
As I understand it:
1) My browser requests a page from www.evilhaxor.org. 2) ?????? 3) My browser sends a TRACE request to slashdot.org. 4) slashdot.org sends back to my browser my cookie data. 5) ???? 6) My browser sends ????? to www.evilhaxor.org. 7) ???? 8) Profit!
OK, sorry, but having more than one ???? is sufficient to make a plan unworkable.
Besides, I run with Javascript off - so I guess the only real exploitable would be the Flash plugin (damn I will be glad when this bug is fixed!)
I REALLY don't want some dumb fake "control panel" poping up over my video when in full screen.
What I want is a simple menu bar across the top of the screen (which, for letterboxed videos, is unused anyway) that appears when I right-click, and disappears when I right-click again, or after a programmed timeout.
And if I directly use the hot-key to do something, then a brief, tasteful OSD to show that it happened is just perfect.
Please DON'T mod me up - I've already taken 2 "-1 Overrated"'s as it is!
It's just not fair - Overrated and Underrated are more like Metamoderations, but MY karma takes the hit!;^)
Also, I don't believe Overrated and Underrated are ever meta-moderated, so they are abused by people as a means to mod-down those with whom the moderator disagrees without fear of metamoderation.
PLEASE! DON'T MOD ME PAST 3!
(Warning - this post contained humor. Those who are humor impaired should seek medical advice before consuming this post)
Finally, somebody who else who is unafraid to point out the stupidity of the interfaces being foisted upon us!
Look, folks - your program is NOT a physical device I can stack in my equipment rack - DON'T MAKE IT LOOK LIKE ONE! It is a PROGRAM! Make it look like a program! I want a simple menu bar across the top of the window. I want that menu bar to follow accepted standard practice - File, Options, Help. I want a minimum of BS - just play the DAMN FILE!
ANTYTHING that increases the tax burden on the average person has a harm associated with it. It may also have a good, but there IS a harm to it as well. Remember, taxes are moneys taken from you by force if necessary and spent on items that you did not choose to spend it on.
Back when government did as little as possible the harm taxes caused were less than the good they did. That is no longer the case, as government grows larger and starts doing things that are not in the common interest.
It is therefor the duty of every citizen to see to it that the government gets as little tax money as legally possible.
Giving more money to the government because they are having a budget shortfall is like buying an achoholic a drink because his glass is empty - it might seem like a charitable thing to do, but it really is harmful.
NOTA BENE - I am not a "Business is Good/Goverment is Stupid" sort of person. I don't like big business any more than I like big government - I like small businesses and local government, because they tend to be more responsive to the individual. That is why taxing interstate commerce, be it done via the Internet, via the mail, via the telephone, or via carrier pideons is a BAD THING - it discourages local government and benefits larger governmental bodies.
Hey
Twiki, how do you connect to the 'Net wirelessly?
Easy, Buck - CDPD CDPD CDPD CDPD
This is a lot like CDPD (Cellular Digital Packet Data), which was supposed to work over existing AMPS networks. It had the same basic problems - you had to update the cell site to make it work, and the cell carriers had to set aside some bandwidth for it.
However, unlike when CDPD was first rolled out, there is now a demand for such services....
Frequently, people will cut & paste the function definition into the header as the function prototype, thus removing the variable names from both helps make it clear that the variables are unused.
Any system that has a "master key" to allow access - be it a physical lock on a door, a backdoor to a program, a key-escrow system, whatever, allows this kind of attack - get the master key, game over.
I had do design an encryption system to manage software options in a piece of gear I designed. I thought about having a "back-door" to enable options on any unit, the better to test software. I quickly abandoned that idea - let the master key get out, and it's game over. Sure, it may make my life slightly more difficult as a developer, but it also means that no one, not even me, can cheat the system.
When I had to write the system up for export permission, I described it in detail - algorithm, file formats, I even had to include the source code for the relevant sections. I suppose you could get that information with a FOIA request. Knock yourself out - if you don't have the private key of the keypair, you won't be able to create the options file.
Say it with me, kids - "master keys and back doors are BAD - JUST SAY NO!"
If a line of code doesn't exists, then it cannot contain a bug.
Like more aphorisms, you can argue this, but my point is this - every line of code in a program is a potential bug. Every line of code requires a bit more grey matter to process, making your code just that much more difficult to understand, debug, and maintain.
So I ruthlessly remove dead code. Often, I'll see big blocks like this:
And I will summarily remove them. "But they were there for archival purposes - to show what was going on" some will say. Bullshit! If you want to say what didn't work, describe it in a comment. As for preserving the code itself - that is what CVS is for!
By stripping the code down to the minimum number of lines, it compiles faster, it checks out of and in to CVS faster, and it is easier to understand and maintain.
And I will recode it thus: void foo_bar(int , int ) {
}
That silences the "unused variable" warning, and makes it DAMN clear in the prototype that the function will never use those parameters. (True, you cannot do this in C.)
Code should be a lean, mean state machine - no excess fat. (NOTE - this does NOT me remove error checking, #assert's, good debugging code, or exception handlers).
I worked on an industrial robot many years ago - its purpose was to cut components to a specified length.
Due to the resolution of the stepping motor that controlled the cutter, the resulting component lengths, when plotted, were a uniform distribution - for length N-(delta/2) to N+(delta/2), where N was the desired length, and delta the minimum step distance. Within that range, all lengths were equally probable.
The customer got angry, because he needed a less than 1ppm out of tolerance rate (tolerance was about 5*delta), and by his calculations we failed.
His calculations? Measure 100 parts, compute sigma, is 6*sigma < tolerance?
The problem is, the equation P(n:n6*sigma) ~ 10^-6 only holds true for a Gausian (a.k.a. normal) distribution (in other words, probability of x, given x is more than 6 sigma from mean, is less than 1 part per million only for a Gausian curve).
Asserting that if you meet 6 sigma, you will be less than 1ppm only holds true for a Gausian curve.
So to apply this to something without first demonstrating that the something follows a Gausian curve is WRONG.
In my case, the failure rate was so very much less than 1ppm it was pathetic, but since this person did not understand the statistical relationships he was trying to apply, he caused us no end of grief.
Slashdot Mirror
Saying the Atari Jaguar was "powered" by the 68K is like saying my computer is only 8 bits, because the 8042 controller that talks to the keyboard is 8 bits.
The 68K was an I/O processor - the main processors in the system WERE 64 bits.
And the 68K family were 32 bits from the get-go: address registers, program counter, and data registers were all 32 bits. True, the external bus interface to the world was a 16 bit wide datapath and 24 bit wide address path on the 68000, but the 68020 was a full 32/32 path. And even the 68K itself still used that 16 bit bus to fetch 32 bits of data (2 operations per word).
Do you classify the 386SX a 16 bit part? - because it had the exact same sort of interface to the world - 16 bit data bus, 24 bit address bus.
True, many of the modern video cards incorrectly call themselves 128 or 256 bit devices when the largest single numerical value they can work with is 32 bits or less, but do try to be accurate in what you complain about.
1983. Billy Joel, "Only the Good Die Young,"
Billy Joel was singing this before Metallica existed.
Until you get a few more years under you belt, I would suggest you keep in mind the old adage "Children should be seen and not heard".
Yes, I do need a 4GHz 64 bit chip for my embedded app.
I do signal processing in communications - I routinely deal with processing signals digitized at anywhere from 300 kSamples/sec to 30MSamples/sec. I have to do parametric calculations (error vector magnitude, modulation fidelity, etc.) that require hundreds of floating point operations per sample - so a 300 kSample/sec stream can burn over 30MFLOPS, and a 30 MSample/sec signal can burn over 3GFLOPS.
And that's just for starters. Then I have to display it, do the protocol analysis, and run the demodulation codecs.
Just because in your limited world you cannot conceive of a need for a chip, do not presume to know the industry - that cell phone you are drooling over needs more processing power than your home town contained ten years ago, and it is only going to get worse.
My point exactly - the only uses of the 68K family are embedded applications - set top boxes, and PDAs - and even the PDAs are moving away from the Dragonball to the StrongArm derivitives.
You DON'T see the 68K being used in computers anymore.
Jay Leno is sleeping with a loaded shotgun.
Just in case.
It is such a shame to see good CPU architechtures die, and crap live on.
The Motorola 68K family were a joy to work with - lots of registers, and a very orthoginal instruction set - you could use any A register for pointers, any D register for data - none of this "ECX is for loops, EDI for destination pointer, ESI for source pointer" crap of the x86.
It's dead now, save for use as a microcontroller.
The Alpha was a ass-kicking, name-taking monster. While I never seriously programmed on it, it was 64 bits long before anybody else knew how to spell it - it had well established software and compiler technology. It is STILL one of the leaders.
But for all intents and purposes, it's dead, Jim. Yet Itanic, with an unproven design concept, is flourishing (sorry, having worked with DSPs that implemented the VLIW idea, I have doubts about the real-world performance of VLIW in a multitasking environment).
As Billy Joel said, "Only the good die young...."
I was thinking about this on my drive into work this morning, and I came to the conclusion that what we need to do is to change the C style stack usage to use two or three stacks.
Consider: C uses the stack for three types of information: call/return information, parameter passing, and local variable storage. I assert that this is the cause of most of the stack problems in C - you are using the same thing for three different needs.
Let me discuss each of the three uses in turn. I will use x86 terminology for this discussion because that is the primary architecture used for Linux and because that is what I am most familiar with, but you should be able to generalize my points without much problem.
First, you have the call/return stack. This needs to the be CPU stack so that normal CALL/RET operations work. The only things that should be stored here are the actual return addresses, as well as possibly register saves (esp. for interrupt routines). However, in a unified stack design it is possible for the bad guys to modify the return address. Thus, even in a non-executable stack environment I can still change the return address to point to a function, say exec().
Second, you have the parameter passing stack. Ideally the only thing on this stack would be parameters passed down to the function from the caller. However, in a unified stack design, I can modify this stack to contain data - thus I can create a pointer to the string "/bin/bash" on the stack. With this and with the call/return modification above, I can cause the current function to "return" to exec(), with "/bin/bash" as the arg. Boom. Remote shell.
Third, you have local variable storage. If this space were seperate from the other two stacks, then overflowing a local buffer, while still bad, would not be able to modify the return address nor would it be able to create parameters. Ideally, every subroutine would be given its own sparely mapped local space - thus boundary errors would likely throw a page fault (granted, the cost of setting such a mapping up for each subroutine call would be prohibitive, so it is unlikely to happen without some form of hardware acceleration. Perhaps a low/high limit register could be added to the various index functions, such that an access relative to EBP, ESI, EDI would fault if it went out of range.)
However, consider just seperating the stack into three areas, widely seperated. ESP would point to the hardware stack. EBP to the local storage area, and ESI to the parameter block (with EDI pointing to "this" for C++). Now, a bad programmer has a buffer in local storage and doesn't range check it. A would-be exploiter still cannot modify the return address nor can he modify the parameter stack. The most he could do would be to hose the local variable storage (granted, that might still allow him to corrupt the local vars for some other function and perhaps get an exploit that way, but it would be even more difficult).
Granted, to do what I just suggested means throwing out *all* standard libraries, tools, compilers, and so forth - I am not actually suggesting that the x86 family do this! However, for new architectures like Sledgehammer et. al, this might be the time to make such a break.
Not quite true. Everytime Sorenson has been approached to release their codec for Linux, Sorenson's response has been "Sorry, but our contract with Apple states they have an exclusive right to the codec. You will have to get Apple to agree to a change before we could release it."
Then when you approach Apple, the response is "But it isn't our codec, it is Sorenson's. You will have to talk to them."
In other words, it is a fine game of "Go ask your mother" - each party says that the other party is the one you must ask.
Furthurmore, were Apple to release a binary only Quicktime player, they could work around the whole mess. They have not done so.
While Apple is quite happy to use Free Software where it benefits Apple, they are quite UNWILLING to do anything that does not benefit Apple. Currently, if you want to reliably play Quicktime formatted videos, you must run either Windows or MacOS. Removing that barrier to Linux would create another competitor for the ABM (anything but Microsoft) crowd, which Apple currently has a lock on.
The time_t type must be signed, so that you can represent negative time differences. If you make time_t unsigned, when you try to do things like saying "if this file is older than that file" you will get a very large positive time, rather than a negative time. Not good.
We are seeing problems with off_t growing from 32 to 64 bits. We are also going to see this when we start going to a 64 bit time_t, as well (albeit not as badly - off_t is probably used more than time_t is.)
However, the pain is coming - remember we have only about 35 years before a 64 bit time_t is a MUST.
I'd like to see the major distro venders just "suck it up" and say "off_t and time_t are 64 bits. Get over it."
Sure, it will cause a great deal of disruption. So did the move from aout to elf, the move from libc to glibc, etc.
Let's just get it over with.
Are the floaters in my eyes getting too big, or did the whole write-up completely fail to give any sort of suggested price for this thing?
Great - so now we can get morons suffering from the 3psi actual pressure (extreme oxygen deprivation) scribbling "FP from Everest!"
I prefer this sort of mountain climbing.
OK, perhaps I need more coffee this morning, but I cannot see how TRACE would be used to cause harm - perhaps somebody can post this in simple terms.
As I understand it:
1) My browser requests a page from www.evilhaxor.org.
2) ??????
3) My browser sends a TRACE request to slashdot.org.
4) slashdot.org sends back to my browser my cookie data.
5) ????
6) My browser sends ????? to www.evilhaxor.org.
7) ????
8) Profit!
OK, sorry, but having more than one ???? is sufficient to make a plan unworkable.
Besides, I run with Javascript off - so I guess the only real exploitable would be the Flash plugin (damn I will be glad when this bug is fixed!)
Weren't XFree supposed to release V4.3 of XFree86 at this show?
No, I don't want a menu poping up over my app.
I REALLY don't want some dumb fake "control panel" poping up over my video when in full screen.
What I want is a simple menu bar across the top of the screen (which, for letterboxed videos, is unused anyway) that appears when I right-click, and disappears when I right-click again, or after a programmed timeout.
And if I directly use the hot-key to do something, then a brief, tasteful OSD to show that it happened is just perfect.
Please DON'T mod me up - I've already taken 2 "-1 Overrated"'s as it is!
;^)
It's just not fair - Overrated and Underrated are more like Metamoderations, but MY karma takes the hit!
Also, I don't believe Overrated and Underrated are ever meta-moderated, so they are abused by people as a means to mod-down those with whom the moderator disagrees without fear of metamoderation.
PLEASE! DON'T MOD ME PAST 3!
(Warning - this post contained humor. Those who are humor impaired should seek medical advice before consuming this post)
Finally, somebody who else who is unafraid to point out the stupidity of the interfaces being foisted upon us!
Look, folks - your program is NOT a physical device I can stack in my equipment rack - DON'T MAKE IT LOOK LIKE ONE! It is a PROGRAM! Make it look like a program! I want a simple menu bar across the top of the window. I want that menu bar to follow accepted standard practice - File, Options, Help. I want a minimum of BS - just play the DAMN FILE!
Consider this:
Sombody creates a content distribution system.
That somebody creates a means of rating content providers to prevent poor content from flooding the system.
Yes, that will work....
NOT.
ANTYTHING that increases the tax burden on the average person has a harm associated with it. It may also have a good, but there IS a harm to it as well. Remember, taxes are moneys taken from you by force if necessary and spent on items that you did not choose to spend it on.
Back when government did as little as possible the harm taxes caused were less than the good they did. That is no longer the case, as government grows larger and starts doing things that are not in the common interest.
It is therefor the duty of every citizen to see to it that the government gets as little tax money as legally possible.
Giving more money to the government because they are having a budget shortfall is like buying an achoholic a drink because his glass is empty - it might seem like a charitable thing to do, but it really is harmful.
NOTA BENE - I am not a "Business is Good/Goverment is Stupid" sort of person. I don't like big business any more than I like big government - I like small businesses and local government, because they tend to be more responsive to the individual. That is why taxing interstate commerce, be it done via the Internet, via the mail, via the telephone, or via carrier pideons is a BAD THING - it discourages local government and benefits larger governmental bodies.
One of the (dis)advantages of being immortal is cluttering one's mind up with triva like this.
This is a lot like CDPD (Cellular Digital Packet Data), which was supposed to work over existing AMPS networks. It had the same basic problems - you had to update the cell site to make it work, and the cell carriers had to set aside some bandwidth for it.
However, unlike when CDPD was first rolled out, there is now a demand for such services....
Frequently, people will cut & paste the function definition into the header as the function prototype, thus removing the variable names from both helps make it clear that the variables are unused.
Any system that has a "master key" to allow access - be it a physical lock on a door, a backdoor to a program, a key-escrow system, whatever, allows this kind of attack - get the master key, game over.
I had do design an encryption system to manage software options in a piece of gear I designed. I thought about having a "back-door" to enable options on any unit, the better to test software. I quickly abandoned that idea - let the master key get out, and it's game over. Sure, it may make my life slightly more difficult as a developer, but it also means that no one, not even me, can cheat the system.
When I had to write the system up for export permission, I described it in detail - algorithm, file formats, I even had to include the source code for the relevant sections. I suppose you could get that information with a FOIA request. Knock yourself out - if you don't have the private key of the keypair, you won't be able to create the options file.
Say it with me, kids - "master keys and back doors are BAD - JUST SAY NO!"
Like more aphorisms, you can argue this, but my point is this - every line of code in a program is a potential bug. Every line of code requires a bit more grey matter to process, making your code just that much more difficult to understand, debug, and maintain.
So I ruthlessly remove dead code. Often, I'll see big blocks like this:
#ifdef old_way_that_doesnt_work_well
blah;
blah;
blah;
#endif
And I will summarily remove them. "But they were there for archival purposes - to show what was going on" some will say. Bullshit! If you want to say what didn't work, describe it in a comment. As for preserving the code itself - that is what CVS is for!
By stripping the code down to the minimum number of lines, it compiles faster, it checks out of and in to CVS faster, and it is easier to understand and maintain.
I will often see the following in C++ code:
void foo_bar(int unused1, int unused2)
{
unused1 = unused1;
unused2 = unused2;
}
And I will recode it thus:
void foo_bar(int , int )
{
}
That silences the "unused variable" warning, and makes it DAMN clear in the prototype that the function will never use those parameters. (True, you cannot do this in C.)
Code should be a lean, mean state machine - no excess fat. (NOTE - this does NOT me remove error checking, #assert's, good debugging code, or exception handlers).
I worked on an industrial robot many years ago - its purpose was to cut components to a specified length.
Due to the resolution of the stepping motor that controlled the cutter, the resulting component lengths, when plotted, were a uniform distribution - for length N-(delta/2) to N+(delta/2), where N was the desired length, and delta the minimum step distance. Within that range, all lengths were equally probable.
The customer got angry, because he needed a less than 1ppm out of tolerance rate (tolerance was about 5*delta), and by his calculations we failed.
His calculations? Measure 100 parts, compute sigma, is 6*sigma < tolerance?
The problem is, the equation P(n:n6*sigma) ~ 10^-6 only holds true for a Gausian (a.k.a. normal) distribution (in other words, probability of x, given x is more than 6 sigma from mean, is less than 1 part per million only for a Gausian curve).
Asserting that if you meet 6 sigma, you will be less than 1ppm only holds true for a Gausian curve.
So to apply this to something without first demonstrating that the something follows a Gausian curve is WRONG.
In my case, the failure rate was so very much less than 1ppm it was pathetic, but since this person did not understand the statistical relationships he was trying to apply, he caused us no end of grief.