Recently posted comments

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.

The manufacturer using RISC-V means trading a blob containing an Arm Cortex-R binary for a blob containing a RISC-V binary [1]. Just because the CPU instruction set is nominally "open" doesn't mean any of the rest of the silicon will be.

[1] Likely put together using some sort of proprietary instruction set extension and a proprietary toolchain. Because "freedom for me, but not for thee"

But I happen to think the original premise of the free software movement was flawed: Stallman couldn't fix the printer driver but he drew the wrong conclusions. What he needed was not the source code, but the specifications. Open specs is the important thing. Source code can be obfuscated, deliberately or otherwise.

In the blob case, if the hardware were well documented, it would be easier to write open blobs.

Against all odds, free software seems to have become a successful minority in the software landscape. On the other hand, free hardware is very much relegated to the margins. So if you don't draw a line somewhere, you can only conclude that freedom is currently completely out of reach. But whenever you *do* draw a line, you'll get unintended consequences, because the line indeed doesn't really make sense.

To end on a hopeful note: free hardware might get a little boost from the recent Right to Repair movement and legislation. That might end up creating a market and legal environment in which full-stack tech freedom becomes feasible.

Is it ideal ? No. Like all non profits the FSF is more constrained than the legislator.

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.

user_pref("browser.ml.chat.enabled", false);
user_pref("browser.ml.chat.menu", false);
user_pref("browser.ml.chat.page", false);
user_pref("browser.ml.chat.shortcuts", false);
user_pref("browser.ml.chat.sidebar", false);
user_pref("browser.ml.enable", false);
user_pref("browser.ml.linkPreview.enabled", false);
user_pref("browser.ml.linkPreview.optin", false);
user_pref("browser.ml.modelHubRootUrl", "");

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.

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.

The x86 ecosystem being relatively open seems to be a historical anomaly. Manufacturers seem determined to not make that mistake again.

How so? I really fail to imagine the legal conspiracy here...

Firmware is just software and exists for the very same reasons. Why do people use software ? Hardware is faster after all!

Personally I like Debian's document about that:

https://salsa.debian.org/deeplearning-team/ml-policy/

It would be very useful to have at least some of the former, for things like human language translation, noise removal from audio, text to speech, speech to text and so on.