Take a look at these screenshots for how you’ll be able to configure X.Org 7.0. Normally you would set VIDEO_CARDS and INPUT_DEVICES in /etc/make.conf. I’m just showing them on the command line to illustrate the configurability and power you’ll get.

Use case 1: You’ve got a keyboard, a mouse, and either one or a couple of video cards, and you hate bloat. You’re a developer, so you want to compile all your X stuff with debugging support.

Use case 2: You use the binary ATi drivers, because you really want to play the latest games (Quake 4 and Doom 3) and no released r300 driver can handle them. You want to try the new evdev driver, a replacement for keyboard and mouse drivers that uses the Linux event interface. You still hate bloat, of course. You want your system to be lightning-fast and optimized.

Use case 3: You want things to just work, and you don’t want to know what sort of video card your computer has. What’s a video card, anyway? You just use X.Org’s autodetection. You do know that you have a keyboard and a mouse though, so you set those up.

Now, I’ll explain the output a little bit. Just before the package name, there’s something like this:
[ebuild N ]

The “N” means it’s a package we haven’t installed before. If it were a “U,” we’d be upgrading. “R” means reinstallation of the same version. The “ebuild” part means we’re compiling from source, not using a binary package.

Take a look at all the USE, INPUT_DEVICES and VIDEO_CARDS flags after the package names. The yellow flags and % symbols mean they’re something new that wasn’t around last time you installed that package. So synaptics, fglrx and nvidia are new options. The green flags with a * after them indicated something you’ve changed yourself since last time you installed the package. The red indicates an active flag — support will be built for it. The blue flag with a minus sign indicates an inactive flag — support won’t be built for that option.

Polvi kindly posted the results of where our $100 quarterly technology fee goes.

Things I’m excited about:

1) Wireless in ALS, where I spend all day working. Seems like wireless coverage in academic buildings was a major focus this year; I saw a number of buildings funded.

2) High-performance graphics lab in Batcheller 214. According to the summary, it’s designed to draw students from Science and Liberal Arts, not just the College of Engineering, which proposed it. It might be fun to see whether we can use this for any of our molecular graphics visualization. With any luck, there will be some way to run Linux in there, since some other COE labs run Linux (or at least Unix).

3) Physics department got $50,000 to buy Linux-based PCs to replace old Sun Blades and recycled HP workstations

Things I’m depressed about:

1) Geoscience department spending almost $50,000 for a Windows-based server farm for remote access to GIS etc for online courses.

2) Absolutely nothing on the list for the Biochemistry department; closest thing was a student server for Cosine, which provides IT for the whole College of Science

A couple of people brought up this patch recently, which changes the default X white-and-black crosshatch startup to a flat black. Gentoo picked up this patch from Red Hat’s Mike Harris before I was a developer, back in early 2003. It appears that SuSE, Mandriva, Arch Linux and Specifix have also picked it, or some variant of it, up. SuSE has one more similar to ours, according to its spec file — appending the ‘-br’ argument to Xservers. Debian and Ubuntu appear to lack the patch. Mandriva’s solution is interesting — they patch it to “Mandrakelinux blue”. This discriminates between working and broken servers, but keeps some of the other downsides.

Some reasons it’s bad:
1) Some people actually like that crosshatch pattern and use it as their desktop.
2) It can indicate problems in the drivers or monitor used; many are incapable of displaying it, whether CRT or LCD.
3) Some LCDs fail to center the screen correctly if using the black background.
4) It’s difficult to tell the difference between some long delay on the flat black screen and an actual lock-up of X.
5) It’s yet another divergence from upstream, which means more work to maintain.

Some reasons it’s good:
1) It maintains the consistency of bootup by not inserting that random “image” for some small period of time, allowing people to have the same image for GRUB, framebuffer bootup and *dm login.
2) Some people think it’s ugly.

Jim Gettys mentions the original reason why it’s the default, but monitors with bit depth greater than 1 superceded that reason.

I’ve been reconsidering whether it’s a good thing to be black by default, so I’d enjoy a discussion on the best way to proceed.