
The Void (Linux) distribution - ColanR
https://voidlinux.org/
======
merricksb
Past discussions:

[https://news.ycombinator.com/item?id=15114055](https://news.ycombinator.com/item?id=15114055)
(16 months ago)

[https://news.ycombinator.com/item?id=16670337](https://news.ycombinator.com/item?id=16670337)
(9 months ago)

------
aetherspawn
I couldn’t find a “Why” section that explains why this needs to exist. Anyone?

~~~
interfixus
Because any independent distro is interesting in its own right. Because++ an
independent, lightweight, rolling distro with a fresh take on various issues
is even more so.

I am an Arch user at home, and a huge fan of Alpine Linux for my servers.
Taking this - and Christmassy time off - as oppurtunity to reacquaint myself
with this fun, light, enjoyable, and hyper-fast Linux, so thanks for posting.

~~~
em3rgent0rdr
I think programmer resources would be better spent helping make another disto
better...and as this seems similar to arch linux, why not just focus on making
it as an arch linux variant...one that ueses Runit instead of systemd, or make
an arch-linux install CD that only uses musl instead of glibc.

~~~
duncaen
You think, but you have no clue about the differences, which are so
substantial that it wouldn't be possible to convince arch to change things
like this, may it be for legacy reasons because some things are breaking
changes or may it be just something the Arch team doesn't care about.

\- Arch Linux supports only x86_64 in the main project

\- Void supports i686, x86_64, armv6, armv7 and aarch64 with both musl and
glibc under one project, one source repository.

\- Arch linux does not allow partial updates

\- Void linux allows partial updates because the package manager tracks shared
libraries and big issues can be avoided by aborting the transaction if a
conflict exists

\- Arch puts everything into one big package

\- Void splits packages, not as much as debian, but at least the development
stuff is in a `-devel` subpackage. This reduces the installation size by alot
(especially useful for embedded systems, arm...).

\- Arch has no repository with debugging symbols

\- Void has a repository with -dbg packages containing the debug symbols.

\- Arch only maintains two kernels, mainline and lts.

\- Void maintains kernels in packages with the a version suffix, `linuxX.XX`.
Users can choose which series for how long they want to use. (also great for
embedded systems)

\- Arch kernel updates remove the old kernel version

\- Void keeps the old kernels, the administrators can boot the previous kernel
until they decides to purge old kernels with the `vkpurge` script if new
kernels work fine.

This are the differences on top of my head, there are plenty more.

But yes tell people they waste resources.

~~~
em3rgent0rdr
> "Arch Linux supports only x86_64. Void supports i686, x86_64, armv6, armv7
> and aarch64..."

Well Arch Linux Arm has optimized packages for soft-float ARMv5te, hard-float
ARMv6 and ARMv7, and ARMv8 AArch64 instruction sets [1], which is even more.

Arch main project used to support i686, but after removing official support,
i686 is still carried on by Arch Linux 32. [2]

Does it really matter if it is not under the same project?

[1] [https://archlinuxarm.org/](https://archlinuxarm.org/) [2]
[https://archlinux32.org/](https://archlinux32.org/)

~~~
duncaen
> Well Arch Linux Arm has optimized packages for soft-float ARMv5te, hard-
> float ARMv6 and ARMv7, and ARMv8 AArch64 instruction sets [1], which is even
> more.

Right, Void does not provide pre-built packages for armv5, there are a few
other architectures void works with but doesn't provide pre-build packages.
this includes armv5, different mips targets and there are currently
contributors working on getting powerpc and powerpc64 merged. powerpc64 will
most likely become another architecture with pre-build packages.

> Does it really matter if it is not under the same project?

Yes, different projects apply different patches, have potentially different
packages or provide different package versions.

With Void every package has the same patches applied, maintainers are "forced"
to write portable patches that can be easily upstreamed. Package versions are
usually the same (some exceptions), no delay.

I bet its easier for void to maintain all architectures at once than the man
power required to maintain separate repositories and patches for the arch
"forks".

Then you have the review overhead with forks, on void maintainers review
commits to one repository, with the arch forks you have a fraction of the arch
maintainers review commits to forks, while all others only review commits to
the main repository.

Void makes it easier to maintain packages for different architectures, it
provides xbps-src which cross compile to different architectures, it uses
Travis-CI to build each pull request for different architectures.

------
kazinator
Can someone explain this:

[https://github.com/void-linux/void-
packages/blob/master/srcp...](https://github.com/void-linux/void-
packages/blob/master/srcpkgs/txr/patches/musl-configure.patch)

This configure test uses a C program to detect that #include <$try_header>
works for some value of $try_header, like alloca.h: note angle brackets. After
detecting it this way, why would we need to switch this to #include "..." for
the sake of Musl, to get the actual program to compile?

~~~
kazinator
I figured it out (without actually building with Musl).

Musl's <stdlib.h> includes <alloca.h> already if _GNU_SOURCE or _BSD_SOURCE is
defined.

Musl's <alloca.h> defines an object-like alloca macro if compiled with GCC:
#define alloca __builtin_alloca.

When we try to include the <alloca.h> header through a macro, as in #include
ALLOCA_H, it's subject to macro expansion: ALLOCA_H is replaced with
<alloca.h>. This is five pp-tokens: < alloca . h >. The second one is the
macro that was defined due to <stdlib.h> having included <alloca.h> already,
and so this gets replaced now; we end up with #include <__builtin_alloca.h>.

------
efiecho
I have been using Void for months on the desktop, and I like it very much,
especially the package manager, but something that REALLY annoys me is how
bloated every package seems to be.

Maybe you only want to use Writer from Libreoffice, but you have to install
absolutely EVERYTHING, many gigabytes including Java stuff that only 0.01%
will ever need, and this is true for most packages, QEMU is another horror
example.

In Alpine Linux almost every package is split into multiple small sub packages
so you can install only the stuff you need. This is great.

~~~
kungtotte
That's a Libreoffice issue, not Void.

You'll see the same thing on any Arch-based distro too for example, and I'd
venture to guess that most distros are the same since there's little incentive
for them to rip apart upstream packages and repackage them.

~~~
efiecho
Alpine has a separate Writer package, Debian has a separate Writer package and
probably many more distros. Same thing with QEMU, a separate package for every
architecture, separate GUI packages etc.

I like so many things about Void, but the package bloat is just crazy.

------
JamesCoyne
Anyone care to give the sales pitch?

~~~
tyingq
There's one in a review here: [https://www.thelinuxrain.com/articles/void-
linux-the-strange...](https://www.thelinuxrain.com/articles/void-linux-the-
strangely-overlooked-distribution)

Key bullets from that:

 _Independent distribution, entirely volunteer run

runit system service manager by default (no systemd)

xbps system package manager, simple ports-like system akin to the BSDs or the
Arch Build System

Fresh, constantly updated software thanks to rolling release

Uses LibreSSL by default instead of OpenSSL

A real hands on but KISS approach to system management, akin to Arch/ BSD
etc._

~~~
Carpetsmoker
I ran Void Linux for about a year. I thought it worked pretty well. I like the
runit system, which proves you can do a sane service mangement without tons
and tons of complexity ( _cough_ systemd _cough_ ). A lot of other stuff took
a similar simple Unix approach, which I rather like (Linux, for better or
worse, often takes a more complex approach).

The reason I stopped using it is because I changed jobs and had to run
Vagrant, which doesn't work with the musl libc. I had to reinstall it to the
glibc version, and figured I might as well use the more "mainstream" Arch
Linux while I was at it, as I was a bit tired of having to spend effort in
getting stuff like that to work.

~~~
sulam
I have to admit I’ve never understood why systemd is perceived as so hard to
understand. Still, it’s good to see some real alternatives.

~~~
Carpetsmoker
Concrete example:
[https://unix.stackexchange.com/q/185495/33645](https://unix.stackexchange.com/q/185495/33645)
(I am the asker of that question).

This is a really weird thing to happen, and not really easy to debug, much
less fix. Look at the diff that fixed the bug for an example. No way I could
have figured that out on my own without a _significant_ investment in time.

With runit, everything is pretty straightforward. Not saying I can figure out
every last bug, but I can at least mostly understand what's going on if I
spend a wee bit of time on it. Same with Free/NetBSD's rc system, and
OpenBSD's rc system. Here, it's really hard to even figure out if this is the
expected behaviour or not, as all this logic is fairly complex.

I remember watching a talk Linus did about Linux around 2000. One of the
reasons he likes Unix is that (paraphrased, as I didn't look up the original)
"everything is understandable; you don't understand all of the system, but if
you want or need to, you can go in there and understand it and hack on it".
Now, that may have been true for the 2000 Linux ecosystem, but for the 2018
system ... yeah, not always. For better or worse, Linux has kind of lost this
property to some degree. There are trade-offs here of course (Linux has also
gained some stuff), but for me personally, I much prefer the "understandable"
and "hackable" Unix systems. I think Void Linux is a good example of that
(OpenBSD is another).

Oh, and here's another example:
[https://unix.stackexchange.com/q/184338/33645](https://unix.stackexchange.com/q/184338/33645)

The systemd error message for this unexpected situation was worthless (see my
self-accepted answer). It was a simple problem, but took me quite some time to
figure out.

~~~
sulam
Thanks for the example, although its power is somewhat reduced by the fact
that you encountered admittedly buggy behavior that has since been fixed.
Still, I appreciate that this is unexpected and likely hard for even an expert
user to fix.

