mikealrogers

This is perhaps the most depressing response I've received to my article.

As I said in my article this is far less about git and more about the chasm that has grown between Apache and the rest of the community.

Your first two points boil down to "nobody makes you join Apache, if you don't like our policies then you can get out". How does this help Apache or its projects?

Apache could still be valuable to the community but this kind of stubborn attitude will insure that it continues to become irrelevant when it could be a leader.

I do understand the purpose of Apache and it is not hosting source code. That is the point I'm trying to make. If that is not its value, and its policies around hosting that source are no longer beneficial to its projects, then it should change its policy.

I think that you, and many people in the ASF, have married the existing policies of Apache with the purposes for which they were created. While the intentions of the policies may still be relevant, and in my opinion correct, the policies themselves will not remain relevant forever in a field as rapidly evolving as technology and GitHub may just be the first example of Apache policy incompatibility with evolution of open source.

This was a good analysis of why the prominent CouchDB companies didn't spent time/money evangelizing the project but it didn't cover the dramatic difference w/ how 10gen handles MongoDB.

10gen spends all their time and money marketing MongoDB. They appear to spend more marketing it than on engineering it. They can afford to do this because their "product" is MongoDB and not an alternative MongoDB based product like the prominent CouchDB companies.

Very little attention is paid to the fact that MongoDB is AGPL and that they are one of the first companies to bring the extortionware business model of the GPL to software as a service via AGPL.

http://www.mongodb.org/display/DOCS/Licensing http://www.10gen.com/commercial-licenses

you know, it's really frustrating how reasonable you always are :)

your expectations with coffeescript have always been great and in line with reality.

i think the frustration isaacs, and myself, have had with many other coffeescript users is that they expect us to take on the work of supporting it to the same degree we support development in javascript.

you have to understand that the purpose of the "javascript is assembly" mantra is to give the impression that writing applications in javascript is a waste of effort compared to using a JS-to language. it infers that there is an order of magnitude difference, which is why isaacs is calling out that it is not.

the mantra is very common when asking for others to do more work to accomodate coffeescript programmers. it gives the impression that our resistance to doing the work is because we all have grey neck beards and expect others to live in the dark ages of programming with curly braces.

C++ can be a "worthwhile difference" over C for some people. others hate it. it's a much more realistic comparison.

if everyone using coffeescript had your demeanor and expectations our world would be a much better place.

I wrote this, quite a while ago.

MongoDB implemented an append only log which is not enabled by default.

The rest of the article is still accurate, and the fact that durability isn't on by default IMO continues to prove that my characterization of their attitude towards durability is still accurate.

on top of IndexedDatabase (which in Chrome uses leveldb).

It actually works with any file, it's just that HTML files get a DOM and jQuery to help you manipulate the page.

It's conceivable to add additional tools in the future (YUI, dojo) and even maybe some tools specific to help creating css.

Having the filesystem be the API makes the caching semantics quite nice and extensible.

node.js camp, which will be awesome, is a tutorial day where you'll go from zero to a functioning realtime application in one day.

Joyent is doing a great job putting it together and I'm excited to speak.

NodeConf is a slightly larger community event that is more like a typical conference and less like a tutorial. It's also going to be a gathering point for the node.js community to come together from around the world.

More announcements soon, be patient and try not to be a dick.

this was part of my initial reaction.

when CouchDB is under concurrent load it does a "group commit" style write anyway and can batch nearly as efficiently as bulk docs. the only additional overhead would be the HTTP headers which is nominal when the documents are a bit larger than "hello world".

in general CouchDB does better under concurrent write load than single writer and while these kinds of optimizations on the client side can be impressive it's not actually what CouchDB is tuned for OOTB.

would you be willing to write up how your writes were outrunning the compactor in a little more detail in either a blog post or in an email to the apache couchdb dev list?

we've been talking about possible improvements to the compactor and having a solid use case that outruns it would help focus that.

i find this whole thing a lot more of an experiment in clojure performance than CouchDB throughput.

he doesn't attach a handler to the response on his writes and is queuing writes in memory and bulking them. he's not concerned with durability at pretty much any layer.

this kind of setup is great for a large initial import of data but i would be weary of running it in production.

I've said it before and I'll say it again: if callbacks are so hard how come all these liberal arts majors write a shit load of working jQuery code?

I think the real problem is that callbacks are too simple for people that want to obsess about engineering new primitives and programming styles.

traditionally durability isn't considered a sliding scale, it's a goal/priority which requires you to implement multiple features and fallbacks to handle everything from invalid writes, crash during write, to the data center catching on fire.

thinking about durability this way may work great for MongoDB but it isn't how durability is framed in the rest of the database world.

it's easy to make something fast if you don't want durability, just look at memcached.

copied from my blog:

@kristina

for some reason wordpress wanted me to moderate your post so sorry for the delay in it showing up.

>> Whoopsy, got your emphasis wrong there ….. Seriously, though, this “unchecked” type >> of write is just supposed to be for stuff like analytics or sensor data, when you’re getting >> a zillion a second and don’t really care some get lost if the server crashes.

did the default change? the last time i attempted to a concurrent performance test this was one of the barriers i hit. my issue isn’t that you include this feature, it’s that it’s the default, i certainly believe there is a use case for it i just think it’s harmful as a default.

>> Since CouchDB is “not a competitor” to MongoDB, it’s nice of you to put all this time >> into a public service.

haha, that’s funny. i regularly use non-CouchDB databases and I get along great with all the people from other databases at conferences. even if i did feel like we were competing, i wouldn’t care. this post really is about reliability issues i don’t think your users are fully aware of and i honestly hope that you fix.

>> fsyncs are configurable. You can fsync once a second, never, or after every single insert, >> remove, and update if you wish.

that’s really good to hear. have you optimized for a “group commit” yet?

>> This is because you assume you’ll run it on single server. MongoDB’s documentation >> clearly, repeatedly, and earnestly tells people to run MongoDB on multiple servers.

I responded earlier to the complexity of actually keeping something available that depends on this. so i won’t cover it again.

>> That’s not to say that things never go wrong, MongoDB is definitely not perfect and has >> lots of room for improvement. I hope that users with questions and problems will >> contact us on the list, our wiki, the bug tracker, or IRC (or, heck, write a snarky blog >> post). Anything to contact the community and let us try to help. I wish every person >> who tried MongoDB had a great experience with it.

You make it sounds like this is all just a matter of bugs, it’s not, and i find blaming it on users who don’t use JIRA or get on IRC a little distasteful.

these issues are architectural and until you do something append-only they aren’t going to go away. someone mentioned earlier that you plan to do an append-only transaction log, if that’s accurate then it’s fantastic news.

that's kind of like saying "we told you our parachutes won't open sometimes. well, not in our conference talks or in our marketing but it's on our wiki and we blogged about it".

if you want to see a message that is clearly delivered about (lack of) durability look at memcached. nobody misunderstands memcached's durability/consistency guarantees.

-Mikeal (after a few drinks)

wait, seriously?

the suggested default step 1 for MongoDB is to acquire 3 servers?

i mean, no other database suggests such a huge default configuration. even knowing that their datacenter can get hit by lightening and all a lot of large production sites don't even run with this kind of redundancy.

this seems like a pretty taxing workaround for not keeping an append-only transaction log.