The GNU/Linux project has begot the most versatile operating system ever. It’s free, open source and designed to be modified and built upon by its users. The heart of the Linux philosophy is the concept of choice. Linux is about providing its users with the freedom to choose what they want to do and how they want to do it. Because both Linux and the software developed for it is so versatile, there exist hundreds of Linux distributions, each one being nothing more than a different collection of software and configurations running on top of the Linux kernel.

Because of the number of Linux distributions and the degree to which their styles/configurations can vary, a given user usually has the ability to choose a distribution closely suited to their specific needs. To aid the ever-prevalent distro-seeker, many Linux users have sought to provide written reviews of various Linux distros. Unfortunately, many reviews fall short. With the increasing population of Linux users, and the increasing number of Linux distributions, there has been a notable increase in unhelpful reviews.

Which leads to the point of this article, namely, how to review a Linux distro. The idea of reviewing a Linux distro is to inform the reader as to how the specific Linux distro in question is different from the other Linux distros. To do this, a reviewer must provide an analysis of the software and configurations that set the disto in question apart from other distros, putting solid emphasis on the big differences, less emphasis on the minor differences, and no attention to the things that are inherent in all Linux distributions. (If you are writing to inform the writer about Linux, you should do that instead, rather than pretend you are reviewing any specific distro.) This basic principle holds for almost any review of any product. For example, movie reviews tell you why one movie, a four-star action flick, is different than another movie, a two-star romantic comedy. The movie reviewer doesn’t spend time explaining the concepts of cut-scenes and character development, it merely explains the aspects of a movie that make it unique.

This article is aimed at the potential Linux distro review writer. It is split into two main sections: things one should review, and things one should not review. Most of the points have sample topics for that point, some of the points and sample topics are more advanced/technical, some are less so. No good review must cover every point and sample topic in this article, this is just a broad list of good ideas. Suit your information for the knowledge level of your target audience.

Here’s a list of things that make for a good review. This is not an exhaustive list, but it covers a lot of ground.

• Philosophy
  Every Linux distro has a philosophy, namely, a statement of purpose and a set of guidelines for development that support that purpose. “Linux for human beings,” “KISS,” “Free, robust, stable,” “Design for control,” are some philosophies that describe various distros. Anyone using a distro with one of those philosophies would instantly recognize it.
  
  This topic is not optional, you must state the distro’s philosophy and exemplify it throughout your review. Consequentially, it is probably the best place to start your distro review, as what you write thereafter should exemplify the philosophy. Remember, your goal is to show how the distro is unique, and it is the philosophy that dictates why the distro unique. All criticisms or negative points against the distro should be held in light of the distro’s philosophy. Is the distro complicated? That might be worth mentioning, but if the distro strives to put user control first and simplicity is of no concern then complexity is not a short-coming of the distro but rather a side-effect of its philosophy. Rather than criticizing a distro for being too complex, instead note that it is designed for experts. Many reviews fail to evaluate a distro for what it is and criticize a distro for lacking things it does not strive to have.
  
  As boring as it may seem, a quick history of the foundations of the distro might prove very informative. Understanding why a distro was created in the first place can say a lot about what its like today and where it might be tomorrow.
  
  Sample topics:
  • Who is the distro’s intended audience? The newbie, the guru, the average home user, the developer, the server administrator?
  • Does the distro tend to value stability or bleeding edge software? (See later points.)
  • Is the distro designed for users who like to control everything?
  • What is the history of the development of the distro? Why was it created?
  • How robust is a base from-disk install of the distro? (See later points.)
• The parent distro
  If the distro in question is itself based on another distro (many are) you should mention the parent distro and how this spin-off/child distro differs from its parent. Some parent-child relationships are distant, some are close. Some spin-off distros maintain their own package repositories and make their own configuration decisions, some are nothing more than the parent distro with a different default window manager and a few extra pre-installed packages. Telling the reader what the parent distro is and how closely the child is related to it is extremely informative for those either familiar with the parent or who will seek to become familiar with the parent.
• The package manager
  The package manager is the heart of a Linux distro. It is how the user most intimately adds to and subtracts from his system. The package manager is arguably the most important and unique component of a distro. Even though most package managers offer the same rudimentary functions, you should review the package manager. And the word “review” does not imply that you should confirm that there are indeed commands for installing and removing packages. You need to provide enough information that it’s clear how the package manager feels to the user. Explain what sets the package manager apart from other package managers. Different distributions make it easier/harder to eliminate orphaned packages or check dependency information, and many have different ideas of what security precautions to take.
  
  Sample topics:
  • Does the package manager have a GUI?
  • How easy is it to upgrade all the packages in the system?
  • Does it provide clear output informing the user what its doing?
  • What level of security is offered? Package authenticity verification? SSL downloads?
  • Does it ever require that the user perform manual tasks to complete a package installation/integration into the system? (Ie, removing certain configuration files or backups.)
  • How is the package database stored? How easily human-readable is it? How easily backup-able is it?
  • How many tools are a part of the package manager? How many are necessary for day-to-day use?
  • How easy is it to perform a system upgrade?
• Support/Documentation
  The level of support and/or documentation available for a distro will likely be one of the most significant influences in a user’s experience with a distro.
  
  The interactive support offered by a forum (and the archived support offered by its search function) can be priceless as a user gets started with a distro and has questions as they encounter Linux phenomena they are not familiar with. A wiki can help the user through the install and/or basic system setup, setup common software, configure it the way they want, and fix common bugs. The absence of a wiki can mean many hours of Googling for decentralized information and exasperation, leading to unfixed problems and a poorer user experience. A documentation tree (somewhat rare outside of behemoth distros) can help a user dig deeply into the distro and modify/fix it if they are so inclined.
  
  Sample topics:
  • Does the distro have an official forum? How large is it?
  • Does the distro have a wiki? How expansive is it? Does it cover the configuration of sudo? What are some of the more obscure articles it has?
  • Does the distro have developer-written/contributed documentation?
• The Packages
  While the package manager controls the addition/removal of packages to/from the system, it would be foolish to overlook reviewing the packages themselves. The packages will be composed of compressed archives, arraigned with file hierarchy and package metadata that handles dependency checking, integrity verification, and the like.
  
  It is arguable that the layout of the filesystem be included in this topic. Many distros have their own ideas about how the filesystem should be laid out. If the distro has any peculiarities or quirks to how it uses the filesystem tree, its usually related to the compilation destination of packages.
  
  Sample topics:
  • What type of packaging standard does the system use? How easy is it for a user to create their own packages? (Some users like to assemble their own software and use the package manager to mange their installation. See point on compiling from source below.)
  • Is package downgrading supported?
  • How quickly are packages updated when their official upstream versions are updated? (Don’t be to picky here: Are we talking about weeks or months?)
  • Continuing from the Philosophy point and the above sample topic, does the distro lean towards being bleeding edge or being stable? (This has been mentioned twice. Hint.)
  • Do the developers do extensive modification of the original packages (security patches, extra functionality), or are they provided vanilla as-is? (For example, Debian developers tend to modify packages as they see fit, Arch Linux developers only apply very common patches occasionally.)
  • How are the packages compiled by default? (For example, with or without debug information?)
  • How is Gnome/KDE split up? How many packages compose a full Gnome/KDE suit? (For example: Is Kolour Paint an individual package, or only available as part of the larger KDE Graphics package?)
  • Are there any filesystem layout quirks, additions, or reservations? (For example, is /usr/local ever used by packages or is it reserved for the user? Is Firefox installed into /var?)
• Support for compiling from source
  The package manager’s job is (usually) only to manage pre-compiled packages. But some users like to manually compile some packages from source, such as to apply custom patches to a program or to get speed by optimizing the program for their specific machine. Many users don’t compile much (if any) from source, but the Linux philosophy is deeply rooted in the distribution and manual compilation of source code, and there are many who like/need to do so. How an operating system lets the user compile/managed compiled programs is important to how the operating system works. Those who rely on it will find their experience very dependent on how manual compilation is handled.
  
  If there exist any distro-specific methods for handling the compilation of both supported (packages in the repositories) and/or un-supported (packages not in the repositories) software, it should definitely be included in a review. If the distro has any form of a ports-like system, a review without mention of it is by default incomplete.
  
  And do not ever, ever waste space explaining that you can do “./configure && make && make install”, that you can use “checkinstall”, or that you can use the “install” program itself — every distro has those, they aren’t worth mentioning in the slightest.
  
  Sample topics:
  • Do there exist any specific tools for the system that aid the user in compiling programs from source?
  • How are users supposed to recompile the kernel? Is initramfs or initrd used?
  • If a user does manually compile a program/package, how easily can it be managed by the package manager? (This has been mentioned twice. Hint.)
  • How is the presence of different kernel versions handled?
  • Is there risk of having the manually-compiled program conflict with the packages managed by the package manager, or is there a way to keep manually installed non-package programs separate?
• Release system
  Distros have different styles of updating the end-users installed distro to be the most current version. Some distros have a new, fully-updated version released every 6 months. Some just release all package upgrades on-the-fly and have no concept of different versions. The way the distro handles version releases is significant to the end-user, as usually full version upgrades mean that the developers reserve the right to move stuff around and/or reconfigure things in a noticeable way if they want to, and push those changes through in the next major release. It also means that developers reserve the right to stop providing package upgrades for a given version, resulting in obligatory periodic upgrades.
  
  Sample topics:
  • What factors decide the version releases (if there are any)?
  • How big are the changes between releases?
  • How often are the releases?
  • How long is there support for old releases?
  • Does evidence seem to suggest that performing a version upgrade is smooth, or is the user better off performing a clean install of the new version?
• Startup style
  Summarizing how a distro manages startup scripts/daemons is easy: All you have to do is say whether the distro uses System V or BSD-style init scripts. Users unfamiliar with these concepts can look them up.
  
  How the operating system uses run-levels is a more complex subject, yet a more interesting on. Fewer users will care about this level of detail but more advanced users might be able to intuit more about the nature of a distro from it.
• Robustness of a default install
  Distros vary in what software they provide for a from-disk installation. Some have more, some have less. Some have roughly equal quantities but the theme of the offered software is completely different.
  
  After you install the distro, how much work must be done to get the system up and running with a graphical desktop and a decent collection of tools? What kind of packages are installed, and what aren’t?
  
  Sample topics:
  • Is a default display manager installed or offered? (Which one?)
  • Does the distro rely heavily on sources from the servers, or can you obtain multiple CD/DVDs for a more robust from-disk install?
  • Does the default install include tools for compiling? (GCC, make, etc.)
  • Does the default install offer Apache for install?
  • What are some of the most specific/obscure programs install/offered by the installer? (For example, if a distro provides Compiz and OpenOffice.org straight from disk, that implies the sort of other packages that are installed.)

The above topics cover a lot of ground. Obviously not every detail need be included in a good review, but many of these points are very critical to how the distro works and failure to address a significant number of them will result in an incomplete review of the distro. If there seem to be too many points to address, remember that you’re writing a technical review, not a grand work of fiction. Wordiness can usually be eliminated. If you know what you’re talking about and put some thought into what you write, you can cram a lot of information into three sentences.

One key to remember is that that not all of the information may seem important to you, the author of the review, but it is what separates one distribution from another. Obviously the information has to be appropriate for the audience you are writing for; that is a decision faced by every technical writer.

If you feel unable to address many of these topics in your review then you probably have no business reviewing the distro and are not as familiar with it as you should be. Many people want to pop in a CD, install the distro, play with it for 40 minutes, and then write a review about it. Unless you did your research beforehand and you made very good use of those 40 minutes, you’re not qualified to offer a review. Spend your time learning more about the distro rather than writing about what you do know.

Now a list of things you should not review.

• Plug-n-play drivers
  Do not ever review a distro by saying “I plugged my external wireless card X and it did(n’t) work”. This is the lamest review you can provide, and is my pet peeve to boot. First of all, and apparently this will come as a shock to some, almost all distros use the same drivers. Support for hardware is pretty much universal, the same drivers that manage your hardware in one distro probably manage it in most other distros, and this only becomes more true over time. Comparing hardware support between distros is basically pointless. It’s even more pointless when your analysis consists of just one generic external wireless card. If it didn’t work, odds are you didn’t set something up correctly.
  
  Second, the comparison you can make between distros is in how they manage drivers. Some distros have special programs to help the user manage and install drivers. Some distros have lots of automatic scripts set up to help ensure the user never has to manually touch their xorg.conf file, some distros demand the user get involved with the xorg.conf file.
  
  Driver management is a valid comparison point, but generic “I tried wireless device X and PCI device Y” tests are basically worthless. “Here’s how easy/hard it is to install Nvidia’s video driver (module version or userland version, take your pick), here’s a short summary of what is expected of you to do so, and here’s what was done automatically by tools”, by contrast, is very informative information.
  
  Note that it is obviously acceptable to review the quantity of drivers provided by a distro if they seem to have a noticeable shortage/abundance of them, but most distros will have about the same drivers. Don’t mention driver quantity unless its very noticeable.
• Five minute quirks
  At various times, some distros have what you might call “five minute quirks”, namely, one or two little problems that often need to be ironed out of a fresh install of the system and are easily solvable by a user with Linux skills that the distro is oriented towards. Sometimes an environment variable needs to be set, sometimes a file needs to be configured, etc. These are bugs not unique to anyone’s specific install of the distro, but rather a very large (if not the entire) user base. One of the developers mis-configured something before release, or some default setting doesn’t work with the majority of hardware, or something like that.
  
  Do not write about these little five minute hiccups in your review. They do not count, they only last five minutes and will likely be fixed in one of the upcoming releases anyway. (See the next point.) Usually the distro’s forum and/or wiki has an easily accessible guide to tell you how to fix the quirks and after a day of usage, the user will not remember it. At absolute most you should say that “minor quirks exist” and say where/how the site addresses these issues. This could be part of your review of the distro’s documentation. Any quirks you fix within five minutes of attempting to do so should not be mentioned. Their fix in the next release will out-date your review.
  
  What’s more, do not write about the stability of a distro based on its five-minute hiccups. Nothing says “I didn’t do any actual research about this distro” like a stability evaluation based on the initial five-minute quirks the distro had as of some arbitrary date.
• Unrelated/temporary bugs
  Do not write about temporary bugs. If the bug is the type that will be fixed within four months, don’t use it as basis for your evaluation of the distro’s stability. This point bears repeating: Whatever you do, do not base your assessment of a distro’s stability on little quirks that will be gone in a couple months. If your readers wanted to read an inane bug listing, they’d browse bugzilla.org.
  
  On that note, do not assess the distro, in any way, based on bugs that are not specific to the distro itself. If the developers of a software package X make a mistake, don’t blame the developers of the Linux distro in question, it’s outside of their control, not their fault, and not their responsibility. It’s irrelevant to your review, so ignore it. If distro X has a bug but distro Y does not, it is possibly that distro Y did not push the new version of the software and thus does not have the buggy version — you can use this to exemplify how “bleeding edge” the distro is. Or its possible that distro Y manually patched the software — you can use this to exemplify how the developers do(n’t) manually patch packages.
  
  You can obviously cite the presence of bugs in your analysis of the stability operating system, but don’t focus on petty bugs. Instead, focus on the release/testing cycle of packages, the speed of security fixes, and frequency of distro-specific bugs. If this means that you actually have to spend some time using a distro and learning about it before you evaluate its stability, cry me a river. If you aren’t willing to do that, don’t comment on it’s stability because you don’t know anything useful about it.
• Artwork
  No one cares what the default desktop color theme of the distro is. Or the default desktop wallpaper. Or whatever. This is my other distro-review pet peeve. As shocking as this may sound, every desktop environment and window manager in the entire universe, throughout every civilization, all of time, and every dimension, can have its color theme changed. If a user doesn’t like the default wallpaper, they will change it. If they don’t like the default Gnome color theme, they will change it. Defaults are irrelevant.
  
  Don’t mention the quantity of community artwork, in the sense of backgrounds and color themes. This is directly proportional to the number of users the distro has and is thus redundant information. And, realistically, nobody cares about it, because most of them will choose whatever distro-neutral artwork they prefer anyway. Users routinely become attached to a certain color theme and will take it with them from distro to distro.
• Installation Process
  This is not a terribly important point, but I’m not a fan of reviewing the installation process of a distro. Most installers, even text-based ones, guide the user through the installation very clearly. Sure a text interface may look a bit daunting to some, but if one just reads the instructions, one can usually just click-through (or, tab-enter-through) the installation with relative ease.
  
  This item might warrant a quick mention, perhaps tying into the distro’s philosophy (ie, in analyzing whether the distro is oriented towards casual or power users), but unless the installation process is exceptionally complicated or buggy don’t devote much space to it. It’s a one-time experience by the user, and a determined user won’t change their opinion on whether to install it based on the installation graphics.

Remember, your goal, as a reviewer, is simple: Review things from the perspective of the average user you are writing for. Don’t go into pain-staking detail unless you’re aiming to provide an in-depth guide, minor details/quirks are often best left for their own special article and are of interest to few readers. Don’t waste time on things that were (likely) very unique to your experience, because almost no one else cares.

Even though this article was somewhat long, your distro review doesn’t have to be. (If it is very long, it’s probably more of a guide than a review. Keep manuals as manuals, and reviews as reviews.) If you have an actual depth of information to convey, you can say a lot by using well-crafted sentences.