Kyle

Recently I was pointed toward an article in the New York Times that revealed and discussed a new bit of information about the state of marriage in this country:

For what experts say is probably the first time, more American women are living without a husband than with one, according to a New York Times analysis of census results.

In 2005, 51 percent of women said they were living without a spouse, up from 35 percent in 1950 and 49 percent in 2000.

Coupled with the fact that in 2005 married couples became a minority of all American households for the first time, the trend could ultimately shape social and workplace policies, including the ways government and employers distribute benefits.

Several factors are driving the statistical shift. At one end of the age spectrum, women are marrying later or living with unmarried partners more often and for longer periods. At the other end, women are living longer as widows and, after a divorce, are more likely than men to delay remarriage, sometimes delighting in their newfound freedom.

In addition, marriage rates among black women remain low. Only about 30 percent of black women are living with a spouse, according to the Census Bureau, compared with about 49 percent of Hispanic women, 55 percent of non-Hispanic white women and more than 60 percent of Asian women.

I think this is a very interesting development. To further explore the causes of this fact about modern marriage, the Times interviewed several women (many divorced) to ask their thoughts on the matter. A woman named Carol Crenshaw had this to say:

Carol Crenshaw, 57, of Roswell, Ga., was divorced in 2005 after 33 years and says she is in no hurry to marry again.

“I’m in a place in my life where I’m comfortable,” said Ms. Crenshaw, who has two grown sons. “I can do what I want, when I want, with whom I want. I was a wife and a mother. I don’t feel like I need to do that again.”

What struck me about this is that she IS a mother, whether she likes it or not. The idea that she can just wash her hands of the whole dirty business, that she feels so little regard for her children and feels no responsibility to them at all is appalling to me. Is THIS what divorce is? Self-centered self-congratulatory women luxuriating in their perceived lack of responsibility? Is this what marriage has become viewed as? A yoke to be thrown off or a burden to be self-righteously borne? No wonder fewer and fewer people seem interested.

Another interesting tale was from a woman named Besse Gardner, age 24, who is currently living with her boyfriend. She says:

“My roommate is someone I’d be thrilled to marry one day, but it doesn’t make sense right now.”

I really do wonder, why not? What, other than location, makes marriage “make sense” at some points and not at others. Ordinarily I would say she’s really not 100% sure of her boyfriend (whatever that means these days) and refusing to say so, but in this context, one does have to wonder.

Another woman (Elissa B. Terris, 59, of Marietta, Ga) divorced her husband of 34 years while complaining that he refused to let her go back to school.

One way of responding to this, of course, is to cheer her on. Any idiot husband with that severe a case of cranial-rectal-inversion deserves to be left, right? And, more to the point, shouldn’t she have been able to tell that he was such a cave-dwelling troll at heart before she married him?

This is an interesting way of looking at it, I feel. There is something going wrong in that relationship, but what are the options, and what could have prevented it? Underlying some of this, particularly the latter question, is the idea that people are who they are and that’s the end of it. This seems to me to be an odd idea given my concept of marriage, which is that it is (or is at least supposed to be) a process of becoming better and better suited for one another: dealing with change, adapting to it, and becoming closer to each other. The adaptation cannot be unlimited, of course, as we are merely human. The choice of spouse must, it seems to me, be based upon core principles and motivators that point toward the potential spouse being willing and determined to grow together. The real difficulty, of course, is making that determination while your hormones and passions are raging, everyone else is getting married around you, pop psychology tells you that everyone should be free to be an individual, etc.

What this reminds me of is a conversation that I had with a wife of one of the researchers at the conference in Italy that I went to. I told her that I was thinking of possibly proposing to my girlfriend, and she told me to “get to it!” because, she said, the older we get, the more ossified our habits and patterns of thinking become. Her description brought to mind an image of people as bits of clay slowly drying, and the younger and wetter the bits are when you mash them together, the better they fit.

Bringing that idea to the idea of the unchangeability of people in marriage, it occurs to me that perhaps a more significant underlying cause here, that is changing (or has changed) how we think of both marriage and of people themselves, is that people are getting married at older and older ages. What was once a more easy thing, that people are more influenced and become more similar with/to their spouses when they marry at younger ages, has become more difficult, as people delay marriage farther and farther (what with college, grad school, med school, law school, etc.). And perhaps what underlies THAT, even, is this fundamental mental depiction of college as a young-ling activity. That when you are a college student, you are fundamentally immature and that thus it is something one should not and cannot do while married.

Or perhaps it springs from something entirely different. It seems to me that this is the natural consequence of marrying for love rather than for something more tangible like money or diplomacy or whatnot. We have this idea that we should choose a mate based on a feeling like love, which is often confused with passion, and at the same time that we should “choose wisely”, because some folks are just bad seeds and we want our marriage to last. This in turn causes people to wait longer and longer to get married because they become pickier and pickier, as they are worried about whether their feelings will last, and the slightest thing that might cause the passion to die becomes a sign that it would never “work out”. Thus, people get married older (if at all), and as a consequence are more set in their ways and less able or willing to compromise. Not that, of course, getting married later cannot ever work, but it is harder, and requires an immediate commitment to building the “team” that is the fundamental structure of marriage.

In my opinion, the fundamental problem behind the conflict where one person (for example) wishes to be further educated and the other doesn’t want it is that fear of change, the refusal to compromise, and a shocking dose of misunderstanding. The man who forbids further education is simply afraid of something he relied on in static terms changing (and, as a consequence, is ruining it) which prevents him from thinking about or understanding the reasons behind the request. The woman who demands further education is incapable of even beginning to grasp where this stranger she married might be coming from, and instead treats him merely as an object of patriarchal subjugation rather than as a spouse and partner who is misguided or afraid. As a result, neither one can communicate or compromise. It shocks me that the “logical” conclusion is that divorce is considered the “natural” solution to this problem. What lack of understanding! What lack of commitment! What a shallow and self-serving view of marriage! On both their parts!

I met with a couple that faced exactly this same problem recently as part of my pre-canna obligations. The woman (who has since been a city councilwoman, been on several school boards, and a handful of other elected positions) wanted to go back to school to get her master’s degree, and her husband wanted none of it. The reason was hat he was afraid of the change in their house: he was afraid of not seeing his wife, of being alone, of assuming her responsibilities in her absence… He was just afraid of the unknown. The way his wife addressed it, in many long conversations, was to reassure him that she was not planning on radically upsetting their world, and that she would get her degree in a way that disrupted their daily routine as little as possible. But what mattered was that she did not simply become absolutist about it, call him a pig, and divorce him. She valued what they had together just as much as he did, and had to
address him as the man she’d promised to honor and cherish the rest of her life.

This is not to say that such an issue of education is a make-or-break issue, but merely that it is representative of the kind of issue confusion that presents itself all the time. All of these things require the introspection of asking “what is the REAL problem” (i.e. fear of change) rather than addressing merely the obvious symptom (i.e. he doesn’t want me educated).

Education is an interesting case for more reasons than just as an example of a topic of marital strife. A follow-up article in the New York Times which reveals:

Statistics show that college educated women are more likely to marry than non-college educated women — although they marry, on average, two years later. … In the past, less educated women often “married up.” … Now, marriage has become more one of equals; when more highly educated men marry, it tends to be more highly educated women.

…

Women with more education also are becoming less likely to divorce, or inclined to divorce, than those with less education. They are even less likely to be widowed all in all, less likely to end up alone.

“Educated women used to have a difficult time,” said David Popenoe, co-director of the National Marriage Project at Rutgers University. “Now they’re the most desired.”

The article does not discuss, though, whether most of these educated women in successful marriages are earning a wage or whether they are full-time stay-at-home moms. They do, however, have this to say:

“Marriage is more difficult today than it was in the past,” Mr. Popenoe said. “The people who excel in one area probably excel in that area, too. And people who are high school dropouts probably have a higher propensity to drop out of marriage.”

The last 30 years have seen a huge shift in educated women’s attitudes about divorce. Mr. Martin [a sociologist at the University of Maryland], who has written about women and divorce, said that three decades ago, about 30 percent of women who had graduated from college said it should be harder to get a divorce. Now, about 65 percent say so, he said.

But for less educated women and for men, the numbers have not changed; only 40 percent — a minority — say it should be harder to get a divorce.

“The way we used to look at marriage was that if women were highly educated, they had higher earning power, they were more culturally liberal and people might have predicted less marriage among them,” Mr. Martin said. “What’s becoming more powerful is the idea that economic resources are conducive to stable marriages. Women who have more money or the potential for more money are married to men who have more stable income.”

I found a great quote:

Locks are like tanks - powerful, slow, safe, expensive, and prone to getting you stuck.

It goes well with this picture:

Creating atomic increments (and avoiding locks) on various architectures is absurdly difficult harder than it should be. And portable? HA! You said “portable.” I’ve been looking into it, and here’s my little collection of implementations.

So, there’s a small amount of information out there about doing it on PowerPC. In GCC’s inline-assembly, on Linux (using gcc 4.1.2) it looks like this:

void atomic_incr(int * operand, int incr)
{
    asm volatile (
        "loop:\n\t" /* repeat until this succeeds */
        "lwarx  6,0,%0\n\t" /* reserve the operand */
        "add    6,6,%1\n\t" /* add incr to it */
        "stwcx. 6,0,%0\n\t" /* put the sum back, and release it */
        "bne- loop" /* start-over on failure */
        :
        : "r" (operand), "r" (incr)
        : "r6"
     );
}

For some idiotic reason, this is different on MacOS X:

void atomic_incr(int * operand, int incr)
{
    asm volatile (
        "loop:\n" /* repeat until this succeeds */
        "lwarx  r6,0,%0\n\t" /* reserve the operand */
        "add    r6,r6,%1\n\t" /* add incr to it */
        "stwcx. r6,0,%0\n\t" /* put the sum back, and release it */
        "bne- loop\n" /* start-over on failure */
        :
        : "r" (operand), "r" (incr)
        : "r6"
     );
}

Note the addition of @r@’s in front of all of the register numbers.

But that’s just fine. It makes some sense, and above all: it works!

Actually, here’s an even better one (more optimizable, and more cross-platform):

void atomic_incr(int * operand, int incr)
{
    register tmp;
    asm volatile (
        "loop:\n" /* repeat until this succeeds */
        "lwarx  %2,0,%0\n\t" /* reserve the operand */
        "add    %2,%2,%1\n\t" /* add incr to it */
        "stwcx. %2,0,%0\n\t" /* put the sum back, and release it */
        "bne- loop\n" /* start-over on failure */
        :: "r" (operand), "r" (incr), "r" (tmp)
     );
}

Now, show me the same thing for Intel processors. What’s that? You can’t? Of course not. Because Intel loves mucking with this stuff, so each of their processors uses a slightly different syntax to get the best speed. That, and getting it into GCC syntax is additionally difficult because some genius keeps changing the GCC assembler semantics.

Here’s a basic atomic increment that works on most x86 machines (NOT i386’s):

void atomic_add(int * operand, int incr)
{
    asm volatile (
        "lock xaddl %1, %0\n" // add incr to operand
        : // no output
        : "m" (*operand), "r" (incr)
    );
}

It uses xaddl so that I don’t have to worry about output, and can do the memory operation. The following also works, but may not be as fast (or it may be equivalent):

void atomic_add(int * operand, int incr)
{
    asm volatile (
        "lock xaddl %1, (%0)\n" // add incr to operand
        : // no output
        : "r" (operand), "r" (incr)
    );
}

Here’s a version that works on 386’s. I don’t know which is “faster” on all architectures:

void atomic_add(int * operand, int incr)
{
    asm volatile (
        "lock addl %1, %0\n" // add incr to operand
        : "=m" (*operand)
        : "r" (incr), "m" (*operand)
    );
}

But does ANY of that work on fancy Itanium (ia64) machines? Hell no!

You may be wondering: how does the Linux kernel implement atomic increments on ia64 machines. Like this:

#define atomic_add(i,v) \
({ \
    int __ia64_aar_i = (i); \
    (__builtin_constant_p(i) \
     && (   (__ia64_aar_i   1) || (__ia64_aar_i    4) \
         || (__ia64_aar_i   8) || (__ia64_aar_i   16) \
         || (__ia64_aar_i  -1) || (__ia64_aar_i   -4) \
         || (__ia64_aar_i  -8) || (__ia64_aar_i  -16) \
            ? ia64_fetch_and_add(__ia64_aar_i, &(v)->counter) \
            : ia64_atomic_add(__ia64_aar_i, v); \
})

Yeah, pretty sweet, no? Separate functions for doing simple math versus doing other increments. Here’s a simple increment:

void atomic_oneup(int * operand)
{
    uint64_t res; // this MUST be 64 bits
    asm volatile (
        "fetchadd4.rel %0=%1,%2"
        : "=r" (res)
        : "m" (*operand), "i" (1)
        : "memory"
    );
}

Note that it HAS to return something, because it’s a fetch instruction. But it’s also conveniently atomic. And that increment doesn’t have to be 1, obviously, but could be any of the ones listed in that ugly #define. But what about adding arbitrary numbers? For this we must use cmpxchg. Here’s how Linux uses it (tidied up a LOT):

static __inline int ia64_atomic_add (int i, atomic_t *v)
{
    __s32 old, new;
    do {
        old = atomic_read(v);
        new = old + i;
    } while (ia64_cmpxchg(acq, v, old, new, sizeof(atomic_t)) != old);
    return new;
}

How can you not love something like that? Boiling it down, that call to ia64_cmpxchg turns into: ia64_cmpxchg4_acq((__u16*)v, new, o); (that @o@ variable is a place-holder). THAT, in turn, is this:

#define ia64_cmpxchg4_acq(ptr, new, old) \
({
    __u64 ia64_intri_res;
    asm volatile ("mov ar.ccv=%0;;" :: "rO" (old));
    asm volatile ("cmpxchg4.acq %0=[%1],%2,ar.ccv":
    "=r" (ia64_intri_res) : "r"(ptr), "r"(new) : "memory");
    ia64_intri_res;
})

Just so we don’t go insane here, here’s a condensed loop:

void atomic_incr(int * operand, int incr)
{
    int64_t res, old, new;
    do {
        old = *operand; // atomic if operand is 32-bit aligned
        new = old + incr;
        asm volatile ("mov ar.ccv=%0;;" :: "rO" (old));
        // these are separate because the compiler inserts stuff in between
        asm volatile ("cmpxchg4.acq %0=[%1],%2,ar.ccv":
                    "=r" (res) : "r"(operand), "r"(new) : "memory");
    } while (res != old); // if res==old, our computation is out of date
}

Ugly much? Just a bit.

Something else I’ve discovered, which is kinda critical. There is a big difference between

asm volatile ( /* stuff */ );

and

asm __volatile__ ( /* stuff */ );

Which is that gcc is MUCH more careful not to muck with the latter, but feels free to modify the former if it feels it would be a good idea. The only difference between

asm volatile ( /* stuff */ );

and

__asm__ volatile ( /* stuff */ );

is that the latter can be used if the former conflicts with something.)

My Dad recently pointed me to this article about the programming tool, Alice. Essentially, the idea is that the way to address the attrition of students away from Computer Science is to make learning programming more “fun.” To that end, Alice provides a Sims-like graphical interface that allows you to express basic programming control flow (iteration, conditionals, etc.) without needing to worry about things like syntax, memory, variables, or math.

I think it’s an interesting idea. I don’t really agree with it, but it is interesting. I mean, I can see a stronger argument for starting with Lego Mindstorms than starting with this thing. Why must computers be reduced to telling stories about three little pigs in order to get anyone interested? Math doesn’t have to do that. Physics doesn’t have to do that. Biology doesn’t have to do that. The Alice author makes fun of adding 20 numbers together, but come on; in calculus, you spend months trying to understand (and memorize) trigonometric equivalents and logarithmic estimations so that you can finally use derivatives to calculate the volume of an imaginary, physically impossible, three-dimensional shape. To mockingly quote him, “Hu-freakin’-rrah.” You have to start somewhere.

If the benefit is primarily that you can easily visualize your algorithms, I would counter that Logo (where you program a “turtle” (triangle) to draw lines) did the same thing back in the 80’s.

And I’m shocked by the vocabulary of this program (Alice). The most popular OS programming language, C, has 32 keywords. Alice, apparently, has 10,000. And it’s supposedly easier?

It’s a shame the author of the article spends so little time pondering the all-important question “Are students who use Alice actually learning what they need to learn?” My own objections to it aside, that’s the really important question.

Though I do feel that when you take your homework home, it shouldn’t look like you’ve been preparing class materials for a kindergarten teacher unless that’s what you have been doing. I mean, what’s next, teaching computers with sock puppets? Perhaps we can get a magician in? And hey, if we can somehow involve gluing glitter and uncooked pasta to things, so much the better, right?

… I may be going a bit overboard there, but seriously. There’s a time and place for infantilizing the subject matter. College-level computer science courses are not it. If there’s a place for Alice, I’d say it’s probably in middle-school. (SOMEthing has to take the place of HyperCard.)

I agree with Jane Robbins (one of the commenters) when she says “The goal isn’t to fill the enrollments, is it? That’s a bad basis for making curricular decisions.”

This is just petty, but Apple? What’s up with libtoolize? I know, I know, you decided you wanted to call it glibtoolize, and that’s fine! That’s fine, I don’t mind. But why did you distribute an autoreconf that still believed in libtoolize? That’s just dumb.

I recently was doing some work on the computer of an elderly friend of mine, and had a bit of a scare with a hard drive that appeared to have failed. Turns out the boot block had been corrupted somehow, which was easy enough to fix from another computer (yay Linux!). Anyway, this made me stick my nose into S.M.A.R.T. statistics on hard drives. There’s a nice little tool for OSX that sits in the menu bar and keeps an eye on your disks for you (SMARTReporter). I figured there had to be something similar for Windows. In the “free” department, there’s very little available that’s worth beans, but I was able to find something called HDD Health. No sooner had I installed it than it started telling me that the Seek Error Rate was fluctuating wildly (generally it would go from 100 to 200 and back again every couple minutes). This was rather sudden! I got worried about the health of the drive, and started backing things up on it… then I looked it up on the internet. Apparently this is a common thing with Western Digital drives (which is what this computer had): their Seek Error Rate tends to fluctuate like that, and it doesn’t mean anything at all. The general recommendation seems to be “download the diagnostic tools from Western Digital; those will be authoritative”. So I did, and they said the drive was in perfect health.

Well, so much for being worried!

It does seem to speak to the temperamental (and largely useless) nature of S.M.A.R.T. statistics. Thing to keep in mind: they don’t always mean much.

There seems to be some disagreement, at Apple Computer, about exactly what the definition of the word “ignore” is. From the “sort” man page:

-d Sort in `phone directory’ order: ignore all characters except letters, digits and blanks when sorting.

What does that suggest to you? Well, let’s compare it to the GNU “sort” man page:

-d, —dictionary-order
consider only blanks and alphanumeric characters

So you’d THINK, right, that sorting with these two options would be equivalent, right?

Nope!

Here’s a simple list:

- 192.168.2.4 foo
- 192.168.2.42 foo

How should these things be sorted when the -d option is in effect? You’ve got a conundrum: is a space sorted BEFORE a number or AFTER a number?

Curse you, alphabet! You’re never around when I need you!

And, of course, BSD and GNU answer that question differently. On GNU, the answer is AFTER, on BSD the answer is BEFORE! Oh goody.

Here’s a better way if you need the sorting results to be the same on both BSD and GNU: replace all spaces with something else non-alpha-numeric that isn’t used in the file (such as an underscore, or an ellipsis, or an em-dash). Then sort with -ds (no last-minute saving throws!), then replace the underscore (or whatever) with a space again.

And if you need it to be consistent on OSX platforms too, make it a -dfs sort (so that capitals and lower-case are considered the same).

So, I upgraded to MacOS 10.5 recently (from 10.4). Those of you who know me will doubtless be thinking “my god, man, what took so long?!?”, and that’s a longer story than I want to get into right now. Suffice to say: we’re rocking and rolling now!

My impressions of the new OS are pretty favorable. I’ve read all the complaints about the UI changes, and they have some merit. By the time I upgraded, Apple had already released 10.5.2, which addressed many of the more unfortunate problems for people like me who put /Applications into the Dock.

I really DO like the “Fan” icon display, though, particularly for the new “Downloads” folder. Creating a folder just for downloads is something I could have done years ago, of course, but I hadn’t - everything downloaded to the Desktop, which inevitably became incredibly cluttered. But I love the new approach, and part of what makes it especially useful is that things in the “Fan” display can be dragged to the trash. HA! I love it! It’s the little things that make me happy. :)

The new X11 is a bit of a pain in the butt. I’d become very used to using xterm - or more precisely, uxterm - for all my terminal needs (which is to say, for 90% of what I do with my computer). That’s not so tenable now, particularly since Apple has apparently decided that uxterm was just too useful a shell script to let stand. I am keeping a copy of that shell script (which just runs xterm with all the necessary utf-8 flags and sets the LANG appropriately) handy, just in case, but for the time being, I’ve decided to migrate to using Apple’s Terminal full time now. Undoubtedly, it’s still not as fast as uxterm, but since getting an Intel iMac, I don’t really notice anymore (on the old dual 500Mhz G4, it was definitely noticable).

For migrating, I’ve had to create my own nsterm-16color termcap file (which I keep in ~/.terminfo/n/nsterm-16color ) in order to ensure that all the features I want work properly. I stole the file from ncurses 5.6, and modified it to add correct dual-mode swapping ( smcup=\E7\E[?47h, rmcup=\E[2J\E[?47l\E8 ) and then to support the home and end keys ( khome=\E[H, kend=\E[F ). These are things that the native OSX dtterm/xterm/xterm-color/whatever terminfo settings don’t do correctly. ( WHY???) …And then, of course, I had to fix the key mapping of pageup/shift-pageup and pagedown/shift-pagedown and all the relative keys, but that was easy to do in the Terminal.app’s preferences. The defaults are sensible, just not for folks who are used to xterm’s behavior. I also re-discovered that I hate Terminal.app’s default blue (a dark, almost-midnight blue), and much prefer having a lighter one. Thankfully I’m not the only one - Ciarán Walsh’s update to the TerminalColors plugin is solid and works well.

Other than that, things have been pretty smooth. I haven’t experienced any really strange compatibility problems — in large part, I think, because I keep my system pretty up-to-date, so I already had the “Leopard-compatible” versions of all the software I use (and all the Unix applications seem to work flawlessly without even needing a recompile - huzzah for that!).

The one application that needed SERIOUS fiddling is VirtualBox. They have an OSX version, but only in beta form. I use it mostly so I can provide sensible Windows XP support to relatives who have computer questions (and for doing browser compatibility tests). I had been using Beta 2 (1.4.6), which had worked flawlessly for my needs. Unfortunately, Beta 2 isn’t compatible with Leopard, so an upgrade to the latest (Beta 3) was necessary. THIS beta seems to have a few problems. For one thing, it can’t understand all the old machine definitions (so when upgrading, make sure you don’t have any important system snapshots or saved machine state that you need). However, it does understand the old disk files, so it’s a simple matter to create a new machine definition using the old disk. The new machine still won’t BOOT, though, and it took me an hour or so of fiddling to figure out how to fix it.

There are two major problems that crop up. First: they changed the default IDE controller for Windows XP guests. The old default was PIIX3; the new default is PIIX4. Either one will work, and if you install XP from scratch on a newly created XP host, it will work with the PIIX4 controller just fine. But if you’re booting from an XP that was created with Beta 2 (i.e. a WindowsXP installation that thinks you have a PIIX3 controller), it will blue-screen and reboot immediately after displaying the Microsoft logo: not good. Fixing it is easy, though: just change the IDE controller for your XP machine in the machine settings dialog.

The second problem is that the network doesn’t work. Actually, that’s not true, the network works just fine, it’s DNS resolution that doesn’t work (but one looks a lot like the other when you’re not paying close attention to error messages). For whatever reason, when your XP system uses DHCP to get its network information, the information it receives from VirtualBox is wrong. Specifically, VirtualBox tells it to resolve DNS names by contacting 10.0.2.3; it should be contacting 10.0.2.2 (i.e. the same as the router). Fixing this was just a matter of changing Windows’ network configuration to use a custom DNS server (10.0.2.2) rather than the one supplied by DHCP. Annoying, but nothing terrible.

The only other stumbling block in Leopard that I’ve come across is the iChat-vs-Internet-Sharing problem that other people have discovered. Essentially, if you have enabled Internet Sharing, iChat can’t do video conferencing. Something to do with being able to remap ports… the explanations I’ve read are rather vague. It’s not especially important to me, but came up when I was trying to demonstrate the virtues of Leopard to Emily.

Which reminds me: the new iChat is MUCH better for talking to multiple people at the same time. The “tabbed” chatting interface is terrific. The vaunted “Spaces” (virtual desktops) are nice, and implemented well, but I gotta say that I’ve gotten used to having just one desktop these days (I use Exposé a lot). Getting used to having the extra desktops will probably take a while.

Two more features I noticed were the Quick View (in Finder, press the space bar to quickly view something) and Web Clips (in Safari, you can take a snippet of a webpage and turn it into a Dashboard widget). Quick View is pretty great, especially for folders full of PDFs, because you can leave it up and keep navigating around the Finder (the contents of the Quick View window will track whatever you select in the Finder), but since I don’t spend much time in the Finder, it’s of limited use. If I could integrate it with my ~/.mailcap file, now THAT would be awesome. Web Clips are not quite as great as they could be. For one thing, they don’t refresh quickly (but they DO refresh—at first I didn’t think they did—and in the worst case, you can click on them and press Ctrl-R to force the issue), and for another, they can’t scale — many of the things I want to clip are large graphics that I wish to monitor. If OSX could scale clips down for me, that would make them much more useful.

Which reminds me — one new feature of Leopard that I adore is their new built-in VNC viewer. It may not actually be VNC, but that’s fine by me — it’s blazing fast, and best of all, it scales the screen down so that you can easily control a screen that’s larger than the one you have. Chicken of the VNC used to be a must-have application for me, but Leopard’s built-in screen viewer is much better for what I usually want to do (which is control the iMac upstairs from the laptop down on the couch).

Its error handling is CRAP.

I am coming to this realization because I recently lost a BUNCH of messages because of a bad delivery path (I told procmail to pipe messages to a non-existent executable). So what did procmail do? According to its log:

/bin/sh: /tmp/dovecot11/libexec/dovecot/deliver: No such file or directory
procmail: Error while writing to "/tmp/dovecot11/libexec/dovecot/deliver"

Well, sure, that’s to be expected, right? So what happened to the email? VANISHED. Into the bloody ether.

Of course, determining that the message vanished is trickier than just saying “hey, it’s not in my mailbox.” Oh no, there’s a “feature”, called ORGMAIL. What is this? According to the procmailrc documentation (*that* collection of wisdom):

ORGMAIL     Usually the system  mailbox  (ORiGinal  MAIL‐
            box).   If,  for  some  obscure  reason (like
            ‘filesystem full’)  the  mail  could  not  be
            delivered, then this mailbox will be the last
            resort.  If procmail fails to save  the  mail
            in  here  (deep,  deep  trouble :-), then the
            mail will bounce back to the sender.

And so where is THAT? Why, /var/mail/$LOGNAME of course, where else? And if LOGNAME isn’t set for some reason? Or what if ORGMAIL is unset? Oh, well… nuts to you! Procmail will use $SENDMAIL to BOUNCE THE EMAIL rather than just try again later. That’s what they mean by “deep, deep trouble.” Notice the smiley face? Here’s why the manual has a smiley-face in it: to mock your pain.

But here’s the real crux of it: procmail doesn’t see delivery errors as FATAL. If one delivery instruction fails, it’ll just keep going through the procmailrc, looking for anything else that might match. In other words, the logic of your procmailrc has to take into account the fact that sometimes mail delivery can fail. If you fail to do this, your mail CAN end up in RANDOM LOCATIONS, depending on how messages that were supposed to match earlier rules fare against later rules.

If you want “first failure bail” behavior (which makes the most sense, in my mind), you have to add an extra rule after EVERY delivery instruction. For example:

:0 H
* ^From: .*fred@there\.com
./from_fred

:0 e # handle failure
{
    EXITCODE=75 # set a non-zero exit code
    HOST # This causes procmail to stop, obviously
}

You agree that HOST means “stop processing and exit”, right? Obviously. That’s procmail for you. Note that that second clause has gotta go after EVERY delivery instruction. I hope you enjoy copy-and-paste.

Another way to handle errors, since successful delivery does stop procmail, is to add something like that to the end of your procmailrc, like so:

:0 # catch-all default delivery
${DEFAULT}

 # If we get this far, there must have been an error
EXITCODE=75
HOST

Of course, you could also send the mail to /dev/null at that point, but unsetting the HOST variable (which is what listing it does) does the same thing faster. Intuitive, right? Here’s my smiley-face:

>:-P