Gokrazy – A Native Go Userland

Gokrazy – A Native Go Userland(gokrazy.org)

160 points by robfig 4 years ago | 31 comments

dang 4 years ago |

A couple past threads:

Gokrazy: a pure-Go userland for Raspberry Pi 3 appliances - https://news.ycombinator.com/item?id=20357605 - July 2019 (9 comments)

Gokrazy: A pure-Go userland for Raspberry Pi 3 appliances - https://news.ycombinator.com/item?id=16672866 - March 2018 (87 comments)

cedws 4 years ago |

gokrazy is a very cool project and something I'd like to see more of. It's not a unikernel per se but it shares the idea of packaging your code and the OS together and shipping it as one. My dream would be a pure Go userspace library to do absolutely anything related to system management you'd need, like managing networking, connecting to Wi-Fi access points, performing upgrades and so on. But it's such a massive undertaking so we're stuck depending on software written in C via FFI or exec'ing shell commands -- pretty gross.

jonpalmisc 4 years ago | |

I run into this often and share the same desire. I quite like Go, but unfortunately the interaction of "my interests" (such as the userspace library you suggested) and "things Go excels at" isn't very large. Having to do everything important through FFI or shell commands defeats the purpose of writing Go, imo.

hnlmorg 4 years ago | | |

If it is any help, I've written a $SHELL in Go and have been using it as my primary shell for around 5 years now. So while it's still largely Beta it is pretty stable these days.

It's intentionally not designed to be a drop in replacement for Bash though. I saw no point replicating all of the problems with Bash when writing a new shell. So it does a lot of things different -- better in most cases -- but that does also create a learning curve too (I mean you're literally learning a new language).

https://github.com/lmorg/murex

throwaway894345 4 years ago | | |

You don’t have to. Go can make syscalls directly, and it even lets you drop into assembly directly similar to Rust, etc.

hamburglar 4 years ago | | |

Gokrazy doesn't expect you do to anything through FFI or shell commands, though. The whole idea is you write your entire app in Go. The kernel, the Go runtime, and a little bit of gokrazy utility/glue code (e.g. bringing up the network and doing DHCP) are the entire platform.

Edit to add: it would actually be difficult to do FFI or shell commands within gokrazy since there's no dynamic loader to resolve external symbols when you try to execute a dynamically linked library or program. You'd have to add this feature if you wanted to call out to anything built with a dynamically loaded C runtime (which is damn near everything these days, with one notable exception being Go executables built without CGO).

cpach 4 years ago | | |

There’s always Rust (^_^)

dingdingdang 4 years ago |

Be interesting to have at least a few benchmarks to see if cutting so much of the regular distro code actually has a positive impact beyond the idea of it being more reliable. And that last bit does seem to remain an idea rather than a reality in that quite a lot of regular userland code (systemd comes to mind) helps stabilise a running linux box over time in a very real way. Personal exp incl having several headless Ubuntu boxes run for more than a year with zero issues despite being saddled with typical server lamp server stack.

All up for trying this though and can definitely see real bonus in terms of less resource use within Pi envs!

francislavoie 4 years ago |

FWIW, Caddy would probably work with this, if you need a web server.

Caddy is pure Go, no CGO. We did a bunch of work recently to ensure that none of the dependencies have any CGO code enabled (involved asking upstream dependencies to switch to pure alternatives).

secure 4 years ago | |

It definitely works with gokrazy, we even have a guide for it: https://gokrazy.org/userguide/install/caddy-http-server/

francislavoie 4 years ago | | |

Awesome! Thanks for sharing!

wishinghand 4 years ago |

I’m too rudimentary of a developer. What’s a Userland? What is this doing that writing apps as Go executables doesn’t or can’t do?

tyingq 4 years ago | |

Maybe the easiest way to visualize it is that there is no filesystem at all. No shell, no "libc", no "ssh into the machine", no "cp", "mv" "ls", etc.

They do provide a way to get one filesystem in place, but you can only interact with it using golang calls within your application.

hamburglar 4 years ago | | |

"no filesystem" does not fit into this list of things. There is definitely a filesystem. It has an optional sshd, and an optional shell that includes cp, mv, ls, etc, but there is always a filesystem.

cpach 4 years ago |

Very interesting project.

Has anyone tried it?

Apparently they have written their own init: https://gokrazy.org/userguide/process-interface/

This makes me curious. I wonder how well Gokrazy would blend with s6/s6-rc…

If anyone is curious there’s more info about those projects here:

https://skarnet.org/software/s6/

https://skarnet.org/software/s6-rc/

hamburglar 4 years ago | |

I’ve tried it. It’s very neat. I wrote a PoC music player on it and it boots up and begins playing music in about 4 seconds if I recall. Has a neat optional web-based service control UI that lets you see the logs and stop/start the “services.” Has a cool dual-boot-image scheme so you can boot a new one and roll back to the old one if needed (takes double the space on the boot drive but it’s still pretty small).

It’s still kind of a toy, however. There is no C runtime, and the maintainer has declared that there never will be (part of the point of the project is not worrying about that kind of complexity) so including anything C-based is going to be an adventure/unsupported. And the maintainer’s use case is custom built personal servers, so he is explicitly ok with, for example, having to hardcode your wireless config because there is no (and apparently never will be) a wpa_supplicant.

But if it had a golang wpa_supplicant implementation and a graphics library (I’ve done a little fb drawing on it and it works but it really needs acceleration) it would make a really nifty platform for little devices with an HDMI UI.

secure 4 years ago | | |

Hello, I’m the maintainer!

You’re right about the lack of a C runtime being intentional. However, C programs can be run if you take on the task of keeping them up-to-date: https://gokrazy.org/prototyping/

Regarding WiFi, we have https://github.com/gokrazy/wifi which currently only works for unencrypted WiFi. If at some point there is a Go solution to configure encrypted WiFi, I’m all for it!

rockwotj 4 years ago |

If you're a fan of this approach to deploying applications and use docker, distroless [1] is a really cool project related to this. It uses debian as the base and supports cgo because it has glibc (and openssl)

[1]: https://github.com/GoogleContainerTools/distroless

jchw 4 years ago | |

Relatedly, there's also buildkit[1] and that entire ecosystem. I've been meaning to check out the experience of building containers using Nix, but either way it seems very interesting.

[1]: https://github.com/moby/buildkit

matthewfcarlson 4 years ago |

It seems like a video output isn’t as much a priority. I’ve been looking at creating a raspberry pie powered arcade machine and I need it to be 100% reliable. A user land implementation seems like a good compromise over a bare metal application.

exdsq 4 years ago | |

Why do you need that level of reliability - is it for potentially commercializing the machine? Sounds like a cool project :)

ed25519FUUU 4 years ago |

No CGO is hard because that means I can’t use SQLite libraries. This has been a continued frustration to me when writing portable Go apps.

allset_ 4 years ago | |

There's a new(er) fork that doesn't use CGo.

https://github.com/zombiezen/go-sqlite

jyap 4 years ago | |

I switched to modernc.org/sqlite. No GCC required. Drop in replacement.