Nathan Hand wrote:> > > Well, using the current methods have transformed Linux from twenty> or so source files, support only for 386 and IDE drives, truly bad> performance and no TCP/IP, into this kernel that's being seriously> considered as a viable replacement for commercial kernels and even> for embedded systems.    Yes. The whole linux community is proud of it.> > So your suggestion sounds a bit like "don't do what works, instead> do what the text books say". Why change what is working?    But I am not saying "stop whatever you are doing and start afresh.  I am only saying "why can't we do whatever we are doing in an  organised manner". If we can foresee that something is going to   happen that is bad for linux why can't we avoid them in the first  place. Never ever ignore something because it was found in the text  books. The great software engineering models that are found in those  text books are not just an academician's theory that he put forth  sitting in a room. They are all outputs by experienced people who  had bad outcomes from their crude development models.> > You might like to consider Linux as an "experiment" in distributed> software development. Linux encourages multiple redundant attempts> to achieve the same goal. Users are used to test code, rather than> traditional regression testing or faked test environments. There's> no design, no road path, no authority except popular consensus.     Everyone, welcomes this approach of distributed development model.  But it is never a brilliant idea to make redundant attempts. Your  view of the Linux development model is something like Darwin's theory  of evolution. He said "the fittest will survive". But that is nature.  That is how it will happen and it will always happen. But it will  take it's own time to happen. It will not happen whenever we like.  We can't afford to let things happen in Linux. We have to make things  happen.      Regression testing may not be catching everything that is buggy   in the software. But that's not the question of the development  model itself. It is the question of the perfectness of the model.  No engineering model is perfect. But every software engineering model  should tend to be perfect.> > Yet surprisingly these attributes - traditionally seen as the best> ways to waste money or kill software projects - seem to be exactly> what keeps Linux popular. Redundant projects compete, so unpopular> projects die. Users provide orders of magnitude more diversity for> testing. No design or road path allows Linux to adapt quickly.    As I already said without design certainly at some point of time  it is going to adapt but not quickly. It will take its own time.> > Linux isn't an efficient development model, but humans aren't very> efficient animals. The chaotic nature of Linux keeps it strong. If    Nothing chaotic in nature can bring out perfectness in quicktime.> you imposed a different model I suspect you'd kill it.    It would never kill it. It would accelerate it.ThanksJana> > --> Nathan Hand - Chirp Web Design - http://www.chirp.com.au/ - $e^{i\pi}+1 = 0$> Phone: +61 2 6230 1871   Fax: +61 2 6230 4455   E-mail: nathanh@chirp.com.au> > -> 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/-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.rutgers.eduPlease read the FAQ at http://www.tux.org/lkml/