Older blog entries for johnsonm (starting at number 7)

Hmm. I appear to have forgotten to write a diary entry yesterday. I walked into the test lab and got shanghaied into a project without even going to my desk, and then the project absorbed time imperceptibly, and I accidentally stood a friend up for lunch. Oops! :-(

Today will be a catch-up day. I've got a bunch of things that I have promised to write for people, so it's time to sit down and get to work.

Co-loc got their act together (turns out there was a routing problem that was masked by the IP problem) and the errata was pushed and announced. Now we just wait for the mailing lists to churn through.

Did a few updates to the current development version of the kernel package.

I'm investigating digital photo printing services such as ofoto, shutterfly, and photoaccess. A bunch of these services try to convince you to install their proprietary software to upload your pictures; one of them wants to replace your camera communications software with their proprietary package which "with one click" uploads your picture to them to print. They also post-process your image based on the camera you have in order to get better color, but they make no mention of white balance settings; my camera (at least) has several different white balance settings, including the default automatic correction. I wonder how this service tries to compensate for automatic white balance? I could send them one of my pictures that looks really washed out and which I can't seem to correct in the gimp, and see what they make of it... But in general, I'm rather leary of "don't worry, we magically correct everything for you" services.

Today was, I hope, the last firefighting day for at least a short while. We finished the last QA cycle on the new kernel and are pushing it out to the ftp sites. The fact that our co-loc accidentally assigned one of our ftp servers' IPs to someone else's machine as well (oops!) has slowed that process down a little (grrrrr!), but I expect that to get cleared up shortly.

In odd moments during the day when I don't find myself actively fighting fires (i.e. while I wait for the build servers to finish compiling or for packages to push out to the world) I'm making sense of the kernel team's area in the test lab. This involves building racks (real racks and bread racks) and re-wiring the whole mess. No matter how neat the wiring was in the first place, moving machines in and out adds entropy to the system, and pretty soon you have no idea which machine is connected to which port of the KVM switch, and tracing network and power cables becomes a puzzle. As much as I enjoy puzzles and untangling cords, I'm ready to put this in good order.

Wow, it has been a long time since I wrote one of these. That's because I was working on IA-64 (Merced, Itanium, whatever) and wasn't sure what Intel's NDA allowed me to say about what I was doing. Fortunately, that's all changed. I did have fun doing the IA-64 work; the process was (as one might expect) similar to what I experienced when I bootstrapped early Linux versions (0.03, 0.10, etc.) on the x86 platform.

I then disappeared off to The Netherlands for nearly two months while my wife attended a short school in symbolic dynamics (her area of mathematical expertise), and I worked remotely on ACPI again. I discovered what it is like to have a metered internet connection, and came to value the U.S.'s flat rate local calling areas. While I was there, I kept a rather detailed diary of my work and play. This includes a few photos; I have hopes that some time I'll have time to go through and add more photos from my collection.

I've discovered that I have fairly naturally slipped into the role of an interface person between the kernel hackers and the user-space folks here at Red Hat. Sometimes I answer questions myself, and sometimes I play traffic cop and direct people towards the right other people to answer their questions. One of my strengths is knowing the difference between questions I can answer and questions I can't answer... I also tend to be the one asked to find slack to do one-time tasks that desperately need to be done. That suits me.

As my other tasks allow, I am still working on ACPI. There are some interesting problems here, many of which involve internal politics within the companies that own the ACPI "standard". ACPI is incredibly broken; if there were any other option I would be campaigning to throw ACPI away. I could write (indeed, have written) screeds explaining how broken ACPI is. However, the two important things that keep me going are that there is no realistic hope of replacing it, and that it is better than the alternative in the power management space (APM).

Spent the last several days on a concentrated bug squash session which will probably continue at least through this (short holiday) week.

Most the effort involves separating the wheat from the chaff. There are a few great bug reports, many reports that require a lot of work to pin down what the user thinks the bug is, and plenty of requests for free technical support... :-)

Returned from trip to CA on a redeye. I won't be very productive today...

John Harper kindly wrote rep-gtk/sawmill patches to build without my grotty Xvfb hack.

Tracked down a system hang with ACPI on an Acer notebook (not specific to Acer, it appears to be a kernel bug, may be a mismatch between kernel and possibly buggy ACPI implementation). Discovered that some machines that offer a soft S5 (soft off) state don't appear to actually implement it. sigh.

Found a bug in aboot. msw tracked it down to aboot not knowing about changes to the ext2 filesystem. Helped fix it.

Made sawmill build on machines without X running by embedding Xvfb in the spec file. Had to search for available X displays carefully to avoid a race condition.

Found an inf^Hternal compiler error in egcs-1.1.2 on the Alpha while building librep. Life sucks sometimes.

Mucking about with ACPI these past few days, fixing a few bugs, finding more than I fix so far, but made it possible to find the ACPI tables on some large memory ACPI machines. All ACPI machines I have worked with so far appear to have mangled ACPI implementations.