On Wed, Nov 3, 2010 at 7:09 PM, Rob Landley <[email protected]> wrote:
>> > 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.
Ohh, I *gladly* would take patches which simplify these.
Or patches which fix them wrt Unicode. Or both.
> Why are the #error and constant-#ifdefed
> out code in miscutils/last.c there?
Surely you meant:
"I propose removing commented out code here in last.c:
#if 1
/* do we really need to be cautious here? */
n = index_in_strings(_ut_usr, ut.ut_user);
if (++n > 0)
ut.ut_type = n != 3 ? n : SHUTDOWN_TIME;
#else
if (strncmp(ut.ut_user, "shutdown", 8) == 0)
ut.ut_type = SHUTDOWN_TIME;
else if (strncmp(ut.ut_user, "reboot", 6) == 0)
ut.ut_type = BOOT_TIME;
else if (strncmp(ut.ut_user, "runlevel", 8) == 0)
ut.ut_type = RUN_LVL;
#endif
"
[optionally: "here's the patch" or "I will commit the change
to git unless someone objects"]
> Should the flash and nand stuff in
> miscutils have its own directory?
Will this materially change anything?
> And editors/patch*.c probably shouldn't
> have all three files lying around (we have source control history for a
> reason)...
Sure. "I propose deleting files such and such..."
> 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).
All these ideas seem like good ones to me.
> 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...
Well, we have some docs like this. They tend to go out of sync with code.
I propose instead adding a few good, strategically placed comments.
>> 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.
I actually look at code size VERY closely. See my other recent mail
where I show that there is, on average, net reduction in size
since 1.00 on the same config.
I'm just doing it not in Rob's way ("rewrite this crap!"),
but in "let's simplify this crap!" way.
I invite Rob to rewrite any part he likes. Then I will
try to simplify his rewrite. It's a win-win situation.
>> > 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.
New arrivals do help in one area: they reduce dependencies
in LFS-type systems. You know it yourself since that's precisely
the reason you use busybox in Aboriginal Linux:
you want to have fewer packages.
And when busybox acquires a new feature _you_ need, you see it
as a win. (For example, 1.18.x will have brace expansion in hush).
Which makes it more useful. Which is good.
Why you fail to extrapolate your feeling of a win when
*others* submit stuff, and it is accepted? They are in exactly
the same position as you: they don't want to cross-compile
a $HUGE_BLOATED_PACKAGE, so they reimplement or port
part of it to busybox.
Same thing.
--
vda
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
