| ▲ | Go-boot: bare metal Go UEFI boot manager(github.com) |
| 74 points by nateb2022 6 days ago | 23 comments |
| |
|
| ▲ | tuananh 10 minutes ago | parent | next [-] |
| There's also Sprout by Edera https://github.com/edera-dev/sprout > Sprout: UEFI Bootloader in Rust |
|
| ▲ | pizlonator 11 minutes ago | parent | prev | next [-] |
| The TamaGo project (which this uses for running on bare metal) looks super impressive! Kudos to the authors for getting this working. I wonder what GC changes had to be made, if any. I wonder if it supports multiprocessing. |
|
| ▲ | Imustaskforhelp 6 days ago | parent | prev | next [-] |
| I really like this idea but can anyone please summarize what it does for me. To me it feels very fascinating (bare metal golang in general) but I am not sure I truly understand its usecase and I would love to know more. |
| |
| ▲ | pjmlp 6 days ago | parent | next [-] | | The use cases is not writing unsafe C in first place, and proving the point Go is usable in such scenarios, regardless of naysayers. The creators of USB Armory also created TamaGo, instead of using Rust, exactly for the same reasons, to prove a point. https://github.com/usbarmory/tamago https://reversec.com/usb-armory/ Because in IT, seeing is believing. | | |
| ▲ | xyse53 5 days ago | parent | next [-] | | It's also a good way to learn about UEFI for people most familiar with go. | |
| ▲ | qhwudbebd 6 days ago | parent | prev | next [-] | | Quite apart from that, an EFI shell that's less awful than the standard UEFI one is an interesting project in its own right... | |
| ▲ | bradfitz 5 days ago | parent | prev | next [-] | | I've been idly following this stuff on & off for years, but I never saw proving a point "instead of using Rust" as one of the motivations of the project. Was that ever stated anywhere? | | | |
| ▲ | guywithahat an hour ago | parent | prev | next [-] | | That's a shame, I was hoping it would be so I could boot thousands of kernels in parallel at once | |
| ▲ | flanked-evergl 3 hours ago | parent | prev | next [-] | | No amount of proven points will give Go null safety, though. | |
| ▲ | schmuckonwheels 3 hours ago | parent | prev [-] | | If one can't write safe C code, then maybe stick to web development and leave the bootloaders and UEFI stuff to people who can. Training wheels are merely a race to the bottom for barely-literate programmers. | | |
| ▲ | monocasa 3 hours ago | parent | next [-] | | The number of memory safety CVEs written in C by people who ostensibly 'didn't need training wheels' point strongly to the antithesis of your argument. And I say that as someone who's been a kernel engineer for 20 years. | |
| ▲ | throwaway894345 36 minutes ago | parent | prev [-] | | There are only people who think they can write safe C code and those who know they can’t. |
|
| |
| ▲ | tomcam 5 days ago | parent | prev | next [-] | | When you turn on a computer, it transfers code to software required to get the machine up and running reliably--the boot process. That used start in a chip called the BIOS. It's a 40-year old holdover from the early days of the IBM PC. UEFI is a more complex and feature-rich protocol. Due to its default memory management Go hasn't been considered the first choice for such purposes but this proof of concept uses Go for the very low level code needed for UEFI. | | |
| ▲ | reactordev 4 hours ago | parent [-] | | “Due to its garbage collection” you mean. There’s nothing stopping you from writing go for bare metal, only your pride. |
| |
| ▲ | techgnosis 5 days ago | parent | prev | next [-] | | There aren't that many UEFI shells and the ones that exist are certainly not modern. Anything new is helpful, especially if its written in a popular language like Go. | |
| ▲ | typical182 4 hours ago | parent | prev [-] | | There’s some more context in a proposal from the folks behind this project to upstream the needed Go runtime hooks into Go proper. From what I can tell, the core Go team seems generally favorable to it, so seems like a decent chance it will happen. From: #73608 proposal: all: add bare metal support https://github.com/golang/go/issues/73608 > Go applications built with GOOS=none would run on bare metal, without any underlying OS. All required support is provided by the Go runtime and external driver packages, also written in Go. And: > These hooks act as a "Rosetta Stone" for integration of a freestanding Go runtime within an arbitrary environment, whether bare metal or OS supported. | | |
|
|
| ▲ | hulitu 3 days ago | parent | prev | next [-] |
| > Go-boot: bare metal Go UEFI boot manager The bare metal list is quiet thin. Why is so HW focused ? I use refind and it seems to be HW independent. |
|
| ▲ | Eduard 3 hours ago | parent | prev | next [-] |
| missed chance to name it Goo-Boot |
|
| ▲ | seanw444 5 hours ago | parent | prev [-] |
| As much as I appreciate Go, putting it on bare metal makes me cringe a little. |
| |
