lkml.org 
[lkml]   [1996]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectA Humble Suggestion for 2.0/2.1
Date
Attached is a post from linux.dev.net which brings up a good point in the 
context of "What should we do differently next time".

Dennis of etinc is a BSD bigot, and that's ok. Good or bad, BSD does
twice the packets per second that Linux does, and it is a more logical
choice for a PC-based router. (This is not to slight any of the
networking crew for Linux; Van Jacobson is a hard act to follow, and no
one expects that we will surpass BSD overnight. Everyone expects that
we will eventually, but that's a different post.)

(etinc makes T1 cards that slide into an ISA or PCI slot, allowing you to
treat a T1 just like a modem connection, sort of. Basically, they save
you tons of money if you have a T1, because the cards are a _whole_ lot
cheaper than an analogous cisco. This makes them cool.)

Nonetheless, etinc does support Linux, and they make a very good product. I
think that Dennis' criticism should be given due consideration.

The interim between 1.2.13 and 2.0 was _way_ too long. Linus admitted as
much when he was at a loss to describe the new features since "I haven't
used 1.2.13 in so long", or something to that effect.

Why wasn't 1.2.14 turned out around the time of 1.3.59? 1.3.57 or 1.3.59
were both certainly good enough, and there was a _ton_ of stuff that people
really wanted to have but couldn't.

If the changes between 1.2 and 1.3.57 were too great for it to be called
1.2.14, then a 1.4 should have been released.

Whether it's a favorite app or a critical driver or sheer timidity,
people are often loathe to turn to the experimental kernels. Plus, we go
to great lengths throughout the documentation to dissuade them from using
the experimentals.

Next time, I think it would be a good thing if we (Hi, Linus!) were to
release stable kernels with a higher degree of regularity. There are a
number of process-control ways of doing this, and how to do it really
isn't the point. If it can be done by people other than Linus, then we
should look at that; if Linus has to do it, then we should all be willing
to help, both with whatever parts of the kernel we work on and in general
testing/pounding/bug-reporting.

Development is a whole lot more fun than that "production" stuff, but I
think it hurts our goals if we stray too far from our main userbase (all
of whom we have told in no uncertain terms *not to use the developmental
kernels unless you have the iron nerves of a fighter pilot*.)

I think that we did stray too far from the 1.2 crowd in the latest
cycle. I think it would be very good for all concerned, while maybe a
little less fun, if we stuck a little closer to them during the next one.

$0.02

_____________________________________________________________________
Todd Graham Lewis Core Engineering Mindspring Enterprises
tlewis@mindspring.com (Standard Disclaimers) (800) 719 4664, x2804

---------- Forwarded message ----------
Date: Thu, 13 JUN 1996 18:53:32 -0400
From: Dennis <dennis@etinc.com>
Newgroups: linux.dev.net
Subject: Re: Bug in 1.2.13 firewall?

Hey. Give me a kernel that works and we'll do a port ......

(snippity)

I love this! No stable new kernel for over a year and you're blaming the
board vendor because you don't have source......The card isnt the problem,
the problem is that there is no stable kernel that has the features you
want. Dont blame the board vendor for that one. We have always promptly
supported the releases...its just been soooo long that you dont remember.

>Your customer will figure out in time that binary only drivers were a dumb
>thing to buy ;)

or than Linux was the wrong O/S :-)


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.049 / U:0.616 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site