I'm not sure what you consider slow, but using a dual 2.4G desktop at work and going to a 700mhz G3 iBook at home I don't notice a serious performance difference. Or at least I didn't until my hard drive started dying on the iBook.
While numerical benchmarks are great, and they do illustrate the objective performance differences, they aren't necessarily a true measure of reality. Performance to a user is entirely subjective.
I'm not terribly concerned with the majority of the population, but instead the majority of the console gaming population. I suspect that well over 50% of them will in fact acquire HD sets in the next 2 years.
I expect in the general population that HD ownership will be at around 30% in 2 years time.
Hell yes it does. Despite owning an hdtv, I hooked my 360 up to an SDTV first (just this weekend in fact, since I bought it Saturday past) and LOVED how it looked. It blew me away compared to the xbox sitting next to it. I was even comparing a game on both platforms (Burnout: Revenge) and it was stunningly better.
Then I took it up to my LCD and played at 1080i and got blown away again.
Besides which, HDTV prices continue to fall and will for quite a while to come. HDTV is an inevitable reality, and so console makers who AREN'T supporting it now will suffer when it becomes the norm (18-24 months is my guess).
The "weaknesses" in QNX are entirely a result of it being designed for one application and no effort being put into making it good at anything else.
Linus' bizarre rambling about data structures and distributed algorithms has nothing to do with it.
Linux is a swiss-army knife, it does a ton of things and none of them very well. QNX is a boning knife, it does one thing quite well and is crap at most everything else. The only thing they share is having a sharp edge.
As for the stability of your linux box, who the hell cares? Its one random box with anecdotal stability metrics. I can find plenty of counter examples of linux boxes crashing due to badly written drivers, userland software, pieces of the kernel, etc.
"You claim i'm an uninformed pontificator yet you argue this point as well? Good luck; let me know how that works for you. When you get that simple interface logic and everything "working reliably as hell"."
I was giving you the benefit of the doubt. I'm guessing that since you decided to block quote large paragraphs of detailed argument and instead change the subject you have no response. As for the interface logic, I never said simple. I even admitted it'll be more logic (and thus more complexity). However critical sections are HARD, interfaces aren't as hard. If I have roughly the same amount of each, I'll take the less hard stuff instead of the more hard stuff.
"As much as large unix systems are complex as hell to manage. You think a microkernel design will make them easier to manage? This is some really good crack here. 9 times out of 10 on large cluster systems it isn't the kernel that is the problem, 9 times out of 10 it is management. 9 times out of 10 you WANT monolithic in a large cluster. No wonder the drug cartels are doing so well."
Large clusters aren't the debate. We're talking large unix systems, i.e. single large systems. Managing in kernel data and processes is a lot harder than stuff running in userspace with a defined interface. We're talking about the difference between spinlocks/semaphores/mutexes/futexes/etc and a messaging interface.
"What does this has to do with the kernel?"
About as much as anything you said about OSX. Which wouldn't have been relevant anyhow since OSX isn't a microkernel, and only marginally behaves like one.
"It certainly can do. A bolt which is used on buses around the world is in a niche compared to, say, windscreen glass."
While I see your point, and agree to an extent, its a poor metaphor (windscreen glass is a pretty niche application of glass, wouldn't you say?).
My point was to refute the implied "QNX isn't anywhere important" statement rather than the exact meaning of niche.
"But MY computer never crashes (Linux); so what else has it to offer? Security? Got that too." Thats wonderful, and my data center full of linux boxes do crash. Usually because of bad device drivers. As for security, while linux is certainly secure in many respects, it lacks the top to bottom security centric design that is much easier with a microkernel.
"I was under the impression that QNX's real killer feature was its real-time abilities. Isn't that a niche feature? How many people would notice the effect of going from current generation Windows and Linux to a hard-real-time version?"
That is, but this isn't about QNX vs Win/Lin, but instead micro versus monolithic. In this respect people wouldn't the difference either, until they sat back and thought about how often they reboot now compared to before. Its the best sort of upgrade though, the sort you never notice.
Uhm, I'm pretty sure niche doesn't mean exceptionally widely deployed.
QNX is everywhere, you just don't realize it. ATMs run it, lots of medical equipment runs it, lots of other embedded apps that you don't even think of run it.
The examples Andy cites prove that in fact the microkernel concept has won in every single field where stability has gone beyond being something people wanted to something they demand. As soon as the general public realizes computers don't HAVE to crash, they'll win there too.
Its a chicken/egg situation. Until the underlying mechanisms needed for self-healing are there, we won't get self-healing systems. Until the user space code for self-healing is there, nobody thinks its worthwhile to support self-healing mechanisms. Thankfully a few folks realize that if they build it, people will come.
Also, your API metaphor is a little bad. While you're right about the end result, saying that this invalidates the utility of the API is wrong imho. The advantage of having the API remains, because you can always go FIX the userland code. Take away the good API and you become well and truly screwed.
Again, the original point is that you CAN and SHOULD design an operating environment that allows for unforseen user software to be installed, and devices to be supported, without the entire system ever crashing.
Ultimately the user base needs to adjust their expectations and begin demanding that OS vendors supply an OS that meets actual, real world needs. Namely zero crashes.
You would be one of those uninformed pontificators Andy so eloquently railed against.
"For small embedded environments where speed or device support isn't a main concern. Micro-kernels will excel for their stability but take a look around and that's not reality or what we have today. We have lots of different hardware, lots of different interfaces and to manage that all via objects it'll just be extremely large."
And none of that has anything to do with monolithic versus microkernel, except perhaps tangentially. Microkernels do not ask each device driver to be a server all its own with zero code reuse, they use generic servers to wrap drivers for specific hardware while still isolating them from kernel space. This means there's no functional difference to the driver programmer from a monolithic to a microkernel architecture, either way you look at the driver interface and write the necessary code.
"If you think the linux kernel is big the relevant code for this would be numerous times larger. It just pushes the code from the kernel into userspace and you will definitely need more code to manage and access data structure"
Why do you suddenly need more code to the same thing? Andy's point is that when you stop sharing data structures, and instead start passing messages from one discrete server to another through well defined interfaces you reduce the amount of complexity (and therefor code) involved in protecting the coherency of those data structures. You will end up with more interfaces, but thats not necessarily a bad thing. I'd gladly trade all of the critical section protection logic for some nice interface logic. Especially since making the latter work reliably is a hell of a lot easier to do, and gives each subsystem the freedom to rework their internals without requiring me to lift a finger.
"If you can isolate your facets and only plan on supporting X number of devices/platforms/chipsets/etc and don't expect any blazing performance. Microkernels are great. Beyond that? With the rate that technology moves, it just becomes a management nightmare."
There's still no credible evidence to suggest that microkernel performance is that horrible, especially with modern clock speeds. Aside from gaming and large scientific compute clusters, very little being done today on a computer uses any significant measure of their speed. We've already covered how you're totally off base on device support (i.e. its orthogonal to the entire debate), and you throw "management nightmare" out there without bothering to define it, let alone defend it.
Large unix systems are already complex as hell to manage. A lot of that complexity is "hidden" in the kernel, which while fine for desktop users is a big pain for system administrators, and would be exposed for manageability in a microkernel setup.
As for OS X and its performance, its not horribly slow. Especially considering that your complaint almost certainly centers around PPC performance not x86, where it was hampered by lower clock speeds that were not counterbalanced by better IPC in any significant fashion. OS X's memory hunger has little to do with the kernel and lots to do with their operating environment, and all of the gee whiz graphical functionality that OS X brings along with it.
Ultimately though, OSX performance is a success story because on a G3 700mhz with 256M of ram its actually useable. Have you tried running Windows XP on a similar setup? Tried turning all of the eye candy on? Bet you didn't like the way it performed either.
Andy's point is that the button isn't on the dash or visible to the user, simply because the vast majority of drivers will never need to push it. The same, sadly, cannot be said about Windows, Linux or MacOS X.
No, those of us who understand English knew it was infact exactly what he meant.
Unsurprisingly means having a lack of surprise. Not is not negating, but instead clarifying the unsurprising aspect. So what he said was that everybody expected the details to be vague.
I can imagine. Well, at least now I know where that 20% of US electricity from petroleum is going. I am overjoyed to live here in Illinois, otherwise known as the Land of Neutron.
Airbags aren't strictly required to meet NHTSA requirements in the US. You can apply for an "economic hardship" exemption, which I suspect is what Ariel/Brammo did. Several other vehicles of a similar orientation have successfully employed this approach.
Then again, Ferrari is apparently trying it with the F430 and running into problems.
I agree with you, except he's also not making a car for use such as you described. I can only assume, since the article was light on intentions, that he started with the Ariel Atom2 because he simply wanted to design a proof of concept electric club racer. Which is what he has done.
Nobody goes out cruising in a club racer, they go out racing in it. You trailer it to the track, do 20-30 miles worth of laps and then trailer it home. Or you drive the 10-15 miles to the track and do the same back home. Either way 100 miles works out fine.
Besides, for the fun driving if you dial back the performance a bit (I'd be fine with a 0-60 of 5.5 seconds, for example) you can probably extend the range a good bit at which point, problem solved.
You may be contributing more pollution, but you may be contributing less. Depends on the rate of pollution emitted per kWh generated versus pollution emitted per mile travelled with an IC engine.
Somehow I doubt though that your IC engine is as efficient at converting chemical energy to mechanical compared to the petroleum powered electrical generator turning it into heat and subsequently electricity.
Besides, where do you live that your electricity is petroleum generated? The vast majority in the US comes from coal.
I knew you were serious, that's why I replied. Not sure how someone else saw that as funny, but this is/. after all.
I'm not quite sure how they made it street legal, but I'm also not sure it doesn't have an airbag. I do know it uses a 4 point restraint instead of a lapbelt or shoulder harness, perhaps there's a waiver for that?
I do know the body has an integrated roll cage, and that there's a rollover bar in place (club racers all have to have these to satisfy league rules) to protect the drivers head.
Trying to claim that Ariel developing an electric is the same as GM or Honda is a little asinine. Ariel could do it only because they are such a small shop and have intimate knowledge of their platform, and can make any modifications they wish to it. I'm not necessarily saying they should do it, but rather that it seems odd to me that they didn't.
The Ariel Atom doesn't need more than 100M of range, especially not with a mere 4.5 hour recharge time. People don't drive the Atom as a daily driver, its a club racer. Even if you drive it to the track and back, which most folks don't, that 100M range is likely to be enough as your race is going to consume maybe 15-20 miles of that range and few folks would drive more than 20-30 miles one way to go to such an event. Any further and its getting trailered.
Honestly, most people could live with a daily driver with a 100m range and an overnight recharge, as a small percentage of the population drives further than that in their daily commute. The reason they think they couldn't is that marketing has told them so. They've been convinced that they must be able to hop into the car and drive cross country at a moments notice, despite the fact that in todays world if you're going more than 500 miles its likely to be cheaper and faster and more convenient to fly. If people learned that it'd get even cheaper to fly, as you'd have more demand leading to more flights, economies of scale, and so forth.
Yeah, same here. Rich suburbs north of Chicago, I see more Bentleys than I do Hondas.
That also being said, for me a $100k electric car might be affordable whereas a $100k gas powered car certainly wouldn't. I spend $1950/year on gasoline simply to get to and from work. Why? Its 75 miles round trip and I get 30mpg, so I burn roughly 2.5 gallons per day at $3/gallon which is the standard price here.
That works out to almost $200/mo more car payment I can afford if I'm not paying for gas. I do realize I'm paying for the kWh to recharge the batteries, but depending on draw I could potentially deal with that via solar or some other "free" energy source.
I'd also not be buying a $100k electric sports car, but instead something more practical, and therefor I'd probably get a little bit better range and it'd probably also not cost $100k since lower performance generally means lower cost to engineer and build.
The article even indicates he's using off the shelf components. Ariel doesn't make an electric Atom (I can't fathom why), so this guy is filling a gap.
The funny thing that the article fails to notice is that with a 100 mile range and only 4.5 hour recharge (if this guy hits his targets) means this car would be practical as a daily driver for virtually everyone.
Breakage no longer actually refers to cd being broken in transit. Its a generic term generally used to refer to anything that causes loss of product between manufacturing and retail. The largest contributor to breakage is theft, also commonly called shrinkage.
When I worked in a music store years ago, we usually averaged a couple hundred dollars a day in shrinkage. Music stores get hurt by this to, as the stated number (it came from management, take as you will) to recover was $20 in revenue for every $1 in loss. That got you to break even.
What other reason does he need? Are you trying to say that it'd be ok if he was PMS'ing and wrong, since at least PMS is a good reason to insult someone?
Slashdot Mirror
I'm not sure what you consider slow, but using a dual 2.4G desktop at work and going to a 700mhz G3 iBook at home I don't notice a serious performance difference. Or at least I didn't until my hard drive started dying on the iBook.
While numerical benchmarks are great, and they do illustrate the objective performance differences, they aren't necessarily a true measure of reality. Performance to a user is entirely subjective.
I'm not terribly concerned with the majority of the population, but instead the majority of the console gaming population. I suspect that well over 50% of them will in fact acquire HD sets in the next 2 years.
I expect in the general population that HD ownership will be at around 30% in 2 years time.
"The 360 still looks damn good on regular TV"
Hell yes it does. Despite owning an hdtv, I hooked my 360 up to an SDTV first (just this weekend in fact, since I bought it Saturday past) and LOVED how it looked. It blew me away compared to the xbox sitting next to it. I was even comparing a game on both platforms (Burnout: Revenge) and it was stunningly better.
Then I took it up to my LCD and played at 1080i and got blown away again.
Besides which, HDTV prices continue to fall and will for quite a while to come. HDTV is an inevitable reality, and so console makers who AREN'T supporting it now will suffer when it becomes the norm (18-24 months is my guess).
Directly? Nothing.
Indirectly? Very little.
Tangentially? A lot.
The "weaknesses" in QNX are entirely a result of it being designed for one application and no effort being put into making it good at anything else.
Linus' bizarre rambling about data structures and distributed algorithms has nothing to do with it.
Linux is a swiss-army knife, it does a ton of things and none of them very well.
QNX is a boning knife, it does one thing quite well and is crap at most everything else. The only thing they share is having a sharp edge.
As for the stability of your linux box, who the hell cares? Its one random box with anecdotal stability metrics. I can find plenty of counter examples of linux boxes crashing due to badly written drivers, userland software, pieces of the kernel, etc.
"You claim i'm an uninformed pontificator yet you argue this point as well? Good luck; let me know how that works for you. When you get that simple interface logic and everything "working reliably as hell"."
I was giving you the benefit of the doubt. I'm guessing that since you decided to block quote large paragraphs of detailed argument and instead change the subject you have no response. As for the interface logic, I never said simple. I even admitted it'll be more logic (and thus more complexity). However critical sections are HARD, interfaces aren't as hard. If I have roughly the same amount of each, I'll take the less hard stuff instead of the more hard stuff.
"As much as large unix systems are complex as hell to manage. You think a microkernel design will make them easier to manage? This is some really good crack here. 9 times out of 10 on large cluster systems it isn't the kernel that is the problem, 9 times out of 10 it is management. 9 times out of 10 you WANT monolithic in a large cluster. No wonder the drug cartels are doing so well."
Large clusters aren't the debate. We're talking large unix systems, i.e. single large systems. Managing in kernel data and processes is a lot harder than stuff running in userspace with a defined interface. We're talking about the difference between spinlocks/semaphores/mutexes/futexes/etc and a messaging interface.
"What does this has to do with the kernel?"
About as much as anything you said about OSX. Which wouldn't have been relevant anyhow since OSX isn't a microkernel, and only marginally behaves like one.
"It certainly can do. A bolt which is used on buses around the world is in a niche compared to, say, windscreen glass."
While I see your point, and agree to an extent, its a poor metaphor (windscreen glass is a pretty niche application of glass, wouldn't you say?).
My point was to refute the implied "QNX isn't anywhere important" statement rather than the exact meaning of niche.
"But MY computer never crashes (Linux); so what else has it to offer? Security? Got that too."
Thats wonderful, and my data center full of linux boxes do crash. Usually because of bad device drivers. As for security, while linux is certainly secure in many respects, it lacks the top to bottom security centric design that is much easier with a microkernel.
"I was under the impression that QNX's real killer feature was its real-time abilities. Isn't that a niche feature? How many people would notice the effect of going from current generation Windows and Linux to a hard-real-time version?"
That is, but this isn't about QNX vs Win/Lin, but instead micro versus monolithic. In this respect people wouldn't the difference either, until they sat back and thought about how often they reboot now compared to before. Its the best sort of upgrade though, the sort you never notice.
Uhm, I'm pretty sure niche doesn't mean exceptionally widely deployed.
QNX is everywhere, you just don't realize it. ATMs run it, lots of medical equipment runs it, lots of other embedded apps that you don't even think of run it.
The examples Andy cites prove that in fact the microkernel concept has won in every single field where stability has gone beyond being something people wanted to something they demand. As soon as the general public realizes computers don't HAVE to crash, they'll win there too.
Its a chicken/egg situation. Until the underlying mechanisms needed for self-healing are there, we won't get self-healing systems. Until the user space code for self-healing is there, nobody thinks its worthwhile to support self-healing mechanisms. Thankfully a few folks realize that if they build it, people will come.
Also, your API metaphor is a little bad. While you're right about the end result, saying that this invalidates the utility of the API is wrong imho. The advantage of having the API remains, because you can always go FIX the userland code. Take away the good API and you become well and truly screwed.
Again, the original point is that you CAN and SHOULD design an operating environment that allows for unforseen user software to be installed, and devices to be supported, without the entire system ever crashing.
Ultimately the user base needs to adjust their expectations and begin demanding that OS vendors supply an OS that meets actual, real world needs. Namely zero crashes.
You would be one of those uninformed pontificators Andy so eloquently railed against.
"For small embedded environments where speed or device support isn't a main concern. Micro-kernels will excel for their stability but take a look around and that's not reality or what we have today. We have lots of different hardware, lots of different interfaces and to manage that all via objects it'll just be extremely large."
And none of that has anything to do with monolithic versus microkernel, except perhaps tangentially. Microkernels do not ask each device driver to be a server all its own with zero code reuse, they use generic servers to wrap drivers for specific hardware while still isolating them from kernel space. This means there's no functional difference to the driver programmer from a monolithic to a microkernel architecture, either way you look at the driver interface and write the necessary code.
"If you think the linux kernel is big the relevant code for this would be numerous times larger. It just pushes the code from the kernel into userspace and you will definitely need more code to manage and access data structure"
Why do you suddenly need more code to the same thing? Andy's point is that when you stop sharing data structures, and instead start passing messages from one discrete server to another through well defined interfaces you reduce the amount of complexity (and therefor code) involved in protecting the coherency of those data structures. You will end up with more interfaces, but thats not necessarily a bad thing. I'd gladly trade all of the critical section protection logic for some nice interface logic. Especially since making the latter work reliably is a hell of a lot easier to do, and gives each subsystem the freedom to rework their internals without requiring me to lift a finger.
"If you can isolate your facets and only plan on supporting X number of devices/platforms/chipsets/etc and don't expect any blazing performance. Microkernels are great. Beyond that? With the rate that technology moves, it just becomes a management nightmare."
There's still no credible evidence to suggest that microkernel performance is that horrible, especially with modern clock speeds. Aside from gaming and large scientific compute clusters, very little being done today on a computer uses any significant measure of their speed. We've already covered how you're totally off base on device support (i.e. its orthogonal to the entire debate), and you throw "management nightmare" out there without bothering to define it, let alone defend it.
Large unix systems are already complex as hell to manage. A lot of that complexity is "hidden" in the kernel, which while fine for desktop users is a big pain for system administrators, and would be exposed for manageability in a microkernel setup.
As for OS X and its performance, its not horribly slow. Especially considering that your complaint almost certainly centers around PPC performance not x86, where it was hampered by lower clock speeds that were not counterbalanced by better IPC in any significant fashion. OS X's memory hunger has little to do with the kernel and lots to do with their operating environment, and all of the gee whiz graphical functionality that OS X brings along with it.
Ultimately though, OSX performance is a success story because on a G3 700mhz with 256M of ram its actually useable. Have you tried running Windows XP on a similar setup? Tried turning all of the eye candy on? Bet you didn't like the way it performed either.
Andy's point is that the button isn't on the dash or visible to the user, simply because the vast majority of drivers will never need to push it. The same, sadly, cannot be said about Windows, Linux or MacOS X.
No, those of us who understand English knew it was infact exactly what he meant.
Unsurprisingly means having a lack of surprise. Not is not negating, but instead clarifying the unsurprising aspect. So what he said was that everybody expected the details to be vague.
I can imagine. Well, at least now I know where that 20% of US electricity from petroleum is going. I am overjoyed to live here in Illinois, otherwise known as the Land of Neutron.
Airbags aren't strictly required to meet NHTSA requirements in the US. You can apply for an "economic hardship" exemption, which I suspect is what Ariel/Brammo did. Several other vehicles of a similar orientation have successfully employed this approach.
Then again, Ferrari is apparently trying it with the F430 and running into problems.
I agree with you, except he's also not making a car for use such as you described. I can only assume, since the article was light on intentions, that he started with the Ariel Atom2 because he simply wanted to design a proof of concept electric club racer. Which is what he has done.
Nobody goes out cruising in a club racer, they go out racing in it. You trailer it to the track, do 20-30 miles worth of laps and then trailer it home. Or you drive the 10-15 miles to the track and do the same back home. Either way 100 miles works out fine.
Besides, for the fun driving if you dial back the performance a bit (I'd be fine with a 0-60 of 5.5 seconds, for example) you can probably extend the range a good bit at which point, problem solved.
You may be contributing more pollution, but you may be contributing less. Depends on the rate of pollution emitted per kWh generated versus pollution emitted per mile travelled with an IC engine.
Somehow I doubt though that your IC engine is as efficient at converting chemical energy to mechanical compared to the petroleum powered electrical generator turning it into heat and subsequently electricity.
Besides, where do you live that your electricity is petroleum generated? The vast majority in the US comes from coal.
I knew you were serious, that's why I replied. Not sure how someone else saw that as funny, but this is /. after all.
I'm not quite sure how they made it street legal, but I'm also not sure it doesn't have an airbag. I do know it uses a 4 point restraint instead of a lapbelt or shoulder harness, perhaps there's a waiver for that?
I do know the body has an integrated roll cage, and that there's a rollover bar in place (club racers all have to have these to satisfy league rules) to protect the drivers head.
Trying to claim that Ariel developing an electric is the same as GM or Honda is a little asinine. Ariel could do it only because they are such a small shop and have intimate knowledge of their platform, and can make any modifications they wish to it. I'm not necessarily saying they should do it, but rather that it seems odd to me that they didn't.
The Ariel Atom doesn't need more than 100M of range, especially not with a mere 4.5 hour recharge time. People don't drive the Atom as a daily driver, its a club racer. Even if you drive it to the track and back, which most folks don't, that 100M range is likely to be enough as your race is going to consume maybe 15-20 miles of that range and few folks would drive more than 20-30 miles one way to go to such an event. Any further and its getting trailered.
Honestly, most people could live with a daily driver with a 100m range and an overnight recharge, as a small percentage of the population drives further than that in their daily commute. The reason they think they couldn't is that marketing has told them so. They've been convinced that they must be able to hop into the car and drive cross country at a moments notice, despite the fact that in todays world if you're going more than 500 miles its likely to be cheaper and faster and more convenient to fly. If people learned that it'd get even cheaper to fly, as you'd have more demand leading to more flights, economies of scale, and so forth.
Yeah, same here. Rich suburbs north of Chicago, I see more Bentleys than I do Hondas.
That also being said, for me a $100k electric car might be affordable whereas a $100k gas powered car certainly wouldn't. I spend $1950/year on gasoline simply to get to and from work. Why? Its 75 miles round trip and I get 30mpg, so I burn roughly 2.5 gallons per day at $3/gallon which is the standard price here.
That works out to almost $200/mo more car payment I can afford if I'm not paying for gas. I do realize I'm paying for the kWh to recharge the batteries, but depending on draw I could potentially deal with that via solar or some other "free" energy source.
I'd also not be buying a $100k electric sports car, but instead something more practical, and therefor I'd probably get a little bit better range and it'd probably also not cost $100k since lower performance generally means lower cost to engineer and build.
The chassis upon which its based already is street legal in all 50 states.
The article even indicates he's using off the shelf components. Ariel doesn't make an electric Atom (I can't fathom why), so this guy is filling a gap.
The funny thing that the article fails to notice is that with a 100 mile range and only 4.5 hour recharge (if this guy hits his targets) means this car would be practical as a daily driver for virtually everyone.
Breakage no longer actually refers to cd being broken in transit. Its a generic term generally used to refer to anything that causes loss of product between manufacturing and retail. The largest contributor to breakage is theft, also commonly called shrinkage. When I worked in a music store years ago, we usually averaged a couple hundred dollars a day in shrinkage. Music stores get hurt by this to, as the stated number (it came from management, take as you will) to recover was $20 in revenue for every $1 in loss. That got you to break even.
What other reason does he need? Are you trying to say that it'd be ok if he was PMS'ing and wrong, since at least PMS is a good reason to insult someone?
Amusingly, Theo today posted to bugtraq and made a point of pointing out how nice and polite he was being (and he was!).