Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Linux Software

Cox on Torvalds and Linux Kernel Development 323

sebFlyte writes "Alan Cox' speech at FOSDEM sounds like it was interesting... according to this ZDNet report on it he has some interesting views. For one, he says: 'Linus is a good developer, but is a terrible engineer.' He also has a few digs at Torvald's methods surrounding security fixes, and some other interesting insights in the kernel development process: 'Sometimes you see a fix and think "this is perfect, move my fix into the kernel tree." Later you think, "I must have been drunk. Don't apply that patch."'"
This discussion has been archived. No new comments can be posted.

Cox on Torvalds and Linux Kernel Development

Comments Filter:
  • by Anonymous Coward on Wednesday March 02, 2005 @12:27AM (#11820842)
    • by TrekCycling ( 468080 ) on Wednesday March 02, 2005 @01:20AM (#11821104) Homepage
      That's interesting. Thanks for the link!

      The most interesting part to me is that he uses a Mac running Linux now. For a long time the story was that he ran SuSE (I'm assuming on x86). I'm a SuSE user, and some of the enthusiasts in SuSE-land used to use this as proof of why SuSE was "the best". I just laughed. I wonder what distro he runs now.
      • Frequently seen in kernel changelogs is something like this:

        torvalds@ppc970.osdl.org
        Linux 2.6.11-rc5


        The 'ppc970' has been there for a while now. I assume this is his PowerPC machine, which would indicate he's been running a Mac for some time.
      • by Linker3000 ( 626634 ) on Wednesday March 02, 2005 @05:26AM (#11821830) Journal
        I wonder what distro he runs now.

        Hurd?
      • The most probable reason for this might be code portability. If you force yourself to write code on a PPC machine then the odds are much better that you'll end up with portable code (as you already know a bazillion x86 users will be testing your code anyway.)

        Microsoft did something similar with Windows NT: The x86 version was only first compiled much later in the development process. The devs all used PPC, MIPS, or Alpha machines to do their development work.
        • NT was developed initially on the MIPS, as in 1988 the x86 family was woefully underpowered. PPC development didn't start until 1995, and it never finished. NT4 SP3 IIRC was the last PPC release.
          • WinNT PPC was finished, I believe the retail WinNT4 CD includes MIPS, x86, PowerPC, and Alpha. I recall dual 604 boxes being advertised in Byte magazine for a while. A review in Byte compared dual 604 against dual Pentium, pointing out dual 604 scaled better. Win2000 PPC was never finished.
        • The most probable reason for this might be code portability. If you force yourself to write code on a PPC machine then the odds are much better that you'll end up with portable code (as you already know a bazillion x86 users will be testing your code anyway.)

          No, using only a PPC does not really help you write portable code. It is pretty much the same as using only an x86. To write portable code you have to use more than one architecture during development. If you write on PPC and wait for x86 users to fi
      • He's actually been using PPC for about a year now, IIRC; he mentioned on the mailing list that he had switched shortly after, when there were some x86 arch-specific changes that he couldn't test.

        It's kind of amusing: he doesn't really get involved with the PPC arch, and continues to work on the x86 arch, just because he knows a lot of the low-level x86 stuff from before and hasn't bothered to learn the low-level PPC stuff.
    • by antime ( 739998 ) on Wednesday March 02, 2005 @01:59AM (#11821218)
      Heh, wonder why they cut out part of Linus' post quoted at the beginning? (The original post read "just a hobby, won't be big and professional like gnu".)
      • Seeing as GNU is mentioned zero times in the article, they probably cut it off to avoid having to explain to people what GNU was. Even though it is in Linux magazine I guess some readers may not know what GNU is, and a discussion of GNU is probably (depends on how you look at it) irrelevant to an interview with Linus Torvalds about kernel development.

  • Odd (Score:4, Insightful)

    by Kip Winger ( 547075 ) on Wednesday March 02, 2005 @12:27AM (#11820844) Homepage
    It's funny how petty squabbles between key developers could tear even what is now a major, corporation-funded project apart that millions of machines and companies depend on.

    I'm willing to be if such things continue, some entity, perhaps IBM, will set down their foot and use pressure put maintenance of the kernel project under the jackboot of a truly dictatorial manager, making Linux more an open source Cathedral than a bazaar.

    • Re:Odd (Score:2, Insightful)

      by kaiser423 ( 828989 )
      Um, how do you see IBM having more power than Linus? He created the thing, and people love him. IBM could start their own branch, but you'll still have Linus'.

      Anyone want to guess which branch would be more popular?
    • Re:Odd (Score:5, Insightful)

      by Soko ( 17987 ) on Wednesday March 02, 2005 @12:49AM (#11820954) Homepage
      I'm giving up mod points to try and dispell what seems to me a sensationalised headline.

      Alan Cox is not showing disrespect to Linus here, read the whole quote:

      "Linus is a good developer, but is a terrible engineer," said Cox. "I'm sure he would agree with that."

      Alan and Linus have been working together for a very long time, so I'm sure Linus wouldn't give this statement a second thought. Each must know they compliment the other and make the whole of the Linux kernel better - even if they have the odd disagreement - or the kernel would have been truly forked (no pun intended) a long time ago. As it is, they work together on patches and ideas. We don't have much to worry about, I think, since Linus' sense of who's a good dev and who fits into his team well is uncanny.

      Soko
      • Re:Odd (Score:5, Informative)

        by LnxAddct ( 679316 ) <sgk25@drexel.edu> on Wednesday March 02, 2005 @02:03AM (#11821233)
        Good points. But for those who didn't rtfa, or have no idea about kernel development, Alan Cox generally makes sure the kernel is stable. Linus likes to innovate and throw new ideas in without necessarily testing them thoroughly. Innovation and stability are usually separated by quite a time period in any development process, so all Alan was more or less saying was that (as the parent stated) they compliment each other. OSDL pays Linus to hack up new stuff thats needed, Red Hat pays Alan to make sure that new stuff is stable and can be effectively used to its full potential. You really do need them both, as one without the other won't achieve much, and giving those tasks to one man alone would be quite a burden and errors would be abundant. Both Alan and Linus are absolute geniuses at what they do and no one is arguing that. Since when did OSS need to sensationalize headlines?
        Regards,
        Steve
        • Re:Odd (Score:3, Informative)

          by Kjella ( 173770 )
          so all Alan was more or less saying was that (as the parent stated) they compliment each other.

          I don't think being called a "terrible engineer" is a compliment. Def: 1. An expression of praise, admiration, or congratulation. Versus a complement: 1c. Either of two parts that complete the whole or mutually complete each other.

          Kjella
          • by oo_waratah ( 699830 ) on Wednesday March 02, 2005 @06:13AM (#11821972)
            Mathematically compliment is opposite sides of an angle. if one is acute then the other must be obtuse. They compliment each other like the chinese ying and yang.

            They balance one another because they are different or compliment each other. THis is different from the compliment that sings the praise of someone else.
    • Re:Odd (Score:4, Insightful)

      by Anonymous Coward on Wednesday March 02, 2005 @12:52AM (#11820978)
      squabbles? go read al viro's lkml posts.

      these folks flame and flame well. Similar fireworks seem to be an important hallmark of a healthy project.

      You are speaking, in ignorance, from the wrong orifice.

    • Re:Odd (Score:3, Insightful)

      by WindBourne ( 631190 )

      First, this same shit occurs in any major corporation. Always has, and always will. Most of the development teams that I have been on, routinely have issues like this.

      2'nd, no corporation controls this. Not one of the companies out there will be jackbooting anybody. They may underfund (fire) a developer for inability to do what they want (there have been some great examples of this, but no sense dragging up shit). None of these companies have any direct say in what happens. As it is, they have to pretty m

    • Re:Odd (Score:3, Funny)

      Cathedral? The 90's called, they want thier jargon back.
    • Re:Odd (Score:3, Insightful)

      by Tony-A ( 29931 )
      I'm willing to be if such things continue, some entity, perhaps IBM, will set down their foot and use pressure put maintenance of the kernel project under the jackboot of a truly dictatorial manager

      Not IBM if I'm right that IBM "gets it".

      It's funny how petty squabbles between key developers could tear even what is now a major, corporation-funded project apart that millions of machines and companies depend on.

      Balderdash. Some people enjoy a good argument. The louder the better.
      Of course it's fun to ima
  • by weighn ( 578357 ) <weighn@Nospam.gmail.com> on Wednesday March 02, 2005 @12:29AM (#11820850) Homepage
    I'm not trolling, and am a little ignorant of kernel development - so bare with me, but surely Linus isn't the be-all-end-all overseer of what ends up in the kernel? Why target him exclusively?
  • by tktk ( 540564 ) on Wednesday March 02, 2005 @12:33AM (#11820878)
    Linus probably keeps all the secret fixes under his security blanket.
  • by Gopal.V ( 532678 ) on Wednesday March 02, 2005 @12:37AM (#11820896) Homepage Journal

    "Linus has this bad habit of fixing security holes quietly," said Cox. "This is a bad idea as some people read all the kernel patches to find the security holes."

    I wouldn't advertise my mistakes either ... neither do the OpenBSD folks or any ego driven engineer :)

    The article paints Linus as the typical Flawed Hero of contemporary literature. He's good and yet he's not perfect - at least that's what comes out of it for me. (and no digs on BitKeeper .. hmmm..)

    • I *know* this is offtopic, but as far as I know the concept of the Flawed Hero comes from the greek tragedy, and I wouldn't ever call it characteristic of contemporary literature, which is more fond of anti-heroes methinks.
      • Hmm. That might be a valid interpretation, but it's not one I would subscribe to. I believe the first instance of what we normally think of as the tragic hero began with Shakespeare. He was the first one (if I remember my literature classes, now fifteen years in the past) to introduce sympathetic hero characters with a fatal flaw that led to their eventual downfall. The hero of the Scottish play, for example, was undone by his ambition.

        Anything since about 1630 can reasonably be called "contemporary." ;-)
        • I was going to mention Sophocles, but then I re-read your word sympathetic.

        • The grandparent is correct. Shakespeare did not invent the tragic hero; the ancient Greeks did. Wikipedia [wikipedia.org], as usual, comes to the rescue.

          I am sympathetic to those who can't stand history courses (I often include myself in that category), but every once and a while, those who complain that we are perilously ignorant of our own history are on the mark. An author who has not studied the Greek plays is like a coder who has not studied data structures: you're liable to repeat time-honored mistakes without even
      • the Flawed Hero comes from the greek tragedy

        Maybe in this case, the Flawed Hero comes from the geek tragedy?

  • by alanlke ( 685520 ) on Wednesday March 02, 2005 @12:38AM (#11820898)
    Cox may have had a good point on Linus' methods for security patches, but fortunately the community has spawned sites such as this http://www.securityfocus.com/ [securityfocus.com] to publicly announce when people find security flaws from poking through the patch code.

    Even if Linus tries to keep these things secret, they'll get out quite quickly.
  • ZD states.. (Score:5, Insightful)

    by Creepy Crawler ( 680178 ) on Wednesday March 02, 2005 @12:41AM (#11820915)
    That Linus is a person, and not a GOD as some people worship him as.

    Its actually pretty damned nice to see a bunch of people get together and make something as big as the Linux Kernel. Linus started it, but we all will finish it.

    Still, I fail to see how some bugs would be super-bad, as the article seems to say. Id rather have a crash bug, rather than a SUID change bug.. STill, not all security comes from the Kernel. Some security comes from network filter drivers, some com from the application, which many hackers target, and whatnot. Though, the kernel is a great place to attack if you have that guest acct and "want" root ;P
  • nothing new (Score:5, Insightful)

    by sewagemaster ( 466124 ) <sewagemaster AT gmail DOT com> on Wednesday March 02, 2005 @12:43AM (#11820927) Homepage
    the /. headline makes it looks like there's quite a bit of fued between cox and torvalds, which isnt really the case if you RTFM.

    different people have different working styles, no matter whether it's kernel coding, software apps, or ASIC designs. if either group/individuals are too giving to the other group, there can never be enough feedback/ constructive critisisms between them. having yes-men surrounding you isnt the best thing. and it's not like that they're arguing so much they've halted any soft of development progress.

    [offtopic]
    gives me an idea though, maybe when job interviewers start asking me those behavioural questions about "a time when you've had disagreements and a way of resolving them", there's no need to bring up something too dramatic.
    [/offtopic]
    • by Anonymous Coward
      which isnt really the case if you RTFM.

      It's an entire manual and not just an article? I'm definitely not reading it now. =p

    • maybe when job interviewers start asking me those behavioural questions about "a time when you've had disagreements and a way of resolving them", there's no need to bring up something too dramatic.

      I had a job interview a number of years ago at a video game company. The guy asked me with a straight face what I would do if two of my co-workers was having a fist fight out in the hallway.

      I almost blurted out, Does that happen a lot around here? Instead, I gave a safe answer that I would go get a superviso
      • Re:nothing new (Score:3, Interesting)

        by mvdw ( 613057 )
        I was once given some advice about interviews from my Dad, who said something along the lines of: often, the interviewer is looking at whether you know your own limitations. For example, they will often continue to probe about a particular issue, and if the interviewee keeps saying that (s)he'd keep trying to fix the problem, that a Bad Thing(tm). The Correct Answer(tm) is to say, after a while, "That's when it becomes your problem". After a certain amount of time with a problem, you should always defer it
    • [offtopic]
      gives me an idea though, maybe when job interviewers start asking me those behavioural questions about "a time when you've had disagreements and a way of resolving them", there's no need to bring up something too dramatic.
      [/offtopic]

      As an experienced interviewer/interviewee, I will go ahead and agree with this for the obvious reasons. Any questions that are ethics-based or drama-based should be answered in the following way: Ask to think about it for 20 seconds, and then come up with somethin

  • (forgive the funny subject, I'm refering to tracking the dynamic elements of a piece of code):

    I've written some code, and try to visualize how my code will run, stepping through each section in order.

    The question I have is, is it still possible for these kernel gurus/hackers to effectively have the kernel and all its nuances inside their head, fully functional at a theoretical/experimental level? Or does development at this point consist of sub groups that are specialized and don't require a level of und
    • by Abcd1234 ( 188840 ) on Wednesday March 02, 2005 @01:23AM (#11821111) Homepage
      The question I have is, is it still possible for these kernel gurus/hackers to effectively have the kernel and all its nuances inside their head, fully functional at a theoretical/experimental level? Or does development at this point consist of sub groups that are specialized and don't require a level of understanding to 'run the kernel in your head'?

      in short, it's the latter. However, keep in mind that, in a well designed system that's properly modularized, with neatly spec'd interfaces between components, it isn't always necessary for someone to have the entire picture, with all the nitty-gritty details, in their head. Instead, one need only grasp how the system operates at a high level, from a component-oriented standpoint, where each of the components themselves conforms to a particular contract.

      Put another way, while Linus may not understand how the driver for a particular digital camera works, he probably does understand the interface that driver exposes, and how that interface ties in with the rest of the system.
  • by DesScorp ( 410532 ) on Wednesday March 02, 2005 @12:50AM (#11820961) Journal
    ...at least it didn't say "Cox IN Torvalds"
  • by mnmn ( 145599 ) on Wednesday March 02, 2005 @12:52AM (#11820974) Homepage
    Linux has become much bigger than Linus now. The kernel alone has its parts maintained by other people, many of whose patches are applied without much checking to the main tree because they're 'responsible' for it, like certain architectures, driver trees etc.

    Apart from the name, Linus currently has the final say of what goes in. Thats just officially. In real life it seems far more is delegated to others for different parts of the kernel, and Linus is one of the developers, far from the most active, and not really exercising his right to block patches against the majority's will.
    • by bonch ( 38532 ) on Wednesday March 02, 2005 @01:16AM (#11821084)
      "Who cares about Linus anymore?"

      Slashdot, apparently, since it usually posts an article on just about every mention of Linus, every minor activity, every little comment, and every little speculation. People glorify him as the guy who single-handedly wrote Linux, when Linux is really the work of thousands of developers who just send patches to him (and now other delegates too).
      • by nysus ( 162232 ) on Wednesday March 02, 2005 @01:53AM (#11821206)
        I'm interested in Linus for purely selfish reasons: I can learn from him. I learn from him even though I've barely looked at any Linux source code or do any programming in C or do any kind of low-level programming for that matter. But as someone who plays a small role on a small open source development project, it's fascinating for me to hear from a person who leads such a hugely successful project and the problems and obstacles he and other developers have to overcome to be successful. It helps me put perspective on my own work.

        That's not glorification, that's taking advantage of somebody else's insights and experience.
      • by oconnorcjo ( 242077 ) on Wednesday March 02, 2005 @03:40AM (#11821532) Journal
        when Linux is really the work of thousands of developers who just send patches to him (and now other delegates too).

        Every leader depends on the efforts of those working for them but that does not mean that great leaders are any less great. Linus LEADS. He is the "queen bee" and as such he makes sure the Linux kernel is a great piece of software though he does little "honey gathering" himself.

      • by michaeldot ( 751590 ) on Wednesday March 02, 2005 @05:29AM (#11821839)
        The more I learn about Linus from day to day, the more he sounds like a great human being with his priorities in the right place... "Other than software, I've been spending a few hours a week for the last month building a small playhouse for the kids in the backyard." A great role model for young geeks once they grow up.
  • Tabloid fluff (Score:4, Insightful)

    by rafael_es_son ( 669255 ) <rafael.human-assisted@info> on Wednesday March 02, 2005 @01:05AM (#11821044) Homepage

    The article is yet another clear piece of filler that pretends to build antagonism between two important figures of the kernel project. How does this stuff keep getting accepted by Slashdot?

    Is this the way Slashdot supports open source, fostering internal divides in exchange of ad eyeballs?

  • Hahaha! (Score:2, Interesting)

    by Pathway ( 2111 )
    I don't know what other people think of this, but I think it's funny!

    I'm not a coder. The cosest I get is some bash scripting, which I haven't had to do in a while. But hearing that even some of the greatest coders (who aren't bound to a company policy to keep mum) sometims screw up, makes me feel good... It just cracks me up that there are those moments in life where even Alan Cox and Linus Travolds say 'What the $#@%! was I thinking?'

    And the best part? It's all visable to all the other developers. Thank
  • by kmactane ( 18359 ) on Wednesday March 02, 2005 @02:03AM (#11821236) Homepage

    I'm sure everyone who doesn't bother to RTFA will now think, "Oh, no, Linus and Alan are bitching each other out in public." That's nothing like what's going on here. For one, the submitter quotes only half of one particular line from the article:

    "Linus is a good developer, but is a terrible engineer," said Cox. "I'm sure he would agree with that." [emphasis added]

    So it sounds like Alan and Linus have discussed this particular difference in their talents before, either over beers at a pub, or over email or something.

    Second, the article makes clear that part of what's going on is that Alan and Linus each have very different responsibilities in keeping Linux going, and so they necessarily focus on different things. Alan points out that as the dev tree maintainer, Linus is trying to keep the code maintainable, while Alan's trying to keep it stable.

    And both of these things are necessary. It sounds to me like rather than being "at loggerheads", or "ready to call off the working relationship", instead Linus and Alan are a very well-matched and complementary team, both of whom contribute enormously to Linux's success and quality.

    Each of them has strengths that make up for the other one's weaknesses, and it sounds like they have a good enough working relationship to give each other constructive criticism when needed.

  • Is it all that obvious? I counted Linus saying obvious or obviously 11 times! To me it isn't.
  • by foobsr ( 693224 ) on Wednesday March 02, 2005 @04:17AM (#11821636) Homepage Journal
    'Sometimes you see a fix and think "this is perfect, move my fix into the kernel tree." Later you think, "I must have been drunk. Don't apply that patch."'

    Nothing has changed. In 1983 one cause of coding (programming) errors had been described as a misfit of perceived and actual reality (Zemarek in Psychologie des Programmierens, S. 111-129, Hrsg. H. Schauer, M. Tauber, R. Oldenbourg, Wien, 1983).

    CC.
  • by Anonymous Coward on Wednesday March 02, 2005 @06:03AM (#11821946)
    "Linus is very keen to have maintainable code, while to have a stable kernel I'm keen to have code that works."

    And these things are mutually exclusive?
    • by Alan Cox ( 27532 ) on Wednesday March 02, 2005 @07:46AM (#11822238) Homepage
      They get to be in conflict over short time periods - that was the point of that part of the talk. If you need a fix that is provably correct, simple and immediate it tends to be the ugly bandaid type fix. Those go into -ac and expire (in theory) for the next base kernel.

      Linus instead is quite happy to say "ok that is a problem but the real fix is to rewrite the logic behind [randomcomponent] to properly ensure that this cannot occur'. That might take a month and is undoubtedly the right answer but it isn't the immediate answer for people hitting the problem currently.

In order to dial out, it is necessary to broaden one's dimension.

Working...