The saga of restoring rpmfind services goes on, of course a couple of hours after I wrote about rpmfind.net being back in shape one of the drives died, apparently it makes a cyclic click audible though a closed door :-\ , it was hosting the packages pages of course, Murthy in action. I will swap a new drive in probably today. In the meantime the speakeasy people contacted me, they built a new box, first surprize is that it's an Opteron box :-) , they initially installed the x86 RHEL version which was working surizingly well, but they reinstalled with the AMD64 version, I don't know for desktop work but for servers x86_64 rocks. Rebuilding the services takes a while still, even at 2MBytes/s it takes an awful long time to resynch hundreds of gigabytes of mirrored stuff.
Struggling quite a bit with some bizarre behaviour I want to fix before pushing it as the replacement for fam in Fedora Core. At least it builds, but debugging threaded stuff is a pain, I absolutely need to remove the threading. I also think I will not enable Suspend/Resume operations that FAM provides, they mean the server has to stack operations if the client asks for them and this really doesn't sound like a proper client/server model for operations. Beside that I doubt it's used anywhere on the desktop, well pushing it for test2 of Fedora Core 3 should help find if it's too strict or not.
GCC aliasing and runtime profiling
Seems other people are interested at shaving their code size by 5-10% following the work done with Arjan on gcc aliasing for library symbols and using gcc runtime profiling. fcrozat also activated it on the Cooker build and gained 7% on size apparently. Seems gtk and some parts of OpenOffice are also potential candidates for those optimizations.
libxml2 and libxslt
Despite the number of changes made in the last release they seems stable, ncm might a bit optimistic (or ironic ;-) to call them "stellar". William and Kasimier chased down a problem in Schemas debugging showing up only in 64bits. William had the machine with 64bits and Kasimier had the knowledge of the code. This resulted in a long IRC session of cut and past gdb and discussion. I think a GDB <-> IRC connector would rock, just so often people manage to get into a problem, but reproducing it outside of their environment is nearly impossible (code/data/platform issues are not always shareable), If we had a standalone python (or perl :-\) script which could create a gdb (or other DB) session and gate it as a user on a public IRC channel, there is tons of obscure bugs that could be debugged in a matter of minutes instead of standing unreproduced in a bugzilla entry. Googling a bit for this I could not find any such tool, it should not be too hard too do, but IMHO would be extremely valuable.