[lkml]   [2001]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Coding style - a non-issue
    [cc list trimmed]

    At 07:30 PM 11/30/01 -0800, Larry McVoy wrote:
    >Yeah, right, Linus. We should all go home and turn loose the monkeys and
    >let them pound on the keyboard. They'll just as good a job, in fact, by
    >your reasoning they'll get there faster, they aren't so likely to waste
    >time trying to design it.

    You are confusing the production of Shakespeare with the production of good
    OS code.

    The high-level design aspect is that there is a problem to be solved or a
    feature to be provided. That represents a goal. Some goals are good and
    some goals are bad. In many cases, you learn which when you actually do
    the code to implement the goal, and determine whether it helps, hinders, or
    just bloats the OS.

    The lower-level design aspect is planning how to achieve the
    goal. Implementation of the lower-level design in code to achieve the goal
    can contain flaws, flaws that don't appear on paper but raise ugly warts
    when you actually try the implementation out. In this sense, this is like
    a mutation to achieve a specific effect -- blue eyes, say -- that has a
    disastrous side effect -- it causes the heart to have a single chamber
    instead of four.

    This assumes that your, um, mutation even lets the organism live. Many
    don't. We call it debugging.

    >I can't believe the crap you are spewing on this one and I don't think you
    >do either. If you do, you need a break. I'm all for letting people explore,
    >let software evolve, that's all good. But somebody needs to keep an eye on

    I don't know you, so I don't know how long you have been in the
    industry. I've watched Unix evolve from the beginning. AT&T streams
    versus Berkeley sockets was a wonderful war, and we are all for the better
    for the experimentation because we got the best of both -- especially as I
    was involved in ARPAnet in the beginning and saw the influence of what
    turned into TCP/IP in both environments. We have different styles of
    system initialization, with some being better for manual management and
    some being better for package management -- and we have both living in the
    world today. The development of X-terminals was fun, too, to try to
    divorce the requirements for a screen from the system that feeds it, and
    yet today the two different processes run together in a single box without
    too much problem.

    These were the products of evolution, of system designers trying to meet a
    need, and the process of getting there was painful and left a lot of
    corpses behind it -- piles of dead code, for sure, but also dead companies
    and burned-out development people. That's part of the business,
    particularly in the commercial world.

    "But someone has to keep an eye on it." Very true. After all, in this
    process of natural selection, how do we weed out the mutations that don't
    work? In the Linux development environment, we have several levels of
    weeding going on. First, there is peer testing -- people downloading
    patches and trying out new things, which weeds out the worst of the
    mutations. Then, there are the maintainers who sit in judgement as the
    patches roll by, picking out the deformed ones bodily and making sure that
    two patches that change the same code play nicely with each other. We then
    have the pre-releases, which for the 2.4 tree were patch-inspected and
    maintained by Linux and by Alan Cox, which people can download and try on
    playpen systems with applications to see if anything subtly nasty crept in
    -- this weeds out a few of the mutations that harm the organism but doesn't
    kill it outright. Finally, we have a production release into which people
    throw all the varied and wacky applications -- and sometimes an ugly (like
    the VM problem) finally is exposed to the light.

    Interestingly, you see a similar development process at commercial software
    vendors and with the successful Open Source projects. Some of the details
    differ (especially the details on the review process) but the overall
    process is similar. Why? It works.

    I suggest you check out this site and specifically
    download this document AND READ
    IT before responding further. While the Software Engineering Body Of
    Knowledge does not use the exact concepts that Linus used in describing how
    things are done, you will find interesting correlations between what is
    described by this document and the idea that you have called "crap."

    Pay particular attention to the section on Validation and Verification.

    Stephen Satchell

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

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