>The last Libreboot release, version 20220710, was released on 10 July in 2022. This new release, Libreboot 20221214, is released today on December 14th, 2022. This is intended to be a testing release.
This paragraph goes from YMD to DMY to MDY... I don't see why hyphenating the date from the release version wasn't good enough.
For a second there I thought that this was a new library that allowed applications to reboot the machine they're running on... as in "LibReboot", not "LibreBoot"
Libreboot changed their definition to include CPU microcode updates. So some people would argue not they're "libre" anymore, or no different from coreboot. Also some people consider it unavoidable, as Debian also folded recently
Also they stopped supporting the most capable boards Asus KGPE and KCMA
From what I can tell this is an alternate motherboard firmware for retro computers. The website doesn't really explain any new features you get by using this over the manufacter provided firmware. It says that it's more secure, but I don't see motherboard vulnerabilities as being a big problem in computing.
Libreboot is a fork of Coreboot, an open source system firmware/BIOS replacement. You are most likely to find it in Google's "Chromebooks" and other devices as Google hired most of the dev team behind the software
Libreboot differs in that it refuses to include things such as CPU microcode. Because the FSF has an absolutely asinine definition of "free software" wherein any code that can be modified or updated is non-free, but if it comes from an untouchable ROM chip they can pretend it's still "free"
They've always called themselves a "Coreboot distro", not a fork. From the homepage: "In the same way that Debian is a GNU+Linux distribution, libreboot is a coreboot distribution."[0]
That was a lot bigger deal when libreboot first started, because at the time Coreboot wasn't doing their own releases, so doing release engineering and such around Coreboot was a lot more of a value-add.
> Libreboot … refuses to include things such as CPU microcode.
That is false since the libreboot+osboot merger. Osboot was a fork of libreboot that had a more lax binary blob policy; they merged back together last month[1], taking osboot's more lax policy[2], which does block out some binary blobs from upstream Coreboot, but allows important blobs such as CPU microcode.
> Because the FSF
I'd be hesitant to say that libreboot does anything because of the FSF; libreboot and the FSF have had a... tumultuous relationship, for both technical/policy reasons, and personal reasons. Libreboot's policy page[2] has a big section about disagreements with the FSF's policy. It's more fair to say that libreboot does things because of Leah Rowe's position on things, which will tend to align with the position of FSF supporters, but not necessarily.
> because at the time Coreboot wasn't doing their own releases, so doing release engineering and such around Coreboot was a lot more of a value-add.
Distributions can still offer value through release engineering steps that coreboot skips: https://doc.coreboot.org/releases/checklist.html#purpose-of-... says about releases: "Our releases aren’t primarily a vehicle for code that is stable across all boards ... Instead, the releases are regular breakpoints ..."
Stable libreboot releases, MrChromebox's releases (over at mrchromebox.tech), vendor releases (Chromebooks, System76, Purism, Starlabs, ...) and so on are useful because they provide more rigorous testing for the subset of devices they actively support.
Unless you're a developer and/or have tools to recover from a bad flash, these releases are more likely to get you a useful firmware image compared to coreboot.org releases.
(That doesn't mean we're not doing _any_ testing before releasing on coreboot.org, but it's somewhat stochastic: whatever the release team has tested themselves or got reports on is good, everything else is of unknown quality.)
> Because the FSF has an absolutely asinine definition of "free software" wherein any code that can be modified or updated is non-free, but if it comes from an untouchable ROM chip they can pretend it's still "free"
That is gross misrepresentation of their position. It is more like if a project is claiming to be free software, then it should not have parts that are non-free software (like redistributing firmware). If the firmware is in hardware ROM or EEPROM chip (or just downloaded independently from third source), then then it is not part of such project and therefore out of scope (i.e. somebody else's problem).
> Because the FSF has an absolutely asinine definition of "free software" wherein any code that can be modified or updated is non-free, but if it comes from an untouchable ROM chip they can pretend it's still "free"
So mask ROM or OTP ROM are okay, but EPROM/EEPROM/flash are not?
Exactly. It is counterintuitive, but they have to draw the line somewhere, and then such things happen. No way around it without making up some rather arbitrary new definitions, with all that problems(1) that that brings. Well, actually. The distinction between hardware (here: basically 3D-printed VHDL et al) and software is already such an arbitrary definition.
(1) like manufacturers tweaking details to fall under the desired definition, legal arguments about the definitions, etc...
This never really made any sense to me. If I build a PC with Windows installed on a read-only flash drive, can I advertise it as running 100% free software?
As I type this on one of my main computers, a machine built in 2011, I have to question your definition of "retro"; I appreciate that it's a sliding scale, but I think I would stick with "old" for anything x86_64 and up. And your list goes to 2015; do you really think 7 years old is "retro"?
A quad core i7 from a decade ago has comparable performance with a modern one. Calling it retro when it's at most 1/3 as powerful seems very out of place
I use it on all my computers that are supported. But on the laptop side, that means I haven't been using it for a while, since most recent supported laptop is from 2013, and work-provided laptops have spoiled me in to liking having more modern hardware.
It's great. Things I like: faster boots than any stock BIOS I've ever encountered; being able to dive in to the source of what I'm running (I'm one of those FSF-type Free Software nutjobs); being able to do fancy things like LUKS encryption all the way down to the BIOS.
The LUKS encryption is a massive selling point to me. I've been considering getting an old X220 as a travel laptop and luckily that appears to be supported.
This paragraph goes from YMD to DMY to MDY... I don't see why hyphenating the date from the release version wasn't good enough.