lkml.org 
[lkml]   [2002]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [linux-usb-devel] Re: [BK PATCH] USB changes for 2.5.34
    Date
    From
    [Cc:'s mercilessly chopped down]
    Daniel Phillips <phillips@arcor.de> said:

    [...]

    > Linux is WAY WAY far from being a really nice development environment.
    > It's really nice in many other ways, but not in that way.
    >
    > For example, there is no excuse for ever needing more than 1/4 second
    > to get from the function you're looking at on the screen to its
    > definition and source text, ready to read or edit.

    There are tools able to do so... nothing kernel-related.

    > There's no excuse for having to copy down an oops from a screen by
    > hand, either. It's nice to know you can fall back to this if you have
    > to, but having that be the default way of working is just broken.

    Yes, I had to do that a (very) few times, when the machine went south and
    logging was dead before. But is is not the "default way" by any long shot.

    > There's no excuse for having to pepper low level code with printk's
    > to bracket a simple segfault.

    It is no excuse to make _every_ kernel out there slow just for the
    hypothetical case it might crash sometime. Be optimistic, man! ;-)

    > OK, I'll stop there. Actually, the only thing I'm really irritated
    > about at the moment is the attitude of people who should know better,
    > promoting the fiction that this veggie-zen-tools-made-out-of-wood
    > thing is actually helping the kernel progress faster.

    Who said it makes the kernel progress faster? Kernel progress' bottleneck
    is the few people who know it in and out, and so are in position to decide
    on the patches presented to them. (It also depends on the scarcity of
    kernel architects, and no thanks, a comittee doing that work would get me
    to run away from Linux _very_ fast indeed; but that is irrelevant here).

    Now, the productivity of the head developers/integrators is as high as the
    average quality of the patches they get. If Aunt Tillie and her sisters get
    a kernel debugger and start spewing off "Set to a random non-NULL value so
    it doesn't crash" patches kernel development will grind to a halt.

    Yes, debuggers have their uses. But the ones I've used on userland programs
    were much, much less useful than you seem to think. Sure, it is nice to be
    able to check on the values in a data structure to find out how it got
    screwed up, but that's it (and that is a very occasional use for me, when
    other approaches have failed). And a kernel Oops usually gives you enough
    to work that out.
    --
    Dr. Horst H. von Brand User #22616 counter.li.org
    Departamento de Informatica Fono: +56 32 654431
    Universidad Tecnica Federico Santa Maria +56 32 654239
    Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:28    [W:0.026 / U:0.152 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site