Ntpd config file support

[Mike Dean]

On Tue, Mar 18, 2014 at 3:15 PM, Harald Becker <ralda at gmx.de> wrote:

> Hi Mike !
>
> >... We work hard to make things easy for them.  One of the
> >stumbling blocks our customers have had in the past is how to
> >configure ntpd to use their internal ntp servers.  Helping them
> >with this usually results in grumbling about it being
> >overcomplicated to perform what should be such a simple task.
>
> This clearly a failure of your system/distro NOT Busybox. Your
> build system shall provide a script to read address of your time
> server from a file and use this address when calling the ntpd
> daemon applet. So customers can be pointed to changing a line in
> a file.
>
> So the deficiency of your software can always be blamed on your software's
userbase?  Sounds like a winning philosophy.


> >isn't added.  It's not worth the time or effort for me to edit
> >your code to add this.  I've simply been trying to point out
> >that catering to your users is the most important thing to do if
> >you want to keep them from jumping ship.  This may be one small
> >portion of Busybox, but it's one of about 20 that we've already
> >replaced with full versions for our upcoming release;
>
> You are always free to replace Busybox functionality with full
> versions. Busybox is neither a system nor a build system nor a
> distro. It is a collection of smaller and simpler counterparts
> than the usual full GNU and other utilities (Beside that there
> exist other alternatives). The intention here is to have SMALL
> binaries using the KISS (keep it simple and small) principle.
> Adding unnecessary config file functionality without other
> benefit violates this KISS principle. Everything can be achieved
> with setting up your right script ... not by the customer, by
> the system/distro maintainer.
>
> >shortcomings in the busybox versions aren't worth the savings in
> >size in the days of GHz processors and 512MB+ RAM on small cheap
> >embedded systems.  They're not even worth the savings on our
> >lowest end 200 MHz models; even those have a minimum of 128MB of
> >RAM.
>
> I know ... "640 kByte RAM ought to be enough for everybody" ???
>
> ... think of there are still more small systems out there, e.g.
> small router boxes with very limited resources. Busybox shall
> give small and simple tools for most users not a versatile system
> for your customers.
>
> If you use Busybox, make it versatile to your customers by
> creating right control scripts and system setups including
> full documentation, and not pointing them around to collect
> information from other places, e.g. up to date version of
> Busybox.html from build (not from Web-Page).
>
> > I'm just trying to get you to see things from the standpoints
> > of the people in this chain who've all clamored in favor of
> > the feature.
>
> I don't say you are wrong, but you are at the wrong place to
> bother. Busybox is not a complete and easy to use system, it is
> just a collection of small and simple alternatives of other
> tools. Use it, when you like and build your system with it, but
> don't add useless code to main binary (for thing easily being
> achieved by other ways).
>
> > ... I'll just use the full version instead and not worry about
> > it.
>
> Fine, you are always free to do this. Depending on kind of system
> I replace from 30 to 75% of Busybox with full or alternative
> versions, using Busybox versions as small and fast scripting
> versions.
>
> --
> Harald
>

My choice to switch stems not from having any difficulty scripting an
alternative, but rather from the lack of trust I have in the busybox
version given my opinion of the decision made by the developers regarding
something that should be a clear cut easy choice.  In my job, when the
customers want something, you find a way to give it to them.  If adding the
feature outright would bloat the system, you make it a configurable choice
so that it won't add bloat where that bloat is unwelcome, but will aid
those who value the convenience more than the space savings.  You already
have the means to do this easily, so why not do it?

When was the last time this mailing list received so many e-mails in one
day?  Especially about just one topic?  That alone should have been a red
flag to you that the users of your software feel that this is important.
 Religious zealotry about a development concept has never led to good
products; engineering (and any software development) is all about trade
offs.  Your unyielding zealotry, instead of facing the challenge of make
the trade off to satisfy the needs of your userbase, combined with you
blaming others for your own shortcomings, is what inspired me to make the
switch.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20140318/09a31965/attachment.html>