= Essay =

Many people have asked me why not use Gentoo instead of Source Mage?

Full-disclosure: I'm a Source Mage developer, but if I thought I could get work done with the larger party, I would have jumped ship a long time ago.  Here are some of the things I can't accept about Gentoo.

   * Gentoo's public freenode channels won't accept questions or suggestions about how things are done in Gentoo.  Compiling this list has been ever difficult becuase of their behavior, and that in itself is a major reason not to use a distro.  Granted, I'm straightforward, but that's no reason to ban somebody.

   * Gentoo's release engineering process isn't.  I have a few problems with it, notably that they publish from a live tree and have zero QA control over it.  A notable Gentoo developer was ejected from the team after bringing up a number of issues with their process that could be improved.  They only listened to some of his suggestions and ignored the most important ones.  When he continued to bring up issues, he wasn't treated well and returned the favor, giving them justification to ostracize him.  Some of the issues are:

      * Gentoo uses a "live tree".  Wow, nobody in their right mind would do this.  

      * Gentoo doesn't have a quality control system other than individual package masks.  This is a major problem because intra-version interactions can never be controlled and deployed until after the fact.  Testing is not an atomic process in Gentoo since they work from a live tree.  Either of this or the point above on their own wouldn't be so bad, but the combination is deadly.

      * Gentoo doesn't test packages in a formal way.  Developers are merely supposed to judge this for themselves.  This wouldn't be too bad, except for the fact that, yes, they use a live tree.

      * Gentoo has lots of packages, many of which are stale.  Their package versioning system leads to a larger tree with increased staleness and more testing requirements.  I suggest a way to indicate versions that aren't stale, or that are officially supported and/or tested with the latest bits on the live tree.

      * Gentoo has few policies to control quality on their ebuilds.  Rather than have process bugs lead to policy changes, developers are allowed to run amok on the source tree.  One platform is able to annihilate the quality of another platform (happened with the OS X porting team recently).  This kinda goes back to general release engineering policies, but it applies to other policies as well.

   * Gentoo doesn't rearchitect parts of their system that need rearchitecting for a few reasons: the initial developers are gone and changing their code is risky, especially since it's undocumented; while portage is written in Python, it was a learning project for drobbins, who essentially was clueless on how to leverage object-orientated design-techniques in his code writing; ebuild maintainers are famous quibblers, who hold back needed changes.

   * Gentoo developer relations team is composed of non-techies who take it upon themselves to interfere with technical discussions by eliminating developers who have the wherewithall to understand how to criticize a system.  Eliminating sources of critique leads to ignorant fanboyism -- the fanboyism that gentoo users are utterly famous for.  This was brought to my attention to Gentoo developers themselves, some of whom left the project, others still are there (one even is still in developer relations supporting the status quo as usual).

   * Gentoo doesn't really like to enable choices if that means a fundamental change is needed.  Take for example the constant question: when is the next kernel release going to hit the tree (live trees are great!)?  Gentoo portage tracks the size of each tarball as well as the hash so a developer can't write an ebuild to support arbitrary versions that authenticate source integrity with gnupg keys automatically.  I was banned from freenode's Gentoo channel for suggesting that this was a limitation that was unneeded.  The response was that it was faster -- while it isn't really.  I was banned before I had an opportunity to explain myself -- while an IO-bound operation is happening the overhead to compute a checksum is negligible, and the IO has already been cached in the VM-layer by downloading it, that the time wasted is so small compared to the flexibility, and remember that there's only time saved if there's an error.  Bailing out with an error sooner rather than later isn't much help if there's still a problem -- sooner as in a second or two on average.

That's just my issues with Gentoo behavior and release engineering.  There are other issues I have with the distro of a technical nature that I won't go into for now, since my expertise is really release engineering.  I'm sure others can pitch in where I left off (or check out http://www.sourcemage.org/Gentoo ).  Everything I mention here as being a problem is not a problem with Source Mage.  We chose to ignore what Gentoo was doing despite their popularity and simply ended up with a better system.

For example, when newbies claim that upgrading Gentoo broke their boxes, they are told to read the docs -- why do they need to read the docs for simple upgrades?  The system shouldn't let itself get HOSED by a simple update.  Sure, break a service or something and that's no big deal, but absolutely HOSE the system due to a g++ ABI change is a simple matter to fix -- well, it might not be so simple if you're using, say, Portage, written in Python that may be optionally linked to g++.  Source Mage lets the package maintainer have so much control that they can actually integrate in almost anything they'd need and override virtually every default action in sorcery to keep an update working while not requiring user intervention, even in the case of the most dangerous updates, like glibc, ncurses, bash, (and Python).

In theory, http://paludis.berlios.de/ might be able to replace many of the problems with Portage, but only if the Gentoo developers are willing to accept this drastic a change.  I haven't looked into it too deeply, but it looks as if it's better architected and immune from a number of the existing problems.  Let's hope it doesn't introduce many other problems already solved by Portage.