bunzip2 fails to decompress pbzip2-compressed files

Rob Landley rob at landley.net
Wed Nov 3 18:09:54 UTC 2010


On Tuesday 02 November 2010 20:26:50 Marek Polacek wrote:
> Although I should probably stay away, since I'm quite new here...
>
> On 11/02/2010 09:57 PM, Rob Landley wrote:
> > On Sunday 31 October 2010 20:05:51 Denys Vlasenko wrote:
> >> How to make them cooperate even though they do not 100% agree on
> >> "how to do things"?
> >>
> >> "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.
> >
> > Tell me about it. :)
> >
> >> If you do want
> >> to reimplement coreutils, util-linux, etc, + libc + maybe even bits
> >> of kernel, you have to work with other people.
> >
> > Everything, everywhere, is broken, even the stuff I write, and I just
> > want to make it less broken.
> >
> > Charles Babbage invented the computer in about the same way Thomas Savery
> > invented the steam engine; it wasn't really useful for quite a while.  In
> > 1939 Howard Aiken dug up the idea and make it barely practical, and
> > ushered in the mainframe age, which was our equivalent of the steam
> > locomotive.  Ted Hoff's microprocessor in 1969 was about like Henry
> > Ford's assembly line, allowing mass production of the S-100 CP/M machines
> > and Model T, respectively.
> >
> > These were incredibly primitive technologies, which we look back on and
> > laugh in other contexts.  But in our case, the guys who did it are still
> > alive. It's that new.
> >
> > Today computers are _maybe_ up to the era of fins and chrome and
> > gas-guzzling land sharks over in the automotive context.  Back when you
> > no longer needed to _be_ a mechanic to own a car, but you needed to know
> > a good one just to keep the thing going.
> >
> > I look around the computer industry and know for a fact that we will look
> > back on this and laugh.  That is the attitude with which I approach
> > programming. The state of the art is transitional crap we need to outgrow
> > as fast as possible.
> >
> >> 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"?
> >
> > Busybox needs the equivalent of kernel-janitors.  A group of people who
> > focus not on adding features but on cleaning up what's already _there_.
>
> Yes, I suppose so.
>
> > I thought it was inherent in the mandate of the project, but apparently
> > not. The focus these days is on features, adding more and more, always
> > making the project bigger and more complicated.
> >
> > I look around and everywhere see things that aren't that hard to clean
> > up,
>
> Which ones (except those mentioned in TODO)?

It's sort of a constant background thing.

If you want a specific example, there's bound to be a way to simplify 
editors/vi.c.  Or miscutils/less.c.  Why are the #error and constant-#ifdefed 
out code in miscutils/last.c there?  Should the flash and nand stuff in 
miscutils have its own directory?  And editors/patch*.c probably shouldn't 
have all three files lying around (we have source control history for a 
reason)...

editors/diff.c is kind of egregious, although I'm biased here because I studied 
up on Brahm Cohen's "patience diff" algorithm meaning to implement it in 
toybox, which is both simpler _and_ produces better results.

  http://bramcohen.livejournal.com/52148.html
  http://en.wikipedia.org/wiki/Patience_sorting
  (See _patiencediff_py.py in the bzr source code.)

Or finish converting the applets to the new inline config and makefile stuff.  Or 
finish converting the test suite to a single unified infrastructure (it has 
something like three).

Or write up some documentation for libbb and what's in it.  Or document how an 
applet actually gets launched now that "main.c" went away from the top level 
and the applet launch code is now incongruously buried down in an obscure 
libbb file...

> Maybe I could pick up the
> easy ones.  I'm involved in busybox only a few months and I'm not very
> satisfied with the fact, that I mostly only _added_ code.

Eh, you're not alone.

> It should be
> nearly balanced with the removed code.  But removing code seems to be
> actually harder than writing new code.

Yup.  I've had various .sig quotes over the years to that effect.  Ken 
Thompson's about one of his most productive days being when he got to delete 
1000 lines of code, and the guy who wrote "The Little Prince" saying that 
perfection is achieved not when there's nothing more to add but nothing more 
to take away...

> > there's just so much of it.  And it keeps accumulating, and nobody else
> > seems to mind.
>
> I wouldn't say 'nobody'.

It is no longer the majority opinion.

> > Unfortunately, as you point out, I already have way too many demands on
> > my time.  And wandering by and picking at it for an hour or two every
> > other week won't even keep up with new accumulations of cruft, let alone
> > deal with the backlog.  Heck, you're currently implying that the problem
> > is entirely in my head, that I'm just too picky.  Maybe so.
> >
> > On a related note, I don't know what the project's mandate is anymore. 
> > The last proposal on celinux-dev before the Linux Foundation gobbled up
> > CELF was "add kexec-tools functionality to busybox".  All fine and good,
> > but where does it stop?  I asked myself "ok, by current standards, what
> > would be a command that _shouldn't_ go into busybox?"  And I can't answer
> > that anymore.  I don't know where the boundaries are.  As far as I can
> > tell, there aren't any.
> >
> > I've come to the conclusion I'm not helping here.
>
> From my point of view, you _are_ helping.  In your own way 8).

No, I'm telling _myself_ to "shut up and show me the code".

I just don't see it making a difference here with the amount of time I have to 
put into it.  It's like trying to mop up a river, the new arrivals bury any 
small gains I could make.

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.


More information about the busybox mailing list