Hacker News Reader

Comment by ckastner | Hacker News Reader

I guess that in their mind, they're producing code for some utopic x86 system that does not have non-open microcode baked in, in which case their approach would be right.

This is a complete denial of reality, of course, and at the cost of the user. Religious dogma, as you put it, seems like an apt description.

View on HN

why is it a religious dogma? i dont see the point of hostility. they have every right to hold to those principles as long as they are not deciving anyone and state their values clearly. who are they harming?

They are deceiving people into believing they are not running proprietary software, while they are, and that software is just not evident because it doesn't live on their filesystem. Then they actively withhold information from users so they will neither find out nor be tempted to find out for some other reason.

If they were being honest, they would tell people that this dongle has a good half a megabyte or so of proprietary Bluetooth stack built-in (with runtime patching/update ability; they all do), and they wouldn't deceptively have a "TET-BT4 source code" link that makes it sound like the firmware is open, while it's actually just a tarball of the Linux kernel (which contains a generic Bluetooth controller driver, nothing specific to this device).

https://ryf.fsf.org/products/TET-BT4

i just looked through this website and found a link to their certification process at https://ryf.fsf.org/about/criteria

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?

The existence of that exception, the way it is implemented, the way they work with vendors to help them fit into it, and the way they do not require informing users of such secondary processors are all deceptive.

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.

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

no. he is calling it deceptive, which is even stronger than confusing. his statement was:

> They are deceiving people into believing they are not running proprietary software

edit: as regards FSF's logic i am not informed enough to comment so i didnt. but the conversation (this thread) was definitely about deceptiveness

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.

[1] https://gitlab.com/nonguix/nonguix

[2] https://www.gnu.org/philosophy/install-fest-devil.en.html

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:

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)

>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)

END

source: 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

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

does the issue in Erata 734 apply to 6200?

> 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

I'm not the FSF, but one argument could be things like the Intel Management Engine that I know the FSF have strong opinions on.

If that's isolated to a separate CPU, it's easier to track the signals going in and out, and the bad things it can do are limited.

The FSF don't actually care about such details - sure, they'll deride ME, but they make no attempt to inform users about how it compares with alternatives and which options are better for users. That's because their criteria are not based on technical analysis, like determining what the access surface of the blobs is, but instead on the mere existence of the blobs. To them, all visible blobs are equally bad, regardless of whether one can completely compromise your system and another one is completely harmless and requires no trust.

>To them, all visible blobs are equally bad, regardless of whether one can completely compromise your system and another one is completely harmless and requires no trust.

For a company that values software freedom above all else this is completely fine. If they are called Secure Software Foundation then your arguments would hold more weight. For example, I really doubt that FSF would claim that GNU Guix is more secure than Open BSD

The FSF have repeatedly associated software freedom (by their definition) with security and privacy. This is just one example, there are many others:

https://www.fsf.org/bulletin/2020/spring/privacy-encryption

but security is associated with free and open source software. i think this is a common position of a vast majority of security experts. to make your claim that FSF deceives or misleads people you need to do a LOT more. for example, can you provide an example where someone claims that GNU Guix is secure by design[0]

i think that taking a position that free software supports security and also that free software principles come before security considerations is not contradictory let alone deceptive

[0]EDIT: i just searched the RYF site and did not obtain a signle result for the term 'security'

https://ryf.fsf.org/search/node?keys=security

The factors that actually impact the upper boundary of achivable security are availability of source code (open or not) and reproducible builds. The 4 freedoms do not actually affect any aspect of security, they are orthogonal.

Also, just because the 2 factors above impact the upper boundary of achievable security does not mean an open source software is automatically more secure.

It is conceivable for 2 comparable pieces of software to exist one open source and the other closed source and for the closed source one to be more secure.

There are many reasons why open source software is in practice considered more secure, among others being faster availability of updates and the aforementioned higher upper ceiling of security.

>does not mean an open source software is automatically more secure

well my point is that FSF never anywhere claimed otherwise. if they did THAT would be wrong and irresponsible

>It is conceivable for 2 comparable pieces of software to exist one open source and the other closed source and for the closed source one to be more secure.

sure. well a simple example is that security by obscurity is a valid concept in a right environment

Security is part of protecting your freedom from being compromised. I read this entire thread and wholeheartedly agree with marcan_42. FSF's position to draw a line where none exists is foolish wishful thinking and potentially dangerous.

I prefer knowing that I live in a world where COMPLETE software freedom is close to unachievable and it (COMPLETE software freedom) is a worthy goal to strive for compared to deceiving myself into believing it has been achieved by ignoring anything below a certain level.

Just because I choose to amputate my ability to update firmware does not mean a malicious party might not be able to do so. Anyone with physical access to hardware will still have that ability by using extra hardware. Handwaving the firmware away does not work against an evil maid attack.

>I read this entire thread and wholeheartedly agree with marcan_42

and you are free to do that and i would not say that you are a part of marcan-worshipping-cult or following some dogma

>deceiving myself into believing it has been achieved by ignoring anything below a certain level

if you are stating that this is what FSF believes then you are in fact spreading a falsehood and fud. this is what marcan has been doing regarding FSF the whole time during this engagement

>Just because I choose to amputate my ability to update firmware does not mean a malicious party might not be able to do so. Anyone with physical access to hardware will still have that ability by using extra hardware. Handwaving the firmware away does not work against an evil maid attack.

Unless FSF is claiming that GNU Guix is secure by design, or is free from such attacks, this is just a strawman argument

The FSF is deceiving themselves and others by believing that just because a user no longer has the ability to update firmware on a device, that device is acually no longer running non-free code.

I really do not understand what is so hard to understand that from a free software POV there is no distinction between a chip loading a blob from system storage and a chip loading a blob from it's own tiny updatable flash. Both load a non-free blob. Neither fully respects your freedom. Drawing the line of Respects Your Freedom TM between those 2 is stupid and deceptive.

The users ability to update firmware is also the ability to revert firmware changes (to a old trusted even if closed source version) made by a malicious party. Users do not gain any freedom by giving up that ability. They loose freedom.

Being able to choose between MS Office and Lotus and Star Office and WPS Office (1) gives the user more freedom compared to being stuck with just MS Office (2), even if none of those respect your freedom. Being able to also choose Libre Office (3) is obviously better. But 1 is still obviously better than 2. The existance or absence of 3 does not change that.

With regards to firmware, the FSF believes that 2 is better than 1. That is stupid. How do you not see that?

It is a valid form of protest but Respects Your Freedom TM certified hardware does not truuuuly respect your freedom.

This is harmful because the goal should be hardware with FLOSS firmware with reproducible builds and with the option for the user to add their own signing keys, NOT unupdatable (by the user) closed source proprietary firmware.

>With regards to firmware, the FSF believes that 2 is better than 1. That is stupid. How do you not see that?

your comparison with MS is ridiculous. FSF software is open. do with their software what you like. FSF believes it should not help you with 1 or 2 due to its principles, and that is OK. why wouldnt it be? the source is there so help yourself if you really want something that they are not willing to help you with (even if they often do apparalently)

anyway this whole exchange is becoming tyring to me. a lot of these comments by people seem to be more about vaging a crusade against FSF than it is about discussing issues in good faith. its somewhat dissapointing, esspecially since i only just realised who marcan is. as far as i am concerned, i am completely unconvinced by marcan and co that FSF is a deceptive organisation and that their work is somehow bad for free software. quite the opposite, i am happy that they exist. i say this simply as a spectator. to me the following comment on their website just clearly shows that they are aware that products they certify run nonfree code:

"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"

(source given elsewhere in the exchanges)

i do not feel deceived in the slightest. if deception is happening it seems to be regarding FSF's position. take care

Or have a proprietary RTOS running on a GPU, working hypervisor-like for the tacked on ARM-multicore, like some very popular fruity berry SBCs.

(giggle)

Librem 5 is not RYF-certified.

You're right, not yet (I wonder why? Maybe they cut too many other corners, or the FSF gave up on the program?), but that entire nonsense was squarely aimed at gaining RYF certification and done with the FSF's blessing.

Look, its all very simple, "firmware that is not normally changed is ethically equivalent to circuits" https://www.gnu.org/philosophy/applying-free-sw-criteria.htm...

Ya, monitors and hard drives all have very complicated firmware too. It is very simple, it is not denying you a freedom which is unethical to deny. FSF is not saying: it's totally great and fine, I'm sure the FSF will be happy to promote any of those devices if they have free firmware in them, celebrating them as more free. It's the same reason they focus on software and not on hardware designs.

Their approach is firmly stuck in the computing paradigm of the 70s and 80s, much like Stallman is personally stuck in the social narrative of the same era. The FSF and him refuse to change and adapt to the times.

But since reality doesn't care about their refusal to adapt, and they can't just throw their hands up in the air and say nothing is free any more and you should just live off the grid and reject all technology, they instead have built a deliberately obtuse set of rules to declare certain things out of scope, so they can maintain the illusion of freedom for their followers while making concessions behind the scenes (and even actively working with manufacturers to devise silly workarounds that fit into that framework, see e.g. the Librem 5's ridiculous secondary CPU core and external flash dance so they can claim the RAM training blob doesn't make their device non-free).

Then they're very careful to never talk about this unless prompted; the fewer people know about all these secret blobs they're running anyway, the better. It's basically cult-like behavior - this kind of control of the information and narrative that followers get is a defining characteristic.

None of this helps users, of course; what would help users would be being informed about not just exactly what blobs exist, but what the risks are, how they might affect their privacy and security, what update options exist, and whether they can be audited or replaced with free versions in the future. But the FSF doesn't care about any of that. They just want to pretend they live in a blob-free utopia.

Edit: Ah, the downvotes have started. I guess the FSF fans have showed up. I hope you're not using an off the shelf mouse to click on the downvote button; those all run proprietary USB HID firmware.

Please don't take HN threads further into flamewar. It lowers the quality of discussion noticeably.

Also, please omit inflammatory swipes like your "Edit", which also badly broke more than one of the site guidelines. Would you mind reviewing them? We're really trying to avoid this sort of hell to the extent possible.

https://news.ycombinator.com/newsguidelines.html

God doesn't exist, that doesn't prevent him of being.

The quest for freedom is, of course, an idealistic one. The important thing is that, in their fight to promote freedom, they meet obstacles. Those friction points reveal the lack of freedom. And so, although they don't reach freedom, they actually show that freedom is limited.

IOW, refusing the statu quo is one of the way to change it.

You should look at history and look at how much freedom you have, how much protection you have, etc. and then ask yourself : where does it come from ?

> IOW, refusing the statu quo is one of the way to change it.

And yet they aren't changing it. The FSF has had exactly zero success in changing the direction the world is moving in with regards to firmware and deep proprietary integration.

In fact, they've done very little for freedom in the past 10-20 years; most of the real breakthroughs have come from much more pragmatic people, such as those developing reverse engineered open source drivers for complex hardware like GPUs.

The FSF shows you how much freedom you lack according to their own bizarre definition of freedom... and then does amazingly little to actually improve your freedom.

>In fact, they've done very little for freedom in the past 10-20 years; most of the real breakthroughs have come from much more pragmatic people, such as those developing reverse engineered open source drivers for complex hardware like GPUs.

Whose efforts get completely circumvented through employment of cryptographic firmware signing, which gate keeps necessary functionality out of said pragmatist's reach.

> The important thing is that, in their fight to promote freedom, they meet obstacles. Those friction points reveal the lack of freedom. And so, although they don't reach freedom, they actually show that freedom is limited.

Well said. If problems are not openly demonstrated and complained about, things will not improve.

> how much freedom you have, how much protection you have, etc. and then ask yourself : where does it come from

Game theoretic behaviour in society that has advanced beyond zero sum.

Same goes for reasonable approach to FOSS, like Marcan is doing himself vs the cult and the arbitrary zero tolerance rules.

i strongly disagree. i think cult, dogma, and religion accusations as well as misrepresentation of FSFs stance (i have zero association with FSF yet i could see thatbtheir position is being crudely misrepresented) do much to discredit any valid points marcan holds

what does adapting to the times mean? FSF and GNU seem to be about fundamentals of computing and software. have these fundamentals changed?

The line between hardware and software has been heavily blurred in the past 30 years. The FSF continue to draw an arbitrary line where none can be drawn, and then say only one side needs to be Free. Since there is no longer any clear line, this gives them the freedom (ha) to deceptively do so in a way that is convenient to them and makes their followers believe they are getting some kind of special Freedom, when in reality the FSF is just tweaking the definitions to make it work.

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

There is no nuance there. Without free software there is no software freedom. If blobs are allowed at all that is already a measure to have a system that works in practice, but in no way makes it the position against closed software and blobs wrong.

The people criticizing the FSF here act as if Stallman were wrong about these issues because he said it back then already. While in reality again and again he was right about how user freedoms are limited when the principles he outlined are not followed.

To give Intel a way to distribute closed source software updates to your processor is definitely a security risk. And we know for certain the actors in the USA that try to use those security risks for their surveillance programs. Don't act like this world does not exist.

But you already run a processor with the very real possibility of backdoors from that very same entity. And let’s be honest, a zero day due to a CPU bug is orders of magnitude more likely to cause real harm than the fantasy of state actors deploying some blobs to your computer and have a look at my meme collection. 100% is never achievable but I much prefer having 85% than nothing.

I too settle for less bad dictatorship as means of governance.

They aren't taking away Intel's ability to push updates to people's computers, because they never had that ability. What the FSF and that Linux fork are doing is taking away users' right to be informed about security vulnerabilities in their system so they can make the choice whether to trust Intel's update or not. By withholding that information they are effectively eliminating the choice, and restricting users' freedom.

That's not true. If distros package closed source firmware updates the manufacturer has the ability to provide updates to people's computer via that system. I mean, that's the whole point and in a trustworthy environment that's a good thing. Maybe have a look at https://wiki.debian.org/Microcode#CPU_microcode_non-freeness (I'm not sure whether I'm just misinterpreting your comment or whether there is a knowledge gap, just to make sure we talk about the same thing :) ).

> By withholding that information they are effectively eliminating the choice, and restricting users' freedom.

You are mixing up agency and software freedom, it's clear that you won't see eye to eye with the FSF as long as you do so.

I'm not even vigorously defending not showing the note about existing firmware updates, if Guix really does so. I'd prefer a note. Just what it would mean and how problematic closed firmware would be seemed like it needed a clarification here.

> If distros package closed source firmware updates the manufacturer has the ability to provide updates to people's computer via that system.

That is not what linux-libre is doing/refusing to do. What linux-libre is doing is censoring a message to their users that their microcode is out of date and their CPU has security vulnerabilities. They could've just left that in and let users make the choice whether to manually install the microcode updates or not.

> You are mixing up agency and software freedom

Agency is more important than software freedom. The FSF's problem is precisely their blind focus on "software freedom" when the definition of "software" can't even be precisely defined any more, to the detriment of everything else that affects users.

>Agency is more important than software freedom. The FSF's problem is precisely their blind focus on "software freedom" when the definition of "software" can't even be precisely defined any more, to the detriment of everything else that affects users

your refusal to accept FSFs right to adhere to its principles is bordering on the extreme. yet you constantly lob insults toward them as an organization. it does not help your points at all. they obviously hold different values to you. i think FSF is ok as long as they are clear about what they are doing and they are not trying to trick anyone. you have done absolutely nothing to demonstate otherwise in this whole exchange and instead you keep slinging FUD. i will repeat my question that i have asked so many times: has GNU or FSF anywhere claimed that they take a security-centric approach? as far as i know they have always taken a free-software approach. that they refuse to bend their principles to infantile screams is a big plus in my books

>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

i think i have always held the opinion that for FSF and GNU their concept of security was "security through free software". that is free software (according to how its understood by them) comes first

> while their policies have absolutely nothing to do with improving users' security or privacy

IIRC Stallman criticized Ubuntu for collecting users' search info by default-- something they used to do[1].

It's unfortunate to see a call to nuance paired with an exaggerated claim that is so easily disproven.

1: https://www.gnu.org/philosophy/ubuntu-spyware.en.html

This comment was strong until the last paragraph about the downvotes.

You broke the site guidelines with this comment and it started a flamewar. Please don't do that; we're trying to avoid it here.

https://news.ycombinator.com/newsguidelines.html

We detached this subthread from https://news.ycombinator.com/item?id=29286715.

Reply on news.ycombinator.com