bunzip2 fails to decompress pbzip2-compressed files

Rob Landley rob at landley.net
Tue Nov 2 20:57:05 UTC 2010


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

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, but 
there's just so much of it.  And it keeps accumulating, and nobody else seems 
to mind.

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.

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