Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Linux Software

KBuild Issues on the LKML 36

Posted by chrisd from the let's-do-the-kernel-hokey-pokey dept.
Mark Bainter writes "If you haven't checked out kbuild lately, you should. The new build system Keith Owens has put so much time into has a long list of benefits, including much shorter build and rebuild times, and greater accuracy. It appears his system is well liked by most, kernel developers (though not all). So the question is, why won't Linus merge it? Keith has been announcing for some time that it is ready to merge, and has worked very hard on trying to keep everything up to date as the development kernel continues to change, yet his requests to merge seem to be largely ignored. Linus did weigh in on the topic, but his views don't seem to resonate very far on the list, and seem rather arbitrary to me. Keith doesn't seem to be all that fond of Linus' thoughts on the matter either, and has called for an email campaign to get Linus to merge it in all at once. Perhaps instead of everyone on /. emailing their (partially informed) opinion to Linus, an open discussion amoung Linux users/developers who might not normally participate on the kernel list would lend some weight one way or another."
This discussion has been archived. No new comments can be posted.

KBuild Issues on the LKML More

KBuild Issues on the LKML

Comments Filter:
  • Its seems that linus has had some real problems merging anything with the recent kernels. Many people have been complaining about this. I heard that linus was to 'appoint' someone to take care of this since he recognized that the job wasn't getting done by himself. That, like many other things, has not materialized. I look at it this way: if linus can't get it done, he needs to get someone who can.

  • How do we think about the next step? (Score:4, Insightful)

    by Futurepower(R) ( 558542 ) on Thursday June 06, 2002 @09:04PM (#3656926) Homepage

    I've been following the sociology of Linux to some degree.

    Linus Torvalds is a brilliant human being, but he doesn't know everything, and no one does. Everyone seems happy with his technical knowledge. However, he doesn't seem as capable of thinking creatively about the sociological issues, such as "How do we make the next transition." It seems to me that there is some need for organization or re-organization of the Linux effort. But what should that be?

    Linux is a world-wide phenomenon. It is one of the most beautiful things happening in the world today, in my opinion. Arguably, governments should use open source, free software, because proprietary software hides some government activities from citizens, or puts an understanding of government operations beyond citizen's financial reach. Possibly Linux will become the backbone that runs all the world's governments.

    It is reasonable to suppose that Linux has grown to the point where there is a need for additional infrastructure to take some load off Linus' huge, but not infinite, mental capacity? If so, how do we think about that? Who will think about that? Who will finish the thinking, rather than just provide disconnected ideas?

    Linux is not about money, but maybe there are times when money would help. Is it possible that a management fund would be useful? If so, I would be proud to donate $100, or more.

    Are there efforts that are not suitable for volunteers? Is it possible that a few employees, under the direction of Linus, could help accomplish clerical tasks?

    I'm not qualified to know the answer, but maybe I am qualified to play a miniscule role in asking some initial questions.

  • is this a good idea? (Score:4, Informative)

    by larry bagina ( 561269 ) on Thursday June 06, 2002 @10:09PM (#3657221) Journal
    Is it a good idea for slashdot to be a soapbox for asking linus to merge in feature x? You ouldn't want him to get slashdotted :)

    More troublesome, though, Linus has been a "benevolent dicatator" so far. What happens when he makes too many "bad" decisions? First he refused to use SCM software, then he decided to use Bitkeeper. He held off on accepting the kernel latency patch, then added it. Now he won't add a popular configuration tool.

    Linus may be a nice enough guy, and (unlike some other FREE software figures) he's quite modest about his work, but he can't please everybody.

    • Is it a good idea for slashdot to be a soapbox for asking linus to merge in feature x? You ouldn't want him to get slashdotted :)

      Yeah, I wrestled with this actually. I had the same concern. In the end, I really wanted to see this get broader coverage than it would get just on the lkml. I did what I could within the post to try and make people /think/ before emailing him. My hope is that we'll get some decent discussion here in the developers area of thoughts and opinions that might help to sway him. (Assuming he even bothers to read it.)

      Hopefully, it won't backfire and cause a deluge of email to him from a bunch of 10-year-olds who can't even spell kernel.

      • What is the real reason? (Score:4, Interesting)

        by Futurepower(R) ( 558542 ) on Friday June 07, 2002 @12:30PM (#3660163) Homepage

        What is the reason that Linus does not want to make the change? Probably the fundamental reason is that he is trying not to over-commit his brainpower.

        Linus has already agreed to the change in principle. The logic for the change is unassailable. This is not a technical problem.

        It seems to be a social problem. Consider this: To do the job right, there must be a flag day. But flag days require a huge peak of mental effort from Linus. He knows, from past experience, that they are painful and disruptive of his inner balance. So, he is trying to maintain balance. Only this. Who is the villain here? No one, absolutely no one.

        If this theory is correct, putting social pressure on Linus may get him to agree. However, pressure may increase the overall stress in his life. Every project needs a coordinator who can think calmly and thoroughly. Increasing the stress takes him in the opposite direction. So, the end result would be that Linux as a whole would suffer.

        Usually social problems require social solutions. A solution would be to find a method of organization that removes some of the demand for Linus to think.

        If someone works at 80% of his thinking capacity, he or she can accept a temporary peak effort. But at 98% of capacity an increase in demand can be health threatening, even if a change would make things easier later.

        We all know that Linus has been doing all of his adult life. He hasn't had the enormous amount of time it takes to explore his inner reality. On some level he experiences extra demands on his brainpower as overload; he is just not an expert at communicating that; instead he gives technical reasons. He seems not be an expert in thinking about the solutions for overload. He seems not to be an expert in organization.

        The solution is not to go to Linus with demands. Demands increase the need for him to think. Instead, go to him with solutions. Go to him not with solutions that are good for Linux, but solutions that are good for Linus. Linus is already overloaded; you cannot expect him to find those solutions himself.

        There are larger efforts than Linux, for example, a large corporation like IBM or a national government. How do they cope with the huge amount of mental effort necessary? Through greater organization. If someone else besides Linus can finish the thinking about this, it is possible that the solution can be adopted.

        Linus has been an excellent leader in a world that often suffers from lack of good leadership. How can things be arranged so that Linux has the benefit of his ability, but the work does not overload him? That's the tough question that will require considerable thinking. If the thinking is not done, the answers are very unlikely to be found.

        My earlier post began about where this one ends: How do we think about the next step? (#3656926) [slashdot.org].

        Another thought. You have come to Slashdot, which is known for its excellent technical discussions (and for its comments by people who only want to trash discussions). This may not be the best forum to discuss a social problem.
        • One of the OS drums so frequently beat is that there is no absolute authority.
          Does it not follow that someone, CoderX, with enough skilz/status can just start developing the kernel the way it 'should' be done?
          There might be a copyright flap, as Linus owns the label 'Linux'. Perhaps CoderX can please RMS by calling it GNU/Xunil or something...
          Had I the skilz, I'd ponder such a move...then shoot myself...
        • What was the RFC for TCP/IP packets being dropped vs. rejected? And can we implement it in Linus?
    • The issue isn't getting Linus to merge a feature, its getting Linus to decide whter to merge a feature or not. People are wasting time maintaining code that may or may not be included in the official tree. Some of them would like an answer. How do you like it when you have a job interview then can't seem to ever get ahold of the recruiter. How long should you keep trying before you "get the hint?" Amd should you have to "get the hint" at all when a 5 second reply of 'sorry, we're not interested', or 'you'll have to excuse me, I'm a moron' would suffice.

  • Ya, nothing is going to get Linus to act on this like a bunch of laymen spamming his e-mail box. You know what the real reason Linus hasn't merged it yet? He is too fucking busy. The best thing to do is to be patient, and keep reminding him - POLITELY!

    • Ya, nothing is going to get Linus to act on this like a bunch of laymen spamming his e-mail box.

      The call for an email campaign was for developers. Not for slashdot. I hesitated to even mention it, but the Q&A in that post was a good resource for keith's opinions on the matter.

      You know what the real reason Linus hasn't merged it yet? He is too fucking busy. The best thing to do is to be patient, and keep reminding him - POLITELY!

      No, I don't buy that. I don't think even Linus would agree with you on that. (I can't speak for him, but I think his words speak for themselves) Keith /has/ been patient. He's been waiting to merge this since the beginning of the 2.5 tree iirc.

      Reminding him isn't going to change his opinion that the code should go in in little pieces regardless of the difficulties of this or how realistic it might be.

  • IMHO... (Score:2, Insightful)

    by moonboy ( 2512 )


    I agree with Linus. I think such decisions and actions are best made with little steps.

    • I agree with him that it's good to move in small patches generally. But there are times when that really doesn't make sense, and I think this is one of those times, and I think I'm in fairly good company.
  • Once you've had them, you can never go back! Oh the speed! Oh the accuracy!

    I'm a non-recursive whore, go Keith!

  • Facts? (Score:2, Interesting)

    by return 42 ( 459012 )
    Well, I don't follow lkml much, so I may be lacking some crucial context here. But it looks to me like Linus is going to merge it, or more precisely, have someone else merge it. What he doesn't want is to merge it all at once. He wants it done gradually, which is generally a better idea if you can do it.

    The argument thread is here [iu.edu]. To me it looks like Keith wants it done right now, isn't willing to wait, and thinks the only reason it's being held up is because Linus is a prick.

    Personally, I don't know if Linus is right or not. Maybe it can be merged this way, and maybe it can't. But he is doing something about it, and if he's wrong, that will become evident fairly soon.

    • I don't think it has anything to do with Linus being "a prick". He just is of the opinion that it can and should be merged in pieces. However, that isn't reasonable given the kind of changes being done. At least in the opinion of many of us. There's a division of thought there.

      To my mind, the whole point of an email campaign is to try and persuede Linus that it /can't/ be done in pieces, and needs to be done in one piece. For more info on this see the link from the story with Keith's FAQ.

      In addition, Keith has gone the extra mile in making sure that both build systems can co-exist. So it isn't even an issue of going all or nothing.

  • Linus's post hints fairly well why he objects to kbuild 2.5

    - Kai has already shown that he can merge with me easily, and actually
    took one traditional flag-day-project (ISDN: every single merge was a
    flag-day merge), and has turned that into a very easy gradual merge
    for me. I used to dread ISDN merges, these days I don't even have to
    think about them.

    - Kai obviously already knows the build system, as he has been doing a
    lot of incremental stuff on it already.

    - Kai isn't an enthusiastic kbuild-2.5 supporter. In fact, he tends to
    be a bit down on some of it. Which is a plus in my book: it means
    that whatever Kai tries to push my way I'll feel just that much more
    comfortable with as having had critical review.
    </i>

    All this translates fairly straightforwardly into: "I'm not accepting patches from Keith. I like Kai, and he is part of the *in* crowd, so if he wants to champion it (since I know he doesn't like it), I'll accept it from him."

    Implicit is that the Linux kernel is officially closed to new contributors. The whole bkbits issue is all about the same thing.

    • Implicit is that the Linux kernel is officially closed to new contributors.

      Not exactly. It's more akin to "if I have a bad experience with you, find somebody else for your patches to go through before I'll check them". Keith is not the only kernel developper with which Linus had (has) some frictions (sorry, no specifics, but it might be the devfs or IDE maintainer). Basically, he doesn't want to deal with some people directly, for various reasons. Which, in a pool of say a thousand developpers, seems normal. Also, Marcelo (the current maintainer of the 2.4 branch) is quite young IIRC, around 18. He probably works on Linux for some time, but it's not impossible to be a new contributor.

      The whole bkbits issue is all about the same thing.

      The BitKeeper issue is more on the questionnable usage of a free (beer) SCM for the development of a free (speech) project. Everybody is free to use BitKeeper for their kernel works. Or to not use it. From the beginning, plain diffs were to continue to be accepted, as they were before. But using BitKeeper results in less difficulties to merge changes together for Linus.

  • Linux is the backbone of a social revolution. The underlying issue of this Slashdot story is not how to build the kernel, but how to manage the part of the new technical and sociological revolution that is connected to having a universal operating system.

    Linux has proven to be an operating system that everyone can rally around. Some governments and large businesses have already adopted it. We live in a world in which much of the infrastructure is guided by computer programs, so strong support for efficient methods of using computers is extremely good news.

    Linux is a fundamental backbone of the entire open source software movement. There was far less support for open source software when there were 200 flavors of Unix and none were preferred. Now programmers can write for Linux, and can depend that those who have an interest in other operating systems have experience in re-writing Linux code for the OS they prefer. I use several Linux programs in which Windows OS versions are provided by one person on each team who has volunteered to build the program for Windows. So even Windows benefits from Linux.

    Most people don't understand the issues. Partly because Linux has become a foundation of organization for a software revolution, this Slashdot story is one of the most important that I have seen in perhaps two years of reading Slashdot. Yet at the time this comment was posted there are only 27 comments rated 0 and above. An earlier story about a small company going bankrupt has five times as many comments!

    The really important (and interesting) questions are beyond the comprehension of most people, apparently.

    Apparently the reason that many of the really important problems don't get solved is that the problems are not only beyond the solving capacity of almost everyone, but also beyond the consideration capacity of almost everyone. So a problem like this doesn't receive much attention and help.

    No sociologist could have guessed how much proprietary software would fail us. Proprietary software companies seem to be competing with themselves to abuse their customers. For example, Microsoft Windows XP expects to connect to Microsoft computers for more than 12 different reasons. Many of those connections expect to have server rights. Some of the "privacy policies" behind those connections provide little actual privacy, and Microsoft and others have changed their privacy policies, and made the changes retroactive, so, effectively, you agree to some unknown contract in the future. (Microsoft just did this with Hotmail, for example.)

    The direction that Microsoft XP has gone makes it not so much an operating system as a money-making scheme. There are a huge number of bugs. For example, a P4 system with an Intel motherboard that was upgraded to Windows XP from a fresh install of Windows 2000 just stops on loading. Behind the blue "Welcome" screen, if you think to press Alt-Tab and look, is a message that says the paging file is too small. That's the kind of double sloppiness those of us who work with Windows see every day: An important message that shouldn't be there because the system was just installed is hidden by another screen. Those who work with Windows are often not very knowlegeable and those who are knowledgeable often don't work with Windows. If they did, they would realize that the situation with this proprietary OS is much worse than they thought. For example, the new menus in Windows XP are often 5 to 7 levels deep.

    Proprietary software companies often seem not to have the will to produce good software. For example, Microsoft's Internet Explorer has 18 unpatched security bugs [jscript.dk] (when this was written). These active security risks are different from the recent 15 that have already been fixed. Why would a company that has 40 billion dollars in the bank let itself get an extremely bad reputation because of software bugs? It doesn't make sense, and Microsoft is not the only software company that is self-destructive in this way.

    Another phenomenon that no sociologist could have foreseen is that proprietary software companies have an extreme mode of failure. The brilliant initial organizers sell out and leave, and the company, in an attempt to maximize profits, hires less expensive people who don't quite have the ability to guide the company through rapid technological change. Customers who chose products from that company find those products increasingly inadequate, until eventually they must bear the selection and training expense of choosing an entirely new company and product. Often the product the first company made just dies. In contrast, although it may become abandoned, open source software never truly dies. Even in the worst situation it is ready to be modified and used again.

    The open source revolution is helping strengthen our fundamental infrastructure. When I look at the operation of my local state government, the government of Oregon, U.S.A., I see a lot of inefficiency and insufficiency. One realistic method of improving government operations is to have better software. For example, Oregon state courts send out notices of actions by mail, and sometimes the notices are lost. The Oregon courts do not have e-mail notification (but the libraries do). You can see all Oregon state laws on the internet, but not the cases before the courts. Everywhere I look in state government, there are areas that could be improved with better software.

    Humans and computers are excellent partners. Computers do exactly the work that humans don't like to do, the repetitive work. A good computer program enforces exact application of whatever policies have been adopted. This is exactly the kind of discipline governments need, because a lot of corruption begins with small deviations from the rules.

    Proprietary software written for governments is no better than proprietary software written for single users. It's expensive. It's exact operation is hidden from both government managers and citizens, who cannot verify how it works. The insufficiency and abusiveness of proprietary software companies slows the acceptance of new and better software into government.

    When governments of poor countries use proprietary software, they often create political and social problem for themselves. Sending a representative of a very poor country to the U.S. for training can cause jealousy and job-related empire building. In contrast, the expectation created by Linux and other open source programs is that someone can teach himself with help from other people who are interested in the same software.

    Linux and all GNU/GPL software is more than just a backbone of a computer revolution, it is the establishing phenomenon of a social revolution that is spreading to other fields. Educators, for example, are working on repeating the successes of Linux by creating open source, free course materials. This makes very good sense. Why not prepare and video tape one course by one especially good teacher, and make it available on the internet to anyone who wants more education?

    Open source is an expression of caring. This may be too warm an expression of philosophy for the comfort of many people connected with open source software, but open source is an act of love. There are many ways to express love, and donating your time and brainpower to the world is one of them.


Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Close