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.

  • Sunoc@sh.itjust.works
    8·
    1 month ago

    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.

  • underscores@lemmy.dbzer0.comEnglish
    4·
    22 days ago

    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.

    • eldavi@lemmy.mlEnglish
      2·
      30 days ago

      i’m surprised that alpine isn’t on that list since they went through all that effort to be “pure” linux.

    • kixik@lemmy.ml
      2·
      30 days ago

      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…

  • refalo@programming.dev
    51·
    30 days ago

    I would argue they’re not safe to use because they block security updates like CPU microcode in the name of absolute freedom.

    • kixik@lemmy.ml
      3·
      30 days ago

      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 Intel

      If 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.

    • underscores@lemmy.dbzer0.comEnglish
      2·
      22 days ago

      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.

  • kixik@lemmy.ml
    3·
    30 days ago

    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)
    • Atemu@lemmy.ml
      1·
      28 days ago

      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:

      1. They’re declarative rather than imperative. You describe the desired end-result rather than providing (or manually executing) the steps to construct it.
      2. 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).