I Love Arch, but GNU Guix Is My New Distro

Then they spin narratives about how this is important for not just freedom, but also security/privacy/etc, while their policies have absolutely nothing to do with improving users' security or privacy, as is made evident by the linux-libre issue, among many others. Actual assessment of the privacy/security impact of proprietary firmware on users is a much more nuanced topic, but the FSF are not interested in nuance, they just say "blobs (that you can see) bad".

Oh don't get me wrong, I'm not saying guix is better (I have absolutely no idea), just that the experience with nix is extremely rough so nix being a bit more popular is not necessarily that much of an edge (or one at all).

> I like Guix as package manager, but their docs can definitely be improved with loads of examples and tutorials.

In fairness I'll say that especially if you're a long term user it is very easy to be blind to the early user experience. Sadly most projects don't push new users towards really reporting their experience or even contributing to the docs, but if you have the time and inclination to do so I'm quite convinced your experience would be extremely valuable to those who'll come after you, even if the project doesn't necessarily value them that much (but even then it can be useful as evidence of issues with the early experience / uptake, and possibly efforts to rectify them later on).

It's also useful on a personal level, because memory is a fickle thing and a year from now you may not even remember your struggles.

it states:

> However, there is one exception for secondary embedded processors. The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product. This can include, for instance, microcode inside a processor, firmware built into an I/O device, or the gate pattern of an FPGA. The software in such secondary processors does not count as product software.

>We want users to be able to upgrade and control the software at as many levels as possible. If and when free software becomes available for use on a certain secondary processor, we will expect certified products to adopt it within a reasonable period of time. This can be done in the next model of the product, if there is a new model within a reasonable period of time. If this is not done, we will eventually withdraw the certification.

END QUOTE

According to you, what is deceptive about this?

Just look at the Librem 5. That CPU needs a blob to even boot (to train the RAM). Normally that would just be embedded into the bootloader. But that would make it evident in the build process for their boot stack that there is a blob involved, and they can't certify that as "Respects your Freedom". So instead they worked with the manufacturer, and came up with this contrived interpretation of the "secondary processor" rule where, as long as the firmware in the "secondary processor" is at least two steps removed from the main CPU and never handled "directly" by it, it's okay. Then they had the manufacturer put the blob in a Flash ROM (Flash, so updatable, remember? just not that easily), and then they had them write a little loader code that runs on another secondary CPU. So the main CPU (running free software) boots a secondary CPU (running free software) that loads a blob from Flash and then boots a third CPU, which now runs proprietary software. According to the FSF, all this pointless obfuscation and extra levels of indirection makes the device magically compliant with their criteria. And so it got certified.

It is completely evident that absolutely none of this helps end-users' freedom in any way, shape, or form vs. just having the blob in the normal bootloader where it can be more easily inspected and analyzed (and also lets users ensure that it hasn't been tampered with). It's just adding obfuscation so users won't find the blob, and therefore will feel better believing they aren't running any blobs.

By this interpretation of the rule, I could ship an x86 PC with an Nvidia GPU that runs its proprietary driver on one of the CPU cores (isolated from the main OS), loaded by the UEFI firmware through ME or something, which communicates with the rest of the cores via VirtualGL or some other RPC, and that would make this PC eligible for RYF certification. Tell me that's not a farce.