On Sat, Jan 19, 2002 at 03:23:59PM +0200, Shlomi Fish wrote: > On Sat, 19 Jan 2002, mulix wrote: > > > why should its maintanence be more scalable and straightforward? > > scalability is a nice buzzword, but so is "quality", "cohesion", > > "direction", which linus supplies in the current system. > > I don't think a scalable solution necessarily compromises on quality, > cohesion and direction.
Why not? We all want cohesion, quality, direction, scalability, reliablity, flexibility, simplicity, and rapid development. Shall we raise the flag of mutiny and demand all those things? You do not solve real world problems by summoning abstract ideals. Mulix and I showed how your suggestion could undermine many of the important qualities of Linux. > A human being cannot effectively replace CVS. A CVS deals with the mechanism of applying patches. Linus deals with the decision of which patches to apply. Two completely different things. > Keeping several distinct > trees is by far inferior to keeping several branches on the same CVS > repository. If the Linux kernel was a 10,000 lines program which mainly > only one person touches the code (as is the case for Freecell Solver), it > can do without CVS. But anything that has a larger codebase or a large > number of developers must use CVS. I don't doubt CVS is an incredible technical convenience. But I don't see how it is relevant to the problems 2.4 had. Care to bring up some concrete examples? [1] > Read item No. 1 in this link: > > http://www.joelonsoftware.com/articles/fog0000000043.html > > to see that I'm not the only person who thinks so. And give me another > example for a project with the scope and number of developers of the Linux > kernel that does not use a source control system. Give me another example for an open source operating system that captured a significant market share. Give me another example for a successful major operating system in the market that is not controlled by a single vendor. Give me another example of successful operating system developed in the last 10 years that uses monolothic kernels. Give me another example of a successful operating system that does not include any management utilities or libraries. I don't see what any of the examples would demonstrate. If you want to talk about Linux, talk about Linux. You say "CVS is good, everyone knows that", but you don't show why CVS is good for Linux, certainly not why it is critically good, which you say it is. SEMA is the classical way to develop top-down software. Linux is the classical bottom-up software development project. The two are inherently and completely incompatible. Actually, I'm not even sure Linux /can/ be developed as top-down. If the source code developemt happens only at the bottom, then it responds to initiative coming from the top. If initiative comes only from the top, so must resources. I know of only two open source projects that really are managed this way -- OpenOffice and Mozilla. Both are very heavily sponsored by commercial interested parties. I've heared suggestions regarding IBM taking over Linux's development, or a consortium of several interested companies. That might actually be pretty good for Linux, and lead to good software developed to meet the needed goals, and remain GPLed. It's just that I much prefer what we have right now. > Linux 2.4.x has everything a UNIXish kernel is expected to have and more. > Yet, there are other features that other people want inside it. I don't > claim, that everything that could have been implemented there is there. > That's why a manifesto is necessary. People so far have placed a > web-server in the kernel, a CORBA ORB, started to implement a JVM, a 2-D > graphics subsystem (GGI), etc. Which of these things is acceptable and > which is not? And generally, which feature that can be propogated to > userland should still be implemented in the kernel. Let me assure you that whether khttpd should or should not be a part of Linux is a much simpler decision to make than whether Rik's rmap patch should or should not be accepted. khttpd is just an add-on that has little impact on the rest of the system. On the other hand, it's totally clear that a VM is something you /do/ expect to have in Linux, as it is one of its fundamental subsystems, and this is precisely the reason why the policy for accepting patches for it is such a sensitive matter. Linux's fundamental subsystems decide its general direction much more than a spiffy new kernel web server does. 2.4 was not delayed due to buggy khttpd or because the ORB wasn't ready. > > linus WANTS to be bothered with any little patch. it's a crucial part > > of his quality control system. > > Linus can take a look at the patch between the CVS repository and what he > checked last time, and pass his comments. And he could do it all the time. So what? Then he'll okay patches he likes, and revert any change he's not yet sure of, and developers would have to recommit them from time to time so that he re-examines their patches. You've changed the mechanism, but kept all the problems. Now, there /have/ been attempts to write software that works according to Linus's development methodology (e.g., BitKeeper), but they have more to do with patch management than source control. > Monolithic kernel != Unmodular kernel. > > By telling how subsystems should communicate with each other, and what > side-effects those communications should have, we can make sure that > everybody is independant of the other developers and can mind his own > business. Well, this is the holy grail of software engineering, is it not? I don't think Linux is there yet, yet it's a precondition for your suggestion. [1] Andrea Arcangeli's new VM, Ingo Molnar's new scheduler, Rik van Riel's fixes to Andrea's VM, Andrea's fixes to his own VM, Andrew Morton's low latency patch versus Robert Love's preemptible patch. ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
