The FSF’s relationship with firmware is harmful to free software users
1–10 of 205 posts
Re: The FSF’s relationship with firmware is harmful to free software users
#2Properly isolated accessory non-free hardware is a good thing, and for a user whose threat model requires libre hardware, the security model of the PinePhone or Librem 5 where the LTE modem is isolated with a kill switch to interact via USB (rather than connected via PCIe, which would have direct memory access) is the right choice.
Is a Thinkpad T400 with a Core2Duo and SSD the right choice in 2022? What about a Pinebook Pro? Friends and acquaintances I know are using these computers as their primary devices today.
Re: The FSF’s relationship with firmware is harmful to free software users
#3I'm well out of my realm of expertise here, but I had a gut reaction to:
> Libreboot, being FSF-recommended, also has this policy of disallowing firmware blobs in the source tree, despite it being a source of nothing but problems.
Later the author points out how there isn't any contemporary libre hardware that would satisfy users (vaguely but reasonably described), and so "free" solutions utilize loopholes in the legal language that defines the FSF's "libre."
What I'm reading is that capable libre hardware does not exist, or at least has not existed for many years.
Why accuse the FSF of hypocrisy?
Later,
> At this point, total blob-free computing is a fool’s errand, so there are a lot of AMD Ryzen-based machines that will give you decent performance and GPU acceleration without the need for proprietary drivers.
Indeed, I don't use truly libre hardware either. I buy whatever The Man makes available. Libre hardware is still a worthy goal. There is no harm here on account of the FSF.
Re: The FSF’s relationship with firmware is harmful to free software users
#4> ...In other words, you can’t microcode update a CPU to add or substantially change capabilities...
> ... vulnerabilities such as Meltdown and Spectre, which were partially mitigated through a microcode update ...
Of these two snippets, only one can be true. Either opaque microcode updates can substantially change how a system performs, or they can't. These mitigations are major changes to how the processor works.
This post looks to me like a fairly typical "doesn't quite get what they mean by freedom" take, of which there are many (which is cool, freedom isn't everyone's cup of tea). The FSF has been quite consistent that if there is a choice to be made, the user should have a practical way of making that choice. If the manufacturer can change how a CPU works with a microcode update, the user should be able to as well.
The FSF has a clear role here. Their job is to say "this software is free, this software is not". People constantly call on them to compromise on that role in the name of security/convenience/helpfulness/strategic adoption concerns/the impractical nature of their stance. The FSF should and does ignore those people. They are a (slightly quirky, yes) moral lighthouse more than an adoption friendly technical project. This microcode is not free software and someone should be pointing that out and complaining about it. If the FSF isn't taking a stand against non-free microcode, who will?
Re: The FSF’s relationship with firmware is harmful to free software users
#5I think the ideology of the FSF is a perfectly fine one. It's the hardware vendors that insist on binary blobs that are the problem here.
Nobody produces truly free consumer hardware and nobody has produced any for years now. Everything is hidden away because of fears of patent lawsuits and other people copying this One Neat Trick when initializing the devices.
Intel would lose very little if it published the source code for the blobs loaded into their processors, because the signature requirements prevent anyone else from developing their own microcode, yet it still encrypts and obfuscates the compiled code. The same is true for most chip and UEFI suppliers.
I hope riscv will soon take off in a way that foregoes all of these blobs, though I highly doubt it since modern hardware is encumbered by patents and secrets. It's a sad reality that free, libre computers do not exist and blaming the FSF for having high standards is the wrong approach.
Re: The FSF’s relationship with firmware is harmful to free software users
#6[deleted]
Re: The FSF’s relationship with firmware is harmful to free software users
#7> ...In other words, you can’t microcode update a CPU to add or substantially change capabilities... > ... vulnerabilities such as Meltdown and Spectre, which were partially mitigated through a microcode update ... Of these two snippets, only one can be true. Either opaque microcode updates can substantially change how a system performs, or they can't. These mitigations are major changes to how the processor works. T…
Yet they are fine with running microcode as long you don't update it. It doesn't make sense. Blobs don't disappear just because they are hidden in ROM.
Re: The FSF’s relationship with firmware is harmful to free software users
#8I've got the feeling the author has read my comment: https://news.ycombinator.com/item?id=30036588
What is said about librem5 is irrelevant: it is not certified.
What is said about gaming the certification is irrelevant: no currently certified devices does it.
There are modern certified devices: Talos motherboards.
There are no modern laptops certified? Blame the vendors. OK, this may not make them change their mind, but while we are not fully independent, I see no other way.
Re: The FSF’s relationship with firmware is harmful to free software users
#9I'm well out of my realm of expertise here, but I had a gut reaction to: > Libreboot, being FSF-recommended, also has this policy of disallowing firmware blobs in the source tree, despite it being a source of nothing but problems. Later the author points out how there isn't any contemporary libre hardware that would satisfy users (vaguely but reasonably described), and so "free" solutions utilize loopholes in the leg…
> Why accuse the FSF of hypocrisy?
I'm not sure I fully agree with the author, but I think their point is that the FSF makes exceptions for binary blobs in some places because of usability, but then denies similar exceptions elsewhere because they're not libre. The complaint is that the decision on what counts as being included in the loopholes appears largely arbitrary, at least from an outsider's perspective.
Re: The FSF’s relationship with firmware is harmful to free software users
#10Very few people or organizations willingly give up control. The whole reason of using copyright law to "enforce" freedom by preventing free software from becoming unfree was because of how much the current legal framework around imaginary property is stacked against a libre approach. So, it's a tough game to play, but FSF didn't achieve what it has thus far by being soft or compromising. Substantial change with hostile parties doesn't happen by constantly yielding.