Busybox and standards/direction

Glenn McGrath bug1 at iinet.net.au
Sun Dec 11 13:10:05 UTC 2005

Trying to state the issues as i see it...

Standard always exists, its just "standard" behaviour, peoples
behaviour changes over time, so for any definition of a standard to
have meaning it needs to change also.

When trying to _define_ a standard there will always be people who
think this should be in the standard or that shouldnt be in it. So
multiple standards can be defined at the same time targeting different

Busybox's demographics has been those wanting a minimal runtime
environment, and to a much smaller extent a minimal build environment.

AFAIK GNU is backward compatable with SuS, so SuS is definetly a good
standard to aim for, it caters to our demographics.

As much as we aim for SuS we do need to be able change the behaviour of
specific applets so users can have a system suited to them, wether its
GNUism, old SuS behaviours or whatever.

I guess im not a pragmatist, because i dont see the relavence of how
cheaply we can implement default functionality that shouldnt be default.

But the the real question isnt what you or i think should or shouldnt be
in there, but how do we give users the ability to customise
functionality without creating an overly complex configuration system ?

We cant give users more choices of behaviour without asking more
questions... so i think we have to accept busybox is always going to be
complex to configure.

Perhaps one thing we could do is group all the SuS utilities together
into their own menu, that way any generic configure options related to
obsolete SuS behaviour (e.g numeric arguments) would be isolated... not
sure if that would make any difference.

It would be great to have a testsuite that would check standards
conformance, but i suspect there owuld be years of work in developing
it. Ideally such an effort would be supported by other utilties
projects as well.


More information about the busybox mailing list