not knowing about https://ryf.fsf.org/ previously, i managed to find and understand their certification process within a matter of ten minutes. if i was a user of these products i don't think i would feel decieved
Is the poster you’re replying to saying anything about the ease of parsing their policy? He doesn’t seem to be calling it confusing. Rather, he seems to be attacking the supposed (il)logic of its contentions and the resulting consequences.
At the moment this back and forth feels like you’re talking past his actual point(s).
The FSF’s principles have always permitted the use of non-free software when it advances the goal of software freedom. GNU was initially built using non-free software.
Given the pejorative yet inaccurate references to “religion.” I can’t help but think some people are deeply disturbed by the very concept of moral principles and and cognitive dissonance is forcing them to hallucinate that the FSF doesn’t actually have principles but is instead a cult. Very odd.
No, the argument is about the pragmatic criteria used to implement agreed upon principles. Bringing this back to concrete discussion, here is a quote from the Libreboot KGPE page:
> AMD Opteron 6200 series (Fam15h, with full IOMMU support in libreboot - highly recommended - fast, and works well without microcode updates, including virtualization)
> AMD Opteron 6300 series (Fam15h, with full IOMMU support in libreboot. AVOID LIKE THE PLAGUE - virtualization is broken without microcode updates.
"Avoid like the plague", yet there is little philosophical difference between compromising to trust AMD's 6200 masked microcode, and compromising to trust AMD's microcode update that fixed Spectre on 6300. The main possible distinction is if you want to argue that AMD became less trustworthy in the time between those two releases.
Obviously if AMD releases new microcode for the 6300 going forward, it's a software freedom/security question of whether that microcode should be installed (automatically or even after review). But as it stands, slow changing microcode updates are in the same security/freedom realm as new CPU releases.
One of the nice things about the FSF's free software principles is that if you disagree with how they think you should use their software, they're not going to stop you. Nonguix[1] provides solid non-free support if that's what you want. In fact it has a helpful section on microcode updates.
The FSF even condones non-free software (in a rather dorky way) for people whose machines require it[2]. I understand the FSF's principles and am glad they hold to them so strongly, but I would use non-free graphics drivers if I were to install Guix. I do fundamentally agree with the principles of software freedom and I am honest with myself that I am in fact making a moral compromise. Similarly I'd probably compromise over CPU microcode patches, even though I believe I have the moral right to view, understand, and change those microcode updates if I wish to and am displeased that my rights are being violated.
I believe in this day and age where the right to repair your own equipment is under serious threat, the principle that we should be free to modify the machines we own as we see fit is more important than ever.
I fully believe in software freedom (including favoring the GPL), and am trying to push it forward with this argument. I just see using a "6300 with microcode 2019-12-18" as the exact same compromise as using a "6200 with microcode 2011-11-14", regardless that the first blob was loaded at runtime while the second blob was loaded at the factory. Neither one lets me audit or modify my processor. There aren't many performant processors that do let you do such things, so the FSF is willing to compromise on systems with the second type of processor. I argue that they should extend that same pragmatism to the first type of processor as well.
Ultimately, the goal of a GNU/Linux distribution is to create a fully Free GNU/Linux environment. A fully free system would be a worthy goal, but Guix is not attempting such a thing (say by refusing to run if it detects hardware that has non-free firmware in flash). Rather they preemptively compromise by ignoring blobs stored in flash, but refuse the same compromise when those blobs would be loaded at runtime. This is completely backwards given that blobs loaded into auxiliary processors' RAM by Free software running on the main processor are actually more under the control of Free software.
And sure, nonguix exists. But I've gotten the impression that when you interact with the Guix community (eg irc), they will give you a bit of a cold shoulder for using nonguix because it is "not free software", even though you're making the exact same compromise as anyone else with a non-Free microprocessor or non-free auxiliary processor firmware. So ultimately I'm arguing that community norms, as led by the FSF, need to change here. They're stuck with an outdated model that simply ignores embedded firmware, rather than engaging with the nuance of labeling each part of a system as "free" or "non-free"
It sounds like we have very similar beliefs. I think the FSF should acknowledge that microcode updates and such are odious but tolerable moral compromises and that we should continue to work for a future where we have complete freedom to modify, repair, and otherwise use our machines as we see fit.
However, for fun, I'm going to do my best to steelman the FSF position: The use of non-free software when no free alternative exists is tolerable. The material difference between firmware that comes with the hardware or microcode that comes with the CPU versus a downloadable update is that the update is voluntary, and thus involves a willful violation of the principle of freedom. By doing so one becomes actively complicit in the erosion of freedom.
I also agree that they shouldn't be jerks on mailing lists and IRC, but have some empathy for persons that aren't so fortunate that they can eschew all non-free software.
I think the FSF position comes to down to 1. It's what they've always done and 2. They don't want to be distributing any nonfree software, even when it wouldn't become part of the Free environment
Whereas having a background in embedded design, I can't ignore that I have many more devices running nonfree software than Free software, despite trying to use Free software wherever I can. In particular, my fully Free desktop relies on non-free { monitor, monitor remote, keyboard, mouse, USB hubs, USB hub PS (power supply), USB switch, UPS, network power switch, circuit breaker, ethernet switch, ethernet switch PS, GPON terminal, GPON PS, nonfree BIOS on router }, in addition to the contentious non-free { video card, network card, CPU }. Any and all of those things could be replaced with a Free equivalent, but at the cost of attention that would be better spent elsewhere. In a world being eaten by software, the best we can do is hope for well-defined interfaces with nonfree systems, for our Free systems to interoperate with.
Perhaps a good way forward would be to split (Nonguix, Debian non-free, etc) into two separate categories depending on whether a package runs in the main security domain (drivers, system software, utilities/applications), or is to be loaded into an auxiliary processor (firmware blobs). Then after this distinction became widely accepted, the Free-first distros would hopefully become more comfortable including the firmware blobs, making a better user experience for their Free environments without impinging upon the freedom within.
(FWIW your steelman isn't it - it would seem to indicate that buying a computer with MS Windows preloaded is good from a software freedom perspective)
And here is the error of your logic: "is voluntary, and thus involves a willful violation of the principle of freedom".
Principle of freedom, in the context of the FSF, has always referred to user/recipient freedom.
A user voluntarily (of their on unconstrained freedom) making a (informed) choice for themselves, by definition does not violate their own freedom, they are exercising their freedom. You are contradicting yourself.
Complicit-ness can be debated with regards to purchasing decisions, not with regards to updating firmware.
i am not affiliated with FSF in any way. yet it seems to me that there are plenty of people arguing against them in very bad faith. here is the full excerpt in question:
>AMD Opteron 6200 series (Fam15h, with full IOMMU support in libreboot - highly recommended - fast, and works well without microcode updates, including virtualization)
>AMD Opteron 6300 series (Fam15h, with full IOMMU support in libreboot. AVOID LIKE THE PLAGUE - virtualization is broken without microcode updates.
>NOTE: 6300 series CPUs have buggy microcode built-in, and libreboot recommends avoiding the updates. The 6200 series CPUs have more reliable microcode. Look at this errata datasheet: http://support.amd.com/TechDocs/48063_15h_Mod_00h-0Fh_Rev_Gu... (see Errata 734 - this is what kills the 6300 series)
>Description: Under a highly specific and detailed set of internal timing conditions during a #VMEXIT for a virtual guest that has multiple virtual CPUs, the processor may store incorrect data to the virtual machine control (VMCB) reserved and guest save areas and may also store outside of the VMCB.
If you are referring to me, I don't see how my excerpt is incomplete or could be seen as bad faith. Libreboot is steering people away from 6300 processors because using them requires explicitly loading a proprietary blob, while encouraging the use of 6200 processors that have an analogous blob baked in at the factory. The real difference is that the former makes you more aware of the compromise.
reading the full excerpt seems to put the reason for rejecting 6300 onto Errata 734 and it was strange to me that this wasnt addressed in your post
however i wasnt referring to you specifically as arguing in bad faith but that seems to be the attitude of some very vocal people here. i included the full excerpt in case the point is relevant. i am not an expert in this field
> reading the full excerpt seems to put the reason for rejecting 6300 onto Errata 734
Well there are two reasons. The first is Errata 734, and the second is that the fix for Errata 734 requires loading different microcode than what was baked into the processor at manufacturing time ("6300 series CPUs have buggy microcode built-in, and libreboot recommends avoiding the updates"). I didn't mention Errata 734, because I'm focused on the second reason.
Working back from their reasoning, Errata 734 seemingly does not apply to the 6200 series.
mindslight, i cant reply to you directly so i will do it like this. thank you for clarifying about Erata 734. if Erata 734 applied to 6200 then libreboots logic would make no sense
i take no issue about with critically discussing someones logic. fud and attacks are annoying and dont contribute to a healthy discussion
