Why we do need Devuan

Some months ago when I looked at the Devuan efforts I thought they’re directed at eradicating any traces of systemd and the Red Hat agenda from Debian. After all, the wounds were fresh and hatred still strong. However, the problem Devuan bravely tries to address is much deeper and echoes across the whole of the GNU/Linux ecosystem. Articles covering systemd merely graze the tip of the iceberg that is *software compatibility*.

GNU/Linux distributions power most of world’s servers, workstations, mainframes and supercomputers. In such mission critical environments it is absolutely mandatory that the computer is up and running most of the time. Update downtime should be minimized and process supervision for key services simplified (less resources needed for maintenance, less possibilities for bugs via human error, etc.). While systemd may seem like it addresses above problems, there are 2 main problems:
1. The simplified process supervision is only superficial. Systemd “seems” simpler, but in fact it does a lot more than a mere supervisor + init. Therefore, the surface for bugs is in reality far greater. In addition, process supervision is not a new concept and many alternative (and simpler!) suites exist.

2. Systemd breaks compatibility with former service scripts (from sysVinit) and has absolutely no intention of fixing this. The goal is unification and streamlining of the whole GNU/Linux ecosystem, not making things work.

The first point is an obvious bait for administrators who are tired of fighting with inflexible Shell scripts and overall hackery. The second point, however, should serve as a MAJOR deterrent to anyone looking for a reasonable process supervisor. There is plenty of intermittent options like OpenRC and sanely written go-to supervisors like s6, nosh or runit. Those are some low-hanging fruits, just ready to be picked…

Devuan is an important project, because it acts as a nucleator, not against systemd, but for preserving what Unix is all about – maintainability, efficiency and modular design. It tries to encourage people to care about the “Unix way” more and be aware that current mistakes will prove costly soon enough. Nowadays, we have several program packages that do what systemd offers, though in a much more elegant and non-intrusive fashion. They can be seamlessly merged with existing OS frameworks and used interchangeably.


Gentoo Captain’s Journal III

Entry #3 Oct 5th 2016:

As promised, this one will be devoted to Gentoo’s package manager – Portage. Almost all distributions have streamlined package management nowadays. No need to fetch tarballs via “wget” or “curl”, inspect code and compile manually with “make”. Everything is handled by a set of utilities that do dependency resolution, sync repositories and register installed software.  Gentoo has all of this and more. Below, a quick roundup of common Portage query operands applicable to the “emerge” Python tool:

  • –ask (-a) – asks for user confirmation before beginning installation
  • –verbose (-v) – print additional useful (for instance, for debugging purposes) information
  • –update (-u) – update installed packages
  • –deep (-D) – check whole ports tree deeply during dependency resolution
  • –sync – synchronize the local ports tree with a mirror
  • –new-use (-N) – a new USE flag was added to one of the configuration files; include that when preparing the payload
  • –depclean – remove any lingering, unused dependencies
  • –unmerge (-c) – remove selected package(s)
  • –quiet (-q) – do not print the complete transaction details to stdout
  • –quiet-build – do not print compilation logs to stdout
  • –noreplace – do not re-emerge package if it was already installed
  • –oneshot – prepare transaction, but do not write details to configuration files

There are of course many more, all of which can be found in the manpage for “emerge”. Interestingly, operands may be used in combinations so that “emerge -auDN” or “emerge -auD” is the standard update command. In addition, performing “–depclean” together with the “–verbose” operand prompts Portage to do reverse dependency resolution also. Contrary to other GNU/Linux distributions, Gentoo’s Portage organizes software in sets (@). @system is the basic set of system utilities vital for package building and management. @world is a higher level set, encompassing also software specifically installed by the user. One can create additional sets locally to store information on favorite applications.

I think Portage is an amazing package manager that does so much that apt and dnf should be ashamed or at least envious. I wish other distributions would offer a similar level of flexibility.

Gentoo Captain’s Journal II

Entry #2 – Oct 4th 2016:

One of the unique features of Gentoo are USE flags. They determine what sort of options do we want or don’t want in our software. Ever noticed how audio decoders don’t come with the full set of codecs in Fedora? Or a program handling text doesn’t have support for the language we would like it to have? USE flags address those issues. They allow the user to tailor the whole operating system to his/her needs. There are two main types of USE flags – local and global. The former work on per-application basis, though can be shared between applications with similar functionalities, like audio encoders/decoders. Local USE flags are specified within the /etc/portage/package.use directory in the format “package-group/package-name flag”. Global USE flags apply to the whole system and allow one to define system-wide trends, like “YES to the GTK engine, themes, etc.”, “NO to KDE related libraries”, “NO to Qt graphical libraries”, etc. They’re placed in the /etc/portage/make.conf text file as part of the USE string. Finally, there are also the USE_EXPAND flags that pertain to specific core system components like Ruby, Perl, Python, Apache modules, etc. They can either be defined globally in the /etc/portage/make.conf text file in separate strings (for instance, PYTHON_TARGETS for version-specific, system-wide Python support) or in the /etc/portage/package.use directory as standard USE flags with special syntax (for instance, python_targets_python2_7).

Working with USE flags is initially tricky, especially when we want to install (“emerge”) a lot in one go. Frequent adjustments of both local and global USE flags are part of standard Gentoo maintenance practices. However, eventually we tailor the system to our liking and incremental, weekly updates become less problematic. Still, updates are necessary, like in the case of any other rolling-release distribution. Arch Linux is similar in that manner, though it doesn’t suffer from user mistakes as much. Therefore, always check a full installation query before committing. In the next entry I will talk about Gentoo’s package manager Portage, since it too has some amazing features.

Lastly, I would like to discuss true 64-bit support that so far is only available to Gentoo Linux as part of the USE flag system. One can install a pure 64-bit operating system without support for 32-bit software (“non-multilib”). This is probably useful when building a 64-bit server or embedded device to limit unnecessary clutter of 32-bit libraries. If the kernel is configured with 32-bit ABI support, 32-bit software can then be run in an isolated chroot (secured via some container technology, for instance). However, this entails the obvious need to maintain two systems at the same time – the host non-multilib 64-bit system and the contained 32-bit system. On a standard 64-bit multilib system, 32-bit support can be triggered on a per-application basis using the abi_x86_32 flag. I would strongly discourage this, however. It will mess up the system whenever a 32-bit program is installed, because then a lot of libraries have to be rebuilt with added 32-bit support. it’s better to add 32-bit support globally via the ABI_X86 USE_EXPAND flag in /etc/portage/make.conf.

Gentoo Captain’s Journal I

I’m a tinkerer at heart, after my father, who’s an electronics engineer. When I was still a toddler, he showed me everything – how to clean computers, how to turn them inside-out, how to exchange hard drives, do upgrades, etc. Those were valuable lessons that I unconsciously stored in the depths of my memory pockets for years. Now they’re finally starting to blossom. They just needed a trigger, I guess. Anyhow, my latest fancy is Gentoo. Though it’s considered a fully fledged GNU/Linux distribution, I feel it’s more of a framework since many things are optional and most of the system utilities have to be compiled from source code. Honestly, it’s a great learning experience, a “rite of passage” of sorts in the GNU/Linux world. Therefore, I decided to document my trials – fortunes and mishaps alike. Might be of value to the future “me” and many others who struggle with similar dilemmas or issues. Let’s get down to business then, shall we?


Entry 1# – Oct 1st 2016:
Every operating system has a kernel. Windows uses the NT kernel, MacOS X relies on the Mach kernel, GNU/Linux has the Linux kernel (surprise, surprise) and various BSDs have their own BSD kernels (FreeBSD, DragonflyBSD, OpenBSD, NetBSD, etc.). Finally, Illumos and OpenIndiana utilize the Illumos kernel. However, only the Illumos-based, BSDs and Linux-based operating systems allow the user to configure and compile the kernel from source code. It’s a non-trivial and oftentimes daunting undertaking. However, knowing what hardware the kernel supports pays off in the long-run. Not to mention the lower resource usage of a kernel that has been trimmed down and tailored to a specific machine. As long as one has the time and will to learn, the benefits are substantial. However, there are certain limitations that cannot be easily circumvented:

  • Because GNU/Linux covers only ~1% of the consumers computer market, many hardware vendors don’t give a flying wardrobe about providing drivers for the Linux kernel.
  • Per above, if GNU/Linux compatible drivers are actually provided, they tend to be poorly documented.
  • Lacking documentation makes it difficult to know which kernel features need to be ON for external drivers to load and function.
  • Computer and device vendors seldom provide information on the make and version of the internals (chips).

The one and only solution is to do proper data mining on the piece of hardware in question, prior to buying it. Then, seriously consider whether building a kernel from scratch is worth the effort. Regardless, Gentoo Linux recommends compiling one’s own kernel as that way we’re sure that every computer internal is fully operational (or not!) when booting the operating system afterwards. Kernel configuration and compilation is fully manual and typically proceeds according to the respective Handbook chapter. Since I don’t like running too many commands by hand, I wrote a simple shell script to do the kernel upgrades for me:

# a simple script to rebuild the kernel, regenerate initramfs with genkernel
# and GRUB2 bootloader config.
read -p "State the kernel version: " KERNEL_VERSION
if [ -e /usr/src/linux-$KERNEL_VERSION-gentoo ] ; then
    cd /usr/src/linux-$KERNEL_VERSION-gentoo
    make silentoldconfig
    make && make modules_install
    make install
    genkernel --install initramfs
    grub-mkconfig -o /boot/grub/grub.cfg
    echo "Sorry mate/lass, kernel sources for this version don't exist!"

“Genkernel” is a handy Gentoo tool that allows building of the initial RAM disc (initramfs) and the kernel also if we’re not interested in working with the .config file. It’s especially useful for non-standard setups like LVM, RAID or disc encryption. Additional details are available in the genkernel manpage. My first kernel compilation took ~1 hour, though together with reading through the configuration file I spent around 3 hours on it in total. On modern hardware the compilation would take 30-60 min and obviously the time devoted to learning about supported hardware is time well-spent. The gained knowledge can be applied to any GNU/Linux distribution. As I said earlier, it pays off in the long-run. To elaborate, running “make silentoldconfig” will ask for confirmation on new features (changed since last configuration) and “make oldconfig” will assume the default responses for them (“Yes”, “No”, “build as module”). If one has multiple versions of the Gentoo kernel, the primary version can be easily selected via the “eselect” tool (“eselect kernel list” to show available kernels and “eselect kernel set <number>” to choose the kernel). I will mention eselect many more times still as it is used for other selections, too.