lkml.org 
[lkml]   [1999]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [Call For Wartectomy] CRLF conversion out of kernel
    In <7mj0ns$bjf@pell.pell.portland.or.us> david parsons (o.r.c@p.e.l.l.p.o.r.t.l.a.n.d.o.r.u.s) wrote:
    > In article <linux.kernel.19990714223326.L2120@loth.demon.co.uk>,
    > Steve Dodd <dirk@loth.demon.co.uk> wrote:
    >>On Wed, Jul 14, 1999 at 11:48:40AM -0700, david parsons wrote:
    >>
    >>> Sure, you can do things the MS-Windows way and arbitrarily break
    >>> compatability from one version of Linux to the next (certainly this
    >>> would be nothing new -- software engineering died of a buzzword
    >>> overdose early in the 1990s -- but it would be nice to be able to
    >>> recommend Linux in terms more glowing than "well, it's Unix, I
    >>> guess.")
    >>
    >>So we gradually let the project die under the weight of years of accumulated
    >>cruft instead?

    > Get back to me in a decade and ask the same question.

    Hmm. Interesting idea. Just we need answer slightly earlier then in a decade :-((

    > Broken behavior in one filesystem is not the "weight of years of
    > accumulated cruft".

    It's just application of "general principle": if cleanups will broke things
    they must be postponed for next stable release of kernel. Not more. If thay
    are ready and working that is :-)

    >>It's good to clear out (some of the) cruft in a major revision; if you
    >>don't like it then may I kindly point you at 2.2.10, or 2.0.37, or 1.2.13.

    > Hey, if I could take 2.2.x device drivers and plug them into
    > 1.2.13, I'd do that and get 220k back on my install floppies.

    If you need it then you'll need some other OS. Not Linux.

    > But, oddly enough, there have been 4 releases of the kernel since then
    > with 4 different device driver interfaces (and nothing but paranoia
    > and contempt for any attempts to publish a driver interface), so
    > nothing will work without massive hackery.

    To me it looks like just application of general principle, nothing more.

    > But why the devil should I reward sloppy coding practices by taking
    > all my toys and playing with a different crowd? Even if Linux
    > wasn't Unix's only hope, there are massive benefits to making it
    > easy to upgrade to new kernels.

    So far noone suggested ANYTHING better then implement-try-and-reimplement
    style of development. Of course you can (and SHOULD) try to avoid as much
    uglyness as possible but in the end story is always the same: something was
    not taked into account when API/driver interaface/cacheing sysbsystem/whatever
    was developed. Better to have well-established way to eliminate obsoleted/ugly
    things in planned fashion then try to keep all accumulated cruft... You MUST
    expect breakage when upgrading from 1.2 to 2.0, from 2.0 to 2.2, from
    2.2 to 2.4 and so on...




    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

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