wait what? using a whole linux kernel as firmware before booting another OS to improve speed, reliability, security? does this seem strange to anyone else?
https://schd.ws/hosted_files/osseu17/84/Replace%20UEFI%20wit...
(The video of the presentation is linked in the OP).
There's already two and a half obscure OS's running underneath the OS for booting. So this replaces all that crap with something lean and good.
I think the concern is about "lean". I don't think there's a lot of code yet, but I do see it will use http://u-root.tk/.
When there is a build system, you'll be able to choose whatever initramfs you want to implement your boot policies. The two choices we have today are NERF (= LinuxBoot + u-root as initramfs, as you linked) and Heads (LinuxBoot with Heads kernel and runtime, see http://osresearch.net).
Heh, that gave me a chuckle
> Userland written in Go (http://u-root.tk)
So much for Go not being a systems programming language.
There are other examples already.
Fuchsia TCP/IP stack and file system driver management utilities are implemented in Go.
https://groups.google.com/d/msg/golang-dev/2xuYHcP0Fdc/tKb1P...
Android's new GPU debugger is written in Go.
https://github.com/google/gapid
An then there are some bare-metal experiments like G.E.R.T.
(I was going for a tongue-in-cheek ribbing of the Go-haters - in retrospect my wording sounds a bit passive-aggressive, probably should have ended with an exclamation mark and a smily or something)
I love it is based on a mix of Oberon and Limbo, compiled to native code and an improvement for what a safe C like language should probably look like, and who knows maybe someone decides a day to do a "Goberon" OS for they OS PhD research.
Basically what Java and C# 1.0 should have been all along, about 20 years ago.
However I also dislike some of the design decisions regarding features that will never come to Go, regardless of how much we get to discuss them, even with the mirage of Go 2.0.
It is possible for *nix to be very minimal, less so than in the old days, of course. But speaking of the old days, when I earned my bread as a CPU logic designer, I recall one grizzled OS developer's reaction to the looooong errata list for the A0 stepping of some new silicon: "Pffft. I can bring up Unix on a broken washing machine."
Obviously it's a heavy weight solution, but the idea of having more drivers and better support is compelling— it's a much easier path to exotic boot setups, eg over wifi, off a SAN, whatever.
UEFI DXE loads disk/network -> Linux
We're doing Linux (with commonly used open source drivers)-> Linux
It's possible that if your end goal is a Linux system without too many requirements, you could stop at the first Linux system without ever booting the second. However the bios rom memory is pretty small, and we're mostly working with about 4-8mb of free space left not including the ME region or UEFI PEI.
Someone did that! Well, something like it, anyway.I have an Asus EeeBox sitting on my desk, gathering dust, that has something called "SplashTop" - if I hit the right key during the POST screen, it boots into a minimalistic Linux desktop in about 2 seconds.
There is networking and a browser. I haven't used it in ages, but I think the problem was that it could not access the file system, so one could not do very much, and I think settings did not persist across reboots. But the general idea seemed appealing at the time.
But EFI can be implemented by others. Including U-boot! Which is really lightweight.
So...this is strictly my own personal experience, but, I've always had better compatibility with my hardware in the BIOS than I have had in any OS. I can't count the number of times my K/V/M has worked in the BIOS, then suddenly stopped working once DOS/Windows/Linux started booting.