Because running out of the box on OS X makes testing way easier. Currently we use DMGs, and performance is terrible.

I know a lot of folks develop on OS X, but this just seems like another argument to develop on Linux or a BSD.

But then, I haven't owned a non-Linux box in 16 years, so I may be an outlier...

It isn't an argument. DMGs are fine for development and testing and they can be made case-insensitive. Or you could just, you know, create a separate partition.

If the DMG speed is too slow for development and running tests(not testing with the full live dataset) you are doing something wrong.

So we shouldn't test using a snapshot of live data? Seems prone to finding errors only on production.

When developing and testing new features/bugfixes? Unless the bug is directly tied to production data I have no idea why you would have to use production data for that. I'm not saying don't do it on a staging server, but you don't develop on the staging server.

Right now I have a vagrant box where the VM images is on a DMG and all data is NFS mounted from the same DMG onto the VM, which is kind of the worst scenario I can think of. The testing database is around 2GB and the source+data files etc is ~200MB, just because I actually do need to fix a bug related to a portion in the production data. What's slow is the CPU, and that is still doing fine. It's not the disc even though I'm abusing it this way. That's on a 2011 macbook, 16GB, 400GB SSD.

HN is a small piece of software which should be easy to write tests for, 2GB db and 200MB source/data-files should be more than you'd ever need to work on something like HN. If you want to stress-test, test fs speeds etc you cannot do that on Mac OS X anyways since you're not running Mac OS X in production.

Changing the specs of a piece of software in order to make development more easy seems totally backwards. You're developing for production, not the other way around.

And at last, why not simply add a case-sensitive partition to your Mac if speed is such a big problem?

Any reason why you're not using Case Sensitive HFS+? I realize most people aren't so this is a nifty change but that seems nicer than using DMGs.

The only problem I ever ran into with it was needing to rename the internal file structure of Adobe apps since they were not particularly careful about matching file name case in code and configuration files. There were scripts to fix their apps. I hope the newer CS editions don't have that problem still...

Steam is also completely broken on case sensitive filesystems. Currently I run a case sensitive partition and store my source and /usr/local directories there. That way all my development is sane, and the rest of the OS can be stupidly insensitive all it wants.

> Steam is also completely broken on case sensitive filesystems.

Except, y'know, Steam for Linux.

We're talking about Macs and, last time I checked, Steam won't even install on a case sensitive filesystem on the Mac (or Windows). They have to on Linux—there's no other choice.

Suppose they want to change platforms in the future or release the codebase for others to use. It was apparently an easy enough change to implement now, so why not?

Pre mature optimization.

This is the exact opposite of pre-mature optimization. They have a mature product that works. We're using it right now. And now they're future proofing it a bit.