Fast, Easy, Cheap: Pick One

Just some other blog about computers and programming

Why Gentoo?

Prompted by the editor of DistroWatch.com Gentoo developer Ben de Groot recently appealed to the Gentoo community to post their reasons for using Gentoo. As a big Gentoo fan and long time I user, I feel inclined to respond.

I am currently responsible for maintaining an HPC cluster of 76 nodes, at roughly 360 cores. The nodes all boot off of an NFS-mounted Gentoo image that we have heavily customized. In addition, we have roughly 10 developer machines which use a different Gentoo image. To support this infrastructure we also have a number of servers, which perform all sorts of tasks: Serving files via NFS, PBS scheduler, netboot server, Xen virtual machine host, etc. All of these are also Gentoo. In total we have over 100 machines running Gentoo.

The whole setup is surprisingly easy to manage. I have set up a local portage mirror, and a local overlay for our own packages. Classes of machines use the same image, so bringing up a new developer box is just an rsync away. A new cluster node can be added just by plugging a macine in to the network and netbooting. Xen domU’s have a template from which they are cloned. For servers, there’s a bootstrap script which builds the machine up with the minimum amount of input at the start of the process. We don’t yet have a binary package host, but it’s something I’m looking at adding.

Some reasons why I love using Gentoo:

  • New versions of packages are quickly available. Some as quickly as the day of the release! For example, the recent OpenSSH 5.0 already has ebuilds.
  • System configuration is not hidden or managed by a restrictive GUI. I’m a configuration file kind of guy, and the way system configuration is handled in Gentoo is very nice for that.
  • You install only exactly what you need. There isn’t really a “default” set of packages, other than the minimum to get the system up and running. This is great for things like our cluster node image.

  • It’s easy to create your own ebuilds. An ebuild for simpler things can take as little as 5 minutes to write, and lets you manage deployment across the network. We also maintain a number of software packages in our SVN repository. With the Subversion eclass, updating an ebuild to pull from a newer release in our repository can be as easy as renaming the file. This is nice. That’s all for now. If you have any questions about our setup, please feel free to contact me and I’ll be glad to help you out.