From 5291ce8c397b3d13177a0e10ff9365d83f0d7616 Mon Sep 17 00:00:00 2001 From: Nicholas Chin Date: Thu, 14 Dec 2023 18:42:40 -0700 Subject: [PATCH 1/2] news/10.md: Fix spelling mistakes --- site/news/10.md | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/site/news/10.md b/site/news/10.md index 6b3aa1d..295cdbe 100644 --- a/site/news/10.md +++ b/site/news/10.md @@ -2,7 +2,7 @@ % Leah Rowe % 12 December 2023 -I'm very proud of the work done in Libreboot, both my myself and by others +I'm very proud of the work done in Libreboot, both by myself and by others who I work with. Many people make Libreboot possible, be it direct contributors to the project, or the countless individuals and companies that work on all the upstream projects used in Libreboot, projects like coreboot. I'm *very* @@ -134,7 +134,7 @@ compiled ROM images, with source code, but there was no automated build system. The [build system](../docs/maintain/) evolved over time. The first releases of Libreboot supported only the ThinkPad X60. Later, T60 -supported and MacBook 2,1 support were added. This first year of the project +support and MacBook 2,1 support were added. This first year of the project was spent on building solid infrastructure, specifically documentation and an automated build system. The design of Libreboot revolves around scripts that automatically download, patch, configure and then compile various codebases, @@ -466,7 +466,7 @@ Libreboot 20160818, 20160902 and 20160907. Initial outcomes ------------- -Libreboot's popularity reached great heights duting this time, greatly expanding +Libreboot's popularity reached great heights during this time, greatly expanding and attracting many new developers. Joining GNU accelerated this further, though it came with certain drawbacks. @@ -653,7 +653,7 @@ which is something I also considered at the time, but that would have required maintaining a full coreboot repository, merging and overseeing a lot more patches from upstream, and diverging heavily. The way Libreboot's deblobbing worked was that it just deleted the blobs, and (by way of configuration) avoided -all boards except those that could bo booted entirely blob-free in the flash. +all boards except those that could be booted entirely blob-free in the flash. This method required far less maintenance - the original blob-free policy of Libreboot has been continued, as of 2023, in a new project I maintain called [Canoeboot](https://canoeboot.org/) - I'll have more to say about this, @@ -709,7 +709,7 @@ the event here: Also of note: Alyssa contributed to Libreboot a custom-written static site -generetor, converting its static HTML into Markdown files for documentation +generator, converting its static HTML into Markdown files for documentation on the website, then generating pages with Pandoc. This static site generator is included in the original Libreboot git repository, and it later became the basis for my own [Untitled Static Site Generator](https://untitled.vimuser.org/) @@ -783,10 +783,10 @@ I keep that repository there for archival, but it is no longer developed. I took over the project again in 2021, and scrapped the rewrite. More on this later in the article! -Andrew Robbins and Sebastien Gryzwna +Andrew Robbins and Sebastian Grzywna ------------------------------------ -Sebastien had joined the project during early 2016, advising about hardware +Sebastian had joined the project during early 2016, advising about hardware and he made quite a few useful code contributions at first. For example, he added support for 16MB IFD configurations in ich9gen. @@ -835,12 +835,12 @@ to it, hoping they'd prove me wrong. When I stepped down, the project had adapted a formalised "democratic" governance policy, implementing a horizontal hierarchy form of collective management. In practise, the former BDFL leadership under me was replaced -by basically the same thing, only it was two people; Andrew and Sebastien +by basically the same thing, only it was two people; Andrew and Sebastian called all the shots. They would regularly turn away code contributions, and -Sebastien in particular was often extremely rude to users on the IRC channel, +Sebastian in particular was often extremely rude to users on the IRC channel, acting in a very elitist manner. -Another general problem that Sebestian's leadership had was, that everything +Another general problem that Sebastian's leadership had was, that everything was always *later*. You want X new feature added? Wait until after next release. When's the next release? Soon. That account of events is quite reductive, but it more or less sums everything up perfectly. The 2017-2021 leadership under @@ -950,7 +950,7 @@ to take it over myself at some point; but it was too complex. I would later take over the Libreboot project. This is what I will cover, in the next sections. Paul stopped working on Libreboot after around -late 2017, leaving the work solely in the hands of Andrew and Sebastien. +late 2017, leaving the work solely in the hands of Andrew and Sebastian. late 2020: osboot ================ @@ -1039,7 +1039,7 @@ project again in late December 2020. I was rapidly working on adding all the Libreboot boards to osboot, and I would have just very quickly updated the deblob scripts; I acted on this desire too soon, running under the gun. -I actually did remove Sebastien and Andrew's access to the Libreboot +I actually did remove Sebastian and Andrew's access to the Libreboot infrastructure, for a few hours, before re-instating them - I wasn't ready for a Libreboot takeover yet. I needed more time to polish everything. Doing a tiny release for 1 customer, on 1 machine (the X230) was all well and good, but @@ -1048,7 +1048,7 @@ I decided that I had time to polish it more. March 2021 Libreboot takeover ----------------------------- -I wanted to get rid of Sebastien and Andrew for some time, at that point. Too +I wanted to get rid of Sebastian and Andrew for some time, at that point. Too many years had gone by, without any releases in Libreboot, and the Paper build system was only growing more complex; it was completely unworkable, and their time was up. They failed. An unwritten rule in the new constitution of 2017 @@ -1072,7 +1072,7 @@ project; I actually did make some temporary releases of osboot (tarballs, with ROM images and source code) in December 2020, but deleted them, because they weren't intended for general use. I was only testing everything. -Sebastien had a lot of knowledge about hardware, but did almost no coding +Sebastian had a lot of knowledge about hardware, but did almost no coding himself; he left that all to Andrew. And Andrew hadn't done any substantial work in over 6 months at that time. And the work that was done, was still far from complete. I anticipated that there would be years left before the Paper @@ -1145,7 +1145,7 @@ I had started in osboot, but at that time still complying with the GNU Free System Distribution Guidelines, like 2016 Libreboot did. I did not use any of the work in the *Paper* re-write. I used precisely zero -lines of code from Sebastien and Andrew's work. I did it all myself. My decision +lines of code from Sebastian and Andrew's work. I did it all myself. My decision to take over the project had been vindicated. I did it for the users. People had been complaining for years about the lack of a release. The Libreboot project was dead. A joke to everyone, and it was no longer my fault; it was From 8f21d0625a88c107c9739c99555947af0deb640a Mon Sep 17 00:00:00 2001 From: Nicholas Chin Date: Thu, 14 Dec 2023 18:56:40 -0700 Subject: [PATCH 2/2] news/10.md: Fix capitalization of various proper nouns This fixes various names, trademarks, and other proper nouns according to how their associated owner/project/etc actually spells it. --- site/news/10.md | 54 ++++++++++++++++++++++++------------------------- 1 file changed, 27 insertions(+), 27 deletions(-) diff --git a/site/news/10.md b/site/news/10.md index 295cdbe..73bef06 100644 --- a/site/news/10.md +++ b/site/news/10.md @@ -103,7 +103,7 @@ mission today is exactly the same as it was then: to provide free boot firmware that normal people can easily use. Something that normal users don't have to think about, that *Just Works*, with regular updates. Clean, simple and professional, with clear documentation. Coreboot documentation today is -much better, but it was very poor quality in 2013 (mediawiki site with lots +much better, but it was very poor quality in 2013 (MediaWiki site with lots of errant pages, poorly organised). It came with a twist: Libreboot initially complied with the FSF's own RYF @@ -119,7 +119,7 @@ project, coreboot does require binary blobs on some boards. More on this later! Since the project was nameless until February 2014, early promotion of my work was talking only about my company and about the FSF endorsement of it; Minifree used to be called Gluglug, hosted at `gluglug.org.uk` (you can check it -in the wayback machine. The shop itself was on `shop.gluglug.org.uk`). For +in the Wayback Machine. The shop itself was on `shop.gluglug.org.uk`). For example, [this video](https://www.youtube.com/watch?v=08HKcH2GguE&t=1565s) talked about the ThinkPad X60 running Libreboot 20131212, but I only retroactively named that to Libreboot in February 2014, so that video is @@ -153,7 +153,7 @@ files behave similarly to BASH scripts, with similar syntax and overall logic flow/style. It is an extremely configurable bootloader. GRUB revolves around the shell, which is basically an extension of the Bash -shell, adapted for use in a multiboot context. GRUB is the reference multiboot +shell, adapted for use in a Multiboot context. GRUB is the reference Multiboot implementation, which boots Linux. Libreboot provides GRUB so that it can directly boot Linux kernels. GRUB has many advanced features, such as GPG and LUKS support, and it has support for virtually all of the major file systems in @@ -179,7 +179,7 @@ Libreboot's initial no-binary-blob policy meant that SeaBIOS could not be used. SeaBIOS then was the most popular payload, and the default one in coreboot, at least on x86. Although SeaBIOS is free software, it did not have a free video BIOS back then. Coreboot's native video initialisation was developed at around -that time, for intel video chipsets, providing a basic framebuffer, but no +that time, for Intel video chipsets, providing a basic framebuffer, but no video BIOS services, so operating systems like Windows could not boot (and they still cannot, on most Libreboot setups). @@ -189,7 +189,7 @@ on top of the coreboot framebuffer, but this capability did not exist in 2013 when Libreboot started. So, SeaBIOS could not be used in Libreboot then. Libreboot provided just the coreboot framebuffer, then loaded GRUB, which then loaded Linux; Linux itself could interact with the coreboot framebuffer, -and the intel video driver (`i915`) sets modes directly, so it doesn't need +and the Intel video driver (`i915`) sets modes directly, so it doesn't need BIOS INT10H or UEFI GOP services for video-related functions. In Linux, your video drivers just write to a framebuffer directly in memory. No abstractions. This feature, called KMS (Kernel Mode Setting) was later ported to the BSDs, @@ -348,7 +348,7 @@ like `me_cleaner` (which strips out code from the ME, usually leaving only the bringup code intact) existed. On the GM45 machines, [Intel ME](https://en.wikipedia.org/wiki/Intel_Management_Engine) is usually disabled on most vendors, but Lenovo provided it because their -machines came with Intel gigabit ethernet, which requires an Intel Flash +machines came with Intel Gigabit Ethernet, which requires an Intel Flash Descriptor and Gigabit Ethernet config in the flash; Intel's standard setup here is to then provide the Intel ME, in two separate versions: a 1.5MB version without [AMT](https://en.wikipedia.org/wiki/Intel_Active_Management_Technology), @@ -358,25 +358,25 @@ The X200 was always possible to use without Intel ME, because the ME only handled AMT and [TPM](https://en.wikipedia.org/wiki/Trusted_Platform_Module) on that platform, which are not required for boot, but the only known way at that time was to flash a *descriptorless* setup, which -meant that you would lose use of the Intel gigabit ethernet. This didn't seem +meant that you would lose use of the Intel Gigabit Ethernet. This didn't seem all that useful for Libreboot users, who expect everything to just work. Steve reverse engineered the Intel Flash Descriptor, finding disable bits in it that put the Intel ME into a permanent reset loop. In this configuration, the ME bootrom does not load any firmware from the flash. The full ME firmware otherwise goes in the main boot flash, alongside the BIOS software (e.g. -coreboot). In Libreboot, the intel ME firmware is excluded on GM45 hardware. +coreboot). In Libreboot, the Intel ME firmware is excluded on GM45 hardware. I worked with Steve between October 2014 to mid-January 2015. Steve provided -instructions for disabling the intel ME in the ICH9M flash descriptor, and +instructions for disabling the Intel ME in the ICH9M flash descriptor, and wrote a proof of concept utility that would take a *factory* ROM image dump, for instance X200 LenovoBIOS dump, and create a file containing just -the descriptor and gigabit ethernet config, but without the intel ME. That +the descriptor and Gigabit Ethernet config, but without the Intel ME. That utility was called *ich9deblob*. Under Steve's guidance, I wrote a utility that would *generate* an ICH9M descriptor from scratch. I then studied the datasheets for Intel's gigabit NIC, -writing a tool to generate the ethernet config from scratch. I had a new program +writing a tool to generate the Ethernet config from scratch. I had a new program written by around mid-January 2015, and I called it *ich9gen*. You can read about ich9gen and ich9deblob on the [ich9utils](../docs/install/ich9utils.md) page. The ich9gen utility was @@ -394,7 +394,7 @@ support was first added to Libreboot. Testing was later done on these other machines. In particular, Timothy Pearson (of Raptor Engineering) added support for switchable graphics, enabling video initialisation on versions of these boards that have both Intel and AMD graphics. Without such support, no video -init was available unless you used a board that only had the intel GPU. A +init was available unless you used a board that only had the Intel GPU. A hardware mux is present on the ones with AMD graphics, enabling you to still use just the Intel one, or switch to the AMD one. @@ -447,7 +447,7 @@ team lead by Mike Gerwitz. Libreboot's build system and documentation used a very peculiar design, which did not fit well into GNU's design policies. GNU had several technical -requirements for projects, such as use of TexInfo files for documentation, to +requirements for projects, such as use of Texinfo files for documentation, to be generated into HTML by a static site generator. At that time, Libreboot's website was written in static HTML, manually. It did not use a static site generator of any kind. @@ -717,7 +717,7 @@ which libreboot.org now uses. Alyssa acted as a sort of spokesperson during this period, acting in my place and I briefly gave her sysadmin privileges for the Libreboot hosting infrastructure, during that year (2017), because she was helping me improve my infrastructure - for example, she taught me how to -use nginx, where I'd previously used lighttpd as Libreboot's web server. +use Nginx, where I'd previously used lighttpd as Libreboot's web server. And that is the greatest irony of all. One of my main concerns about Libreboot's GNU membership was that I would lose control of the project, but I soon stepped @@ -741,7 +741,7 @@ GNU standards? I attempted to answer this, by actually doing it. I commissioned work, on the Libreboot mailing list (which existed at the time, and was hosted by GNU), to convert the website's static HTML files. Work was underway for converting the -entire documentation to TexInfo files, GNU's preferred format for documents. +entire documentation to Texinfo files, GNU's preferred format for documents. This was later scrapped, when I decided to accept Alyssa's work instead; she converted the website to use Markdown instead, with a custom static site generator. @@ -757,8 +757,8 @@ the [contrib page](../contrib.md). Paul's build system, the so-called *Paper build system*, was provided by him as a proof of concept. It initially only supported CrOS-based devices, for example -the ASUS Chromebook C201, integrating coreboot, depthcharge and various -chromeos utils that were needed. +the ASUS Chromebook C201, integrating coreboot, Depthcharge and various +ChromeOS utils that were needed. The goal of the build system re-write was to make Libreboot much more flexible and generally more configurable. Libreboot's build system *worked* very well at @@ -815,7 +815,7 @@ mentally and financially for gender reassignment surgery scheduled for late August 2018; then I spent a year recovering from that. And lots of other things. A lot of events, most/all of which won't be covered in detail here, were going on in my life, such that I never had the time nor mental energy to get involved -in Libreboot. And then the covid pandemic threw me off for a further year. I +in Libreboot. And then the COVID pandemic threw me off for a further year. I was planning a takeover of Libreboot in early 2020, but ended up doing it in 2021 instead. I had discussed the possibility publicly, several times during 2020, but nobody took me seriously at the time. @@ -894,7 +894,7 @@ utils (most of the C sloccount is ich9utils). If you actually look at the Paper system, almost all of it is covering utilities that don't need to be included in the project, many of them -chromeos-related; modern Libreboot (using my design, the lbmk build system), +ChromeOS-related; modern Libreboot (using my design, the lbmk build system), uses U-Boot, courtesy of work done by Alper Nebi Yasak (more on this later). I compile U-Boot with the *same* generic script that I maintain, which is less than 300 sloc in size, and compiles SeaBIOS, coreboot and U-Boot, without @@ -967,7 +967,7 @@ policy, since osboot later merged with Libreboot, in November of 2022, but it's the same policy that osboot used. I was commissioned by a Minifree customer to provide a ThinkPad X230. I already -knew then that the X230 (an ivybridge platform) could boot entirely blob-free +knew then that the X230 (an Ivy Bridge platform) could boot entirely blob-free in coreboot, except for the neutered Intel ME (using `me_cleaner`) and microcode updates. To my mind, it seemed acceptable in terms of software freedom. A solid, all-round very useful machine. @@ -990,7 +990,7 @@ and efficient. Thus, osboot was born. It initially began with Tianocore integrated in it, using MrChromebox's branch for coreboot. MrChromebox is a coreboot distro that -provides Tianocore as a payload, on many chromebooks, so I leaned on his +provides Tianocore as a payload, on many Chromebooks, so I leaned on his expertise to provide experimental Tianocore support, in my Libreboot 20160907 fork. I completely gutted about half of the build system in that Libreboot release, when forking it, because most of it no longer worked for modern @@ -1183,12 +1183,12 @@ it didn't hurt anything because Intel ME was always a problem. I didn't know ME neutering was possible, until I found out about `me_cleaner` - I would never provide anyone with a setup that uses a non-neutered ME, because of the networking and backdoors provided in such setups. The `me_cleaner` project removes such -backdoors from the intel ME, resulting in a clean image that only contains the +backdoors from the Intel ME, resulting in a clean image that only contains the init firmware in the ME. In this configuration, the ME initialises itself but doesn't actually run anything, so it just sits there permanently in the init stage. Things like AMT no longer work, when you run `me_cleaner`. -To put it simply: at least on the intel side, `me_cleaner` changed everything +To put it simply: at least on the Intel side, `me_cleaner` changed everything and opened up a lot more machines for me. But to do that, I had to abandon Libreboot policy. Hence, osboot was born. Libreboot policy was a liability to the free software movement, because it limited the amount of free software that @@ -1288,7 +1288,7 @@ down. That almost never happens, as the FSF tends to be extremely dogmatic, too drunk on their own prestige; set in their ways. They initially hosted their project on the official sourcehut instance run by -Drew Devault. I simply asked Drew to terminate their hosting. He complied. He +Drew DeVault. I simply asked Drew to terminate their hosting. He complied. He gave them two weeks to rename their project, or be deleted, and they did not rename. Their website was hosted on sourcehut at the time, so their website went offline for a day; on that same day, I announced the [Libreboot @@ -1379,11 +1379,11 @@ code is now used by Libreboot, to provide serprog firmware on many STM32- and RP2040-based microcontroller boards; we use them as SPI flashers, but you can use them for many other purposes. They're quite handy little machines. The serprog firmware integration was done by Riku Viitanen, who also added many -HP Elitebook machines to Libreboot during 2023. +HP EliteBook machines to Libreboot during 2023. Thanks to the work done by Nicholas Chin, several Dell Latitude laptops are now supported in Libreboot, which can be flashed without disassembly. We support -GM45 and Ivybridge models, and we're adding many more (we have identified +GM45 and Ivy Bridge models, and we're adding many more (we have identified about 20 of them). You can actually just read the Libreboot release announcements from 2023, if @@ -1417,7 +1417,7 @@ FSDG is the policy that GNU Boot uses, that Libreboot previously used, before it adopted the modern [Binary Blob Reduction Policy](policy.md) - GNU Boot started, specifically because it opposed the new policy in Libreboot. -Well, GNU Boot seemed to be going nowhere fast. I monitor their git activity +Well, GNU Boot seemed to be going nowhere fast. I monitor their Git activity daily, and their development pace is much slower than mine; slower than mine, even when I'm going slow. I thought to myself: what if a *competently* engineered solution existed, like GNU Boot but not?