> > > I think people are being too absolutist about
> > > this.
> >
> > Sure, here we go again with the assertion that video hardware is
> > somehow so very very diferent from all other kinds of hardware in a
> > computer that it must be handled in a way that is markedly different (and
> > inferior). It is *quite* obvious to all of us involved in the GGI project
> > that this is very much not the case, and since we have been hacking the
> > kernel for over two years now I would say that we come from a far more
> > knowledgeable perspective on this issue than most on this list, at least
> > moreso than those who seem to not be able to resist GGI-bashing.
>
> It *is* quite different from all other hardware: the number of sources
> involved
I'm not sure what you mean by 'sources' here. Different
manufacturers? Different types of video I/O?
> and the bandwidth of the data streams make it a unique case.
OK, I will grant you this. But, *all* types of hardware have
their own unique peculiaries and must be handled differently. Indeed, the
bandwidth issue would seem to argue FOR kernel inclusion of video driver
code, since that code will be foundational and a lot of other kernel
subsections will interact with it. Those interactions can be much more
highly optimized and tweaked when the kernel-user barrier doesn't need to
be worked around. Look at NT 4.0. The video drivers weren't in the
kernel in 3.51, but were moved into the kernel in 4.0, and they got a LOT
of speed out of it.
> However, when I say people are being too absolutist I mean both ways.
> I'm quite happy going with whomever puts out the better solution
> (XFree86 or GGI.) I'm just commenting on what I see.
It hurts to be labeled an absolutist when we feel that we are
simply following established OS design principles.
> > We walk the walk while others merely talk the talk. We are not
> > afraid to defend the validity of our ideas (on this list or anywhere
> > else), and back them up with running code. Given the scope of the GGI
> > project (an almost total rewrite of the Linux console subsystem), we are
> > doing pretty damn well, thank you very much, especially when you consider
> > the almost total lack of cooperation and assistance we have recieved from
> > the rest of the core kernel development team (exceptions noted - we know
> > who you are and we thank you).
>
> Given the vitriolic nature of the communications some of the GGI
> project members have had from the very beginning most kernel
> developers have written GGI off as a bunch of flukes.
^^^^^^
I think you mean 'flakes' |->.
> The flame from
> about a year and a half ago ("we're going commercial" or something
> like that) was the straw that broke the camel's back for a number of
> people.
That was an off-the-cuff remark born out of frustration. GPLed
code cannot be 'taken commercial' in any case.
> To be frank, I would be very hesitant to "defend the validity of
> your ideas" in any *other* form than working code -- may it be fair or
> not, you have exceeded your hot air quota by quite a bit.
Indeed, and as I mentioned before I have, since the last GGI
flamewar on this list, made a point of not even *mentioning* the GGI on
this list - even when GGI-related issues came up, I bit my tounge and went
back to coding. However, I WILL NOT stand idly by when attacks on or
misstatements about the GGI are made, on this list or anywhere else. We
have enough work ahead of us without having everyone in the Linux
community considering us to be 'flakes' and 'full of hot air'.
Jon