Libreboot 20230423(libreboot.org) |
Libreboot 20230423(libreboot.org) |
(real meaning: https://en.wikipedia.org/wiki/Libiberty)
All the heavy lifting is done by Coreboot.
- Release engineering and testing. When Libreboot started, upstream coreboot wasn't doing releases at all; now they are, but they're still not suitable for end-users who want to use stable tested software: "Our releases aren’t primarily a vehicle for code that is stable across all boards"[0]. Downstream distributions that test on a specific range of devices (such as Libreboot, mrchromebox.tech, and vendors such as Chromebooks, Purism, System 76, ...) are still important to the ecosystem to provide stable releases. In the words of a coreboot dev: https://news.ycombinator.com/item?id=33997880
- Pre-compiled and tested binaries, because lots of users aren't set up to build their own.
- A distribution of tools for more easily installing them than a sequence of long `flashram` incantations.
- Loads of documentation.
- Pre-configuration of common payloads, such as GRUB or SeaBIOS.
And let's not forget that the Libreboot project does contribute to upstream coreboot.
[0]: https://doc.coreboot.org/releases/checklist.html#purpose-of-...
Most importantly it identifies devices, which can be booted with as little involvement of non-free blobs (binary large objects) and pre-configures coreboot to support exactly that use-case, whilst enabling features off by default in Coreboot like CMOS settings. Also it disables the Intel Management engine, not by patching it out, but by booting in a way which does not require it to load in the first place, if possible. Depending on architecture, like some laptops with Core2 and some server boards like any AMD processor from the Bulldozer era can be booted off-of firmware images, which contain no black-box blobs from the manufacturer or parts, which cannot be recreated from FOSS code. Most crucially, this also includes μCode updates.
So it could be seen as a tradeoff in stability and performance to get close to the ideal of extending FOSS into the realm of Hardware.
I wouldn't call it drama. There's often important practical reasons to try to minimize closed parts of the firmware. See also the high-security / high-trustworthiness work of Purism.
The page https://libreboot.org/news/policy.html does a better job of showing how the Libreboot's policy is at odds with the FSF's RYF and FSDG policies. And that disagreement between Libreboot and the FSF definitely causes drama in the community.
Heck, a few Libreboot contributors split off and created a fork (also claiming the Libreboot name): https://libreboot.at/
After reading the posts from marcan_42 and GrapheneOS developer strcat, I have a much lower opinion of Purism.
https://hn.algolia.com/?query=strcat%20purism&sort=byDate&ty...
https://hn.algolia.com/?query=marcan_42%20purism&sort=byDate...
They recently included non-free binary blobs. They should probably rename to openboot
The FSF's criteria have become quite calcified and unprincipled at this point. Specifically I'm talking about how blobs loaded from flash are given a pass, while blobs on isolated coprocessors are verboten.
Principle requires that binary blobs in flash (or even ROM) are put in the same class as every other binary blob. And pragmatism for the modern world requires that we incorporate security relationships into our analysis of user freedom.
The bit I'd call unprincipled is giving a pass to software that is baked into hardware, and hardware modification in general. This is pure pragmatism from the world of the 90's, regardless of the stated justification.
This crutch allows RMS to avoid having to work out an approach to analyzing systems which are combinations of libre, non-libre, and someone else's domains. And due to the rise of everpresent network connectivity, analyzing these combined systems to figure out how libre software can be used to create the most user freedom is more important than ever.
In RMS's terms, such systems just seem to be considered "unethical; avoid" and his thinking stops. This isn't particularly productive when overwhelming commercial interests herd users into those types of systems, network effects keep them there, and many are part of real businesses that can't just be forked.
Libreboot has said "given that goal, we believe that the FSF's RYF and FSDG policies are problematic and partially undermine the goal", and the FSF has said "no, we believe that our RYF and FSDG policies are the best policies at this point in time, and Libreboot's non-compliance with those policies partially undermines the goal". But both sides agree on the goal.
Hell, you use this for anything; "why make a new album, movie, or book when there are already thousands upon thousands of them? Yours probably isn't any better!"
And if you're going to start talking about copy-rightable works of entertainment, then yes if you write a book based off another book just with 1 extra character (analogous to "install <major distro> and do apt install X") then that book would violate copyright and should not be written. It's the lack of copyright in FOSS that allows all the pointless duplication of effort with all the almost identical linux distros.