OK, I have determined what blogs are for. They give an easy way to publish aggregated technical fix information in a search-engine-friendly format. Aggregated: quite often, fixing a specific technical problem (even a common one!) requires looking around the web at a number of false leads on mailing list archives, tech docs, knowledge bases, etc. Putting the whole solution, once found, into a single blog entry (including links / attribution to the original solvers) makes sense. Seach-engine-friendly: mailing list archives are good, but only if they get web-published and Googled. Realistically, if it's not in Google, it doesn't exist — especially in the realm of technical problems that could have any number of origins (imagine compiling an XML to Excel Perl module on Mac OS X: is your problem with GCC, libxml, Excel, Perl, or Mac OS X? Which mailing lists do you search first?). Additionally, most computer problems have a characteristic error message which appears with some limited amount of variation. That message is easy to post on a blog. I originally believed that the solution to the aggregated technical fix information was a search-engine feeder backed by an RDBMS, but it is clear that any schema will be too inflexible for the variety of problems. Better to post error messages verbatim, try to be as explicit about keywords as practicable (if it segfaults, include the words “crash', “segmentation fault”, and “segfault” as an aid to searching), and let Google handle the hard stuff far better than a FTS through an RDBMS could hope. Why do this? Well, this is a case of the comedy of the commons: figuring out a solution like this on one's own or by searching through mailing lists piecemeal could consume hours or days of productive time. However, posting a solution once found is trivial, taking mere minutes. If even one other person posts a solution that I find which saves me 3-4 hours, it's worth all the time I'll ever spend in posting such things.