X 开发者大会 (freedesktop.org) 网上现场直播

jcome

We have scheduled a three day X Developer's meeting from Wednesday, April 28, through Friday, April 30, 2004, at the Cambridge Research Laboratory (CRL) in Cambridge, Massachusetts.

音频和视频直播：
http://out-166.tunnel.crl.dec.com./cgi-bin/twiki/view

jcome

#

Jim Gettys's talk:

    * The X11 drawing model was intended to be replaced since the beginning, but nobody had the expertise.
    * Rob Pike and the Plan 9 guys showed that Porter/Duff compositing can be done fast enough, even in software, for the basic imaging model.
    * 2D is fundamentally different from 3D.
    * Glitz shows that Cairo can run quickly.
    * New features don't get used unless they work on every X server. Dual code paths suck, as they never get tested.
    * X is but one component of a desktop environment. Good citizenship may involve fixing other components.
    * Application startup is painful. Latency kills you, not lack of bandwidth. Round-trips to the X server depend on latency. For GTK+, we have about 130 round-trips at application startup; we may be able to eliminate around 90% of them (we used to have about 130 round-trips; this got improved by batching/caching calls to XInternAtom()).
    * X through SSH is replacing the X security extension. Fat clients are really expensive;
    * X request stream is dominated by image data (gradient buttons, glyphs, etc.). This compresses extremely well, at a factor of around 300.
    * Still, we often keep duplicated image data in the client and the server. How to avoid that without going down the dreaded path of XIE? And how do we avoid re-compressing a stream that is already compressed (e.g. don't compress the part of the protocol stream that is already transferring a JPEG).
    * Toolkits should do a lot of the work (changes in screen size, for example).
    * Xlib needs to handle loss of connection properly; think of wireless networks. We should be able to preserve and migrate sessions, but we should then handle authentication issues. Think of GNU Screen but for X servers.
    * XInput needs support for hot-plugged devices, DBUS/HAL integration. We need support for networked input devices; think of a conference room with input devices for each attendee's table.
    * We need network audio. Current audio servers all suck. Need low latency for VoIP; need synchronization facilities for audio/video.

#

Keith Packard's talk:

    * Eye candy: translucent windows, magnifiers, window animation, flash-free window manipulation.
    * Right now we have visible window management effects — resize a window, the WM resizes first, then the application's content. The plan is to double-buffer the whole desktop, and have cooperative buffer updates. The perceived effect is that everything is cleaner/faster — in Mac OS X everything is smooth, so it appears to be faster, while it is measurably slower.
    * The plan is to have windows have their own OpenGL buffers for their content. Have the video card composite everything. Applications would draw everything off-screen. Have a Compositing Manager take care of compositing everything to the screen.
    * But then, input is currently untransformed — if you had a compositing manager that changed window positions/sizes (a la Exposé), you would have to transform coordinates in input events.
    * The compositing manager is actually another X client.
    * Synchronized updates: pend updates until client drawing done. Have a synchronization facility between window manager and clients.
    * Mouse input: X server figures out which window corresponds to the global mouse coordinates; it also defines the stacking order. This needs to be moved outside of the server.
    * Three new extensions:
         1. Xfixes: little things, Region objects.
         2. Damage: monitor rendering to drawables, send events indicating damaged windows.
         3. Composite: off-screen window contents, split window hierarchy.
    * Arbitrary visuals: ARGB visual for transparency; implemented with the Composite extension.
    * Keith started an Ultra Sexy(tm) demo; run a regular server and move windows around; things flicker as usual. Then, start the client for the compositing manager; everything is smooth now and it does appear faster.
    * Another cool demo; use a client to set the opacity of a window arbitrarily.

#

Jim Gettys again:

    * The Microsoft model of everything-in-client-PCs drives cost of ownership way up.
    * If we bother to make X good for remote operation again, and with security, interesting things can happen.
    * We should not require sysadmins at home!
    * We need fine-grained access control. You go over to a free computer and want to display your stuff there, but it should not interfere with what is running in it already.

#

Eamon Walsh on fine-grained access control for X:

    * Need to bring the X server into the Secure Linux project; need control on the level of individual protocol requests.
    * For the kernel, SELinux provides hooks for security implementations, but there's nothing special for the network. There are some user-space changes as well.
    * In the SELinux research agenda, there is local GUI security — the kernel and low-level user-space enhancements are practically done. Also pending are labeled networking and a network-wide policy.
    * X clients can exchange information in several ways, including window properties, so that has to be secured.
    * Just like the kernel, the X server could have a cache of security policy decisions.
    * Goals for security framework: based on existing work; easily extensible; non-intrusive (callbacks rather than local code); works at dispatch layer to avoid performance issues; provides framework for arbitrary access control extensions.
    * With the XC-Security extension, clients go to the server via a decision engine in the middle (Xext/security.c), that just has trusted/untrusted attributes. The idea is to replace that middle-man with a mechanism for callbacks (Xext/xace.c); those would make the security decisions.
    * You can install new hooks, and the security people can actually implement the callbacks.
    * KeithP suggests that instead of a flat list of hooks, it should be hierarchical for if a new security model wants to do more specific things.
    * Tytso: what about return codes? It's different to know whether an atom exists than whether its value is actually accessible. Reply: the middle-man can modify the return values however it wants.
    * Non-intrusiveness: that's why the core code is separate from the actual security implementation — middle-man versus the callbacks. The whole framework is a compile-time option.
    * Sample hooks: CORE_DISPATCH, EXT_DISPATCH (replace XC-Security shadow dispatcher); RESOURCE_ACCESS, DEVICE_ACCESS, PROPERTY_ACCESS (replace SecurityCheck*Access() functions); MAP_ACCESS, BACKGRND_ACCESS (replace untrusted child & background "None" checks — windows with a background of None can be used maliciously to get the content of underlying windows).
    * Can get client credits from several sources (basic PID, UID, GID, or a security context).
    * For now, there is an AUTH_AVAIL security hook for remote clients.
    * Future work: trusted window labeling (e.g. have your window manager decorate secure windows differently from normal windows — how do you pass this information? via a secure window property, for example).

#

James McQuillan on the Linux Terminal Server Project:

    * Diskless think client; boot over network. Xserver -query to log in via XDMCP. Can run apps locally. Low hardware requirements.
    * Widely used for schools (k12ltsp), kiosks, internet cafes.
    * Current security is X through SSH. In the future, Kerberos, NFSv4, IPSec, or other options.

#

Ted T'so follows up on security:

    * Kerberos is nice from ~200 users onwards. SSH is nice for up to about 100 people, but it gets messy when you need to remove authorized keys from many machines (e.g. someone from your organization leaves), or what if a key gets compromised. However, SSH is dead easy to configure.