LinuxBoot Continues Maturing - Now Able To Boot Windows

[davidhendricks]

A bit surprising they are using Go for systems programming, instead of a lot more appropriate Rust for it. No heavy runtime should be an important factor for tiny firwmare.

The idea of LinuxBoot is simply to use Linux as your bootloader. U-root is one possible environment you can use, but if there is a similar set of tools written in Rust that you prefer to use, more power to you :-) Heads developers are also part of the community, and they use Busybox.

U-root has existed since 2012 and is pretty far along. Go is easy to learn, easy to use, and is a fairly natural progression from C (it doesn't sacrifice things like types and pointers like some other modern languages). It works well for standalone programs and as a scripting language - Writing simple, safe C code and shell scripts is very difficult, doing everything in Go makes life a lot easier.

I don't know a whole lot about Rust, but for what it's worth the same people hacking on LinuxBoot are also working on Oreboot (https://github.com/oreboot/oreboot) which is a fork of coreboot written in Rust. If you'd like to contribute an embedded environment like u-root that's written in Rust I'm sure the team would appreciate it ;-)

[shmerl]

Go is easy to learn, easy to use, and is a fairly natural progression from C (it doesn't sacrifice things like types and pointers like some other modern languages)

I wouldn't call it a natural progression from C due to runtime and garbage collector. Natural progression from Java or Python - may be. Natural progression from C and C++ is Rust Different language core design ideas and goals. I.e. I'd call C, C++ and Rust systems programming languages. But not Java and Go.

[SystemCrasher]

How is this different from something like coreboot?

It differs in conceptual level. Look, most modern boot loaders overgrown into what can be classified as crippled version of OS. Basically, things like u-boot, GRUB, Coreboot, UEFI and so on tend to provide OS-like facilities, like accessing file systems, loading extra modules/programs, using some "drivers" and so on. And if someone really wants it to be OS in that place... needless to say, real OS does OS's job much better than crippled replacements. Say, being able to access far more file systems in a fully featured fashion, or sporting multitasking/threading/async IO or so - well, imagine you want to display nice progress and interact with user while, say, reading large file. That rather painful if you only got 1 thread/task since you have to interleave IO and user interaction yourself. Or user interaction stuck while IO is performed. Which doesn't feels that good if someone serious about pretending to be full fledged OS-like environment.

[SystemCrasher]

I wouldn't call it a natural progression from C due to runtime and garbage collector. Natural progression from Java or Python - may be. Natural progression from C and C++ is Rust Different language core design ideas and goals. I.e. I'd call C, C++ and Rust systems programming languages. But not Java and Go.

Next logical step to such "progression" could be, say, wearing some pampers or so all the time. Just to be on safe side, blah-doh.


p.s. on side note I wonder how they booted Windows and if one can also kick e.g. "firmware" part that way. Say, 64-bit ARMs may want TrustZone spftware upload before starting OS. Boot loaders like u-boot take care of that... I wonder if Linux can do smth like this. Kexec syscall on its own currently isn't terribly versatile.