lkml.org 
[lkml]   [2004]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: New dev model (was [PATCH] delete devfs)
    Date
    Paul Jackson wrote:

    > The direction presented to us now is having smaller, more continuous,
    > steps in the head end, over having fewer larger, more disruptive steps.
    > Do we do all the incompatible changes in a big chunk, once every couple
    > of years, or do we do them one a week, ongoing.

    Do I read that correctly? You are suggesting doing big disruptive
    changes every week? I know what you mean, but this is just what many
    people don't want, being told that they have to give up cyrptoloop or
    devfs to get a better scheduler.
    >
    > Now, I repeat, this is at the head end. End users who want stability
    > aren't feeding directly off kernel.org anyway.

    Having been bitten by vendor kernels repeatedly, I would say that some
    are and some aren't. And people who want minor new features like a
    device driver or better scheduler don't want to rebuild a system from a
    base install just to get there. It's one thing to get all the new
    features of a 2.N to 2.{N+2} conversion, but it isn't worth a major
    reconfig to get there.
    >
    > The affect downstream on real users is this. If the head end operates
    > in big chunky style, then as this big change flows downstream, it makes
    > transitions for distros, service providers and middlemen more costly and
    > difficult, creating expenses that must be passed on to the end user.

    Do you suggest that many disruptive changes are less expensive than one
    every few years? There should be something between RHEL "stable for five
    years" and FC2 "run up2date on the hour" models. The stable series has
    been that in the past, and dropping any disruptive change into the
    stable series seems to belie the term stable.
    >
    > Yes - damming up the flow of changes creates stability. But if you're a
    > middleman, you don't need Linus to choose where to build the dam, and
    > when to open the flood gates. It's more efficient for you to choose for
    > yourself when to do that damming, based on your particular resources and
    > customer needs, rather than have to deal with hundred year floods and
    > draughts imposed on you by Zeus.

    So everyman becomes his own vendor, if you want a minor feature you have
    to patch it into an old kernel which still works for you? This is a
    major change from the way stable vs. development has ever worked... It's
    not the pace of little things which troubles me, it's Reiser versions,
    and vanishing cryptoloop and devfs, and things like that which require
    major changes in a system.
    >
    > The end user always gets their stability, if only because they won't
    > upgrade a system that is "working".
    >
    > And every change at the head end is disruptive for some poor slob.
    > The only perfectly compatible change is no change at all. We delude
    > ourselves if we think we can separate the "safe" fixes and additions
    > from the "unsafe" incompatible changes. Better that we should expend
    > some energy on smoothing out and minimizing the cost of change to those
    > downstream from us. This needs to be done the old-fashioned way, one
    > change at a time.
    >
    > The question is whether we impose, on all those downstream from us,
    > occasional hundred year floods, or do we provide a steady stream, and
    > let them build their own little beaver dams, as suits their various and
    > diverse needs and business cycles.

    No matter how you spin it, you are still talking disruptive change over
    and over vs. an occasional major rethink.
    >
    > The great lesson of capitalism over communism is that a thousand free
    > workers and investors, each optimizing their own little plot or
    > portfolio, beats a single centrally imposed five year plan, even if the
    > man pulling the levers is a genius such as Linus or Lenin (sorry, Linus,
    > couldn't resist ...).
    >
    Of course making the end users far more dependent on vendors didn't
    enter into this at all...

    --
    -bill davidsen (davidsen@tmr.com)
    "The secret to procrastination is to put things off until the
    last possible moment - but no longer" -me
    -
    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 14:04    [W:2.587 / U:0.156 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site