Date: Sun, 25 Mar 2018 00:29:14 -0400 From: Joe Maloney <jmaloney@ixsystems.com> To: freebsd-hackers@freebsd.org Subject: Re: OpenRC 0.35 for FreeBSD Message-ID: <CAFvkmYN7SCmUr2sfV7g0w4BA1i5qTQeK3yqAOqZkV60%2BS9a%2BOg@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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@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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFvkmYN7SCmUr2sfV7g0w4BA1i5qTQeK3yqAOqZkV60%2BS9a%2BOg>