Intel’s Clear Linux distribution has been getting a lot of attention lately, due to its incongruously high benchmark performance. Although the distribution was created and is managed by Intel, even AMD recommends running benchmarks of its new CPUs under Clear Linux in order to get the highest scores.

Recently at Phoronix, Michael Larabel tested a Threadripper 3990X system using nine different Linux distros, one of which was Clear Linux—and Intel’s distribution got three times as many first-place results as any other distro tested. When attempting to conglomerate all test results into a single geometric mean, Larabel found that the distribution’s results were, on average, 14% faster than the slowest distributions tested (CentOS 8 and Ubuntu 18.04.3).

There’s not much question that Clear Linux is your best bet if you want to turn in the best possible benchmark numbers. The question not addressed here is, what’s it like to run Clear Linux as a daily driver? We were curious, so we took it for a spin.

Installing Clear Linux

Installation is much the same for Clear Linux as for any other operating system—download the ISO, dump it to a thumb drive, boot, and go. Two installer versions are available: a “server” that’s text-mode only and a “desktop” that uses a fully featured live desktop environment. We chose the desktop. On real hardware, Clear gave us no trouble and installed immediately—but in a KVM environment, it initially refused to install, with a less-than-helpful “failed to pass pre-install checks” error message.

A little sleuthing online uncovered the fact that while Clear Linux’s live desktop environment will boot in BIOS mode, the actual OS requires UEFI. In our virtualization environment—Linux KVM, under Ubuntu 19.10—new VMs default to BIOS mode unless you check “Customize configuration before install” on the final step, and then in the Overview tab, change from BIOS to UEFI. So we blew away the VM, recreated it with the appropriate UEFI firmware, and then we were off to the races.

Once we’d straightened out our VM’s firmware architecture, installing Clear Linux in a VM was as straightforward as on real hardware—real hardware with UEFI firmware, that is. If you were hoping to install Clear Linux on legacy hardware that only supports BIOS mode, you’re out of luck.

The installer is clear and straightforward. You must choose a language (currently from a very limited list), an installation target, and feed the installer a username and password for the new OS. You also need to let it know whether you’re opting in or out of phone-home telemetry used for QA and dev purposes.

When setting an installation target, Clear Linux offers either a “safe” installation or a “destructive” one. We did not test the safe installer, instead choosing to install Clear Linux as the only operating system available.

Once you’ve selected your options, Clear shouldn’t take more than a few minutes total to actually install—but if you walk away and come back, it’s worth realizing that the screen saver lock screen may kick in on you. (If you’re not used to Gnome3, click and drag up to dismiss the lock screen.)

Post-installation: The GIMP race

For the most part, there didn’t seem like a lot of point in doing traditional performance benchmarks on Clear Linux. Phoronix has already done plenty of those—and yes, without a doubt, Clear Linux is faster on average than most distros. But winning benchmarks isn’t necessarily the same thing as feeling fast.

Without a point of reference for comparison—a watched and ticking timer or a head-to-head race—most people won’t notice less than 33% difference in the time to complete a familiar task. A typical observer—one not actually timing things—faced with an hour-long task that completed in 40 minutes will think “hey, that seemed fast.” The same observer, waiting for a one second task to complete, will generally start frowning around 1300ms.

We should also point out that the majority of Phoronix’s benchmarks focus on long-running computational or storage tasks. This type of benchmark correlates better to changes in hardware than to changes in software at the distribution level. That is to say, even if Clear Linux benchmarks faster at a task relevant to desktop performance, the difference may be easily overwhelmed by differences in the desktop—or the specific application package—itself.

When I installed and opened GIMP in a Clear Linux virtual machine, I thought, “that feels fast”—but I was expecting it to feel fast. To test my initial perception, I also opened GIMP on my Ubuntu 19.04 workstation itself, and counted Mississippi—turns out, the Ubuntu desktop was actually twice as fast as the Clear desktop. So much for human perception? Perhaps not—I work within VMs a lot, so maybe I had been subconsciously comparing the Clear VM to an Ubuntu VM, not to Ubuntu on the host workstation.

To test that theory, I brought an Ubuntu 18.04.4 VM and a Clear Linux VM up side by side, each with 4 vCPUs and 4GB of RAM allocated. Then I installed and configured the NTP daemon on both VMs, to bring their clocks to within a millisecond of one another, and installed my own whenits scheduling utility. With all that done, the results of a side-by-side “GIMP race” were no different—despite having the same resources allocated to each, the Ubuntu 18.04 VM still “won” handily.

Investigating further, I noticed that Ubuntu 18.04 uses an older version of GIMP than Clear does. So I uninstalled the system-provided GIMP 2.08 from the Ubuntu VM, and installed the latest 2.10.14—the same version Clear uses—from a PPA. The outcome didn’t change significantly—GIMP still opened faster in the Ubuntu VM, and you can see the side-by-side results of that final “race” in the short video clip above.

None of this should be taken as a definitive benchmark making Clear Linux out to be “slow.” But it does demonstrate the fallibility of human perception and the limits of how much impact a “fast” distro can really have on normal, day-to-day operation of a desktop system. Aside from booting, Clear Linux didn’t feel noticeably faster than Ubuntu in general use—either in VMs hosted on my Ryzen 3700X workstation or on an i7-6500U powered Dell Latitude I installed it on directly.

If you’re the sort of person who gets really enthusiastic about compiler optimizations in Gentoo or Arch packaging—or if you’ve got a very specific task that you’re eager to potentially accelerate by 15% or so—Clear might very well be for you. But if you expect the kind of kick-in-the-pants speedup that your friends will immediately notice and drool over, you’ll probably be disappointed.

Installing software

Ubuntu 19.10 and Clear Linux both use the Gnome Software Center as a GUI for software installation and removal. The most immediately obvious difference here is Canonical’s efforts to make the repositories in their version of Software Center feel more curated and caretaken—Ubuntu’s Software Center prominently features Editor’s Picks and featured applications that Clear Linux doesn’t.

Somewhat more importantly, Canonical has much deeper repositories underneath than Clear does—and that can make an impact even when both distributions offer a particular application. For example, the game Frozen Bubble is available in Software Center on either distribution—but on Clear, it’s sourced as a flatpak, coming from third-party source dl.flathub.org.

On Ubuntu, Frozen Bubble comes from Canonical’s own Universe repository instead of a third-party source. That might not sound like it matters—but installing the game on Ubuntu from Canonical’s own repository only took a few seconds, while it took nearly ten minutes to install on Clear.

Will it Chrome?

 

Neither Clear Linux nor Ubuntu bundle the Google Chrome browser—but on Ubuntu, installation is as straight-forward as it would be on Windows: a search, a download, a click, and you’re done. The actual download you get is an Ubuntu native .deb file, and besides installing the browser itself, it automatically updates your repository list—so from then on, Chrome will be automatically updated by Ubuntu, the same way and using the same tools as the standard system updates.

Browsing to the Chrome download page in Clear Linux’s natively installed Firefox presents you with the same choice of a .deb or .rpm download—but neither one will “just work.” There is a bit of trickery you can do on Clear Linux’s command line to download the .rpm file, extract and install it, and then do some manual reconfiguration to keep the fonts from looking weird.

Unfortunately, Chrome won’t be automatically updated as it would on Ubuntu or most other desktop distributions—you’ll instead have to remember to update it yourself, and go through the same few steps on the command line (including reconfiguration of the fonts) each time you do.

Package management

Of course, more advanced users will likely never bother with the Software Center in the first place, on either distribution. Ubuntu, as a Debian-based distribution, uses .deb packages under the hood, which can be installed, updated, removed, and searched using the apt command line tool. Clear Linux doesn’t use apt—or yum, zypper, pacman, pkg, or anything else you’ve likely heard of. Instead, it uses its own command-line package management tool called swupd.

For the most part, swupd works like any other package manager—there’s an argument to install packages, another couple to search them either by package name/description or by included files, and so forth. Unfortunately, I must admit I found swupd consistently frustrating—in particular, the arguments are verbose and oddly worded.

In Debian, Ubuntu, Fedora, OpenSUSE, CentOS, or FreeBSD you’d install to install a new app from repositories—for example, apt install gimp. But in swupd, you swupd bundle-add instead. You similarly bundle-remove, bundle-list, bundle-info and so on.

This might sound like a minor, petty distinction, but I found it to be pretty obnoxious. I fumbled the syntax—for example, mistakenly typing add-bundle instead of bundle-add—far more frequently than I normally do when using an unfamiliar package manager.

The bundles themselves also flout relatively standard naming conventions pretty frequently. For example, when I found myself needing a particular set of headers that Ubuntu has in uuid-dev, and Fedora has in libuuid-devel, Clear Linux instead had them in os-core-dev—and figuring that out was an enormous nuisance. Trying swupd search uuid didn’t list the os-core-dev bundle at all—and neither searching for the actual file I needed, with swupd search-file uuid.h. (More on this topic later.)

Although swupd works, it feels an awful lot like the result of NIH Syndrome. Intel claims that a lot of Clear Linux’s secret sauce is in the packaging, and perhaps it genuinely needed to build its own management tool from the ground up. But from this sysadmin’s perspective it’s difficult to see the benefits, and easy to see the warts—a little more effort devoted to swupd‘s polish and usability would go a long way.

Will it ZFS?

Not everybody is going to care whether you can get OpenZFS working on Clear Linux. But certainly cared, and I spent a ridiculous amount of time chasing this particular dragon. I was seriously considering paving my main laptop and reinstalling it with Clear Linux for a long-term test drive—but even on “just a laptop” I didn’t want to do without ZFS’ ability to rapidly asynchronously replicate, cryptographically detect and repair bitrot, use inline compression, and so forth and so on.

The OpenZFS project itself doesn’t have any installation notes for Clear Linux, and a swupd search zfs came up empty, so I hit the Internet. Searching “Clear Linux ZFS” brings you rapidly to Clear’s FAQ, which states “ZFS is not available with Clear Linux OS” and offers btrfs as an alternative.

Btrfs offers most of the same features that ZFS does—but unfortunately, if you actually use the most interesting of those features, such as redundant arrays with data healing, rapid replication, or inline compression, it rapidly becomes unreliable. (Yes, really—commercial NAS devices such as Synology and Netgear’s ReadyNAS use btrfs, but they layer it on top of LVM and mdraid, and they do so for good reason. See Debian’s wiki for more, and note Red Hat’s decision to deprecate btrfs entirely in RHEL 7.4.)

The Clear Linux FAQ also points us to an elderly Github issue in which a user requests a ZFS bundle, and is shot down. Another user asks for help getting unsigned kernel modules to work, and gets a pointer to some documentation via a now-dead link. I found a copy of the deadlinked doc on web.archive.org (and later, a Clear Linux project member provided an updated link to the current version), but that didn’t get me where I needed to go either.

Installing the linux-lts-dev bundle was straightforward, as was creating a kernel configuration file which would allow unsigned modules to load. But switching back to the LTS kernel—necessary, since the native kernel was a bit too bleeding-edge for official support from OpenZFS—proved trickier. Installing the kernel was simple—swupd bundle-add kernel-lts2018—but getting Clear Linux to actually boot from it was a bit of a nightmare.

The clr-boot-manager tool looks pretty straightforward—but not all of the options worked.
Enlarge / The clr-boot-manager tool looks pretty straightforward—but not all of the options worked.

Jim Salter

The distribution doesn’t keep its boot management configuration in any of the places an experienced *nix user might look for them—/boot, /etc/default, anything to do with grub, etc. I never did find the actual configuration data location but eventually discovered that a Clear Linux user is expected to manipulate the boot environment with the tool clr-boot-manager. Unfortunately, clr-boot-manager set-kernel org.clearlinux.lts2018.4.19.103-113 followed by clr-boot-manager update—which should have selected that kernel for use at next boot—did absolutely nothing, and I spun my wheels poking at things, rebooting, running uname -a and still seeing a 5.5 kernel running for quite some time.

Finally, I gave up on clr-boot-manager set-kernel and instead tried clr-boot-manager set-timeout 10. That actually worked—after rebooting this time, I was presented with a kernel list and manually selected the 4.19 LTS kernel. Now, uname -a showed me that I was running on the 4.19 kernel, and I was ready to compile ZFS!

The problems were far from over, unfortunately. Downloading and extracting the OpenZFS source tarball, chdiring into it, and running ./configure, I was presented with an error: uuid/uuid.h missing, libuuid-devel package required. Unfortunately, there is no libuuid-devel bundle in swupd—nor is there libuuid, uuid, uuid-dev, uuid-devel, or anything else along those lines. Neither swupd search uuid nor swupd search-file uuid.h came up with any useful results, either—even though they should have.

Finally, I opened up a new issue in the ZFS on Linux tracker, hoping either that someone else had gotten ZFS running on Clear or that I could get enough information about the configure script to try to monkey-patch it myself. Brian Behlendorf—founding developer of the Linux port of OpenZFS, and all-around nice guy—didn’t have the answer either.

But Brian did give me the hint that finally solved the puzzle—although swupd search-file uuid.h didn’t find the package I needed, swupd search-file libuuid.so.1 did. So one swupd bundle-add os-core-dev later, ./configure and make install both completed successfully!

The remaining issue I faced is that the simple Linux Kernel Module (LKM) manipulation command insmod—which allows you to specify a path to the module to be inserted into the kernel—does not resolve dependencies, and so insmod /path/to/zfs.ko failed with the error unknown symbol. The much smarter tool modprobe will detect and resolve dependency issues—but it won’t let you specify the path to the kernel modules, and the installer had dumped them into places where modprobe didn’t know to look.

After a bit of flailing, I eventually just dumped a symlink to the each of ZFS’s package.ko files—which were in individual directories under /lib/modules/extra—directly into /lib/modules itself. With that, modprobe zfs worked, and I actually had ZFS running on Clear Linux. Huzzah!

Although ZFS was functional now, there were still papercuts to deal with. The zpool and zfs commands were in /usr/local/sbin, which isn’t part of the default PATH in Clear Linux. Also, the ZFS module wasn’t set to load automatically on boot. Those remaining problems are fortunately pretty trivial to solve. To fix the path issue, either update your PATH to include /usr/local/sbin, or symlink the utilities there into /usr/local/bin. To get ZFS to autoload on boot, create a directory /etc/modules-load.d, then create a file /etc/modules-load.d/zfs.conf, and populate it with a single line just saying zfs.

This shaggy dog story isn’t really about ZFS itself—it’s about the fact that issues that are relatively simple under more well-traveled distributions can be a giant pain in the rear under Clear Linux. These types of issues are all solvable, of course—but if you aren’t willing and excited to be a part of the effort to solve them yourself, for those who come after you, you should probably steer clear of Clear as a daily driver.

The good

  • Clear Linux is backed by Intel, one of the world’s largest and foremost computer science companies
  • Clear Linux has a concise, clear mandate: be secure, be fast, do things right
  • Most things work with little or no tweaking
  • If you’re bound and determined to have The Fastest Linux In The West, this is the distro for it—sorry, Arch and Gentoo users
  • “This is Linux! I know this!”

The bad

  • Although most things work without tweaking, most users will quickly want something that does
  • Intel’s swupd package management tool is clunky, warty, and doesn’t seem to index all packages properly
  • There are so few users, searching for help can seem like time travel to the past (Who were you, DenverCoder9What did you see?!)

The ugly

  • Clear Linux—for now, at least—is much better suited to a simple set of repetitive tasks where execution speed is absolutely mission-critical than it is to wide-ranging, general purpose daily use

Listing image by ollegN / Getty