I usually refrain from distro- (and editor-, and language-) related discussions but I think Void Linux deserves an exception here:
- Everything is remarkably simple, (mostly) well-documented and straightforward.
- Friendly, dedicated and very knowledgeable community
- Open development, very few hooks to jump through if you have something to contribute
- No systemd, so: rebooting your system isn't a lottery where, if you lose, you get to wait for 90 seconds for some service to stop, your system doesn't start doing strange new things after every update because something that's been working fine since the 1980s has recently been declared broken, no binary logs to get corrupted (and no need to tweak your system and sidestep this brilliant scheme). Of course, you can't do much DevOps on Void Linux, but I'm pretty sure that's about as relevant as the fact that you can't run macOS on low-power embedded systems.
- Completely community-ran and independent. Some things don't happen as quickly as in corporate-backed projects, but you're also not beta testing for their LTS or enterprise-grade releases, either. Also, no bureaucracy, no priority mismatch, no one to shove alpha-quality software down your throat.
It's basically like OpenBSD with more drivers but based on slightly worse and less cohesive technology :-).
> Of course, you can't do much DevOps on Void Linux..
Why not? runit is really great - it's an implementation of daemontools from djb - it's a powerful system - including socket activation, log handling, you can even run custom check scripts for your services. I'd even say it's more poweful than systemd and better for devops once you go beyond systemctl enable apache2
Whenever the line between a technical discussion and a systemd bashing thread becomes blurry, someone who does DevOps for a living invariably pops up to say how much they like systemd -- usually for pretty valid reasons.
It's also ubiquitous enough that, by this point in time, some of my younger colleagues who do DevOps for a living have never used anything but systemd. Doing Stack Overflow-driven (aka copy-paste) DevOps without systemd is pretty challenging nowadays.
Hence the joke.
Otherwise, yes, of course you can do DevOps on Void. I can't imagine what you couldn't do DevOps on; I know folks who were doing it on Novell Netware before the whole thing even had a name.
Isn't devops basically an infrastructure engineering, which if anything, is as anti-systemd as it gets. I guess people think of devops as something different then.
I found the question interesting as well especially since the original post mentions how michael works on void and distributimg it with ansible (many of the things he mentioned sound like devops to me)
> if you lose, you get to wait for 90 seconds for some service to stop
Now, now, that's really down to the way you write your RC scripts. Plenty of distros over the years have had timeout-based prereq-waits in their init.d scripts.
(Heck, I currently have a prereq-wait of some kind going on in the early-stage init of a macOS system, because it happens to contain a non-Apple-manufactured NVMe SSD formatted as APFS. Seems like TRIMing APFS volumes gets deferred to boot-time.)
90 seconds? You're lucky. I have machines running systemd (RHEL 7) that simply will not reboot unless I use the --force option. They will just sit there with a blank screen forever otherwise.
This is that case where you needed a smiley after the joke. I thought when you said that, that the reason was that it used a too simplistic init system a la OpenWRT, where you can’t check if the process is running, automatically restart daemons, etc.
The norm for what exactly? There are very simplistic init systems out there that do not supervise anything, and every daemon must come with its in shell script that checks if it is running. Without looking, I don’t know what Void does and the original comment here didn’t make it clear.
Considering every major init system ( and process supervisor ) since IBM Aix in has process supervision and auto-restarting to some degree then yes.
Void Linux uses runit a descedent of djb's daemontools which does automatically restart services and provides a way to check if it's running by starting the daemons themselves and keeping them as direct childs.
Whoa - that is a pretty big item. Thanks for mentioning that. One of my todos this year is to check out encrypted ZFS on Linux. I will try that on Void.
I've been running encrypted ZFS on Void for about a year. [Only caveat: I wasn't able to get an encrypted ZFS root working on Void (there is some issue with grub+luks+zfs), but I have system with an unencrypted ZFS root with an encrypted /home on ZFS.]
runit is an implementation of djb daemontools - http://thedjbway.b0llix.net/daemontools/blabbyd.html - the latest release is from 2001 - so this must be around since the early/mid 90ies - it's also what systemd copied to a degree also solaris / launchd got some inspiration from daemontools.
A while ago I started looking for alternative linux distributions and void linux is my new darling that came out of this search.
It has many binary packages, out of the box musl images, images for many of my arm boards (raspberry pi *, c2 and cubieboard for instance) and a nice packagemanager with source support and arch like syntax (it's splitted like the debian apt-get/apt-cache but worse... I still like it)
If someone knows where I can report bugs for the live system I would appreciate a link (or I have to do it over the forum/mailing list).
It uses runit as init system and I nearly forgot how nice a system without systemd could be.
I have a little project on the backburner where I started porting arch to musl, but since I found voidlinux I completly stopped.
It has an arch package to install void in a chroot and it has void packages for an arch like init system (mkinitcpio). The packages are updated regulary and even thought it's a larger distribution than alpine linux (it doesn't start with a barebone busbox base, but without wget and curl :D),but has a way larger precompiled package list than it (it even has some precompiled packages missing from other distributions like toybox the bsd licensed busybox like tool)
Anyway since it still offers 32bit x86 binaries I will maybe use it in time for my old hardware. Up until now void Linux has made me very happy and I wonder why I didn't see it 10 years ago when it's first release was born. If you haven't yet give it a try.
I also used to use void-linux for many of these reasons(after arch for a few years). But i have now moved to nixos. It offers me the benefits of replicating system setup(i don't backup my system folders anymore, just my homedir and the nixos configuration files), cleanly removing system-wide packages(no more stale config hanging around) and of course the benefits of using nix for isolated/reproducible builds.
I’m glad you posted this again. I remembered you posting this a week or two ago, but when I got a chance to look into it I couldn’t remember which article or what the name of the project was. I’m a fan of the style of NixOS, and also a fan of Arch, so this is a must-try. Thanks!
I liked the sound of this, so i tried to install it. I'm not sure if im just a complete idiot but i can't get it to install. Their liveCD image only lets me connect to WEP/WPA networks, so i can't connect to the WPA2-Enterprise network my school is on. They also don't let you connect to an unsecured endpoint so i cant connect to the alternative network provided.
I also couldn't get it to boot in UEFI, had to switch back to legacy bios. The partition manager is also a little confusing, i can't figure out which sizes to use or how to create them, i like debians ui here alot for this.
I ran the musl libc version of Void Linux for a while on one of my laptops but ran into a lot of problems and buggy behavior.
If you are going to use Void Linux I would strongly recommend not picking the musl version unless you are specifically interested in improving musl support by filing and/or fixing bugs.
Almost all of it. Musl AFAIK strongly sticks to the standard. It is one of the biggest things holding back wider adoption.
Similar to the dependence between the linux kernel and GCC. Clang should work but linux also has the 'GNUisms' so deep there a big project called LLVMlinux to correct it.
We are referring to buggyness during execution (what the parent of the comment i'm responding to says) while most problems with GNU-isms come hit you at compile-time.
I haven't found the musl flavour of Void particularly buggy; using the musl variant will limit your range of installable packages though since some applications have hard glibc requirements (and many require some sort of patching to work with musl, which can range from trivial to very difficult).
My first impression is that it feels really snappy. I am not sure if I like the cli interface of the package manager. But I will give this one a try.
Can someone share their experiences regarding Void's stability? I am currently using openSUSE Tumbleweed on my desktop and primary laptop, and while I am mostly happy, things sometimes kind of break after installing a batch of updates.
I used Void on my previous laptop for about a year with no stability issues. The only reason I stopped using it was because I wanted to experiment with a no-grub EFI stub booted whole disk encryption using LUKS non-systemd setup, which I only really had an idea of how to do on Gentoo, so I went back to that. [Edit: I think I might have almost had this working on Void, in fact, but there was some piece that I couldn't get right, if I remember, but that I could do more easily in Gentoo. But I can't remember what that might have been. It's been a while since I did that.]
Otherwise, I probably would have stayed with Void for a while more. It was pretty nice.
I recently tried a number of Linux distros to get specific GNU tooling for an embedded project I'm working on. (My daily driver is OpenBSD.) The Void philosophy is very appealing to me compared to most other Linux distros. I tried both Void with glibc and with musl. Both of them would install ok but then immediately panic on rebooting, and I didn't spend the time and effort to get past that to find out whether it would be stable once I got it running.
I love Void, but I personally find that Arch is much better supported overall in terms of packages and the AUR. I haven't tried Void recently though so maybe I should give it another go and help contribute.
I have been using it for now two years, and my only problem so far was a bad default umask with fish shell which wrongly set root-only permission on package search. Fixed with the correct umask in my fishrc.
Oh, and steam can't remember to keep me logged, but I'd probably blame Valve rather than void for this (very minor) inconvenience.
Slackware and Arch are still very much alive as projects.
By 'successor' do you mean 'works in a similar way and I happen to like it better' or is there something that you think Void has got that slackware and arch don't have?
PS: downloading the void live .iso now for a bit of distro-hopping on a spring morning.
As someone who switched from Slackware to Void several months ago, Void boots far faster. Also, though I haven't used Arch, Void really feels like a combination of a slimmed down Slackware + NetBSD (the author of Void is a NetBSD commiter IIRC). Of course, Gentoo portage was inspired by BSD ports, which I believe was an impetus for Arch's package manager.
I don't know what the story is for Arch, but I find that Void strives to make the system dead simple: it is even more minimalist than Slackware (it feels more like a BSD). It isn't just small, though: it has good defaults. There isn't a whole lot of documentation beyond the well-written man pages, and I believe this is in part because it isn't necessary.
Like Arch, though, it is a rolling release system: an update may break your system, and package indices quickly become stale as old packages are deleted from the server. You can easily fix this by updating the index.
Installed on an old Thinkpad X61s from the xfce4 live .iso (< 600Mb) dd'ed to a usb stick. Boots into an xfce live graphical session with network-manager recognising the Atheros wifi card. Minimal install - xfce 4.12 plus Web browser and image viewer (1.5Gb on hard drive).
Ran the installer script from a terminal in the live session - result is an ncurses dialogue that walks you through the steps. Disk already partitioned and skipped the network set-up stage and selected install from local. Rebooted into (graphical, xfce4) installed system in a few minutes. Network manager up and running, needed to log-in to local wifi again.
Probably because I skipped the network stage in the installer, I needed to set a repository for updates.
It looks like you've already figured out some things like sound, wifi, and xbps, but: I found the following guide helpful in complementing the man pages:
I worked out that root defaults to /bin/sh before reading the voidtips page above. Also worth mentioning here that Firefox-esr (52) is installed by default from the xfce4 live iso. Firefox release (59) is also available as is Chromium (65). Some font-puggling is needed (fontconfig stuff) to get sub-pixel rendering.
In all, quite nice. I'll see how long it takes me to break this.
A year ago or so I switched to Void Linux from Debian and my conclusion so far is that Void is a near perfect Linux distribution. Stable, simple and systemd free. The package manager is simply a pleasure to use.
My only critique is that most packages will install everything but the kitchen sink, so even if I only need "Writer" I have to install every single component of LibreOffice and this makes the system a little bloated.
Question - is there any reason your project can only be used on x86_64? I can't readily find documentation about godarch that suggests it even requires 64bit hardware.
The base docker images (https://github.com/godarch/distributions) only supports x86_64. Docker images have support for having multiple embedded rootfs tarballs for multiple platforms, but it gets complicated. Maybe in the future.
Also, you have to build your recipes on the same target arch that you are going to deploy to. Irrelevant to your question, but something to note.
Darch isn't "go get"-able. Things need to be vendored and you'll need a certain version of containerd and runc (which isn't "go get"-able either).
Are you having a problem with the Void package script? The go build template for Void is very naive, I wouldn't use it. It uses symlinks which doesnt place nice with vendoring tools. Things will be a lot smoother when vgo is done and their template is updated accordingly.
Except that the makefile really depends on submodule updates and other mechanisms that require a git clone (hard on the build servers) instead of a tarball that can be cached and checksummed.
I love Void. It's like Arch was back when I first tried it. My main machine still runs Slackware, but my Raspberry Pi 2 runs Void and I've been mostly satisfied with it. The unsatisfying bit isn't really Void's fault; a bug in Xorg prevented it from working with musl on ARM. this has since been fixed.
I use both as daily drivers on laptops, and they are both very nice systems. Some differences:
* Alpine is lighter-weight. As at least one point, Alpine packages are split into small parts (usually at least app, app-dev, and app-doc, respectively containing the actual program, the development headers, and the manpages/docs). Alpine also defaults to using Busybox for coreutils.
* Void is rolling release with regular updates and a surprisingly large repo. Alpine has a rolling "edge" release and stable releases that are supported for 2 years.
* Void works on a traditional install to a writable root filesystem; Alpine can do that ("sys" install), or can run in RAM, optionally persisting state).
* Alpine uses hardened kernels. They used to use grsec, not sure what code they use now. Additionally, they configure the system to be locked down; for instance, on the laptop I'm using to type this comment, I can only check the battery status as root, and powertop outright doesn't work (as I understand it, they completely killed off the debugfs interface it needs).
* Void seems to be more into cutting-edge tech; ZFS and wireguard come to mind.
In general, Alpine is designed for embedded, Void is a general-purpose system. Both can do the others' job, but that's their tendencies.
The alpine userspace is also great to run in containers
my LXC container basically runs up DHCP to get an IP and a SSH server to provide a remote shell, everything else is per-server setup like webservers and stuff, compared to the ubuntu containers I run Alpine uses a LOT less memory and CPU.
Alpine is musl only; Void has both glibc and musl variants. Void seems more desktop-focussed than Alpine, and (at least as of a year ago) I didn't have a lot of luck with ZFS on Alpine.
Hehehe I wrote the original wiki entry (because someone on irc asked for something like that)
I think it's still the recommended way for dependency management reasons and missing glibc-packages. If you can get your program running with the alpine glibc you should probably do that
If you're into programming in C, and like simplicity, you might find more likeminded people there, similar to OpenBSD. Nix is more popular among functional programmers.
Nix is for everybody; I don't do functional programming but I still use Nix for everything. If OpenBSD is simple, or C is simple, and Void is also simple, then it sounds like I should not bother trying out Void.
I've explored potential Nix usage but I found it far to complicated and documentation on production usage rather lacking.
I would rather love something that explains me how to setup Nix on Alpine Linux and then deploy Nginx + PHP 7.1 with several websites. For desktop usage I enjoy tinkering with edge and upstream releases too much to consider Nix anyway.
What what? That's more or less what a package manager does; take archives ("packages"), unpack them into the system ("install"), and then keep a database of what archives are unpacked and what files each one owns. In practice there's a lot added to that (pulling the archives from a central repo, dependency resolution, searching, managing config files...), but the simple case is barely more than tar.
"Because of this, xbps-src is in fact not a binary, it is a collection of very intricate shell scripts that use standard tooling available on almost any Linux distribution to bootstrap a compiler, build chroot, and XBPS itself."
When he stepped away from NetBSD, I remember reading that it was because he wanted to work on a package manager.
It might be that the entire raison d'etre for Void Linux is a package manager consisting of shell scripts.
Not sure what he thinks of pkgsrc but IMO their work has made things so easy that, e.g., one can easily use a set of shell scripts instead of pkg-add, etc. I do this to save space on small systems. IME, the pkgsrc bootstrap scripts are a very reliable way to build a gcc toolchain. (build.sh as well)
One project I have had on the list for many years is to build Linux on BSD. Could it be done? Has it been tried?
Also, maybe S6 deserves a mention as another daemontools clone, with the added bonus that it may lead one to discover execline.
Nothing against runit. I use socklog and occasionally udpsvd by the same author.
> One project I have had on the list for many years is to build Linux on BSD. Could it be done? Has it been tried?
How do you mean? Compiling the Linux kernel on a BSD machine? Using GNU on BSD (if so, the answer is yes; see Debian GNU/kFreeBSD)? Linux kernel with BSD userland?
Compiling Linux on computer running BSD. User has no computer running Linux, but she has computer running BSD. She builds needed toolchain, downloads and compiles Linux kernel. Its relatively easy to build BSD while running Linux. But vice versa?
Okay, so I tried it, and I'm going to say, "not easily".
Started from base FreeBSD install, installed gcc and gmake, pulled down a tarball from kernel.org. Did a `gmake x86_64_defconfig` to get started. First problem: FreeBSD calls it "amd64", Linux calls it "ia86". Exported ARCH=ia86 and retried. It gets further now but appears to blow break trying to build some .S files (FreeBSD uses as from GNU binutils, but it's like a decade old). I couldn't figure out how to fix, so gave up:)
I suspect it would work in a Linux jail, though, since that's a GNU userland with a Linux ABI from the kernel. Didn't try, though.
I also won't speak to whether it would work on netbsd/openbsd/etc.
- Everything is remarkably simple, (mostly) well-documented and straightforward.
- Friendly, dedicated and very knowledgeable community
- Open development, very few hooks to jump through if you have something to contribute
- No systemd, so: rebooting your system isn't a lottery where, if you lose, you get to wait for 90 seconds for some service to stop, your system doesn't start doing strange new things after every update because something that's been working fine since the 1980s has recently been declared broken, no binary logs to get corrupted (and no need to tweak your system and sidestep this brilliant scheme). Of course, you can't do much DevOps on Void Linux, but I'm pretty sure that's about as relevant as the fact that you can't run macOS on low-power embedded systems.
- Completely community-ran and independent. Some things don't happen as quickly as in corporate-backed projects, but you're also not beta testing for their LTS or enterprise-grade releases, either. Also, no bureaucracy, no priority mismatch, no one to shove alpha-quality software down your throat.
It's basically like OpenBSD with more drivers but based on slightly worse and less cohesive technology :-).