OpenRC 0.35 for FreeBSD

[Joe Maloney]

Sorry for the delay in responding, and thanks for the replies.
Specifically OpenRC just adds a couple of neat things like service
supervision, parallel startup, and some interesting features like
service hotplug.  Originally I had planned to respond back with a more
eloquent email covering features, scary things, that had been reviewed
by peers with a higher writing skill than a mere mortal like myself.
Considering the technical challenges I encountered I feel more
inclined to stop here for now, and just wing it with an explanation.

TrueOS has a decent (not perfect) implementation of OpenRC with over
1100 scripts for various ports.  Those were easy conversions.  It
turns out however I underestimated how much work it would be to create
a proper drop in for FreeBSD that meets my standards as an end user.
While trying to deal with dhclient conversion I just found myself
displeased fighting with network.subr race conditions.  This work
didn't even begin to address ipv6 at this point.  I also looked at
integrating dhcpcd which supports ipv6, and ipv4 into base which
TrueOS uses from ports.  However this was beyond my skill level to
write a proper Makefile for that.

For any solution like launchd that requires xml having to write over
1100 in a different format like xml, or ucl vs conversion I think
would add even more overhead than something like OpenRC where most
scripts just work after a few simple modifications.  Then you have
base which was over 100 last I checked.  While I could see the
benefits of FreeBSD adopting something new like launchd with UCL I
think the biggest blocker would be dealing with network.subr.  Maybe I
am wrong but it sure seems that way.  When I looked at runit I think
it didn't provide the same level of per service management from what I
recall but that was years ago.  I am more of a sysadmin if that makes
sense so I have to back away from the keyboard when it requires
reinventing the wheel too much versus planning, and taking on a
project incrementally in phases.

In short.  I underestimated this effort for FreeBSD on a technical
level given my current skillset.  Otherwise on a political level I
would have been have happy to put forth the work in to give talks,
have discussions about various options, and so on which I already have
at various Linux conferences.  The last conference S.E.L.F was very
rewarding where I met one of the co-founders who told me a very
interesting story about the political work required to baselayout 2
into Gentoo.  Prior to that I did not push that hard to get my talks
accepted at various BSD conferences because I wanted to wait until I
had something substantial, and practice giving talks vs just coming to
the table with nothing, and only talking about what is possible.

Anyways I am afraid the TrueOS implementation that I helped with is
the best I can offer for a more proper evaluation at this time than
what I was working on.  I can maybe circle back in another year, or so
to see if this is more do-able.  If so by that time I will be able
provide a better presentation with a comparison of various init
options based on feedback here.  Cheers.

Joe Maloney

On Tue, Mar 6, 2018 at 7:34 AM, Jan Bramkamp <crest at rlwinm.de> wrote:
> On 02.03.18 17:11, Jonathan Anderson wrote:> On 02.03.18 17:11, Jonathan Anderson wrote:> On 02.03.18 17:11, Jonathan Anderson wrote:
>>
>> On 2 Mar 2018, at 12:13, Jonathan Anderson wrote:
>>>
>>>
>>> [...] there are a number of options that I've heard of vying for
>>> consideration:
>>>
>>>  - finit
>>>  - jobd (is this still a thing?)
>>>  - nosh
>>>  - OpenRC
>>>  - runit
>>
>>
>> Oh, and also s6: https://skarnet.org/software/s6/why.html
>
>
> I've run s6 + s6-rc as init replacement for FreeBSD 11.1 on my laptop for
> over a year. The init_path kenv simplifies testing alternative init systems
> a lot. It works really well and required only minimal porting.
>
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"