Choose OpenBSD for your Unix needs. OpenBSD -- the world's simplest and most secure Unix-like OS. The world's most used SSH implementation OpenSSH, the world's most elegant firewall PF, the world's most elegant mail server OpenSMTPD. OpenBSD -- the cleanest kernel, the cleanest userland and the cleanest configuration syntax.
With Linux, it's lot of beating around the bush. Overcomplicated config files, a lot of disabling and removing of things one don't need, having to deal with a messy and outdated firewall. With OpenBSD, I'd just have to change a few config file lines and lo and behold have one of the most secure and well-thought out servers the world has ever seen.
Also, with the existence of Puma, I don't see why anybody would want to use Passenger.
At least with Linux I don't have to wait 6 hours for all my software to finish compiling. Think about all the trees that are unnecessarily cut down because of all that compiling. And support for Linux is much easier to get than support for OpenBSD.
TLDR: Passenger takes a more holistic and integrated approach and is a lot easier to use. It has superior management and administration tools, superior robustness features, superior security features (e.g. sandboxing through user switching), better documentation, uses less memory, etc.
OpenBSD doesn't require compiling, it has precompiled packages just like Linux.
Yes, support for Linux is much more wide-spread, but that's due to marketing and not the quality of the OSes themselves.
As for Passenger vs Puma, no management and administration tool is more superior than the Unix commandline. Plus, you don't need fancy sandboxing features assuming your OS user account is properly secured in the first place.
You mention superior this and that, but I find it all hard to swallow as I know you guys go around spamming Puma-related articles and tutorials with stuff about Passenger.
OpenBSD only has a small number of precompiled packages, and usually extremely outdated. If you want to get anything useful you have to compile ports. As for the question of whether Linux being widespread is due to marketing or quality: that is completely irrelevant. The fact that Linux is more widespread is all that matters. We don't live in a theoretical world where only theoretical technical superiority is the only thing that matters.
You are right, no management and administration tool is more superior than the Unix command line. The thing is, Puma's Unix command line tooling is almost nonexistant. All of Passenger's management and administration tools are command line tools.
You are also correct in that you don't need fancy software to do things for you when you can do all that stuff yourself. It's a bit like saying that Docker has no added value because you can setup LXC yourself. But it's not hard to imagine why so many people do find value in Docker.
As for spam: yes you are right, there have been times in the past when we were overly eager with promotion. I apologize for that, and we've since adjusted our strategy.
Having said that, our claims have always only been based on facts. For example: how do I find out what requests my Puma processes are currently handling, and how long they've been active? Where are the tools to query that information?
I never knew about CheckInstall: a utility that tracks all the files modified during "make install" and creates a Debian package for them. That's just great! Bonus: you can then use the package it creates to install on other machines. https://help.ubuntu.com/community/CheckInstall
Rather than installing Ruby 2.1 from source using rbenv, it is also possible to install Ruby 2.1 using APT, by using the Brightbox PPA: https://launchpad.net/~brightbox/+archive/ruby-ng
The Phusion Passenger APT packages are compatible with the Brightbox Ruby packages.
This. I'm so grateful to Brightbox for having relieved me from the rvm/rbenv madness. Same painless packages on both development and production. Priceless.
That's a great guide! We realized that a lot of people were spending a lot of time on stuff like this, and that's why we built Cloud 66. We help you to deploy and manage your applications on any cloud (ie. DigitalOcean, AWS, Rackspace etc) - feel free to check us out http://cloud66.com
This write up is something that I've been looking for. Some folks at the local Rails meetups have also told me about Dokku, which facilitates deployment for sure, but I'm left wondering what the ramifications/disadvantages of an automated process (like Dokku and I guess Heroku) vs a "proper" setup like this one described.
I can attest that the ruby-build project is a huge lifesaver. If you need to build an experimental ruby, it's the way to go. You can install it completely out of the system path. I really appreciate the effort that was put into it because it probably saved me about a week of work.
Bad firewalling advice imo. Use ubuntu's ufw. Admittedl, ufw feels more difficult if you already know iptables, but it's way more robust than the example given there.
Which makes me wonder, which is the correct way which lends itself to automation and doesn't depend on AWS/AMI?