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."'"
An Interview with Linus himself
Actually Linus *is* the "be-all-end-all" of what makes it into the vanilla kernel on kernel.org. Plenty of other people have their own patches, but Linus dictates main-line completely.
no they are not.
programmer = code monkey
developer = higher level design and algorithms.
engineer = full system design, makes the important decisions.
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/ 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.
That was quite funny, and I see that you managed to fool somebody into giving you an "Insightful" mod.
Mods take note, the parent post is deliberately nonsensical. For example, "It's been shown that creating working kernel based on a register machine like most modern microprocessors is NP hard".
Uh, not really - Andrew Morton is the official maintainer of the 2.6 kernel, and Marcelo Tosatti is the maintainer for 2.4.
Computer Engineers writing software are usually supervised by Computer Scientists, they are clearly more qualified to make the important decisions.
More accurately in a software development organization:
programmer/developer/computer engineer = code monkeys of differing experience
architect = computer scientist who makes important, well-informed decisions
HAD
He's a hacker with a lack of experience in projects outside his own.
Are you sure? I thought he works pretty closely with Linux-related projects, when the need arises. For example, look here.
Note that Linus was the top poster for that week.
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
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
Live today, because you never know what tomorrow brings
Maybe the problem is that it's mispelled?
Compliment is to give praise.
Complement (note the e) is to make complete.
How about that? It turns out spelling *is* important.
I'd think that one is complement too.
But hey, I'm not a spelling nazi.
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.
Without GNU's GPL MS would've openly pirated various free implementations of UNIX.
What about the ones that are not released under GPL, like *BSD?
The BSD TCP/IP network stack was openly "pirated" by Microsoft, if by "pirated" one means "used while drowning in hypocracy by decrying the very free movement one is exploiting," which is really the only definition of "piracy" I can imagine would apply to using a Free product in compliance with its license. I suspect that is what the original poster meant.
I wouldn't have chosen the word "pirate" as it implies copyright violation, which is clearly not the case if you're adhering to a license. "Exploited" would have been more appropriate.
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. I personally think the GPL is what has made Linux viable and protected it against many of the worst depridations by Microsoft...though of course it won't hold up to a patent assault once Bill Gates finishes ramming software patents down the Europeans' throats (one may speculate on which appendage Mr. Gates is using to do the ramming), but as Apple, OpenBSD, FreeBSD, ogg-vorbis, and numerous other projects have shown, the BSD license has its strengths as well, and can be quite ideal for other projects.
The Future of Human Evolution: Autonomy
try here, for a start
Actually, you are mistaken.
That was going to be the direction, but they changed their mind. Linus is still the final guy for mainline, and Andrew maintains the -mm patchset of things that are being groomed for inclusion into mainline.
All the kernel.org 2.6 releases come from Linus' tree.