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.
- 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.
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.
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 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.
I want to see opinions and answers from actual humans, not from a Random Bullshit Generator. If I wanted to see the Random Bullshit Generator’s opinion, I would have asked it myself.
> Libreboot is a downstream distribution (or fork) of coreboot which doesn’t allow non-free binaries (“blobs”)
Libreboot does allow some blobs, if there is no good alternative, and because a mostly-free board is better than a completely non-free board according to their policy: https://libreboot.org/news/policy.html
> and only supports a small number of devices, the vast majority of which are over 10 years old.
That one’s probably accurate.
> Libreboot also doesn’t “keep track” with coreboot; its most recent release is from mid-2016, whereas coreboot is updated regularly.
The link we’re commenting on leads to a release announcement. The linked announcement mentions the previous release was 10 days ago. There was a gap in libreboot releases between September 2016 and May 2021, so the Random Bullshit Generator’s response is outdated by 2 years.
Fortunately, Random Bullshit Generators do not have feelings, and will not get hurt by my use of the (IMO more appropriate) term to refer to them. They are overhyped, and I do not think that posting their output in HN comments leads to positive and thoughtful discussions.
I'm doing it for the first time. Didn't know it will get this negative a reaction. I feel like the answer was acceptably worded. I even pointed out that I understand half the answer was wrong. I felt like it was in the spirit of HN.
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.
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.
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).
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/ ).
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.
