[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Interesting story about Linus
Ruth Wolfson said:
> I came across this story on the web, about Linus killing Linux?
> Thought some of you might be interested in reading it, if you haven't
> already seen it.
>
> http://www.techweb.com/wire/story/TWB20010126S0013
>
> Any thoughts on this?
My initial reaction is that these people are complete morons.
These people obviously just don't get it. I quote:
"VARs are reluctant because they don't see a clear channel. They
don't see a Microsoft or strong corporate company saying, 'We're
going to be here forever,'" he said.
("He" being "Hal Davison, owner and president of Davison Consulting,
Sarasota, Fla.")
I have a hard time figuring out where to start, but here goes. First
of all, it scares me that twits like this honestly think that
companies like Microsoft have done *anything* right, and that there is
*anything* about them that the Linux community would have any interest
in emulating.
Here's the primary problem with this whole line of thinking... Linus
(along with Alan Cox, David Miller, Ted Ts'o, Stephen Tweedie, etc.)
is *the* reason that Linux doesn't suck. He's an excellent engineer,
and, even better, he has an excellent sense of taste. He refuses to
put anything into the kernel that he thinks will harm the kernel
long-term. (The other guys I mentioned, and others, are great at this
too, plus Linus does a good job of educating others on what is
acceptable.) Linus also refuses to leave cruft in the kernel for
backwards compatibility at the kernel level (in other words, binary
kernel modules aren't guaranteed to work for any kernel other than the
one they were compiled for) for the same reason. The example always
used for why this is a Good Thing is Microsoft's flagship products,
Windows. There's so much cruft for DOS, 16-bit Windows, etc.
compatibility that every version of Windows has become an
unmaintainable mess. (That said, note that most Linux programs still
work as long as you have all the appropriate libraries. I still have
a.out crap from '94 and earlier that still works. The kernel
developers do everything in their power to not break userspace that
don't mess with kernel internals or /proc.)
Regardless, if *anyone* wants to have more control over the direction
of the kernel, they need to just write more damn code. Linus won't
refuse good code. What he will refuse is "direction". He's not
interested in proposals. He's interested in seeing working code.
Even if Linus doesn't like a bit of code, there's *no* reason why
*anyone* can't keep making a patch available, even if it *isn't*
accepted into the main kernel. (A good example of this is Reiserfs.
It's been available for a long time. Several of the distributions
have included it for some time. Linus didn't accept it until the
2.4.1 pre-patches. Another good example is KDB, the kernel debugger,
which Linus has said he'll *never* accept since it touches too much of
the kernel, even if it is a useful piece of code for a lot of people.)
If you want to see an example of a company that seems to actually
understand Linux development, see
http://oss.sgi.com/
Some of SGI's kernel work has already been included in the kernel.
Other stuff will definitely be added when it has matured a bit. Some
things will never be added to the stock kernel for various reasons.
All of this work has definitely had an impact on kernel development
though. You can see it in late 2.2.x kernels, and even more so in
2.4.x.
Oh well... I should stop now and let my blood pressure return to
normal.
Steve
--
steve@silug.org | Southern Illinois Linux Users Group
(618)398-7320 | See web site for meeting details.
Steven Pritchard | http://www.silug.org/
-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.