Ying Tong Iddle I Po

Pleasure is remembering that the Carlton Arms beer festival starts today. I shall certainly be hoping to make it over a little later on.

Yet again I totally failed to do any admin but managed to send an invoice for all this month’s consulting off. Also got some good results from the work which was nice. I also did about 2 quanta of thesis work too. I’m feeling somewhat stressed at the moment so would like a random fun job which, in my current state of mind, is probably going to be writing some sort of article. Unfortunately I have no ideas. I started writing an article/tutorial about using the new Composite extension in recent X.org X servers to enable people to experiment with eye-candy but it got too long and involved (note to self - probably better to assume reader-knowledge of Xlib beforehand). I still want to write a proof-of-concept OpenGL based compositing manager[1] but a flaw with the Composite extension, IMHO, is that one cannot selectively choose which sub windows to split the window tree at. Only none or all of them (to those who have no idea what I’m talking about, it pretty much means that one has to manage all or none of the windows, not all minus the one you hope to display in[2]).

[1] Luminocity [sic] is already such a thing but it requires one run two X-servers, one to displaying the composited screen and a ‘fake’ one for the applications to talk to.

[2] In principle one can associate a GLX visual with the root window and work from there (the same way that xcompmgr does with Xrender) but GLX + Composite don’t play nice at the moment[3] meaning that clipping is all screwed. I do not want people to have to apply patches to X.org to follow the tutorial :).

[3] Something I’m not entirely sure can be fixed without some serious changes to the DRI model like OS X does[4].

[4] All rendering is done into off-screen pBuffers and composited by the Window Server. Under the current GLX model the DRI system mediates direct access to the frame-buffer. This is better for cards without pBuffer support but a pain in the bottom if one wants to have a central process responsible for compositing.

Gah - loads of thing to do today of which I have done almost none. The printer is conspiring against me trying to register as self-employed and I forgot my laptop which I have to get Apple to fix again (the famed motherboard problem…). I got a fair bit of actual consultant work done though so it isn’t all bad. I also got around to re-installing GNUStep on my Linux box so I can pretend it is OS X :).

I rarely post bash quotes but this one made me laugh out loud in the middle of the lab.

<Azemilcar> What do you Brits say when you stereotype American speech?
<Starblaydia> anything lacking irony or sarcasm usually qualifies, Azemilcar
<Gala|drunk> *nod*
<Yamatto> or we just hoot like gibbons and invade sandy countries.

Update: This quote just floated over from a discussion on the other side of the lab: “But having them separate is just a special case of keeping them together…”.

I’ve just finished re-installing (multiplying by 5 the storage space) our MythTV box here. I don’t know if it is a function of our new telly, the change in OS, the new version of MythTV or it being the second time I’ve done it but the picture quality has improved dramatically. I’m having fun now watching a pr0n^WOsbournes DVD and enjoying the fact I also got around to binding LIRC to xine.

Oh goodness. Robotic bins made by an artist + a large technical student population = some amusingly hacked bins methinks. Lucky for them the nearest college is Homerton.

Meh. That is my opinion :). I appreciate that the PPC is neater and nicer in many respects but, aside from easy virtualisation courtesy of mol, day-to-day the processor doesn’t particularly affect me. For 99.9% of typical real-world uses I would imagine the switch to x86 will make little negative impact and there will always be more R&D being poured into x86 than PPC. I don’t know whether the ‘Intel’ switch is x86_64 or x86 but I would prefer the former just from a future-proofing PoV. All-in-all I’m in favour if this means I can install OS X on my no-name beige box, or at least can virtualise the hardware fairly simply[1].

What does annoy me is people who say the port must have been easy since OS X is based on FreeBSD. This is a wonderful example of the Apple tech marketting creating a myth and sustaining it. OS X is based on Darwin for the kernel and also has a collection of Unix-style CLI programs from BSD. Darwin is a Mach-based OO kernel with a FreeBSD compatibility API. This means that some drivers and sub-systems can be ported from FreeBSD but, to take an example, the IO system (USB, keyboard, etc) is based on IOKit — totally unlike FreeBSD’s kernel. It is like saying that Win 2k is based on FreeBSD and GNU since the TCP/IP stack is from BSD and one can run the GNU tools on it. Darwin is a wonderful OS to read and browse (I highly recommend it) and writing a device driver is far easier but don’t go giving the BSD guys too much credit.

[1] Given Xen + a sufficiently clever person + a port of Darwin + a hack to the OS X installation packages to replace the kernel image some very cool magic could happen indeed.

I’ve just been bitten by this bug in Ubuntu Breezy (TBF it is the unstable release). This, eventually, necessitated downgrading a load of things on my system pretty much by hand. I wish I were still using Gentoo…

http://blogs.gnome.org/nb.cgi/view/rbultje/2005/06/01/0 *grin*

In other news DM updates have stopped for a while because I’ve paused development for a while. Remember the ‘nightly’ builds are only as new as the latest SVN.

I recently started doing a bit of consultancy work + thesis writing up. I don’t even have time to wikisurf anymore :(.