When a No means Yes | Hacker News Reader

When a No means Yes

hackingdistributed.com

89 pointshoonose38 comments

Headlines like this are the casual references that makes tech a boys club. You don't think you're doing any harm, but by distorting an important argument about rape, you're undermining the sentiment behind "No means no" even as you use it in a different context.

Congrats on invoking Godwins law on a topic not related to the thread.

Where did brennenHN invoke Hitler or Nazis?

http://en.wikipedia.org/wiki/Godwins_law

Uh, technically, you did.

Agreed, that headline is totally rapey.

Hair-trigger, there.

You're absolutely right. I have zero tolerance when it comes to cultural acceptance, denial, or apologizing for rape.

We all know what the title is referencing, and it's implying that there are circumstances when "no means no" isn't true. The content of the article may be unrelated, but the title is still problematic.

This post is basically the same thing as complaining about the existence of hot dogs. We all know they're just a device to institutionalize the act of fellatio.

The title is not problematic because he's describing a false negative. Context matters, you can't call "rape" every time someone puts these three words together because they are normal words that can be used to describe non-rape concepts. If your comment dealt with anything but a refusal to engage the words on their own terms I might be a bit more supportive of your stance here, but there simply isn't any "there" there.

Trigger warning for data corruption and poor public relations.

And of course the HN boys club doesn't see anything wrong with the headline. I expected nothing less :(

Seriously, people: "No means yes" is a clear reference to "No means no". It's a really bad choice of headline, because it communicates "I don't care about issues that women are facing, if it gets me a catchy headline".

I'd be inclined to be ambivalent on this, except that in the OP there is no literal "yes" or "no" involved (i.e., something like, "I set the MONGO_UNSAFE_DATA_COMMIT flag to 'No'") so I'm not even sure what the headline means, except that it gets a little edge parodying the anti-rape saying.

At least you can't blame the OP for thinking too much about SEO.

I clicked on the comments just to see if anyone noticed this shit; thank goodness you did.

I did the same thing and no one had yet

Could we please stop with the intellectual terrorism on HN?

People can't write a blog entry anymore without being labelled either homophobic or sexist.

What's your take on humor btw? You know, like stand-up comedians making fun of white people or making fun of black people?

My take on humor is that if you need to make racist jokes to be "funny", you're pretty bad at your job as a comedian.

There's nothing funny about racism, sexism, or other discrimination. And if calling out people for being utterly insensitive and dismissive of minorities makes me an "intellectual terrorist", I'm happy to accept that label.

"No means Yes" has many meanings [1], many having no rape related sentiment at all.

[1] http://tvtropes.org/pmwiki/pmwiki.php/Main/NoMeansYes

We recently have been having to work around an issue that, on top of all the other issues we've had means we're moving away from mongo entirely. The current issue is that a mapreduce on a cluster into a sharded collection will, at some point, start silently not writing 30% of the data into the sharded collection. And from that point onward, roughly the same amount of data is lost any time it goes to that collection. We have to watch for it and create an entirely new sharded collection to mapreduce into, then everything works fine for a while until that one starts not getting some data. When we create a new collection, we just pick a new name, copy all the previous data over, update the MRs to point to that collection and hit go. I would be able to understand data loss caused by certain durability settings from a client, but on mapreduce results?

I almost feel like I am missing out on hating MongoDB with others, because for me it just works, and _nothing_ I have seen people complain about is really a problem for me. Even in this article your upset because if you have multiple threads using a single connection the getLastError message won't always report the query form the current thread ? That's like saying your upset because the linux kernel does not let other threads know your in the middle of a mutation of a memory address so it may get corrupted. Its your fault deal with it.

Then your upset because in the past it didn't preform like you wanted it to so somehow that should be factored into the _current_ reliability ? My takeaway is you didn't care enough about your data in the past to understand your persistence layer why do I feel you are going to do the sane thing in the present and understand your persistence layer now , it appears if it doesn't work like you want it to by default then its broken and 10gen should really be making a datastore just for you. I am more annoyed that I need to now specify that I _don't_ want to wait for confirmation of write, but I at least took the time to understand how the DB works and what I need to do with it.

What is your usage of it? Saying it works for you might mean nothing at all if you do 5 ops/second on average and have < 10 gb of data or something.

Non-gamers are perfectly happy with a shitty graphics card too.

Does it matter? We do a pretty continuous 400k ops/s worth of Mongo, but I don't think that's necessarily going to fix anyone's issues with it.

400k ops/s?

How many machines is that?

I can do it one one.

It was a bit snarky, but the points he made were based in fact not opinion. I personally like and use mongo, but I don't pretend it's perfect.

Has anyone considered that maybe MongoDB attracts developers because its extremely easy to use?

Consider their great homepage scenario:

  - click "try it out" 
  - type "tutorial"

Couple of minutes later you know enough MongoDB for most CRUD apps.

Or the restriction-less API:

  - collections simply come into being.
  - store arbitrary objects without schemas
  - create arbitrary indexes
  - search by arbitrary conditions

I can't imagine how one would go with lowering the barrier of entry even further...

Yes, this is mostly marketing and usability. No, you can't skip on those and rely only on technical superiority - you have to fight on all fronts.

This guys arguments are really bad because he makes them from a very narrow one sided point of view. It is actually hard to read through the hatred....

> First, the 10gen spokesperson seems to have read only the H2 elements on my original writeup -- he seems to not have read or understood the actual text that goes along with them. Do they have some local CSS applied that makes regular text invisible?

Couldn't read past that.

Why? It was accurate, and it does you no favors to brag about not reading an argument.

I suppose I was just not in the mood to read an article filled with such an overt tone of condescension.

Actually he is quite right and MongoDB is a disaster when it comes to data reliability. The fact that some facts are hard to accept as true and cause feelings to be hurt doesn't change their validity. Not every piece of software is good just because a lot of people use it.

I don't read it as hatred at all.

If you read the Mongo rebuttal it seems as though they willfully misconstrued the points he made in his original post.

Mongo was broken by default in 2.0, that's why they changed the default behavior in subsequent versions. The author even went out of his way to talk about the changed behavior in his first post.

I don't know, this is the first critique of Mongo I've seen that really attacks Mongo stability and I'm eager to see how Mongo responds. The author is correct that Jason's (from Mongo) response left a lot to be desired.

Yes the author appears to dislike Mongo, but if his reasons are correct and his points are valid, discounting his opinion due to word choice seems unnecessary.

I am not discounting due to word choice, i am discounting because his points seem to be a rant based on the whim that software never has bugs or problems. For some mongo does exactly as advertised, for some it doesn't. It is the same argument that you can pose between eventual and immediate consistency.

Also i will be the first to agree that Mongo does not hold up well to all points but to say that data gets lost is pretty bold. I have been using it for quite some time now and by following mongo best practices, i have not lost any data. In fact by following mongo best practices i have saved myself from a few data-catastrophes.

The argument that it doesn't come configured correctly out of the box is pretty weak too (at least that is how i am reading his statement of "broken by default"). What is configuration too hard. Sure they put their software out in a way that is more in tune with a lab / development atmosphere... but if your using mongo in production and you do not do the proper configuration steps, then maybe you should hang up your devops hat and hand that job off to someone else. Even mysql sucks for production out of the box, it is a security nightmare. Innodb looses data when shutdown incorrectly especially if the journal is corrupt. Saying that there is only one drive fault tolerance just means that your not striping your data properly. All the arguments are based upon a lazy implementation not actual problems.

And YES you should know something about how your backend software works. You should know it intimately so that you can debug and make it more bullet proof. So ya, i think the arguments are weak and full of hate and not something made off of experience and ability to work with a software vendor. Do i think mongo is perfect for the tinkerer like mysql is, no. Do i think mongo is good enough to hold BI data that is critical, yes.

SO I think we're almost having two separate arguments here.

On the one hand we're talking about Mongo working out of the box and on the other we're talking about developer skill. I'll agree with you that an unskilled developer is going to have a bad time running any Database, but I take issue with the idea that defaults aren't important.

The default settings are the defaults for a reason. Whether that reason is ease of adoption or performance testing, there's a reason. Mongo's default behavior was not sensible and has since been corrected to be more sensible, and I think we both agree on this point.

Mongo is a really cool database with a lot of neat features, but it doesn't get a pass just because it's cool. If the defaults on Mongo could cause data loss, they should change the defaults, right?

I agree you should understand your backend, but I also see a lot of value in having sane default settings. To be honest, the majority of users may never pass beyond the default settings, which is a shame, but true.

So the author's rant is just that, but he's not wrong. He might be mistaken about the potential of Mongo, but he's not really mistaken about Mongo "out-of-the-box".

Does that clarify my position with respect to the author's opinions?

With the default settings in MySQL if you shut down an innodb database incorrectly you will loose data if not the entire table, should we vilify them for the same thing.

I am not saying he is wrong, and i am not saying that mongo is wrong either. I feel, if you RTFM, that they are very very clear as to the state of things. They are not hiding anything and if anything they are providing and application state that is not ideal for said user too bad IMO. I am not going to setup a new linux box without changing the root password, or setup a wordpress site without altering the config and locking down apache. Did you know a linux system is not 100% secure out of the box, WHAT A SHOCKER.

Fair points sir. Fair points all around. Cheers.

> With the default settings in MySQL if you shut down an innodb database incorrectly you will loose data if not the entire table, should we vilify them for the same thing.

Yes, we should. I do not think shipping unsafe defaults is ok.

> I am not going to setup a new linux box without changing the root password

This is why most Linux installers prompt you for the password.

> Yes, we should. I do not think shipping unsafe defaults is ok.

Isn't it the difference between shipping a product open enough and with enough barriers torn down to get the hobbyist hooked (drug dealers) and the expert will have a script to fix all those hols anyway. And agreed, shipping with unsafe defaults is bad for the expert but very very good for the novice.

> This is why most Linux installers prompt you for the password.

The key word there is MOST.

I wouldn't call it hate. He's clearly very frustrated that he carefully worded his points, only to receive responses to points he didn't make.

We've all had those co-workers who come to us with tough to debug problems that we correctly diagnose for them and lay out for them, only to have them gloss over the details and claim the issue we found isn't an issue at all. Their inability to follow the details was the root of their inability to debug the problem. In the case of the blog post, the guy who diagnosed the issue is the one coming to the person with the bug, but this blog post is the same old your-inattention-to-subtle-detail-always-makes-you-come-to-me-I've-always-been-right-in-the-past-so-just-try-my-suggested-fix-before-arguing argument, but happening out in public on the Interwebs.

Reply on news.ycombinator.com