Void Linux: Into the Void(michaelwashere.net)
michaelwashere.net
Void Linux: Into the Void
https://michaelwashere.net/void/linux/culture/2017/09/18/into-the-void.html
103 comments
> 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
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
Thanks for beating me to saying all of that. It's been my experience, too.
Void Linux has made me say a good "wow" more than any other Linux.
I love that I can use many of my favorite bits of OpenBSD, even doas.
xbps takes just a minute to learn, and is surprisingly ("wow") fast and robust.
Who knows why it's not more popular, but it doesn't matter. It's awesome.
Void Linux has made me say a good "wow" more than any other Linux.
I love that I can use many of my favorite bits of OpenBSD, even doas.
xbps takes just a minute to learn, and is surprisingly ("wow") fast and robust.
Who knows why it's not more popular, but it doesn't matter. It's awesome.
No systemd, so [...] you can't do much DevOps on Void Linux
How so? How is DevOps linked or dependent on systemd in your view? Personally, I find systemd gets in the way of devops.
How so? How is DevOps linked or dependent on systemd in your view? Personally, I find systemd gets in the way of devops.
Oh, the downvote machine works here as well...
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.
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.
Some people use "devops" as a derogatory term for developers copy-pasting stuff to the terminal.
Certain in-terms tend to acquire ironical undertones quite quickly, such as "agile" now meaning certified scrum masters(tm) doing half hour standups.
Certain in-terms tend to acquire ironical undertones quite quickly, such as "agile" now meaning certified scrum masters(tm) doing half hour standups.
For me devops is summed up thus:
http://www.commitstrip.com/en/2015/07/08/true-story-fixing-a...
http://www.commitstrip.com/en/2015/07/08/true-story-fixing-a...
I don't understand, what can't DevOps do much without systemd where most of the DevOps culture involving around automations?
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)
mdekkers(1)
[deleted]
> 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.)
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.
Not only no systemd; Void uses runit, which is systemd's service management principles done The Unix Way™.
you can't do much DevOps on Void Linux
https://news.ycombinator.com/item?id=16671791
I can't edit my post anymore :-)
I can't edit my post anymore :-)
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.
but you can check if the process is running and automatically restarting supervised services is the norm.
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.
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.
Another nice feature is first class support for ZFS.
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.]
I am so glad to hear encrypted ZFS is stable and working. Thanks for sharing that.
> something that's been working fine since the 1980s has recently been declared broken
Void Linux uses runit, which was released in 2004, so I guess they agree.
Void Linux uses runit, which was released in 2004, so I guess they agree.
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.
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.
With Darch (I'm the author), you can use VoidLinux with a replicated setup.
Also, each boot is a clean boot (tempfs overlay). This ensures you capture your OS changes through your build script.
https://godarch.com/
This gives me what I love about Nix (scripted setup) with OSs I love (Arch and Void).
Also, each boot is a clean boot (tempfs overlay). This ensures you capture your OS changes through your build script.
https://godarch.com/
This gives me what I love about Nix (scripted setup) with OSs I love (Arch and Void).
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 just automated my laptop setup with Salt [1]. I want to keep using that instead of bash scripts (what Darch uses, by the looks of it).
I like the idea of having "images" with tempfs overlay. Is it possible to combine Salt with the image feature from Darch?
[1]: https://github.com/atmoz/workstation-formula
I like the idea of having "images" with tempfs overlay. Is it possible to combine Salt with the image feature from Darch?
[1]: https://github.com/atmoz/workstation-formula
I'm not familiar with Salt, but it looks interesting!
Does Salt allow you to run from an already-built (but minimal) Arch installation? The base Darch images (godarch/arch) is bootstrapped manually.
Would I have to create a godarch/arch-salt image that is bootstrapped from salt files, so that you could further salt the image?
How would salt handle the inheritance that Docker provides?
Does Salt allow you to run from an already-built (but minimal) Arch installation? The base Darch images (godarch/arch) is bootstrapped manually.
Would I have to create a godarch/arch-salt image that is bootstrapped from salt files, so that you could further salt the image?
How would salt handle the inheritance that Docker provides?
Yes, have a look at how I bootstrap an Arch installation: https://github.com/atmoz/workstation-formula/blob/master/boo...
All you have to do is install Salt, and then you can run salt-call to apply states.
Yes, Salt states can depend on other states, and you could choose to apply only selected states.
All you have to do is install Salt, and then you can run salt-call to apply states.
Yes, Salt states can depend on other states, and you could choose to apply only selected states.
By the sounds of it, you could do this currently.
1) Create a root image for your use that installs Salt in your Arch image. See here: https://github.com/pauldotknopf/darch-recipes/blob/master/ba...
2) For the rest of your recipes/layers, create a script/bash file like you would normally, but just pass execution to Salt.
I'll look into Salt more. Maybe there is a way to extend Darch to support different "executors" to support things like bash/Salt/Puppet/etc.
1) Create a root image for your use that installs Salt in your Arch image. See here: https://github.com/pauldotknopf/darch-recipes/blob/master/ba...
2) For the rest of your recipes/layers, create a script/bash file like you would normally, but just pass execution to Salt.
I'll look into Salt more. Maybe there is a way to extend Darch to support different "executors" to support things like bash/Salt/Puppet/etc.
This is cool!
Nixos was on my list as well, but I never got to try it out properly since void linux won me over.
I'm still using arch as well, but I guess I always try to choose the right distro for my use case.
But I think I will give nixos a spin again some time. I like the idea of the package manager very much
I'm still using arch as well, but I guess I always try to choose the right distro for my use case.
But I think I will give nixos a spin again some time. I like the idea of the package manager very much
Bug reports are mostly handled on GitHub.
For the live system probably here: https://github.com/voidlinux/void-mklive/issues And issues related to packages https://github.com/voidlinux/void-packages/issues
For the live system probably here: https://github.com/voidlinux/void-mklive/issues And issues related to packages https://github.com/voidlinux/void-packages/issues
I also love void. The reason I use it is for regression testing of musl. But boy the updater is so much faster than anything else.
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 stopped after seeing all that.
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 stopped after seeing all that.
A new(ish) from-scratch Linux distro designed by an old NetBSD dev.
Distribution homepage: https://www.voidlinux.eu/
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.
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.
Odd; I've run the musl version for years without issue. What kinds of failure did you see?
The only thing I've seen is that WebKit on musl has broken JavaScript, which I suppose would be a big issue for some people.
The only thing I've seen is that WebKit on musl has broken JavaScript, which I suppose would be a big issue for some people.
Do wonder how much of that was from code having adopted GNU-isms...
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.
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.
honestly not that much since adopting a GNU-ism or Glibc-ism will in most case result in errors at compile-time.
Nope. This 'self is the standard' way of GNU software is one reason I'm not a big fan of GNU.
https://wiki.musl-libc.org/functional-differences-from-glibc...
https://wiki.musl-libc.org/functional-differences-from-glibc...
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).
I just installed Void Linux a VM.
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.
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.
Otherwise, I probably would have stayed with Void for a while more. It was pretty nice.
Anecdote: I've used Void for a few years, and I have had it break exactly once that I recall. That one time was filesystem issues[0], fixed by fsck.
[0] Not sure what caused it; F2FS may have been less stable than I thought, or the cheap SSD might have lost a bit.
[0] Not sure what caused it; F2FS may have been less stable than I thought, or the cheap SSD might have lost a bit.
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.
Oh, and steam can't remember to keep me logged, but I'd probably blame Valve rather than void for this (very minor) inconvenience.
Nice, my past distros of choice were slackware & archlinux. This feels like a successor to those. I'm sold.
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.
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.
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.
Our initial author, and the primary author of xbps, came directly from the NetBSD community.
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.
Now installing some applications. LibreOffice is version 6 'fresh'. A bit like OpenBSD, installing Libreoffice brings a metric tonne of dependencies.
Edit: you need to install alsa to get sound
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.
echo 'repository=http://repo.voidlinux.eu/current/' \ >
/etc/xbps.d/00-repository-main.conf
Now installing some applications. LibreOffice is version 6 'fresh'. A bit like OpenBSD, installing Libreoffice brings a metric tonne of dependencies.
Edit: you need to install alsa to get sound
xbps-install alsa-utils
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:
http://www.troubleshooters.com/linux/void/voidtips.htm
More articles on Void from the same author, including an install guide:
http://www.troubleshooters.com/linux/void/index.htm
http://www.troubleshooters.com/linux/void/voidtips.htm
More articles on Void from the same author, including an install guide:
http://www.troubleshooters.com/linux/void/index.htm
Thanks.
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.
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.
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.
Hey guys. FYI, Darch (my project) has support for VoidLinux.
https://godarch.com/concepts/recipes/distributions/
https://godarch.com/concepts/recipes/distributions/
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.
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.
I'm having a .... not fun time updating darch to the latest version. Does your makefile still require git, or can I kill that code?
You can remove the git stuff, as long as you are not building containerd and runc as well.
What issues are you running into? The AUR and VoidLinux package don't have an issue. Skype (paul.knopf1) me?
What issues are you running into? The AUR and VoidLinux package don't have an issue. Skype (paul.knopf1) me?
Why does a go get pull in docker and everything else?
I'm trying to clean up the Void package to make it more maintainable.
I'm trying to clean up the Void package to make it more maintainable.
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.
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.
Yeah, when I added the package, I told them the next version will not require vendoring and can be built without git. The next version will do this.
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.
How do people compare this to Alpine Linux? I'm interested in both.
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.
* 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.
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.
IIRC you can install glibc into Alpine when an application needs it but the packages are all musl.
A glibc chroot still seems to be the recommended method: https://wiki.alpinelinux.org/wiki/Running_glibc_programs
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
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
Package manager sounds like a worse version of ~~Nice~~ Nix, but distro's choice of services is neat.
Edit stupid autocorrect. Also further research indicates xbps is way more traditional. Sigh...
Edit stupid autocorrect. Also further research indicates xbps is way more traditional. Sigh...
Why would one use Void instead of NixOS or another Nix-based distro?
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.
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.
"after all the package manager is really just keeping a database of files and unpacking archives onto the disk."
err..... what
err..... what
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.
The matrix background on that page is cool but it does not go past the first page of scroll which sort of ruins the effect.
Without systemd? Shut Up And Take My Money!
For more variety: http://without-systemd.org
"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.
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?
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.
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.
chroot into /emul/linux directory/jail with GNU/Linux libraries, headers and GCC toolchain as Linux binaries, not BSD ones, then build.
There are probably obvious reasons this wont work but without trying I do not know what they are.
There are probably obvious reasons this wont work but without trying I do not know what they are.
Gobolinux is also mostly powered by shell script (i think you may find the odd python and compiled code in there for performance reasons).
/consisting of/s//built from/
/bootstrap scripts/s/scripts/utility/
apologies for being a bit sloppy here
/bootstrap scripts/s/scripts/utility/
apologies for being a bit sloppy 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 :-).