OT bunzip2 fails to decompress pbzip2-compressed files

[Denys Vlasenko]

On Monday 01 November 2010 10:21, Tito wrote:
> 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 

Of course. However, good maintainer has to listen to others,
and fish out useful things he did not think about/did not notice/etc.
Don't let power (to accept/reject patches) to corrupt himself :)

Conversely, contributors should try to, well, contribute.
Yelling "this whole thing is wrong and stinks!"
is not exactly very useful. It allows frustration to vent, yes,
but it doesn't contain constructive proposal.

Sligtly better version is: "what is this in file foo.c on line NUM?
It's wrong and stinks! Why on earth is it there?" - it does point out
something specific which is supposedly wrong. However, I would prefer
that it be phrased differently - without implying that the author
of said thing is an idiot (even if he it - does it help when you
call him idiot?), and also it does not contain the proposal
how to make it better.


> 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)

Still a goal


> 2)simple ( Can't say what this means: usually code is simple for the one who wrote it and obfuscated for others ;-)  ) 

Exactly. What is simple for me is not simple for Rob.
But this is still a goal, and if more people help
to make it simpler, the better. Patches are more useful
than yelling that "this whole thing is getting complicated,
ugly! Why??? AAA!!!!"


> 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."

Yes, still a goal. That's why uname -D was replaced by -d: to match
"standard" tool. I see how it could be done better. I bet Rob also
could have a few proposals, but he was occupied with venting
his frustration and he forgot to direct his thinking into
the direction of "ok, this is wrong, Denis is an idiot, but how
would I want this mess improved, exactly?"... hint hint ;)


> 4)it is for linux (so we don't care about other oses) and gcc (so we don't car about other compilers).

Well, I don't see this as a useful goal.

If patches to support something non-Linux are sent,
and they don't contradict other three goals
(meaning: they add very little complexity - hundreds of new ifdefs
in almost every file are definitely no-no) then they can be accepted.


-- 
vda