On the usefulness of advice.

A few of the points stressed by sites that peddle advice on finding a job include things like "never send a resume without a cover letter" and "avoid the one-liner cover letter that says 'please consider my application for this position'".

Oddly enough, of the three employers that have actually responded to my applications, I didn't send any cover letter at all to one, and I sent the Forbidden One-Liner to another. Nearly every application that I've slaved over to produce a well-written cover letter (going by the common wisdom I get from just about everyone) has apparently gone straight to /dev/null. I'm beginning to think I should just quit wasting my time on these things and aim for quantity rather than quality.

Announce: leafsmtp

I recently redid my whole mail setup to use mutt and modular programs for sending/receiving mail. Since I've generally found a full-fledged MTA to be overkill and an unnecessary pain to configure for a personal system, I tried out a "simple" SMTP relayer called esmtp. It was OK (aside from my configuration confusion), but it has a few small deficiencies, esp. the fact that it doesn't manage a queue, thus forcing all deliveries to run in the foreground. Having determined that Python modules exist to run the client (and, in fact, the server) end of an SMTP session, I decided that it can't be that hard to write my own implementation of these programs with just a bit more oomph.

Happily, I turned out to be right. After three days of hacking, I now have a fully-functional...or at least functional enough to relay my email around...email system in a mere 736 lines of Python. It can put messages into an on-disk queue directory (~/MailQueue by default); the benefit here is that it makes it totally safe to background the delivery process, which is nice if you happen to have a slow SMTP server or (when using it as a delivery backend for getmail/fetchmail) run a lot of time-consuming spam checks. Without sticking the mail on the disk while it's being delivered, there is a chance that you'll lose mail if the delivery fails, especially if the delivery process has forked into the background. And unlike complete MTAs such as exim, this all works without needing anything to run as root (unless you want to deliver to the mail spools of other users).

There is no Debian package. In fact, there isn't a proper source package, but you can pull down the upstream repository with

darcs get http://people.debian.org/~dburrows/darcs/leafsmtp

You'll have to either pass the --set-scripts-executable parameter to darcs, or run "chmod +x" on the leafsmtp executable once it downloads. There's only a little documentation, but hopefully it's enough to get you going.


Oh, and the name: it is, of course, indicative of the fact that this is meant to be a reasonable mail system for leaf nodes on the Internet. It's a little inaccurate, since a leaf node could receive mail directly, but it sounds a lot nicer than most of the other things I thought of :-).

More lines-of-code nonsense

After my last post about lines of code in aptitude, I was wondering how the program has grown over time. Plus, someone pointed out that I ought to be using sloccount to get a more accurate picture, since it ignores blank lines and comments. So, with a bit of hacking around to extract information about past aptitude versions, I present the aptitude-over-time graph:



The "zigs" in this graph represent overlapping development cycles of the program. It's interesting to note that about 1/3 of the source lines in 0.3.4 are ignored by sloccount because they contain only comments or whitespace.

A PostScript version and the raw data are also available (the last column is the supposed number of person-years it would take to produce the program according to a formula which, in the words of an IRC denizen, "is useful to convince your boss you need a pay raise").

P-E-B-C-A-K

If you want to set up your email so that you send it using esmtp and mutt, be sure to put "set use_envelope_from=yes" in your mutt configuration, or dreadful things will happen and your mail will end up in the ether between the worlds. Really.

Actually, I wonder how many of my problems with using "real" mail transport agents and mutt would have been avoided had I known about the existence of this simple option. Oh well, live and learn.

A cry from the bitbucket

Well, I've pretty much come to the conclusion that I cannot send mail to many important @debian.org addresses. I know my mail is working because I can email myself (including @debian.org), and mail I've sent to anywhere except @debian.org works. However, since a few days ago, all my mails to bugs.debian.org, whether bug submissions or additional information on bug reports, just vanish (other people's mails are going through, so the system isn't broken); repeated (GPG-signed) requests to changes@db.debian.org to update my SSH keys have gone unanswered and un-acted-upon; and several mails to the lists have vanished into the ether. I've emailed a few role addresses about the issue, but I wouldn't be surprised if those emails get dropped on the floor as well.

Since it appears this is about the only way I can contact Debian people, could someone with admin access to our mail system please tell me why I'm shut out? This started when I changed how I send mail, so it's possible I misconfigured something (although I'm just forwarding through my smarthost using ESMTP), but I need to know what it is in order to fix it!

aptitude goes distributed

As I've hinted at in a few recent emails to the BTS, I've moved the HEAD of aptitude development to the distributed revision control system darcs. In my case, the draw is not so much being able to coordinate a large developer pool; the main advantages of darcs are that (a) it has sane branching and merging (as opposed to, say, SVN), and (b) I get disconnected operation for free (highly useful when your main development machine is a laptop).

Oh, and distributed revision control is New And Shiny[tm]. That too.

The new repository can be fetched with the following command:

darcs get http://people.debian.org/~dburrows/darcs/aptitude

Once you've checked out the source, you can use it the same way you'd use the Subversion source tree. To merge any new patches from my public tree into your local tree, run:

darcs pull

Now, the fun thing about darcs is that the checkout you just made is also a perfectly fine repository. So, for instance, if you make some changes, you can run

darcs record

in your copy of the repository. When you finish answering the prompts, your repository will now have an extra patch committed. You can now push it to other repositories, let other people pull it (if your repository is public), or email it using

darcs send

If you have a working sendmail setup, this will use it to send me a patch. If not, you can either pass --sendmail-command to "send", or use

darcs whatsnew

to see what you've changed.

The Operation Was A Success (and the patient lived!)

Well, I've done it. I took a laptop apart, reassembled it, and not only did I live to tell the tale but (more importantly) so did the laptop! Even better, as soon as I turned it on, I could tell that the fans were working far more effectively -- the noise level is so much lower it's ridiculous. I haven't run any games....umm, I mean tests yet to see if the performance is better, but I'd be happy even if I could just cut down on the noise pollution around here.

The only slightly worrying thing is that I have one more screw than I did before I started all this madness. However, the laptop appears to be not falling apart. Hence, I conclude that the screw can't be that important ;-). (and certainly not worth tearing the whole thing apart to replace!)

Hopefully this will last for at least a few months -- by a few months after I first bought this, I was already noticing severe performance problems that in retrospect were the first onset of the dust-clogging-the-fans issue. Maybe if I keep the environment more dust-free (i.e., clean and vacuum more regularly) I can delay a recurrence, though.

I'd like to thank everyone who emailed me with stuff to try or handed out helpful advice on IRC. It was immensely helpful to be able to pick the brains of people who are a bit more conversant with hardware hacking than I am.

Did I just do that?

So, back around the beginning of August, I decided that since I was temporarily (hopefully :) ) unemployed anyway and I wasn't in immediate financial peril, I'd spend some weeks working on aptitude full-time, so I could shift some of the ideas in the "things I'd like to do but that take too much effort" pile into the "things I've done" pile. I had already done a bit of work right around graduation, and another good chunk in June. But I didn't expect what I just discovered when I went to bring my resume up to date.

daniel@sleepingbeauty:~/stuff/txt$ darcs whatsnew
{
hunk ./resume.tex 42
-  47,000 lines of C++ code and 9000 lines of DocBook XML
-  documentation)\footnote{Statistics refer to version 0.3.2, released
-    May 1 2005.}.
+  70,000 lines of C++ code and 10,000 lines of DocBook XML
+  documentation)\footnote{Statistics refer to version 0.3.4, released
+    September 30 2005.}.
hunk ./resume.txt 26
-   47,000 lines of C++ code and 9,000 lines of DocBook XML
-   documentation -- statistics taken from version 0.3.2).
+   70,000 lines of C++ code and 10,000 lines of DocBook XML
+   documentation -- statistics taken from version 0.3.4).
}

Now, a certain amount of that was adding GPL copyright boilerplate to files that lacked it. A lot of files already had it, but still at 20 lines per file for 282 files, that comes to about 5,000 lines. Some more can be credited to whitespace and ritualistic C++ syntax that was introduced when I broke some of the more horrible and grotty pieces of source into bite-sized pieces. Still, that's a lot of lines of bloa^H^H^H^Hcode.

[UPDATE] and I apparently hit "publish" instead of "save as draft". Whoops! Enjoy, world :-)

Give me a lever of 6" length and a place to sit...

Well, I finally got the CPU off the heatsink. The solvent didn't do it (it might have helped, but it wasn't critical); neither did freezing the CPU or heating it or even just Yanking Really Hard. I finally managed to separate the two things by wedging the tip of a screwdriver under the CPU and gently applying pressure until it separated from the cooling apparatus.

Queued up for tomorrow: get the right thermal material (the stuff I have is very prominently labelled "not for attaching CPUs to heatsinks"...whoops) and put the laptop back together. I halfway expect that it'll fail to boot once it's reassembled, after what I've put the poor thing through, but nothing ventured nothing gained.

I Hate Hardware

About a year and a half ago, I bought a laptop. While it isn't the greatest computer ever, it has generally served my needs. However, I've been having more and more trouble with it lately. The first sign of serious trouble was when the computer shut itself down while I was playing bzflag, leaving a message in the system log about the temperature exceeding 90 degrees Celcius. After that, I of course took precautions to ensure that it was well-ventilated, even to the point of buying a special laptop cooling device (basically an elevated stand with two enormous fans mounted in the bottom). However, the condition of the system has continued to deteriorate. I felt pretty confident that I knew the cause -- dust buildup in the ventilation system, and so yesterday I pulled out a set of screwdrivers and set out to clean every last dust bunny out of the system. Sure, I said to myself, I've never opened a laptop before, but I've assembled a desktop, so I'm totally qualified!

Ha.

My laptop is currently in pieces all over the floor of the apartment. Taking it apart wasn't too bad, aside from the fact that you have to remove about 20 tiny screws, most of them totally inaccessible. Even getting the CPU out wasn't too bad, and when I did I found (as predicted) a huge wad of dust wedged between the heatsink and the fan.

But here's the fun part: there is no way to reattach the CPU to the motherboard! The problem is that the fan/heatsink assembly on this thing is huge -- it covers almost a quarter of the area of the case. To reassemble everything, I need to open the socket, insert the CPU, and close the socket again -- however, if I insert the CPU while it's attached to the assembly, it blocks access to the socket's open/close control. So it appears that the only way to put the CPU back onto the motherboard is to remove it from the heatsink, stick it into the slot, and then reattach the heatsink.

And (joy) I can't get the heatsink off the CPU or out of the fan assembly; they all seem to be practically welded together. When pulling didn't work, I headed to Fry's and bought some nasty-smelling solvent that's supposed to dissolve the thermal adhesive holding the CPU to the motherboard. All it did was give me about a half hour of ventilating the area while I waited for the lightheadedness to wear off. I'm currently seeing what happens if I leave the whole mess in the freezer for a while; several people have told me that might work (presumably because the various components shrink away from each other as they cool).

Once I get the CPU back in, all I have to do is reapply thermal adhesive, attach the heatsink+fan assembly to it, then find all 30 or so screws I took out and figure out where each one goes. At this rate, I'll be amazed if the whole thing works even if I do get it all back together in one piece.

aptitude 0.3.4 uploaded to experimental

I've just uploaded aptitude 0.3.4 to experimental. At this point all of the destabilizing changes I wanted to squeeze into 0.4 have made it into the source tree and seem to work, so this is a release candidate for 0.4 once the translators catch up. Please go test it!

Relative to the version in unstable, this version has UTF-8 support, a new dependency resolution algorithm, threading (e.g., the program is responsive while a download is going on), and a whole bunch of smaller bugfixes and new features (including some of the most annoying bugs in previous versions).

[UPDATE] I was just reminded that not everyone is familiar with how packages get into our archive. Packages don't go into the archive immediately upon being uploaded (which is why installing aptitude directly from experimental doesn't work yet); they first have to sit in an "incoming" queue until the once-a-day archive maintenance script runs and moves them into the archive.

In brief, aptitude will be available in the usual way at around 4-5PM EDT tomorrow, or you can get it from the following URLs (which will be removed around 3PM EDT tomorrow):

• aptitude
  
• aptitude-doc-cs
  
• aptitude-doc-en
  
• aptitude-doc-fr