Time Heals All Wounds.. And Then Kills the Patient
<Previous Next>
Evening
Evening
Wed Mar 14 12:28:47 2007
Eye Construction Kit
Topics:

One of the things I think I could really get into if I were to have a systems-type job would be to work on the guts of X (or other things of that sort) - I like OS kernels a lot too, I can get really interested in reading about the latest clever optimisations that compiler people are working on, and thinking about virtualisation gives me warm fuzzies, but X has always been a love of mine. One of the things that's led to advances (of sorts) in X is people looking at the system as a whole and asking, "How can I work around what normally happens to make this specific case work faster/better" - using things like SHM support and direct(ish) hardware access partially to wholly avoid the normal X software path. This can be good for some specific purposes, but I cringe when I hear about GNOME people building dependencies on GL and similar libraries/APIs - this effectively changes the common case. I like having fast, pretty graphics when I'm playing some kinds of games on X and for screensavers, but for normal tasks, network transparency is far more important to me - I don't want my desktop to be as bouncy and interactive as OS X, especially if it uses OpenGL because it'll be all kinds of slow whenever I connect via VNC or use nonlocal X. I wish people were working on the opposite to all this GL stuff - it'd be awesome to pull X communication up to the toolkit level (when feasable) with fonts, widgets, and similar negotiated between client and server and XPM-style communication a last resort. This would entangle toolkits and X itself, but so long as this entanglement were an extension that were itself optional, I think it could be cleanly implemented without burning too many bridges. I get the feeling that I've written about this before though...

A few random bits for y'all:

I've been having a grand time with this weather. Hurrah!