Or the next time refers to a "AA battery" (as opposed to a AA cell, since "battery" should refer to a collection of cells), or any room without a bath a "bathroom", or to a commode as a "toilet" (since the word actually refers to the act of dressing), or someone hits the "gas pedal" (since it's really the throttle, controlling the flow of air).
Oh, wait, you mean to tell me that these are accepted terms for these things now? They're well established as acceptable terms for these things?
Some technically incorrect usage may be common (calling a 3.5" floppy disk a "hard disk", for example), but never become accepted usage. Other technically incorrect usage does become accepted usage.
It wasn't that long ago that the verb "impact" was considered non-standard, as in "This really impacts my schedule" or "Technology has impacted society" or "Impact your world". (You can find impact-as-verb going back to the 1600s, but in a much narrower sense than is used these days.) Nowadays, these examples are widely considered acceptable usage, although there still those who disagree. For example, the Random House dictionary says "Although recent, the new uses are entirely standard and most likely to occur in formal speech and writing." American Heritage isn't quite as keen on it though, weaseling thusly: "[T]he verbal use of impact has become so common in the working language of corporations and institutions that many speakers have begun to regard it as standard. It seems likely, then, that the verb will eventually become as unobjectionable as contact is now, since it will no longer betray any particular pretentiousness on the part of those who use it."
You see a similar weaseling on "literally," if you actually bother to go look. Random House:
Since the early 20th century, literally has been widely used as an intensifier meaning “in effect, virtually,” a sense that contradicts the earlier meaning “actually, without exaggeration” [....] Although this use of literally irritates some, it probably neither distorts nor enhances the intended meaning of the sentences in which it occurs.
AHD:
For more than a hundred years, critics have remarked on the incoherency of using literally in a way that suggests the exact opposite of its primary sense of "in a manner that accords with the literal sense of the words." [....] The practice does not stem from a change in the meaning of literally itself—if it did, the word would long since have come to mean "virtually" or "figuratively"—but from a natural tendency to use the word as a general intensive [...]"
English is full of confusing words. That doesn't make their use improper, it just makes them potentially confusing. I'm inclined to put "literally" in that category. If I said "I dusted the light dusting of dust off the book," aside from being (purposefully) repetitive, is it incorrect? The verb "dusted" means removing dust, whereas the verb "dusting" (used as a gerund) means adding dust. (Somebody cue "Buffalo buffalo..." guy.)
I do agree with his penultimate advice: "Don't write silly-soundingly." I also agree with his ultimate advice: "Be clear." I don't think either translates to a dictum to never use "literally" in a figurative context. I personally translate these to mean "Don't use the word 'literally' to intensify an already hyperbolic figurative expression, and don't use the figurative sense of 'literally' in a context where the literal sense is also plausible."
The phrase "literally an assault on my brain" doesn't seem all that hyperbolic, and it doesn't seem confusing. Saying something like "jumped so high he literally jumped over the moon" just pushes the hyperbole a bit much. Saying something like "wrote so hard he literally broke his pencil in half," when in actuality he hadn't (maybe he just snapped the tip) is simply confusing to the point of being incorrect. There's a continuum.
Erm... to whomever marked me troll: Wry humor isn't trolling. Through tongue-in-cheek wording, I was making the point that voting irregularities in Florida were amplified by the Electoral College system, rather than dampened out as shentino posited.
In the case of Florida in 2000, the electors did not overrule voting irregularities. Rather, in the end, the Supreme Court decided the election.
That's how I'd approach an electronic voting system. All that said, though, I'm not sure "throwing technology at it" is the right thing. Paper ballots with optical scanning and random auditing under multiparty review is likely a better route to fast results and reasonable certainty. The number of paper ballots examined in the audit can go up as the election gets closer to a tie.
Then again, look at the Franken vs. Coleman debacle. How would this have turned out differently (if at all) if the voting systems in the precincts had electronic voting in a system similar to the above? Would we still have write-ins for Lizard People?
The intent of the law appears to be to require clear "code" vs. "data" separation. The mechanism (the "code") should be fixed, and everything that the code manipulates (the "data") cannot turn into mechanism (more "code") once the system is certified. This would seem to preclude generating SQL queries. In my mind, it also requires that data that drives the election (ie. ballot definitions) need to also be immutable at election time. That is, once an election is configured, the configuration needs to be locked down and then certified prior to the election. I propose one way to do this here.
In the case of protecting against self-modifying machine code, I suggest that the machine run regular integrity checks, perhaps after each vote. The code that runs the election shouldn't be particularly large, so it shouldn't be too expensive to run a quick signature check over it. (Under a second.)
My questions are: Why aren't ballots immutable on the voting machines, perhaps signed cryptographically to ensure no tampering? Why are votes even logged in a generic database, rather than written as signed records to something flat, both locally and remotely? Everything seems so easily tampered with from what little I've seen. I'd prefer a more airtight approach.
Whether you realize it or not, you pointed to the real problem: With a generic SQL database backend, what stops uncertified code from modifying it outside the rules of the election? Even if the election-driving code is fixed in ROM, if you can re-run the install script and wipe the database, you can throw away an entire machines' vote totals. That's bad.
There is no possible way to write a general election package that will be configurable for a wide variety of elections and STILL have it all hard coded. It has to be data driven.
I agree that it must be data driven. I strongly disagree that an SQL database is a proper mechanism for doing this in a voting machine. Here's how I think it should be done:
The ballot should get defined once at the election headquarters, signed with an asymmetric key, and then loaded at all the precincts from (effectively) read-only storage. Voting records should go into a time-stamped log, perhaps signed by the voting station in a similar manner. Each signed record can include integrity checks, such as the current running total of votes and the expected number of records before it to detect missing records. Actions such as "Load Ballot," "Begin Dry Run," "End Dry Run," "Begin Live Election," "End Live Election" and so on should also appear in this log so that votes are recoverable if someone tries to throw the election by "restarting" the election day. Logs should be tallied both remotely and locally to provide an additional layer of auditability, just like syslogd does in UNIX, with one difference: The voting machine and its remote loggers both need to verify each others' identity with each log update. One possible architecture is to have each machine log remotely at several other machines in the same precinct as well as at least one machine upstream. The logging topology should be part of the signed (and therefore certifiable) ballot definition, with some provision for failing nodes--ie. multiple lists of the form "Must connect to at least 2 machines from this set," "Must connect to at least 1 machine from this set," "Must connect to at least 3 machines from this set."
I don't see anything that requires the generality and flexibility (and thus mutability and general tamper-ability) of a generic SQL database. The data that drives the election should be fixed and immutable (and therefore easily certified) well ahead of opening the precincts, and the voting logs are linear and write-once, like a cash register tape. The tally code upstream might also insert the logs into a database for analysis purposes, but the tallies themselves never need to be in a database--they're just totals. The database should never be part of the election process directly. If it's there, it's just there to make it easy to run fun, informative queries that are a complete adjunct to the actual vote tallying process.
If the voting records are only in something as generic as an SQL database, what stops uncertified software from changing the behavior of the system by directly updating the database? You really want a write-once log at each level whose integrity is ensured at every step by the format. If the integrity is ever compromised (either intentionally or by a hardware failure), it should be possible to recover as many votes as possible, minimizing the number of spoiled ballots.
Be careful... if you insult them too much, they might take back all their talent! (Mike Myers, Martin Short, Eugene Levy, Dan Akroyd, William Shatner, Michael J. Fox, etc. etc...) Of course, they may also take Celine Dion and Bryan Adams too...
If they can tie UI elements to a deadline such as "before the next screen refresh" to keep the UI snappy at (nearly) all times, I don't mind losing some background throughput.
20% overall hit on system performance, as in the peak throughput of your system may take a 20% or greater hit due to scheduler decisions that guarantee deadlines get met, even if that means not allowing work to proceed on tasks that are ready to run.
For example, task A may be ready to run, but if the scheduler picks it, then task B might miss its deadline because A's time quanta is too long. This can be true even if B isn't yet ready to run, but is about to be. Ready-to-run task A may take 40ms with a deadline way in the future. Task B might be ready to run in 20ms, and when it does run, it'll run for 70ms. Now suppose B's deadline is 100ms away. If task A can't be preempted, we can't run task A, because then we'd start task B too late. A real-time scheduling algorithm might therefore choose to idle 20ms until B is ready if it's not possible to preempt task A.
(Note to pedants out there: What I just described is not EDF, but a more generic off-the-top-of-my-head example of how realtime scheduling decisions, perhaps even just made by a human making a static schedule, can lead to idle time.)
These sorts of statements tend to apply though when all tasks use a real-time scheduling algorithm, or only to the subset of tasks that are classified "real-time". Linux's scheduling algorithm will remain hybrid, with some real time tasks and the rest using the CFS scheduler (SCHED_OTHER).
As a result, it seems highly unlikely to me that SCHED_EDF (or SCHED_DEADLINE or however it gets spelled) will make Linux a true hard real-time OS. It will just add a new, more traditional real time scheduler to the existing set of soft-real time schedulers (SCHED_RR, SCHED_FIFO). A system with predominately real-time tasks will probably meet all of its real time guarantees with high probability. I wouldn't run my medical equipment with it just yet though, particularly if any of the SCHED_OTHER tasks are doing disk I/O and/or thrashing the VM.
Re: your sig... (0x2B | ~0x2B) = ~0, regardless of your bit length.
Not too surprising. I imagine they trademarked it back in 1977 or 1978, since droids were such a cornerstone of Star Wars, and especially the merchandising wave that followed with all the plastic Kenner crap in the 80s. (In fact, I found one from 1977 here. In case that link ceases to work, it's a now-dead trademark for "Droid" as it applies to toys. It's been superceded by other variations on the Droid mark.)
Right, because when the breeders planned out the mating that eventually resulted in your dog, they planned out his all leather interior, ride control, electronic stability control, premium sound system, power-to-weight ratio, navigation system, heated/cooled seats, the ergonomic positions of all the controls, etc. etc.
Oh, wait, no. They knew they were breeding a dog, not a Lexus wannabe. I imagine if someone wanted to "kill" a Lexus (say Infiniti or Acura or Cadillac or Lincoln or Jaguar or Rover or BMW or Mercedes or....), they'd start with an actual car, not a canine.
Are you saying its 3G won't work on other US networks if I buy an unlocked one? That's a serious pity if it's true. I'm somewhat stuck with AT&T because my wife has an iPhone, but I'd love to move from my N82 to an N900. I'm rather tired of my N82 not talking 3G, but my understanding is that the N82 won't talk 3G on any US network due to the band it's on. If the N900 talks 3G in the US on one carrier, it seems like it'd talk 3G in the US on more than one.
I seem to recall AT&T had to be dragged kicking and screaming into Visual Voicemail support. That is, Jobs more or less forced it down Cingular^H^H^H^H^H^H^H^HAT&T's throat. Forcing them to not subtract the value Apple already added does not constitute adding value.
Are the N900's locked to a network? I would've thought I could buy one and use it on another network with the appropriate SIM card. Or are you referring to a subsidized N900?
Cut and paste? It's been out for months now, never used it. MMS? Never used it. MP3/AAC ringtones? Always supported, (you have to change the file extension is all), but actually never used them. Video recording? Never used it (and yes I have a 3gs.)
Good for you. You bought an expensive phone and don't use all the features. I've used MMS, cut and paste, an MP3 ringtone and video recording on my Nokia N82 since I bought it in 2007, for about the same price as a first gen iPhone. Newsflash: Some customers actually use the features of their phones, and some customers they don't. Plenty of people expect these sorts of features to be standard at the iPhone's price point, though.
With iPhone I use everything that comes with it and then some because the iPhone makes it easy.
Except apparently video recording, MMS, cut and paste...
I imagine the ratio is worse for software. Albums still go for $10-$20, but lots of software starts much higher. High enough that plenty of folks wouldn't ever buy it, and so they'd only ever encounter and/or use pirated copies. So, I wouldn't be surprised to see a ratio more like 25,000:1 for software. (For truly pricey stuff, perhaps higher.)
When I was in college, I know my copies of Windows and WordPerfect and Lotus 1-2-3 were all pirated. Those together would have been a many hundreds of dollars all by themselves at full retail price. I knew plenty of folks that had a copy of Photoshop 4. None of us had $600 to drop on a copy though. I imagine the situation isn't too much different today.
These days, I pretty much use Linux exclusively. Hurray free software!
One salient difference is that anyone writing a VMS device driver was encouraged to include errorr-logging, whereas the huge majority of Windows drivers seem to lack anything of the sort. The assumption seems to be that PCs work most of the time, and if they crash or work unreliably then the solution is to reboot - or, if the problem is persistent, buy a new PC.
Unless they're selling into a corporate environment where the corporation has standardized on specific hardware, there's no incentive for manufacturers to provide such error logging. In fact, there's incentive not to. In the consumer market, if a peripheral starts logging errors, the consumer is likely to replace the component with a competitor's offering, not a replacement from the same vendor. It's a great way to throw business to your competitors. There's far more incentive to just silently fail and hope you never get found out.
For this to show up in Windows, Microsoft would have to make it a driver certification requirement. Manufacturers would certainly push back on that. I think it'd be a good thing, though, because it'd make it much easier to determine which manufacturers ship solid products vs. which ones are crap. Even though I don't use Windows (except at work), even I'd benefit, because all the Windows users' experience would get more data out there on what's good and what's bad.
Slashdot Mirror
I dislike that phrase, but I always get a chuckle out of a related phrase: "Never make assumptions, because it makes an ass of you and Umption." ;-)
Or the next time refers to a "AA battery" (as opposed to a AA cell, since "battery" should refer to a collection of cells), or any room without a bath a "bathroom", or to a commode as a "toilet" (since the word actually refers to the act of dressing), or someone hits the "gas pedal" (since it's really the throttle, controlling the flow of air).
Oh, wait, you mean to tell me that these are accepted terms for these things now? They're well established as acceptable terms for these things?
Some technically incorrect usage may be common (calling a 3.5" floppy disk a "hard disk", for example), but never become accepted usage. Other technically incorrect usage does become accepted usage.
It wasn't that long ago that the verb "impact" was considered non-standard, as in "This really impacts my schedule" or "Technology has impacted society" or "Impact your world". (You can find impact-as-verb going back to the 1600s, but in a much narrower sense than is used these days.) Nowadays, these examples are widely considered acceptable usage, although there still those who disagree. For example, the Random House dictionary says "Although recent, the new uses are entirely standard and most likely to occur in formal speech and writing." American Heritage isn't quite as keen on it though, weaseling thusly: "[T]he verbal use of impact has become so common in the working language of corporations and institutions that many speakers have begun to regard it as standard. It seems likely, then, that the verb will eventually become as unobjectionable as contact is now, since it will no longer betray any particular pretentiousness on the part of those who use it."
You see a similar weaseling on "literally," if you actually bother to go look. Random House:
AHD:
So there you go.
I enjoyed the article too. :-)
English is full of confusing words. That doesn't make their use improper, it just makes them potentially confusing. I'm inclined to put "literally" in that category. If I said "I dusted the light dusting of dust off the book," aside from being (purposefully) repetitive, is it incorrect? The verb "dusted" means removing dust, whereas the verb "dusting" (used as a gerund) means adding dust. (Somebody cue "Buffalo buffalo..." guy.)
I do agree with his penultimate advice: "Don't write silly-soundingly." I also agree with his ultimate advice: "Be clear." I don't think either translates to a dictum to never use "literally" in a figurative context. I personally translate these to mean "Don't use the word 'literally' to intensify an already hyperbolic figurative expression, and don't use the figurative sense of 'literally' in a context where the literal sense is also plausible."
The phrase "literally an assault on my brain" doesn't seem all that hyperbolic, and it doesn't seem confusing. Saying something like "jumped so high he literally jumped over the moon" just pushes the hyperbole a bit much. Saying something like "wrote so hard he literally broke his pencil in half," when in actuality he hadn't (maybe he just snapped the tip) is simply confusing to the point of being incorrect. There's a continuum.
If you liked that article, you might enjoy A Way With Words. They actually covered this use of "literally" in one of their episodes, about 42 minutes in. And they actually mention the Slate article. :-)
You're literally full of it. "Literally" has been used as an intensifier since the 17th Century. Get over it. And before you go off on the author of the article I just linked... He's a dictionary editor. I think he spends more time with a dictionary than any of us.
Nuke it from orbit. It's the only way to be sure.
Erm... to whomever marked me troll: Wry humor isn't trolling. Through tongue-in-cheek wording, I was making the point that voting irregularities in Florida were amplified by the Electoral College system, rather than dampened out as shentino posited.
In the case of Florida in 2000, the electors did not overrule voting irregularities. Rather, in the end, the Supreme Court decided the election.
Are you sure they closed down 800 sites, and not 419 sites? ;-)
That's how I'd approach an electronic voting system. All that said, though, I'm not sure "throwing technology at it" is the right thing. Paper ballots with optical scanning and random auditing under multiparty review is likely a better route to fast results and reasonable certainty. The number of paper ballots examined in the audit can go up as the election gets closer to a tie.
Then again, look at the Franken vs. Coleman debacle. How would this have turned out differently (if at all) if the voting systems in the precincts had electronic voting in a system similar to the above? Would we still have write-ins for Lizard People?
The intent of the law appears to be to require clear "code" vs. "data" separation. The mechanism (the "code") should be fixed, and everything that the code manipulates (the "data") cannot turn into mechanism (more "code") once the system is certified. This would seem to preclude generating SQL queries. In my mind, it also requires that data that drives the election (ie. ballot definitions) need to also be immutable at election time. That is, once an election is configured, the configuration needs to be locked down and then certified prior to the election. I propose one way to do this here.
In the case of protecting against self-modifying machine code, I suggest that the machine run regular integrity checks, perhaps after each vote. The code that runs the election shouldn't be particularly large, so it shouldn't be too expensive to run a quick signature check over it. (Under a second.)
My questions are: Why aren't ballots immutable on the voting machines, perhaps signed cryptographically to ensure no tampering? Why are votes even logged in a generic database, rather than written as signed records to something flat, both locally and remotely? Everything seems so easily tampered with from what little I've seen. I'd prefer a more airtight approach.
Whether you realize it or not, you pointed to the real problem: With a generic SQL database backend, what stops uncertified code from modifying it outside the rules of the election? Even if the election-driving code is fixed in ROM, if you can re-run the install script and wipe the database, you can throw away an entire machines' vote totals. That's bad.
Here's how I'd go about voting machine architecture.
I agree that it must be data driven. I strongly disagree that an SQL database is a proper mechanism for doing this in a voting machine. Here's how I think it should be done:
The ballot should get defined once at the election headquarters, signed with an asymmetric key, and then loaded at all the precincts from (effectively) read-only storage. Voting records should go into a time-stamped log, perhaps signed by the voting station in a similar manner. Each signed record can include integrity checks, such as the current running total of votes and the expected number of records before it to detect missing records. Actions such as "Load Ballot," "Begin Dry Run," "End Dry Run," "Begin Live Election," "End Live Election" and so on should also appear in this log so that votes are recoverable if someone tries to throw the election by "restarting" the election day. Logs should be tallied both remotely and locally to provide an additional layer of auditability, just like syslogd does in UNIX, with one difference: The voting machine and its remote loggers both need to verify each others' identity with each log update. One possible architecture is to have each machine log remotely at several other machines in the same precinct as well as at least one machine upstream. The logging topology should be part of the signed (and therefore certifiable) ballot definition, with some provision for failing nodes--ie. multiple lists of the form "Must connect to at least 2 machines from this set," "Must connect to at least 1 machine from this set," "Must connect to at least 3 machines from this set."
I don't see anything that requires the generality and flexibility (and thus mutability and general tamper-ability) of a generic SQL database. The data that drives the election should be fixed and immutable (and therefore easily certified) well ahead of opening the precincts, and the voting logs are linear and write-once, like a cash register tape. The tally code upstream might also insert the logs into a database for analysis purposes, but the tallies themselves never need to be in a database--they're just totals. The database should never be part of the election process directly. If it's there, it's just there to make it easy to run fun, informative queries that are a complete adjunct to the actual vote tallying process.
If the voting records are only in something as generic as an SQL database, what stops uncertified software from changing the behavior of the system by directly updating the database? You really want a write-once log at each level whose integrity is ensured at every step by the format. If the integrity is ever compromised (either intentionally or by a hardware failure), it should be possible to recover as many votes as possible, minimizing the number of spoiled ballots.
Be careful... if you insult them too much, they might take back all their talent! (Mike Myers, Martin Short, Eugene Levy, Dan Akroyd, William Shatner, Michael J. Fox, etc. etc...) Of course, they may also take Celine Dion and Bryan Adams too...
(Tongue planted firmly in cheek, eh?)
Those electors sure saved us a bunch of trouble in Florida in 2000, didn't they?
If they can tie UI elements to a deadline such as "before the next screen refresh" to keep the UI snappy at (nearly) all times, I don't mind losing some background throughput.
20% overall hit on system performance, as in the peak throughput of your system may take a 20% or greater hit due to scheduler decisions that guarantee deadlines get met, even if that means not allowing work to proceed on tasks that are ready to run.
For example, task A may be ready to run, but if the scheduler picks it, then task B might miss its deadline because A's time quanta is too long. This can be true even if B isn't yet ready to run, but is about to be. Ready-to-run task A may take 40ms with a deadline way in the future. Task B might be ready to run in 20ms, and when it does run, it'll run for 70ms. Now suppose B's deadline is 100ms away. If task A can't be preempted, we can't run task A, because then we'd start task B too late. A real-time scheduling algorithm might therefore choose to idle 20ms until B is ready if it's not possible to preempt task A.
(Note to pedants out there: What I just described is not EDF, but a more generic off-the-top-of-my-head example of how realtime scheduling decisions, perhaps even just made by a human making a static schedule, can lead to idle time.)
These sorts of statements tend to apply though when all tasks use a real-time scheduling algorithm, or only to the subset of tasks that are classified "real-time". Linux's scheduling algorithm will remain hybrid, with some real time tasks and the rest using the CFS scheduler (SCHED_OTHER).
As a result, it seems highly unlikely to me that SCHED_EDF (or SCHED_DEADLINE or however it gets spelled) will make Linux a true hard real-time OS. It will just add a new, more traditional real time scheduler to the existing set of soft-real time schedulers (SCHED_RR, SCHED_FIFO). A system with predominately real-time tasks will probably meet all of its real time guarantees with high probability. I wouldn't run my medical equipment with it just yet though, particularly if any of the SCHED_OTHER tasks are doing disk I/O and/or thrashing the VM.
Re: your sig... (0x2B | ~0x2B) = ~0, regardless of your bit length.
See my comment here.
Not too surprising. I imagine they trademarked it back in 1977 or 1978, since droids were such a cornerstone of Star Wars, and especially the merchandising wave that followed with all the plastic Kenner crap in the 80s. (In fact, I found one from 1977 here. In case that link ceases to work, it's a now-dead trademark for "Droid" as it applies to toys. It's been superceded by other variations on the Droid mark.)
Of course, that would be my theory. Amazingly, there is a very recent application (Oct 9th, 2009 if that link expires or only works for me) from Lucasfilm specifically covering Droid in a cell-phone context. That makes me wonder if there were preemptive negotiations to prevent something like the iPhone trademark kerfluffle that happened back in 2007 between Cisco and Apple.
If you want to do your own searches (in particular if the links I provided don't work), go here, or if that fails, here.
Right, because when the breeders planned out the mating that eventually resulted in your dog, they planned out his all leather interior, ride control, electronic stability control, premium sound system, power-to-weight ratio, navigation system, heated/cooled seats, the ergonomic positions of all the controls, etc. etc.
Oh, wait, no. They knew they were breeding a dog, not a Lexus wannabe. I imagine if someone wanted to "kill" a Lexus (say Infiniti or Acura or Cadillac or Lincoln or Jaguar or Rover or BMW or Mercedes or ....), they'd start with an actual car, not a canine.
Are you saying its 3G won't work on other US networks if I buy an unlocked one? That's a serious pity if it's true. I'm somewhat stuck with AT&T because my wife has an iPhone, but I'd love to move from my N82 to an N900. I'm rather tired of my N82 not talking 3G, but my understanding is that the N82 won't talk 3G on any US network due to the band it's on. If the N900 talks 3G in the US on one carrier, it seems like it'd talk 3G in the US on more than one.
Got references? I'm genuinely curious.
I seem to recall AT&T had to be dragged kicking and screaming into Visual Voicemail support. That is, Jobs more or less forced it down Cingular^H^H^H^H^H^H^H^HAT&T's throat. Forcing them to not subtract the value Apple already added does not constitute adding value.
Are the N900's locked to a network? I would've thought I could buy one and use it on another network with the appropriate SIM card. Or are you referring to a subsidized N900?
Good for you. You bought an expensive phone and don't use all the features. I've used MMS, cut and paste, an MP3 ringtone and video recording on my Nokia N82 since I bought it in 2007, for about the same price as a first gen iPhone. Newsflash: Some customers actually use the features of their phones, and some customers they don't. Plenty of people expect these sorts of features to be standard at the iPhone's price point, though.
Except apparently video recording, MMS, cut and paste...
I imagine the ratio is worse for software. Albums still go for $10-$20, but lots of software starts much higher. High enough that plenty of folks wouldn't ever buy it, and so they'd only ever encounter and/or use pirated copies. So, I wouldn't be surprised to see a ratio more like 25,000:1 for software. (For truly pricey stuff, perhaps higher.)
When I was in college, I know my copies of Windows and WordPerfect and Lotus 1-2-3 were all pirated. Those together would have been a many hundreds of dollars all by themselves at full retail price. I knew plenty of folks that had a copy of Photoshop 4. None of us had $600 to drop on a copy though. I imagine the situation isn't too much different today.
These days, I pretty much use Linux exclusively. Hurray free software!
Unless they're selling into a corporate environment where the corporation has standardized on specific hardware, there's no incentive for manufacturers to provide such error logging. In fact, there's incentive not to. In the consumer market, if a peripheral starts logging errors, the consumer is likely to replace the component with a competitor's offering, not a replacement from the same vendor. It's a great way to throw business to your competitors. There's far more incentive to just silently fail and hope you never get found out.
For this to show up in Windows, Microsoft would have to make it a driver certification requirement. Manufacturers would certainly push back on that. I think it'd be a good thing, though, because it'd make it much easier to determine which manufacturers ship solid products vs. which ones are crap. Even though I don't use Windows (except at work), even I'd benefit, because all the Windows users' experience would get more data out there on what's good and what's bad.