Slashdot Mirror
Cox on Torvalds and Linux Kernel Development
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."'"
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.
- - - - - Fear not the reaper, but my shiny white teeth.
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?
Mongrel News all the news that fits and froths
"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."
Say it with me...GPL.
One more time...GPL.
Got it? Good!
"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 eitherThe 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..)
Quidquid latine dictum sit, altum videtur
Are they? I know some "programmers" who definitely do not practice "software engineering" all the time...the engineer who needs a quick tool to plug and chug some calculations isn't really going to care so much about code reuse as someone who's writing a word processor...
That Linus is a person, and not a GOD as some people worship him as.
;P
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
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]
my blog
So fork the kernel. Unless I'm missing something, OSS is rife with opportunity to make something else happen. Lord knows, there are plenty of branches of the kernel that are available.
If microkernel is the way to go, then write the code, and we'll see what happens in the OSS marketplace. I'm not going to say "best technology wins," as that's rarely been the case historically.
There is, after all, a reason that the HURD hasn't taken over yet. I might well be missing something, as this isn't really my area.
ceci n'est pas un sig.
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.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
from TFA: "Cox revealed that although Linus is good at developing code, he does not enjoy some of the other jobs that go along with software development such as bug fixing and beta testing."
Note that Linus and Microsoft are both being accused of the same thing.... some purists are arguing that they don't focus enough on the bug fixing. The reality is, that no matter what focus you will NEVER have a bug free system. All software makes such feature/stability tradeoffs perhaps the most important challenge of any software project is balancing the tradeoffs of perfectionism vs. time-to-market of bleeding edge features that is best for their market. Other operating systems that do focus excessively on security for their "core" offering tend to fall behind in features (like the old mainframe software banks use, etc). Sure such software has its place; but it's not the mainstream market.
Note that for the security consious customer, though, Red Hat and SuSE both have higher-security releases of their own (like the Common Criteria vesrions like this one; and releases like Debian Stable that also focus on security and bug fixes only. By people who don't understand that those releases are targeting a different market, those branches are often criticised for being filled with obsolete software.
It doesn't have to be Linus's job to handle the most conservative customer's needs.
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?
HAD
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
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.
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".)
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:
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.
Kai MacTane: Web developer for hire in San Francisco
The VFS is a better OO abstraction than anything you will ever come up with in your lifetime.
Uh, what? The VFS is hardly a brilliant concept, but rather the sort of abstraction that any good designer will come up with. It's also not an original Linux invention (Sun OS has had it since 1985, I think). The kernel developers also seem to have a perpetual problem with defining an interface once and defining it well. It happened to me more than once that FUSE broke during a supposedly minor kernel upgrade. For all its virtues, the Linux kernel is hardly a case study in good software engineering.
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.
"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?
But to get a stable kernel you tend to do small horrible fixes. Linus is very keen to have maintainable code, while to have a stable kernel I'm keen to have code that works.
I have heard this argument used sooo many times to excuse sloppy coding in production environments. It is bullshit! There is no reason why maintainable code would not be stable. There is every reason to believe (backed by a lot of experience in production) that "small, horrible fixes" would be unstable!
"One of the hard problems to fix are design errors," said Cox. "These are a pain because they need a lot of refactoring. Linus' approach is to re-write it to a better design."
From this statement, I know who I'd rather have in charge of kernel development: Linus! There are times when the design shows basic flaws that should be fixed. The correct approach is to redesign and rewrite it NOT to pile fix upon fix on top of a flawed design.
I think this article shows Cox in a bad light NOT Linus.
it sounds like Cox words were twisted a bit.
I don't know because i'm not there BUT. it seems like AC is talking about people in general when he is talking about kernel bugs, not Linus approach.
earlier in the article he does say they have different approaches. But the article on slashdot splices quotes together to appear to make controversy where none may exist.
Here is the whole paragraph.
These early issues can be easy to fix as they are often obvious bugs. "Early problems you get are normally very easy to fix," said Cox. "As soon as the release comes out bug reports say 'You've broken this'. Almost immediately you go, 'Whoops, that's my mistake'. Ten minutes later the fix is in the development tree."
"He's a real midnight golfer"
Microsoft openly exploited the BSD TCP/IP network stack because of the liberal BSD license, something the authors of FreeBSD have absolutely no problem with, and in fact encourage. As to whether this is strategicly wise of them or not, well, that is a flamefest reserved for typical GPL/BSD arguments.
People who license their code under a BSD license don't mind people using their work. Its not like Microsoft using the BSD TCP/IP stack way back when caused it to diasppear from all of the BSD distributions on the planet. Its still there free for anyone to use. Microsoft using it doesn't change that.
You can only "usurp" a piece of BSD licensed code by making it better than it was. If you make a better version then you deserve to be paid for your efforts. If people agree that yours is better then they will purchase your product. If they don't or think your price is to high then they can always use the orginal code that is still free and still available for anyone to use.
BSD code only ever "goes away" when other people have made better versions (with or without the original code in question) and people migrate to the better code. Who really cares if some company takes BSD code and slaps their name on it? They'll have to make improvements in some way to get people to use their code over the free code that is still freely available.
So the problem isn't that Microsoft "took" the BSD TCP/IP stack. The problem is that people keep giving Microsoft money for their crap products.
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 find problems you are not writing portable code, you are fixing the non-portable code that you wrote and distributed.