Linus Flames Lisp

,

The following is originally posted to newsgroup comp.lang.lisp in 2007-12.

Linus Torvalds wrote:

I'm distrustful of projects that do not have well-defined goals, and well-defined interfaces. They tend to bloat and do “everything” over time. This is what gives us horrors like GNU emacs and Mach: they don't try to do one thing well, they try to do _everything_ based on some loose principle (“LISP is good” or “microkernels make sense” or “GGI should do graphics”)

I'm in general of a anti-hero attitude… and so i haven't much read any writings by Linus. However, in the past decade since i'm in the unix industry (since 1998), I have ran into a few of Linus's writings.

My impression is that he's one of the rather more pretentious type of character, prone to use words and rhetoric to smite different opinions in a nonchalant way. (but i think he's overall a good human animal)

Yesterday i was checking out what's the current status of the vapourware Fresco windows system, and in turn i was reading about GGI (http://en.wikipedia.org/wiki/General_Graphics_Interface)

Then i ran into one of Linus's post: regarding it.

List:       linux-kernel
Subject:    Re: GGI Project Unhappy On Linux
From:       torvalds () transmeta ! com (Linus Torvalds)
Date:       1998-03-26 6:52:04

Source marc.info

I don't know much about low-level programing. The article seems reasonable and level headed, but except that gratis emacs lisp vilification (and Mach). What a practical asshole.

Linus's Original Post

For historical preservation, the original article is pasted below.

List:       linux-kernel
Subject:    Re: GGI Project Unhappy On Linux
From:       torvalds () transmeta ! com (Linus Torvalds)
Date:       1998-03-26 6:52:04
[Download message RAW]

I won't answer to any of the individual postings, but I _can_ try to
explain my own personal standpoint, and at least let people know _why_ I
think as I do. 

But before I even start on this, I'd like to point out two things that
are completely unrelated to GGI, but may well explain to some people
what my behaviour wrt the kernel is concerned is based on. 

 - I have always seen my job as kernel maintainer to be acting as not
   only a developer, but more importantly act as a _filter_ for others. 
   That has obviously become more and more important over time, as my
   personal development effort has been more and more superceded by
   having tens of other kernel developers. 

   As such, my most important function is to say NO! to people.  This
   continually surprises some people, as they see a very rapid pace of
   development, and often huge patches on a weekly (or even daily)
   basis. However, there are a few things you should realize:

	- I usually don't say no to driver development and stuff that
	  doesn't impact anything else.  If a new disk driver is broken,
	  it can't be any worse than not having a driver at all, and even
	  a broken driver is more likely to receive attention than
	  somebody having to start from scratch. 

	  The same thing goes for architecture-specific patches that do
	  not impact any other architecture, and doesn't impact any
	  fundamental kernel code.  I only start worrying when there are
	  patches that imply _future_ modifications and imply a new
	  framework for new things: THAT is when the "design" of the
	  system starts to come into play.

	- There's often a backlog of patches that have been floating
	  around for some time, and they have often had quite a bit of
	  feedback from me before they actually make it into the standard
	  kernel. Usually they have also had a longish period of real
	  use by real users.

 - I don't see the world in black-and-white.  I don't actually like
   Linux-only features unless they have a good reason for them, and I
   really like Linux to be a "standard" system (with reasonable
   extensions where they make sense, but they really should have either
   minimal impact or be _really_ sensible in somethign that there is no
   previous standard). 

   The world would not be a better place if Linux were to be the only
   operating system out there, and we should play along with established
   standards if we can and when that makes sense. From the very
   beginning of Linux development the whole idea was not to create a
   Linux-centric world, but to create a good operating system that
   worked with what was already there.  Much of early development was
   not modifying applications to suit Linux, but to modify Linux to suit
   applications. 

 - Finally: I'm flexible.  I can be convinced.  But I am almost _never_
   convinced by rhetoric: I'm completely unmoved by people arguing about
   things on a theoretical level or using pretty words and examples to
   get their point across.  I'm _only_ convinced by real code, and by
   people actually _doing_ rather than talking. 

   I may be cynical, but there's way too much hot air on the internet,
   to the degree that I don't believe in anything that I set sent in
   email or see on the internet before I've actually seen some real
   action.  "Show me the code" can convince me, but "wouldn't it be nice
   if" has absolutely no power over me.

Ok, with that not-so-short preface, I'll tell you a few reasons for why
I have been less than entusiastic about GGI:

 - I think that X is good enough.  Yes, X is larger than some people
   like, and it could be faster.  But X has a lot of good features that
   make it better than any of the alternatives I've seen so far.  I
   never much cared for the original SVGA-lib, and the GGI people seemed
   to be more impressed with SVGA-lib than with X. 

   Yes, there are older and smaller machines that don't run X all that
   well, but I refuse to let those kinds of machines set the Linux
   design decisions.  I think SVGA-lib is the correct solution for thise
   kinds of setups, and for anything remotely modern X is the way to go.
   I want to think about the _future_, not the past.

   Again, I can be convinced, but I need to be conviced by _actions_,
   not words (and "new graphics cards don't come with support in
   SVGA-lib" is not a very good argument, even though I've seen it
   multiple times.  New graphics cards are usually plenty good enough
   for X). 

 - I'm distrustful of projects that do not have well-defined goals, and
   well-defined interfaces.  They tend to bloat and do "everything" over
   time.  This is what gives us horrors like GNU emacs and Mach: they
   don't try to do one thing well, they try to do _everything_ based on
   some loose principle ("LISP is good" or "microkernels make sense" or
   "GGI should do graphics")

   For example, in fairly recent emails on the matter I have very much
   supported a much more _limited_ goal of trying to do everything to
   help the XAA ("XFree86 Accelerator Abstraction" or whatever the TLA
   stands for) work well. Because unlike GGI, the XAA project:

	- is well-defined and with very clear and defined goals
	- has working code already in production use (not in the kernel,
	  but that's actually a bonus, they have a good user-level setup
	  already, and kernel support would be only an extension of
	  something that already works)

 - I've seen more arguments about GGI than about anything else.  That
   may be because the issue is so muddled, but the point is that it's
   not endearing me to the project.  There's a lot of [mis]information
   floating around, and the whole _issue_ is muddy. I don't think that
   leads to a good design.

Anyway, I do believe that graphics support is extremely important, but I
think that doing it right is more important.  And I'm not going to jump
head-first into anything that would be very hard to back out of before I
_know_ it is right. 

		Linus
blog comments powered by Disqus