Ask HN: What Linux distro for a Rails app that needs to scale?

On the other hand, if you use a distribution that somehow 'benchmarks' marginally better but you don't know how to configure it or deal with it properly, you'll end up losing any performance gains you otherwise would have had. Better to deal with a distribution that works the way you do (Which is why a lot of people like CentOS or Ubuntu Server) than end up making a major mistake somewhere because you are in unfamiliar territory.

(Gentoo? Blech. -funroll-loops.)

We use Ubuntu 8.04 LTS because it is committed to be supported for a very long time. Traditionally Debian releases have been supported with security updates and the like for one year after the subsequent release. There's no guarantee or date for Debian. Ubuntu 8.04 Server Edition on the other hand is supported through 2013... and that very well might turn out to be longer than Debian 5.0.

And if the answer is "visualized it" - then compiling is a waste of your time to being with. Better to run native from packages than virtualized from source.

I was right there with you until this bit of crazy.

Do not build everything from source. You're just asking for trouble when you do. You lose so many really important features of modern Linux distros when you do this, that I can't believe people are still suggesting it as a sane practice for production servers.

If you install from source you won't be able to update quickly and easily via apt-get or yum when a security update comes out...you'll have to rebuild. But, you probably won't even know a security update exists until it's too late. If you don't keep copious and specific notes about what your custom build does, and why you did it that way, you will forget a flag or overwrite or lose a config file, and it will break something next time you roll out a new version.

The performance benefits are probably negligible, and in my many years experience cleaning up amateur maintained systems, it is just as likely to be negative as it is positive. You probably know dramatically less about the package you're building than the maintainer of the OS package, and you're more likely to make mistakes than they are. Those mistakes could have security implications, performance implications, or stability implications.

Certainly, if you are the maintainer of some piece of software, you might want to replace it. I've never run a system without at least a few custom builds...but the custom pieces are usually software that I am one of the core maintainers of, and I know it better than just about anybody. And, when I do run custom software, I tend to build an RPM or deb of it, and setup a local yum or apt-get repo, so that when I need to replicate my production machine, I can do it quickly and consistently.

You're working against the grain if you go BSD instead of Linux with Rails, whether you like FreeBSD or not.

For the past several years, and up until FreeBSD 7 you've always been seriously misled. FreeBSD has historically had dramatically worse performance in most concurrent server applications (certainly in multi-process SMP workloads). As of FreeBSD 7, it generally is the equal or slight better of Linux. It is not better in enough categories or by a large enough margin for anyone to say with confidence that a particular workload will perform better on FreeBSD or Linux. One would always have to benchmark the actual application, and the differences would be minimal in most cases...and with every new kernel release, you'd have to benchmark again, because things change and performance advantages might flip from one release to the next.

And, tptacek is correct, none of the other BSDs has inherited these dramatic performance improvements found in FreeBSD 7, so they are very unlikely to provide better performance than any modern Linux version on modern multi-core hardware.