On Monday 01 November 2010 02:05:51 Denys Vlasenko wrote:
> On Sunday 31 October 2010 23:17, Rob Landley wrote:
> > On Thursday 28 October 2010 16:10:35 Denys Vlasenko wrote:
> > > On Friday 22 October 2010 20:07, Dan Fandrich wrote:
Snip
>
> Obviously, different people are good at (slightly) different things
> (optimize for -O2 versus optimize for -Os etc);
> and also they like different styles (while(1) versus for(;;),
> // versus /* */, 4-char tabs versus 8-char ones, placement of {},
> levels of optimizations ("how ugly are we ready to make our code
> to squeeze out that last microsecond/byte"), etc etc etc.
>
> How to make them cooperate even though they do not 100% agree on
> "how to do things"?
Hi,
Once upon a time there was something as style-guide.txt
for this issues.
> "Everyone goes to his own corner and play only with his toys" is
> a solution, yes, but it does not scale: you can't reimplement
> everything, not alone, not in one lifetime. If you do want
> to reimplement coreutils, util-linux, etc, + libc + maybe even bits
> of kernel, you have to work with other people.
>
> You don't have to work with really nasty guys (let's not point
> at well-known examples here), but OTOH you can't expect people
> will magically code in a way which is EXACTLY matching
> your views of proper balance between "simple", "clean", "fast",
> "small", "compatible" etc without (at a minimum) receiving
> your comments. How would they know they strayed away from
> "one true path"?
Usually it is the maintainer to guide the development and say what is in and
what is out
and then there is the goal of the specific project that shows the direction.
Sometimes it is not very clear to me anymore what the goal of busybox is
nowadays,
but maybe it's just due to the fact I am self-taught and lack the experience of
the other
list members.
In the past you could tell it in a few words:
1)small (in the sense that we jump through hops to save a few bytes)
2)simple ( Can't say what this means: usually code is simple for the one who
wrote it and obfuscated for others ;-) )
3)no-non standard features :
"When in doubt about the proper behavior of a Busybox program (output,
formatting, options, etc.), model it after the equivalent GNU program.
Doesn't matter how that program behaves on some other flavor of *NIX; doesn't
matter what the POSIX standard says or doesn't say, just model Busybox
programs after their GNU counterparts and it will make life easier on
(nearly)
everyone."
4)it is for linux (so we don't care about other oses) and gcc (so we don't car
about other compilers).
I can say for sure that in beginning the code was simple for me as I learned
C programming on the busybox mailing list after reporting a bug in the strings
applet to Erik Andersen and he told me to fix it and was very patient in
reviewing
all the segfaulting patches i submitted until it was really fixed.
Have to thank him for this as it opened to me the world of computing.
Due to this fact I'am a little sentimental abut busybox and that's why
i felt the need to partecipate in this OT² discussion.
Ciao,
Tito
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
