Re: The Great Kernel CVS Mutiny
- Original Message - From: Adi Stav [EMAIL PROTECTED] On Thu, Feb 07, 2002 at 02:20:37PM +0200, Tzafrir Cohen wrote: BTW: there is a little non-free license issue with BitKeeper. From what I understand, the license of BitKeeper is basicaly a free license, but requires that you preserve one feature: logging to a certain main reposirtory. snip Anyway, kernel people use it, so people probably don't care. Linus doesn't care, but Linus never had any ideological or even snip It bother /me/, though, especially as I can't see much commercial gain Larry Mcvoy can get by those restrictions. snip Of course he gets commercial gain - companies who want to use BitKeeper and don't want the open logging feature (and show me one manager who want balk at the very idea of data about his internal development efforts circulating on the internet) will be required to buy a license. if BitKeeper was free as in GPL, then said manager wouldn't be required to purchase a license, and some (or most ? or all ?) will not. Oded -- No violence, gentelman -- no violence, I beg of you! Consider the furniture! -- Sherlock Holmes = 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]
Re: The Great Kernel CVS Mutiny
On Sat, 9 Feb 2002, Oded Arbel wrote: - Original Message - From: Adi Stav [EMAIL PROTECTED] On Thu, Feb 07, 2002 at 02:20:37PM +0200, Tzafrir Cohen wrote: BTW: there is a little non-free license issue with BitKeeper. From what I understand, the license of BitKeeper is basicaly a free license, but requires that you preserve one feature: logging to a certain main reposirtory. snip Anyway, kernel people use it, so people probably don't care. Linus doesn't care, but Linus never had any ideological or even snip It bother /me/, though, especially as I can't see much commercial gain Larry Mcvoy can get by those restrictions. snip Of course he gets commercial gain - companies who want to use BitKeeper and don't want the open logging feature (and show me one manager who want balk at the very idea of data about his internal development efforts circulating on the internet) will be required to buy a license. if BitKeeper was free as in GPL, then said manager wouldn't be required to purchase a license, and some (or most ? or all ?) will not. Actually, their license is basically you can change anything you want, but the software has to pass some regression tests that include logging to our server. Why not take the approach of gnu to posix-compliance: Many programs are not posix-compliant, unless you set the environment variable POSIXLY_CORRECT . You could have an optional --dont-log-with-main-server switch wihtout or NO_LOGGING_TO_MAIN_SERVER environment variable. Just a silly thought. -- Tzafrir Cohen mailto:[EMAIL PROTECTED] http://www.technion.ac.il/~tzafrir = 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]
Re: The Great Kernel CVS Mutiny
he actualy is, but he is more control freak than anything else. one person deciding all about the kernel.. no one knows everything well enough to do it certanly not him.. Ely Levy System group Hebrew University Jerusalem Israel On Wed, 6 Feb 2002, Shlomi Fish wrote: On 6 Feb 2002, Oleg Goldshmidt wrote: Well, it seems that The Great Kernel CVS Mutiny led Linus to BitKeeper... http://slashdot.org/article.pl?sid=02/02/06/1341250mode=thread I should add that by CVS I meant any decent source control system and BitKeepter seems to fit this description. This is definitely good news. I don't know what role my post played in Linus' decision, though. The point of the mutiny was that people should have abandoned the original way of maintaining the patches, regardless of Linus' approval. But now that he uses it himself, there isn't much point in it. It's good to know Linus is not as senseless and stubborn as I believed he was, originally. I discovered other things I don't like about the waythe kernel was maintained since the original mutiny call, but they are relatively minor in comparison to using a source control system. Regards, Shlomi Fish There is no IGLU Cabal! They had to maintain a codebase the size of the Linux kernel, and could not use a source control because the project leader was religiously opposed to it. This caused disorder and confusion, and nobody thought of starting The Great IGLU Cabal CVS Mutiny. -- Oleg Goldshmidt | [EMAIL PROTECTED] If it ain't broken, it has not got enough features yet. = 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] -- Shlomi Fish [EMAIL PROTECTED] Home Page: http://t2.technion.ac.il/~shlomif/ Home E-mail: [EMAIL PROTECTED] Let's suppose you have a table with 2^n cups... Wait a second - is n a natural number? = 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] = 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]
Re: The Great Kernel CVS Mutiny
there is no kernel of any OS that I know that only one person decide usualy there are few people and a voting involved. not mention that not EVERY patch goes to the that person Ely Levy System group Hebrew University Jerusalem Israel On Thu, 7 Feb 2002, Shlomi Fish wrote: On Thu, 7 Feb 2002, Ely Levy wrote: he actualy is, but he is more control freak than anything else. one person deciding all about the kernel.. no one knows everything well enough to do it certanly not him.. I have to disagree here.I know that Linus is the ultimate authority on what goes into the Linus' kernel and what stays out. I also know there are several other trees floating around. I think someone has to decide what goes in and stay out of there, and it might as well be him. When one is working on any software project with a large codebase, there should be an architect who decides what features or re-factorings will be done and when. One of my OS programming rules states that The number of items on a project's to-dolist always grows or remains constant. One cannot put everything possible in the Linux kernel at the same time, and survive to tell the tale, you have to say something like: ReiserFS in, kdb out, asynchronous IO - never, feature X - will be postponedto the 2.7.x development tree. I'm not entirely happy with all of Linus' technical decisions regarding the kernel, but someone has to be the kernel architect. Using a source control system enables having the rejected or temporarily rejected patches in a separate branch, which helps making sure that maintaining a common codebase is not a hopeless situation. I'm not sure if it's a very good analogy, but I also have to make decisions on what goes in and stays out of the current Freecell Solver development tree. I sometimes get feedback from other people (usually power users or those who look or use the code) that a certain feature should be implemented before the rest. But the final decision is mine. It could be a bad analogy because it's a much smaller code base than the Linux kernel or similar projects, and I'm practically the only one who modifies the code. Incidently I don't use a source control system but rather keep an archive for every version. I'd like to start using CVS, though, but it's not critical IMO, because of the reasons states above. Regards, Shlomi Fish Ely Levy System group Hebrew University Jerusalem Israel On Wed, 6 Feb 2002, Shlomi Fish wrote: On 6 Feb 2002, Oleg Goldshmidt wrote: Well, it seems that The Great Kernel CVS Mutiny led Linus to BitKeeper... http://slashdot.org/article.pl?sid=02/02/06/1341250mode=thread I should add that by CVS I meant any decent source control system and BitKeepter seems to fit this description. This is definitely good news. I don't know what role my post played in Linus' decision, though. The point of the mutiny was that people should have abandoned the original way of maintaining the patches, regardless of Linus' approval. But now that he uses it himself, there isn't much point in it. It's good to know Linus is not as senseless and stubborn as I believed he was, originally. I discovered other things I don't like about the waythe kernel was maintained since the original mutiny call, but they are relatively minor in comparison to using a source control system. Regards, Shlomi Fish There is no IGLU Cabal! They had to maintain a codebase the size of the Linux kernel, and could not use a source control because the project leader was religiously opposed to it. This caused disorder and confusion, and nobody thought of starting The Great IGLU Cabal CVS Mutiny. -- Oleg Goldshmidt | [EMAIL PROTECTED] If it ain't broken, it has not got enough features yet. = 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] -- Shlomi Fish[EMAIL PROTECTED] Home Page: http://t2.technion.ac.il/~shlomif/ Home E-mail: [EMAIL PROTECTED] Let's suppose you have a table with 2^n cups... Wait a second - is n a natural number? = 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] -- Shlomi Fish [EMAIL PROTECTED] Home Page: http://t2.technion.ac.il/~shlomif/ HomeE-mail: [EMAIL PROTECTED] Let's suppose you have a table with 2^n cups... Wait a second - is n a natural number
Re: The Great Kernel CVS Mutiny
On Thu, 7 Feb 2002, Ely Levy wrote: there is no kernel of any OS that I know that only one person decide usualy there are few people and a voting involved. designed by a comittee is *not* a compliment. not mention that not EVERY patch goes to the that person neither should every patch go to linus. see recent patch penguin thread on lkml. /me vows to stay out of pointless, meaningless, gossip driven, fact lacking threads for at least 24 hours. -- mulix http://vipe.technion.ac.il/~mulix/ http://syscalltrack.sf.net/ = 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]
Re: The Great Kernel CVS Mutiny
On Thu, 7 Feb 2002, mulix wrote: On Thu, 7 Feb 2002, Ely Levy wrote: there is no kernel of any OS that I know that only one person decide usualy there are few people and a voting involved. designed by a comittee is *not* a compliment. comittee? more like crow see other kernels as every favor of BSD solaris irix hurd... or do you think linux kernel is better designed?:P not mention that not EVERY patch goes to the that person neither should every patch go to linus. see recent patch penguin thread on lkml. that was my POINT. /me vows to stay out of pointless, meaningless, gossip driven, fact lacking threads for at least 24 hours. -- this is no rumors it's based on what linus said in replaying to the patch penguin thread on lkml Ely = 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]
Re: The Great Kernel CVS Mutiny
On Thu, 7 Feb 2002, Ely Levy wrote: there is no kernel of any OS that I know that only one person decide usualy there are few people and a voting involved. not mention that not EVERY patch goes to the that person 1. Linus's linux is just a kernel, not a complete OS (as oppsed to the BSDs . Hurd seems to focus on kernel development and applications porting, and reply on the debian repository) 2. Linus has the final word on what goes into the official kernel tree. But the kernel is distributed under the GPL, and this means that anybody is free to fork it. Practically most linux distros have their own forks, which sometimes include substaintial changes to the linus tree. I avoid getting into more technical arguments. This topic has been discussed in many places lately. BTW: there is a little non-free license issue with BitKeeper. From what I understand, the license of BitKeeper is basicaly a free license, but requires that you preserve one feature: logging to a certain main reposirtory. I wasn't able to figure out what happens if your system is not connected to the internet (or, OTOH, if it is maliciously tricked to believe that this main server is unavailable). Anyway, kernel people use it, so people probably don't care. For more information: http://lwn.net/1999/features/BitKeeper.php3 http://www.bitkeeper.com/Sales.Licensing.Overview.html -- Tzafrir Cohen/\ mailto:[EMAIL PROTECTED]\ / ASCII Ribbon Campaign Taub 229, 972-4-829-3942, X Against HTML Mail http://www.technion.ac.il/~tzafrir / \ = 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]
Re: The Great Kernel CVS Mutiny
Tzafrir Cohen [EMAIL PROTECTED] writes: 2. Linus has the final word on what goes into the official kernel tree. But the kernel is distributed under the GPL, and this means that anybody is free to fork it. And IIRC Linus has gone on record many times encouraging forking. I am not entirely sure it is a Good Thing (TM). -- Oleg Goldshmidt | [EMAIL PROTECTED] If it ain't broken, it has not got enough features yet. = 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]
Re: The Great Kernel CVS Mutiny
Well, it seems that The Great Kernel CVS Mutiny led Linus to BitKeeper... http://slashdot.org/article.pl?sid=02/02/06/1341250mode=thread -- Oleg Goldshmidt | [EMAIL PROTECTED] If it ain't broken, it has not got enough features yet. = 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]
Re: The Great Kernel CVS Mutiny
On 6 Feb 2002, Oleg Goldshmidt wrote: Well, it seems that The Great Kernel CVS Mutiny led Linus to BitKeeper... http://slashdot.org/article.pl?sid=02/02/06/1341250mode=thread I should add that by CVS I meant any decent source control system and BitKeepter seems to fit this description. This is definitely good news. I don't know what role my post played in Linus' decision, though. The point of the mutiny was that people should have abandoned the original way of maintaining the patches, regardless of Linus' approval. But now that he uses it himself, there isn't much point in it. It's good to know Linus is not as senseless and stubborn as I believed he was, originally. I discovered other things I don't like about the way the kernel was maintained since the original mutiny call, but they are relatively minor in comparison to using a source control system. Regards, Shlomi Fish There is no IGLU Cabal! They had to maintain a codebase the size of the Linux kernel, and could not use a source control because the project leader was religiously opposed to it. This caused disorder and confusion, and nobody thought of starting The Great IGLU Cabal CVS Mutiny. -- Oleg Goldshmidt | [EMAIL PROTECTED] If it ain't broken, it has not got enough features yet. = 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] -- Shlomi Fish[EMAIL PROTECTED] Home Page: http://t2.technion.ac.il/~shlomif/ Home E-mail: [EMAIL PROTECTED] Let's suppose you have a table with 2^n cups... Wait a second - is n a natural number? = 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]
Re: The Great Kernel CVS Mutiny
I discovered other things I don't like about the way the kernel was maintained since the original mutiny call, but they are relatively minor in comparison to using a source control system. Regards, Shlomi Fish I would like to read about those other things you dislike as it gives me a chance to learn about the development of the kernel. I do not follow it at all and the posts here are a great source of information. -- Shaul Karl email: shaulka(at-no-spam)bezeqint.net Please substitute (at-no-spam) with an at - @ - character. (at-no-spam) is meant for unsolicitate mail senders only. = 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]
Re: The Great Kernel CVS Mutiny
On Thu, 7 Feb 2002, Shaul Karl wrote: I discovered other things I don't like about the way the kernel was maintained since the original mutiny call, but they are relatively minor in comparison to using a source control system. Regards, Shlomi Fish I would like to read about those other things you dislike as it gives me a chance to learn about the development of the kernel. I do not follow it at all and the posts here are a great source of information. Unfortunately, I only follow the kernel development from second hand sources (LWN, and posts of people who are LKML members). I've requested the sys-admins of vipe.technion.ac.il to arrange for me to have some arrangement so I'll be able to read the LKML messages there, but it has not been put forth yet. You can check the Linux-IL archives, (in the Great Kernel CVS Mutiny thread) and read my comments to see what I suggested and what LKML members who are members of Linux-IL too, said actually takes place in the development of the Linux kernel. But I'm not sure if I can effectively pass judgement on a system which I don't have a first hand familiarity with, so I suggest you to let my comments rest. I still stand by my original criticism regarding the lack of use of a source control mechanism, because I believe it is obvious that a project with the scope and number of developers as the Linux kernel cannot effectively function without it. This is a common software engineering knowledge, I believe. Regards, Shlomi Fish BTW, my fellow project taker for the IP-Noise Project is now working in Elbit on writing Assembler code for a Digital Signal Processor. Strangely enough, his team does not use a central source control system. He got used to working with it, because we used CVS for our project, so he installed Visual SourceSafe on his NT workstation, and uses it independently, but not all the team is aware of the importance of using source control mechanisms. The project head said they may use a centralized CVS or something like that for their next project. I still find it strange that there are teams in Elbit that do not use a Source Control mechanism. I only started to seriously use CVS for IP-Noise, and since then I also started using it for some of my homework. Now I think that source control kicks ass, and I think Linus Torvalds will eventually find it a life-saver too. I can't imagine working on a team without using it. -- Shaul Karl email: shaulka(at-no-spam)bezeqint.net Please substitute (at-no-spam) with an at - @ - character. (at-no-spam) is meant for unsolicitate mail senders only. -- Shlomi Fish[EMAIL PROTECTED] Home Page: http://t2.technion.ac.il/~shlomif/ Home E-mail: [EMAIL PROTECTED] Let's suppose you have a table with 2^n cups... Wait a second - is n a natural number? = 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]
Re: The Great Kernel CVS Mutiny
On Sun, Jan 20, 2002 at 08:33:33AM +0200, Shlomi Fish wrote: I disagree with your claims. And by raising the flag of mutiny I do not intend to demand them. I intend to implement a system that will make them a reality. This is a productive mutiny, in which people do something instead of just whine, attack, or spread FUD. I know you disagree with our clainms. Again: why would your suggestion not lead to a reduction in kernel coherence and quality as we described? Like I said, I believe it's impossible for Linus to pass his decision for each and every patch that goes in. OK - whether the VM should be replaced - should be ultimately his decision. However, if there's a patch to the VM, then the VM maintainer or its architect should be able to apply it without consulting LT. Alright. Right now it is Linus who is the maintainer of the VM. Can you suggest someone who would do the job better? As of now, from what Moshe Bar said, there were many patches, which fix important bugs, and were rejected by Linus, since only he has an ultimate repsonsibility on what goes into linux-2.[45].x-vanilla. Moshe said that the S.u.s.e kernel had 200 patches to apply. By definition (according to the Joel test which I referenced) the kernel should be at any point bug-free. This is why using a CVS and delegating responsibility for applying patches is a must. I don't think you completely understand the nature of VM debugging. More often than not, it's not a straightforward business like Oops, NULL pointer dereference -- I forgot to initialize, where it's very clear both where the bug is and what the fix does. VM debugging can, perhaps, more often be described as tuning. No VM can behave perfectly, or even well, in all circumenstances, so the simplistic goal of bug free does not apply. Instead, the VM hackers try to have the system general enough and yet respond well to all reasonable cases. That's very hard to do because you can't really know in advance which tuning directions truely solve the problems and which only appear to do so due to the by-definition limited range of behavior models that the developer's initial testing covered. That was exactly the problem with Rik's original 2.4.0 VM -- it appeared to be perfect, but the larger user base introduced by the even version number uncovered serious problems with it. So you can't really separate the global policy making with taking in VM patches when it comes to VM tuning. Thinking, in advance, which VM patches would improve the system in the long run and which would not require such qualities as complete understanding of the entire system, complete understanding of the usage patterns by userspace code and by users, consulting the contradicting suggested ways to solve the problem, ability to weigh the existing arguments and testing results for and against a patch, and, of course, a great deal of intuition. I doubt that in the last months before he passed the kernel on to Marcelo Linus did much for the kernel other than just this. Now, you can say his judgement was mistaken in some choices, perhaps he should have been more aggressive in accepting patches or less aggressive at other times. But if Linus didn't do this job, someone else would still have to. You can't evade that. 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. These are all non-sequitors. I don't see how they are derived from the original request for an example. They intend to show that the existence or the lack of an example of other projects working similarly to Linux has no relevancy to the issue at hand, unless one is willing to consider every uniqueness of Linux a weakness. My article referenced the Joel Test, which Joel Spolsky claims is a better alternative than SEMA. I don't know if the Joel Test is about top-down or bottom-up software. In fact, I think it applies to software in general. It can't be used with the bottom-up development model as it requires writing code according to a specification and a schedule. My model can be used whether for bottom-up or top-down software development. No, it cannot. Your model assumes that the role of the top developer is to direct the project (since that is his only way to control it), while in a bottom-up approach the top developer /selects/ a direction from among the many suggsted by
Re: The Great Kernel CVS Mutiny
[/me replies against my better judgement. oh well] On Sat, 19 Jan 2002, Shlomi Fish wrote: I believe that the way things are done in the kernel development have to change in many ways to make its maintainance more scalable and straightforward. There should be: 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. 1. CVS. why? you haven't given *one* compelling argument why kernel hackers need a cvs. as adi aptly put it, linus is a cvs with taste. no source control system will replace him. 2. Roadmaps for the next stable release - what goes in, what stays out, etc. sometimes there is. it's posted on linux-kernel periodically by linus, usually in a rather crude form. (bio in, kbuild not yet, etc). 3. A general, short, manifesto that explains what Linus thinks the kernel should have and what not. (I.e: should it have a sound subsystem? Should it have GGI? Should it have an in-kernel GUI?). Just kidding about the GUI part. i think it's pretty obvious what should be in a unixish kernel and what shouldn't be. 4. Maintainers of different subsystems who may delegate authority to other people. we have that. 5. Making sure Linus need not be bothered with any little patch. Linus can read the CVS diffs if he'd like, but people can commit changes without asking him. linus WANTS to be bothered with any little patch. it's a crucial part of his quality control system. 6. Defining well-defined interfaces for the subsystems to interact with each other, and explaining what should or should not be done. this is called a micro kernel, unlike linux, which is a monolithic kernel. Did I miss anything? I believe what I proposed is better than the ways things are done now. yes, you missed quite a lot. for starters, explain why your system will be better than the system we have now, which is not perfect, but works. i also get the feeling you are not very familiar with the way linux kernel development is done, except from second and third hand sources. may i suggest you take some time to *learn how its done now*, before proposing a Grand Novel Absolutely Better Way of Doing Things? also, this subject has been hashed to death on lkml. maybe you should read an archive or three? -- mulix http://vipe.technion.ac.il/~mulix/ http://syscalltrack.sf.net/ = 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]
Some re-thoughts (was: Re: The Great Kernel CVS Mutiny)
After writing my previous message about the subject, I have other thoughts. The problem, which triggered the mutiny discussions, is the fact that Linus was not always prompt in accepting bugfix patches. So some subsystems remained buggy (even if there was no dispute which bugfix patch to accept). As a result, the 2.4.* kernel series earned the nickname Kernel of Pain. Today, the official policy is that 2.(2n).* series are for bugfix patches, and 2.(2n+1).* series are for new features. But Linus himself didn't follow this policy religiously. I suggest to change the method of operation, so that two kernel development processes will go in parallel. One of them, to be managed by Linus himself, and it will concern itself with new features, with directing the future of kernel developments. Also, non-obvious bug fixes would go into it (I mean those fixes, which need judgement by Linus). The other process will concern itself with bug fixes and stabilization of Linus' kernel. Essentially, it would be an outgrouth of what the Distributions are already doing. People would test the kernel, apply patches and tinker with it until it is stable. Once in a while, the products of both processes will be merged together: Linus will take a stable kernel and start accepting new-development patches against it, discarding the previous (unstable) kernel from the development series. After a while, people will start a kernel stabilization process from Linus' work. The differences, relative to today's 2.(2n).* vs. 2.(2n+1).* approach would be: 1. At any moment of time, there will be both stabilizing and development kernels at the bleeding edge. 2. Linus will concern himself only with development kernels. --- Omer There is no IGLU Cabal. It is being restructured, and people are still looking for the best way to structure it. WARNING TO SPAMMERS: see at http://www.zak.co.il/spamwarning.html = 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]
Re: The Great Kernel CVS Mutiny
On Sat, 19 Jan 2002, mulix wrote: [/me replies against my better judgement. oh well] On Sat, 19 Jan 2002, Shlomi Fish wrote: I believe that the way things are done in the kernel development have to change in many ways to make its maintainance more scalable and straightforward. There should be: 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. One cannot maintain a piece of software of the scope of the Linux kernel without using CVS. Like I said, I now also uses CVS for preparing my SICP homework, which consists of very small Scheme programs, and a TeX document. Moshe Zadka told me that he uses CVS for every C program he writes at home. 1. CVS. why? you haven't given *one* compelling argument why kernel hackers need a cvs. as adi aptly put it, linus is a cvs with taste. no source control system will replace him. A human being cannot effectively replace CVS. 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. Read item No. 1 in this link: http://www.joelonsoftware.com/articles/fog43.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. 2. Roadmaps for the next stable release - what goes in, what stays out, etc. sometimes there is. it's posted on linux-kernel periodically by linus, usually in a rather crude form. (bio in, kbuild not yet, etc). OK, then it can be deleted from the mutiny. 3. A general, short, manifesto that explains what Linus thinks the kernel should have and what not. (I.e: should it have a sound subsystem? Should it have GGI? Should it have an in-kernel GUI?). Just kidding about the GUI part. i think it's pretty obvious what should be in a unixish kernel and what shouldn't be. 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. 4. Maintainers of different subsystems who may delegate authority to other people. we have that. OK, but I'll explain what's wrong with this system. Continuing the analogy of Moses and the Israelites: what we currently have is that the Israelites consult the Sarey Asarot. They in turn take _all_ of their problems to the Sarey Meoth, who in turn take all of them to the Sarey Alaphim, who in turn do it to the clan leaders. Eventually, Moses has to OK all of the problems the Israelites encountered. By using CVS, a maintainer of a subsystem can commit his changes without Linus having to OK everything that goes in and out there. 5. Making sure Linus need not be bothered with any little patch. Linus can read the CVS diffs if he'd like, but people can commit changes without asking him. 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. At the moment what we have is something like a directory traversal in which each directory has forked its own thread, and they all echo its output to one pipe, which happens to be Linus Torvalds. I don't think it is scalabale. 6. Defining well-defined interfaces for the subsystems to interact with each other, and explaining what should or should not be done. this is called a micro kernel, unlike linux, which is a monolithic kernel. 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. Did I miss anything? I believe what I proposed is better than the ways things are done now. yes, you missed quite a lot. for starters, explain why your system will be better than the system we have now, which is not perfect, but works. i also get the feeling you are not very familiar with the way linux kernel development
Re: The Great Kernel CVS Mutiny
Even though off-topic (as was the whole of this thread), I can't stop myself to say a few things: 1. The first, and most important: I was subscribed to lkml for a few weeks, and quickly unsubscribed. I do read every issue of Kernel Traffic (http://kt.zork.net), since issue 1 (three years ago), and recommend that to anyone interested. A few pages a week, and I have yet to find an important thing in this thread that wasn't mentioned there (with real quotes, unlike in here). 2. What do you want from Linus? Would any of you want to invest 10 years in some project, many of them as a _hobby_, and suddenly someone comes and tells you do this and do that? The fact is, he is quite good at what he is doing. That's why there is not yet any danger of another linux fork getting a large market share. I think this will only happen if (when?) big Unix vendors dump their own and move to Linux (and hopefully, will make a single server version, not like the current Linux distros that have their own sets of patches). (On a second read, I guess RH's kernel has a market share larger than Linuses, but you see my point). 3. About odd-even minors: In addition to what others have said, and to quotes from Linus (which I read on KT), as I see things, this is no different from other OSes. Almost nobody regards a first released version of any OS (or any large program, for that matter) as Enterprize-Mission-Critical-Bullet-Proof-Whatever-Ready. When you get such a release, if you are interested, you install it for testing, playing, etc. You put it on your Multi-Million- Dollar-Companys server only many months after that, when you are comfortable with it and hope that the really bad problems got fixed (and you installed and tried the fixes). Linux is the same. The only difference is that you also get all the development versions prior to release. And since those are usually very good (I personally ran 2.4.0-preXX for many months before 2.4.0 and most of them were very good). This makes people expect that the X.even.0 version will be perfect. Well, life is different. In real life, the number of people trying pre- versions is considerably smaller than those using released versions, and that makes it simply impossible to test all the different configurations and find all the bugs. Linus makes a .0 when he thinks it is ready for regular people (that is, regular Linux users, not normal sane people). Then another bunch of bugs are discovered and solved, and when it stabilizes, Linus gives it to a maintainer. This time was a bit different because of the known VM thing, which I won't talk about (but will only remind that it was a known issue well before 2.4.0 - read KT issues around Jun 2000 - issues 70-80). Conclusion: 4. In short - if you want to use Linux for an important server, count from the maintainers' first version. I will personally trust very much 2.4.18 or .19 (at home I still use 2.4.7-linus). Proof: Alan got 2.2 around 2.2.12 (can't find for sure, but latest 2.2-ac was 11), and 2.2.14 was a great kernel (proof: 2.2.15 was 4 months later - the biggest interval between 2.2.x versions until between 19 and 20). (and BTW - 2.2.14 was almost exactly a year after 2.2.0, and the 'stable' 2.4 will hopefully be 1.1-1.3 years after 2.4.0 - not that bad, despite the VM fiasco). Just my 2 agorot, and excuse the long and boring mail (I couldn't resist), and to make it a bit on-topic, Uri's last name (from Compaq) is Leibovitch (Thanks for the lecture organization, Uri! , although I guess you do not read this. Maybe someone at Compaq will forward), Didi = 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]
RE: The Great Kernel CVS Mutiny
Without repeating or attaching what was said, I think that a simple approach would do the trick. Linux as opposed to corporation politics is an evolutionary organism were the strongest and best survive. There is no need for any mutiny, if Linux wasn't working well the organism would take steps to correct itself. As an example, if the Linux community would overwhelmingly believe that linus judgment threatens the welfare and advancement of the kernel they would fire him, or in another words: would declare him senile and put him in a home and just fork to another child ;). Anyway, for any big change like CVS the community would have to have a huge incentive to change, because in nature, anything that works don't change. Until Microsoft or the US will declare war on Linux I don't see anything changes. So, calm down your enthusiasm, think for a minute, and undestand that there is just not enough insentive for a change. Only the NEED is debateable. If it's not broken, don't fix it! :) * - * - * Tzahi Fadida [EMAIL PROTECTED] Fax (+1 Outside the US) 240-597-3213 * - * - * - * - * - * 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]
Re: The Great Kernel CVS Mutiny
On Sat, 19 Jan 2002, Adi Stav wrote: 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. I disagree with your claims. And by raising the flag of mutiny I do not intend to demand them. I intend to implement a system that will make them a reality. This is a productive mutiny, in which people do something instead of just whine, attack, or spread FUD. 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. Like I said, I believe it's impossible for Linus to pass his decision for each and every patch that goes in. OK - whether the VM should be replaced - should be ultimately his decision. However, if there's a patch to the VM, then the VM maintainer or its architect should be able to apply it without consulting LT. 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] As of now, from what Moshe Bar said, there were many patches, which fix important bugs, and were rejected by Linus, since only he has an ultimate repsonsibility on what goes into linux-2.[45].x-vanilla. Moshe said that the S.u.s.e kernel had 200 patches to apply. By definition (according to the Joel test which I referenced) the kernel should be at any point bug-free. This is why using a CVS and delegating responsibility for applying patches is a must. Read item No. 1 in this link: http://www.joelonsoftware.com/articles/fog43.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. These are all non-sequitors. I don't see how they are derived from the original request for an example. 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. My article referenced the Joel Test, which Joel Spolsky claims is a better alternative than SEMA. I don't know if the Joel Test is about top-down or bottom-up software. In fact, I think it applies to software in general. 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. My model can be used whether for bottom-up or top-down software development. 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. I'm not saying Linux should become a %100 industrial project. But we can at least be rational and change the model in which it
The Great Kernel CVS Mutiny
I've just been to Moshe Bar's lecture, which was an excellent lecture. One of the things that were said in the beginning is that Linus Torvalds has become inefficient in accepting important patches made to the kernel. For instance, Moshe said that he has cron job that sends a group of patches to Linus every week. Linus has prepared a procmail rule to throw it to the garbage. And naturally, he refuses to use CVS, which makes it hard on everybody. I always thought it was not good that Linux is not managed with a CVS server. But the situation as it is calls for immidiate action. That's why I'm organizing The Great Linux Kernel CVS Mutiny. I call for a benevolent developer to place the source code of the Linux kernel in CVS, and for all developers who has nothing against CVS to use it to maintain their code. When Torvalds releases patches those patches (or their aprpropirate portions) will be applied to the CVS tree. We can call this tree the linux-2.5.x-cvs tree... ;-) Now, even if Mr. Torvalds frowns upon this methdology, the other developers will still have the benefit of not having to cope with his caprices. I can testify that CVS is a great tool and one wonders how he lived without it. I used CVS for my IP-Noise project (which eventually produced a Linux kernel module) and am using it now for doing my homework in the Technion Structure and Interpretation of Computer Programs course. I believe Linus Torvalds will not regret it, if he switches to CVS. However, I don't think we should suffer because of his unwillingness to reach this conclusion on his own. Please propogate this message further. Regards, Shlomi Fish P.S: Note that I'm not raising the CVS it myself because: 1. I'm not an expert kernel developers. 2. I have better things to do than to become a part of the core Linux kernel team. 3. I believe I'm still entitled to make important suggestions for re-organization. -- Shlomi Fish[EMAIL PROTECTED] Home Page: http://t2.technion.ac.il/~shlomif/ Home E-mail: [EMAIL PROTECTED] Let's suppose you have a table with 2^n cups... Wait a second - is n a natural number? = 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]
Re: The Great Kernel CVS Mutiny
Heard about BitKeeper? Ingo uses it, as well as other people. Linus is actually thinking to use it once larry mcvoy will finish implementing some features (other people who use it are RedHat, IBM among others) Hetz = 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]
Re: The Great Kernel CVS Mutiny
linuxppc uses BitKeeper also. DaveM (Sparc, Networking maintainer) uses CVS. Hetz Ben Hamo wrote: Heard about BitKeeper? Ingo uses it, as well as other people. Linus is actually thinking to use it once larry mcvoy will finish implementing some features (other people who use it are RedHat, IBM among others) Hetz = 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] = 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]
Re: The Great Kernel CVS Mutiny
On Fri, 18 Jan 2002, Shlomi Fish wrote about the need for a Great Kernel CVS Mutiny and since then things never were the same...: [... details were snipped ...] This is a classical problem of wanting to eat a cake and have it, too. We all want Linus to continue to lead the kernel development effort. But we want Linus to give professional attention to those patches, which he receives, and which deserve it. We also want to have heretic kernels - kernels, which got patches, which Linus didn't approve of or didn't even review. Simple forks won't do, because if a forked kernel diverges too far, then it'll be impossible to patch it with Linus-approved patches and vice versa. This is like the sterility of descendants of interbreeding, if their parents are too genetically different from each other. It would also be nice to be able to mix and match different patches to create kernels. For example, when there were two (or three?) different VM implementations floating around, it would have been nice to make them interchangeable (in the source code level) - selectable by means of a kernel compile-time configuration parameter. A solution, which will address the above concerns, will allow the Linux kernel to become a testbed for new OS innovations. If someone wants to try a novel filesystem, he can try to implement it on top of a reorganized Linux kernel. If someone else (probably Shlomi, who seems to be endless fountainhead of ideas) comes forth with a novel process scheduling algorithm, he can try it under realistic loads by plugging it into Linux kernel. This way, hacking Linux kernel will again become the fun it was in the days when the kernel was small and one could try a new thing without modifying a lot of the kernel; and didn't have to bother with managing a large software project. --- Omer There is no IGLU Cabal. It was going to require a 100,000,000 line long software package, and of course people DIED of drowning in all those pesky coordination-type details while trying to develop, perfect and maintain this monstrous but GREAT software package. WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html = 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]
Re: The Great Kernel CVS Mutiny
[ ... Really Long Letter Snipped ... ] Please refer to the following lecture, which talks about the engineering of Win2K: http://www.usenix.org/events/usenix-win2000/invitedtalks/lucovsky_html/ I spotted the link thru a post Chen made to Hackers-IL, and it also appeared on the Joel-on-software site somewhat later. The Win2K codebase is even larger than Linux is (due to the fact that Win2K is something like the Linux kernel, glibc, X-Windows, Gtk+, and some other stuff all combined in a big mish-mash). Nonetheless, it does show how a team of programmers was able to grok a very large codebase. I believe that the way things are done in the kernel development have to change in many ways to make its maintainance more scalable and straightforward. There should be: 1. CVS. 2. Roadmaps for the next stable release - what goes in, what stays out, etc. 3. A general, short, manifesto that explains what Linus thinks the kernel should have and what not. (I.e: should it have a sound subsystem? Should it have GGI? Should it have an in-kernel GUI?). Just kidding about the GUI part. 4. Maintainers of different subsystems who may delegate authority to other people. 5. Making sure Linus need not be bothered with any little patch. Linus can read the CVS diffs if he'd like, but people can commit changes without asking him. 6. Defining well-defined interfaces for the subsystems to interact with each other, and explaining what should or should not be done. Did I miss anything? I believe what I proposed is better than the ways things are done now. Of course I recall the first rule of open-source programming: Don't whine unless you are going to contribute. Which means that unless I'm going to act as a new and better Linus myself (at least until Linus OKs my suggestions), then I can't complain much. Maybe I'll join the lkml and try to change the system from within. (of course, I think I'll need to ask Orr Dunkelman for a dedicated account for that on vipe, because lkml happens to be quite high volume). Regards, Shlomi Fish -- Shlomi Fish[EMAIL PROTECTED] Home Page: http://t2.technion.ac.il/~shlomif/ Home E-mail: [EMAIL PROTECTED] Let's suppose you have a table with 2^n cups... Wait a second - is n a natural number? = 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]
