anyone interested in bringing launchd to BusyBox?

[Laurent Bercot]

  The technical impact of Denys's change was actually extremely small,
which is the main reason why it was not discussed (much) on the list.

  The change was meant to send a political message, and it has done so
quite successfully. The message is: Busybox will not yield to
aggressive expansionism.
  The message is not "Busybox needs a new init system" or "Busybox needs
a service manager".

  So far Busybox has done a good job of focusing on mechanism and
keeping away from policy decisions or endorsing a system more than
another. (And even though I like the model and have personal
interests in seeing it spread widely, I think adding tcpserver and
runit as busybox applets was unwise, because contrary to that
agnosticism.)

  I would like it to remain that way, *especially* when it's about
such a politically heavy weighted subject as a service manager.

  Busybox is useful when it's about providing clean, small
implementations of standard tools other implementations of would be
too big to fit on embedded platforms.
  Good system software will naturally compile and fit into integration
projects without needing to be rewritten and be provided as a part of
Busybox. It is true for runit, it is true for the s6 family of tools,
it may be true for relaunchd (if you remove the build-time Ruby
dependency).

  Integrating that kind of software into busybox has no technical benefits,
it only serves to advertise the project; and that is unfair both to
competitors who refrained from attempting to get aboard the Busybox
train, and to Busybox users who have no wish to see their tool of choice
become a battleground for popularity contests and political agendas.

-- 
  Laurent