Void Linux thread

[q66]

So I got this idea we could possibly start a thread per distro/OS and share things like a general overview, hardware support and current status and news as a part of it. That would help get things organized and provide some kind of entry point. I wasn't entirely sure which is the best section for this; but the operating system section appears to be more about porting, while I'd like to focus more on what it means for actual users, so User Zone seemed like the right place.

And of course, while at it, as a maintainer of the PowerPC support, shameless self-promotion is never a bad thing for an establishing project, so without further ado, here's a Void Linux thread. I suggest other distribution threads follow a similar layout.

Summary

- Website: https://voidlinux.org, https://voidlinux-ppc.org (PowerPC port)
- IRC: #voidlinux and #voidlinux-ppc on irc.freenode.net
- Package manager: xbps
- Packaging: binary (with ports-style source build support), >11000 packages, >7000 unique software projects
- Release: rolling
- C library: glibc or musl
- Userland: GNU
- Init system: runit
- FSF certified: no
- Linux-libre: no (ships firmware)
- Non-free software: separate repository

PowerPC support

Source support upstream; binary support provided via an unofficial staging fork (production ready)

- 64-bit little endian (glibc + musl) - POWER8+
- 64-bit big endian (glibc + musl) - 970/G5+ (AltiVec required)
- 32-bit (glibc + musl) - generic

What is Void Linux?

Void is a general purpose Linux distribution with the aim of being small, simple and minimalistic, while inheriting lots of its philosophy from the BSDs; it's also independent (not forked from anything). It's based on its own xbps package manager, is rolling release and binary based (while allowing simple custom source builds based on a similar system to a ports tree; this system also allows for cross-compilation of nearly every package to different architectures). You get a choice of two C standard library implementations (glibc and musl) and it notably uses runit instead of systemd for its init system (but is not an anti-systemd distro per se) as well as libressl instead of openssl. Officially, it's available for x86 (i686 and x86_64) and ARM (armv6l, armv7l, aarch64). Unofficially, it's available for PowerPC (ppc32, ppc64, ppc64le). Source build profiles are also available for MIPS (mips, mipsel).

PowerPC fork

Started in December 2018. Void now provides support for 6 flavors (ppc64le/ppc64/ppc glibc/musl) total, with ppc64le having the greatest support for now, but all of them growing (https://repo.voidlinux-ppc.org/stats.html). I'd consider it production ready at this point. Live images are shipped with support for everything from old Macs to most modern POWER9 machines (for both LE and BE). Installer is provided.

Modern ELFv2 ABI is used for both LE and BE (kernel and userland). 4kB page size is used for kernel (as opposed to 64kB used by most other distros), as it makes much more sense for any use case other than a single-purpose server with large amounts of RAM, which is nowhere near the primary target (it's desktop/workstation).

Most desktops and other important software are already supplied. There's at least one modern browser with JavaScript support on every target (Firefox Quantum on all 64-bit with 32-bit being WiP, webkit2gtk and qt5-webkit based ones (Epiphany, Midori, Surf...) on all, and Chromium-based qt5-webengine and browsers based on that (Falkon, qutebrowser...) on ppc64le and experimentally ppc64 - runs, but has color and likely other issues)

Build infrastructure is provided by a Talos 2 Lite, with an 18-core POWER9 CPU, 128GB RAM and a 4x1TB (2+2 mirror) SSD setup with ZFS. A VM (KVM) with half the resources of the machine handles BE and 32-bit builds (no cross-compiling for any of the packages). Both the host and guest systems run Void, of course. The final packages are hosted in Chicago, IL on a server provided by a Void and Talos community member Zach Dykstra.

There's also documentation in a handbook format and FAQ provided on the website.

Blackbird:




PowerBook G4:


Power Mac G5:

[Jubadub]

Agreed on selecting the "User Zone" section, it does seem more appropriate, according to their descriptions. And this is an excellent idea! I had considered something like this, but I had zero drive to actually get it done, let alone with this level of superb quality. Nice job! This certainly serves as a perfect entry point.

If I may make a suggestion, what about an extra line in the summary to state whether or not the distro/flavor contains binary blobs, and its FSF status? This will be an important point for some, especially now that the Talos line has been officially certified with FSF's RYF. Libre software enthusiasts are certainly a considerable end-user demographic for RaptorCS. Afterall, we are talking about the most powerful computer lines of all time among those which FULLY give control back to the user.

[q66]

I guess that's a good point. Though, for Talos specifically, it won't try to load any blobs by default in the first place, as they're not required (unless you add something that needs them like a GPU)

[Jubadub]

Interesting, I didn't know that. But would blobs be required even for the AMD Radeon Pro WX7100 and AMD Vega 64? On the official purchase page, unlike the other 4 GPUs listed there (all NVidia), those 2 AMD ones aren't marked as "proprietary".

[q66]

Obviously, as all GPUs require firmware, and specifically anything using amdgpu needs *loadable* firmware (i.e. it's not onboard anymore) in form of signed firmware blobs. The driver may not be proprietary, but the firmware always is.

[SiteAdmin]

Obviously, as all GPUs require firmware, and specifically anything using amdgpu needs *loadable* firmware (i.e. it's not onboard anymore) in form of signed firmware blobs. The driver may not be proprietary, but the firmware always is.

We mark anything requiring kernel/userspace binaries as Proprietary.  Card side firmware we don't explicitly call out, since it's IOMMU isolated.  If we see any libre GPU options start showing up, we'll start calling out cards that require vendor firmware somehow, but for now there's no real point considering the state of the GPU market.

[Jubadub]

Obviously, as all GPUs require firmware, and specifically anything using amdgpu needs *loadable* firmware (i.e. it's not onboard anymore) in form of signed firmware blobs. The driver may not be proprietary, but the firmware always is.

Actually, what is obvious is that what you said is not obvious (and is technically even wrong in the end when you said "the firmware always is [proprietary]"), for 2 simple, factual reasons:

- Just like drivers, firmware source code exists for various devices, and GPU firmware is no different (whether they are already out there or not is another matter). In fact, even the Talos computers contain firmware you can recompile at will;

- The purchase page marks the NVidia GPUs as "proprietary", which, for people not familiar with the availability or lack thereof of libre GPU firmware, can easily and reasonably be interpreted it refers to the firmware. (The driver situation being proprietary or not is OS-dependant, not Talos-dependant, and the purchase page is for Talos alone).

There's also the fact it has been previously discussed on Raptor's Twitter (not sure if by them or a 3rd party) that ALL firmware has been "liberated" (as in, made libre) for the RaptorCS computers (or something along those lines), except one: HDD / SSD firmware. But whether that is true or not, I don't know. But people checking out Raptor's two Twitter accounts can easily come across the statement.

We mark anything requiring kernel/userspace binaries as Proprietary.  Card side firmware we don't explicitly call out, since it's IOMMU isolated.  If we see any libre GPU options start showing up, we'll start calling out cards that require vendor firmware somehow, but for now there's no real point considering the state of the GPU market.

Now this clears it up, many thanks.

[q66]

Actually, what is obvious is that what you said is not obvious (and is technically even wrong in the end when you said "the firmware always is [proprietary]"), for 2 simple, factual reasons:

- Just like drivers, firmware source code exists for various devices, and GPU firmware is no different (whether they are already out there or not is another matter). In fact, even the Talos computers contain firmware you can recompile at will;

What are you talking about? There is no libre GPU firmware. It literally doesn't exist. Raptor hardware doesn't contain a GPU, so it doesn't need to concern itself with that out of box, but any GPU you add, it will always have proprietary firmware.

[MPC7500]

That's why Raptor is unable to build a notebook at the moment.

...and an open-firmware DRM-free GPU.  That's the primary hold-up for us right now, not the CPU.

Twitter

[nglevin]

q66, thanks for all the work to get Void working on POWER. I really enjoyed your talk on the challenges of porting the distro, along with exactly what pieces work and why.

I'd like to give it a try with WindowMaker and dmenu, after being somewhat convinced of dmenu's seaworthiness with this Void Linux setup guide. With that, it should resemble an old FreeBSD desktop I used to have.

Also, props for having bpftrace on all platforms. That will easily make me miss dtrace less.


Since it's mentioned as a distinguishing factor in this port, are there benchmarks showing the impact of ELFv2 on ppc64be or ppc32?

[q66]

Since it's mentioned as a distinguishing factor in this port, are there benchmarks showing the impact of ELFv2 on ppc64be or ppc32?

ELFv1/ELFv2 are 64-bit ABIs, 32-bit uses the SVR4 ABI, so it's not relevant there. ELFv2 on 64-bit supposedly has faster library calls and stuff, but I haven't benchmarked it. It's nicer/simpler/less annoying from programming perspective though, and there is just no reason to go with a 30 years old legacy ABI when there's a choice not to, if people have some legacy binaries or something, they can spin a debian chroot or whatever legacy environment for it, there's nothing preventing that.

I don't even see how I'd go about benchmarking that as it would mean having to have a reasonably large ELFv1 testing environment in the first place (i.e. compiled with otherwise the same flags etc., so another distro won't do) which I never had (ELFv1 was never even attempted).

[nglevin]

That's fair. Benchmarks can be deceiving as they are further isolated from their original context.

POWER is one of those ABIs that I hadn't had much experience in. Based on your reference to SVR4, found this 2014 slide deck introducing ELFv2 in the context of what came before and the default 64-bit Linux POWER ABIs (ELFv1 for be, ELFv2 for el) in the GCC compiler options.

This clears things up, thanks.

[Raion]

Neat stuff you're doing q66 for Void Power.

Aikatsu's a cute anime, I saw that in your shot. Checking the docs you have, it's not clear - does this distro have qemu-kvm support?

[q66]

Neat stuff you're doing q66 for Void Power.

Aikatsu's a cute anime, I saw that in your shot. Checking the docs you have, it's not clear - does this distro have qemu-kvm support?

Sure, there's just one caveat when using it as a host system: when using -machine newer than pseries-2.x, qemu will complain about not having 64kB pages, as Void uses 4kB pages for its kernels; the workaround is either to further limit HPT to 4k (like -machine <whatever you want to use>,cap-hpt-max-page-size=4096) - this will work but also limit guests to 4k when using HPT (on POWER9 when using Radix MMU, which is default, 64k guests will work fine unless booted in HPT mode), alternatively use something like -machine pseries-2.11 which will boot 64kB guests regardless of other settings.

So basically mostly affects POWER8 users, or those who explicitly disable Radix (for KVM-PR or whatnot) and even most of those can just use some pseries-2.x machine type and it'll work alright. The only ones out of luck are those who have older hw, require 64kB guests, and also require some feature available only in newer machine types, but vast majority of users don't need to care.

[q66]

Currently attempting a 64-bit long double transition to get rid of the messy IBM double-double format used on most distros and unify the representation across targets. Musl has been using it all along, now trying glibc.

I don't want to go with the 128-bit IEEE754 format as that requires VSX and would mean a different one on ppc64le and the rest (and also, when not targeting POWER9, it means basically reverting to soft-float).