why not build an app for it, and sell it on the itunes store?

there's no reason to tie this to a single product. if they are making money off of one advertisement per half hour per user, then it should hold that raising the number of users significantly would also raise their profits.

who cares if it's from microsoft or apple? if the service is good, and can attract enough users to survive, then it could be a good product.

go to help & preferences, click on classic index - general, and check use classic index.

that got rid of it for me.

Ditto for MMS. What would be special about iPhone MMS, other than that all of a sudden millions of iPhone users are suddenly going to start using the service. Here's to hoping its simply a capacity problem and not a "how can we rape our customers even more" problem.

if it were a capacity problem, wouldn't we have already have seen it for the razr? it supported MMS from day one, and there were plenty more of those than iphones out there.

You were elected as a Republican, for better or for worse. You should either finish your term as one, or if you can no longer consider yourself a Republican, resign.

funny. i thought that he was elected as a senator, based on his values and the things he's done for his constituents. i didn't realize that once someone became a republican, or a democrat, or a libertarian, or a communist, that they lost all ability to do anything but the party line.

what a nice black and white world you must live in.

how about jump to top trying pause, then jump to top to pause view the pause, then jump to top page pause on an pause, jump to top iPhone?

is there any way to disable all of this behavior?

Everything else will require at least a medium rewrite at some point when you switch over to a real database. You could of course extend everything upon a glorified flatfile until your reinvented wheels strangles all your progress.

not really. i think that you (and, unfortunately, the FA) are missing the point that the map and reduce functionality, while powerful, have one major advantage: scalability. simply put, a query can be, by definition of the map function, broken up into several discrete operations and performed simultaneously on the data.

while this can be done in Oracle, using RAC, to some extent, the cost and complication is a major barrier to entry. Cache-Fusion, while typically good, can also end up being a liability when the cost based optimizer attempts to split up the query into atomic tasks in order to correctly parallelize the query. for instance, on one application of RAC (multiple multi-core servers, fibrechannel disks, and oracle clustered filesystem), across 100,000,000+ rows, when heavy writes were occurring, it was cheaper computationally to force a full disk scan, using hints, than to rely on Cache-Fusion to figure out what data was stale and what data was fresh. this was discovered after several days spent neck deep in tkprof output.

conversely, map, by design, already does this.

Linking to Wikipedia doesn't really make you authoritative, as an aside.

no, its puts things in context, and helps to make sure that we are using common terminology via definition.

anyways, your attempts at flamebait won't draw me in - you've already shown in this, and previous comments that you're just out looking for a fight.

if you were willing to learn about something, and not just make inflammatory comments, that would be something else entirely. i feel kind of sorry for you.

first some context. i architect data warehouses for a living. i also live in a world of building fairly specialized frameworks to deal with data warehouses architected as star and snowflake schemas. i tend spend quite a lot of time in pseudo-relational databases that don't fully implement codd's rules.

for fun, i like to spend some time toying with couchdb, using it for loose data warehousing, extending it, and generally enjoying the application development freedom it gives me.

that said, let me respond to some of your points:

Slacker DBs like CouchDB and SimpleDB, have taken off for the simple reason that most developers have absolutely mediocre database knowledge or skills, and rather than learning it's just as easy to just wave it all off as obsolete.

map/reduce solves a specific problem in data warehousing - column based lookups given specific rules, able to be broken down into atomics and performed in massive parallel. this allows for very cheap horizontal scaling over a large dataset.

It's no surprise that the creator of CouchDB, for instance, hadn't a clue about databases when he began his project.

this just shows ignorance. even just a cursory scan of damien's resume says otherwise.

what if i want to take a picture of something in front of me, on my desk, while i am sitting down. i've actually done this a few times, so it's not too much to ask.

hopefully there will be an easy override button i can press?

sometimes gadgets try too hard to be "smart", and end up infuriating the end users.

google for star schema - or snowflake schema, or denormalizing data.

but if you have so much data that 80 queries/second mysql 3 may not be the best tool for the job.

modern rdbms's rely on several nice tricks to make things a little bit easier, ranging from partitioning of data to join collapses, to materialized views, and partial indexes. none of which you will get from mysql 3.

The relational database is not going anywhere and nothing in that article is based on any firm understanding of managing data.

no, the relational database is not going anywhere, you are correct. but, that does not mean that there aren't instances where a non-relational database, with the addition of map/reduce, aren't extremely useful.

non-relational databases have been around for decades, and are in use for quite a number of applications involving rapid development and storage of very large records. couple this with map/reduce, and you have the ability to scale quickly with very large datasets.

scaling quickly is a very difficult problem to solve with an RDBMS - you either need to continue to throw more hardware at the problem, to the point of diminishing returns, or re-architect your data at the cost of possible significant downtime, while still attempting to serve up the data in a timely manner. i've been deep in the bowels of oracle RAC, fighting to get just 5% more speed out of a query over a billion rows and realizing that i have to start over with a new schema, just to squeeze more data out. compare that to simply adding another machine and letting the map functionality run across one more cpu before returning it for the reduce.

Is the notion of a "join" obsolete? No, but it is typically impractical in a high volume system. You would probably use denormalization as a strategy.

once again, correct, but having to denormalize to a snowflake or a star isn't always the best solution. you're taking the best parts of the relational database model, and throwing them out - normalization, referential integrity, just to squeeze more out of something that may not be the best tool for the job.

do you hammer with a wrench? i have before, and i managed to hurt my thumb.

throttle away.

amazingly, a lot of the webkit work appears to have made it back into khtml.

i guess that's not really contributing though, huh?