Overall they aren't that different. If someone else is doing the provisioning and packaging, and you are just writing Chef or Puppet configs, there is little di

Overall they aren't that different. If someone else is doing the provisioning and packaging, and you are just writing Chef or Puppet configs, there is little difference. I pick the distro based on specific needs. If you run RHEL/CentOS you basically need the EPEL repository from the Fedora project. The differences come out when you start dealing with lower level things. In those cases I find Red Hat's approaches are more pragmatic (work better in the real world) while Debian's approches seem to strive for theoretical perfection. RH is optimized for the 90% use case, Debian is optimized for nothing (or is optimized for the 10% use case). Some examples: Kickstart vs Preseed: For PXE boot automated installs Red Hat's installer (anaconda) uses Kickstart for the configurations. Debian (debian-installer) uses Preseed (it can actually use some Kickstart configurations, but not enough to eliminate Preseed). Kickstart is easy, for example creating disk partitions and file systems can be done is a few human readable lines (zerombr, clearpart --all, part / --fstype=ext4 --grow). Preseed makes bizarre choices. You are essentially automating the interactive installer, including having to confirm all those dialog boxes that say things like "Are you sure you want you overwrite your data", "The previous configuration didn't use LVM and the new one does, are you sure you want LVM?", "This is your last chance, your data will be lost". So along with the partition configuration which is more verbose (not really human readable), you need lines like (d-i partman/confirm_write_new_label boolean true, d-i partman/choose_partition select finish, d-i partman/confirm boolean true). It makes no sense that an automated install is not automated, but some will argue it's more powerful. Package init scripts: Debian WTF?! Debian packages usually use a helper program called 'dh_installinit' to install and manage their init scripts. The defaults of dh_installinit are horrible, and most packages seem to stick to the defaults. It defaults to starting services when the packages are installed, which is rarely what you want to happen. Almost always you want to configure the service and then start it (optimizing for the 10% use case). When you upgrade a package it defaults to stopping the service before the upgrade and starting it again after. Very few services require that. I don't want my web server stopped are a few minutes while packages are upgraded. Conversely Red Hat actually have a hot binary restart option in their Nginx init script, so you can do a package upgrade and restart with the new binary with no downtime. If you want to see how crazy it gets read line #132 of the iptables-persistent init script. They actually disable the stop function (required by LSB) because if they didn't it would disable the firewall during package upgrades: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/iptables-persistent/precise/view/head:/debian/iptables-persistent.init http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/... Ubuntu is half-backed: Even Ubuntu's LTS releases have half implemented features and very little documentation about new/changed features. The most annoying case I encountered was their switch to Upstart as the init system for 10.04 LTS. Some services (like apache2) had normal init scripts in /etc/init.d, others were moved to a new Upstart configuration format (like sshd). The services with the new upstart format had symlinks in init.d that that printed a message that it wasn't a real init script (but didn't actually manage the service). They didn't document this, or tell you how to manage these new init scripts. None of their service management utilities were upgraded to handle the new init system. If you ran 'update-rc.d' it would symlink the non-functional message script the rc.d directories, so on boot or shutdown it would print a big message and not actually start or stop the service. On the flip-side, Red Hat also switched to Upstart. But Red Hat did it in a totally seamless way, all the init scripts are still fully functional in init.d, 'service' and 'chkconfig' work as expected. And the system gets all the benefits of upstart (smarting ordering, faster boots) with none of the downsides. The one minor change that Upstart had (the contents of /etc/inittab) is clearly documented: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_Notes/deployment.html https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enter... Packaging: I think packaging and creating repos in Red Hat is more straight forward than Debian. Lots of people will disagree. Debian's systems seems over-thought, like they tried too hard to make is perfect for everyone, which just ended up making it more complicated for everyone. All that being said, I still pick Debian-based systems a lot. Mainly when I want a specific package or package version. And when I write Puppet modules I make sure they work on both.