Unfortunately, Matthew is correct, and it seems that Ryan Farmer is the idiot that signed a few of us up to about 200 mailing lists this morning. Not only do I trust Matthew's analysis (and was watching him go through the various steps on IRC as it happened), but then there were two other bits.

Ryan refused to approve two of my comments I made on his latest blog entry (more than happy to screenshot this). He claimed he too had been spammed, and had to abandon his email address of a few years. Even if you ignore the length of the text blanked out in the title bar not even remotely matching the length of his personal email address, there were only 131 messages in the inbox, of which 127 were unread, and no others but spam visible. He claimed they were archived; I offered to publicly apologise if he'd do a quick screencast showing him logging into that account and showing some messages from the archive to prove the point. Unfortunately he didn't bother approving these comments. (Incidentally, if you had to 'abandon' an email address due to an avalance of newsletters, et al, which took an hour or two to fully unsubscribe from, would you still bother blacking out the address everywhere?)

As per his standard 'insult everyone with random images from the internet and YouTube videos, then wildly claim conspiracies against him' policy, he went on to claim Matthew was conspiring against him, but given the choice between Matthew conspiring and severely irritating a few of his friends in the process, and some scorned 16-year old continuing his track record of acting like an irrational, immature idiot, I know which one I'd pick.

It takes some skill to be banned from all the Ubuntu IRC channels and the Ubuntu forums both, but I guess this morning showed that was completely justified. Apologies to everyone waiting on the announcement of sponsorship for XDS, as well as hotels, but unfortunately some people just can't conceive of having better things to do than acting like chavs. Hopefully IzanbardPrince/TheAlmightyCthulu/etc goes back to impersonating Kevin Carmony, flaming the bejesus out of companies using BIOSes which trip Linux bugs, and other, equally productive, uses of his time.

Sorry for the hideously late announcement, but an extraordinary comedy of errors involving quite a long chain of people and a series of unfortunately timed holidays meant we couldn't confirm this until now.

Anyway, the 2008 X Developers' Summit will be held from Sep 3rd-5th at Edinburgh Zoo (nearest airport EDI, or overnight sleeper train from London). More details and links to come later today. See you there!

Make of them what you will.

daniels@psyence:~/x/xorg/xserver% wc -l **/*.[ch] | tail -1
  730420 total
daniels@psyence:~/x/xorg/xserver% git diff -p xorg-server-0_99_1.. | diffstat | tail -1
 2747 files changed, 178062 insertions(+), 628051 deletions(-)
daniels@psyence:~/x/xorg/xserver% echo $((628051-178062))
449989

I agree pretty much with what ajax said, but Alberto's post struck me as pretty weird. Given that git's internal format has been unbelievably stable (indeed, far more stable than bzr: a few times, I've just given up trying to get code because doing so would require me to compile a new bzr -- barrier to entry like what), I don't see what's stopping anyone from developing alternate git clients that are all Windows-friendly (or OS X-friendly, or Eclipse-friendly, or whatever).

A quick FAQ: the reason all DSA keys have been removed from fd.o and we aren't accepting any new ones is that they are vulnerable to man-in-the-middle attacks if they have ever been used (not just generated) on a system with a predictable RNG: see Steinar's summary of the maths. We're going with precedent of debian.org rejecting DSA keys, and a general desire to be safe rather than sorry. RSA keys are the default in OpenSSH anyway, so I'm not really sure why you'd want to generate DSA.

If you're attending the excellent FOSDEM (which you should), you should make sure you get down to my talk on input. We're now at the stage where we understand not only the problems, but their causes and fixes, and the code which led us there, and I think by early 2009[0] we should be in really good shape. Finally.

I felt a bit bad posting a blog entry just about myself, but then I thought hey, at least I'm not putting a picture of myself in here.
[0]: Peter has a thesis to write, I have work to do and another move to make, et al.

The X Developers' Conference 2008 will be held at the Googleplex in Mountain View, California from April 16th-18th, 2008. If you're interested in coming, please sign up at the wiki; we're also interested in having people talk if they want to. More details as they come to hand, but start booking your flights now.

After my shameless beg, a number of people emailed me (thanks -- sorry about the lack of comments) to tell me that I should really be using awesome, and I am. (Other popular suggestions were wmii and dwm.) I'm well happy with it so far, so thanks!

Dear lazyweb,
I want to try out a window manager like Ion, but I don't want to actually use Ion due to the fact the author's an irritating nutcase who I'd rather not encourage any further, and its utterly daft license. What's a man to do?

Following on from AMD's announcement at XDS 2007, Intel have just released documentation on their graphics hardware, without NDA, available to the public. There's also a mirror at X.Org. Cheers, Intel!

< eikke> is there any "small" thing which I could be able to do, now?
< eikke> if possible wihtout breaking my hardware as there's no major company behind my back :p
< marcheu> eikke: the most likely way your hardware breaks when doing driver stuff is because you throw it out of the window

Every time I see a post about changelogs (sorry Behdad, nothing personal), I die a little bit inside.

There are three problems here:

• In any merge, you always collide horribly on the ChangeLog, and it just makes working with more than one person and/or branch nigh on impossible, so you lose all the benefits of an RCS that actually supports merging.
• git gives you a system with very lightweight microcommits: in your local tree, you can easily amend, rebase, modify, and walk back, before you push. So, instead of queuing up ten million things such that you need a complicated changelog, do lots of little, relatively self-explanatory commits.
• Even when you have complicated commits that require explanation (e.g.), just make the commit log sufficiently verbose, so that git blame, gitweb, and any other tool, can offer people the full context, rather than making them dive into an unrelated file and remember the exact date, etc. In X, we just generate ChangeLog from git log, and we're really happy with that so far.

Matthew Tippett just threw a CD full of AMD/ATI specs to Dave Airlie, approved for public release with no NDA. I'm now holding one of those CDs as well. Thanks, AMD.

In the past five hours, we've pushed 72,000 PDFs, for a total of around 1TB. This ... turns out to actually push the limits of our new fd.o setup.

I'm sitting here at XDS, and John Bridgman and Matthew Tippett are announcing AMD's open source plans. In three words: 'specifications without NDA'. 2D very soon, 3D coming when the legal issues have been taken care of. Specs for the r3xx core will probably be coming later on down the track.

I don't need to say how awesome this is.

6124 daniels 15 0 2109m 1.5g 18m R 1 75.4 426:30.01 firefox-bin
3000000 1486 74 1 5808 962 1427069K 60K 1427129K 6124 Django | Model reference | Django Documentation - Mozilla

I honestly don't understand how Firefox could consume 1.5GB of RAM, as well as 1.4GB of pixmap storage in the X server. This is a new record. (And the pixmap storage rose to 1.7GB before I killed it.)

Just under a week after XDS was announced, we've already got 38 (out of 40!) attendees registered. 40 is our current cap, and we need to change it soon if we're going to break that number, so please, ensure you're registered if you're planning to come. If there's too many people, registering now won't bump other people off, it'll just mean that we know we can increase the size a bit. :)

Our accommodation is in 'single sets': a study with adjoining bedroom (single bed), and en suite (so, your own shower and toilet). For the moment, registration is everyone who's signed up on the attendees page, and hasn't told us that they're not staying in the college. Please do not contact Clare College and book the rooms yourself: we have a big group booking.

Wireless will be available in the main conference room, as well as in the bedrooms, and a common area.

So: if you're thinking of coming, register!

Update: We're now at 38 people, not 25. Two spots left.

After a bit of a delay in the announcement, I'm proud to finally unveil the X Developers' Summit 2007. September 10th-12th, at Clare College in wonderful Cambridge, UK (not the one near Boston). We'll be running a sponsorship program too, so X developers, even if you don't think you can make it, just keep those days free.

More information on the wiki page. See you in Cambridge!

Does anyone know how to make gtk-doc actually work with srcdir != builddir builds? The whole 'this is too complicated to work in those situations' premise is a sheer copout, and I'm sure this has annoyed someone else before me enough to come up with a fix. (No, it won't work in absolutely every single situation ever, but c'est la vie.)

At least it's not the worst thing I've encountered today:
typedef struct generic_list_rec
{
    void *next;
}
GenericListRec, *GenericListPtr, *glp;

I'd always had the ludicrously useful Google Search Keys extension installed, but now Google's Beta Search Keys complement this incredibly well (complete with vi mode!). Can't imagine life without the extension, let alone without the new Google one ...

(Via Adam Rosi-Kessel.)

Just a quick note to say a huge thanks to everyone who's offered support (financial, hardware-wise, or just verbal) to the r5xx project -- we really appreciate it. A couple of FAQs:

Thanks! Where can I send money?

Sadly, money isn't the issue: we have jobs/university theses/lives to tend to. We just lack for time right now.

Thanks! Where can I send hardware?

If you have a card that you won't be needing back (we may lose or fry it), please email myself (daniel@fooishbar.org) and Jérôme (j.glisse@gmail.com), detailing what you have, and we'll get back to you if it'll be useful to us.

Will this work with the X2xxx cards (r6xx)?

Yeah, pretty much. It just needs someone to hack up the small amount of code to deal with it.

What's happening with X1650 and above (r530/r580)?

Most of the code is written, however, initialisation doesn't happen correctly for some reason.

What's happening with 3D support?

It should be relatively simple to implement from the existing driver, as the engine is believed to be extremely similar, but we want to get the basics working before we start attacking things like this.

Which tools do you guys use?

For tracing the video BIOS, we use a hacked version of xresprobe: vbetool will instrument the BIOS quite well. For tracing fglrx, we use a hacked version of valgrind: run it against the X server, making sure that it is not suid root. For getting impatient and playing with registers, we use avivotool.

Where does the development happen?

On IRC, #dri-devel seems to serve somewhat as the ATI development centre. This gets fairly well coalesced into The Irregular Radeon Development Companion, however, so you may prefer to just follow that.

Shouldn't all this be on a wiki page somewhere?

Yes, but I have to get up in less than four hours.

Once again, thanks for the support, from all of us. It's been great.

As Jérôme announced, the Avivo driver for newer ATI chips is now available. Unfortunately we've all been very busy, so it's taken literally months longer than we'd hoped. But we have a driver that, while having no acceleration, is able to set modes on VGA, DVI, and laptop panels: all it really lacks is TV out support, and support for the complete set of models. Pretty cool stuff. Any help we can get is appreciated, so if you've done X or driver development, or are interested in same, please get in touch via xorg@lists.freedesktop.org. It's completely FLOSS, licensed under the GPL.

Part of the reason I've been so busy is trying to arrange the X Developers' Summit in Cambridge, UK, around the 10th of September. But more on that later.

The linux.conf.au 2008 Call for PapersPresentations is now open. We're accepting submissions from now until July 20th, 2007; you'll be notified in early September of the paper committee's decision.

Go check out the announcement, and start thinking of cool talk ideas. Once you've got to that stage, be sure to read mbp's How to get a conference abstract accepted, and Mary's Getting a talk into linux.conf.au (not just because she's a co-chair of the paper committee).

This year, we've introduced one optional step: a video submission. If you think that you're a great speaker, and if only we could see you, we'd say yes instantly, then grab a camera, and convince us. :)

Also, if you're interested in running a mini-conf before the main conference, we're also taking proposals for mini-confs.

See you in Melbourne!

It's just not our week, I guess. For the past couple of days, gabe.freedesktop.org (www.fd.o, ns1.fd.o, lists.fd.o) has been playing up: it will just mysteriously die with no explanation. It appears to still be alive, but we can't access it at all. Bringing it back up yields nothing suspicious before it dies, so we're suspecting some bad hardware. This wouldn't be too major a problem, bar the loss of the above-named services and dri.fd.o, openclipart.org, and a few other services, if it weren't for other things conspiring against us.

All revision control services (git/CVS/SVN committing and checkout, web access to same), Bugzilla, xorg.fd.o, people.fd.o and planet.fd.o, are on separate machines which are unaffected by this failure. But, unfortunately, we got less than 24 hours notice that our secondary DNS server at MIT was being moved, and would be offline for a while. Two DNS servers gone. Our third DNS server, hosted in the UK, is still servicing requests just fine, but apparently our registrar never noticed the update. So the third DNS server according to the glue records is home.keithp.com, which is also off the air right now for some reason.

So, ns0.bluelinux.co.uk is still serving names, and you can still access some services if you use that, but we're not sure how long until normal DNS is back up, let alone how long it will take us to get gabe fully fixed.

Sorry for the outage, please bear with us. If you think it's frustrating not being able to check www.fd.o, try checking the remote console and watching /proc/meminfo hopelessly spew into the serial console as you are unable to log in ...

Have been feeling rather unwell for the past couple of days, so I decided, while I feel like death warmed up, how could hacking at Valgrind possibly make it worse?

I took Tilman Sauerbeck's extended version of Dave Airlie's valgrind-mmt, and cleaned up a couple of minor bits -- changed the offset to be specified in hex, added support for repetitions (e.g. 'repeated 255 times', instead of the same line 256 times over), and also added support for the in*/out* family on AMD64, which was quite entertaining as I've not really touched either assembly or Valgrind before. Got it working in the end, despite libVEX's best efforts to frustrate me, and ended up feeling slightly better as well. Huzzah.

Anyway, 'sudo valgrind --tool=mmt --offset=0xc1000000[0] /usr/bin/Xorg :0 -ac > x.log 2>&1' will trap all MMIO accesses made by X or its VBIOS, provided you run the BIOS through x86emu instead of lrmi.

Postscript: spent a few minutes after writing this trying to figure out if there was anything I should've said, and didn't. Now, hours later, I realise there was one minor detail omitted: the URL. gitweb is just there, and the anonymous clone URL is git://people.freedesktop.org/~daniels/valgrind.

[0]: Get the base address with lspci -v. Your video card should have two PCI regions, of which one is big (your main video memory), and the other one is 32 or 64kB (the MMIO space, i.e. the bit you want).

On behalf of the rest of Planet Ubuntu, I'd like to apologise for Stephan Hermann. Most everyone else there isn't half as obnoxious, so please ignore that entry.

Just a quick reminder: if you were planning on going to the X.Org Developers' Conference in the Bay Area, from the 7th-9th of February, then please make sure you've registered on the page. If you weren't planning to come and you work on X or related fields of endeavour (toolkits, desktops, maybe you're an IHV), then you should consider coming along as well. There'll be a mix of scheduled talks, random freestyle hacking, corridor schmoozing, dinners, after-dinner fun, and a whole world more.

If you'd like to come but your pockets don't go quite that deep, please consider applying for sponsorship. The Foundation is willing to pay for travel and accommodation to developers who couldn't otherwise attend.

Hope to see you in sunny(ish) California!

One of the annoying features of reading several planets, is that you end up reading entries from people you otherwise respect, who seem to have various complexes about nonsensical issues. We all saw the month in which half of Debian decided it was cool to rip on Ubuntu, and now apparently it's the new cool thing to do if you work on Fedora.

According to a particularly obnoxious entry, the quality or otherwise of Ubuntu's kernel[0] does 'damage to the free software community'. Now, they've focussed on binary drivers. Which is fair enough: I am personally quite uncomfortable with binary drivers, and extremely unimpressed with Ubuntu's recent move towards binary drivers by default. While I respect the fact that they still encourage users to install free drivers, providing them by default is not a winning move, in my opinion. But I'm not going to discuss this further right now, because if I do, the terrorists win.

The reason the terrorists win, is because some people like to furiously handwave and make strawmen. Apparently now, everyone who's ever touched Ubuntu is rabidly for binary drivers, but the problem here is the handwave from criticism of Fedora's alleged community into yet another ramble about the kernel tree and binary drivers.

I certainly hope the Fedora community is more mature than this, both in general, and in their ability to have a constructive debate about the level of its community involvement. Right now, it is not even disputed that there is effectively none. At first glance, they may appear similar, but if you look further, the similarities vanish. Anyone can come in and get involved in the decision making in Ubuntu, but more important than that, the process is at least completely transparent, so you can see what's going on, on public lists, at every step. Fedora does not have this: decisions magically appear On High from RHEL types. This is not necessarily a bad thing, and does not necessarily result in a lower-quality distribution, but if everyone could just accept this as being true and move on, rather than bitterly baiting a successful community distribution about it, I think everyone would be a lot happier.

The biggest difference is -- yes, basically all the Ubuntu core developers are employed by Canonical. These people were handpicked from the Debian community originally, and now a great deal of them start as Ubuntu community members, and are employed by Canonical because having them work full-time on this stuff would be awesome. The process is still entirely transparent: being employed is a mark of recognition (sorry), and a request to continue working on this even more, rather than a pre-requisite to being able to do anything. Witness Fedora Core vs. Fedora Extras, for example: there are quite a few packages that non-Red Hat employees are prevented from meaningfully contributing to.

So, the summary in a nutshell: binary drivers bad (and Ubuntu moves towards promoting same even worse), Fedora 'community' not at all, handwaves bad, refusal to get involved with a meaningful debate about community governance and structure without engaging in petty mudslinging and pointless handwaves inexcusable.

(Disclaimer: I am not involved with any distributions, nor do I have any professional affiliation with them either. I'm just an irritated observer.)

[0]: I don't claim to have any insider knowledge here; the only point at which its quality or otherwise has become an issue for me lately, is a random hang in gettimeofday() in a corner case recently, which I've been too lazy to isolate and report as a proper bug; I worked around it in the X server anyway.

(Please note, I didn't write this: I just fixed a couple of bugs and put it in a patch. All credit to the original author, Tommie Gannert.)

Tired of the sucktitude of automake command lines? Find it incredible that people could seriously claim to prefer command output so verbose that you actually miss all the warnings?

if /bin/bash ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../../GL/mesa/swrast -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I/home/daniels/x/mesa/Mesa/include -I../X -I../array_cache -I../glapi -I../main -I../math -I../shader -I../shader/slang -I../shader/slang -I../swrast -I../swrast_setup -I../tnl -I.. -I../../../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -DXFree86Server -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I../../../../include -I../../../include -I../../../../Xext -I../../../../composite -I../../../../damageext -I../../../../xfixes -I../../../../Xi -I../../../../mi -I../../../../miext/shadow -I../../../../miext/damage -I../../../../render -I../../../../randr -I../../../../fb -g -O2 -MT s_masking.lo -MD -MP -MF ".deps/s_masking.Tpo" -c -o s_masking.lo s_masking.c; \
then mv -f ".deps/s_masking.Tpo" ".deps/s_masking.Plo"; else rm -f ".deps/s_masking.Tpo"; exit 1; fi
gcc -DHAVE_CONFIG_H -I. -I../../../../GL/mesa/swrast -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I/home/daniels/x/mesa/Mesa/include -I../X -I../array_cache -I../glapi -I../main -I../math -I../shader -I../shader/slang -I../shader/slang -I../swrast -I../swrast_setup -I../tnl -I.. -I../../../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -DXFree86Server -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I../../../../include -I../../../include -I../../../../Xext -I../../../../composite -I../../../../damageext -I../../../../xfixes -I../../../../Xi -I../../../../mi -I../../../../miext/shadow -I../../../../miext/damage -I../../../../render -I../../../../randr -I../../../../fb -g -O2 -MT s_masking.lo -MD -MP -MF .deps/s_masking.Tpo -c s_masking.c -fPIC -DPIC -o .libs/s_masking.o

Prettify Automake finally fixes this. I've put up a deb that at least works on Edgy (but has some pretty shady changes; getting it to build was, um, interesting) here; re-autoreconf with that, then run configure with --enable-pretty-cmds to get much more sensible output:

  [C ] fbbits.c
  [C ] fbblt.c
  [C ] fbbltone.c
../../fb/fbbltone.c: In function "fbBltOne":
../../fb/fbbltone.c:354: warning: left-hand operand of comma expression has no effect
  [C ] fbbstore.c

Warnings! Visible! Amazing!

So, I finally merged the input-hotplug branches on master. Basically, this means that instead of attempting to hide behind one device (/dev/input/mice, the console keyboard), and hacking around it with gash and tape when we actually expose multiple devices[0], we finally expose multiple devices in a useful way. This is consistent through out the Xorg and KDrive servers; Xnest and Xvfb also have support, but that's not the most useful thing ever.

This required a huge overhaul of the old input code, much of which dates back to the mid-80s; the bits that don't were sticky-taped on the side, working more in spite of our core input code than with it. So, in addition to being generally useful and providing things like multiple keymaps on different keyboards and different acceleration (and so) on different pointer devices, it also actually caused a net removal of code.

So, once you've set yourself using evdev for the drivers, you can also now dynamically add and remove devices. Last night, not long before I released all the components, I removed all the input devices from my configuration file, told X not to add any, and added 'respeclaration --daemon' to my session: completely dynamic input. I've been using the core bits (the whole input API rework) for quite a long time, along with Zepheniah's evdev driver, but this is the first time I've been using a session with completely hotplugged input, as opposed to adding and removing devices every now and then to test the hotplug capabilities, which was actually a piece of cake, compared to reworking all our core input code to deal with devices appearing and disappearing.

Still, this all needs good desktop integration. Keyboard and mouse applets need to become aware of multiple devices[1], and allow people to configure them separately. The desktop should also take over the role currently filled by respeclaration, which works perfectly well, but shouldn't be generally deployed; management of input devices thus turns into a session management issue, which leaves the desktop to dictate policy.

There are still some nits in the D-BUS policy to sort out (right now, only root can reconfigure the devices), but I believe it's fundamentally the right model: it's machine-oriented, rather than session-oriented. There are still some minor changes that need to be made, but working out who should be trusted to add input devices was more or less impossible in the X security model.

xserver 1.3 (for Xorg 7.3) should be good fun.

[0]: Key presses/releases from your second device will just magically appear from your first device. Useful, huh?
[1]: In brief: check for inputproto 1.4 at build time, check DEVICE_CORE on whatever appears as the core pointer, and if 'iscore' is 1, then you have a virtual core pointer. Anything that sets status to 1 for DEVICE_CORE will also generate core events. Setting controls on the core keyboard or pointer will propagate those changes down to all the devices which also send core events. I'm going to document this soon.

No thanks. Especially when distributing kernel images without the corresponding source is surely against this whole GPL thing. Great example to set to vendors: 'I'd give you the source to our kernel modifications to get Linux up and running on this wireless router, but it'll cost you'.

Credit where credit's due:

Hello Daniel,

Thank you for writing in. My personal apologies for what happened, this is
not allowed behavior here at Google and this email was mistakenly sent to
you. Mistakes happen but we're sorry that this particular mistake
happened, unsolicited email is not acceptable. If you have any further
questions, please do not hesitate to email us.

Sincerely,

Sam

The Google Base Team

If this means that Google are stopping Google Base spam completely now, more power to them.

We found this e-mail address from the public Google search results.

Can someone please explain to me how spamming public lists is somehow compatible with Google's stated 'don't be evil' ethos? freedesktop@l.fd.o wasn't the only list to get hit. Very disconcerting.

So, dear Google,
What gives?
Daniel

Update: Yes, I checked the headers, it's definitely Google:
Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.12])
by gabe.freedesktop.org (Postfix) with ESMTP id 8EA189E72E
for <freedesktop@freedesktop.org>; Mon, 14 Aug 2006 16:53:29 -0700 (PDT)

Update #2: No, it wasn't a joe-job. And hopefully that'll be the last one they send.

Daniel, if you can somehow build a card that's at r2xx level (note the current state of the art is r5xx), not to mention be register-compatible, you are nothing short of a genius, and ATI and NVIDIA will be begging you to let them pay you a number of your choice.

It's not going to happen anytime soon. They're not worried about that.

Luis, If you can still find the ThinkPad T43 around, it would seem to be a perfect fit for your needs. It's 1400x1050, has an ATI X300 SE in it (supported by Free drivers, including DRI), and the wireless is Centrino, which only has the firmware problem. The only thing wrong with it is that it's a behemoth both in size and weight compared to my dainty little X40, but I guess that's what you wanted if you were asking for T series recommendations.

While I'm here, you all get a bonus picture of the moon over the Baltic:


If you zoom in, you can see that it's roughly four picodegrees over the sea. Brilliant.

Since all the cool kids are doing it, here are some of the more interesting stats from the Google analysis tools. The third most popular search term used to hit my site has been 'jdub' of late, which is a bit worrying. Number five is 'scandinavian window systems' (?), number fifteen is 'abortions', number seventeen is 'word up for hilltop hoods' (okay, I share the sentiment, but will Googling for it really be that useful?), and number eighteen is 'bluetooth beatbox', which really defies explanation beyond being a googlewhack, but it's not even that.

The mind boggles. At least it's not quite as odd as when I maintained a very large, Google-indexed, IRC quotes file.

So, thanks to the effort of our fearless team, new Xorg hotness is available, and even brings those blue sparks. You might note that this is a mere five months after X11R7.0, and note the 7.2 release plans, which have us releasing X11R7.2 in a mere six months. We're back. Oh yes, we are back.

xf86Init.c in OpenBSD:
Fri Mar 10 17:29:51 2006 UTC (7 weeks, 5 days ago) by deraadt
proper geteuid calls because suse hires people who mistype things

I don't know what went wrong in Theo's life to make him such a whiny, raving sociopath, but I, for one, have had about enough with the sort of behaviour I wouldn't accept from my seven-year old sister, let alone someone who's allegedly old enough to know better. Grow up, Theo.

Everyone on #xorg-devel has seen me harassing people about our current stats with bugs. If anyone with knowledge of the X codebase felt like coming in and doing a bunch of really painful, unrewarding, triage work, it'd be massively appreciated. That NEW line should really continue plummeting down! On that note, I'd like to publicly big up Erik Andren in particular, for doing a ton of awesome triage work so far to help us get that graph down, and help beat our Bugzilla into something usable that helps us, rather than its current awfulness.

Joe muses about Xlib and connection aborts. Two things:

Yes, libX11 is going away. It's unfixably broken (not only is the implementation utterly horrendous, but the concept is exactly what toolkits don't want), and we can't change existing behaviours because libX11 is just one of those API/ABIs you cannot break.

Yes, the ability to recover from connection aborts is essential. D-BUS is broken in the exact same way, yet some people feel inclined to defend it (e.g. mandating reboots when either of the D-BUS daemon, or libdbus, are upgraded; advocating segfaults in client applications when the bus dies as the right thing to do?!?). I don't think either behaviour is in the least bit sensible, and it would be really keen if both could be fixed (by using XCB in toolkits for the former, by fixing libdbus to be less obnoxious for the latter).

RFCs are hard, let's go shopping. You'd hope that people writing allegedly sensible mail clients would have slightly more respect for RFCs, but it appears not ...