A popular expression in the Linux forums nowadays is noting that someone “uses Arch btw”, signifying that they have the technical chops to install and use Arch Linux, a distribution designed to be cutting edge but that also has a reputation of being for advanced users only. Whether this meme was originally posted seriously or was started as a joke at the expense of some of the more socially unaware Linux users is up for debate. Either way, while it is true that Arch can be harder to install and configure than something like Debian or Fedora, thanks to excellent documentation and modern (but optional) install tools it’s no longer that much harder to run than either of these popular distributions.

For my money, the true mark of a Linux power user is the ability to install and configure Gentoo Linux and use it as a daily driver or as a way to breathe life into aging hardware. Gentoo requires much more configuration than any mainline distribution outside of things like Linux From Scratch, and has been my own technical white whale for nearly two decades now. I was finally able to harpoon this beast recently and hope that my story inspires some to try Gentoo while, at the same time, saving others the hassle.

A Long Process, in More Ways Than One

My first experience with Gentoo was in college at Clemson University in the late ’00s. The computing department there offered an official dual-boot image for any university-supported laptop at the time thanks to major effort from the Clemson Linux User Group, although the image contained the much-more-user-friendly Ubuntu alongside Windows. CLUG was largely responsible for helping me realize that I had options outside of Windows, and eventually I moved completely away from it and began using my own Linux-only installation. Being involved in a Linux community for the first time had me excited to learn about Linux beyond the confines of Ubuntu, though, and I quickly became the type of person featured in this relevant XKCD. So I fired up an old Pentium 4 Dell desktop that I had and attempted my first Gentoo installation.

For the uninitiated, the main thing that separates Gentoo from most other distributions is that it is source-based, meaning that users generally must compile the source code for all the software they want to use on their own machines rather than installing pre-compiled binaries from a repository. So, for a Gentoo installation, everything from the bootloader to the kernel to the desktop to the browser needs to be compiled when it is installed. This can take an extraordinary amount of time especially for underpowered machines, although its ability to customize compile options means that the ability to optimize software for specific computers will allow users to claim that time back when the software is actually used. At least, that’s the theory.

It didn’t work out too well for me and my Dell, though, largely because Dell of the era would put bottom-basement, obscure hardware in their budget computers which can make for a frustrating Linux experience even among the more user-friendly distributions due to a general lack of open-source drivers. I still hold a grudge against Dell for this practice in much the same way that I still refuse to use Nvidia graphics cards, but before I learned this lesson I spent weeks one summer in college with this Frankensteined computer, waiting for kernels and desktop environments to compile for days only to find out that there was something critical missing that broke my installations. I did get to a working desktop environment at one point, but made a mistake with it along the way and decided, based on my Debian experiences, that re-installing the operating system was the way to go rather than actually fixing the mistake I had made. I never got back to a working desktop after that and eventually gave up.

This experience didn’t drive me away from Gentoo completely, though. It was always at the back of my mind during any new Linux install I performed, especially if I was doing so on underpowered hardware that could have benefited from Gentoo’s customization. I would try it occasionally again and again only to give up for similar reasons, but finally decided I had gained enough knowledge from my decades as a Debian user to give it a proper go. A lot has changed in the intervening years; in the days of yore an aspiring Gentoo user had to truly start at the ground up, even going as far as needing to compile a compiler. These days only Gentoo developers take these fundamental steps, providing end users with a “Stage 3” tarball which contains the core needed to install the rest of Gentoo.

Bringing Out The Best of Old Hardware

And I do have a piece of aging hardware that could potentially benefit from a Gentoo installation. My mid-2012 Macbook Pro (actually featured in this article) is still a fairly capable machine, especially since I only really need a computer these days for light Internet browsing and writing riveting Hackaday articles. Apple long ago dropped support for this machine in macOS meaning that it’s no longer a good idea to run its native operating system. In my opinion, though, these older, pre-butterfly Macs are still excellent Linux machines aside from minor issues like finding the correct WiFi drivers. (It also can’t run libreboot, but it’s worth noting that some Macs even older than mine can.) With all of that in mind I got to work compiling my first Linux kernel in years, hoping to save my old Macbook from an e-waste pile.

There’s a lot expected of a new Gentoo user even with modern amenities like the stage 3 tarball (and even then, you have to pick a stage file from a list of around 50 options), and although the handbooks provided are fairly comprehensive they can be confusing or misleading in places. (It’s certainly recommended to read the whole installation guide first and even perform a trial installation in a virtual machine before trying it on real hardware.) In addition to compiling most software from source (although some popular packages like Firefox, LibreOffice, and even the kernel itself are available as precompiled binaries now), Gentoo requires the user to configure what are called USE flags for each package which specify that package’s compile options. A global USE flag file is also maintained to do things like build GNOME, Bluetooth, even 32-bit support into every package, while specific package USE flags are maintained in other separate files. For example, when compiling GIMP, users can choose which image formats they want their installation of GIMP to support. There’s a second layer of complexity here too as certain dependencies for packages can be “masked” or forbidden from being installed by default, so the user will also need to understand why certain things are masked and manually unmask them if the risk is deemed acceptable.

One thing that Gentoo has pioneered in recent years is the use of what it calls distribution kernels. These are kernel configurations with sane defaults, meaning that that they’ll probably work for most users on most systems on the first try. From there, users can begin tweaking the kernel for their use case once they have a working installation, but they don’t have to do that leg work during the installation process anymore. Of course, in true Gentoo fashion, you can still go through the process of configuring the kernel manually during the install if you choose to.

Aside from compiling a kernel, Gentoo also requires the user to make other fundamental choices about their installation during the install process that most other major distributions don’t. Perhaps the biggest one is that the user has to choose an init system, the backbone of the operating system’s startup and service management systems. Generally most distributions decide for you, with most larger distributions like Debian, Fedora, and Arch going with systemd by default. Like anything in the Linux world, systemd is controversial for some, so there are alternatives with OpenRC being the one with the most acceptance in the Gentoo world. I started out with OpenRC in my installations but found a few pieces of software that I use regularly don’t play well with it, so I started my build over and now use systemd. The user also can select between a number of different bootloaders, and I chose the tried-and-true Grub seeing no compelling reason to change at the moment.

In addition, there’s no default desktop environment, so you’ll also need to choose between GNOME, KDE, XFCE, any other desktop environment, or among countless window managers. The choice to use X or Wayland is up to you as well. For what it’s worth, I can at least report that GNOME takes about three times as long to compile as the kernel itself does, so keep that in mind if you’re traveling this path after me.

It’s also possible you’ll need to install a number of drivers for hardware, some of which might be non-free and difficult to install in Gentoo while they might be included by default in distributions like Ubuntu. And, like everything else, they’ll need to be compiled and configured on your machine as well. For me specifically, Gentoo was missing the software to control the fans on my MacBook Pro, but this was pretty easy to install once I found it. There’s an additional headache here as well with the Broadcom Wi-Fi cards found in older Macs, which are notoriously difficult pieces of hardware to work with in the Linux world. I was eventually able to get Wi-Fi working on my MacBook Pro, but I also have an 11″ MacBook Air from the same era that has a marginally different wireless chipset that I still haven’t been able to get to work in Gentoo, giving me flashbacks to my experience with my old Dell circa 2007.

This level of granularity when building software and an overall installation is what gives Gentoo the possibility for highly optimized installations, as every package can be configured for the user’s exact use case for every package down to the kernel itself. It’s also a rolling release model similar to Arch, so in general the newest versions of software will be available for it as soon as possible while a Debian user might have to wait a year or two for the next stable release.

A Few Drawbacks

It’s not all upside, though. For those without a lot of Gentoo experience (including myself) it’s possible to do something like spend a day and a half compiling a kernel or desktop environment only to find out a critical feature wasn’t built, and then have to spend another day and a half compiling it again with the correct USE flags. Or to use the wrong stage file on the first try, or realize OpenRC won’t work as an init system for a specific use case, or having Grub inscrutably be unable to find the installation. Also, don’t expect Gentoo to be faster out-of-the-box than Debian or Fedora without a customization effort, either; for me Gentoo was actually slower than Debian in my benchmarks without a few kernel and package re-compiles. With enough persistence and research, though, it’s possible to squeeze every bit of processing power out of a computer this way.

Personally, I’m not sure I’m willing to go through the amount of effort to migrate my workstations (and especially my servers) to Gentoo because of how much extra configuration is required for often marginal performance gains thanks to the power and performance capabilities of modern hardware. Debian Stable will likely remain my workhorse for the time being for those machines, and I wouldn’t recommend anyone install Gentoo who doesn’t want to get into the weeds with their OS. But as a Linux hobbyist there’s a lot to be said for using other distributions that are a little more difficult to use than Debian or even Arch, although I’d certainly recommend using a tool like Clonezilla to make backups of your installation from time to time so if you do make the same mistakes I made in college you can more easily restore your system. For me, though, I still plan to keep Gentoo on my MacBook Pro since it’s the machine that I tinker with the most in the same way that a classic car enthusiast wants to keep their vehicle on the road and running as well as it did when it was new. It also lets me end forum posts with a sardonic “I use Gentoo, btw” to flex on the Arch users, which might be the most important thing of all.

For those of you longing for better gaming on an Apple Silicon device, Asahi Linux is here to help.

While Apple’s own line of CPUs are relatively new kids on the block, they’ve still been around for four years now, giving hackers ample time to dissect their innards. The team behind Asahi Linux has now brought us “the only conformant OpenGL®, OpenCL, and Vulkan® drivers” for Apple’s M1 and M2.

The emulation overhead of the system means that most games will need at least 16 GB of RAM to run. Many games are playable, but newer titles can’t yet hit 60 frames per second. The developers are currently focused on “correctness” and hope to improve performance in future updates. Many indie titles are reported to already be working at full speed though.

You can hear more about some of the fiddly bits of how to “tessellate with arcane compute shaders” in the video below. Don’t worry, it’s only 40 minutes of the nine hour video and it should start right at the presentation by GPU dev [Alyssa Rosenzweig].

If you want to see some of how Linux on Apple Silicon started or some of the previous work on hacking the M1 GPU, we have you covered.

These days, when something electronic breaks, most folks just throw it away and get a new one. But as hackers, we prefer to find out what the actual problem is and fix it. [Bonsembiante] took that very tack when a MOTU brand audio interface wasn’t booting. As it turns out, a bit of investigative work led to a simple and viable fix.

The previous owner had tried to get the unit fixed multiple times without success. When it ended up on [Bonsembiante]’s bench, reverse engineering was the order of the day. Based around an embedded Linux system, there was lots to poke and prod at inside, it’s just that… the system wasn’t booting, wasn’t showing up over USB or Ethernet, or doing much of anything at all.

Extracting the firmware only revealed that the firmware was actually valid, so that was a dead end. However, after some work following the boot process along in Ghidra, with some external help, the problem was revealed. Something was causing the valid firmware to fail the bootloader’s checks—and with that fixed, the unit booted. You’ll have to read the article to get the full juicy story—it’s worth it!

We’ve seen [Bonsembiante’s] work here before, when they turned an old ADSL router into a functioning guitar pedal. Video after the break.

Although Linux runs almost every supercomputer, most of the web, the majority of smart phones, and a few writers’ ancient Macbooks, there’s one major weak point in the Linux world that will almost always have developers reaching for a different operating system. Linux is not a real-time operating system (RTOS), meaning that it can’t respond to requests in the real world within a set timeframe. This means that applications needing computer control in industry, medicine, robotics, and other real-world situations generally need a purpose-built RTOS. At least, that was true until recently when an update to the Linux kernel added real-time capabilities.

The feature, called PREEMPT_RT, forces the Linux kernel to respond to certain request within a set limit of time. This means that a system with this support built into the kernel can “preempt” any current task, stopping everything else a computer is doing in order to execute that task right away. There are some existing solutions to getting a functional equivalent system working with Linux now, but they can be clunky or inelegant, requiring the user to install patches or other software to get it to work. With the support built directly into the kernel this will become much less of a pain point for anyone who needs this functionality going forward.

This feature has been in the works for around two decades now, so with this entering general use now we would expect to start seeing it show up in various projects as well as in commercial offerings soon, especially since other RTOS solutions can be pricey. Don’t recompile the kernel in your desktop for this feature just yet, though; real-time function can cause some unintended consequences with normal use you’ll need to account for. There’s some more discussion on this in the /r/Linux subreddit and there are some other real-time operating systems available for computers not typically capable of running Linux to take a look at as well.

It’s not uncommon for a new distro version to come out, and a grudging admission that maybe a faster laptop is on the cards. Perhaps after seeing this project though, you’ll never again complain about that two-generations-ago 64-bit multi-core behemoth, because [Dimitri Grinberg] — who else! — has succeeded in booting an up-to-date Linux on the real most basic of processors. We’re not talking about 386s, ATmegas, or 6502s, instead he’s gone right back to the beginning. The Intel 4004 was the first commercially available microprocessor back in 1971, and now it can run Linux.

So, given the 4004’s very limited architecture and 4-bit bus, how can it perform this impossible feat? As you might expect, the kernel isn’t being compiled to run natively on such ancient hardware. Instead he’s achieved the equally impossible-sounding task of writing a MIPS emulator for the venerable silicon, and paring back the emulated hardware to the extent that it remains capable given the limitations of the 1970s support chips in interfacing to the more recent parts such as RAM for the MIPS, an SD card, and a VFD display. The result is shown in the video below the break, and even though it’s sped up it’s clear that this is not a quick machine by any means.

We’d recommend the article as a good read even if you’ll never put Linux on a 4004, because of its detailed description of the architecture. Meanwhile we’ve had a few 4004 stories over the years, and this one’s not even the first time we’ve seen it emulate something else.

If you cut your teeth on Z-80 assembly and have dabbled in other assembly languages, you might not find much mystery in creating programs using the next best thing to machine code. However, if you have only used high level languages, assembly can be somewhat daunting. [Shikaan] has an introductory article aimed to get you started at the “hello world” level of x86-64 assembly language. The second part is already up, too, and covers control structures.

You can argue that you may not need to know assembly language these days, and we’ll admit it’s certainly not as important as it used to be. However, there are unusual cases where you really need either the performance or the small footprint, which is only possible in assembly language. What’s more, it is super useful to be able to read assembly from your high-level tools when something goes wrong.

Of course, one of the problems is that each assembly language is different. For example, knowing that the x86 assembly doesn’t completely transfer to ARM instructions. However, in most cases, the general concepts apply, and it is usually fairly easy to learn your second, third, or fourth instruction set.

We’ve had our own tutorials on this topic. You can also debate if you should learn assembly first or wait, although in this case, the audience is people who waited.

Although Android technically runs on top of Linux, generally most Android devices abstract away the underlying Linux-ness of these machines. In theory this is a good thing; we wouldn’t necessarily want to live in a world where we have to log in to a command-line interface just to make a phone call. But too much abstraction often needlessly restricts the capabilities of the underlying hardware. [Murray] a.k.a [Green Bug-Eyed Monster] has an Android TV box with just such a problem, as the Android OS included with it allows for watching TV just fine, but with a few tweaks it can run a full Linux installation instead, turning it into a much more versatile machine.

This specific Android TV box is based on the Rockchip 3566, a popular single-board computer used in a wide array of products. As such it is one of the easier targets for transforming a limited TV machine into a fully capable desktop computer. The first step is to compile an Armbian image for the machine, in this case using an x86 installation of Ubuntu to cross-compile for the ARM-based machine. With a viable image in hand, there’s an option to either solder on a microSD slot to the included pins on the computer’s PCB or to flash the image directly to the on-board eMMC storage by tricking the machine into thinking that the eMMC is missing. Either option will bring you into a full-fledged Linux environment, with just a few configuration steps to take to get it running like any other computer.

[Murray] began this process as an alternative to paying the inflated prices of Raspberry Pis over the past few years, and for anyone in a similar predicament any computer with the Rockchip 3566 processor in it could be a potential target for a project like this. You might need to make a few tweaks to the compile options and hardware, but overall the process should be similar. And if you don’t have an RK3566, don’t fret too much. We’ve seen plenty of other Android TV boxes turned into similar devices like this one which runs RetroPie instead.