Why I like Gentoo
Update, 2021-02-15: I added the section with the distribution kernel.
I like Gentoo for several reasons! Two of the reasons is the fact that Gentoo makes my computer fun to use (again) and that their friendly and helpful community always brings a smile to my face.
I also like the atmosphere around Gentoo, it’s laid back and fairly.. meta. I feel like most Gentoo users seems to think of Gentoo as a tool rather than anything else, a personalized tool for your own personal needs.
There’s no elitism at all in the land of Gentoo and you don’t get any extra “Internet karma” for using some weird piece of software by some obscure project and you won’t get hated on for choosing to install the ‘wrong’ init-system or any ‘mainstream’ software, like a major desktop environment. As a long time user of other Linux based operating systems this was a truly fresh breath of air for me.
If you want to read about Gentoos philosophy in their own words I can highly recommend reading the philosophy of Gentoo by the creator Daniel Robbins.
Rolling release yet stable
With Gentoo, you get what I call a semi rolling release model. When it comes to the default kernel they always use the longterm support (LTS) kernel and when it comes to other software they’re in no hurry to rush out anything brand new to the stable repository. If you for some reason want to install a newer version of any package you can at any time choose to do so with ease.
When it comes to most other Linux based operating systems and their packages that’s classified as “unstable”, you’re almost always left with just one option; to enable a whole repository with untested packages, which is almost never a good idea. With Gentoo on the other hand you can allow untested packages on a per-package level and a lot more.
Gentoo doesn’t rely on various repositories to separate stable and untested packages from each other, they instead use something called keywords. There’re two keywords for every architecture:
||Both the package version and the ebuild are widely tested, known to work and not have any serious issues on the indicated platform.|
||The package version and the ebuild are believed to work and do not have any known serious bugs, but more testing is required before the package version is considered suitable for arch.|
You can add keywords for a specific package (or a whole category), a specific versions of a package and all versions of a package up to or after a specific version.
The package management system
Compiling your packages from source code with settings and optimizations specifically tuned for your hardware can sometimes give you a significant performance boost, but with today’s hardware that is for most not relevant anymore. The real benefit with compiling your own software is that you gain a greater control over the software you use. It means that you can customize the compiler and the target-application options to better fit you and your system. If you don’t use a feature with a certain package why should you then have to install the package with that feature enabled in the first place?
With something called USE-flags you can easily enable and disable specific features for software both on a global and on a per-package level. As an example; there’s a USE-flag called
perl which adds support for the programming language Perl for certain packages. My favourite terminal emulator URxvt comes with support for plugins via Perl and If I want it to support Perl I can just install the package
x11-terms/rxvt-unicodeas is, since the USE-flag
perl is enabled by default, but I don’t want to use Perl I can add the flag
-perl to completely disable support for Perl and avoid installing any unnecessary packages.
Another thing that I like with Gentoo is the fact that it’s easy to set up your own local repository and add your own ebuilds. An ebuild is a text file with Bash syntax that instructs the package manager on how to compile the package.
You can read this on the Gentoo wiki:
The Distribution Kernel project aims to maintain sys-kernel/*-kernel packages. These kernel packages have three goals:
- Covering kernel maintenance wholly within packages (install via emerge, upgrade as part of @world upgrade), without requiring additional actions from the user or resorting to non-portable hacks.
- Providing a default configuration that works for most of diverse systems, for users who are not interested in configuring their own kernel from scratch.
- Supporting different bootloaders and /boot layouts (LILO, GRUB, systemd-boot, EFI stub…) with minimal effort, including deploying self-built kernel binary packages over a fleet of heterogeneous systems.
The modern versions of Distribution Kernels support two mechanisms for changing the kernel configuration: savedconfig and /etc/kernel/config.d directory. Savedconfig replaces the entire default config with an administrator-supplied config file, so it is probably a better choice for those desiring to build an entirely custom kernel. When using /etc/kernel/config.d, configuration files are merged on top of the default configuration file, so it is more convenient for use-cases that change some specific options.
This means that you can maky changes to your kernel by simply creating a single file in a directory, adding any content you want, like
CONFIG_X86_X32=n and then simply emergin the kernel. If you want to, you can take it even further by enabling the USE-flag
savedconfig and use your own configuration file while you let emerge handle the rest of process. It can’t get any easier than this to use your own kernel.
A small note about installing packages in Gentoo
I let a friend read this draft before publishing it and it turns out he had totally misunderstood how you install packages in Gentoo using the default package manager emerge. He thought it was complicated, that you need to use
make and know where to install files, but it’s actually just as easy as installing any package in any other Linux based operating system:
# emerge --ask <package>
That’s everything! The flag
--ask/-a is optional, but I highly recommend using it so you get a chance to inspect what emerge wants to before it executes the command.
A better init
When the operating system I was using at the time switched over to systemd, I experienced a noticeable downgrade in terms of stability and usability. The two things that annoyed me the most wasn’t the stability issues, it was the binary logs and the fact that when I booted up and shut down the operating system I always had to wait 90 seconds for some issues with a service that was not working as intended.
I used systemd for several years and I really tried to like it for what it was, but I eventually gave up when I got fed up when something was always giving me a hard time. It did kill the fun in using computers for a while. It also didn’t help that they had (and still have) a weird approach to software design, an anti-UNIX philosophy and the fact that they sometimes make controversial moves that no one really asked for.
I have been using Gentoo for years now and I have so far never had any real issues with their init-system OpenRC, for me it has been reliable, familiar and easy to use.
The documentation is very good! The Gentoo wiki used to be regarded as the best documented wiki for a long time, but has in recent years been put down to a noble second place by the Arch Linux wiki.
The (sometimes) downsides with Gentoo can be the very fact that you have to compile pretty much all software by yourself. This can sometimes be an inconvenience for some on slow hardware, but if you do have a secondary computer with more horse power available you can set up Distcc on both computers and then distribute the compiling tasks between them across a network.
- Gentoo do provide some binary packages for some of the heavier packages like
That’s all! I hope you liked reading my thoughts about Gentoo.