How should an IT department choose a standard Linux distribution?

I currently work in an environment that has used Linux for more than a decade. Everybody in the office uses different distros on their desktops as well as the servers. As such, the choices of distribution tend to revolve around a number of things in no particular order:

  1. History – Obviously systems like RedHat and Debian have been around for a long time. As such, the adage “if it ain’t broke, don’t fix it” can be used for these. Upgrading becomes easier if the software is supported well on a distro.
  2. Familiarity – Similar to History, however we all have our favourites. I cut my teeth on Debian, and migrated to Ubuntu (a hard decision at the time because I tend to commit to a community). Conversely, it’s a pain to have to remember how to do things on a dozen different distros (not to mention the scratch-built ones).
  3. Support – I migrated to Ubuntu mainly because I appreciated what they were doing as far as offering paid support. That was a selling point if ever a client had a concern about running a system long-term. Similar to RedHat’s approach (but RPM hell was going on at the time). We have a number of RedHat servers for this reason also.
  4. Dependencies – Some softwares are easier to use on some distros simply because the dependent packages are more easily obtainable or buildable. As example of this would be oVirt on RedHat. There are no packages for some softwares on some distros. And you could compile it, but why would you if the package was right there on another distro?
  5. Granularity – Distros like Gentoo offer finer control over versioning and software-switch granularity. Other distros have “pinning” in various forms, but that’s still not as controllable or reliable.
  6. Binding – While it’s possible to compile from source on most distros, some distros are better at it than others. This can have an effect, say, if your project patches existing libraries for extended functionality.
  7. Prettiness – Some distros are just better-looking. Every geek knows it’s just fluff (and you could probably get away with doing it as a web app these days) but some clients are wowed by this stuff, and we all know it.
  8. Stability – Some distros stream “stable” versions of software as opposed to “testing”, “experimental”, etc. This can mean alot if you know that the version you’re building on will eventually reach a consensus on stability. You may develop on “experimental” knowing that by the time your project is finished it will have reached “stable” and be good to rely on.
  9. Package management – If you’re developing something on a daily basis, and it’s going to go out to 1000s of machines in one hit, then you probably want something that makes it easy to build, maintain, and track packages across those systems.
  10. Consistency – This is more an argument for the same distro. Less mistakes get made (and less errors in security) when people can focus on one distro as opposed to several.
  11. Predictable release schedule – If you want to be sure that your software stays supported, planned upgrades offer a certain type of stability.
  12. Security – Some distros have active security teams whose job it is to respond immediately to genuine security risks in any approved package.

Those are just a few things that come off the top of my head regarding reasons why each system was chosen. I don’t see any one guiding light or preference of one distro over another in this decision. Diversity and choice can be great and offer you some really good options to get a project started quickly, but it’s also the noose that can hang you. Make sure you think ahead of what you’re going to need. Plan what the system’s needs are as well as when the system is going to be upgraded or retired. Don’t assume you’ll always be the one maintaining it.

Leave a Comment