omnios-build VS musl-cross-make

key features at OmniOS Community Edition

OS Challenge: Try out an Illumos (OpenSolaris) image in a VM (there are Solaris kernel options available in Proxmox). If you want something fun, install OmniOS and create a Linux zone on it. So cool to run Linux on Solaris. https://omnios.org/

While UTM is much better at resource usage, it's not perfect. Virtualbox seems to emulate more of a system instead of passing it through to the hypervisor and so is better for running more unusual OSes. I have two VMs there running Illumos which I have yet to figure out how to boot in UTM. A problem that I think is related to UTM's greater use of the hypervisor is that you can't suspend and resume VMs that use it instead of being emulated, so I've still got a few VMs hanging around in Virtualbox which spend most of their time suspended. Finally, what stops me from using UTM at work is that you can't use it as a Vagrant provider. This is incredibly annoying, as the lack of a decent virtualization application makes the otherwise very nice M1 Macs nothing more than pretty toys. I expect that this glaring lack will be fixed within the next couple of years.

Can anyone recommend a good place to start learning OmniOS? Coming from Debain world. Other than the documentation on omnios.org, I only found a few blog posts here and there...

OpenIndiana is pretty neat. It has quite a few cool features like Zones, DTrace and Crossbow. ZFS is another big feature but you have already said that you don't really care about that. Hardware support is kinda lacking, but improving. Also it's rolling release so if you're like me and don't like that, OmniOS might be a better option; it's another illumos based OS.

I've done the same alpine trick for static binaries but may I introduce you to musl-cross-make?

https://github.com/richfelker/musl-cross-make

Just burned out static toolchains that make me static binaries for all architectures gcc supports. Much like musl.cc but they suggest building your own and I do.

I use these toolchains on debian (/ anywhere a non-ancient linux kernel runs) to make static binaries, you can too!

Python obviously isn't 14kb because its code is divided into hundreds of shared object files. So the way I like to measure things is using static executable size, using tools like https://github.com/jart/cosmopolitan or https://github.com/richfelker/musl-cross-make of which you'll find a static build in the cosmo repo. For example, here's the technique I used to build TinyLISP was something like this:

I have a different issue with ring. This is on a custom Cortex A9 board at work. For most depedencies I can get compilation working fine with armv7-unknown-linux-musleabihf. I was able to build the cross compiler using https://github.com/richfelker/musl-cross-make , adding

A bit off topic, I hope someday GCC's build system gets overhauled. A huge advantage of LLVM is that it is quite easier to rebuild the runtime libraries without rebuilding the compiler. With GCC that's a pain, unless one takes the time to re-package GCC very carefully like https://github.com/richfelker/musl-cross-make and https://exherbo.org/.

Maybe getting some new GCC devs in there with projects like this would help with that?