By relying on the series Linux 6.19This publication inherits the technical innovations of the original kernel, as in What's new in GNU Linux-libre 6.18However, it introduces specific changes to remove any trace of opaque binaries. The result is a version tailored to those who prioritize code transparency, even if it means foregoing certain features or hardware support that depend on proprietary microcode or firmware.
Based on Linux 6.19, but without proprietary components
The GNU Linux-libre 6.19 kernel is built directly on top of the stable version of the main kernel, but it systematically removes firmware loading support and other elements that rely on proprietary blobs. This particularly affects drivers, which, despite offering open-source code, require closed-source microcode to function correctly—something the project considers incompatible with its freedom standards.
Among the areas reviewed in this edition, the elimination or modification of firmware loading routines in SDCA sound components and various other components stands out. graphics and network driversThis prevents the system from automatically attempting to download or upload unauditable binary files, thus reinforcing the system's consistency with the guidelines of the Free Software Foundation Latin America (FSFLA) and other similar groups in Europe.
Adjustments to Intel, Qualcomm, NVIDIA drivers and sound codecs
A significant part of the work on GNU Linux-libre 6.19 has focused on updating the cleanup of several drivers affected by new blob names or internal changes to the base kernel. Specifically, the Intel Xe GPU drivers have been revised, the Intel iwlwifi Wi-Fi controller, the NVIDIA Nova-Core graphics solution, Qualcomm Iris and Venus components, as well as the Q6V5 platform.
In addition to the graphics and network drivers, the project team has fine-tuned the debugging of multiple sound codecs such as those of TI tas2783 and other audio chips, along with network drivers such as TI PRUeth, Marvell mwifiex, and FourSemi fs210x. In all these cases, the filters that identify and disable references to non-free firmware have been adapted, taking into account the new identifiers and file paths introduced in the 6.19 branch of the original kernel; a similar task to that performed in GNU Linux-libre 6.15 that purifies drivers.
The project has also stopped cleaning up certain components that have already disappeared from the official Linux tree, such as the old driver STM C8SECTPFE DVBIt has been removed upstream. Since it no longer exists in the codebase, it is not necessary to maintain specific debugging rules for it, which slightly simplifies maintenance.
Reorganizing the cleaning process at DeviceTree
Another important area of ​​work in GNU/Linux-libre 6.19 is the management of DeviceTree (DTS) files, which describe the hardware configuration in numerous embedded systems and ARM boards. In this version, the following have been implemented: regrouped and rearranged commands intended to clean up references to blobs within these files, with the intention of bringing some order to a list that keeps growing.
With each kernel development cycle, new ones appear dts files that incorporate blob names or proprietary firmware paths. Version 6.19-gnu expands the coverage of these cleanup rules to include new devices, while also attempting to better structure the collection of scripts and patterns used, which facilitates future revisions and reduces the likelihood of inconsistencies.
Strict policy regarding non-free firmware and modules
GNU/Linux-libre maintains a very firm stance regarding proprietary software within the kernel: functions that allow load closed microcodeThe use of blob-dependent modules is restricted, and references to non-auditable components are removed. This affects both controllers based on external firmware and certain modules not released under open licenses. These decisions align with what has already been proposed in previous editions of the free kernel.
In practice, this means that the 6.19-gnu kernel may lack functionality for certain modern devices, especially in the area of Wi-Fi cards, recent GPUs, and specialized hardware which relies on firmware loaded at boot time. In return, users and organizations gain the assurance that the running kernel will not incorporate code whose behavior cannot be reviewed or modified.
Availability, downloads and distribution
The new GNU Linux-libre 6.19 can be downloaded in the following format: compressed tarballs from the project website and from FSFLA.orgwhich serves as one of the benchmarks for this development. These sources allow the kernel to be compiled manually on virtually any distribution, an approach that remains common among system administrators and advanced users in Europe who want finer control over their environment.
For those who prefer to avoid manual compilation, ready-to-use binary packages are available in the following format: DEB and RPMIn the Debian and Debian-based ecosystem, packages can be obtained through the Freesh project, while in the Red Hat-type distributions, a repository maintained by the RPM Freedom initiative is offered. This approach is particularly practical for those who manage multiple computers or servers and want to deploy the free kernel in a consistent manner.
In most cases, the GNU Linux-libre kernel can be installed along with the standard kernel which is included in each distribution, allowing you to choose which version to boot from the boot manager. This coexistence makes it easier to test the debugged kernel without giving up hardware support from the official kernel, something many people in European work environments use as an intermediate step before adopting a completely free environment.
All this effort surrounding GNU/Linux-libre 6.19 reinforces the commitment to a kernel aligned with free software principles, at the cost of accepting certain compatibility limitations with hardware dependent on proprietary firmware. With its adjustments to key drivers, the reorganization of the cleanup in DeviceTree, and the range of packages available for different distributions, this version positions itself as a solid option for those who prefer to prioritize transparency and code control over absolute compatibility with every device on the market.
