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