31–40 of 54 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
[flagged]
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.
Earlier quoted context omitted.
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...
Earlier quoted context omitted.
These comments are usually downvoted but they're usually quite useful. Thanks.
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…
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.
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...
Earlier quoted context omitted.
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 c…
Earlier quoted context omitted.
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 po…
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.
Earlier quoted context omitted.
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.