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 _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox