svn commit: trunk/busybox: coreutils coreutils/libcoreutils include etc...

[Manuel Novoa III]

Rainer Weikusat,

On Sat, Sep 10, 2005 at 05:40:44PM +0200, Rainer Weikusat wrote:
> Rob Landley <rob at landley.net> writes:
> > On Friday 09 September 2005 22:58, Rob Landley wrote:
> >> Can you honestly say this checkin is an improvement, or just marking
> >> territory?  (If the latter, please put a big warning at the top of the file
> >> that nobody else is ever to check any changes into this file.)
> >
> > P.S.  Sorry, I'm overreacting.
> 
> Actually, you are not. Each of the points you addressed is valid and
> specifically, all the code I yet had the mispleasure to come in
> contact with written by Manuel is nearly unbelievably crappy,

Oh my...  I haven't heard any complaints from Erik to that effect.
In fact, I haven't heard any complaints from _anyone_ to that effect
other than from you.

> especially wrt 'superflous complexity' that arises as a natural side
> effect when a wrong conception is pushed to its technical limits, ie
> to the point where the code becomes "hard to shrink" because it takes
> an extraordinate amount of time to understand what it is doing how in
> the first place. But this is to be expected when there is never

The two most important qualities of busybox code are (or should be)
correctness and minimal size.  Coding style, comments, documentation,
etc. are all nice.  But they are tie breakers only.

A number of things done in the name of size minimization will naturally
make the code harder to understand.  All of the code I write for either
busybox or uClibc goes through a number of size reducing iterations.
Perhaps this is why you find the code "hard to shrink".

As far as it taking an "extraordinate" amount of time to understand to
my code, that may also be due in part to the iterative code transformations.
Then again, it may also be more a relection on your skill level than mine.

> anything even resembling a rational discussion about the merits of
> some piece of code: It becomes a pure issue of turf and 'the others'
> don't act much different than you do.

There are very few applets in busybox that are complex enough to require
discussion.  And even those generally have a primary maintainer.  Most
often, one person writes an applet, one or more others may do size
reductions, and then the applet stays relatively static unless bugs are
found.

Occassionally, someone may completely rewrite an applet.  If it is smaller
and equally or more correct, it "wins".  Busybox is, after all, about
generating the smallest correct code to implement a particular task.

> Socially and technologically, "open source" is a horrid failure (with a
> few exception, like the Linux-kernel, for instance). It makes a lot of
> sense oeconomically, because while spending a lot of money to have bad
> software written is not very sensible, using this bad software for
> free instead of developing something (equally bad) from fresh makes
> sense.
> 
> Sometimes, the world resembles a piece of shit pretty closely.

If you're aware of any bugs in my code, I'll be happy to fix them.  If
you simply don't like my code, then submit better... where 'better' is
using the busybox metric.

Manuel