Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
enroot
A simple yet powerful tool to turn traditional container/OS images into unprivileged sandboxes.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
traveling-ruby
Self-contained Portable Ruby ( 2.6.10 -> 3.3.x ) Binaries for Linux/MacOS/Windows (by YOU54F)
The main reason Zig was chosen is because the project was started at a hackathon[0] at which there was a prize for "best use of Zig". Beyond that there were also other reasons: 1. I have been wanting to try out Zig 2. It fit the requirement of being a so called "systems language".
However having written it in Zig I have a few retroactive reasons for why Zig was a good choice (if not the best choice):
* The build system allows to make the runtime a dependency of the "compiler". I don't think any other language has that.
* The interoperability with C/systems calls is amazing (in comparison to anything but C/C++)
* The ability to embed files
[0]: https://treehacks.com/
[1]: https://github.com/NilsIrl/dockerc/blob/68b0e6dc40e76c77ad0c...
Yep pretty much.
The executables bundle crun (a container runtime)[0], and a fuse implementation of squashfs and overlayfs. Appended to that is a squashfs of the image.
At runtime the squashfs and overlayfs are mounted and the container is started.
[0]: https://github.com/containers/crun
It will depend heavily on the docker image you're trying to ship. For example with macos-cross-compiler[0] the resulting binary is over 2GB. With python:alpine[1] it's only 25MB.
Because image isn't copied whether the image is 2GB or 25MB the startup time will be nearly instantaneous for both.
The runtime adds 6-7MB of overhead although I expect that this can be reduced to less than 3MB with some work.
[0]: https://github.com/shepherdjerred/macos-cross-compiler
Enroot can do something similar: https://github.com/NVIDIA/enroot/blob/v3.4.1/doc/cmd/bundle....
Unfortunately cosmopolitan wouldn't work for dockerc. Cosmopolitan works as long as you only use it but container runtimes require additional features. Also containers contain arbitrary executables so not sure how that would work either...
As for WASM, this is already possible using container2wasm[0] and wasmer[1]'s ability to generate static binaries.
[0]: https://github.com/ktock/container2wasm
[1]: https://wasmer.io/
Unfortunately cosmopolitan wouldn't work for dockerc. Cosmopolitan works as long as you only use it but container runtimes require additional features. Also containers contain arbitrary executables so not sure how that would work either...
As for WASM, this is already possible using container2wasm[0] and wasmer[1]'s ability to generate static binaries.
[0]: https://github.com/ktock/container2wasm
[1]: https://wasmer.io/
You can already do this with these forks of ruby-packer and traveling-ruby:
https://github.com/ericbeland/ruby-packer
https://github.com/YOU54F/traveling-ruby
ruby-packer is what I use to distribute a paid CLI, although on macOS only because my product is specifically for customers on macOS.
The advantage of ruby-packer is that it is much simpler, but you need to have access to each OS where you want to distribute your executable. OTOH, with traveling-ruby, you can build executables for all OSes from the same machine.