tamago VS gokrazy

There's two major production-ready Go-based operating system(-ish) projects:

- Google's gVisor[1] (a re-implementation of a significant subset of the Linux syscall ABI for isolation, also mentioned in the article)

- USBArmory's Tamago[2] (a single-threaded bare-metal Go runtime for SOCs)

Both of these are security-focused with a clear trade off: sacrifice some performance for memory safe and excellent readability (and auditability). I feel like that's the sweet spot for low-level Go - projects that need memory safety but would rather trade some performance for simplicity.

[1]: https://github.com/google/gvisor

[2]: https://github.com/usbarmory/tamago

Of course it can, there are companies shipping products written in bare metal Go.

https://www.withsecure.com/en/solutions/innovative-security-...

https://github.com/usbarmory/tamago

For comparison, what are the differences in goals and approach with Tamago? https://github.com/usbarmory/tamago

I've been keeping an eye on TinyGo (Go compiler that targets microcontrollers and uses LLVM) and also TamaGo (allows you to run Go on bare metal, without any C dependency).

If you want to go deeper, there is also bare-metal Go runtime for rpi (among others): https://github.com/f-secure-foundry/tamago

> just proves your lack of knowledge

Tone is not needed.

For TamaGo, it seems to allow developers run their application, not build an OS on the hardware. But I have not played with it, you are right.

> TamaGo is a framework that enables compilation and execution of unencumbered Go applications on bare metal

The environment does not seem to allow building a generic operating system [1]. F-Secure ported the runtime itself to boot natively. But please correct me.

> There is no thread support

The environment you run in is specifically curated for Go applications, such as the memory layout. I'd call this an "appliance" rather than enabling Go to be used for full-fledged generic operating system implementations.

[1] https://github.com/f-secure-foundry/tamago/wiki/Internals

Switching to gokrazy[0] was the best thing I did for my Raspberry Pi uptimes. I think a lot of that is because it defaults to using read-only partitions so the common issue of SD cards falling over when you run apt upgrade no longer happens.

But I also think that gokrazy's simplicity and design helps it be just a solid, reliable foundation to build on top of.

[0]: https://gokrazy.org/

The idea there sounds a lot like https://gokrazy.org/, which builds a minimal go userland, wrapping one or more user provided go applications, and bundles in a linux kernel.

Targets mostly at single board computers, and I think it downloads pre-built kernels (and bootloaters if needed), rather than trying to build them directly, since getting a working cross compilation toolchain set up and plumbed into the kernel compilation process is still a pain.

I've personally only used yocto/open-embedded for that which does nicely handle building the cross-compilation toolchain, kernel image, and modules. But it is kinda overkill for that task, being designed to build a whole userland too.

reminds me of https://github.com/gokrazy/gokrazy which does similar things.

https://gokrazy.org/ would like a word

Fun! We have support for running on gokrazy (https://gokrazy.org/) already, and that's probably where Unikernel Linux is more applicable for us, for when people just want a "Tailscale appliance" image.

I'll email you.

gokrazy exists! https://github.com/gokrazy/gokrazy

https://github.com/gokrazy/gokrazy for one example