Vista, etc.

[Christopher Browne]

On 12/22/06, D. Hugh Redelmeier <hugh-pmF8o41NoarQT0dZR+AlfA at public.gmane.org> wrote:
> | From: Simon <simon80-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org>
>
> [Please, folks, trim your posts.  And don't top-post.  The Fedora
> mailing list guidlines seem reasonable:
> http://fedoraproject.org/wiki/Communicate/MailingListGuidelines#head-90ccad98d62191f372b5f14c74baabb5d38fb58d
> ]
>
> | Also, there must be other practical uses for AIGLX than just this,
> | like accelerating remote clients, which I _assume_ is possible now.
>
> I don't really understand the new things in X.  My impression is that
> many new facilities are not great over a wire.  Like Render.

Yeah, I think they are making more assumptions these days to the
effect that "all access is local."  It's true, sometimes, but it's
mighty dangerous to build requirements for that into apps.

Does Render only work over :0?  Or only *well*?  That's not at all
clear from the documentation...

It doesn't sound like it should intrinsically need to be local-only.

Is there a relevant connection between Render and Cairo?  The latter
seems to be a mechanism that some of the GUI libs out there seem to be
moving towards; by having some higher level abstractions (e.g. - a
rendering model akin to the "easy bits of Postscript"), you should
have something that lower levels could optimize.

> I'm not even sure that X drivers don't compromise security: allowing
> direct access to the video card may allow direct access to anything in
> memory.  Even if you are only trusting the X server program, that is a
> lot of code to trust.

This (the X server) has grown to a big enough monolith, even with the
theoretical merits of the modularization process in R7, so that
auditing this for security seems problematic.

> |  I
> | also would say it got merged basically because it adds optional new
> | functionality without breaking anything.
>
> Yikes.  As if X didn't already have too many features.

Few systems have the ability to diminish their features without
risking forking/cancellation...
-- 
http://linuxfinances.info/info/linuxdistributions.html
"...  memory leaks  are  quite acceptable  in  many applications  ..."
(Bjarne Stroustrup, The Design and Evolution of C++, page 220)
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists