All and all, it is pretty simple. I've been using it for about 6 months now without any problems. Things should get even better once 5.8.0 matures, as it is even more OS X friendly.
my brand-spanking-new tibook doens't seem to like picking up wireless connections. At all. Period. I've given up on it. I was so mad at it during Jessie's RT talk, that I slammed the screen shut and stared at it.
So I'm using cat 5. I'm the guy with the length of blue cat5 that Larry almost tripped over, right off the stage during Damian's talk.
I just discovered that I'm kinda rare for having got mod_perl to work on OS X. Funny thing is that I've been doing most of my devel for dyn on my OS X box, running a whole copy of the system.
In other news, I played around with the patch on Net::DNS that Matts found. It's slower than the old code. Fudge!
Got activeperl installed on XP under Virtual PC. Installed nmake, installed Net::DNS. Can't reproduce the bug. (The bug being the Net::DNS::Resolver doesn't get the right IP for the local recursive DNS server.)
However, the bug report was for windows 2000. So I install w2k, activeperl, nmake, and Net::DNS. And... I can't reproduce the darn bug!
On the plus side I had an epiphany last night about how Net::DNS::Resolver should be reorganized. Right now it's very monolithic, with lots of the "copy and paste" code reuse methodology.
I don't have the details plained out, I have to wade though the code and figure those out, but here is my plan:
Net::DNS::Resolver keeps the same interface, it's for setting options, building packets to be sent, and getting the results of sending those packets. Interally, it uses Net::DNS::Connection::UDP or Net::DNS::Connection::TCP classes, instead of Net::DNS::Resolver::send_tcp() or Net::DNS::Resolver::send_udp(). To keep the options going back and forth nicely, I'm leaning towards some sort of options object, but that's not in stone.
I'm thinking that Net::DNS::Connection will be a super class of Net::DNS::Connection::UDP and TCP. The super class will be smart and try UDP first, and then use TCP if you run into packet fragmentation. (Or if you're doing a AXFR....)
I currently have Resolver.pm in peices scattered around my home directory. I'm also working on Text::ReflowEmail. But that's a whole other story.
Tim (krellis) is visiting. First night he's in, we decide to get the cool VoIP phone working. Networks hijinks!!
I had a DSL with all my machines NATed behind one of those magical Netgear 'router' thingys. Now, the phone talks to the controller thing, and the controller tries to talk back to the IP the phone has. In this case, the controller is trying to talk to 192.168.0.25, the internal IP. Enter network hijinks.
We setup one of my freebsd machines to do the PPPoE magic, and run NAT for me. so far so good, when we set up a IP tunnel, so that my interal 192.168.0/24 can talk to the office $something/27 directly.
Plugged in the phone, and poof. I have a Massachusetts phone at my apartment in Lansing, Michigan. I feel so l33t.
The Net-DNS homepage was, until last night hosted on a Sun X1 at dyn's ithaca server farm. All was well. Then, we notice, hey... sodium (the box's name) thinks it's July 8th.
We fix the time, it drifts off by a day or so in a few minutes. Something is clearly not right with the thing. Our solaris guy reboots the box, what the heck. It works for windows.
Later that night, I try to log into the darned thing. It's not up. I ask the solaris guy, "Yeah, it didn't come back up".
Around this point I realize, that the only complete copy of the site was on sodium, and that I had bits and peices on other machines, but that's it. Luckily google's cache had some missing stuff, and I just can generate the docs from the distrabution in one line. Copied the tarballs from cpan, and things were looking good again.
I really don't want to do that again.