Intel does have https://www.clearlinux.org/

At least they don’t suffer from a lack of onboarding paths for x86, and it seems they are doing a nice job with their dGPUs.

Still unforgivable that their new CPUs hit the market without excellent Linux support.

+1, especially the 'Grand Inquisitor' portion. And a close 2nd would be Dostoevsky's "Crime and Punishment.'

This article is a nice addition to the community since rarely is a complete rewrite of a firmware corpus possible. Speaking of Rust and host or boot firmware, the recently published https://techcommunity.microsoft.com/t5/surface-it-pro-blog/s... provides a nice experience report. Other work on moving Rust into EDKII for UEFI style firmware https://github.com/tianocore/edk2-staging/tree/edkii-rust is described in https://uefi.org/sites/default/files/resources/Enabling%20RU... and https://cfp.osfc.io/media/osfc2020/submissions/SLFJTN/resour.... There's also guidance on Rust for firmware in a book chapter https://link.springer.com/chapter/10.1007/978-1-4842-6106-4_....

This is a good read. Dr. Blaise Agüera y Arcas was a keynote speaker at https://attend.ieee.org/newera/program/ here in Seattle a week ago but he didn't really get a chance to delve deeply into his position. During his slot there ended up being a lot of back-and-forth about whether AGI truly achieved or just seeing ACI, etc, among the folks from MS, Meta, Google, UW, and even https://www.dia.mil/ rep.

"Universal" is also a term that doesn't typically engender happiness in technologists.

Universal has been part of the definition of modernism. One can always critique a modern effort on the scale of universality.

Modernism grew out of post world war 1 optimism for a universal humanity.

In Ocaml, interesting. I was similarly surprised when I learned that the firs Rust compiler was written in Ocaml, too https://users.rust-lang.org/t/understanding-how-the-rust-com...

ML (short for "meta-language") was originally designed for use in programming language research, and really shines for that purpose. And OCaml is probably the most pragmatic dialect for the purpose.

SML is very dated and the standard library and ecosystem lack many things that are considered table stakes for a viable programming language nowadays. And F# and Scala are fine as enterprise languages, but being tied to .NET and Java respectively makes them less desirable for implementing a language that won't itself be coupled to one of those runtimes.

Tree processing is best done in a language with decent algebraic datatypes and pattern matching. I would’ve preferred Standard ML, but, well, pot-ay-to, pot-ah-to. Haskell is another choice but the techniques you need to use there (while undeniably gaining you some possibilities) don’t really generalize to other languages, so you’re now writing a book about compiler construction in Haskell rather than just compiler construction. Ditto for Rust. Kotlin has deliberately anemic pattern matching. C# or F# leave you depending on Microsoft’s benevolence (sic). Metalua and Sweet.js both have decent ADT support but both are pretty much dead. Racket exists, I guess, and there are some pattern-matching libraries for normal Scheme as well, but the charisma malus of the parenthesis is real even if I don’t understand what causes it.

So OCaml was probably the most mainstream choice among the languages with appropriate tools, as funny as that sounds. And honestly, once you get over the syntax, it doesn’t actually have anything outrageous.

This reminds me of the saying https://en.wiktionary.org/wiki/success_has_many_fathers,_fai... that I’ve seen often played out in big companies, too.

There is still support for CSM in the open source https://github.com/tianocore/tianocore.github.io/wiki/Compat... and even nice projects like https://github.com/coreboot/seabiosto fabricate the CSM16 binary, but many vendors have stopped validating this path, including production of legacy BIOS option roms for adapters (net, gfx, etc) https://www.phoronix.com/news/Intel-Legacy-BIOS-EOL-2020. I still believe CSP's maintain some of this support in their hypervisors' guest firmware for legacy OS binaries/ISO boot support? Also since Windows requires UEFI Secure boot enabled by default and CSM has to be disabled for the UEFI secure boot path, this is another reason legacy BIOS boot isn't exercised so much these days. We could have added legacy oroms hashes to UEFI Secure boot implementations https://patents.google.com/patent/US8694761B2/en, too, but again folks pushed back in their zeal to remove legacy BIOS overall. We didn't add the CSM spec https://www.intel.com/content/dam/www/public/us/en/documents... to the PI https://uefi.org/specs/PI/1.8A/ since folks were hoping UEFI would remove the need for CSM. I still remember being challenged in the early 2000's by a long-time BIOS mgr at Intel "Is removing legacy a good idea with EFI? You know, we're really at legacy."

Fascinating work. The ARC std https://en.wikipedia.org/wiki/ARC_(specification) was used to boot the Dec Alpha Windows machines, along w/ MIPS, etc. Anyone know of other open source variants of that in the wild? At intel in 1998 the original efi spec was modeled on & inspired by Arc. The Intel boot initiative (IBI) in fact looked mostly like Arc. EFI (now UEFI) is sort of Arc + installable GUID-based interfaces (aka protocols) a la MS COM https://en.wikipedia.org/wiki/Component_Object_Model. Page 8 of https://www.intel.com/content/dam/www/public/us/en/documents... recounts some of those travails.

My roommate's Alpha had the SRM firmware which he used to boot NetBSD. ARC would boot NT but SRM could not.

https://en.wikipedia.org/wiki/SRM_firmware

Seems to be a trend including work like https://www.linuxboot.org/.