Announcement

Collapse
No announcement yet.

LinuxBoot Continues Maturing - Now Able To Boot Windows

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • SystemCrasher
    replied
    Originally posted by shmerl View Post

    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.
    Last edited by SystemCrasher; 15 November 2019, 01:01 AM.

    Leave a comment:


  • SystemCrasher
    replied
    Originally posted by ihatemichael View Post
    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.

    Leave a comment:


  • shmerl
    replied
    Originally posted by davidhendricks View Post
    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.

    Leave a comment:


  • davidhendricks
    replied
    Originally posted by shmerl View Post
    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 ;-)
    Last edited by davidhendricks; 14 November 2019, 12:42 PM.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by ihatemichael View Post
    How is this different from something like coreboot?
    Coreboot is low-level board initialization. When it has done the job it will load and execute a payload, SeaBIOS, Tianocore (UEFI), or hardcoded GRUB load or whatever.
    Currently, coreboot is mostly an empty shell as the board initialization is done by vendor blobs, Intel FSP or AMD's equivalent.

    linuxboot is a payload. It can be loaded by coreboot or by proprietary board init blobs and is much simpler, safer and infinitely more powerful than commercial UEFI firmware.

    the "it has a chance for adoption" said by the other user means that this can be relatively easily retrofitted to a board without knowing secret OEM information, it's just a matter of opening the stock UEFI firmware image with UEFI developer tools, removing all unnecessary components so only low-level board initialization parts remain, and then hook Linuxboot to them, then flash that back to the board firmware chip.
    Last edited by starshipeleven; 13 November 2019, 09:18 PM.

    Leave a comment:


  • anarki2
    replied
    Originally posted by ihatemichael View Post
    How is this different from something like coreboot?
    It has a chance for adoption.

    Leave a comment:


  • ihatemichael
    replied
    How is this different from something like coreboot?

    Leave a comment:


  • pal666
    replied
    Originally posted by shmerl View Post
    A bit surprising they are using Go for systems programming, instead of a lot more appropriate Rust for it.
    it's scripting, not systems programming. remember, they were using shell for it since beginning. and of course there are more appropriate languages for systems programming

    Leave a comment:


  • onicsis
    replied
    Step number ZERO: dumping unsafe C to learn Golang

    Leave a comment:


  • MrMorden
    replied
    Originally posted by shmerl View Post
    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.
    TinyGo can compile Go code to AVR8. It's amazing what you can do these days.

    Leave a comment:

Working...
X