Design Principles

Design Principles

In short

YABS is opinionated in a few specific ways, and most of those opinions were formed in public between October 2019 and February 2020 and have not changed since. If you understand these principles, most of the script's behaviour — and most of the feature requests that get declined — make sense.

The principles

1. One line, no prerequisites, no root

The whole point is curl -sL yabs.sh | bash on a freshly provisioned box. Nothing to install, nothing to compile, no sudo. Mason's reasoning from October 2019:

"Much of bench.sh/nench.sh's success is that you can simply run the one-liner and not have to worry about anything being installed prior. Once you start adding in pre-reqs, more than half of the potential users of the script have already been turned off."

Consequences:

• Static fio and iperf3 binaries are downloaded at runtime (see Precompiled Binaries).
• Everything runs from the current directory, not /tmp (which is often mounted noexec), and the script checks it can write there first.
• Only tools that exist on essentially every Linux system are assumed: bash, awk, sed, grep, df, stat, free, uptime, shuf, timeout, tar, and curl or wget. Anything else (lscpu, ping, systemd-detect-virt) is optional and degraded gracefully.
• Dependencies that crept in were later removed again (bc in 2023, grep -P in 2023).

2. Use the real tools, not home-grown approximations

YABS does not implement benchmarks; it orchestrates the tools the community already trusted — fio, iperf3, Geekbench — and parses their output. The README calls it "automat[ing] the execution of the best benchmarking tools in the industry." This is also why the output looks the way it does: the numbers are the tools' numbers, lightly formatted.

3. Measure what matters, even if people expect something else

The clearest example is dropping sequential disk tests in January 2020:

"People might be used to seeing them, but they're essentially useless as they aren't testing real-world conditions, so I guess it's best not to continue the facade that anything of value can be interpreted from these results."

Likewise, iperf3 with 8 parallel streams was chosen over a speedtest-style single connection because a server's job is to serve many connections at once.

4. One size must fit all, so keep the test honest and simple

A benchmark that millions of strangers run on hardware you have never seen has to be a compromise. The disk test is four mixed 50/50 random tests at four block sizes, 30 seconds each, on a 2 GB file, because that was the shape the community could agree was defensible rather than perfect. Mason: "creating a 'one-size-fits-all' test is HARD." When in doubt, YABS prefers a test everyone understands over a more sophisticated one few can interpret.

5. Report, don't judge

YABS prints numbers; it never says "good" or "bad". From January 2020:

"The cutoffs between them can be arbitrary and essentially our opinion of what 'good' means. In addition, what's considered good today might be considered poor 2 months from now as hardware and expectations change."

Interpretation is left to the reader (and to pages like Interpreting Results and to the comparison databases). This also keeps the script neutral between providers.

6. A benchmark is a snapshot

Nothing in the output claims to be a long-term measurement; the date and uptime are printed at the top precisely so a result can be placed in time. See Benchmarks Are Snapshots.

7. Be transparent about trust

The script is a single readable bash file; the binaries' build scripts and workflows are public; checksums and VirusTotal scans are published; locally installed fio/iperf3 are preferred over downloaded ones. The bin/README has said since 2020 that "this is just a script on the internet" and that you have to decide whether to trust it. No telemetry is collected by the script itself (the only data that leaves your machine goes to the test endpoints, to Geekbench when it uploads your result, and to any URL you explicitly pass with -s).

8. Degrade gracefully

If something cannot run, YABS says so and continues: binary download failed → dd fallback; no IPv6 → skip the IPv6 table; iperf server unreachable → busy; Geekbench failed → an explanatory message tuned to the likely cause (CentOS 7, IPv4-only CDN, low memory, missing tar). A partial report is more useful than an aborted run.

9. Uploading is opt-in

Nothing is sent to a results database unless you pass -s <url>. This was Mason's explicit condition when the idea was first raised in 2020 (issue #9): "I will, however, like the uploading of the results to the comparison website to be opt-in rather than opt-out."

10. The JSON is a public contract

Several third-party sites parse YABS JSON. Keys are never renamed or repurposed and value formats are not changed; new information is added as new keys. Even known mislabels (disk_units: "KB" and speed_units: "KBps" for values that are actually KiB-based) are preserved for compatibility and documented instead.

11. Don't add noise for the majority

Features that help a few power users but clutter the report for the typical VPS user are declined or kept behind flags. Examples: disk model names (#106, closed), a RAM-speed test (requested 2019 and 2026, declined: "I can't say I've ever seen anyone caring about ... RAM speed"), hashing benchmarks. Extra system-information lines were accepted only where they help interpret the other results (uptime, distro, kernel, VM type, network info).

12. The iperf server list is a shared resource

Every YABS run moves tens of gigabytes through donated public servers. The list grows reluctantly; changes are preferred as one-for-one swaps that improve geographic and provider diversity, link capacity and port-range depth. Users who need a specific location are pointed to -p.

13. Prefer portability over cleverness

Parsing is awk-based and locale-pinned (LC_ALL=C). Code paths exist for GNU, BusyBox and uutils coreutils; for /proc/cpuinfo layouts on x86, ARM and RISC-V; for curl or wget. When a portability bug is found, the fix is tested in containers of several distributions before it lands.

How these play out in practice

Question people ask	Principle	Where it is explained
Why does it download binaries instead of using apt?	1, 7	Precompiled Binaries
Why is there no sequential read/write test?	3, 4	Tests: Disk (fio), History
Why are read and write almost identical?	4	Interpreting Results
Why doesn't it tell me if my VPS is good?	5, 6	Interpreting Results
Why does it use so much bandwidth?	2, 12	Tests: Network (iperf3)
Why won't you add my favourite metric?	11	Contributing
Why keep the odd JSON unit labels?	10	JSON Output and Integrations

See also

• History
• Benchmarks Are Snapshots
• Comparison with Other Bench Scripts
• Contributing