On Apr 21, 2005, at 10:54 AM, Lan Barnes wrote:
An interesting story to follow. It's a mixture of religious passion, power, rage, jelousy ... just like opera.
http://news.com.com/Torvalds+unveils+new+Linux+control+system/ 2100-7344_3-5678651.html?tag=nefd.top
Not particularly interesting. It just shows that Linus is not a particularly good manager (been clear for a while), and may not be as good technically as everybody thought (a bit surprising).
I don't think there are any credible claims that Linus is a particularly good /people/ manager, or even a particularly good project leader, in the general sense, but he seems to be accepted on whole as a more than adequate manager for the particular project he does manage - the kernel. As to his technical expertise, I've never seen any claims about that one way or another. In fact Linus himself has admitted on more than one occasion that his skills and philosophies may not be ideal.
But at least for the present, the Linux kernel is his baby, so to speak, so he doesn't have to care what anyone else thinks. As he and others have said for years, anyone is free to fork the kernel. So far, I don't see any significant major efforts in that direction..
There are other signs:
The fact that Linus doesn't believe in kernel debuggers and forces that decision on everybody.
I also read through most of the important discussions of this subject on the KML, and having gone in with an open mind, while also leaning toward a kernel debugger being a good thing, I came out with being maybe a bit on the side of it not being a good thing. For the most part because of how dynamic and fluid the Linux kernel development is and how rapidly it changes in often major ways which would tend to not only make a kernel debugger stable only for short periods of time, but also I tend to be convinced that /on this particular code base/ a kernel debugger would tend to contribute to overall kernel destabilization.
The Alpha EV5 Linux implementation *cough*hack job*cough* (Although, to be fair, that was the first real cleanup/refactoring of Linux, so I'll cut him some slack)
The whole VM subsystem mess
So the kernel has its warts. Nobody's arguing it doesn't. But I'd say that its success has more than proven it has more than enough good points that it has little if any competition (outside Windows). If you want a wart-free OS, you'll have to look at...I don't know, OpenServer or Unixware might be close. Something that hasn't changed much in decades. Just think of Linux as the English language of OSes. Unlike some other OSes or Latin, it's a living OS and therefore always evolving.
Pissing off *lots* of your users by choosing BK when there were perfectly fine alternatives (Perforce being the primary alternative if you didn't like any of the open source ones).
What Linux *users* liked wasn't a factor Linux' choice to use BK. What kernel *developers* liked might have been, what /he/ liked certainly was. Prior to Linux using BK, there really wasn't much of an SCM system being used at all at the top of the kernel development pyramid, was there?
This "Git" is now just an extension of "I'll be damned if I'll change my thinking or processes". Why build yet another incompatible source code system?
Linus' explanation seems pretty clear that Git is what /he/ wants. He's not dictating what others must use. He wrote it for himself. And pretty much in the same way and with the same motivation that most Unixy software has been written. It's his own hack. And because it's also GPL'ed, it's susceptible to others' improvements.
SVN works. arch works (its incompatibility with Windows is not a problem for the Linux kernel). darcs works (they regularly pull the kernel into darcs as a performance test of the system). Perforce works and grants free (as in beer) usage licenses to open-source developers (the FreeBSD guys use this for highly divergent kernel hacking) without the strange constraints that BK put on people.
So, Linux doesn't like those. So impeach him and elect someone that likes what you like and for your reasons.
Talking about Git--"Right now, the pain of using it (due to the rough edges) is just higher than the gain, unless you have rather specific needs--needs that the kernel development process has, but probably not very many (or any) other project," he said. "Even for kernel developers, it's certainly going to be less pleasant than BK was."
Bullshit. For an "uber-hacker" like Linus, filling out the "rough edges" of any of the existing systems *should* be trivial.
Yep, and every program that's ever been written in the Unix world was good enough for everyone else out of the gate. None of them needed improvement, and any that did were always honed to perfection by their original authors. That's bullshit. The thing about itches is, that once scratched sufficiently, they tend to stop itching.
Even if it isn't trivial for him, one of the other kernel developers could knock the rough edges off.
Which because he's GPL'ed it, they (and you and me) are free to do.
In addition, most of the newer SCM systems (darcs and arch, especially) are custom tailored for high code divergence, branching and merging.
But maybe they aren't particularly suitable to the Linux kernel development process?
I think we are just seeing the fact that folks serving as Lieutenants under Linus were the true talents behind Linux (actually you just have to look at how many of those people also commit changes to the *BSD kernels; it's an eye-opening experience). This tends to be true of any of the open source projects; however, only some of the leaders realize this.
-a
Again, was it ever credibly claimed otherwise?
--
Best Regards,
~DJA.-- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
