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

@@ -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?