[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: anyone interested in bringing launchd to BusyBox?
From:       Bartosz_Gołaszewski <bartekgola () gmail ! com>
Date:       2015-11-16 21:43:37
Message-ID: CAFdkumgOA4wa0OawsgSeSniR4-z8LbzzB4XWduBEb=Rbhanj5Q () mail ! gmail ! com
[Download RAW message or body]

2015-11-16 11:06 GMT+01:00 Laurent Bercot <ska-dietlibc@skarnet.org>:
>
>  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.

Has it been discussed at all? I can't find anything regarding it and
I'm pretty curious as to what caused the angry commit message.

Best regards,
Bartosz Golaszewski

>  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



-- 
Best regards,
Bartosz Golaszewski
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]