modular -> monolithic

[JoJo jojo]

Well now we are getting somewhere,

X.org is not sexy enough?
(well we could always fork a xxx.org, but I postulate 1 X is enough)

X has less developers?
Yes, as a result of XF86 fork, community is still divided,
some people(OS/companies) are still using xf86?

Resistance to change?
Naturally, from Xfree86 to X.org like windows to Vista.
(will take time & understanding) likely 2 steps forward 1 step back.

Compatibility Vs manageable code base
Leave it to the X engineers, they know what they are doing,
let them draw the line. Just add transparency to the mix.

Large codebase has quality issues?
Yes,  problem is compounded by forked community,
building from source problems, backward compatibility,

X.org is largely neglected by opensource community?
We need an attention hog, flame-fests. The kind that make short-work of
emacs-vi, freeBSD-linux, OpenBSD-helloworld.
May I suggest a plan, get RMS, respected(somewhat) by most,
this automatically guaranties the attention of Theo & Linus,
this could really snowball into something big !
(although X.org might have to adopt GPL3 which means another flame
automatically !)

damn we are good at this.

-JoJo

On Jan 23, 2008 11:22 AM, Keith Packard <keithp at keithp.com> wrote:
>
> On Tue, 2008-01-22 at 21:28 -0600, Pat Kane wrote:
>
> > In the good old days RWS  did that.
>
> Where by 'good old days', you mean before 1988. After that point, the X
> consortium staff (including RWS and me) were paid by the corporations
> doing the development, and it wasn't (yet) clear that the corporations
> shouldn't have a direct say in what went into the distribution.
>
> Thus we suffered through XKB, XInput, XIE, PEX, VEX, Xt and a wealth of
> other really bad ideas, along with the constant requirement that
> 'nothing old stop working'. Shockingly enough, the only things which
> survive unscathed from that era are things which were *not* developed
> using this model (Shape and Xv being the only two largely intact and
> non-trivial extensions that we use today).
>
> It's really only in the last couple of years that we've taken a strong
> stand against some of those mistakes, along with an acceptance that
> we've still got a lot of catching up to do. Having spent the last 8
> years adding a bunch of missing functionality, we're only now starting
> to work on areas of the system which cannot easily be fixed in small
> incremental steps.
>
> One thing the kernel never faced was fifteen years of fundamental
> stagnation with a wealth of kludge-arounds piled on top.
>
> --
> keith.packard at intel.com
>
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>