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]