[arch-general] Alternative init system proposal

Ivan parazyd at dyne.org
Mon Feb 8 00:58:19 UTC 2016

Hello, I have a proposal for Arch Linux developers and by mailing
on this list I would also appreciate feedback from non-developers that
use Arch Linux. 
Note: I am not here to hate on the current status, nor
to disapprove of current Arch choices.

So, to get to the point...
I would like to propose development and official support of an
alternative init system and service manager. My main preference would be
OpenRC + sysvinit. The combination of those two has shown to work
surprisingly well even with the current Arch's binary packages which are
compiled with systemd support/dependencies. There are OpenRC packages
already in the AUR, as well as an unofficial repository called
"openrc-eudev" that replaces udev with Gentoo's eudev. See 
http://systemd-free.org for more info. (Please disregard the hate on the 
website, I am not pro-systemd-hate)
Now, I realize this is not the correct way to do this stuff, and if we
an alternative system, a lot of compiling might have to be done, Or is
possible to keep systemd support?

1. Udev... Well, there are two alternatives worth mentioning. The first
obviously, Gentoo's eudev that works really well, and keeps udev
compatibility. Another alternative worth mentioning is vdev
(https://github.com/jcnelson/vdev). It is also maintained in the AUR.
vdev is developed to be completely non-dependent on systemd and I think
it might be a nice option to consider. Note that it is still under

2. Packaging... If current and furure builds are kept with systemd
then there's only the option of including an OpenRC-compatible script in
the same package, along with the systemd.service file, and then
depending on what's used on the machine, install the according one (in
most cases).
Otherwise, new compilation will have to be done, and that brings up the
issue of storage space, which, in the worst case - gets cut in half.
I would need more feedback on this.

2.1. Repositories... core, extra, community and multilib would not need
any -openrc offsprings. If we would build new packages, without systemd
support, pacman would need code modifications to distinguish between the
two - systemd and openrc. An idea is to modify the package naming scheme
somehow, possibly -openrc and -systemd. 

3. Support... The biggest drawback is definitely the support that goes
on in ArchBBS, ArchWiki, Bugtracker and eventually #archlinux on
freenode IRC. 
The ArchBBS and the IRC wouldn't be detriment(?) because they don't
have any *specific* support threads or sections. However, the ArchWiki
need a lot of rewriting/editing, but honestly, the community is big
enough to handle it. As for the bugtracker, it might get a bit more bugs
than usually :D

To conclude, this is still a mere draft and a proposal. I realize that
there are a lot more things to be discussed about this. So, please give
me feedback on all of this and let's see what we can do about it and
what it can develop into...

Kind regards to the entire mailinglist,
~ parazyd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20160208/7b146604/attachment.asc>

More information about the arch-general mailing list