Supported Platforms

Supported Platforms

In short

YABS runs on Linux on five CPU architectures: 64-bit and 32-bit x86, 64-bit and 32-bit ARM, and (experimentally) 64-bit RISC-V. Everything else — *BSD, macOS, other ISAs — prints Architecture not supported by YABS. and exits. It also runs inside VMs and containers, but there you're benchmarking the host's shared resources, and on Windows you need WSL2.

Architecture support matrix

uname -m → internal ARCH → which assets/features you get:

uname -m	ARCH	fio/iperf3 asset	fio file size	Geekbench 4	Geekbench 5/6/7
x86_64	x64	fio_x64, iperf3_x64	2 GiB	✔ (geekbench4)	✔
i?86 (i386/i686...)	x86	fio_x86, iperf3_x86	2 GiB	✔ (geekbench_x86_32)	✘ (GB5/6/7 fail; with default flags the failure is silent — use -4)
aarch64/arm* with getconf LONG_BIT=64	aarch64	fio_aarch64, iperf3_aarch64	512 MiB	✘ (no GB4 ARM build)	✔ (LinuxARMPreview tarballs)
arm* with LONG_BIT≠64	arm	fio_arm, iperf3_arm	512 MiB	✘	✔ (ARM Preview)
riscv64	riscv64	fio_riscv64, iperf3_riscv64	512 MiB	✘	✔ (LinuxRISCVPreview tarballs for 5.5.1/6.7.2/7.1.0)
anything else	—	—	—	—	exit 1: Architecture not supported by YABS.

RISC-V additionally prints RISC-V compatibility is considered *experimental* at startup (added Oct 2026, #97).

Checking your own platform

uname -m            # -> what the ARCH mapping sees
getconf LONG_BIT    # 64 or 32 (only consulted on arm*/aarch*)
bash yabs.sh -h     # shows "Detected Arch" plus tool/connectivity probes

The uname -m matching is substring-globbed (*x86_64*, *i?86*, *aarch*|*arm*, *riscv64*), so values like aarch64_be or armv7l still map correctly; ARM bitness comes from getconf LONG_BIT, not the kernel name.

Distros and userlands

Historically tested across CentOS/RHEL/AlmaLinux, Debian, Ubuntu, Fedora, Alpine and openSUSE (and their container images), with many more reported working by users. Requirements are minimal: bash, /proc, curl or wget. Known quirks:

• Alpine / BusyBox: works, and several code paths exist because of it — the disk-total calculation avoids df -t/--total (BusyBox df lacks them), bc is never used (#79), grep -P is never used (#59), and lscpu may be absent on ARM (#84), which triggers fallbacks.
• Minimal images (e.g. almalinux:9-minimal, opensuse/tumbleweed container): may lack tar (Geekbench is skipped with a clear message), awk (script can't run — real installs have it), or lscpu/systemd-detect-virt/ping (degraded info fields).
• Locale-less environments: missing the C locale only produces a warning — locale 'C' not detected. Test outputs may not be parsed correctly. — since output parsing assumes . decimals.
• What works everywhere: the fio/iperf3 static binaries are musl-built, so glibc version is a non-issue for them (Alpine included). The fragile parts are the tools — tar, lscpu, ping, systemd-detect-virt, awk — which is why so many detection/fallback paths exist.

Feature degradation cheat sheet

Missing/absent	Consequence
curl AND wget	effectively nothing works — no downloads, no geolocation, no connectivity fallback
curl but wget present (or vice versa)	nothing — code picks whichever exists
tar	Geekbench skipped with a message (unless local geekbenchN)
ping	no latency column (--), weaker connectivity probes
lscpu	degraded CPU detection on ARM/RISC-V; fine on x86
systemd-detect-virt	VM Type prints empty
fio/iperf3/geekbenchN local packages	none — repo binaries downloaded instead
IPv6	no IPv6 iperf table; everything else normal
IPv4	no Geekbench download, no Network Information, degraded probes

Virtual machines and containers

• KVM/Xen/VMware/Hyper-V VMs: fully supported — this is the primary audience. VM Type shows what systemd-detect-virt reports (KVM, XEN, VMWARE, MICROSOFT, NONE on bare metal).
• LXC / OpenVZ: runs, but CPU flags (VM-x/AMD-V), RAM/disk totals, and all benchmark numbers reflect the host and its current load. simfs (OpenVZ's filesystem) is included in the disk-size calculation. VM Type shows LXC or OPENVZ.
• Docker: same caveat — the fio test exercises the container filesystem's backing storage; iperf results reflect the container's network path. Fine for comparative testing, not a bare-metal measure. The project itself uses Docker extensively for portability testing (see Contributing).
• WSL2: supported (this is how Windows users run YABS). WSL1 does not work.

What changes in a container, concretely

YABS output	Inside a container
VM Type	LXC / OPENVZ / detection-dependent
VM-x/AMD-V	reflects host passthrough, often Disabled
fio results	the host's disk under the container's mount — plus cgroup I/O limits where configured
iperf results	the container's network namespace/NAT path
Geekbench	shared host CPU; cgroup cpu.max quotas can cap scores hard

RISC-V specifics (experimental)

Real RISC-V /proc/cpuinfo has no model name, cpu MHz, or x86-style flags — the script reads processor/uarch/isa instead:

• CPU model: lscpu → uarch field → /proc/device-tree/model → literal "RISC-V", with the base ISA string appended in parentheses.
• AES-NI: derived from zkn/zknd/zkne ISA extensions.
• VM-x/AMD-V line: the h (hypervisor) extension.
• fio file size: 512 MiB like ARM; Geekbench uses the RISCV Preview builds.

Development/test caveat (not a real-host issue): QEMU user-mode RISC-V does not implement io_setup, so fio's libaio engine fails with ENOSYS — a full-system VM or real hardware is needed to exercise the disk path. Two other emulation quirks to be aware of when testing: lscpu in user-mode leaks the host's CPU model via sysfs, and the emulated /proc/cpuinfo advertises extensions (like zkn* AES and v) that real silicon may not have.

Real hardware for validation is genuinely scarce — the only mainstream cloud RISC-V offering (Scaleway's EM-RV1) is frequently out of stock — which is part of why the support is labelled experimental.

Known limitations

• No BSD or macOS — requested as early as Jan 2020; the script is deeply /proc- and coreutils-dependent, and there are no fio/iperf3 builds for those systems.
• 32-bit x86: Geekbench limited to version 4; with default flags the GB6 attempt fails without a message (known code quirk), so pass -4 explicitly.
• CentOS 7 (and other glibc < 2.27 distros): Geekbench 6/7 won't run; script prints the known-issue message (#71). Use -4/-5. Note the fio/iperf3 binaries are musl static and unaffected — this limit is Geekbench's own glibc requirement.
• ≤ 1 GiB RAM: GB5/6/7 likely fail — add swap or use -4.
• IPv6-only hosts: Geekbench can't download (cdn.geekbench.com is IPv4-only) and the Network Information section is skipped (ip-api.com is IPv4-only). fio/iperf3 binaries come from GitHub (IPv6-capable), so those tests still run.
• NAT VPS / no public IP: everything works except that geolocation shows the shared egress IP; iperf results may be limited by the NAT gateway.
• Outbound firewall / proxy environments: everything is plain HTTP(S)+TCP — but the iperf port ranges (5200–5210, 9204–9240), github.com, cdn.geekbench.com, ip6.me, and ip-api.com all need egress; partial egress shows up as busy cells or missing sections rather than a hard error.

See also

• Getting Started — prerequisites and WSL2 notes
• System Information — the per-arch detection fallbacks
• Precompiled Binaries — per-arch asset names and toolchains
• Tests: CPU (Geekbench) — per-version platform availability