Getting xserver patches reviewed

[Bernardo Innocenti]

On 11/24/07 10:20, pcpa at mandriva.com.br wrote:

>   The X Server also isn't as attractive, i.e. being a Kernel hacker is
> usually considered cooler than being a X hacker.

True, but I really can't see why...

Clearly, the Linux kernel is in quite a good shape and
is no longer *that* crucial for a wider adoption of Linux
in the enterprise or in the desktop.

The graphics subsystem, on the other hand, is really where
Linux lags behind Windows and MacOS X.  Working on it,
offers a lot of opportunity for improvement that will
make a big difference.

Non-techie users look at how the interface looks and behaves,
and base their subliminal perception of the whole platform
from these hints.  Being slowish or flickering, simply
makes us look bad in their minds, and there are no benchmarks
that can change their perception of Linux being slow and
clumsy.


> But if the X Server
> magically becomes "mission critical" ready, lots of people would want
> to have theirs names associated and start contributing, but this is very
> unlikely to happen as the stability is heavily associated with fully
> functional interfaces and graphics chips, that may either be buggy, or
> the driver may contain bugs.

The Linux kernel also deals with imperfect or undocumented
hardware.  I suspect the huge number of developers is what
makes drivers more mature.

Now, I know I'll get tomatoes from both X and the kernel
hackers for saying this, but I claim that the X codebase
would be much *easier* to work with than the kernel.

First, because it's single threaded.  Second, because it
runs in userspace.  Third, there simply are fewer transversal
concepts to deal with, such as paging, execution contexts,
dma, software suspend.

Despite its bad reputation, most of the code I've seen in
the guts of the X server looks quite tidy and easy to work
with.  There are a few exceptions, of course, but over the
past two years I've seen lots of big cleanups happening.

If anyone still thinks the X server is hard to work with,
please clone the git tree and start reading from main() on.
No kidding.

There are *lots* of open newbie tasks such as eliminating
the excessive use of #ifdef's, switching to C99 types and
undoing the questionable idea of hiding pointers behind
typedefs.

"X is hard and uncool" is just a heritage of the obscure
XFree86 age.  It's not been true for a while.


>   Another problem is license (the dead horse :-) There should be a
> mechanism to allow developers to contribute GPL code, other than, "do
> your own new project". I did not yet finish a repository I have been
> planning due to, guess what, lack of 'qualified people' time. But if
> xorg/freedesktop implements something similiar, I would be happy and
> submit for commit rights. One of the things I have been considering,
> is something like having gpl code residing in a subtree, and then,
> at build time one could choose if wants to compile with gpl code or
> not. The idea is to work with symlinks. Well, nothing prevents me
> from making my own mirror at Mandriva, where people here can commit
> GPL licensed code, so, maybe I will come back here for a more
> concrete proposal to it later, when this is more than a "wishlist",
> with more than "changing my own git mirror in my own computer".

I also had this fear that use of a permissive license would
have made Xorg an easy prey of pillagers.  It was very much
the case with Wine, until they finally switched to GPL.

But these days, even companies in the business of proprietary
software seem to be willing to contribute their code back to
Xorg...

So until the situation changes for the worse, there's no clear
advantages to justify undergoing the endless religious wars
that a license switch would take.

Except, maybe, for the VNC case.  Did you have some specific
piece of GPL software in mind?

-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/