I installed Void Linux on my new laptop this May, switching from Arch, which I'd been using for about six years. The experience is very positive overall. For desktop, I'm using AwesomeWM and NetworkManager, altho Void comes with a variety of options to choose from.
I were afraid that their Wiki is not detailed enough, and expected that some packages could be missing. However, I could easily install everything I needed from the repository (except flashplugin). TeX is installed slightly differently, but the wiki entry helps here. Regarding documentation, DuckDuckGo does not show search results from Void Wiki, so I have to use Google search instead. Documentation seems sufficient, and where I need more, I can refer to Arch wiki.
With Arch, all services seemed automatically enabled when the packages were installed, otherwise you had to use systemd commands for configuration, which seemed a bit opaque to me. In Void, which is using Runit, enabling a service (like alsa, crond, cupsd, etc) is a matter of creating a symlink, which feels very transparent and reliable. I think, I like the idea of keeping the information about your services in the plain view in the filesystem. I have never been a configuration guru, so prefer this transparency and simplicity, and it felt robust so far.
> In Void, which is using Runit, enabling a service (like alsa, crond, cupsd, etc) is a matter of creating a symlink, which feels very transparent and reliable.
It's exactly the same in systemd, although people usually use systemctl. It will report what it does:
$ sudo systemctl enable sshd
Created symlink /etc/systemd/system/multi-user.target.wants/sshd.service → /usr/lib/systemd/system/sshd.service.
I belive his point is that you actually use "ln -s" to activate a service, instead of it being done by some utility, without you knowing what else it might have done too.
I'm using arch right now, and I can't think of any packages that automatically enable their own service. I could argue for the usability and transparency of systemd, but I won't. Simply because I think it is really important that alternatives to systemd exist.
I personally like systemd as a init system and service manager, but think it is bundling too much. Variety is not just the spice of life, its needed for a health ecosystem.
As for void linux, does it have anything close to the AUR in terms of package availability?
I'm in a weird position on systemd. I like it as an init system and I like journald and logind (not that I'm very knowledgeable about logind).
However, I really dislike the bundling that is happening in systemd-world. It feels almost like an embrace - extend - extinguish approach, only for 'software opinions' as opposed to profit.
Sadly, this has become a very political debate, and I don't have first hand experience, so much of my opinion is based on biased second-hand accounts. Though I try to get accounts that are biased both ways.
Note that the primary impetus was actually not necessarily that archlinux has degraded in quality over the years ever since Judd was no longer in charge, but primarily that systemd interferes with everything.
I have this suspicion that the author may still be a happy archer, but systemd made him reconsider. And archlinux made a deliberate decision to switch to systemd without alternatives, so I really can not hold anyone but the new archlinux developers responsible for that.
Projects often change with the "under new management" syndrome - that is inevitable.
> Sadly, this has become a very political debate
This is only partially true. While I agree that there is a lot of conflict between pro-and-con systemd, the major issue is that some random guys here and there decide - and subsequently dictate - onto everyone else THEIR particular mind view. And I think that this is the much more upsetting thing.
> so much of my opinion is based on biased second-hand accounts.
Many who dislike systemd do so not because of "political reasons" but of REAL PROBLEMS THAT THEY HAVE ENCOUNTERED.
I also encounted this, such as an infinite loop of systemd at boot-up time. And I had no patience to want to debug any of it. Went back to slackware again, true and tested; it is only a base for LFS/BLFS for me though. If anyone asks, I rather use GoboLinux - but I also can not recommend anyone currently to use GoboLinux until a few more things have been resolved. It's still the best by far.
There is nothing wrong with slackware per se, mind you. It's a bit slow in its development taste for my taste ... but it is still the closest towards "oldschool linux".
Many years ago, I bought a red hat set of CD and SuSE. Installed both... had a GUI. Knew nothing what to do.
Then I installed debian. I think it was woody or potato back then... xorg did not work, but the commandline worked, so I worked through the old handbook learning *nix. :-)
That was great!
Since systemd, I no longer touch anything of debian. devuan is the true successor here - the debian devs abandoned the users.
Until then, I can recommend voidlinux for one reason - I actually know a few people who HAVE been using it since quite some time among them this famous dude:
And I know a few more ruby-folks who are still using archlinux but may consider switching. I may try to convince jhass for example ... ;) - although I do have to say, voidlinux needs a bit more polishing still.
Yeah, I might be wrong when saying that services are automatically enabled in Arch.
My understanding is that Void has xbps-src [1], [2] for installing packages from source code, and it is somewhat similar to AUR. Xbps-src package database is essencially a github repository, you clone it and use it to build and install packages for your system. I installed it and used only once to build some obscure video streaming program, which failed to compile, and I did not follow up to figure out why it failed.
The difference would probably be that while anyone can add (or update) a package to the AUR, the xbps-src maintainers have to explicitly allow this. On the one hand it makes it harder to start contributing, but on the other hand, there is a minimum level of quality that is maintained. After a while you get used to it though, and ultimately updates are processed pretty quickly, especially if the submitters know what they're doing.
>The difference would probably be that while anyone can add (or update) a package to the AUR, the xbps-src maintainers have to explicitly allow this.
Nothing is preventing other users to fork or start their own void-packages repo on any git hosting service of their choice. In that sense it's actually more open to contributors than the AUR. Now the experience for the end user might not be perfect if they don't know that such a repo exists.
But you can do the same with the standard arch repositories too. The (intended) advantage of the AUR was precisely that people don't have to create their own repositories that are hard to trust and have to be updated all the time, can fall out of maintenance, and only the original creator can access (quasi like Ubuntu PPA's - which I personally hate). That's not to say that the AUR has no downsides, but what you're describing wouldn't make it better, imo.
I were afraid that their Wiki is not detailed enough, and expected that some packages could be missing. However, I could easily install everything I needed from the repository (except flashplugin). TeX is installed slightly differently, but the wiki entry helps here. Regarding documentation, DuckDuckGo does not show search results from Void Wiki, so I have to use Google search instead. Documentation seems sufficient, and where I need more, I can refer to Arch wiki.
With Arch, all services seemed automatically enabled when the packages were installed, otherwise you had to use systemd commands for configuration, which seemed a bit opaque to me. In Void, which is using Runit, enabling a service (like alsa, crond, cupsd, etc) is a matter of creating a symlink, which feels very transparent and reliable. I think, I like the idea of keeping the information about your services in the plain view in the filesystem. I have never been a configuration guru, so prefer this transparency and simplicity, and it felt robust so far.