HardwareQuality is a shell script that benchmarks a whole machine

The whole tool is one script you pipe into bash

The problem HardwareQuality solves is that a server or VPS arrives with a spec sheet you cannot verify, and the usual way to find out means installing a pile of benchmark tools by hand on a machine you may not want to modify. This project is a script instead. The repository layout is minimal: a .github/ directory, a LICENSE, a README.md with a Chinese and an English version, a hardware.sh that is the whole program, and ref/ and res/ directories for reference material and resources. The supported platforms are listed broadly, covering Ubuntu, Debian, Linux Mint, Fedora, RHEL, CentOS, Arch, Manjaro, Alpine, AlmaLinux, Rocky, Anolis OS, Alibaba Cloud Linux, SUSE, openSUSE, Void and Windows via Docker, and the target hardware spans servers, VPS virtual machines, containers and bare metal on both ARM and AMD architectures. The interface is bilingual Chinese and English.

Inventory and benchmark are one run, not two

The scope is what distinguishes it from a single-purpose benchmark. The script collects comprehensive hardware information across CPU, GPU, memory, disk, motherboard, sound card and network card, and it runs automated sysbench, fio and Geekbench tests against the CPU, GPU, memory and disk, with visual comparison of the results. The per-component detail is where the work is. For the CPU it parses model, architecture, core and thread counts and frequency, and it monitors temperature during the stress test. For the GPU it distinguishes discrete from integrated, parses vendor and device information, analyses the driver environment, monitors temperature and scores it. For memory it reports total, used and available capacity and the usage rate, counts slots and sticks, and tests bandwidth and latency across multi-channel and server memory configurations.

Disk testing borrows CrystalDiskMark's workload shape

The disk handling is the most elaborate part. The script supports SATA, NVMe and RAID device identification, automatically matches mount points to the device under test, parses SMART and NVMe health data, and runs fio performance tests that it describes as fully simulating the workload conditions of CrystalDiskMark and ATTO with visual output. That is the right shape for a server check, because sequential throughput and random IO on a virtual disk are exactly the numbers a provider's marketing page omits. There is a separate disk mode and a verbose disk mode, and the script can be pointed at a specific path to test, which is what you want when the disk you care about is not the one the system booted from.

Six flags cover the modes you actually need

The command line is a single letter per mode, and the README documents each. The convenient interactive mode is the one-liner that opens the menu, and the parameter modes cover the rest: a standard check, a fast mode with the -F flag, a disk mode with -D, a verbose mode with -V, and a flag to point the disk test at a specific directory with -d. Two flags are about output and one is about behaviour. The -j flag produces JSON output, and the -o flag writes the report to a file as ANSI, JSON or plain text. The -n flag skips the system detection and the dependency installation, and the -y flag installs the dependencies automatically. The -l flag selects the language, taking cn or en, and the -f flag makes the report show the full IP address and path information. The fast mode is one flag away from the standard check:

bash <(curl -Ls https://Hardware.Check.Place) -F

bash <(curl -Ls https://Hardware.Check.Place) -F

Privacy mode exists because Geekbench uploads your results

This is the detail that should decide whether you run it on a machine you care about. The -p flag is a privacy mode that disables the online report generation, and the README explains why in one line: Geekbench 5 forcibly uploads test results, so privacy mode disables the Geekbench 5 test in order to guarantee zero uploads. The flag itself is one option:

bash <(curl -Ls https://Hardware.Check.Place) -p

The flag itself is one option:

bash <(curl -Ls https://Hardware.Check.Place) -p

The general mode is therefore not fully offline, and the flag is not a cosmetic switch. There is also an online report feature that the -p flag turns off, so the two are the same mechanism. The script also exposes a -f flag for showing the full IP address and path information in the report, which is useful for a support ticket and is another reason to prefer the privacy mode on a shared or a rented host.

Docker works but loses hardware detail on Windows

The Docker path exists for the cases where you cannot or should not run a script on the host, and the README is upfront about its limits. On Linux the container is run with the host root mounted read-only, and the whole invocation is:

docker run --rm -it --privileged --net=host --pid=host -v /:/host:ro xykt/check -H && docker rmi xykt/check > /dev/null 2>&1

and the whole invocation is:

docker run --rm -it --privileged --net=host --pid=host -v /:/host:ro xykt/check -H && docker rmi xykt/check > /dev/null 2>&1

with host networking and the host PID namespace, and the privileged flag set, and the image is removed afterwards in the same command line. The Windows variant is shorter because the namespace flags are not available, and the README notes in both places that the Windows architecture limitation means you cannot get complete hardware information. The project also notes that the Docker path for passing parameters is not recommended, inserting the arguments before the ampersand. The interactive mode has a Docker equivalent too, using a different image name.

AGPL-3.0, a script history and a sponsor list

Two things about the project sit outside the code. The first is the licence, AGPL-3.0, which for a shell script that is largely a wrapper around other people's benchmark tools is a strong copyleft, and the practical question it raises is what happens if you redistribute a modified copy as part of a service. The second is the update history, which the README keeps as dated entries rather than as tagged releases: a hardware weighted scoring feature added on 2026-02-05, an updated verbose mode showing all test details on 2026-01-28, and the initial script publication on 2026-01-16. There are no GitHub releases, so the commit history is the version record, and the last push to the repository was on 2026-07-15. The README also carries a sponsor table, a run counter and a daily runs history chart, plus acknowledgements to a contributor on a Chinese forum, and links to the sponsor's contact details.

Editorial conclusion

HardwareQuality suits someone who has just rented a VPS or received a bare metal box and needs to know what the hardware actually is and roughly how fast it is, without setting up a benchmarking harness. It does not suit a machine you do not own, and the pipe-to-bash pattern is worth thinking about before you run it. Before adopting, read hardware.sh in the repository rather than running the remote copy, decide whether to use the privacy flag given that Geekbench 5 uploads results by default, and note that the last push to the repository was on 2026-07-15 with no GitHub releases published.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. README
4. xykt/HardwareQuality on GitHub