Libreboot 20230423
libreboot.orgI have a lot of trouble reading it a "libre boot" rather than "lib reboot". The lib prefix is so common in open-source/Linux.
I never noticed that before, now I cannot unsee it
Same here :)))
LibreBoot probably solves it
I think that's intentional. See also: libiberty.
That name reminds me of "Liberty Biberty" from the insurance commercials: https://www.youtube.com/watch?v=4mrLqtmko5Y
(real meaning: https://en.wikipedia.org/wiki/Libiberty)
I never understood what Libreboot does on top of Coreboot. As far as I could tell it's a "distro" of Coreboot that just disables some things and maybe adds a few patches.
All the heavy lifting is done by Coreboot.
Libreboot provides:
- 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-...
Pretty much +95% of the Linux distros are like this.
That's not correct. Each distro has a huge amount of code in the form of patches, packaging and installation that they handle.
Think of the manhours + resources wasted achieving/maintaining basically the same thing in slightly different ways...
Not really. Whoever created these distros had a specific vision they wanted to achieve. Debian is one thing, Arch is another. The world is richer for having both.
Debian and Arch are different enough that the argument isn't about them. The issue is the 100's of distros that could be replaced with just "install <major distro> and do apt install X" (or some other trivial thing like changing the default to KDE instead of Gnome).
You can also replace that with "just install Windows", or "just use macOS".
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!"
You completely misunderstand. Windows and Mac are different enough from every linux distro that the argument isn't about them.
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.
If whoever is putting in the time and money to maintain those things thinks it's worth, then there must be a reason for it.
90% of distros' "visions" is ultimately just providing a general-purpose desktop/laptop OS. There's indeed an insane amount of wasted effort, both on developers' part but also users (skill portability is an issue because no 2 Linux distros/machines are alike).
I think the original comment is more about debian,Ubuntu, Lubuntu, Xubuntu, etc. And then separately, Arch vs Anarchy, etc.
I would argue that those are either similar enough to not be wasteful or dissimilar enough to not be redundant. Lubuntu is just Ubuntu with some minor differences in default packages and configs; there's not enough difference there to be wasteful. OTOH, Ubuntu, at least for a long time, was genuinely much more friendly to beginners than Debian, partially just because they could get patches in faster, and partially because they had a looser standard around non-free packages. There was divergence but for a good reason, and the projects have largely collaborated over the years so that the source code changes are shared where sensible but they target slightly different audiences with different support systems. Well, there's also Canonical just being Canonical but there's no way to solve that.
Does Libreboot (.org) still have the binary blob drama going on?
This? https://libreboot.org/freedom-status.html
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.
There's definitely drama around it. There's drama around whether devices seeking RYF certification can use newer (blob-allowing) versions of Libreboot, even if the devices has a board for which Libreboot doesn't use blobs. There's drama around whether FSDG-following GNU/Linux distros can still ship the Libreboot tools.
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/
I hadn't seen this new Libreboot policy. This is fantastic!
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.
I wouldn't say that the FSF's criteria are unprincipled. At his pre-Libreplanet talk on 2023-03-17, RMS gave a principled and pragmatic explanation of the criteria. I don't agree with him on his application of some of the principles or on where the appropriate places to make compromises between principles and pragmatism are; but that doesn't mean his conclusions are unprincipled.
I'm watching the video (I haven't had my dose of RMS in a while), but I haven't heard anything new so far.
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.
I'm curious why you call it drama and not debate. Every open source project is constantly debating new ideas. Calling something drama has a connotation of another layer of ego.
A debate can have an answer; this is two groups with mutually exclusive subjective views.
But I would say that there is an answer here. Given the mutually-agreed on objective of protecting/creating-a-distribution-that-respects the users' rights to the 4 freedoms as defined by the FSF, there is an answer as to which policy best serves that goal.
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.
But you can absolutely debate subjective issues. We do that all the time when discussing policies.
When there's a fork and disagreement over who "owns" the name, that's drama.
> See also the high-security / high-trustworthiness work of Purism.
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...
I'm pretty sure that "drama" is the whole reason Libreboot exists, instead of just merging into the Coreboot project it's based on.
Nope, what libreboot does is make coreboot simple for end users to install. With coreboot, you have to configure it manually (by design). Libreboot even provides pre-compiled binaries (with clear instructions on how to install them).
'Was'
They recently included non-free binary blobs. They should probably rename to openboot
Haven't heard of this, can you share more context or a link to a story about this?
There was a sibling "osboot" project that allowed in the minimum amount of binary blobs to add support for more boards. This is at odds with the FSF's RYF and FSDG policies. In November 2022, libreboot merged osboot, adopting osboot's more permissive binary blob policy ( https://libreboot.org/news/policy.html ). Because libreboot is no longer in compliance with the FSF's policies, this has created some drama in the community. Some of the libreboot contributors have even split off and created a fork (also claiming the Libreboot name: https://libreboot.at/ ).
Perhaps they can distinguish themselves as LibReboot, in contrast to LibreBoot.
Thank you for the explanation!
Can someone ELI5 what this is and what purpose does it serve?
This is a pre-compiled distribution of Coreboot with the aim of sticking as close to free as in freedom philosophy.
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.