FOSSwire

That’s a scary headline. Chances are, after seeing that, you might not care about the rest of this article. But hang on for a second: Have an Intel graphics chipset, or use an ATI graphics card (open-source drivers or not)? Then this image might be familiar to you:

If you don’t notice it right away, the glxgears window is below the other two. Ugly. This is a problem with the current X.Org stack using a rendering mode known as DRI1. I won’t go in to technical details of why this happens, but it all boils down to this: Using DRI1, 3D applications are given a space of the screen to draw into, and this is then sent directly to the display. That sounds somewhat logical, but when you throw in more fancy operations, such as Compiz and desktop effects, things get tricky. Keith Packard of Intel does a good job explaining this and other problems with X acceleration.

Keith mentions a golden combination that can be used right now. Fedora 11, arriving in one week, will include everything needed for a pleasant X experience. Ubuntu 9.04 does ship UXA, but it is not on by default due to stability issues at the time it was released. Instead, EXA is used, the same mode included with 8.10.

If you’re using Ubuntu 9.04 or another distribution with UXA support that is almost ready, there is a one-liner you can add to /etc/X11/xorg.conf. In the Device section, add Option “AccelMethod” “uxa” as it is below:

Section "Device"
	Identifier	"Configured Video Device"
	Option	"AccelMethod"	"uxa"
EndSection

Be prepared to revert the change later: without a newer kernel or X server, UXA mode has proven to be a little crashy. I’ve had good experiences while using at a 2.6.30 kernel, though I still do not use it for day-to-day computing. Even if you can’t get it to work for extended amounts of time yet, it still is nice to see this:

The glxgears test is positioned neatly in the background; you can see it through the semi-transparent terminal. And if that’s not enough proof that this works:

Applications can create a lot of temporary files sometimes, and these files aren't always cleaned up automatically.

An example of this is when you run Python applications. Particularly if you're a Python developer, your source code directories stack up with a .pyc version of each file, which is the cached compiled copy of the script.

To clean up (especially if you're going to do a source commit or an upload somewhere to extend that example) files of a certain file extension, you can use this command line snippet:

$ find . -name "*.ext" -exec rm '{}' ';'

Obviously, replace *.ext with the pattern that you want to delete.

I shouldn't need to say this, but use this with caution. Make sure you're not accidentally going to delete something useful that matches the pattern you enter, and always keep backups yada yada. Tread carefully when batch deleting.

A very quick command line tip today, for users of pretty much any Unix-based operating system, including Linux distributions.

When you're looking up information on a certain web site or domain name, you might be used to using whois functions on websites such as DNS Tools to see who owns a domain.

However, in most cases there is a much quicker way to get the same information, which is through your command line.

As you might guess, it's simply:

$ whois domain.com

If you also want to hide the legal information that gets returned on a whois request, for brevity, you can easily do so with:

$ whois -H domain.com

This often won't catch it all and give you purely the results, but it usually helps reduce the level of output.