The Return of Gentoo

About nine months ago I wrote a post title The End of Gentoo. At the time, the article mostly echoed my growing frustrations with the lack of maintainer support for the vast collection of software in Portage, Gentoo’s repository and package management subsystem. Although the gentoo-server mailing list has all but dried up, gentoo-user has seen a marked increase in activity. Whether seasonal or otherwise, I think it’s a positive sign.

Another positive sign that comes to mind is the increased frequency and speed with which package maintainers have been pushing stable (and sometimes unstable) package versions out the door. For example, I was surprised to discover that MongoDB exists in Gentoo at version 1.8.2 as of this writing, which is conveniently the same version in FreeBSD’s ports collection. Ubuntu is decidedly behind the curve, holding in at around version 1.4.x. Of course, with sufficient digging, you can find prebuilt .debs of 1.8.3, or you can always fall back on building from source. Then again, I’m somewhat torn with regards to this: Sure, it brings back memories of earlier days when I often had to build packages by hand just to apply security fixes or obtain new versions, but I also wonder what the value is to it. After all, if I abandoned Gentoo to avoid the nightmare of compile-wait-restart, what’s the point if I leap over to another distribution that is forcing me to do exactly the same thing (except with less automation)?

Given the nature of work and my current projects, I’ve discovered that Gentoo suits my needs best. I can obtain fairly new versions of packages with some degree of customization without the need to manually run the ./configure && make && make install cycle by hand. Downgrading is also fairly easy, provided it doesn’t affect too many packages. However, I’ve found that eselect for those packages it supports can be an exceedingly welcome tool in the developer’s arsenal. I may not use it with any degree of regularity, but the option of setting the system default of a specific package to one version or another is appealing. I suspect this will be mostly useful for any Python-based tools I write in the near future, particularly given the split that is currently underway between 2.x and 3.x, but eselect also works with a handful of other systems that exhibit some degree of change between versions, including PostgreSQL and Boost.

But, I confess that none of this really influences my motivation for writing this post. Well, with the exception of V8 and MongoDB.

I think that much of my decision revolves around familiarity and maybe, if I were to make something of a stretch, annoyance. Ubuntu on the desktop looks absolutely beautiful. I love it. I really do. But the moment you dare to venture beyond the official packages it shipped with (think instant messengers), you begin to encounter various bits of weirdness that fester into a sore. Ubuntu has a great community of developers and supporters, but sometimes more peculiar problems are harder to find via search simply because of the noise level generated by its popularity. There’s nothing wrong with that–in fact, that’s an excellent problem for a distribution to have–but for unusual issues, it often makes finding the answer an uphill battle that is difficult to win without some patience. Add this to the abomination that is NetworkManager (installed and enabled by default), the excessively annoying network configuration borrowed from Debian, and whatever blasphemous modifications have been made to sysvinit, and one starts to see a pattern that makes this distribution more than a little tiring to those who simply wanted something that Just Worked.

It’s ironic in a way. I read an article a couple of weeks ago praising Linux Mint for many of these same reasons that Ubuntu seems deficient. Perhaps I should give it a try…

Yet time and again, I find myself drawn to Gentoo. It’s a rough distribution to maintain. It has many sharp edges. It’s not exceptionally good for use on a server where security updates may need to be applied from upstream regularly. It’s not even really that great for low powered desktops (try compiling Xorg and the desktop manager of your choice on a Netbook without distcc or cross-compilation on another system and then get back with me). Time and again, Gentoo lures me in. Why? Well, I’m starting to think that the answer is more complicated than simply “familiarity.” Perhaps I should take back what I said earlier.

About 8 or 9 years ago, I started toying around with a handful of Linux distributions. The only *nix-based systems I knew at the time were FreeBSD and OpenBSD; I had no idea what Linux really was, why there was such a significant chasm between the userland and kernel, or even really what the differences were between distributions. Superficially, I just assumed that the init systems were largely identical, and individual distributions simply customized various subsystems here and there. I had no idea that the world of Linux was vastly different from that of FreeBSD. In the latter, kernel and userland development is largely one and the same. FreeBSD is the kernel. It’s also the world. From init to various userland tools (yes, even ls) to device drivers (oh fxp0, how I miss you), development continued as a part of a single cohesive continuum. Little did I know, the Linux world is almost the polar opposite of that.

I was introduced to Gentoo by my friend John G. who suggested it as a more “BSD-like” distribution of Linux. He was right–everything about Gentoo seemed to be a GNU-derived analog of the BSD world with the one exception that it was decidedly Linux-flavored. But the most important lesson I took from Gentoo was that of how an operating system is put together–from scratch, but with training wheels. Sure, I knew all of the basic steps: There’s the file system, the kernel, the userland tools, and then there’s various odds and ends here and there that are glued in place to make life easier (or more miserable). In some ways, it’s almost a surprise any of this actually works as well as it does.

Yet I think it was that experience with Gentoo that won my heart. Not only do you have to partition the file systems yourself, but you have to effectively bootstrap the entire system from a live CD (or other Linux distribution), prepare it, and configure it, but you also have to build the kernel and all of the utilities yourself. To this end, I think Gentoo should be a required topic in any operating system course in every CS program at all universities. It’s like Linux From Scratch set to super-easy-mode. It’s no surprise then that any time I want to learn anything new, the best way for me is to pick it up under Gentoo and play with it.

And let’s be honest, Gentoo probably has one of the very best network configuration systems in the Linux world. It better–because it’s the kindred spirit of FreeBSD’s network configuration via rc.conf, except that it’s not. Well, not completely.

This isn’t to say that Gentoo is all sunshine and roses. It certainly does have more than its fair share of sharp edges. I recently reinstalled it on my desktop (no, I still have my Ubuntu install) only to discover that it still takes the better part of a weekend (and then some) to configure, build, and find everything you want, get things situated exactly right, and then discover that there’s one or two minor annoyances still eating away at you. For me, those annoyances are font-related, but I suppose nothing’s perfect. Ubuntu’s fonts are about as close to perfection as possible in the Linux world. Although, I admit that sound and sound support sucks badly in both. Oh, and don’t get me started on media players. I spent most of my free time this week messing around with the damned things only to discover that nearly every single one available is absolutely terrible. I miss Amarock 1.4. They had a good thing going…

The most important lesson I’ve taken from the time period between now and the time I wrote that fairly anti-Gentoo rant is something worth repeating: Nothing perfect. No distribution is perfect, no one distribution will do everything you want, and compromise is always a necessity. I still like Ubuntu for its aesthetics, but Gentoo is still the most appropriate solution for a general purpose workstation. I guess some things never really do change.

So, lesson learned: Rants are stupid. The future you is always the wisest. Sometimes you look back on what you wrote and wonder what the hell you were thinking. Long live Gentoo!

No comments.

Atom-based Media Center: Part 1

I elected to give myself a little project this weekend and it started with this small mountain of boxes:

Boxes, boxes, boxes.

Don’t worry, there’s a method to my madness. It isn’t often my crazy ideas have a purpose, so this time I’m making an exception. I also promised to share some of my experiences with a friend of mine who was interested in the project so he could freeload some information share in the learning experience.

The idea started about two weeks ago when I was mulling over some way of providing my mother with an entertainment system that could replace a few aging devices. Since she’ll be having back surgery next week, I figured it would be much easier for her to contend with a single device than to muck about with several. Plus, she has an old video cassette recorder that is on the verge of going wherever it is electronics go when they pass on into the afterlife, and it occurred to me that bringing her kicking and screaming into the digital age might not be such a bad idea. She’s in desperate need for a video recorder of sorts and being as I inherited her frugal nature, I wasn’t about to purchase a TiVo unit for her. TiVos are too limited anyway. She needs a relatively decent computer to sub-in for the period of time she won’t be able to sit at an actual desk. Plus, with her “real” computer being in an upstairs room and her refusal to let us bring it downstairs, I started mulling over a solution.

So far, I’m fairly impressed. There have been some teething problems–the project is still a work-in-progress–hence I’ll be posting this DIY walk-through in multiple parts.

Read more…


Build Pidgin (or Carrier) in Ubuntu

I had a request from Will to give a run down on how to build Pidgin (Carrier, rather) from scratch in Ubuntu. It’s not too difficult, but Ubuntu doesn’t ship with many of the development headers and libraries required to build either of these two applications. Worse, Carrier doesn’t ship with a working configure script, so you need the auto* tools to build that first.

Now, I’m sure someone will probably say “But you can just download the .deb and install it from there, it’s easy!”

Yeah, you can. This post isn’t about easy: It’s about giving the user a choice. After all, that’s what open source is about, right? :) So, for the sake of argument, let’s assume that the individual reading this post has absolutely no other choice but to build Pidgin/Carrier from scratch.

Easy enough?

I’ve listed the packages that are required to have a fully functioning IM client. I also have “barely optional” and “optional” packages listed as well. Barely optional are packages which you don’t need to install, but if you don’t, certain things probably won’t work and your IM client might not play very nicely with other applications like the desktop environment. Optional packages are those which you really don’t need, but if you have a really morbid fascination for installing everything, you can choose to grab them all.

If you’re installing from Synaptic, here’s the list of packages you’ll need:

  • Required Packages
    • automake
    • libtool
    • gettext
    • libglib2.0-dev
    • libgtk2.0-dev
    • libxss-dev
    • libstartup-notification0-dev
    • libgtkspell-dev
    • libxml2-dev
    • libgstreamer0.10-dev
    • libnss3-dev
    • libgnutls-dev
  • Barely Optional Packages
    • libdbus-glib-1-dev
    • libnm-glib-dev
  • Optional Packages
    • libmeanwhile-dev
    • libavahi-client-dev
    • libperl-dev
    • tcl8.5-dev

I’ll explain more about each of the optional categories in a moment. First, let’s map out the commands you’ll need to run to get this started:

Install the Packages

You will probably need to update Ubuntu first. If you don’t, you’ll have to reinstall a bunch of packages down the road. Though, I suspect that if you’re going this far, you’re already expecting to install a lot of things. In that case…

Here’s the command line you’ll need to get started:

apt-get install automake libtool gettext libglib2.0-dev libgtk2.0-dev libxss-dev libstartup-notification0-dev libgtkspell-dev libxml2-dev libgstreamer0.10-dev libnss3-dev libgnutls-dev libdbus-glib-1-dev libnm-glib-dev

Then, unpack the Pidgin or Carrier sources:

tar jxvf pidgin*.tar.bz2 (Use zxvf if you have a gzip instead)

tar jxvf carrier*.tar.bz2 (Use zxvf if you have a gzip instead)

Carrier only
Create the configure script for the next step:

Carrier and Pidgin Both
./configure --disable-meanwhile --disable-avahi --disable-perl --disable-tcl

And that’s it. Before I close this post, though…

What are all these darned packages anyway?

I’m glad you asked. It’s a mess, I’ll give you a short drill-down:

Barely Optional Packages:

  • libdbus-glib-1-dev: D-Bus support. This handles communication between user applications, the system–heck–even the kernel. You can read more about D-Bus. To disable D-Bus support use: --disable-dbus. Be careful, though. Disabling this might cause minor problems with Pidgin’s ability to interface with your desktop environment. Then again, maybe you want this…
  • libnm-glib-dev: NetworkManager. This handles network connectivity from the desktop environment. I’m not sure why libpurple or Pidgin would need this, but I imagine it has something to do with Pidgin’s ability to start when the desktop environment starts. To disable NetworkManager support use: --disable-nm. Note that you might not want to do this.

Optional Packages:

  • libmeanwhile-dev: Meanwhile/Sametime IM support. Use --disable-meanwhile to disable this.
  • libavahi-client-dev libavahi-glib-dev: Avahi/Bonjour autodiscovery support. This isn’t really necessary. If you plan on enabling it, you do need both libraries installed. Use --disable-avahi to disable this.
  • libperl-dev: Perl scripting support. Yep, some people use this. Use --disable-perl to disable this.
  • tcl8.5-dev: Tcl scripting support. Use --disable-tcl to disable this.

Other noteworthy things…

  • Installing libgtk-dev pulls in a lot of packages. In fact, it pulls in about 53 dependencies.
  • libxss-dev is required for Pidgin to track mouse/keyboard activity.
  • libxml2-dev is needed for–you guessed it–XML-related stuff. Incidentally, if you’re building PHP from scratch, you’ll need this.
  • It isn’t recommended to disable NSS and GnuTLS support with --disable-nss and --disable-gnutls; if you do, MSN, Novell Groupwise, and Google Talk support won’t be built.

So there you have it: Building Pidgin or Carrier yourself should be (reasonably) easy!