The SuperDrive in my wife's G5 desktop machine has been failing to read some disks for a while now, and getting worse. Finally, it's become intollerable, so I had to replace it. I was worried that any replacement drive wouldn't have the "Apple supported" bit set on it, but as of Tiger and iLife '06 (at least), that concern is moot. That's not to say that the procedure is completely trouble-free. But with a couple of tricks, it can be done.
Most of what you need to know can be found in this helpful document at Apple's site. If you're replacing your optical drive with one you bought from Apple, then that's all there is to it.
In my case, however, I bought a Plextor 670A. When I got done installing it, the tray hit the inside of the G5 case why trying to eject. The problem is that the bezel on the front of the tray is too tall for the G5 case opening. This is likely the case with all 3rd party optical drives. The geniuses in industrial design made the case opening too small. Grumble.
Fortunately, the Plextor drive came with a beige tray and drive front bezel and instructions to swap it. The tray bezel that was too tall snapped right off, but left a "raw" looking edge. I could have just left it that way, but I took another look at the old Pioneer drive to see if there was a way to use that drive's old tray bezel instead.
It turns out that that tray bezel is just stuck on with adhesive! It was reasonably trivial to peel it off and stick it on the tray of the plextor. I crossed my fingers and reinstalled it all and sure enough - it's perfect. You'd never have any idea that it wasn't the factory drive installed in the machine.
To go along with the whole home theater thing, my wife bought me a Pioneer VSX-D914 digital surround sound receiver. It can handle up to 7.1, but our house is set up for 4.1.
I bought an M-Audio Sonica Theater used off eBay for about $15. Turns out that was a pretty good move. One small caveat, though - you do need to load the software for it or it will work only sort of part-way. Once you load the software, you need to visit its preference program (you can find it in the system preferences, but it actually runs on its own) and set it for the digital output mode. The Sonica Theater actually has a bunch of little 1/8" stereo jacks for 5.1 output, but I bought it to use its coax S/PDIF output.
With the sonica driver and software installed, the EyeTV 500 sent Dolby digital 5.1 audio right into the receiver. CSI:Miami never sounded so good. Although EyeTV has a special setting to get it to send its audio directly to a digital interface, in this instance, you do better to just set the system up to use the Sonica Theater and leave EyeTV alone.
To get the mac DVD player to output correct digital audio from DVDs, I found it was necessary to use its preference to select digital output. Otherwise, you get downmixed stereo.
So now the home theater sounds as good as it looks!
When I signed on with my company, they stuck a PC on my desk. I immediately wiped the drive and installed FreeBSD on it. FreeBSD is a good server-class OS, but the Mac has utterly spoiled me. So I actually bought myself a Mac Mini to use at work. It will be a while before there's any IT budget for a new machine for me, and in the meantime the mini is just fine, and it was very inexpensive, as things go.
I like IPv6 quite a bit. It's a great way to leave behind all of the restrictions and inconveniences that NAT impose. Anywhere I have a routable IPv4 address, I can set up 6to4 and do things like directly ssh to machines at home on the inside LAN.
Well, at work I don't have a public IPv4 address. To make a long story short, tunneling IPv6 over IPv4 just wasn't going to fly with the corporate firewall. I didn't want to make a big issue or anything, so I decided to tunnel over UDP. The easiest way to do that, of course, is with openvpn. So to make a long story short, I was able to set up IPv6 connectivity between my office machine and the house pretty easily.
Then along came the mac. What to do? Well, the mac is Unix-y enough that building and installing openvpn is no problem at all. Rather than fetch and install the LZO library, I simply added "--disable-lzo" to the configure command, then a make and make install. One last task is to obtain a tunnel driver for OS X.
I don't know if anyone will find this entry interesting, but it is certainly more interesting than an empty blog, and it is a harbringer of things to come. I haven't really hacked OS X very much lately - this is a testament to its functionality and stability - it hasn't needed hacking.
Instead, today I will talk about PostgreSQL - the most advanced open source database on the planet.
I've been using PostgreSQL for various chores ever since I started working with SQL databases. That, actually, was relatively recently in my career. My first computer was an Apple ][. In the late '80s, I transitioned directly from that to Suns running SunOS 4. Sort of an odd leap to make. I've moved with the cheese quite a number of times - I've changed my mind (in each case going from hating to loving) about Java, Databases, Object Oriented programming, GUI programming and Macs (thanks to OS X) in their turn.
What did it for me on Databases was running the 2nd FreeBSD core election a few years ago. I set up a small website where the developers could log in and register their votes (or revise them, if desired). At the end of the election, I presented the results. I did all this using PHP, a whole lot of regular expression parsing, and files in a hierarchy of directories. When I got done, it worked, but I couldn't help saying to myself, "there has to be a better way."
Databases. Duh. I didn't run the next core election (because I decided to run - unsuccessfully), but shortly after started designing little web applications using LAMP (in my case, FreeBSD, apache, PostgreSQL and PHP). At the time, I picked PostgreSQL over MySQL because of better support for transactions. I haven't looked back.
Anyway, back to today. Before I headed off to work this morning, I decided to upgrade PostgreSQL from 7.4.7 to 8.0.1 on my main FreeBSD machine (the one serving OSXHAX, among other things). Now the rule is, every time the first or 2nd digit of the number changes, you must do a dump/restore of the entire database. I wasn't looking forward to it.
I shouldn't have been concerned. Here's how it went:
Since I had set up the PostgreSQL periodic script that comes with the port to backup the database, I just ran it by hand to back it up.
/usr/local/periodic/daily/502.pgsql
Next, I shut down
/usr/local/etc/rc.d/010.pgsql stop
Next, I moved the data directory aside so that I could easily revert, if necessary:
cd ~pgsql && mv data data-
Next, I upgraded the database ports:
portupgrade -o databases/postgresql80-client postgresql-client
portupgrade -o databases/postgresql80-server postgresql-server
I copied the old pg_hba file, to preserve the access control I had set up
cd ~pgsql/data && cp ../data-/pg_hba.conf .
Next, I did an initdb and started up
/usr/local/etc/rc.d/010.pgsql initdb
/usr/local/etc/rc.d/010.pgsql start
Next, I recreated the users
cd ~pgsql/backups(today's date)
su pgsql
gzcat pgglobal- | psql template1
Next, I restored the databases(note, I was still using the pgsql user at this point)
foreach i (pgdump-*-(today's date)*)
pg_restore -C -d template1 $i
end
And that's all. Total time: about 10 minutes. It was easier than I had any hope it would be. Typing up this entry was harder.
Part of this ease was the existence of the FreeBSD ports system and the portupgrade command. But even if I decided to host the database on another OS, I suspect it would have been just about as easy.
Anyway, I am probably going to move away from Movable Type for this blog. I don't want to pay for the new non-free (as in beer) version. I was going to try Wordpress, but they aren't very database-neutral. So I will probably try Serendipity. I also am probably going to broaden the scope a bit. That way I can post more often without being off-topic.
I'll probably keep the OSXHAX name, though. It's just too cool.
It turns out I was wrong about the Mac Mini being able to handle full 1080i or 720p video from the EyeTV 500. What actually happens if you have less than a dual-G5 is that the video is scaled down to half-resolution (4 pixels become 1). So 1080i becomes 960x540 and 720p becomes 640x360. Then the video is blown up to fit the window or screen you're using.
This winds up looking as good as it does because the scalers that El Gato uses are really, really good. But any way you slice it, you're really winding up with EDTV rather than HDTV - or something that's approximately DVD quality.
Of course, the recordings are at full resolution. So I am going to, one of these days, install the software on my dual G5 and copy a recording over the net from the mini and see what it looks like. Alas, my dual-G5 machine doesn't have the 23" cinema display, it only has the 20", so the resolution is only 1680x1050 - I still won't be seeing actual 1080i.
It still looks plenty good to me. Certainly good enough until I can get my hands on an HD DirecTiVo. But when I do, I'll be switching back and forth between TiVo and the Mac a lot more than I do now, which will be a bit of a shame.
We've recently switched our phone over to Vonage. In doing so, our HDVR2 DirecTV TiVo stopped being able to make its daily phone call. I've found a good workaround using my powerbook.
DirecTV TiVos make two kinds of phone calls - there's the daily TiVo call, which goes to a local number and connects up with v.90. That's the phone call that has problems over Vonage. The other type of call is the call from the DirecTV receiver on behalf of the decryption card. This call lets DirecTV verify that multiple receivers are on the same phone line and that you're in the right blackout zone for sports packages and tells them about any PPV events you've ordered with your remote. This call happens about once a month to an 888 number and only goes at about 9600 bps, and the concensus is that these calls have no trouble going over Vonage. So I need to come up with an alternative for the TiVo calls, but leave the Vonage line connected for the other ones.
It turns out that TiVo software has some magic prefix codes that alter how it dials out. ",#401" tells it to use Ethernet (actually, it tells it not to do any prep work at all and just presume that the Internet is reachable). ",#3xx" tells it to use an external modem connected to the unit's "remote out" serial port, and ",#2xx" tells it to not send dialing commands, but simply start PPP negotiation immediately on the serial port. In both cases, the XX is the first two digits of the serial port speed. 11 = 115200, 56 = 56000, 96 = 9600, etc.
So if I make a cable that goes from the serial port on the DTiVo to a USB-to-Serial adapter and plug that into the mac, and have the mac be a PPP server, that would take care of the daily TiVo call.
The serial port on the TiVo looks like a headphone jack. It has 3 conductors: the shield, which is ground, the ring, which is transmit data, and the tip, which is received data. If you wire these to a DB9 female connector such that the tip goes to pin 2, the ring to pin 3 and the shield to pin 5, that DB9 will plug into the typical USB-to-serial adapter and work perfectly.
Having done that, we next need to handle the PPP server aspect. First, since your mac will be routing Ethernet packets from one interface to another, we must turn on IP Forwarding. You do this with the command
sysctl -w net.inet.ip.forwarding=1
(you must be root to do this). If you're already using your mac to share an Internet connection, this may already be in effect.
Next, use ifconfig -a to find out your IP address. You'll also need to make up another IP address on the same network for the TiVo to use. Lastly, you'll need to know the name of the device that is your USB-to-serial adapter. It will start with /dev/tty. Put all of that together with this command:
pppd device 115200 local persist passive maxfail 0 proxyarp macipaddr:tivoipaddr
(again, you need to do this as root). The command won't appear to have done anything. It runs as a daemon, so it should be ready to go.
On the TiVo, set your dial prefix to ",#211" (type that as pause, enter, 2, 1, 1). None of the other settings matter. Then make a test call. If your USB-to-serial adapter has activity lights, you should see them go, and the test should succeed.
This technique will also work if you have Internet connectivity but don't want your TiVo to dial out for some reason, and your TiVo doesn't have the ability to do Ethernet.
A while ago, I bought an EyeTV 500 as a way to dip my toe into digital HDTV. With the introduction of the mac mini, I have now dived the rest of the way in.
When the mac mini came out, I decided to buy one to put in the living room to hook to the TV. I was going to use it to play DVDs, check mail and play the occasional game (currently Myst IV). But I didn't think it was going to have enough CPU horsepower to play the video from the EyeTV 500. To put it in perspective, displaying 1080i video (1920x1080, 30 Hz interlaced) on my wife's 23" cinema display takes almost all of her 1.6 GHz G5.
While I was waiting for the mac mini to arrive, I did some tests with my Powerbook. Plugging it into an NTSC TV was a real disappointment. The mac desktop looked horrible. So it wasn't long after that that I bought a Samsung HL-P5063W. It had an HDMI input, for an eventual HD TiVo of some sort, a DVI input for the mac, and a bunch of analog inputs. Its native resolution is 720p (1280x720, 60 Hz), and the mac desktop looks great at that resolution. More importantly, the TV is capable of shrinking the desktop so that all of it fits on the screen (TV sets have overscan, meaning that the picture is actually larger than the visible area. That means the edges aren't visible. In the case of the mac desktop, about half the dock and the whole menu bar don't show up).
Because I wasn't going to be using 1080i, I thought I'd try playing back some shows recorded by the EyeTV. Long story short, the mac mini does have enough horsepower to show HDTV at 720p. However, the mac I bought was the "maxi" mini - the 1.42GHz model. And watching digital TV takes almost all of the available CPU. I've now moved the EyeTV out to the living room and set up a bunch of recurring recordings for HD shows like the CSI and Law and Order series.
So if you're considering a mac mini to use as an HTPC, I say go for it!
I finally got the Virtual PC upgrade edition. I did this primarily so I could move the virutal PCs from my Powerbook off to my G5 for better performance. Long-time readers will remember I have two guests: Windows 2000 and FreeBSD.
Installing Virtual PC is straightforward enough. One thing about it is that, like Office, it tries to broadcast its license key on the LAN to detect duplicates. If you don't want it to do this, just do this:
sudo ipfw add 10 drop udp from any to any 21790
This goes along with the line for Office v.X:
sudo ipfw add 11 drop udp from any to any 2222
I don't need to do any of this stuff, simply because I don't illegally copy software. Even Microsoft's.
Back to the matter at hand. Upgrading the Windows 2000 guest was actually more difficult than upgrading the FreeBSD guest. When you import the Windows 2000 guest, it starts up without a working keyboard and mouse. You just have to let it sit at the login prompt for about 10 minutes watching the disk icon blink. During this time it is making note of the hardware changes. Once you feel you've waited long enough, select 'shut down' from the PC menu, and tell it to "shut down windows 2000". This will shut down Windows the nice way, which will save the changes it made. The next time you start up, you should have control of the machine. Install the new VPC additions and everything will be fine from then on. After installing the new VPC additions, do not let Windows reboot on its own. There is some sort of bug that will get you into a BSOD loop. You need to power off the virtual machine and turn it back on. Once the new VPC additions are in, this is no longer an issue.
The only trick to FreeBSD that hasn't been discussed on this site before is the new USB support in Virtual PC. When I first tried to boot the FreeBSD guest (which I think is running 5.2.1), it hung trying to probe the USB host controllers. The fix is to go into the PC settings and disable USB support. I'll upgrade the guest to 5.3 and give it another try later on. Once it booted, I was able to start X with the exact same configuration as before.
If you have Nextel dialup modem or Packetstream service, there is an easier way to configure your "modem" to work with your mac.
In previous entries, I've given you a modem configuration script tailored for the Motorola iDen series of phones for use with Nextel. It turns out that there's a much easier way to go.
Buy the Nextel USB cable and get either Packetstream service or dialup modem service. They claim that you need their software and that it's only supported under Windows, but it works just fine with OS X.
Plug in your USB phone cable at both ends and go into the network preferences. It should notice that you've added a new device. Set it up with either a dialup destination or, for Packetstream, with a phone number of "S=2". Then flip over to the "modem" tab and tell it you have a Sprint PCS Vision modem and not to wait for dialtone.
That's it.
A while ago, I reported I had trouble getting FreeBSD fully functional as a guest OS under Virtual PC. I've revisited this idea and gotten further.
I never got X running on my FreeBSD 5.0-RELEASE guest under Virtual PC. Shortly after that, my Windows 2000 installation died after a windows update, and I sort of gave up on Virtual PC. It turns out I didn't really need Windows that desperately after all, and I have a FreeBSD desktop machine I can use if I want to (and it turns out with OS X handy I don't want to very much).
I decided more or less on a whim to resurrect the w2k VPC (it turns out it was quite easy - I just had to blow away the system hive of the registry and reinstall the VPC guest support), and that inspired me to have another go at FreeBSD.
It turns out that whatever was ailing X has been fixed sometime between 4.2.0 and 4.3.0, as I was quite easily able to get a nice 1152x768 16 bit color X server running without too much trouble. There's no trick to it. You just tell X that you need to use the "s3" driver.
The only issue now is that the real time clock runs very slow. I'm hoping that upgrading to 5.2-RELEASE will fix this. If it does, then that will make FreeBSD fully functional. Update! It appears that adding 'kern.timecounter.hardware=i8254' to /etc/sysctl.conf may fix this. Since the machine is virtual, you can't count on the TSC clock being accurate at all. There is also some special software you can run from cron to occasionally sync the virtual clock to the host clock. If it isn't already, I'll look into making that a port.
I'm not sure what use I'll put it to. After all, OS X itself is based on FreeBSD, so I have all of the *nix I really want and need without virtualization.
In the past I've said that Safari didn't support IPv6. I may have been tricked by my customary rather simplistic test.
In the past, I've usually tested for IPv6 awareness in browsers by surfing to the KAME project home page. They have some code on their page to provide alternate content for those fetching the page over IPv6 (the "Dancing Kame").
When I last tried this with Safari, I got the IPv4 page. I was playing around with a friend's web site this evening when I discovered to my shock that Safari was trying to use IPv6 to get there.
The upshot is that Safari does not prefer IPv6 addresses (but it will use them), and the kame.net name servers give back the IPv4 address record first.
So the better way to test this is to add an entry to /etc/hosts for a nonexistent name with the IPv6 address of an IPv6 aware HTTP server (www.osxhax.com will do) and try to point Safari to that nonexistent name. If you get the page back, then IPv6 must have been used to fetch it.
I don't know if this always worked or not, but I have Panther, and it works now. Huzzah!
Here's my test program. If you have an IPv6 connection set up, they should all succeed.
import java.lang.*;
import java.io.*;
import java.net.*;
public class foo {
public static void main(String[] args) {
System.setProperty("java.net.preferIPv6Addresses", "true");
DoATest("literal", "3ffe:1200:301b:0:2d0:b7ff:febe:e2a8");
DoATest("A and AAAA host", "quack.kfu.com");
DoATest("AAAA only host", "morpheus.kfu.com");
}
private static void DoATest(String testname, String host) {
System.out.println("Starting test " + testname);
try {
InetAddress ad = InetAddress.getByName(host);
System.out.println("Success: " + ad);
Socket s = new Socket(ad, 22);
System.out.println("Got connected.");
s.close();
}
catch(UnknownHostException e) {
System.out.println("Unknown host!");
return;
}
catch(IOException e) {
System.out.println("I/O Error!");
return;
}
}
}
It's not AirPort Extreme, but some folks need this capability, so...
Thomas McQuitty has figured out how to hack a driver written for a Belkin USB 802.11b adapter so it will talk to the Netgear MA101 (rev B).
His instructions are a bit round-about, though. All you really need to do is install the Belkin driver, then cd to /System/Library/Extensions/drivername.kext/Contents and edit the Info.plist file.
I've been on again / off again playing with a FreeBSD guest installed under Virtual PC. For a while, sound didn't work, but with VPC 6.0.1 sound now works.
To get it going, you need to do this (in a 5.0-RELEASE guest installation):
Add this to /boot/device.hints:
hint.sbc.0.at="isa"
hint.sbc.0.port="0x220"
hint.sbc.0.irq="5"
hint.sbc.0.drq="1"
hint.sbc.0.flags="0x15"
Then add this to /boot/loader.conf:
snd_sbc_load="YES"
snd_sb16_load="YES"
The only problem left is X. The X server consistently crashes loading the 'int10' module every time no matter what I try. It must be an issue peculiar to FreeBSD running in a Virtual PC guest, since it aparently doesn't happen to Linux.
After making any changes to your 10.x kernel extensions, according to various sources, you should remove the files making up your kext cache. The two files are /System/Library/Extensions.mkext and /System/Library/Extensions.kextcache. Remove those two files and they will be rebuilt the next time you reboot. This will fix situations where the driver loads and works, but does not auto-load on reboot, and maybe other situations as well.
I've been in contact with someone at Apple about the JRE test results I posted, and between him and I we've narrowed things down a bit.
In particular, it appears the issue centers around name service lookups. If you call InetAddress.GetByName() with a literal IPv6 address, it works. InetAddress is an abstract base class starting with 1.4.1, and is implemented as either an Inet4Address or an Inet6 Address, and all (most?) of the socket type operations take InetAddress objects and just do the right thing.
However, not everything is perfect. Calling InetAddress.GetByName() with a name that has only an IPv6 address (no IPv4 address) associated with it does not appear to work correctly.
I had to copy a CD (this was at work, and it was an image we owned, so there were no copyright ramifications) today, so I wound up getting a crash course in disk mounting.
disktool is the command line tool for manipulating automatically mounted media, like CDROMs. Before you can use dd to read a CD, you must unmount it. disktool -u disk1s0 will unmount the CD from your desktop. You can then dd if=/dev/disk1s0 bs=2k | dd of=diskname.iso bs=10m will copy the CD into a file called diskname.iso. ISO files can be used by Disk Copy to burn copies.
Once you're done reading the image in, you can use disktool -e disk1s0 to eject the CD.
I don't know where I've been hiding, but aparently Nextel's packet data service has come of age a bit in the last year. Rather than using your Nextel phone to make data calls into your own house/company/ISP (which is slow, costs you minutes and takes an eternity to connect), you can now just use your phone as a connection directly to the Internet.
Of course, Nextel only really supports this on a PC, but it appears to work just fine on *nix machines and a Mac. You have to get your Mac(hine) talking to the phone (Check out the iDen modem script and 232A driver hack), then just tell Internet Connect that the "phone number" is "S=2". All done. I've been getting about 20 kbps or so, with not-great latency. I sort of compare the agregate experience to not-quite-first-generation-Ricochet, but it's the best offer I've had so far...
10.2.3 comes with ssh, but unfortunately, it's not compiled with IPv6 support. This is a shame for those of us with IPv6 networking set up. Fortunately, the folks at KAME have a simple package you can load that will replace your ssh and sshd with the same versions, but with IPv6 support enabled. Hopefully one of these days (one of these updates), Apple will flip the IPv6 switch and save us the trouble. :-)
You can fetch it here.
I don't know why I didn't do this sooner, but I performed my little IPv6 JRE test, and unfortunately, the current developer's preview JRE 1.4.1 does not make IPv6 connections. I'm now starting to feel like Apple really just sort of enabled IPv6 in the OS accidently. :-(
(Update: Be sure and check out this entry for more information)
Did a little more poking around, and I now have a way to get the finder Command-K Connect to server... dialog to use a WINS server. You need to make a file in your home directory called .nsmbrc and put this in it:
[default]
nbns = ip.addr.of.wins
There are probably other useful options to use here as well, but that was enough to get smb://foreignmachine/share to work. The 'detail' view of that dialog box (with the servers that fill in) won't fill in from the WINS server, so you need to know the name of the machine.
One of the things I had a bit of trouble with at first was printing. To make a long story short, it turns out that the built-in Epson driver just plain isn't as good as the Gimp Print
stuff.
Also, in the print center, hold down "option" while you click the "Add printer" button to get more transport options, including SMB printing (Windows print sharing).
There's not much to this trick.
/dev/da0s2 /ipod msdos rw,noauto 0 0
Change da0 to whatever device shows up. mount /ipod and you should see your iPod's filesystem.
camcontrol eject 1:0:0. The 1:0:0 part is the CAM device identifier. That's what mine happens to be. You can find yours by doing a camcontrol devlist with the iPod attached. camcontrol eject will send a SCSI device unload, which is what will get the iPod to spin down.I like the IOGear -232A a lot. It's the smallest possible size for a USB serial dongle (it looks more like a small serial cable), and I bought it originally because it was supported by FreeBSD. IOGear's site only provides a driver for OS 8.x/9.x, however. Bummer!
I did some detective work. IOGear and ATEN appear to be the same company, and the IOGear 232A and the ATEN UC232A appear to be the same product. ATEN's site has an OS X driver (or rather, had. It appears to have been taken down) but I couldn't get it to work right. Something about version numbers. No matter. The chip inside the device is made by Prolific Technology. It's their PL-2303 USB serial controller. They also have an OS X driver for the chip. This driver works, but needs one little tweak:
After installing the package, go to /System/Library/Extensions/ProlificUsbSerial.kext. Edit the Contents/Info.plist file. Change the idProduct and idVendor numbers to match those you get from the Apple System Profiler (for mine, the Product is 8200 and the Vendor is 1367).
Having done all that, you can now kextload ProlificUsbSerial.kext and see /dev/tty.usbserial show up whenever the dongle is plugged in. Enjoy!
The last time I checked, the driver was here, but you should check their technical website for updates.
Update: It looks like the driver is no longer available from the Prolific Technology site. Not sure why. There is another manufacturer that has it available on their site. You want the newer one (right now it's the v106 one). Since they're nice enough to mirror the driver, I would suggest that if you don't already have a device that you buy theirs instead of IOGear's.
Apple released Safari today. Yay! It's a beta, so it's not feature-complete quite yet. One thing missing is that although Safari will check SSL certs on web sites to make sure they're signed by an approved CA, there's no UI for adjusting the list of trusted certificates.
The good news is that the set of approved CAs is managed in a System-wide Keychain file. It's in /System/Library/Keychains/X509Anchors. You can use certtool to add to this list easily. Just take the CA cert in PEM format and pull up a terminal window and type sudo certtool i cacertpemfile k=/System/Library/Keychains/X509Anchors. Simple as that.
I use Nextel's dialup data service to get on the Internet. To get this working on a mac, I had to sort of hack together a modem script. I took the Ricochet one and neutered it a little bit, and came up with this. Unpack it and put the file in /Libraries/Modem Scripts. You may need to speed-lock your phone's serial port to 57,600 bps to get it to work. Having done this, you merely plug the phone's serial cable into any serial port you can get to work on your OS X machine (this entry for the IOGear -232A) and set up InternetConnect in the traditional manner.