Why I don’t recommend Automatix (not what you may think)…

There’s a four-syllable word that stirs up emotions in Ubuntu users like no other word: Automatix

The fans of Automatix swear by it. The opponents of Automatix can go off in a rage at the mere mention of it.

I’m a little bit in between.

The relative non-issue of breakage
I’ve heard it often said that Automatix will break your Ubuntu system. I’ve also heard the Automatix apologists say that it’s not Automatix itself that breaks your system but the extra software Automatix installs… or Ubuntu breaking itself with its own updates. It’s also possible that Automatix may have broken Ubuntu in the past during upgrades but no longer. Who knows for sure? I’ve searched all over the web, and I haven’t seen any technical explanation of either how Automatix breaks your system (detailing which part of Automatix disrupts the normal functioning of Ubuntu) or doesn’t (detailing Automatix’s non-intrusive nature).

Breakage doesn’t concern me that much. I know that’s a strange thing to say, but it really doesn’t. The Automatix proponents have a point—Ubuntu could break by itself. That doesn’t exclude Automatix from breaking Ubuntu, but it also means you can’t falsely reassure people that by refraining from installing Automatix that their Ubuntu installations will remain intact. I had a HAL update (granted, it was a proposed update) break my resume-from-suspend. Breakage happens. Automatix may be responsible for some of it, but it isn’t happening in such great numbers as to cause Automatix fans to stop using Automatix.

The red herring of the command-line
Neither side of the Automatix debate is solely to blame for this, but in debates about Automatix, inevitably the question of the command-line (or terminal) comes up—with the Automatix fans saying that not everyone wants to learn the command-line and the Automatix anti-fans saying that learning the command-line is a good thing or that the command-line is faster to use than Automatix.

That argument may be interesting on one level, but those are not the only two options (Automatix or terminal). A lot of what Automatix does and, more disturbingly, most of what people recommend Automatix for, can be achieved easily through the already existing GUI (graphical user interface)—either through Add/Remove or Synaptic Package Manager. While this isn’t true of all the software or tweaks Automatix handles, it is true of many of the packages people recommend Automatix for.

The root of the problem part one: panacea
My main objection to people recommending Automatix isn’t anything I have against Automatix itself so much as the way people recommend Automatix. Automatix is not a panacea. And it is not always the best solution. But many times on the Ubuntu Forums, an Automatix fan will jump in and suggest Automatix for just about anything: How do I install Flash for Firefox? Just use Automatix. How do I install Wine? Just use Automatix. No, people. No. Automatix is not the solution for everything. Automatix is a piece of software that has appropriate uses and less-than-ideal uses. It is far easier to install Flash than it is to install a helper program that will install Flash. By the same token, it is far easier to install Wine than it is to install a helper program that will install Wine. Consider this comparison:

Install Wine with Automatix

  1. Go to the Automatix website
  2. Find the Automatix .deb to download
  3. Wait for Automatix to download
  4. Double-click the .deb to install Automatix
  5. Wait for Automatix to install
  6. Launch Automatix from the menu
  7. Check off Wine to install it
  8. Wait for Wine to install

Install Wine with Synaptic Package Manager

  1. Launch Synaptic from the menu
  2. Search for Wine
  3. Click to install Wine
  4. Wait for Wine to install

See the difference? There are some cases where Automatix may be a good solution, but most times I see it recommended, the person needing help would be better off just using traditional (and, yes, point-and-click) methods of installing software. I might recommend Automatix if someone wanted every single popular non-free codec and software package. That might be a good situation for it. But for one or two programs, no.

The root of the problem part two: inertia
Ubuntu’s codec and general software installation has improved a lot with recent releases, especially Ubuntu 7.04 (nicknamed Feisty Fawn). I don’t know how many Automatix users are aware of how easy it is to install codecs (easy codec installation and Ubuntu restricted extras) or other software (some extra repositories enabled by default) now. Once you get used to depending on a piece of helper software, you may not realize eventually that you don’t need it any more. Some people may need it, but if you refuse to take a bandage off, how will you know when your wound has healed?

Final thoughts
On a related note, I’ve heard that the Automatix developers have been talking with the Ubuntu developers, but I don’t know if they’re working together. If they are, great. If they’re not… well, they should be. Part of the beauty of open source it the ability to contribute back patches and improvements to a project. If the Automatix developers note deficiencies in the way Ubuntu handles packages, maybe they could help develop a better Ubuntu instead of a workaround? As I said before, they may be doing this already. I don’t know.

I’m grateful that the Automatix developers created Automatix. It filled a real need when it first arrived, and many users have grown to appreciate it. Still, the insanity (both the anti-Automatix and pro-Automatix) must stop. It’s a piece of software. It won’t solve or create the world’s problems.


  1. Been a while since I used Automatix, Aysiu, but is there anywhere on their site, or the forums that details the steps required to install any one item that Automatix does for you?

    That would (possibly) keep both camps happy – show them what Automatix can install, but link each item to how you would do it WITHOUT Automatix.

    Just an idea.

  2. I’ve never seen such a guide, but I don’t know if it’d keep both camps happy. Such a step-by-step guide would probably show, in most cases, that Automatix doesn’t really do much special for single items. The benefit of Automatix is the bulk installation of a lot of things (especially packages or tweaks not in the repositories), not one or two individual software packages.

  3. I’d really be interested to know HOW Automatix can break a system. What would the difference be if a shell script modfied sources.list and then installed stuff from custom repos? That shouldn’t break anything, AFAIK

  4. Well, I guess the alleged breakage would come from more than just modifying the sources.list. As I said before, I haven’t seen any technically detailed explanations of how breakage would occur in recent versions of Automatix (older versions used a –force-yes flag for apt-get installations).

    My main objection to Automatix recommendations isn’t breakage, though.

  5. One of the sillier things that it does is in distro_helpers.py – in checkConflicts() it runs “killall -9 dpkg”.

    This is obviously to allow AX to use apt/dpkg, which requires a lock. However, sending SIGKILL to dpkg is a really bad idea – it could corrupt your dpkg database, which could then prevent you from using apt at all.

  6. In Re. to RAOF, if dpkg isn’t configured to catch the signal, it doesn’t matter whether it’s SIGKILL or SIGINT does it? I don’t see where kill is really any worse than sending it any other signal is all I’m saying.

  7. In general, interrupting dpkg with anything that is not a SIGINT is a bad idea, including `kill` (15) and `kill -9`.

    Automatix has only a few uses, but I do have to admit that it greatly simplifies adding binary codecs for DVD, WiMP9, Real, QT, and MP3 to desktop systems.

Leave a comment

Your email address will not be published. Required fields are marked *