Gokrazy – A Native Go Userland(gokrazy.org)
gokrazy.org
Gokrazy – A Native Go Userland
https://gokrazy.org/
31 comments
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.
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.
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
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
You don’t have to. Go can make syscalls directly, and it even lets you drop into assembly directly similar to Rust, etc.
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).
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).
There’s always Rust (^_^)
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!
All up for trying this though and can definitely see real bonus in terms of less resource use within Pi envs!
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).
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).
It definitely works with gokrazy, we even have a guide for it: https://gokrazy.org/userguide/install/caddy-http-server/
Awesome! Thanks for sharing!
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?
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.
They do provide a way to get one filesystem in place, but you can only interact with it using golang calls within your application.
"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.
https://en.wikipedia.org/wiki/User_space#Overview says:
“The term userland (or user space) refers to all code that runs outside the operating system's kernel.”
I see a difference between userland and user space. For userland I would add “and that’s needed to bring the OS to a usable state”. You need code that is triggered when an USB device is plugged in, tools to query what hardware is available, tools to format disks, etc.
“Usable state” is up for discussion, though. For example, I don’t think X11 or Wayland are needed, but opinions on that will vary. That may be why the table in the link I gave has parts shaded yellow.
I don’t think (but Wikipedia disagrees with that by making user space and userland synonymous) anybody calls QT, the Gimp or Open Office part of userland, even though they run in user space.
“The term userland (or user space) refers to all code that runs outside the operating system's kernel.”
I see a difference between userland and user space. For userland I would add “and that’s needed to bring the OS to a usable state”. You need code that is triggered when an USB device is plugged in, tools to query what hardware is available, tools to format disks, etc.
“Usable state” is up for discussion, though. For example, I don’t think X11 or Wayland are needed, but opinions on that will vary. That may be why the table in the link I gave has parts shaded yellow.
I don’t think (but Wikipedia disagrees with that by making user space and userland synonymous) anybody calls QT, the Gimp or Open Office part of userland, even though they run in user space.
QT, Gimp and Open Office are 100% considered userland. I'd be surprised if you could find very many people who disagree.
Until someone more experienced than me comments: The userland is the collection of programs and functionality that run outside of the kernel. AFAIK you need some things (but I'm not sure which) apart from the kernel if you want to run your executables, and it looks like Gokrazy provides those.
To clarify a bit, you don’t need additional things to run your executables per se (for example, pure Go binaries can run directly on the Linux kernel) but there are a lot of utilities that you will probably want—things like a process manager, SSH daemon, a shell, etc. These are all userland components.
To expand on this, it means that once the kernel is done booting, the first (and only) program it will start is the bundled go-written application. This differs from the usual chaining to the "init" (like systemd) process, which would then spawn a myriad of other programs.
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/
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/
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.
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.
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!
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!
I use it to run internal services I don't want going down when I'm messing around in the homelab. Namely: internal DNS, MQTT broker and various prometheus pollers (e.g. unifi-poller). I'm a big fan of this project.
Do you have a blog article or so that describes this in more detail? It sounds interesting!
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
[1]: https://github.com/GoogleContainerTools/distroless
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
[1]: https://github.com/moby/buildkit
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.
Why do you need that level of reliability - is it for potentially commercializing the machine? Sounds like a cool project :)
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.
There's a new(er) fork that doesn't use CGo.
https://github.com/zombiezen/go-sqlite
https://github.com/zombiezen/go-sqlite
I switched to modernc.org/sqlite. No GCC required. Drop in replacement.
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)