functional_test

What's the upside to this? Larger size, potential legal issues -- all for an Easter egg?

People defend it, and it hasn't been taken out in 1.0, but it seems like an all downside trade.

I see the value of Easter eggs, but the fact that this issue keeps coming up should be enough of a sign that it isn't worth it in this case.

I'll ask again, what else do you suggest?

Anonymous sources of information are generally recognized as less credible (for example, they have less reason to be truthful since they have no credibility on the line).

Of course, the larger problem isn't the anonymity of the authors. It's why the bible should be accepted over any other text. Perhaps it should, but that would have to be argued separately.

I did not say that it was the only way, please don't put words in my mouth. I said it was the standard way (which it is).

What other methods would you suggest?

Because if you don't require evidence proportional to the claim, your world view can end up including any and all beliefs, which is neither interesting nor useful.

One of the classical ideas in epistemology is the justified true belief theory of knowledge [1]. This has flaws (see: the Gettier problem [2]), but it's a reasonable approximation. Obviously what qualifies as justified is a debated topic, but it's generally agreed that "no justification" is not a justification.

[1] http://en.m.wikipedia.org/wiki/Epistemology

[2] http://en.m.wikipedia.org/wiki/Gettier_problem

Based on what?

This is a genuine question, not snark. Serious claims like this require equally serious evidence (and if you have some, I'm quite interested).

To make a point. Let's be honest, the money probably wouldn't be life changing, but establishing a precedent in matters like these actually could be.

Avoiding questions because of theoretical potential outcomes of people knowing the answer is neither good nor useful. Knowledge is not implicitly dangerous or immoral.

Also, in this particular case, it seems that the people interested in that sort of thing could figure it out anyway. Obscurity isn't security.

Have you used an OXO measuring cup? They really are a lot easier to use when baking and cooking, and my sponges never have a problem getting in those corners.

It sounds like you subscribe to Materialism [1].

In fact, these are widely debated questions. Materialism is only one of many philosophies that seek to answer these questions (e.g. dualism). Be careful about accepting answers like that if you haven't examined at least the major alternatives.

[1] http://en.wikipedia.org/wiki/Materialism

It shows good faith. It shows your willingness to negotiate.

You can go through life upset that the world doesn't work the way it "should" - you can even refuse to participate like the original poster. But you will generally have a worse outcome, so is it worth it? Why not play along, just a little?

Same thing goes for: dressing up (why should it matter if I'm in a suit?), sending thank yous (why should it matter if I already said thank you?), and just about any other social grace.

You can't possibly be serious. You pocketed his ~$12K loss and you're giving him a $50 credit? Are you high?

Sloppiness like this wouldn't fly in actual finance. It would get you fined and possibly more. Lacking any sort of internal controls, even something as simple as balancing your books and verifying all transactions... It's shocking and negligent. Even more so for a YC company. Shame on you.

"The Amazon system is characterized by low wages, permanent performance pressure and short-term contracts" - one of the union board members

For me, this sentence captured the entire article. Of course the wages are low-- the jobs require no skills and have been largely automated by Kiva et al.

It's hard to argue that performance pressure is a bad thing -- logistics is an industry where performance matters. And again, the competition is robots.

Complaining that contracts are short term does have some legitimacy. That said, it's clearly a seasonal business; do the unions honestly expect them to hire people year round when they just aren't needed?

I really want to be on the side of the people, but I'm afraid that asking for more money/longer contracts/etc. is just a way to make the automation even more compelling.

The primary "unreasonable" default seems to be that in the beginning, writes were not safe by default. Although they were explicit about it (if you read the docs), it probably was a bad decision. This has been changed, thankfully.

As far as maintenance, it's unreasonable to expect that you could have a zero maintenance configuration. What other software does that? Your operating system doesn't. Your browser doesn't either. Nothing is immune to entropy.

I seem to have been able to use it correctly. In fact, I ran a cluster for years in production without any issues. I know of several other groups that have used it successfully as well.

As far as I can tell, a lot of people assumed it worked like a SQL database. It doesn't, which disappointed them. I'll even admit that some of the original defaults like the write concerns didn't really make sense as defaults. But that was all in the introductory documentation. Major subsystems like databases deserve at least a skim of the documentation if not a full read; if not up front then at least before putting them into production.

In a proper production environment, you just compact each slave one at a time because you have a replica set rather than a single instance.

Of course, if you aren't replicating your business's production database, you have a whole world of problems.

Seriously, another case of using Mongo incorrectly? I want to believe all the Mongo hate, but I can't because I always find out that the actual problem was one or more of:

* didn't read the manual

* poor schema

* didn't maintain the database (compactions, etc.)

In this case, they hit several:

" Its volume on disk is growing 3-4 times faster than the real volume of data it store;"

They should be doing compactions and are not. Using PostgreSQL does not avoid administration; it simply changes the administration to be done.

"it eats up all the memory without the possibility to limit this"

That's the idea -- that memory isn't actually used though; it's just memory mapping the file. It will swap out for something else that needs the space unless you are actively using all the data, in which case you really are using all your memory. Which is why you should put it on its own server...

"it begins to slow down the application because of frequent disk access"

"Finally we sleep quietly, and don’t fear that mongodb will drive out redis to swap once again."

You should be running Mongo on a server by itself. At the very least, if you're having disk contention issues, don't run it on the same server as your other database.

I'm not sure you always need to read the manual for everything, but for your production database, it's probably worth it.

I just don't think the snark is necessary here. I'm pretty technically savvy and I found the wallet setup process to be... unintuitive. For example, transactions didn't show up until I told my wallet to sync back to before I created it because Multibit doesn't sync by default to a sane time.

Also, it's demonstrably less safe to give your Bitcoin wallet to a site than to give your cash to a bank. To imply that the security and insurance of these sites is comparable to banks is laughable -- you frequently hear about sites getting hacked and losing all of their BTC.

Of course, banks have other problems (depending especially on how you view the Fed), but disingenuous claims like this do nothing to help Bitcoin.

Yep, this time is different [1].

In all seriousness, if you really believe this, I suggest you pick up a copy of that book. History doesn't repeat itself, but it does rhyme, and you'd be surprised just how similar this time is.

[1] http://www.amazon.com/This-Time-Different-Centuries-Financia...

Exactly. Although rebasing is convenient, it does involve taking destructive actions on a repository which is ostensibly a tool to make sure your data isn't lost. The feeling in the Mercurial community is that this is potentially dangerous and not necessary.

Really, it would be best if there was some way to retain the original commits while rebasing to clean the history. Time for a new DVCS?

Check my comment history, I've given several use cases. Basically, Mongo is nice if you don't need a lot of relational stuff but do have lots of arbitrary data to store. A good example is time series data where the format changes over time -- often it's not a good idea to go back and convert old data (sometimes it's not even possible). Mongo makes it really easy to support multiple schemas if your business requires it, rather than having to maintain arbitrary numbers of different tables.

This is spot on, no one would actually follow that protocol.

Tangentially, the best side effect of HFT seems to be that a lot of technical people have become more sophisticated in understanding incentive structures and contracts. I wonder how that affects funding decisions for startups of the ex-HFT crowd.

Turns out you can read the manual of a vehicle ahead of time. Turns out you can also test drive and do everything else you said, and we don't need to pretend that it's all mutually exclusive. Stop being a pedant -- me listing every bit of due diligence about my car isn't relevant, so let's stay on topic.

Honestly, how can people on HN actually be this against reading? Especially things that are really important? Sure, don't read the contest rules for your McDonald's monopoly. But if the data for your livelihood depends on something, there's no excuse for not reading the documentation.

If understanding your production database is a bad use of your time, then I really don't understand your priorities, but I'm glad you're not on my team.

You don't need to read every word of everything, but some things are worth it. Do you sign contracts without reading them too since it's a "terrible use of" your time?

Literally 1 month ago, I bought a car and did exactly this. What's impractical about spending a little time to read?

Wouldn't that become quite a bit of book keeping though?

I'm not sure how anyone else could know what my best interests are. There are a lot of real world applications where small amounts of data loss don't matter but latency matters a lot.

Any time I deploy something as critical as a database, I carefully read about what it does and how it works. Not doing so is like signing a contract without reading it.

Generally I'd only have at most 2 formats at once while you converted the older records to the new format. You're right that there's no sense in keeping around a dozen versions but there are a lot of business cases for having two versions of a schema active at once. For example, if you can't bring down your application to convert everything mid-day and instead want to do an incremental conversion.

I would also read the manual of a car I just bought before driving it. I guess that's just my style.

Don't get me wrong, I'm not saying your assumption is unreasonable. But in the end, it's on you as a conscientious developer to read the documentation. I'm not even suggesting cover to cover - in this case though they are very up front about write concerns. There is no real excuse to find this out any other way, it's just negligence.

The file system is great for some things, but, for example, how would you handle the same data to having multiple indices?