So how exactly does this become "Microsoft mean to blind users!"
MS is mean to all users. Blind users are users. MS is mean to blind users.
The simple business logic is that MS has an opportunity to gain and retain customers by supporting ODF. The not-so-simple logic is that if they support ODF, they will be undermining their practice of profiting from lock-in.
Mean is a lousy word. It's probably more accurate to say that MS's long-term marketing goals are in opposition to the needs of their customers. Either way, it's a sure sign of a broken company.
You should not dismiss the concept of Open Source software as a "silly doctrinaire reason". The economic impact of adopting proprietary software could be enormous and long-lasting. It's critical that this technology be sustainable in the long term without dependence on a single foreign entity.
Apple could easily be gone in ten years, but there will be a continuity of Open Source software until the next ice age.
Gee thanks, Bill, for telling us what we're legally allowed to do with the product we bought from you.
Take your useless support and shove it. We bought the right to use your rotten code, we bought the right to resell it for whatever we can get. We're Americans you fascist SOB.
You may be the richest man on Earth, but you're still a lying, cheating, two-faced, fuckwad... And your mother drinks elderberry wine. You have earned the right to be first at the guillotine.
"The problem is you don't appear to be using the term "latency" in a meaningful or consistent fashion."
Latency is the time the program has to wait for a minimal amount of data, i.e. a one-byte request. It includes the time it takes to dispatch the command, the time it takes the head to position itself and settle at the correct cylinder, the time it takes for the platter to rotate to the beginning of the target sectors and whatever bus latencies are involved. That's for a single request. The thing that you seem to be missing is that the latency also includes the time waiting for earlier requests to be serviced (even without considering xfer time).
"That doesn't make it correct. Indeed, whoever wrote that Wikipedia article has the same problems with terminology and assumptions you do."
It's a better source than any you have bothered to find.
"Consider the scenario where you have a three-disk RAID0, with a 64kb chunk size. A request for 140kb is made, and conveniently enough, is contained in chunks on all three disks. So they are able to operate in parallel and provide maximum benefit."
In the cases where the single disk can fetch the 140k with a single seek, it will be faster on average than the 3-way raid-0. But a request that requires >1 seek on the single disk will have a shorter latency when distributed across >1 disks. Three requests for chunks that only require a single seek on a single disk can be handled simultaneously, each with the same average latency as the single disk.
"Here is another way to think about it. By your reasoning, a RAID1 made up of eight disks with an 8ms latency would have an average latency of 1ms. Do you seriously believe if you benchmark an eight-disk RAID1 you'll get an average seek time of 1ms ?"
The mistake you're making is not looking at the workload as a whole.
Take 8 random requests and submit them to single disk. I'd expect to wait (on average) 64ms for them all to complete. Now submit them to an 8-way RAID-1. I wouldn't expect any of them to complete in 1ms. That's not what I've been saying. But I would expect them to complete in 8ms. So instead of 64ms/8 requests, I'd have 8ms/8 requests.
It's more about statistics than physics.
Your point about writes versus reads is well understood. Parity RAID is very slow to write, and mirrors will also increase the average latency. RAID-0 however provides the same speedup on writes as it does on reads.
You're right in not expecting specialized support on your modified code, but I think you left out some important points.
If you find a bug in a customized program, you try to reproduce it on a stock version. If it exists, you submit a bug report against that. It's their bug, completely.
If you modified the code, then you should be able to determine if the modifications are working as expected. If not, it's your bug.
Maybe you have shared your modifications with others who can help. Maybe it has already been merged into the standard codebase.
Even when it's not possible to reproduce the bug due to logistical contraints, or to determine whose fault it is, the vendor should still listen to the problem and offer guidance on how to isolate the problem.
"I never suggested a single drive will always offer better overall performance than a RAID array. Merely that it will have better latency."
I wasn't trying to imply that you had made that suggestion. Just to be clear, this whole discussion has been about latencies, not transfer rates.
"Huh ? Perfectly balanced, parallelisable IO (as per your RAID1 and "checkout" examples) is about as "best case" as you can get when talking about RAID IO."
With RAID-1 it doesn't matter that the requests are balanced. a two-way mirror gives a 2x improvement in average latency. Make it a 3-way mirror, and you'll have a 3x improvement.
With RAID-0, the balance of requests does matter. Assume two disks, one containing even block numbers, the other containing odds. If the requests are pathological, i.e. all odds, the improvement will be 0. But if *any* of the requests are even, then there's an improvement.
I only jumped into this thread because you were modded informative for saying:
"RAID improves throughput, but not latency. If you need low latency, you need high-RPM drives and no amount of RAID will help you."
High-RPM (and fast head servos) are important, I never said otherwise. but improvements in those areas come incrementally. Many systems already have the fastest disks available, yet the demand for faster disk service persists and RAID satisfies that demand.
Wikipedia backs up what I have said. Please read what it says.
"You can do all the seeks in parallel, but without spinding locking, you're gonna need to wait longer (on average) for the sectors you need to rotate under the heads, because you're going to need every read to rotate under the heads, not just half of them."
Almost right.
"you're going to need every read to rotate under the heads"
But they're spinning in parallel. The average time it takes for a sector on one disk to reach the head is 1/2 of a revolution. The average time it takes for two sectors on separate disks to reach their heads is still 1/2 of a revolution. The point I'm making is that in that 1/2 rev, you have performed two operations instead of one.
"I guess in theory with RAID 1 you only have to wait for the first sector of each pair to come under the head. If controllers do that, good on them."
Any controller worth its salt will do this. Implementations aside, it's a natural property of RAID that it's *possible*. That's why I hate hearing people using the bogus rule-of-thumb "RAID doesn't improve latency.
When reading both disks can be accessed independently. Like RAID 0 the average seek time is reduced by half when randomly reading but because each disk has the exact same data the requested sectors can always be split evenly between the disks and the seek time remains low. The transfer rate would also be doubled. For three disks the seek time would be a third and the transfer rate would be tripled.
It goes on to say: The only limit is how many disks can be connected to the controller and its maximum transfer speed. Most IDE RAID 1 cards use a broken implementation and only read from one disk so their read performance is that of a single disk.
So maybe the rule of thumb should be "broken RAID does not improve latency".
"There's typically a lot more to disk access than perfectly parallelisable disk reads."
"The problem is you are taking your hypothetical, best-case scenario and treating it as the general case."
I did not show the best case nor did I treat it as the general case. I used one of the simplest cases to illustrate my point.
"So, I suppose in a manner of speaking "latency" has been reduced (in that you're waiting less)"
You're almost there.
"but it's not because the latency of the disk operations has improved, it's because the throughut has improved."
No, it's a latency issue. It has nothing to do with throughput, by which I assume you mean transfer rate. Consider the case where each read is for a single byte, or in my analogy, each shopper has a single item. Throughput doesn't matter, it's latency.
You're correct in saying that the more knowledge the RAID controller ( whether it be hardware or software ) has about the data, the more it can optimize performance, but it's only in the patholgical cases where there will be no improvement.
You're also right to say that quicker disks are a win. But even the fastest disk in the world can be easily swamped by a large number of requests.
"the rule of thumb that RAID doesn't really help with latency applies to all of them"
All of them? You started off by saying that I gave "the one" example of RAID reducing the overall latency of multiple reads. Well, it's not the only one. RAID-0 will give the same result unless the data is pathological somehow, e.g. it clashes with some other interleaving scheme.
I understand what you're saying about the independence of checkout lanes, but it's the same as having a fairly uniform distribution of read requests (across the range of blocks in the volume). A hotspot in the data is similar to having just one checkout lane that accepts checks. Everyone in the store who is paying by check will experience a higher latency. But anyone who has cash will still benefit by the extra lanes.
More spindles == faster service. Naturally, quick drives are also a critical factor, but it's not always possible to upgrade to a quicker drive.
I suspect that the reason so many people think that RAID doesn't reduce latency is that they're using braindead controllers. I've seen plenty of them that are too stupid to even load balance across mirrors, the simplest case.
"Your analogy sucks. Not only is the scenario of people being served at checkouts talking about completely independent operations, but that independence also allows for performance hotspots (ie: longer queues in a particular aisle) to be avoided. Accesses to a RAID array exhibit neither of these characteristics."
The analogy works well. You just seem to be overlooking the obvious. Take mirrored RAID as an example. Assume the system needs to read 100 separate chunks of data. With a single disk, it must wait for 100 seeks (100 people in a single checkout lane), With two disks (lanes), the reads (checkouts) happen in parallel, so the system only waits for 50 seeks.
That's why it IS a myth that RAID doesn't improve latency. It won't improve the best case, but it will improve the average. It's sysadmin 101 that you add spindles when the transaction load gets high. Whether you spread the load at the filesystem level or at the block level doesn't matter, as long as it allows two disks to work at the same time.
A log disk will probably be dedicated to that single purpose, so as far as that particular storage system is concerned, it's just single-tasking.
There's still a potential benefit though. Some transactions will fall at the end of a cylinder, requiring a second seek. Others will be large enough that they will also require extra seeks. If the log were being written to RAID stripes, a two-seek transaction could be done with half the latency.
But like I said, the benefits vary with data access patterns. A log file is just a pathologically bad case.
The only case in which RAID does not improve latency is that of a single tasking system.
The latency that's important for a multitasking system is the time an application has to wait for its data, not the time it takes the disk to process a single request. The benefits vary depending an access patterns, array geometries and RAID level.
Having more drives simply means there's a better chance that some requests can be handled in parallel. Your claim is akin to saying that people won't have to wait longer at the supermarket checkout when only one lane is open.
No, you have it wrong. The artist's woofer wasn't large enough (and probably wasn't baffled properly). It wasn't a woofer at all, just a moving cone.
It's all about creating enough air pressure to be felt/heard. A 12" fan can move much more air than a wall full of 12" cones.
The limitation of most acoustical drivers is that by design, they need to reciprocate and most of the power is wasted in accelerating and decelerating mass. The best analogy I can think of is that of a modern helicopter compared to that old learning-to-fly contraption with the beach umbrella on top.
They're (they == you know who) are simply asking for too much money. The only reason they haven't been selling this stuff already is that it used to cost too much (fixed + variable) to distribute the bits.
My ass wasn't born yesterday, so I'm gonna pull a number out of it and say that distribution costs have gone down by a factor of 100 since the VHS days (vs bittorrent).
I don't care about fancy menus and stupid commentary tracks. Spare me the pleasantries. Just lemme put the shows on my shelf and i'll give you some buckos. WTF do they need ITunes for? They have the bits, I have the money. We're only as far away as a google search, a URL, and a credit card number. Make it happen at my price and I'll donate a MythTv plugin. Kudos to Steve Jobs for interposing his company as another layer of needless markups.
I recently STOLE the first two seasons of "WKRP", a better than average 70's US sitcom. You can't buy it, largely do to the fact that it contained so much copyrighted music. The way I see it, they're all so busy trying to screw each other they're neglecting their own core business.
I'd happily send someone $15 if they would make an "honest man" out of me for those 50 episodes, but it won't happen. They're too greedy. C'est la guerre.
Here's an idea (all rights reserved), make a "reality" tv show about maximizing viewer satisfaction and distributor profits by efficiently distributing the product.
If you think that voting for one of the two major candidates is a waste, then vote for one of the minors. He won't win, but his viability will be increased for the next go round.
I'm a Massachusetts conservative, so I'd be hard pressed to vote for Kerry. But there was no way in hell that I was going to vote for the devil Bush, and even if I had, it wouldn't have done any good. I felt that the only way to make my vote count for anything was to vote for a third party.
Another point I'd like to make here is that corruption and incompetence come in all different shapes and sizes. If I had been living in one of the closely contested states, I'd have voted for the lesser of the two evils, namely Kerry.
The saddest thing is that America at large is waking up to the fact that the Bush administration is nfg, but it's too late. The damage has been done. Still, I can hope that he comes tumbling down with Cheney, Rove, and Libbey and that the nation learns that the Bush family cannot be trusted. They've been fucking us over for three generations.
"INCLUDING WITHOUT LIMITATION ANY "ADDON" OR "MOD," THAT IN BLIZZARD ENTERTAINMENT'S SOLE DETERMINATION:..."
It seems to me that this means it applies not only to the enumerated items, but to whatever they say it applies to. I don't think that you should be telling people that they have nothing to worry about.
"No programming, no modularity, no general problem solving."
Programming was done by selecting and arranging gears. Modularity was accomplished by adding layers, coupling the shafts from one layer to another. I'd even go so far as to say that it's general purpose in the sense of an "Erector Set".
Differential gears make this device far more interesting than any other mechanical clockwork I've ever seen.
Slashdot Mirror
So how exactly does this become "Microsoft mean to blind users!"
MS is mean to all users.
Blind users are users.
MS is mean to blind users.
The simple business logic is that MS has an opportunity to gain and retain customers by supporting ODF. The not-so-simple logic is that if they support ODF, they will be undermining their practice of profiting from lock-in.
Mean is a lousy word. It's probably more accurate to say that MS's long-term marketing goals are in opposition to the needs of their customers. Either way, it's a sure sign of a broken company.
They rejected OSX in favor of a better solution.
You should not dismiss the concept of Open Source software as a "silly doctrinaire reason". The economic impact of adopting proprietary software could be enormous and long-lasting. It's critical that this technology be sustainable in the long term without dependence on a single foreign entity.
Apple could easily be gone in ten years, but there will be a continuity of Open Source software until the next ice age.
"...suing you for emotional anguish!"
Judge: Oh, I thought it was a dog. Case dismissed.
Gee thanks, Bill, for telling us what we're legally allowed to do with the product we bought from you.
Take your useless support and shove it. We bought the right to use your rotten code, we bought the right to resell it for whatever we can get. We're Americans you fascist SOB.
You may be the richest man on Earth, but you're still a lying, cheating, two-faced, fuckwad... And your mother drinks elderberry wine. You have earned the right to be first at the guillotine.
What I'm trying to say is FUCK YOU.
"It about time!"
+5 funny
+5 informative
- 1 frist psot typo
-10 cocky sig
"The problem is you don't appear to be using the term "latency" in a meaningful or consistent fashion."
Latency is the time the program has to wait for a minimal amount of data, i.e. a one-byte request. It includes the time it takes to dispatch the command, the time it takes the head to position itself and settle at the correct cylinder, the time it takes for the platter to rotate to the beginning of the target sectors and whatever bus latencies are involved. That's for a single request. The thing that you seem to be missing is that the latency also includes the time waiting for earlier requests to be serviced (even without considering xfer time).
"That doesn't make it correct. Indeed, whoever wrote that Wikipedia article has the same problems with terminology and assumptions you do."
It's a better source than any you have bothered to find.
"Consider the scenario where you have a three-disk RAID0, with a 64kb chunk size. A request for 140kb is made, and conveniently enough, is contained in chunks on all three disks. So they are able to operate in parallel and provide maximum benefit."
In the cases where the single disk can fetch the 140k with a single seek, it will be faster on average than the 3-way raid-0. But a request that requires >1 seek on the single disk will have a shorter latency when distributed across >1 disks. Three requests for chunks that only require a single seek on a single disk can be handled simultaneously, each with the same average latency as the single disk.
"Here is another way to think about it. By your reasoning, a RAID1 made up of eight disks with an 8ms latency would have an average latency of 1ms. Do you seriously believe if you benchmark an eight-disk RAID1 you'll get an average seek time of 1ms ?"
The mistake you're making is not looking at the workload as a whole.
Take 8 random requests and submit them to single disk. I'd expect to wait (on average) 64ms for them all to complete. Now submit them to an 8-way RAID-1. I wouldn't expect any of them to complete in 1ms. That's not what I've been saying. But I would expect them to complete in 8ms. So instead of 64ms/8 requests, I'd have 8ms/8 requests.
It's more about statistics than physics.
Your point about writes versus reads is well understood. Parity RAID is very slow to write, and mirrors will also increase the average latency. RAID-0 however provides the same speedup on writes as it does on reads.
You're right in not expecting specialized support on your modified code, but I think you left out some important points.
If you find a bug in a customized program, you try to reproduce it on a stock version. If it exists, you submit a bug report against that. It's their bug, completely.
If you modified the code, then you should be able to determine if the modifications are working as expected. If not, it's your bug.
Maybe you have shared your modifications with others who can help. Maybe it has already been merged into the standard codebase.
Even when it's not possible to reproduce the bug due to logistical contraints, or to determine whose fault it is, the vendor should still listen to the problem and offer guidance on how to isolate the problem.
"I never suggested a single drive will always offer better overall performance than a RAID array. Merely that it will have better latency."
I wasn't trying to imply that you had made that suggestion. Just to be clear, this whole discussion has been about latencies, not transfer rates.
"Huh ? Perfectly balanced, parallelisable IO (as per your RAID1 and "checkout" examples) is about as "best case" as you can get when talking about RAID IO."
With RAID-1 it doesn't matter that the requests are balanced. a two-way mirror gives a 2x improvement in average latency. Make it a 3-way mirror, and you'll have a 3x improvement.
With RAID-0, the balance of requests does matter. Assume two disks, one containing even block numbers, the other containing odds. If the requests are pathological, i.e. all odds, the improvement will be 0. But if *any* of the requests are even, then there's an improvement.
I only jumped into this thread because you were modded informative for saying:
"RAID improves throughput, but not latency. If you need low latency, you need high-RPM drives and no amount of RAID will help you."
High-RPM (and fast head servos) are important, I never said otherwise. but improvements in those areas come incrementally. Many systems already have the fastest disks available, yet the demand for faster disk service persists and RAID satisfies that demand.
Wikipedia backs up what I have said. Please read what it says.
"You can do all the seeks in parallel, but without spinding locking, you're gonna need to wait longer (on average) for the sectors you need to rotate under the heads, because you're going to need every read to rotate under the heads, not just half of them."
Almost right.
"you're going to need every read to rotate under the heads"
But they're spinning in parallel. The average time it takes for a sector on one disk to reach the head is 1/2 of a revolution. The average time it takes for two sectors on separate disks to reach their heads is still 1/2 of a revolution. The point I'm making is that in that 1/2 rev, you have performed two operations instead of one.
"I guess in theory with RAID 1 you only have to wait for the first sector of each pair to come under the head. If controllers do that, good on them."
Any controller worth its salt will do this. Implementations aside, it's a natural property of RAID that it's *possible*. That's why I hate hearing people using the bogus rule-of-thumb "RAID doesn't improve latency.
I should have posted this paragraph in my first post: from the wiki page on RAID(level 1).
When reading both disks can be accessed independently. Like RAID 0 the average seek time is reduced by half when randomly reading but because each disk has the exact same data the requested sectors can always be split evenly between the disks and the seek time remains low. The transfer rate would also be doubled. For three disks the seek time would be a third and the transfer rate would be tripled.
It goes on to say:
The only limit is how many disks can be connected to the controller and its maximum transfer speed. Most IDE RAID 1 cards use a broken implementation and only read from one disk so their read performance is that of a single disk.
So maybe the rule of thumb should be "broken RAID does not improve latency".
"There's typically a lot more to disk access than perfectly parallelisable disk reads."
"The problem is you are taking your hypothetical, best-case scenario and treating it as the general case."
I did not show the best case nor did I treat it as the general case. I used one of the simplest cases to illustrate my point.
"So, I suppose in a manner of speaking "latency" has been reduced (in that you're waiting less)"
You're almost there.
"but it's not because the latency of the disk operations has improved, it's because the throughut has improved."
No, it's a latency issue. It has nothing to do with throughput, by which I assume you mean transfer rate. Consider the case where each read is for a single byte, or in my analogy, each shopper has a single item. Throughput doesn't matter, it's latency.
You're correct in saying that the more knowledge the RAID controller ( whether it be hardware or software ) has about the data, the more it can optimize performance, but it's only in the patholgical cases where there will be no improvement.
You're also right to say that quicker disks are a win. But even the fastest disk in the world can be easily swamped by a large number of requests.
more spindles == faster service
"the rule of thumb that RAID doesn't really help with latency applies to all of them"
All of them? You started off by saying that I gave "the one" example of RAID reducing the overall latency of multiple reads. Well, it's not the only one. RAID-0 will give the same result unless the data is pathological somehow, e.g. it clashes with some other interleaving scheme.
I understand what you're saying about the independence of checkout lanes, but it's the same as having a fairly uniform distribution of read requests (across the range of blocks in the volume). A hotspot in the data is similar to having just one checkout lane that accepts checks. Everyone in the store who is paying by check will experience a higher latency. But anyone who has cash will still benefit by the extra lanes.
More spindles == faster service. Naturally, quick drives are also a critical factor, but it's not always possible to upgrade to a quicker drive.
I suspect that the reason so many people think that RAID doesn't reduce latency is that they're using braindead controllers. I've seen plenty of them that are too stupid to even load balance across mirrors, the simplest case.
"Your analogy sucks. Not only is the scenario of people being served at checkouts talking about completely independent operations, but that independence also allows for performance hotspots (ie: longer queues in a particular aisle) to be avoided. Accesses to a RAID array exhibit neither of these characteristics."
The analogy works well. You just seem to be overlooking the obvious. Take mirrored RAID as an example. Assume the system needs to read 100 separate chunks of data. With a single disk, it must wait for 100 seeks (100 people in a single checkout lane), With two disks (lanes), the reads (checkouts) happen in parallel, so the system only waits for 50 seeks.
That's why it IS a myth that RAID doesn't improve latency. It won't improve the best case, but it will improve the average. It's sysadmin 101 that you add spindles when the transaction load gets high. Whether you spread the load at the filesystem level or at the block level doesn't matter, as long as it allows two disks to work at the same time.
A log disk will probably be dedicated to that single purpose, so as far as that particular storage system is concerned, it's just single-tasking.
There's still a potential benefit though. Some transactions will fall at the end of a cylinder, requiring a second seek. Others will be large enough that they will also require extra seeks. If the log were being written to RAID stripes, a two-seek transaction could be done with half the latency.
But like I said, the benefits vary with data access patterns. A log file is just a pathologically bad case.
"RAID improves throughput, but not latency."
Argh! This myth needs to end.
The only case in which RAID does not improve latency is that of a single tasking system.
The latency that's important for a multitasking system is the time an application has to wait for its data, not the time it takes the disk to process a single request. The benefits vary depending an access patterns, array geometries and RAID level.
Having more drives simply means there's a better chance that some requests can be handled in parallel. Your claim is akin to saying that people won't have to wait longer at the supermarket checkout when only one lane is open.
No, you have it wrong. The artist's woofer wasn't large enough (and probably wasn't baffled properly). It wasn't a woofer at all, just a moving cone.
It's all about creating enough air pressure to be felt/heard. A 12" fan can move much more air than a wall full of 12" cones.
The limitation of most acoustical drivers is that by design, they need to reciprocate and most of the power is wasted in accelerating and decelerating mass. The best analogy I can think of is that of a modern helicopter compared to that old learning-to-fly contraption with the beach umbrella on top.
Optics by Bubbles.
They're (they == you know who) are simply asking for too much money. The only reason they haven't been selling this stuff already is that it used to cost too much (fixed + variable) to distribute the bits.
My ass wasn't born yesterday, so I'm gonna pull a number out of it and say that distribution costs have gone down by a factor of 100 since the VHS days (vs bittorrent).
I don't care about fancy menus and stupid commentary tracks. Spare me the pleasantries. Just lemme put the shows on my shelf and i'll give you some buckos. WTF do they need ITunes for? They have the bits, I have the money. We're only as far away as a google search, a URL, and a credit card number. Make it happen at my price and I'll donate a MythTv plugin. Kudos to Steve Jobs for interposing his company as another layer of needless markups.
I recently STOLE the first two seasons of "WKRP", a better than average 70's US sitcom. You can't buy it, largely do to the fact that it contained so much copyrighted music. The way I see it, they're all so busy trying to screw each other they're neglecting their own core business.
I'd happily send someone $15 if they would make an "honest man" out of me for those 50 episodes, but it won't happen. They're too greedy. C'est la guerre.
Here's an idea (all rights reserved), make a "reality" tv show about maximizing viewer satisfaction and distributor profits by efficiently distributing the product.
One man's opionions, take them or leave them.
Air and space are insignificant. It's ether that matters.
"You may drool once you find the Fix & Continue (ZeroLink) feature"
Business Basic has had that feature for 35 years.
harboUr?
Shuah, we put the tea in, but we took out 'u'. Most of us don't bothah with the ahhs eithah. The word is habah. So thayah.
If you think that voting for one of the two major candidates is a waste, then vote for one of the minors. He won't win, but his viability will be increased for the next go round.
I'm a Massachusetts conservative, so I'd be hard pressed to vote for Kerry. But there was no way in hell that I was going to vote for the devil Bush, and even if I had, it wouldn't have done any good. I felt that the only way to make my vote count for anything was to vote for a third party.
Another point I'd like to make here is that corruption and incompetence come in all different shapes and sizes. If I had been living in one of the closely contested states, I'd have voted for the lesser of the two evils, namely Kerry.
The saddest thing is that America at large is waking up to the fact that the Bush administration is nfg, but it's too late. The damage has been done. Still, I can hope that he comes tumbling down with Cheney, Rove, and Libbey and that the nation learns that the Bush family cannot be trusted. They've been fucking us over for three generations.
Doing business with the Nazis.
http://en.wikipedia.org/wiki/Prescott_Bush
Pardoning criminals in the Iran-Contra scandal.
http://en.wikipedia.org/wiki/George_H._W._Bush
Conflicts of interest involving media coverage of the 2000 election.
http://en.wikipedia.org/wiki/John_Prescott_Ellis
Highly suspicious actions involving the Florida voter lists in the 2000 election.
http://en.wikipedia.org/wiki/Jeb_Bush
Bank scandals.
http://en.wikipedia.org/wiki/Neil_Bush
Shady offshore business dealings.
http://en.wikipedia.org/wiki/Marvin_Bush
"INCLUDING WITHOUT LIMITATION ANY "ADDON" OR "MOD," THAT IN BLIZZARD ENTERTAINMENT'S SOLE DETERMINATION:..."
It seems to me that this means it applies not only to the enumerated items, but to whatever they say it applies to. I don't think that you should be telling people that they have nothing to worry about.
I think you mean cow-orker.
"No programming, no modularity, no general problem solving."
Programming was done by selecting and arranging gears. Modularity was accomplished by adding layers, coupling the shafts from one layer to another. I'd even go so far as to say that it's general purpose in the sense of an "Erector Set".
Differential gears make this device far more interesting than any other mechanical clockwork I've ever seen.
"Even the wikipedia article it links to describes this as a clockwork mechanism."
But then it goes on to explain:
"The device is all the more impressive for its use of a differential gear, which was previously believed to have been invented in the 16th century."
It's far more sophisticated than a clockwork. Call it what you want, but it is a significant discovery in the history of analog computers.