nbfc-linux is a C rewrite of NoteBook FanControl with a fan control database

A C port that keeps the original interfaces

The project is a C port of Stefan Hirschmann's NoteBook FanControl, and the README is careful about what that means. It provides the same utilities with the same interfaces as the original NBFC, although the implementation differs. That distinction matters for anyone arriving from the Windows version, because the command names, the configuration concept and the client service split carry over, so the documentation you already know mostly applies, while the plumbing underneath is different C code. The primary language of the repository is C, and the three programs are the service, the client and the probing tool, all written in C, with manual pages in `doc/` for each of them. It is a port in the sense of a reimplementation with a compatible surface, not a translation.

What the comparison table actually reveals

The README opens with a table comparing NBFC Mono and NBFC Linux, and it is the most informative part of the documentation. Portability goes from crossplatform to Linux only, and the runtime from Mono to native. Memory consumption drops from about 50MB in the Mono version to about 230KB, which is the headline number. The model configuration files change format, from 210 XML files to 312 JSON files, and the Linux side adds a model compatibility database that the original does not have. Fan control rights stay with any user, but service control rights move to root only. ACPI method support is added, through the `acpi_call` kernel module. The runtime design becomes fail-safe, where the original is not OOM-safe, and the IPC concept changes from TCP/IP to Unix sockets with a binary protocol becoming JSON, while the graphical interface is Windows only in one case and Linux only in the other.

Packages for the distributions that matter

Installation is mostly a matter of downloading a release artefact and handing it to the package manager. The table lists version 0.5.4 builds for Arch Linux as a zstd package installed with `sudo pacman -U`, for Debian Trixie and Bookworm, Ubuntu Resolute, Noble and Jammy, Linux Mint 22 and 21 as deb files installed with `sudo apt install`, and for Fedora 44 and 43 plus openSUSE Tumbleweed as rpm files installed with `sudo dnf install` or `sudo zypper install`. Beyond that there are several alternative routes. Arch users can install from the AUR with `yay -S nbfc-linux` or from a PKGBUILD for the git version, and NixOS has both a declarative and an imperative installation document, the latter using `nix profile install` or `nix-env -if .`. Fedora users can build an rpm from a source archive with `./pkgbuilds/rpm/buildNBFC-LINUX`, which requires podman, and the general source route is the autotools sequence starting with `./autogen.sh` and `./configure`.

The service, the client and the probing tool

Three programs cover the whole workflow, and the Makefile names them. `src/nbfc_service` is the daemon that talks to the embedded controller, `src/nbfc` is the command line client you interact with, and `src/ec_probe` is the probing tool, which is what you use to find out what a laptop's embedded controller will accept. The separation matters for the security model, because the service does the privileged work and the client does not need to be root. The service is installed as a systemd unit, with an OpenRC and a SysV init script alongside it, and the Makefile chooses between them with an `INIT_SYSTEM` setting for systemd, systemv or openrc. The IPC between them is JSON over Unix sockets, and the format is documented separately in `PROTOCOL.md`, with the client and service man pages in `doc/nbfc.1.md` and `doc/nbfc_service.1.md`.

The configuration set and the model database

The value of the port is mostly in its data. The repository ships the configurations as JSON under `share/nbfc/configs`, with 312 files against the 210 XML files of the original, and it adds a model compatibility database at `share/nbfc/model_support.json`, which the original does not have. To find out whether your machine is covered, the README points to a configuration search on the project site, and if you want to add a model yourself there is a configuration how-to document. The reasoning behind that data is explained in the README, where the author says he regularly purchases laptops to create configuration files, analyse their ACPI firmware and gain a deeper understanding of how these systems work, and that the knowledge gained is documented and preserved in a tutorial so others can work with similar hardware.

What the build pulls in

The Makefile shows the dependency set, and it is worth reading because it explains the design. The client links against libm, libcurl, libcrypto, the Lua libraries and the libxml-2.0 libraries, and also uses `dl`, so the client can load plug-in code at run time. The service links against libm, Lua and `dl`, and the probing tool against libm, Lua and `dl`. Lua is resolved through `pkg-config` with a preference for `lua5.4` and a fallback to `lua`, and libxml-2.0 is used for the XML side. The release build strips the binary with `-s`, enables link time optimisation, disables unwind tables and frame pointer omission, and the debug build switches to `-Og -g`. The `acpi_call` kernel module is what provides the ACPI method support that the original lacks.

Licence, release pace and where the project stands

The licence is GPL-3.0, which is the same licence as the original project it ports, so the derivative work question does not arise. The release history is regular. Version 0.5.2 was published on 2026-05-13, 0.5.3 on 2026-08-08, and 0.5.4 on 2026-10-10, and the last push to the repository was on 2026-10-18, so the port is being worked on rather than merely maintained. The repository layout shows the three programs under `src/`, the shared data under `share/`, the manual pages under `doc/`, the shell completions under `completion/` for bash, fish and zsh, the packaging recipes under `pkgbuilds/`, and the configuration sources under `xml/`, with the generated sources under `etc/` and `endpoints/`. The README also notes that the author accepts donations for the work, which is how the configuration database keeps growing.

Editorial conclusion

Adopt nbfc-linux when your laptop's fan control is locked to a fixed curve and you want the same set of profiles the Windows original offers, since the port provides a service, a client and a configuration set for hundreds of models. Do not adopt it on a desktop or a server, since the tool is about laptop EC and ACPI fan control, and check first that your model appears in the configuration search, because the database only covers the laptops someone has already analysed. Verify first that your distribution has a package, and note that service control requires root while fan control does not.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. nbfc-linux/nbfc-linux on GitHub
4. README
5. Releases