Perfection is the enemy of good
Perfection is the enemy of good
Posted Oct 15, 2025 8:19 UTC (Wed) by nim-nim (subscriber, #34454)In reply to: Perfection is the enemy of good by dskoll
Parent article: The FSF's Librephone project
You’ve pretty much made the FSF case, blobs are just software (and most often badly written software that would benefit from outside review), there is no business case for keeping them proprietary except the habits and beliefs of managers that went to electronics courses where software (moreover, FOSS software) was not a thing.
I do remember how the people in charge of the electronics deps at my uni steadfastly chose all the worst possible software dead ends on the market for their tooling, the dumber and disconnected from software culture they were the more they appealed to them. Sometimes it seemed they were deliberately targeted by sellers of aborted solutions, just like scammers target the old and vulnerable.
Posted Oct 15, 2025 9:10 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (15 responses)
Either blobs are unacceptable full-stop (but that means ruling out access to SCSI, IDE, NVMe, SATA, SAS etc HDDs and SSDs), or they should be user-serviceable - including allowing the user to reverse-engineer and modify their own systems in ways the manufacturer does not approve of.
But the FSF's position is that blobs that are in ROM are A-OK, even if the manufacturer intended them to be updated at runtime, and even if they have known serious bugs, but blobs that can be modified by a sufficiently motivated user are not, and I cannot make sense out of this position.
Posted Oct 15, 2025 9:52 UTC (Wed)
by nim-nim (subscriber, #34454)
[Link] (8 responses)
The FSF position is quite simple and easy to understand as long as you do not engage in strawmen, and remember it was all kickstarted by the need to service a broken printer. It is basically right-to-repair for software, decades before right-to-repair became a grassroot movement.
It is all way clearer than the intellectual contortions people engage to invent mythical it-is-like-software-but-it-should-be-locked-because-bigcorp-says-so categories.
Posted Oct 15, 2025 10:13 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (7 responses)
As a consequence, most "RYF" devices take firmware that is intended to be serviced, and cut the "write enable" pin to the flash device so that it cannot be serviced in the field, but instead has to be returned for repair if there's a bug in the software.
This is not a strawman - this is a very real problem. And the FSF's attitude is that this is what we want - software locked down so that it can only be serviced by return to manufacturer, not in the field.
Posted Oct 15, 2025 10:50 UTC (Wed)
by nim-nim (subscriber, #34454)
[Link] (6 responses)
You want things to be sort of serviceable except when the OEM feels it is inconvenient, that did not work for Stallman’s printer and that does not work for current products, news are full of bricked products, designed obsolescence, enshittification, etc.
Posted Oct 15, 2025 11:04 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (4 responses)
Why does RYF explicitly permit devices that can only be serviced by the OEM and not by the end user, while rejecting devices where the end user has the necessary access to service it?
As far as I can tell, the sole justification for this is that if RYF insisted that firmware was serviceable by the end user, or not serviceable by the OEM at all, there would be very few certified devices, and none that handled RF at all.
Posted Oct 15, 2025 11:23 UTC (Wed)
by nim-nim (subscriber, #34454)
[Link] (3 responses)
Is it ideal ? No. Like all non profits the FSF is more constrained than the legislator.
Posted Oct 15, 2025 12:31 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (2 responses)
Why does the FSF want to lock things down so that users cannot service firmware themselves, nor can they have Free firmware, but instead are tied to paying the vendor for servicing events?
Posted Oct 15, 2025 13:23 UTC (Wed)
by pabs (subscriber, #43278)
[Link] (1 responses)
https://libreplanet.org/wiki/Group:Free_Software_Foundati...
I proposed that the FSF:
Change the criteria to require non-free firmware on secondary processors be able to be upgraded, downgraded, locally modified, replaced or reverse engineered. One way to see this is that some freedoms are better than zero freedoms.
Change the criteria to require that free software running on the main processors must be protected from modifications by non-free firmware on secondary processors, through the use of an IOMMU or similar technology.
Posted Oct 15, 2025 22:20 UTC (Wed)
by hailfinger (subscriber, #76962)
[Link]
While your additional requirement is useful from a freedom perspective, it is desperately needed from a security perspective.
Posted Oct 15, 2025 12:21 UTC (Wed)
by excors (subscriber, #95769)
[Link]
I think all of that news is about IoT products that depend on cloud services that aren't supported forever. As far as I can see, RYF doesn't say anything about cloud services - it's only concerned with the updateable firmware on the device itself, plus the software used to build and install that firmware, plus Windows drivers on CD-ROM included with the device. They explicitly say RYF "only certifies that hardware respects your freedom and control, and not a vendor's infrastructure or customer service apparatus" (https://ryf.fsf.org/about), but the vendor's infrastructure is the biggest issue for long-term support.
In theory, Free firmware means you could adapt it to work with a new Free cloud service. But I think the cloud software is often much more complex than the firmware, and they're often tightly coupled with a poorly-documented protocol (because both sides were developed in parallel by the same company, and mandatory OTA firmware updates (incidentally forbidden by RYF) mean they don't need to maintain long-term backward compatibility, so they could avoid the hassle of building a well-defined stable interoperable API). When reimplementing the proprietary cloud service to work with the Free firmware, I'm not sure you'd save much effort compared to redesigning and rewriting the whole firmware+cloud system from scratch with a more suitable API.
The better way to avoid bricking of IoT devices is to buy ones that don't require a proprietary cloud service at all, and are compatible with e.g. Home Assistant. The firmware doesn't really matter.
Posted Oct 15, 2025 9:54 UTC (Wed)
by ryanduve (subscriber, #127786)
[Link] (1 responses)
Posted Oct 15, 2025 10:13 UTC (Wed)
by farnz (subscriber, #17727)
[Link]
Posted Oct 15, 2025 12:37 UTC (Wed)
by pizza (subscriber, #46)
[Link] (2 responses)
You also left out most [1] input devices (ie keyboards/mice/touchpads/touchscreens,scanners), displays (anything newer than analog CRTs), and other output devices (eg printers of various types).
It is sound engineering practice (not to mention effectively legally required in many jurisdictions) to make devices field-updateable. The FSF's "RYF" performative nonsense results in an objectively *worse* product, including from the perspective of "user freedom".
> I cannot make sense out of this position.
...The FSF's "RYF" position is akin to putting a brown paper bag over a bottle of booze. If you can't see what's in it, you can pretend it's something else (ie "doesn't contain software"), because you _technically_ don't know for sure.
[1] as in nearly everything ever made available on the market.
Posted Oct 15, 2025 17:59 UTC (Wed)
by cesarb (subscriber, #6266)
[Link] (1 responses)
Most analog CRTs I've used (both computer monitors and TVs) had on-screen menus. I'd have to go back to my very first computer monitor and my very first TV (that TV had fully mechanical controls, including a nice rotating knob to choose the channel with a fine-tune collar around it) to find an analog CRT without some form of built-in software.
Posted Oct 15, 2025 18:09 UTC (Wed)
by farnz (subscriber, #17727)
[Link]
Posted Oct 15, 2025 15:10 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
And I think that places it on serious collision course with European Consumer Protection laws. The CRA has already been mentioned, but combined with "Fit for Purpose" legislation, it sounds like RYF hardware will not be "fit for purpose" in the EU.
Combine the requirement for goods to have "a reasonable life" with the CRA's requirement for software to be fixable and get fixed during said life, that means RYF hardware will be deemed to have zero life at point of sale, and thus "unfit for purpose".
We'll see ...
Cheers,
Posted Oct 15, 2025 14:21 UTC (Wed)
by dskoll (subscriber, #1630)
[Link]
The thing is, if the device works as specified, what freedoms are you missing by not being able to change the blobs? It's only if blobs actually restrict you from doing things that you might plausibly want to do (and that don't e.g. violate radio spectrum rules) that they become a problem.
And yes, the embedded software industry is a cluster-****. But there are way too many short-lifespan devices powered by way too much niche software to make open-sourcing the blobs remotely interesting to most people.
The problem is that the FSF's case as set out by RYF is that proprietary blobs with full-blown DRM to prevent a user from attempting to service them are acceptable as long as you lock in the bugs at time of manufacture. And I cannot see a valid argument for that particular contortion.
Perfection is the enemy of good
Perfection is the enemy of good
The FSF's position is disconnected from reality - it says that if I burn the software into ROM, and require you to pay for an RMA, it's fine to lock the software down so that it cannot be serviced any other way, but if I allow you to change the software, it's not OK.
Perfection is the enemy of good
Perfection is the enemy of good
If the FSF's position is as you say, why does RYF certify devices where there are DRM-protected blobs that prevent you from servicing the firmware yourself, but that permit the manufacturer to service the firmware with a small wire link during RMA?
Perfection is the enemy of good
Perfection is the enemy of good
RMAs are free to the manufacturer - the FSF's RYF-approved vendors do, IME, just charge the cost to the end user for servicing the firmware, to the point where it's normally cheaper to throw away a perfectly working device and buy a new one from them than it is to get them to service the firmware.
Perfection is the enemy of good
Perfection is the enemy of good
Perfection is the enemy of good
That is surprisingly hard on quite a few processors (yes, in the x86 space as well as the ARM space and elsewhere) unless you move the free software into a secure enclave (which usually has its own share of non-free blobs needed to run the free software).
Perfection is the enemy of good
Perfection is the enemy of good
Yes, because I start without HTML tags, and add as I need formatting. For short comments like this, no tags.
Perfection is the enemy of good
Perfection is the enemy of good
Perfection is the enemy of good
I had a CRT TV towards the end of the CRT era that had literally one chip in it, and might well have had software in mask ROM not internal flash. That would count, to me, as genuinely hard-coded software per RYF terminology, since an embedded mask ROM (unlike embedded flash) needs you to replace the entire chip to rewrite it.
Perfection is the enemy of good
Perfection is the enemy of good
Wol
Perfection is the enemy of good