On Mon, 17 Jul 2000, you wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On Sun, 16 Jul 2000, Ian C.Sison wrote:
> > >
> > > It may be old but it serves its purpose. It has a well-defined extension
> > > architecture (remember XVideo? GLX? DGA?) and it is a standard. Try to
> > > bring in another GUI standard and all the vendors will be jumping over
> > > each other trying to leverage their proprietary technologies.
> >
> > Methinks now is not the time for another GUI standard. Now is the time to take
> > the codebase of X, cut out all the fat, the never used features, FORGET
> > compliance with that watyamacallit X consortium, and plain and simply keep the
> > focus: Desktop GUI. No more fancy stuff like remote X connections which aren't
> > really used, and who's functionality can be duplicated with programs like VNC.
> >
>
> Well, remote X connections *are* used. I use them for one. And to be
> frank, I don't think that is what's slowing X down and bloating it too
> much. It's just not done *right* under X. And using VNC to do the same
> would be painfully slow, at least from my understanding of the way VNC
> works. Try transmitting a true-color 1280x1024 screen across the network
> and see what "meltdown" really means. We had a chance with Sun's
> experiments with NeWS, but that never really caught on. A display
> PostScript could be just what we need (and last I heard, someone was
> writing a free one for the GNUStep project...what the hell is happening
> there?).
>
> > This i fear i can never see happen to Linux. Not unless X is re-engneered and
> > optimized for PURELY desktop functionality.
> >
>
> Reengineered and optimized yes. But not purely for desktop functionality.
> It's not X's client-server architecture that causes it to bloat. It's the
> cruft that comes from its heritage that bloats it.
You are right there about the cruft and baggage it has to inherit from
yesteryears requirements. However the client-server technology i believe won't
cut it for true direct to the hardware video updates for simple display
management. There's too much overhead if you simply want to manage a _local_
display.
If you want to use remote X sessions, then use the real X windows
implementation, as no one is really stopping you from doing so. My suggestion
is an alternative [bastardised] implementation of the X API which does away with
all possibleoverhead, and yet tries to remain compatible in order for higher
level layers to still work.
-
Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph
To leave: send "unsubscribe" in the body to [EMAIL PROTECTED]
