Hans Fernhout's Blog

Introduction

I already said that I like Gentoo Linux, but it can take some effort to keep it up to date, especially on less capable hardware. I tried to install Gentoo on a Raspberry Pi 4B and found a way how to do that, years back. However, that project is dead now, and the successor project on the Gentoo Wiki looks a lot more complicated. I have done those cross compile excercises in the past, and found that it requires even more maintenance than regular Gentoo. No thanks.

I also have an old netbook, an Acer Aspire One ZG5 with an Intel Atom N270 processor. It is over ten years old and it was underpowered even when I bought it. The good thing about it is that it uses just a tiny bit of power and it is small. I use it sometimes for checking things out. It runs Gentoo fine, but it can take days to update. When I stumbled on Alpine Linux, which has a focus on small and embedded systems, I thought I should try it on both the Pi, and the netbook.

Raspberry Pi

Alpine has a specific image for the Pi, even for the 64 bit AArch64 architecture, and a good wiki article describing how to install it. My Pi has 8 GB of memory, so the default option of Alpine to run the whole operating system on an overlay file system in memory sounds appealing:

• The Pi does not have a disk. It boots from a slow SD card. Loading programs from the card would be slow. Running the OS from memory would also reduce wear on the SD card.
• There are security advantages of running an OS in memory.

It is possible to install additional packages. These get installed in memory on the overlay file system. Memory is not persistant, so installed packages would be gone after a reboot. The same applies to any changes in settings. There is however a possibility to save installed packages in a local repository cache on the SD card, as well as any changed configuration files. This is done through the local backup utility, lbu. When the system boots, it loads the OS in memory, copies the configuration files over it and reinstalls the packages again, also on the overlay file system in memory.

Alpine boots quick enough on the Pi, but the more packages are installed, the slower it gets. It is still doable though, even with a complete desktop installed like this.

Acer Aspire

It has a nice ring to it: Alpine on an Acer Aspire...

The classic way of installing an operating system on a computer's harddisk is more appropriate for this system with a regular harddisk and only 1 GB of memory. Alpine could be installed alongside of Gentoo, by giving it its own btrfs subvolume on the existing harddisk partition.

The base disk layout before installing Alpine was as follows:

/dev/sda1: ext4, boot volume
/dev/sda2: swap
/dev/sda3: btrfs, gentoo and home as subvolumes

Creating the Alpine subvol was done from Gentoo.

Then, after booting Alpine, the Alpine btrfs subvol and the boot partition needed to be mounted:

# mkdir /mnt/alpine
# mount -o subvol=alpine /dev/sda3 /mnt/alpine
# mkdir /mnt/alpine/boot
# mount /dev/sda1 /mnt/alpine/boot

Finally run the setup-disk program with the appropriate environment variables:

# ROOTFS=btrfs
# BOOTFS=ext4
# SYSROOT=/mnt/alpine
# BOOTLOADER=grub
# setup-disk -q -v /mnt/alpine

I had to manually edit the grub boot configuration, because with a separate boot partition, grub-mkconfig cannot figure out where the root partitions of the different kernels are located.

Impressions

I read somewhere that Alpine was originally based on Gentoo, and certainly see the similarities. Of course, the service manager OpenRC is used by both distros. I did read though that Alpine may replace OpenRC with something new, which would be a pity: I like OpenRC. It would also mean that Alpine can no longer borrow the OpenRC scripts from Gentoo.

A key difference is that Alpine is a binary distribution, which makes software package installations much faster than the emerges on Gentoo, but it cannot take advantage of the specific CPU capabilities like Gentoo. For instance, when a CPU has the AES-NI instruction, and the software makes use of it by setting appropriate march and mtune parameters when software is being compiled, encryption and decryption can be much faster. This could have a notable effect to network traffic like https, vpn and ssh, and when using LUKS encrypted disks. For the case of the Pi and the netbook it does not matter much though: the Atom processor does not have many specific instructions, and the AArch64 processor does not have such variations that it will make a difference. The AArch64 architecture is also new enough that is does provide for instructions to handle AES encryption and decryption. Using specific CPU instructions is more relevant on x86 and amd64 architectures with a lot of history, where recent high end processors have a richer instruction set compared to older or simpler ones.

Alpine makes heavy use of busybox, which provides many of the functions normally provided by individual programs. In /bin 80 of the 90 programs softlink to busybox, and in /usr/bin 131 out of 164. Busybox does not provide completely the same functionalities though, e.g:

• Busybox provides ash as a command interpreter, instead of the more common bash. Something to note when creating shell scripts.
• Busybox even provides the vi editor, but not all editing commands are understood.

Initially I had the urge to replace commands provided by busybox with the real commands by installing the real packages, On the Pi that makes the boot process slow, and it would use more memory runtime. I think it would be better to live with the limited busybox commands.

Another difference is the release method. Where Gentoo employs a true rolling release model, Alpine is versioned. Upgrading from one version to the next would require updating the repository URLs. I have not done that yet.

One comment that can be read often is that Alpine uses the musl C library instead of the more common GNU C library glibc. From a user perspective I do not think it matters much:

• Maybe musl is slower, but who can tell? It may be just a theoretical disadvantage.
• It is nice that musl is smaller for memory constrained systems. The combination of musl and busybox leads to the amazing small size of just 11 MB for /usr and /usr/bin together on the netbook for Alpine. These directories on Gentoo take 95 MB. These numbers are valid for base installations of Alpine and Gentoo, which are not completely comparable because they do nor provide the same functionalities. A factor 8 is still impressive.

Conclusion

Alpine Linux is allright. It is great for low powered computers. The overlay file system is quite fascinating. I hope Alpine will stick with OpenRC: instead of creating something new yet again, why not spend the effort to improve OpenRC? Alpine is heavily used for Docker containers, so it may be that knowing a bit more about Alpine is useful when I explore Docker in the future more.