Void is a general purpose operating system, based on the monolithic Linux® kernel. Its package system allows you to quickly install, update and remove software; software is provided in binary packages or can be built directly from sources with the help of the XBPS source packages collection.
It is available for the Intel x86®, ARM® and MIPS® processor architectures; Software packages can be built natively or cross compiling through the XBPS source packages collection.
Void Linux is an independent distribution, developed entirely by volunteers.
Unlike trillions of other existing distros, Void is not a modification of an existing distribution. Void's package manager and build system have been written from scratch.
Install once, update daily. Your system will always be up-to-date.
Thanks to our continuous build system, new software is built into binary packages as soon as the changes are pushed to the void-packages repository.
We were the first distribution to switch to LibreSSL by default, replacing OpenSSL.
xbps is the native system package manager, written from scratch with a 2-clause BSD license.
xbps allows you to quickly install/update/remove software in your system and features detection of incompatible shared libraries and dependencies while updating or removing packages (among others). See the usage page for a brief introduction.
xbps-src is the xbps package builder, written from scratch with a 2-clause BSD license.
This builds the software in containers through the use of Linux namespaces, providing isolation of processes and bind mounts (among others). No root required!
Additionally xbps-src can build natively or cross compile for the target machine, and supports multiple C libraries (glibc and musl currently).
We would like to warn people of a domain name that is no longer under Void
voidlinux.eu lapsed in its original registration, and was
purchased by an unknown 3rd party before Void Linux could regain ownership. At
this time, please assume that anything involving
voidlinux.eu is not related
to Void Linux, and should be considered potentially malicious. Of course, if
the person who owns the domain now would like to transfer it to our control,
we’d be grateful, and will update voidlinux.org to indicate if this happens.
Our official domain is VoidLinux.org.
Thanks to the work of maxice8 we’re pleased to announce cross compiling support for gobject-introspection and packages that depend on this tool. This is a big step forward to support more packages through cross compiling and stay future proof for glib development.
maxice8 put together a comprehensive post about his work. This article will be higher level overview of our work in this field.
gobject is an abstract description of types defined in glib. Glib is used on a wide range of application and libraries, most notably gtk. Glib itself is written in C but it’s possible to provide dynamic language bindings to other languages such as python.
This mechanism is not builtin into glib, but instead is provided by the gobject-introspection tool. This tool scans both the source and the binary blob of a library and creates a metadata file that is used to provide type information for other language bindings. For a deeper dive into gobject-introspection please consider the docs at readthedocs.io
When it comes to Void, we have high demands on portability of applications. Our armv6l, armv7l and aarch64 platforms a completely and exclusively cross compiled, meaning they are built on an x86_64 host. This leads to an interesting problem with gobject-introspection which by design needs to run on the same platform as the produced binaries are targeted.
Unfortunately, as already stated this has been a design decision of this software and we can’t do anything to change this constraint itself.
Furthermore, during the last few years the Gnome community drifted towards extensively using gobject-introspection in their products. This led to the breakage of more and more applications in the gnome-ecosystem.
During the last few months we considered different solutions to this problem. This first proposal to not support gir through cross compilation and only allow it through native build became more and more unsatisfying as the number of packages using this mechanism increased over time.
The second approach which was the followup to the one described above was to add native builders to the system and build those packages on those native builders. The issue was here that this would require a lot of infrastructure work and added a lot of complexity.
The third solution and the one we chose was to use the userspace emulation features of Qemu to emulate the target system only for those calls that needed to be on the target platform. The yocto project is already using this approach to cross compile Gnome Applications to other platform. We reused many of their tooling for void-packages. Nontheless, we hit many porting issues - our tooling must run on musl, too - , new bugs were triggered in void-packages - see for example these two posts at maxice8’s blog, and many other small issues needed to be resolved.
Basic support for cross compilation has already landed in void-packages, the musl port is not yet finished, but we expect it to work soon(tm).
maxice8 also prepared a blog post about his porting work on libgusb.