That is REALLY impressive. Now I should really look into making the changes necessary to package it...

I don't want to brag but with my unorthodox ways I had void-66 since 66 was in beta [66] but it was a pain in the neck keeping up and trying to juggle between two pkg-managers. The bare essentials came from obarun and dependencies came from void, except I think 2-3 pkgs that arch repackaged specially to fit the needs of pacman (curl and something else). But this was plastering the binaries from one to the other, not real void. Arch kernel with mkinitcpio not dracut.

I can't wait to get void-musl and 66 married, to me that would be the ultimate system.

The obarun community will not lose me, don't worry. I am not after a personal system, I am looking for a system that has the potential to send systemd and its supporters back to the jar of the evil ginis. The big corporate people have been winning for so long and in every battle I think it takes a little victory somewhere to turn the moral around. I see a system based on musl, with s6 and 66 being of weapon grade.
You would have to admit, with void as a base you can sleep easier. With arch you never know what will be thrown at you, when you wake up, and have things breaking faster than you rebuild them. Am I wrong? You can be Platini but they can keep moving the goal posts around.

by the way, inside the dracut space of void, there is this thing called systemd-udev, is this part of eudev?

HHHhhmmmm.... :)
I think unintentionally, trying to get the damn thing to boot I discovered some area of the system I had no idea existed, but it made some sense. Of course things can make sense, like falling inside a lagoon full of water, knowing how to swim and climb rocks to get out is another story :)

fungalnet wroteby the way, inside the dracut space of void, there is this thing called systemd-udev, is this part of eudev?

dracut in voidlinux uses eudev (see the depends array in the template).

Yes I know it is eudev, but inside that dracut pre-booting area there is label systemd-udev :)

Welcome.
Those posts you refer to reddit and sysdfree are outdated now, because boot-66serv has really become boot@ -66serv and is a module service. See the obarun wiki on modules and boot module in specific.

I know of bedrock but haven't tried it, with void I am a bit more familiar.
The basic configuration different between obarun and void in terms of services is where they are placed, /usr/lib/66 in obarun /usr/share/66 in void. With boot, as I found out, if you just copy obarun's to /usr/share/66/service it fails because within it there is a use of the script module.sh which is directed to /usr/lib instead of /usr/share, otherwise it is identical with what void's teldra has created.

https://github.com/teldra/void-packages/tree/66-boot/srcpkgs/boot-66serv

You can build it into an xbps package or just copy the stuff from the git to the appropriate locations. I've used it for glibc and musl. It works great. Read the contents of the 66 script and try to understand what it does. This is teldra's solution so you don't have to remove anything runit related from void and it would be easy to switch back. Basically it moved the runit powerfunctions out of the way and makes room for the s6 functionality and you can revert if you didn't like s6/66. Basically he is trying to make it into a compatible pkg within void, so there would be no conflicts.

https://github.com/mobinmob/void-66-services

The 2nd link is by mobinmob
and has services that work on void without modification, they are a bit simplified compared to Obarun's to blend better with runit simplicity.

The configuration of the boot@ module is just the same as in the Obarun wiki, but if you have the old boot-66serv (non-module) make sure to remove it before using this. Also tty@ -66serv is required because on the new module tty12 becomes tty@ tty12 using that script, while the rest of the tty is defined within the module as tty-rc@ tty*** and in the module script you can define between 0 and 11 ttys.

Monbinmob is the void expert and I have to admit I have avoided void lately, after getting 66 to work, just the presence of elogind in the repository and its link to a whole load of crap averts me :) But I don't use consolekit either, so it doesn't change anything from me, just the feelings from void were hurt.

I do admit to using xbps on arch and pacman to void with a few things I can control their dependency conflicts, or little script packages, but there are strict religious people who scream "policy" to me about such things, so I'll be quiet.

Void has in its blood a history. Void had systemd before debian did, correct me if I am wrong. Void has been eager in taking down content that connects it with its past. Its forum is gone ... now the wiki is discontinued and replaced by a workmanual. For all I know their perceived forum reddit../r/void might be gone, serving as a support forum. Nowhere in void's official documents does it say "we will not utilize systemd AGAIN!". Like we say here, don't put too many eggs in your basket. Ok, realistically I don't expect it to. But I didn't expect or could understand this "removal" of ck2 and converting all ck dependencies to elogind, or its continuous support for Gnome.

Ataraxia I think was musl based and non systemd, and it is now patching systemd to use in musl! Just 3 months ago the author was asking me why I didn't add it to the new list of linux without systemd, and I did, then took it out again! :)

I like kiss-linux k1ss.org declaration, front page, right in the middle, no systemd no elogind! Clear and loud commitment.

To each his own ... I suppose. Since they started dancing in that rhythm they will be chasing their tail everytime some gui/DE gadget utilizes YET another feature of systemd ... patching and redirecting .. and more. All this because it was meant to save them work from upstream stuff asking for logind and libsystemd.

The virus will keep crawling deeper and deeper.

Is an old thread but I consider interesting to say that it seems that void supports now seatd. You don't need elogind anymore (that's the theory, of course).

I think this works complimentary to systemd/elogind I don't think it is a replacement for logind. I haven't read much about it, I wonder if it is a biproduct of a BSD effort to port wayland to their environments.