hardinfo: a Linux system profiler that is being archived in favour of a successor

The first line of the readme is a decommission notice

HardInfo is a system profiler and benchmark for Linux systems, and the very first thing the readme does is warn you that the repository is being decommissioned and will remain as a personal archive of the HardInfo source code.

The development continues in a different repository, under the hardinfo2 organisation, and the readme says this branch will soon become a mirror of the main branch of that project.

That is an unusual arrangement and it is worth understanding what it means. The code in this repository is not going to be deleted, so the history, the modules and the build system remain readable, and anything you need to fork is still here. What is ending is maintenance of this branch, and the mirror plan is how the two histories stay connected rather than diverging.

For an adopter the practical answer is simple: use the successor. For a reader who wants to understand how a Linux system profiler is put together, this tree is still a good specimen, because it is a complete application in C with a real module system, a translation catalogue and a man page.

The last push was on 2026-09-06, the repository publishes no GitHub releases, and the licence is GPL-2.0 with the project page at hardinfo.org.

What the tool does, and what has already been switched off

HardInfo is able to obtain information from both hardware and basic software and organise it in a simple to use GUI, and the feature list names three things: report generation in either HTML or plain text, benchmark result synchronisation, and the ability to explore the information on remote computers.

Then the status section says which of those still work. On capabilities, HardInfo currently detects most software and hardware detected by the operating system, which is a sensible target for a profiler built on the system's own reporting rather than on vendor protocols. On features, the remote synchronisation was disabled due to server loss, and the remote server code still exists in a separate branch of this repository.

On development, the readme says the work is currently done by contributors and that a new dedicated maintainer is needed, which is the specific thing a prospective contributor would need to weigh.

So the state of the project is: the local profiler works, the reports work, the benchmarks work, and the network features are in the state that a lost server leaves them in. The synchronisation flag in the build configuration is set to 1 by default for exactly that reason, so the default build has the dead feature switched off rather than failing at runtime.

The dependency list dates the project precisely

The dependency section is short, and one entry tells you most of the story.

Required are GTK+ 2.10 or newer, GLib 2.10 or newer, and zlib, which is needed for the zlib benchmark. Optional, and only for synchronisation and the remote features, is Libsoup 2.24 or newer.

GTK+ 2.10 is the headline. That is the second generation of the toolkit, from before the switch to GTK 3, and a project that has not moved to it in more than a decade is telling you something about its maintenance model. It is also a practical fact for anyone building today, because the GTK 2 development packages are no longer shipped by most current distributions, and the successor project is the natural place to see what a maintained version looks like.

The optional Libsoup dependency is there for the network features, and the fact that it is optional rather than required is the design decision that keeps the local build working now that the server is gone. Libsoup 2.24 is likewise from the era when the remote features were written, which is consistent with a codebase that has been stable for a long time rather than one that has been keeping up with the network stack.

For a profiler, the dependency profile is otherwise exactly right. There is no database, no web framework and no runtime, which is what you want in a tool you run on a machine to find out why the machine is slow.

Building is cmake, and two of the switches matter

The build section is a short sequence, and it starts by telling you to create a build directory and build from there rather than in the source tree.

hardinfo $ mkdir build
hardinfo $ cd build
build $ cmake ..
build $ make

The prompt prefixes are in the original, which is a small indicator of how the instructions were written, as a person typed them.

Then come the variables that can be changed, and two of them change the character of the build. The build type can be Release or Debug, with Release as the default, and the readme warns that Debug prints messages to the console and is not recommended for general use, which is a sensible default for a tool whose output people paste into bug reports. The install prefix defaults to /usr/local, and the readme notes that distributions usually change it to /usr, which is the usual divergence between a local install and a distribution package.

The third variable is the interesting one. HARDINFO_NOSYNC disables network synchronisation, and it defaults to 1, disabled because the server was lost. It is set with the standard cmake -D parameter, and the readme gives both examples: a debug build with the build type, and a build with the synchronisation disabled explicitly.

The synchronisation is enabled automatically if Libsoup is detected, so on a machine with those development headers installed the build will try to use the network path, and the flag is the escape hatch for anyone who hits trouble building with it.

A few pieces of hardware still need setting up by hand

Most hardware is detected automatically, and the readme names the exceptions, which is the kind of detail that saves an afternoon.

Sensors are the first. If the machine is compatible with the lm-sensors module, you use the sensors detection program included with the package on Debian based distributions, and you have to make sure the detected kernel modules are loaded, which is the step people forget, because the program reports what it found but the loading is separate.

Disk temperature is the second. To obtain the hard disk drive temperature you need the hddtemp daemon running in daemon mode on its default port, so the temperature shows up at all.

Memory speed is the third, and it is the one that surprises people, because the information exists in the machine but the kernel module that exposes it is not loaded by default. The eeprom module has to be loaded, with the module loading command, and then the module screen refreshed so the profiler re-reads it.

All three follow the same pattern: the data is present in the hardware or in the kernel, the profiler is not privileged enough to reach it by default, and you have to grant access once. The readme says as much, that most hardware is detected automatically, and the exceptions are listed here, which is the honest way to document a profiler that runs as a normal user.

The code layout is a good map of how a desktop profiler is built

The repository listing describes the shape of the application better than the readme does, and it is a familiar shape for a Linux desktop program of this vintage.

The hardinfo/ directory holds the program itself, and includes/ holds its headers. The modules/ directory is the interesting one, because that is where the detection logic lives, one piece per kind of hardware or subsystem, which is why adding a device means adding a module rather than editing a central probe. The shell/ directory is the graphical interface, tools/ holds command line utilities, and data/ holds the data files the program ships.

Then the packaging and polish. There is a man page as a proper file, a desktop entry file with a template extension so the installation path can be substituted at build time, a translation directory, a documentation directory, a directory of pixmaps for the interface artwork, a directory for vendored dependencies, and a CMake configuration template that generates a header from the build settings.

The community files are present too, an authors file, a contributing guide and a todo list, and there is a formatting configuration for the C sources and a submodules file, so some dependencies are pulled in as git submodules rather than vendored in the tree.

Taken together, this is what a mature desktop application looks like from the outside: a module system, a themeable interface, translations, a man page, a desktop entry and a build system that can be repackaged by a distribution. The one thing it lacks is anyone to keep it current, which is the sentence at the top of the readme.

Editorial conclusion

Adopt the hardinfo2 project rather than this repository, because the readme states plainly that this one is being decommissioned and will become a mirror of the main branch of the successor, so anything you build against the code here will be built against a project that is ending. Do not plan on the remote features, because the readme says the remote synchronisation was disabled after the server was lost and that the network synchronisation is off by default. Before you install either version, read the requirements, because the current tree still asks for GTK+ 2.10 and GLib 2.10, and expect to load kernel modules by hand for temperature and memory speed data.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. lpereira/hardinfo on GitHub
4. Project website
5. README