If the distribution does not have it by default, please include the instructions to use it on the system.
Note: I can’t compile the libre kernel from the source.
You must log in or register to comment.
Trisquel provides a good experience out of the box imo, as long as your hardware is supported and if you don’t mind the dated looking interface. I used it for a while on my corebooted laptop.
I didn’t used much any other “100% libre” distros. As much as I wanted to use it, I never managed to have Guix to run on that machine.
[edit:] to answer OP’s question, I would use a distro that ships with it.
I would argue they’re not safe to use because they block security updates like CPU microcode in the name of absolute freedom.
Not sure why you mentioned this. At least on Arc, or any distro based on it like Artix, the ucode per CPU is offered as a separate package:
% pacman -Ss ucode system/amd-ucode 20241111.b5885ec5-1 Microcode update image for AMD CPUs world/intel-ucode 20241112-1 [installed] Microcode update files for Intel CPUs world/iucode-tool 2.3.1-5 Tool to manipulate Intel galaxy/amd-ucode-xz 20230625.ee91452d-4 Microcode update image for AMD CPUs extra/intel-ucode 20241112-1 [installed] Microcode update files for Intel CPUs extra/iucode-tool 2.3.1-5 Tool to manipulate IntelIf your distro doesn’t help with ucode packages, you can ultimately download it from intel/amd/whatever. And the same applies for the hardware firmware in general.
So it’s true that some hardware won’t properly work out of the box by using libre-linux, but nothing prevents you from getting the required firmware from other packages or sources. Granted that doesn’t make things easier. And granted that might defeat the purpose of using linux-libre, but you might at least only add only strictly required binary blobs for your current hardware.
real linux-libre distros do not offer microcode packages because they are non-free
That’s definitely a factor to consider, but running binary blobs that you don’t have the source for is also a risk. It comes down to what threat vectors you think are important and what risks you’re willing to take.
Short answer is Trisquel if you like Ubuntu/Debian, Parabola if you like Arch, and Guix if you like frustration.
The libre kernel is a bit of a pain regarding wifi and bluetooth, and depending on your graphics card the drivers aren’t going to run quite as well. You might need to get new a wireless card/usb, since there’s only a few modern chips that work with it.
There’s a list of distros on gnu.org that use the libre kernel by default, if you want to look at more options. PureOS is based on Debian focused on privacy and security. Hyperbola is based on Arch with 32 bit and BSD options.
Personally I use Guix, which is an amazing abomination with awesome features that most people don’t care about. I wouldn’t recommend it for most people unless you are coming from NixOS, know a lisp dialect, and/or are willing to put in a lot of effort.
i’m surprised that alpine isn’t on that list since they went through all that effort to be “pure” linux.
It’s probably because they use busybox instead of gnu utilities so it’s not technically GNU/Linux, but yeah.
Even more than Busybox, Alpine uses MUSL. So, not very GNU at all.
Arch and Arch based distros like Artix have linux-libre available from AUR if one doesn’t have an issue with building from source. Also see my other comment about Guix, there’s a non official repo with ucode and hardware firmware…
linux-libre is harder because if you want cpu ucode plus hardware firmware support in general so that you can make your bad citizen hardware work, you’ll need to add it out of the linux package.
Someone mentioned Guix as a gnu + linux distribution was hard, and in general that’s true, but not because of linux-libre since there’s a non official Guix repository providing non libre/free cpu ucode plus hardware firmware, see:
https://gitlab.com/nonguix/nonguix
The complex part of Guix comes from it being a inmutable distribution based on the ideas from NixOS, though it’s not a fork from Nix since it’s even based on Guile rather than the Nix language, but their packages and configurations are quite different than any other distribution, the same as its inmutable system and I believe on both reproducibility is a thing…
But bottom line, for Guix you can even get packages to make linux-libre work with your hardware provided you find the corresponding firmware in the non official repo, and in general (not just Guix) as long as you find the firmware somewhere else (not in linux-libre) you would be OK, and depending on your distro that might be a really hard task.
I use Artix, and though I haven’t explored it yet, I’ve been wondering how hard it’d be to install linux-libre, and get the strictly required firmware from the AUR, perhaps it’s possible. The package is actually offered from AUR:
% aur search linux-libre aur/linux-libre 6.11.9-1 (+37 0.35%) The Linux Libre kernel and modules aur/linux-libre-docs 6.11.9-1 (+37 0.35%) Documentation for the Linux Libre kernel aur/linux-libre-firmware 1.4-1 (+3 0.00%) (Orphaned) Firmware files for Linux-libre aur/linux-libre-headers 6.11.9-1 (+37 0.35%) Headers and scripts for building modules for the Linux Libre kernel aur/linux-librem5 6.6.57-1 (+0 0.00%) The Linux kernel for Purism Librem 5 aur/linux-librem5-docs 6.6.57-1 (+0 0.00%) The Linux kernel for Purism Librem 5 (documentation)The complex part of Guix comes from it being a inmutable distribution based on the ideas from NixOS
That’s not the most significant factor in what makes it hard/different. There are immutable distros that come with less complexity and are arguably more immutable than NixOS or guix.
What actually sets it apart and can make these harder to use is:
- They’re declarative rather than imperative. You describe the desired end-result rather than providing (or manually executing) the steps to construct it.
- There is not a single global dependency dependency state upon parts of which any given package depends. Dependencies are explicit, direct and encapsulated on a level that’s as fine as you’d like instead (down to the per-file level).
Follow this guide:
https://www.fsfla.org/ikiwiki/selibre/linux-libre/freesh.en.html
