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)? 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. It should be
nearly balanced with the removed code. But removing code seems to be
actually harder than writing new code.
but
> there's just so much of it. And it keeps accumulating, and nobody else seems
> to mind.
>
I wouldn't say 'nobody'.
> 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).
> Rob
Thanks,
Marek
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
