unbox
or unshare-toolbox
is an independent reimplementation of the ideas developed by toolbx.
It does not use established container runtimes (podman
, docker
, systemd-spawn
, etc) to isolate the processes but instead it
is implemented directly with Linux Nampespaces to provide the environment of execution. For the creation of the images it is possible
to use existing OCI images.
Warning The implementation is still very young, and has not been "battle tested" at all, the only usage to my knowledge has been in my personal computer. If you find any bugs, please open an issue.
There are no distro packages available yet, so the preferred way to install is to download the appropiate binary from the releases page.
unbox
can also be installed from source. You should install Rust
and cargo
first following these instructions.
If you have just installed you can build using the native
option for the most optimized experience:
$ just native
[...]
$ cp ./target/optimized/unbox ~/.local/bin/
Or a statically linked binary:
$ just sbuild optimized
[...]
$ cp ./target/x86_64-unknown-linux-musl/optimized/unbox ~/.local/bin/
But it is not needed, you can also use:
$ cargo build --profile optimized
[...]
$ cp ./target/optimized/unbox ~/.local/bin/
The first step is to create a toolbox, which will store their root filesystems inside of ~/.local/share/unbox/images/
.
If the rootfs is contained in a tarball it can be created from the following command:
$ unbox create <name> -t <path to rootfs.tar>
If podman
or docker
are installed an OCI image can be downloaded an used, note that it may take a while if the image has not already been downloaded:
$ unbox create <name> -i <url for the image> -e <engine to be used>
For example to create an Arch Linux toolbox from its official OCI image using podman
:
$ unbox create archlinux -i docker.io/archlinux:latest -e podman
To open an interactive shell inside an existing toolbox:
$ unbox enter <name>
To run a specific command inside an existing toolbox:
$ unbox run <name> -- <command> <arguments...>
For example, in the previously created archlinux
toolbox:
$ unbox run archlinux -- ls -lh
To list the names of the existing toolboxes:
$ unbox list
To delete an existing toolbox:
$ unbox rm <name>
There are a number of different implementations of the ideas originally developed by toolbx
, this section compares unbox
with each of them
to flesh out their strengths and weaknesses. This comparison should not be regarded as absolute truth as it may be biased by my opinions and interests
or lose accuracy with new developments in each of the different implementations.
Implementation | Language | Based on | Image | Time to enter |
---|---|---|---|---|
toolbx | Go | podman | OCI images | 837 ms |
distrobox | Shell | podman or docker | OCI images | 284 ms |
nsbox | Go | systemd-nspawn | Ansible | --- ms |
devbox | Go | nix-shell | - | --- ms |
unbox | Rust | - | OCI images or tarballs | 1 ms |
For the source of the "Time to enter" metric check here
Toolbx is the original implementation and is the default in Fedora Silverblue. This means that it has been more "battle-tested" than the other alternatives, with more bugs being found and fixed and more features being considered implemented. Officialy only Fedora images are supported, but it is possible to create images following their documentation for other distributions. In my opinion the most important downsides are the long time to enter into the toolbox and the lack of flexibility by using an OCI runtime.
Distrobox offers much more choice, from a wider set of tested images and a choice of using either podman
or docker
as the container manager. The project also
has as one of its aims to be fast, and it is significantly faster than the original toolbx
in my tests. It is probably the second most used implementation, so
most features are already implemented and a lot of bugs have been fixed. In my opinion the most important downsides are the long time to enter into the toolbox
(although one of their aims is to be as fast as possible the use of an OCI runtime puts a hard limit on how fast it can run), and the fact that is is written in
a shell language which I dislike for bigger projects.
Devbox is a young implementation based on the Nix
project and it is more focused on giving reproducible environments to developers than on "pet" userspace for
immutable distributions. In my opinion the biggest downside is the usage of Nix
, which is not a pleasant experience to use in ostree
distributions like
Fedora Silverblue. Another downside that it shares with unbox
is that because it is a younger project some features might be missing or some bugs may not have been
found.
unbox
is distributed under the Mozilla Public License v2, and any contributions will be incorporated under that license unless explicitly stated otherwise.