Awhile back I went a little overboard and picked up a few DVDs that I thought might be interesting to watch.  That was a few months ago, and I'm only now getting around to them.

I started with Requiem for a Dream, last night.  I didn't really know too much about the movie beforehand other than that it dealt w/drugs and people's lives being messed-up.  There really wasn't much more to it, actually.  However, the presentation was unique and powerful - Darren Aronofsky really did a great job of portraying the lives of the main characters as their dreams evaporated throughout the film.  Every once and awhile I'll come across a film that makes me think about all the good things in life (that most of us take for granted?).  This was one of those movies.  The last one was Children of Men.

Would I recommend?  Well, depends on who's asking, I suppose.

Pi is next on the viewing list.

I was looking through some logs today, and this one caught my eye:

Aug 5 07:51:01 dax named[90967]: client 129.79.247.103#46566: view external: zone transfer 'kamichoff.com/AXFR/IN' denied

(I always go back and forth on whether I should be allowing TCP DNS queries, or not.  On one hand, it makes DNSreport happy, and will handle tons of RRs for an object, if I ever need that many.  On the other hand, I'm opening up my servers to undisclosed vulerabilities in named, etc.)

Anyway, 129.79.247.103 is…

% host 129.79.247.103
103.247.79.129.in-addr.arpa domain name pointer DNS-RESEARCH-SERVER-FOR-MORE-INFO-SEE-DNS-TXT-ENTRY-FOR-hulk.cs.indiana.edu.
% host -t TXT hulk.cs.indiana.edu.
hulk.cs.indiana.edu descriptive text "DNS RESEARCH INFO AT http://www.cs.indiana.edu/cgi-pub/cshue/zone_transfers.php"

If you go there, it's apparently a project with the goal of gathering statistics on the percentage of servers out there that allow unrestricted zone transfers.  I suppose, as always, the results will be depressing.

If I were you, I'd avoid 2.1 like the plague.

I saw a FreeBSD update for the jabberd port this morning, and decided to upgrade.  Big mistake.

Out of the three clients I tried, only one of them worked after the upgrade (Psi).  Gaim and cabber both complained about authentication errors.  This is after a meticulous update all the XML configuration files and manual refreshing of the database schema (see the first comment here).

Sufficed to say, prox@prolixium.com will be offline for a bit.

Update:

Turns out SASL is enabled by default, in the new version, and Gaim/cabber accept this authentication mechanism, but really don't support it correctly.  Commenting out the sasl section under authreg mechanisms did the trick.

If Quantum physics wasn't weird enough:

http://www.msnbc.msn.com/id/19875410/site/newsweek/page/0/

So, if a router load-balances between two links, and packets act like elementary particles…

Let's cut to the chase, and stop the stupidity:

• Fix I-485.  You know what's wrong, just do it.  Oh, also: PAVING IT IS NOT THE ANSWER.
• Do something about all the new buildings and housing developments that are popping up like mushrooms on crack.  If you're not going to expand the roads or deploy a light rail where it will actually benefit people, rig up some zoning magic that may help prevent complete congestion collapse.
• Fix the DMV.  I'm sick of seeing all these people riding on the wrong side of the road, especially school buses.  It's just a tad dangerous.  Also, contrary to popular beliefs, cell phone usage in the waiting area DOES NOT CAUSE CAMERAS TO CRASH, use another excuse that makes sense.

There, now I feel better!

I'm starting to think that the word “thanks” is becoming overutilized, therefore cheapened and perhaps meaningless, in today's online correspondence.  I hope this is only constrained to IT, but maybe it's worse than I think…

Take a look at your .signature file.  Does it have some form of Thanks! included above the contact information?  If so, you are part of the problem!  Why say thanks to everything?  It's supposed to be said when you are thanking someone for something!  Webster's says:

to express gratitude, appreciation, or acknowledgment to: She thanked them for their hospitality.

What purpose does a thanks! serve when the body of the e-mail relates to oh, asking someone why a server was shut down without a notification message sent to the Unix administrators group?  Thanks for being incompetent?  Or, how about a thanks! after canceling a meeting due to scheduling conflicts.. thanks for being unavailable?  How about after sending out general information, like “the 21 subnet will be retired this weekend” - thanks for reading this?

Can we all just reserve this word for situations when it's appropriate?

I finally acquired up some more horsepower for my lab, the other day (since a single Athlon 64 couldn't handle 9x dynamips instances and 5x VMs).  Other than the forcedeth driver (from linux-image-2.6.18-4-amd64) reading the MAC address in the wrong byte order, installation of Debian Lenny amd64 (testing) was uneventful.  I found out shortly after that this happens to be resolved in the linux-image-2.6.21-2-amd64 package.

VMware Server 1.0.3 (build 44356) installed fine, after applying the recommended patch, downgrading module-init-tools and installing the following compatibility packages:

• ia32-libs
• lib32bz2-1.0
• lib32gcc1
• lib32ncurses5
• lib32objc1
• lib32readline5
• lib32stdc++6
• lib32z1
• libc6-i386

However, starting any VM results in a host system hang, several seconds into the bootup process of the guest OS.  The log displays the following:

Jul 16 20:42:13: vcpu-0| MONITOR PANIC: vcpu-0:DoubleFault @ 0x4020:0x8a3b4 (0x63,0x2cc0)
Jul 16 20:42:13: vcpu-0| Core dump with build build-44356
[...]
Jul 16 20:42:14: vcpu-0| Monitor Panic. Last Disk I/O was to the MBR
Jul 16 20:42:14: vcpu-0| Msg_Post: Error
Jul 16 20:42:14: vcpu-0| [msg.log.monpanic.beta] *** VMware Server internal monitor error ***
Jul 16 20:42:14: vcpu-0| vcpu-0:DoubleFault @ 0x4020:0x8a3b4 (0x63,0x2cc0)
Jul 16 20:42:14: vcpu-0| There is a problem in this version of VMware Server.

Seems to happen with the two guests I've tried, which are Red Hat Enterprise 5.0 Server and Debian/GNU Linux 4.0.  Toying with noapic and other kernel arguments in the guest doesn't seem to help.  I suspect something is going horribly wrong with the vmnet module, since that's the only VMware module that is resident at the time.  I'd submit a bug report to VMware, but I'm not running a “supported” host OS.

Oh well, at least dynamips runs nicely.

Happy 4th!