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.
> 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
>>> - 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.
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[hidden email]"