Date with the Gentoo Oxen – Part Deux

larry-the-cow-full-udder.jpg

As part of my journey to the sane and minimal of GNU/Linux, I decided to revisit Larry’s neighborhood of Gentoo Linux. I tried it for some days in the past, though without much success. Perhaps I was merely not ready for a certain level of complexity. After having spent many more hours recently, I sadly reached a similar conclusion. To avoid a full-scale rant, I decided to put down the strong and weak points of Gentoo Linux as I see them in my tired, watery eyes.

Why Yes:

  • Almost perfect control of what will end up in the kernel and installed software. Especially useful when we want to avoid certain unwanted, but persistent components like dbus, systemd, pulseaudio, etc.
  • Minimal, tailored setups (see above), essential for embedded or low-powered systems.
  • Broadening our understanding of GNU/Linux in general.
  • Testing various compilation parameters as part of day-to-day developers’ work.
  • L33t feel of being able to tackle the most vicious maintenance issues (relevant at least to me!).

 

Why the hell No:

  • Building packages from source code is time-consuming and should be done by build-farms, rather than personal computers.
  • Compiling badly written code produces binaries compiled from badly written code. Unless core issues are addressed, compiling alone doesn’t help much.
  • With currently accessible hardware, the overall performance gain is minimal. We’re talking <5% net gain on average.
  • Number of Gentoo installations = number of Gentoo users. Reproducibility is highly relevant to bug-tracking and in Gentoo Linux it’s immensely difficult to achieve.
  • Kernel trimming is a two-sided sword – often 3rd party devices/drivers may fail to work, because we forgot to add just this one module/feature. This applies to the whole of GNU/Linux, though.
  • Non-standard software behavior and often permission problems. For instance, why does the ‘lspci’ command require superuser elevation? Why does my X session fail to start with timeouts on xauth and the .Xauthority file lock-up?
  • Scattered configurations – ALSA can be configured through at least 2-3 files system-wide. This, however is more of a GNU/Linux issue than anything else.
  • Features unintentionally left out might be useful in the future. This involves more compilation rounds if they are.
  • Some features cannot be avoided due to package design. For instance, KDE wallpapers needing almost the full KDE desktop due to some minor requirement for animations.

The unfortunate take-home of my modest assessment is that it’s not worth it. For instance, during kernel compilation I accidentally left out parameters which were later needed for my wireless driver in an absolutely non-trivial way. In addition, updates can be quite lengthy and require leaving the computer on overnight. Personally, I don’t consider this to be standard XXI-century practice, unless we’re developers and this is what we do out of fancy or for a living.

The distinct advantage of operating systems, such as Arch Linux or FreeBSD is that source file adjustment and compilation is optional and only required when we want to tinker with program components. Heck, at this point one could even try CRUX Linux, because it’s so much simpler. In addition, it seems to be a tad more KISS-savvy than Gentoo Linux.

Over and out!

Leave a comment