Index: [thread] [date] [subject] [author]
  From: Andrew Apted <ajapted@netspace.net.au>
  To  : ggi-develop@eskimo.com
  Date: Mon, 24 May 1999 12:52:51 +1000

Re: kgi into 2.3.x

Christoph Egger writes:

>  And what did Linus say about the idea of KGI?

Below is what he said about a year ago on linux-kernel.  I don't what he
has said recently since I dropped off that list a long time ago, but I
doubt his opinion has changed much in the meantime.

Cheers,
___________________________________________________
                                               \  /
  Andrew Apted   <ajapted@netspace.net.au>      \/
 

|  From: torvalds@transmeta.com (Linus Torvalds)
|  Date: 26 Mar 1998 06:52:04 GMT
|  Subject: Re: GGI Project Unhappy On Linux
|  
|  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


And then this:


|  From: Linus Torvalds <torvalds@transmeta.com>
|  Date: Sat, 28 Mar 1998 23:27:30 -0800 (PST)
|  Subject: Calm on the GGI waters..
|  
|  Hi all,
|  
|  Bill Harvey just sent me the first rational email in this whole
|  discussion, and it wasn't about GGI at all, but about the debate.
|  
|  He reminded me of what I always know but sometimes ignore: flaming doesn't
|  get you anywhere. As a result, I decided I'd better apologize for my
|  choice of words in the debate, and I think I'll just not reply to this
|  thread any further because I can't seem to not get upset by it. 
|  
|  I know a lot of people want to make a better world for graphics in Linux,
|  and I agree very much with that goal. I obviously don't always agree about
|  the methods, but things have only gotten worse from this particular
|  discussion, which is why I'll go sit in a corner with an ice-pack for a
|  while just to calm down.
|  
|  Sorry again for some of the harsh words, and I hope this apology will
|  allow some people to re-read my emails, ignore the inflammatory tone, and
|  still consider what I've been trying to say. And when I get irritated,
|  give me an extra inch (or mile) of rope, knowing that Linux is _very_
|  important to me, and that I can easily get carried away.. 
|  
|  		Linus


And then this:


|  From: Linus Torvalds <torvalds@transmeta.com>
|  Date: Sat, 28 Mar 1998 23:51:50 -0800 (PST)
|  Subject: Re: Calm on the GGI waters..
|  
|  Btw, one last word to clarify my position a bit, and maybe explain why I
|  have gotten so upset by the GGI discussion. 
|  
|  For example, I've already pointed out that the current kernel already
|  _has_ a rather limited support for graphics: it can already write text on
|  various graphics cards (the TGA chip I mention is only one of them, and I
|  brought it up really only because that's the one I've used personally). 
|  
|  So what is the difference between that kind of graphics support and the
|  GGI kind? 
|  
|  The difference is really a matter of interface, and tying my hands.
|  
|  The TGA kind of "make the graphics card work as a text-mode thing" kernel
|  code does not imply a new interface. The code to do the text rendering may
|  be simple or complex, buggy or bug-free, but whatever the case is it does
|  not limit me or the kernel in any way because it really implies only a
|  very limited interface to user space, and it is also an interface that I'm
|  more thn happy to provide and that is _obviously_ required, ie a basic
|  tty-like interface. 
|  
|  Think of it as a very basic kind of driver, but a driver that makes no
|  policy. The kernel only really guarantees that it can write characters on
|  the screen.
|  
|  In contrast, the GGI kind of interface implies a lot _more_ in the way of
|  support. And by implying that, it ties my hands: I am no longer free to do
|  what I think is right, because I have to abide by the interface. This is
|  what makes UNIX so good: the basic interfaces are _really_ well thought
|  out (whether by chance or good design the basic "fork()" + "execve()" +
|  "everything is a file" mentality is a very simple but powerful one). That
|  is why I like UNIX, and why I wanted to write my own. 
|  
|  So while I'm more than happy to have my hands tied in the sense that I, as
|  the maintainer of Linux, export that kind of fork() + execve() type of
|  interface to user mode, I am not at all certain what kind of interface I
|  would feel happy about exporting wrt graphics. I feel confident in
|  exporting the text-mode things - that one is a no-brainer. But graphics? 
|  
|  As a result, I kick back _very_ strongly because I don't see any
|  "obviously correct" interface. I'd be happy either with something very
|  generic (basic DMA and interrupt interfaces to XFree86, for example), or
|  something very specific (some very limited subset of XAA for example: only
|  the bare necessities to make XAA easier to do). But anything else is not
|  "obvious" any more.
|  
|  And when it is not obvious, I feel that "nothing" is much better than
|  "something that might not be the right thing".  Because it is much easier
|  to fix up "nothing" than it is to fix something that people depend on.
|  
|  		Linus

Index: [thread] [date] [subject] [author]