by meithecatte on 1/23/22, 12:58 AM with 192 comments
by MathMonkeyMan on 1/23/22, 1:26 AM
> 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.
by jeroenhd on 1/23/22, 1:40 AM
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.
by yellowapple on 1/23/22, 5:41 AM
The FSF's stance here also impacts the "ports" trees of various BSDs and (GNU/)Linuxen; if they so much as include instructions for compiling and installing nonfree software (regardless of whether they actually include nonfree software), the FSF considers the whole OS nonfree. Same deal with any (GNU/)Linux distro that maintains a nonfree repo - even if that repo is disabled by default.
The rationale for these sorts of stances is that even so much as making nonfree software available for installation is an "endorsement" of that software. In spite of that rationale, the FSF maintains officially-sanctioned precompiled ports of software like GIMP for nonfree operating systems like Windows and macOS - because apparently it's okay to endorse those nonfree operating systems, because reasons.
by r283492 on 1/23/22, 3:50 AM
> In other words, you can’t microcode update a CPU to add or substantially change capabilities.
There is CCC security presentation floating around where someone reversed engineered microcode before it was signed, and designed a backdoor into it, a remote code execution triggered by going to a specific webpage. That is a substantial capability that exists in todays microcode.
by roenxi on 1/23/22, 1:38 AM
> ... 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?
by jeppesen-io on 1/23/22, 4:02 AM
I saw this on the nonguix repo for all non free software for guix
> Please do NOT promote this repository on any official Guix communication channels, such as their mailing lists or IRC channel, even in response to support requests! This is to show respect for the Guix project’s strict policy against recommending nonfree software, and to avoid any unnecessary hostility.
To do my job and boot my laptop nonguix is required but not even allowed to talk about it with the OS it intends to support, is not something I can agree with
I think the above is the type of side-effects seen with a hardline policy of the FSF. Obviously I'm not the target of this type of policy, but I still feel more good can be done in the long run with a little compromise to the realities of using a computer today
by irfwashere on 1/23/22, 2:36 AM
I think China has a few companies working on domestic processors. Let's say they are convinced by Stallman's charisma to make chips that are not cutting edge but decent, and libre.
Whatever your thoughts are on China but I would suggest to the FSF to slowly move in that direction. Where all the component schematics are open and viewable. At least to go for auditability since no one trusts the Chinese.
Like I said, forgive the naivete, but it feels like a noble yet lofty goal.
And then proceed to go into every industry with right to repair issues. Deere tractor competitors, home appliances, and so on. In the name of component longevity and repairability. All of this to repudiate forced obsolescence and to promote end user freedoms.
It's a stretch but I enjoy dreaming about it. Hoping a better world is possible.
by basilgohar on 1/23/22, 1:51 AM
by BrS96bVxXBLzf5B on 1/23/22, 4:26 AM
"They should die for the cause."
Harm isn't very present on the FSF priority list.
by simfree on 1/23/22, 1:15 AM
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.
by guilhas on 1/23/22, 1:54 PM
Although I think they could have a second tier, more relaxed for Debian, NixOS and others, that exclude nonfree software/firmware but allows you to enable it. But in general I think it is commendable that they have been able preserve their values and not dilute and disappear
When I buy my hardware I make sure it is compatible, stable and won't have many issues with Libre Linux, even thing like swapping the wireless card to a compatible one
And this has been the rule also for all Linux users. You want to make sure you have a smooth experience, you will have to check for hardware recommendations. Want fingerprint working? Better be sure before you buy
Regarding security most Libre people are not serving cloud services in their computers, and install only open source. So the microcode security mitigations like, spectre and meltdown, are mostly unnecessary. Also browsers and kernels have been patched for it anyway
When I configure a server I will probably majorally never upgrade it, because it will always cause problems, sometimes small, other times big headaches. I would sooner configure a new one and migrate things slowly
If one microcode update is enough to fix your system is also enough to break it: Intel to disable TSX by default on more CPUs with new microcode https://news.ycombinator.com/item?id=27664856
This recent security paranoia that you should be updating everything every day or else the hackers will get you! seems unnecessary and potentially harmful
by jancsika on 1/23/22, 3:14 AM
https://mntre.com/media/reform_md/2020-05-08-the-much-more-p...
by someoneelse9 on 1/23/22, 1:52 AM
Even the T60 offers a decent performance if your usecase is browsing the web, mail and other simple tasks.
The FSF might be wrong in some aspects but there's no real alternative to Libreboot. The Framework laptop is not free software friendly. Even if it was corebooted, it would require many proprietary blobs and it's highly unlikely, if not impossible, that they will be ever able to remove the Intel ME.
There are other options that are nearer to be completely free (as in freedom) hardware, eg the Pinebook Pro. I'm unsure if there are any proprietary blobs required to boot it tho, but the lack of Intel ME makes it a much better candidate for a new generation of 'libre' hardware.
by aragilar on 1/23/22, 6:28 AM
by Avamander on 1/23/22, 2:06 AM
FSF should stick to software only, learn to see shades of grey and label hardware accordingly or reject anything that isn't open until silicon (silicon excluded). Current choice is half-baked.
by throwaway81523 on 1/23/22, 7:49 AM
by deknos on 1/23/22, 8:51 AM
sorry, but i think the FSF is totally justified. the ME engine and stuff like that showed that the industry does not have the best interest of customers (business and endusers alike) at heart and will fuck them over for more money.
and then the whining here is great again and it's like "Stallman was right" and at the next turn "but ma feetures" complaints come around, because it costs more money or time which also would be the ethical thing to do often enough
by ineedasername on 1/23/22, 3:58 AM
by koprulusector on 1/23/22, 5:20 AM
by pabs3 on 1/23/22, 3:35 AM
by marcodiego on 1/23/22, 1:51 AM
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.
by jimmyvalmer on 1/23/22, 4:15 PM
It's sad any of it is being directed towards sophistic, quasi-religious debate.
by toolcombinator on 1/23/22, 7:35 PM
It’s a dinosaur from another era with its hypocritical RAM vs ROM policies, or “secondary processor” loopholes.
It assumes that there’s one Central processor in charge, something that hasn’t been true for a very long time.
Which parts of an SOC is central? The CPU? Great. Modern CPUs are multicore chips, so which one are central and which one are secondary?
by spacexsucks on 1/23/22, 4:06 PM