71–80 of 205 posts
Earlier quoted context omitted.
It has one tiny blob for ram initialization, people are looking into removing it. It may become RYF certified. Freedom wise, it is the best modern laptop.
Better than the pinebook pro?
I 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…
At this point, I think that's become a cop-out on their part. If they really want to make their vision of truly open hardware a reality, they need to roll up their sleeves and make it happen. Mostly open (due to reverse-engineering) FPGAs are a thing, SkyWater is a thing, RISC-V is a thing. Take one of the open source RISC-V designs, design and build a test system using an FPGA[1] (or more than one... depending on wh…
I'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…
"They should die for the cause."
Harm isn't very present on the FSF priority list.
Earlier quoted context omitted.
Better than the pinebook pro?
Yes. Pinebook pro has one or more other blobs and they are for more significant functionality.
Earlier quoted context omitted.
At this point, I think that's become a cop-out on their part. If they really want to make their vision of truly open hardware a reality, they need to roll up their sleeves and make it happen. Mostly open (due to reverse-engineering) FPGAs are a thing, SkyWater is a thing, RISC-V is a thing. Take one of the open source RISC-V designs, design and build a test system using an FPGA[1] (or more than one... depending on wh…
IMHO, we need a free hardware foundation today just like we needed FSF in the 80-90's.
FSF's hardline attitude has always rubbed me the wrong way. I respect and support their goals but at the end of the day software should respect the needs and desires of their users 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 i…
The OS isn't a person. The OS has online discussion forums and the people who develop the OS CAN talk about it in the appropriate forum. Identifying and separating nonfree issues is a useful tool in their goals.
The FSF last year started a new campaign that is specifically meant to not be hardline and to respect the needs and desires of users: https://www.fsf.org/blogs/community/support-the-freedom-ladd....
If you'll forgive my naivete here I've been thinking a lot about the FSF philosophy and wanted to ask HN: how big of a project would it be to create a fully libre (whatever you want to call you it) laptop? Like how feasible is it to use "free" components put together into a package and what kind of budget would be required? I think China has a few companies working on domestic processors. Let's say they are convinced…
But what does it mean by "Libre"? You see, the entire disagreement is about a problem of our definition: How does one define "a hardware system without non-proprietary software"?
Ideally, if every single chip in a computer has free hardware design down to the logic gate or HDL level, that would certainly qualify as 100% libre in both hardware and software (if a free operation system is also used). But obviously it's not practical, and it's also out of scope of what the FSF does, it's the Free Software Foundation, and it only cares about software, not hardware. Thus, the FSF defines "Respect Your Freedom" as a hardware system that doesn't require you to execute any nonfree software to use.
This sounds like a straightforward definition, right? But for many different types of hardware - essentially 90% of all digital electronics - if you open it up, decap the chips, you'll find a general-purpose microprocessor core executing code in a hard-wired Mask ROM. The chip can be a CPU with embedded microcode, a serial port transceiver, a USB controller, or even a Voltage Regulator Module (just search "DigiVRM"). Sometimes you don't even know it's implemented in this way. Thus, a practical boundary between hardware and software must be drawn.
The FSF's argument is basically the following: Consider a blackbox hardware system, such as a chip. Inside the chip, you may find a bunch of logic gates, hardwired to be a finite state machine, or you may find a read-only Mask ROM driving the microprocessor. But it's irrelevant: from the perspective of the software user outside the chip, it doesn't make any difference, it's just an implementation detail in the hardware realm that matters to a hardware engineer, not a software developer. Externally they can even be indistinguishable, if not at the electrical level, at least at the software level. Thus, as long as the logic is not controllable by software, it's not considered as a form of "non-free software" and it gets "Respect Your Freedom" approval. I think there's little to no disagreement at this point, but it gets controversial next.
Now, consider two chips, one is a controller and another is its ROM. The FSF argues that, if the ROM is not reprogramable via software even by its vendor after it leaves the factory (if the ROM is 100% read-only, or if the Write function is permanently disabled at hardware level), the controller and its own ROM are collectively considered equivalent to some hard-wired electronic circuitry in the pure hardware realm, using the same argument. Thus it also gets "Respect Your Freedom" approval.
However, if the ROM can be reprogrammed (e.g. has an enabled "Write" function) or controlled by software (e.g. uploading a blob by the device driver to the chip), it's considered as a form of non-free software, thus the FSF say it "Does Not Respect Your Freedom".
And this is where the disagreement starts.
The FSF may insist that a software-controlled firmware is strictly a type of computer program, thus it must be non-free software, meanwhile firmware not controlled by software may as well be a collection of hard-wired logic gates, so it's a "don't care" item for a software user - or at least a form of compromise. The counterargument is that, regardless of whether the firmware control is enabled or disabled, you're ultimately running the same non-free software in both cases (even though, the first case is invisible to software and the second case is visible to software), and it's just a matter of location, either ROM or disk. Since running fixed non-free software is better than running vulnerable non-free software, the "Respect Your Freedom" hardware's "quasi hard-wired" firmware is a waste of time and provides less user freedom.
I only described the disagreements, it's up to you to decide. Now, I'm curious to know what would be your definition of "Libre", after learning what I've told you?
Earlier quoted context omitted.
> Why accuse the FSF of hypocrisy? If I ship some piece of hardware on a PC with its firmware burned into a ROM and do not provide the source (a binary blob), the FSF will happily say my hardware is RYF-certified. If I ship the exact same hardware with the exact same firmware as a binary blob but in Flash RAM or loaded at init by a driver they'll accuse me of not "respecting freedom". Same hardware. Same firmware. Sa…
See https://www.fsf.org/campaigns/free-bios.html for the rationale. Basically, FSF had to make a compromise here. If you use Flash ROM (or other writable medium), the firmware counts as a nonfree software . However, if you use actual ROM, the firmware might as well have been a circuit baked right in the product, so it counts as hardware ; nevertheless, it counts as non-free. FSF's ultimate goal would of course be to…
That doesn't mean that mask ROM is free of antifeatures, though - in fact, often times mask ROM is the highest privilege level in the system and thus the best place to put antifeatures. In the case of x86 PCs, the BIOS gets it's own privilege level above the kernel; ARM PSCI also runs in EL3 above normal kernels or hypervisors. These can still actively damage user freedom even if it's "technically hardware" and non-updatable.
Also, the fact that it's not rewritable means that...
1. Security bugs[2] will never be fixed[3], rendering the hardware unsafe to use over time.
2. We cannot practically replace the firmware with a Free equivalent.
It should not be understated that the vast, vast majority of hardware did not come Free. We had to open it ourselves through painstaking reverse-engineering and reimplementation work. This is an ongoing burden that the community must meet for the foreseeable future. Manufacturers are not going to stop shipping hardware with proprietary firmware or drivers anytime soon. Ergo, anything that stands in the way of firmware or driver reimplementation is, in my opinion, bad. This includes making it more difficult to update or replace firmware by putting it into a mask ROM.
My personal opinion is that you can't really draw a line in the sand and say, "this hardware respects your Freedom, but this other hardware doesn't". Hardware manufacturers have zero interest in fully-Free firmware, and I don't expect this to ever change. Not even with RISC-V, which will almost certainly have even more "embedded" fragmentation than ARM does. Whatever standard the FSF writes for "Respects Your Freedom" hardware, someone is going to try and rules-lawyer non-Free software into getting that badge. So they should not provide a strict standard at all.
There's also another question of how much energy we actually want to burn on getting Free firmware into chips. An alternate interpretation of the idea behind the Free BIOS campaign is that the BIOS itself got "interesting" enough to be a Freedom threat. Back when it was still a ROM, Free kernels could ignore it entirely; now it gets it's own privilege level and has to at least be considered. CPU microcode is less of a threat than the BIOS, here - the microcode just lets you patch how certain instructions get decoded, while the BIOS can actively debug and spy on Linux.
[0] I am going to use the term "mask ROM" loosely. Consider one-time programmable memories like PROM or EPROM to be in the same category, as they cannot be electronically erased and then reprogrammed by the same circuit that uses them.
[1] There is a sui generis right for "mask works", but it is far less toxic than software copyright. For one, it has a reasonable term length.
[2] I am assuming security from the standpoint of an end-user, of course. Being able to defeat TiVoization is not a security bug for me.
[3] It is possible to swap ROM chips in some cases, if the part is socketed, or if it is soldered and the user has the appropriate level of soldering skill. However, at this point this is no longer read-only. It's just Flash memory with extra steps. There is no legal or ethical difference between reflashing a chip with proprietary software on it and replacing it with a new chip with new, proprietary software on it.
Earlier quoted context omitted.
> You already accepted it when you bought the CPU and it came with the base version. No, that is a version you can't physically modify. The other version is one you can't modify because of it's license and signature verification. You are simply ignoring important differences, like saying an elevator is no different than a flight of stairs, they both get you up, and anyone who avoids elevators must be an idiot.
... but you can modify the base version. That's how microcode updates work, they patch it (via a patch register CAM). Are you trying to argue that the physical mechanism used for patching matters? That's an implementation detail, it has nothing to do with freedom. Your CPU comes with patchable proprietary software. Period.
There is some read-only memory that contains the base version. It is executed on boot. You can tell the cpu to run a different version by pointing it to a different version during the boot process (or later). You can't change the version in the read-only memory.