4 ms·

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 so

by User23 5y ago

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.

mindslight 5y ago
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.
- medo-bear 5y ago
  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: BEGIN >CPUs supported: >AMD Opteron 6100 series (Fam10h. No IOMMU support. Not recommended - old. View errata datasheet here: http://support.amd.com/TechDocs/41322_10h_Rev_Gd.pdf http://support.amd.com/TechDocs/41322_10h_Rev_Gd.pdf) >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_Guide.pdf http://support.amd.com/TechDocs/48063_15h_Mod_00h-0Fh_Rev_Gu... (see Errata 734 - this is what kills the 6300 series) END source: https://libreboot.org/docs/hardware/kgpe-d16.html https://libreboot.org/docs/hardware/kgpe-d16.html the Errata 734 is quoted here as reference: BEGIN >734 Processor May Incorrectly Store VMCB Data >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. END
  - mindslight 5y ago
    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.
    - medo-bear 5y ago
      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 does the issue in Erata 734 apply to 6200?
      - mindslight 5y ago
        > 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.
      - medo-bear 5y ago
        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
- User23 5y ago
  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. [1] https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix [2] https://www.gnu.org/philosophy/install-fest-devil.en.html https://www.gnu.org/philosophy/install-fest-devil.en.html
  - mindslight 5y ago
    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"

by User23 5y ago

mindslight 5y ago

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.

medo-bear 5y ago
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: BEGIN >CPUs supported: >AMD Opteron 6100 series (Fam10h. No IOMMU support. Not recommended - old. View errata datasheet here: http://support.amd.com/TechDocs/41322_10h_Rev_Gd.pdf http://support.amd.com/TechDocs/41322_10h_Rev_Gd.pdf) >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_Guide.pdf http://support.amd.com/TechDocs/48063_15h_Mod_00h-0Fh_Rev_Gu... (see Errata 734 - this is what kills the 6300 series) END source: https://libreboot.org/docs/hardware/kgpe-d16.html https://libreboot.org/docs/hardware/kgpe-d16.html the Errata 734 is quoted here as reference: BEGIN >734 Processor May Incorrectly Store VMCB Data >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. END
- mindslight 5y ago
  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.
  - medo-bear 5y ago
    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 does the issue in Erata 734 apply to 6200?
    - mindslight 5y ago
      > 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.
    - medo-bear 5y ago
      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
User23 5y ago
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. [1] https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix [2] https://www.gnu.org/philosophy/install-fest-devil.en.html https://www.gnu.org/philosophy/install-fest-devil.en.html
- mindslight 5y ago
  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"