When I said random, I meant literally random. Roll the dice. By doing so, you dilute the effectiveness of the lawn-sign politicians (those with literally name-only recognition.)
Now, if you actually have an opinion (as you obviously do) no matter how strong or weak, vote it. That's your first responsibility. But I was replying to your very specific words:
>>>"saw a whole bunch of names for lower-level people I never heard of. Rather than make a random guess,"
My point was that a mathematically random guess would have been more fair to the process than to give support to the guy with the biggest lawn sign; you would have more impact than not voting at all.
Unfortunately, half the voters are going to be of below-average intelligence, no matter what you do. For example, appealing to them with lawn-signs is an effective tactic -- if you can get them to remember your name for the two minutes it takes to drive by the sign and enter the polling place, you have a chance. Politicians don't get elected by the percent of "educated votes" they get, it's the total of "all votes" that wins. There is no incentive for them to change that. What you did by not-voting was to give the lawn-sign-mentality crowd more of a voice. Even a random choice on your part would have diluted their effectiveness.
The next problem is that of "educated voters". Sure, we all say we want informed people to go to the polls. But no, politicians don't actually want that, either. They only need people that will vote for them, and not the people who will vote for the other guy. So there's no incentive for them to assist in educating the voters, especially if their position might scare off half of those that understand it. It's far more effective to put on a circus that appeals to a larger quantity of stupid people than it is to make carefully reasoned arguments that appeal to only a handful of the smart people.
I think BikeHelmet meant that if the temperature ranged from 50K to 5000K from pole-to-equator, and was linear in temperature rise as you moved from the north pole southward, you would find a habitable band just slightly south of the pole that would extend from a too-cold northern border to a too-hot southern border, and that band would only be about 0.5 km.
Or if the planet was tidally locked, you'd find the habitable band would be a band ringing the darker side of the shadow line that divides the diurnal areas from the nocturnal areas.
Of course, habitable still implies there aren't rocks constantly falling from the sky, ruining your picnics and canceling all the plane flights.
if MMORPGs did start to allow user submitted content, then would it be right to continue their pricing structure?
So combine them. MMORPG operators could offer a discount, or credit towards future play, for user generated content. Did you create an interesting quest? You get 10% off next month's bill. Did you do some fancy artwork for a suit of arms and armor? Next month is free. Did you create an entire battleground arena? Cool, here's a year of free gameplay and a job offer.
Sure, most UGC is going to be mostly worthless, but if they encouraged it as a marketing tool they'd end up with a lot of neat stuff to sell.
I also added content to a couple of MUDs way back when. I think the difference between those and WoW is that to write for a MUD meant your only technical requirement was to have an good command of the language. Adding content to WoW, Eve, or whatever, would require you to have 3D modeling skills.
You'd also have to be cognizant of game balance -- adding a vending machine to spit out Swords of UberPwnage +10000 for a gold piece, or adding the "Quiet Fieldmouse 1HP" and having him drop 500 gold is going to ruin gameplay.
Back when we were writing MUDs, balance was in our minds because we wanted our creation to be both challenging and fun. Today, with MMORPGs serving as real paycheck-delivering jobs for armies of offshore gold farmers, you'd have to suspect everyone of ulterior motives no matter what they were creating. "You added a tree in the middle of that open field? Hmm, is that really so you can play a game of capture-the-clan-flag, or is it to let you climb up and shoot the snakes easier for your gold-farming operation?"
Not only is it a bad idea to gather all that info in one place, but the idea itself won't work. If I have two encrypted SSL streams, one contains malware, the other contains my banking information, how does his magical tool know the difference?
"Please, anti-malware tool who is reporting all my machine information to the great vendor's database in the cloud, I want you to also sniff my banking traffic."
A professional warden, you mean. Filing frivolous and harrasing lawsuits is a crime, and he belongs in jail for making other people's lives miserable. If they can get him therapy while he's in prison, that's fine, but get him off the streets before he costs someone else another million dollars to defend against his criminal actions.
I agree completely that an optimizing compiler is no excuse for writing crap code. There is never an excuse for writing crap code.
But I think you'd be surprised at just how wide-spread the optimizations are that they're able to exploit now in the Phoenix middle tier. The algorithm recognition pieces can spot common patterns, and optimally hardwire them. It counts instructions and unrolls loops when it would save cycles.
An optimizer doesn't care what you are trying to do, it only cares what you explicitly told it to do. With an assembler, you have to pump all that same level of care, and all those brain cycles into accomplishing absolutely every task, no matter what. Painting a window? Optimize it, make sure you have no memory leaks, move the right language bitmap resource into place, build a font, everything. Accepting keypad input? Keep hand allocating memory, don't leak it. Poll the hardware wires, looking for contacts. Write some keypad debounce code. Trigger an FSM with your key code. Processing messages? Keep going with every stinking module, optimizing, not leaking, allocating, deallocating, polling hardware, formatting protocols, etc., etc., etc.
At no point is there a payoff for writing all that glue code in assembler. Each module is as fragile as it sounds. All the learning about loosely coupled code that you get for free when using a framework? Gone, or you implement it as a bunch of macros. And how do you interface all those assembler modules together? Do you hand write a higher level interface language, too?
And now that you built me the perfectly optimized hand-assembled phone, who am I going to get to maintain it? You will, for $5,000,000 per year? Hmm, let me think on that proposition.
Hand assembled code is not commercially viable, at least not on the large scale required to implement a system. Hand optimized code can be great when you're dealing with a single high-performance component, such as a video driver or a hardware interface chip. But you don't build a system out of it for any reason other than the love of the hack. And you can't sell "hack-love".
Modern optimizers are getting really, really good at optimizing code. So much so that the code they produce is only a few percent less efficient than most hand-tuned routines.
For grins and giggles, you ought to examine some of the optimizations that Microsoft's latest compiler delivers. I had the good fortune to hear Louis Lafreniere present some of the details from their latest offerings, and they really are remarkable. They've rewritten the concept of compiler by adding a new standard for the intermediate step between parsed and compiled, allowing a plug-in architecture to scan an entire package for optimizations, not just a single compilation unit (such as compiling one.C file at a time.) They identify loops and extract common data (even when it crosses module boundaries!), they can replace multiple levels of indirection with a single pointer redirection, among many cool tricks.
The bigger problem is the demand for more features and functionality, driven by a very high expectations set by market successes such as the iPhone. Sure, you could write a hand-assembled phone system that might yield 50% more battery life. Would it have anything more than a 10-digit LCD display? Could you support a touch screen with drag and drop navigation, MMS, SMS, Bluetooth, MP3 support, etc., etc., etc.? Could you deliver a crash-free hand assembled solution to market in a year? Hint: you'd be a multi-millionaire if that answer were yes. And without the eye candy it won't sell, therefore it's not a relevant solution.
I just realized there might be a positive spin to their numbers as well. Because security awareness has been at the current peak for only a short while (it's really taken off in the last two or three years), it's possible that they're reporting higher numbers of attacks because they now have the tools and monitors in place to detect the higher numbers. Perhaps hacking is not nearly as bad now as it was before, it's just that they didn't know they were being hacked before, and now they do.
Aha, I found that they have "number of records" metrics, too, as long as you're willing to harvest them out of their reports.
2009 YTD: Total Incidents: 330 Total Records Affected: 138,772,156
2008: Total Incidents: 703 Total Records Affected: 85,843,506
2007: Total Incidents: 484 Total Records Affected: 165,184,031
2006: Total Incidents: 530 Total Records Affected: 51,142,868
2005: Total Incidents: 140 Total Records Affected: 55,988,256
So 2009 is indeed a "severe" year in terms of records lost. Again, though, these are totals of all reportedly lost data, regardless of how the data went missing. A backup tape with 100,000 records lost in a dumpster counts equally with a hacker stealing 100,000 credit cards from a web site, even though one loss clearly places the data at a higher risk for fraudulent use than the other.
Good way to go
on
A Geek Funeral
·
· Score: 4, Insightful
Remembered as in life, not as the struggle through the end.
Could be shenanigans, but they're using different metrics. OSF uses media reports to search for breaches that have been made public whereas TFA conducted a survey of "more than 600 Canadian IT security professionals."
After I posted it, I figure that if they weren't looking at 2009 (because most reporting is done on an annual basis), 2008 does indeed look pretty terrible by comparison to the rest of the years. Although TFA does say that in 2009 the security professionals are reporting 11 incidents per organization compared to 3 per org in 2008.
So, are the Canadian corporations better at hiding breaches from the public than the OSF indicates? Are the "professionals" overreporting and including counts of attempted breaches, like drive-by WEP attacks that go nowhere, or phishing emails, or viruses? Or is this a real count of actual breaches that caused a loss of valuable data, and they're just not telling us?
But "simple" does not mean "secure". Yes, simple is easier to verify, but you can write simple, clean code and still get hit with a security incident.
Code that is simple and secure today also doesn't mean that it will be secure tomorrow, once the next exploit is created and discovered. How long ago was it before javascript existed? Nobody cared if you put <script> tags in your comments, because browsers didn't even know the keyword "script". Suddenly browsers started appearing that supported this tag, and people got creative when posting comments, including cute scripts to animate their signatures. Then XSS attacks were discovered and became all the rage, and perfectly secure web sites around the globe suddenly had a new threat model that became their responsibility to clean up.
You can review simple code all day long and assure yourself that it will do what it's supposed to do. But it's very, very hard to review code to ensure that it won't do something bad, especially when you don't have tomorrow's definition for "bad" to review against!
That's because you're talking about CDs, and not data transfers among the clouds.
The original audio CD medium was designed to tolerate errors. If a bit goes bad when you're playing it, you don't stop and pop up a dialog to the user saying "ZOMG! BAD BIT ON TRACK 7! Retry, Cancel or Allow?" The player just compensates for the bad bit and keeps on playing. Similarly, a bad bit on a JPEG or in an MPEG stream won't prevent the images from displaying, or you'd never see a digital TV show, ever.
But that's not how you transfer data to and from machines on the internet. TCP is a protocol designed to detect some errors and recover from them. Digital signatures provide almost absolute assurance that the copied data is unchanged from the original. Placing data in just about any modern cryptographic digital envelope can give you the assurance that what is in the envelope is the same as what you put in the envelope.
Even bit torrent is good at providing lossless data storage and transfer.
So no, you can't compare CDs to cloud storage. They are not even close.
Oh no! This is nothing like fact-based reporting, either.
Look at the graph on the banner of OSF Dataloss. That banner, right across the top, shows the number of reported incidents, month by month, since Feb 2007. The 2007 average seems to be in the mid-40s. The 2008 average seems to be about 60 per month. The 2009 bar graph is steadily sloping downwards, starting from a high of 61 incidents in Feburary dropping down steadily to 23 last month and 16 this month.
To be a bit more factual, you can visit the statistics. That shows the progression from 2005-2009 looking like this: 2005 140 2006 530 2007 484 2008 703 2009 331
Nothing in the statistics even remotely seems as bad as last year, and this year's pace seems to be trending towards even fewer breaches than 2006's level.
Some guy posted a great instructables on building your own high speed book scanner, purposely designed to rapidly photograph book pages without curves. He even includes a software stream that OCRs the contents and sticks them into PDFs.
It's been quite popular -- so much so that he's created an online forum at http://www.diybookscanner.org/ dedicated to discussions from DIY book scanners all over the place, where they talk about builds, parts, and software.
I've been very tempted to build one myself just to avoid carrying heavy books around in my backpack.
Apple's recommendation if you can't get MMS working or don't want to upgrade is to continue to send pictures via email. It's pragmatic but not the best solution for immediate mobile to mobile picture transfers.
How much people really need an instant mobile to mobile picture transfer solution is a different question.
Oh, sorry, you're absolutely right. I was confusing some of the salesman's spiel with some of the things we rearranged on our plan to switch to the iPhones.
For that matter it'll never got popular. This is partly because operators overprice MMS and because it doesn't really serve that much purpose.
Well, there are a couple of things that you got wrong here. First, overpriced or not, unlimited MMS is included as a part of the data plan you have to buy from AT&T when you have an iPhone. So cost won't matter.
The other is that one reason MMS hasn't taken off is that it's been hard to use on a lot of phones. On some of them the user has to know to go into a different messaging task, or to say create some kind of special message, and do some weird stuff they've never done before. On the iPhone, they added a little camera icon to the left of the text entry box. Couldn't be easier.
Since the "barriers to entry" have now been substantially lowered, iPhone users will indeed start to use the feature more.
I'd argue that the real metric is user perception, not raw performance. If you can keep the user entertained with a screenful of flying monkeys, you can actually load slower but be perceived as faster than a blank-to-full-screen transition.
Slashdot Mirror
When I said random, I meant literally random. Roll the dice. By doing so, you dilute the effectiveness of the lawn-sign politicians (those with literally name-only recognition.)
Now, if you actually have an opinion (as you obviously do) no matter how strong or weak, vote it. That's your first responsibility. But I was replying to your very specific words:
>>>"saw a whole bunch of names for lower-level people I never heard of. Rather than make a random guess,"
My point was that a mathematically random guess would have been more fair to the process than to give support to the guy with the biggest lawn sign; you would have more impact than not voting at all.
Unfortunately, half the voters are going to be of below-average intelligence, no matter what you do. For example, appealing to them with lawn-signs is an effective tactic -- if you can get them to remember your name for the two minutes it takes to drive by the sign and enter the polling place, you have a chance. Politicians don't get elected by the percent of "educated votes" they get, it's the total of "all votes" that wins. There is no incentive for them to change that. What you did by not-voting was to give the lawn-sign-mentality crowd more of a voice. Even a random choice on your part would have diluted their effectiveness.
The next problem is that of "educated voters". Sure, we all say we want informed people to go to the polls. But no, politicians don't actually want that, either. They only need people that will vote for them, and not the people who will vote for the other guy. So there's no incentive for them to assist in educating the voters, especially if their position might scare off half of those that understand it. It's far more effective to put on a circus that appeals to a larger quantity of stupid people than it is to make carefully reasoned arguments that appeal to only a handful of the smart people.
I think BikeHelmet meant that if the temperature ranged from 50K to 5000K from pole-to-equator, and was linear in temperature rise as you moved from the north pole southward, you would find a habitable band just slightly south of the pole that would extend from a too-cold northern border to a too-hot southern border, and that band would only be about 0.5 km.
Or if the planet was tidally locked, you'd find the habitable band would be a band ringing the darker side of the shadow line that divides the diurnal areas from the nocturnal areas.
Of course, habitable still implies there aren't rocks constantly falling from the sky, ruining your picnics and canceling all the plane flights.
if MMORPGs did start to allow user submitted content, then would it be right to continue their pricing structure?
So combine them. MMORPG operators could offer a discount, or credit towards future play, for user generated content. Did you create an interesting quest? You get 10% off next month's bill. Did you do some fancy artwork for a suit of arms and armor? Next month is free. Did you create an entire battleground arena? Cool, here's a year of free gameplay and a job offer.
Sure, most UGC is going to be mostly worthless, but if they encouraged it as a marketing tool they'd end up with a lot of neat stuff to sell.
I also added content to a couple of MUDs way back when. I think the difference between those and WoW is that to write for a MUD meant your only technical requirement was to have an good command of the language. Adding content to WoW, Eve, or whatever, would require you to have 3D modeling skills.
You'd also have to be cognizant of game balance -- adding a vending machine to spit out Swords of UberPwnage +10000 for a gold piece, or adding the "Quiet Fieldmouse 1HP" and having him drop 500 gold is going to ruin gameplay.
Back when we were writing MUDs, balance was in our minds because we wanted our creation to be both challenging and fun. Today, with MMORPGs serving as real paycheck-delivering jobs for armies of offshore gold farmers, you'd have to suspect everyone of ulterior motives no matter what they were creating. "You added a tree in the middle of that open field? Hmm, is that really so you can play a game of capture-the-clan-flag, or is it to let you climb up and shoot the snakes easier for your gold-farming operation?"
Not only is it a bad idea to gather all that info in one place, but the idea itself won't work. If I have two encrypted SSL streams, one contains malware, the other contains my banking information, how does his magical tool know the difference?
"Please, anti-malware tool who is reporting all my machine information to the great vendor's database in the cloud, I want you to also sniff my banking traffic."
I much preferred the video of the jet-powered merry-go-round: http://www.youtube.com/watch?v=tjS8btFb9RA&feature=popt00us07 At least there you get some fun out of the danger before the whole thing blows up in your face.
A professional warden, you mean. Filing frivolous and harrasing lawsuits is a crime, and he belongs in jail for making other people's lives miserable. If they can get him therapy while he's in prison, that's fine, but get him off the streets before he costs someone else another million dollars to defend against his criminal actions.
I agree completely that an optimizing compiler is no excuse for writing crap code. There is never an excuse for writing crap code.
But I think you'd be surprised at just how wide-spread the optimizations are that they're able to exploit now in the Phoenix middle tier. The algorithm recognition pieces can spot common patterns, and optimally hardwire them. It counts instructions and unrolls loops when it would save cycles.
An optimizer doesn't care what you are trying to do, it only cares what you explicitly told it to do. With an assembler, you have to pump all that same level of care, and all those brain cycles into accomplishing absolutely every task, no matter what. Painting a window? Optimize it, make sure you have no memory leaks, move the right language bitmap resource into place, build a font, everything. Accepting keypad input? Keep hand allocating memory, don't leak it. Poll the hardware wires, looking for contacts. Write some keypad debounce code. Trigger an FSM with your key code. Processing messages? Keep going with every stinking module, optimizing, not leaking, allocating, deallocating, polling hardware, formatting protocols, etc., etc., etc.
At no point is there a payoff for writing all that glue code in assembler. Each module is as fragile as it sounds. All the learning about loosely coupled code that you get for free when using a framework? Gone, or you implement it as a bunch of macros. And how do you interface all those assembler modules together? Do you hand write a higher level interface language, too?
And now that you built me the perfectly optimized hand-assembled phone, who am I going to get to maintain it? You will, for $5,000,000 per year? Hmm, let me think on that proposition.
Hand assembled code is not commercially viable, at least not on the large scale required to implement a system. Hand optimized code can be great when you're dealing with a single high-performance component, such as a video driver or a hardware interface chip. But you don't build a system out of it for any reason other than the love of the hack. And you can't sell "hack-love".
Not that old chestnut again.
Modern optimizers are getting really, really good at optimizing code. So much so that the code they produce is only a few percent less efficient than most hand-tuned routines.
For grins and giggles, you ought to examine some of the optimizations that Microsoft's latest compiler delivers. I had the good fortune to hear Louis Lafreniere present some of the details from their latest offerings, and they really are remarkable. They've rewritten the concept of compiler by adding a new standard for the intermediate step between parsed and compiled, allowing a plug-in architecture to scan an entire package for optimizations, not just a single compilation unit (such as compiling one .C file at a time.) They identify loops and extract common data (even when it crosses module boundaries!), they can replace multiple levels of indirection with a single pointer redirection, among many cool tricks.
The bigger problem is the demand for more features and functionality, driven by a very high expectations set by market successes such as the iPhone. Sure, you could write a hand-assembled phone system that might yield 50% more battery life. Would it have anything more than a 10-digit LCD display? Could you support a touch screen with drag and drop navigation, MMS, SMS, Bluetooth, MP3 support, etc., etc., etc.? Could you deliver a crash-free hand assembled solution to market in a year? Hint: you'd be a multi-millionaire if that answer were yes. And without the eye candy it won't sell, therefore it's not a relevant solution.
I just realized there might be a positive spin to their numbers as well. Because security awareness has been at the current peak for only a short while (it's really taken off in the last two or three years), it's possible that they're reporting higher numbers of attacks because they now have the tools and monitors in place to detect the higher numbers. Perhaps hacking is not nearly as bad now as it was before, it's just that they didn't know they were being hacked before, and now they do.
Aha, I found that they have "number of records" metrics, too, as long as you're willing to harvest them out of their reports.
2009 YTD:
Total Incidents: 330
Total Records Affected: 138,772,156
2008:
Total Incidents: 703
Total Records Affected: 85,843,506
2007:
Total Incidents: 484
Total Records Affected: 165,184,031
2006:
Total Incidents: 530
Total Records Affected: 51,142,868
2005:
Total Incidents: 140
Total Records Affected: 55,988,256
So 2009 is indeed a "severe" year in terms of records lost. Again, though, these are totals of all reportedly lost data, regardless of how the data went missing. A backup tape with 100,000 records lost in a dumpster counts equally with a hacker stealing 100,000 credit cards from a web site, even though one loss clearly places the data at a higher risk for fraudulent use than the other.
Remembered as in life, not as the struggle through the end.
I'm sure your brother appreciates the sentiment.
Could be shenanigans, but they're using different metrics. OSF uses media reports to search for breaches that have been made public whereas TFA conducted a survey of "more than 600 Canadian IT security professionals."
After I posted it, I figure that if they weren't looking at 2009 (because most reporting is done on an annual basis), 2008 does indeed look pretty terrible by comparison to the rest of the years. Although TFA does say that in 2009 the security professionals are reporting 11 incidents per organization compared to 3 per org in 2008.
So, are the Canadian corporations better at hiding breaches from the public than the OSF indicates? Are the "professionals" overreporting and including counts of attempted breaches, like drive-by WEP attacks that go nowhere, or phishing emails, or viruses? Or is this a real count of actual breaches that caused a loss of valuable data, and they're just not telling us?
But "simple" does not mean "secure". Yes, simple is easier to verify, but you can write simple, clean code and still get hit with a security incident.
Code that is simple and secure today also doesn't mean that it will be secure tomorrow, once the next exploit is created and discovered. How long ago was it before javascript existed? Nobody cared if you put <script> tags in your comments, because browsers didn't even know the keyword "script". Suddenly browsers started appearing that supported this tag, and people got creative when posting comments, including cute scripts to animate their signatures. Then XSS attacks were discovered and became all the rage, and perfectly secure web sites around the globe suddenly had a new threat model that became their responsibility to clean up.
You can review simple code all day long and assure yourself that it will do what it's supposed to do. But it's very, very hard to review code to ensure that it won't do something bad, especially when you don't have tomorrow's definition for "bad" to review against!
That's because you're talking about CDs, and not data transfers among the clouds.
The original audio CD medium was designed to tolerate errors. If a bit goes bad when you're playing it, you don't stop and pop up a dialog to the user saying "ZOMG! BAD BIT ON TRACK 7! Retry, Cancel or Allow?" The player just compensates for the bad bit and keeps on playing. Similarly, a bad bit on a JPEG or in an MPEG stream won't prevent the images from displaying, or you'd never see a digital TV show, ever.
But that's not how you transfer data to and from machines on the internet. TCP is a protocol designed to detect some errors and recover from them. Digital signatures provide almost absolute assurance that the copied data is unchanged from the original. Placing data in just about any modern cryptographic digital envelope can give you the assurance that what is in the envelope is the same as what you put in the envelope.
Even bit torrent is good at providing lossless data storage and transfer.
So no, you can't compare CDs to cloud storage. They are not even close.
Oh no! This is nothing like fact-based reporting, either.
Look at the graph on the banner of OSF Dataloss. That banner, right across the top, shows the number of reported incidents, month by month, since Feb 2007. The 2007 average seems to be in the mid-40s. The 2008 average seems to be about 60 per month. The 2009 bar graph is steadily sloping downwards, starting from a high of 61 incidents in Feburary dropping down steadily to 23 last month and 16 this month.
To be a bit more factual, you can visit the statistics. That shows the progression from 2005-2009 looking like this:
2005 140
2006 530
2007 484
2008 703
2009 331
Nothing in the statistics even remotely seems as bad as last year, and this year's pace seems to be trending towards even fewer breaches than 2006's level.
I call shenanigans on this report!
No, it's a flightless bird with hairy feathers.
B.C. reference, anyone?
Follow the http://diybookscanner.org/ link. He says he's migrating it to there.
Some guy posted a great instructables on building your own high speed book scanner, purposely designed to rapidly photograph book pages without curves. He even includes a software stream that OCRs the contents and sticks them into PDFs.
It's been quite popular -- so much so that he's created an online forum at http://www.diybookscanner.org/ dedicated to discussions from DIY book scanners all over the place, where they talk about builds, parts, and software.
I've been very tempted to build one myself just to avoid carrying heavy books around in my backpack.
Apple's recommendation if you can't get MMS working or don't want to upgrade is to continue to send pictures via email. It's pragmatic but not the best solution for immediate mobile to mobile picture transfers.
How much people really need an instant mobile to mobile picture transfer solution is a different question.
Oh, sorry, you're absolutely right. I was confusing some of the salesman's spiel with some of the things we rearranged on our plan to switch to the iPhones.
For that matter it'll never got popular. This is partly because operators overprice MMS and because it doesn't really serve that much purpose.
Well, there are a couple of things that you got wrong here. First, overpriced or not, unlimited MMS is included as a part of the data plan you have to buy from AT&T when you have an iPhone. So cost won't matter.
The other is that one reason MMS hasn't taken off is that it's been hard to use on a lot of phones. On some of them the user has to know to go into a different messaging task, or to say create some kind of special message, and do some weird stuff they've never done before. On the iPhone, they added a little camera icon to the left of the text entry box. Couldn't be easier.
Since the "barriers to entry" have now been substantially lowered, iPhone users will indeed start to use the feature more.
I work in retail, you insensitive clod!
It'd be nice if I could join a group of like-minded computer enthusiasts, and comment on relevant articles with them, maybe even hold discussions.
Maybe some kind of rating system to filter out the spam. And a way to thread the discussion.
And it'd be neat if I could post journal entries and stuff.
Oh, right. I'm already on /.
I'd argue that the real metric is user perception, not raw performance. If you can keep the user entertained with a screenful of flying monkeys, you can actually load slower but be perceived as faster than a blank-to-full-screen transition.