Just spotted a new story on my Google Gentoo feed: “Qlusters unveils open-source systems management.” They open-sourced a formerly proprietary tool for managing hundreds of Linux servers (it also supports Windows to some extent) and called it OpenQRM. Sounds intriguing, with possible repercussions in the clustering world outside datacenters as well. They say they’re looking into support for Debian and Gentoo, so let them hear your voices. Check it out.

Could be … I’m excited about the possibility too.

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.

I just bought this book. The author, Phillip Ezolt, gives a really great introduction to all the ways your programs could be limited (CPU, I/O, memory, network), then discusses a number of tools for diagnosing and solving these problems for both individual applications and system-wide changes. He actually describes which parts of these tools are useful, doesn’t just copy and paste the man pages as so many books do.

After that, he walks readers through three examples of identifying and solving different problems with GIMP, Nautilus and prelink. This, for me, was one of the most useful parts. The tools Ezolt uses include oprofile, valgrind, vmstat, gdb, iptraf, sar and many more. If you want to improve the performance of any program, I highly recommend this book.

Before I bought it, I already had read it once while sitting in Borders. It was so good, I bought it despite having already read it.

Last night, ferringb mentioned to me that he wanted to pull a bash backtrace function from eselect into portage. So I took a look at it, and it seemed like a great idea. But it was missing one thing that could be really helpful: It didn’t show the arguments to functions.

Here’s a sample of the original output:

You’ll notice that not only does it lack arguments, but it says bleb() is in the wrong file, and it tries to attribute the original failure to main(). This doesn’t make a lot of sense, so we change both the sourcefile array, $(basename ${BASH_SOURCE[${n}]}), and the function name array, funcname=${FUNCNAME[${n} – 1]}, by 1. Here’s the enhanced output:

Here’s the chunk that does most of the heavy lifting:

This code is part of a loop printing the most recent function first. We initialize p to 0 at the beginning of looping through the call stack, then increment it by the size of the argc to that function on each pass through the loop: ${BASH_ARGC[$n – 1]. This is necessary because bash only has one-dimensional arrays. Thus, BASH_ARGC[] contains the argc values for every function in the call stack, but BASH_ARGV[] contains a concatenated list of every single argument without clear separators between functions.

If we wanted the most recent function last, we’d have to change things around a little:

In particular, note how j starts at 0 instead of the last argc, and how newarg is set in a very different way. We need to treat p differently when going in reverse order (it’s initialized to ${#BASH_ARGV[@]}, the size of the argv array), which necessitates the changed treatment of the rest.

We enclose the whole loop in a test for the existence of BASH_ARGV for backwards compatibility with bash-2: BASH_ARGV and BASH_ARGC weren’t incorporated into bash until 3.0. Another caveat is that neither of the arrays are set without the extdebug setting near the top of your code:

Thanks to ferringb for way too much discussion about how the output format should look and for making us put the effort into figuring out how to switch the ordering around for compatible output with Python tracebacks from portage.

For completeness, here’s the beginning of the loop in both cases, respectively:

The complete code is available for both versions.

I use Liferea for blog reading. It’s a nice app, but it has some trouble detecting when I get the same post from multiple feeds. Really, Liferea, I don’t need to read it more than once; just mark it read and let me get on with it.

Anyway, I started using Liferea because it lets me create categories for my priorities of different feeds. I’ve got 3 priority levels of personal blogs, plus another one for newspapers and magazines. I rarely get to the third level, and never the newpapers/mags level. Every once in a while, I browse the third level, and if I find anything good, I exchange it for something in level 2 that I haven’t been getting much out of.

This week, I’ve moved Stephe Walli back up to #2, and Ted Leung dropped to #3. Ted has interesting things to say, but not really on topics I care about right now. Bye, Ted, see you in a couple months. Keep up the good work on Chandler.

A quick summary of my categories, for anyone who wants to see what I see:

Priority 1
Jay Cotton, Kazem Ardekanian, Pat Mochel, LWN.net, Gentoo Universe, Gentoo X team commits, Corvallis free Wi-Fi, Planet Freedesktop.org, and a Google search for Gentoo.

Priority 2
r0ml, Stephen O’Grady, a Google search for links to my blog, Paul Graham, Stephe Walli, Passionate Users, O’Reilly Radar, Planets: KDE, GNOME, OSLUG, another private one.

Priority 3
Bram Cohen, Ted Leung, Jon Udell, Joel on Software, Don Marti, Doc Searls, Planets: Ubuntu, Fedora, Debian, Novell/SuSE, Kernel, Cheap Stingy Bastard, Woot.

I spent a significant chunk of time today on scripts to track down all the packages that still aren’t ported to modular X and identify their maintainers. Read more from the gentoo-dev list.

Over the next week, I plan to track the total number of unported packages in hopes of seeing a gradual decline. Once that decline gets low enough, I’ll unmask modular X so the testing (~arch) folks can get at it more easily. It’ll still require the migration guide, though.

If you want to join the effort to get the tree ported to modular X, take a look at my latest list of unported packages on the gentoo-dev thread linked earlier, read the porting guide and jump in!

Unported packages as of Jan 16, 2006 17:45:56 PST: 1058
Unported packages as of Jan 18, 2006 01:18:30 PST: 1037
Unported packages as of Jan 19, 2006 00:18:21 PST: 1012
Unported packages as of Jan 20, 2006 00:04:03 PST: 1003
Unported packages as of Jan 21, 2006 13:27:22 PST: 917
Unported packages as of Jan 22, 2006 22:05:42 PST: 871
Unported packages as of Jan 23, 2006 23:07:22 PST: 867
Unported packages as of Jan 24, 2006 23:02:28 PST: 783
Unported packages as of Jan 24, 2006 23:02:28 PST: 513 “true”
Unported packages as of Jan 25, 2006 21:32:30 PST: 498
Unported packages as of Jan 28, 2006 13:34:04 PST: 465
Unported packages as of Jan 29, 2006 23:23:02 PST: 401
Unported packages as of Jan 30, 2006 23:37:30 PST: 406
Unported packages as of Feb 02, 2006 12:33:49 PST: 343
Unported packages as of Feb 03, 2006 20:43:54 PST: 329
Unported packages as of Feb 12, 2006 11:18:44 PST: 260

Too bad I didn’t come across this survey a few years ago … As it turns out, I majored in biochemistry and chemistry with a minor in journalism.