In Part 1 of Malus Sylvestris Migration I went over some basic differences between Mac OS X, Linux, and Windows. Basic configuration, Application installation, and linking were discussed. In this, the second installment, I intend to cover some more interesting features. These include virtual desktops, configure scripts, and the like.
At the point where I left off, I figured I was pretty good to go. I had Xcode installed, so I grabbed the Thunderbird 2.0b2 source so I could compile it – hacking on Thunderbird is one of my soon-to-be all-encompassing projects.
Unpacking the source was easy: Finder builds in support for .tar.gz and .tar.bz2 files in addition to simply ZIPs. Pretty convenient. Unfortunately, configure bombed when it realized I didn’t have GLib installed. This is mentioned in the Build Prerequisites page, so it wasn’t really a surprise. What was a surprise, however, came when I tried to install GLib. It built fast enough (and by watching the
configure script I learned that my MacBook is still just a 32bit machine. Or at least ints are still 4 bytes long, as are pointers. [As an aside, I later learned that OS X will go all-out 64bit with 10.5, scheduled for October 2007. Can’t wait!]), and
make check indicated that it was functional. But the hangup came when it tried to use the standard /usr/local prefix for the installation. Years of Linux work has taught me that, when in doubt, all stuff goes in /usr/local. OS X, on the other hand, doesn’t even have a /usr/local. This means that users’ default shell settings won’t use it if you create it (it isn’t in the path), and compiling won’t link to libraries there anyway because OS X doesn’t use ELF but instead uses “Dyld” executables. Thus there’s no
ldconfig, and no way to link to stuff in /usr/local either.
Seeing that I’d have to install to /usr made me stop and ponder the gravity of what I was doing. And, more importantly, it made me stop and re-read the build instructions for Thunderbird.
On the page, it mentions
apt-get and a couple package managers; Fink and Darwin Ports. I used Debian long enough to know what apt-get is, and also long enough to know that I hate it. I also used Red Hat long enough to know that rpm is just as annoying. In Linux, package managers for me have been nothing but an irritation. I know how to compile and install packages, and I like to customize my builds with obscure GCC optimization flags just for kicks. Using package managers means someone else did the picking for you. It also means that you’re at the mercy of the package-manager managers’ ability to accurately check dependencies. This has been my biggest problem with rpm thus far. So mentally when I read the part about using a package manager to install libIDL, GLib, and friends I substituted “This step is for morons who use Macs and don’t know how to use compilers, run configure, or anything!” before each sentence. Or, actually, I just skipped over it, figuring that’s what it was talking about. I’m not one of those morons, I thought, so I don’t need this garbage.
At this point I was in a huge cross-roads. I could use /usr, I could build a /usr/local heirarchy and configure everything to honor that (a huge task), or I could use a package manager. I decided to go with D: None of the Above. I asked a Mac-Using Friend, and he noted using Fink for some of his development needs. With anecdotal confirmation of a package manager like that, I figured it couldn’t be all that bad. I grabbed Fink, and away I went.
Fink installs like a normal OS X application. It configures its package management hierarchy in
/sw to keep it separate from all the other stuff on your system. This is nice for emergency cleanup. Apt-get works like it should, though the package selection is a bit sparse at times.
Following the instructions ultimately lead to a working build of Thunderbird. The
configure script found the needed libraries and generated working Makefiles. To take advantage of finally have a dual-core system, I ran
make -j2, and watched as both CPUs chugged along to produce a running build of Thunderbird. Apt-get did its job, which gave me a bit more confidence in package managers on OS X.
Another feature I’ve grown to enjoy from using Linux has been Virtual Desktops. There are applications that do this for Windows too, so it should be possible on OS X too, right? A bit of googling came up with a couple results. I went with VirtueDesktops, mostly because of the lack of other packages support for Intel-based Macs.
Some other utilities were mentioned that I should use. These included a VNC client, Chicken of the VNC, a chat client that I have yet to use, and some other utilities. These all used
.dmg disk images, so I got to see a lot of them. I also noticed something interesting: Many .dmg’s open and have just 1 file, the application. Some have another icon, an Application folder. These usually have background art that suggests that you drag the application file into the application folder. For a while this simply confused me, but then I realized that the Application folder links to the harddrive’s application folder, so you’re really just copying it to the hard drive. This got me thinking about some other application weirdness though.
How on earth do these programs get away with just having one huge file? Surely they aren’t still using Resource Forks and all that junk, right? This mystery disturbed me until I realized that these application files were actually some kind of meta-file. You can open them with a right click, and select
Show Package Contents. This lets you see the pieces that make the application. I like this for design reasons. It keeps the application fairly atomic. It also make uninstallation a snap. You simply drag the application to the Trash, and it’s uninstalled. I much prefer this to Windows’ Registry and Program Files setup. Something always gets missed there. And Linux’s /usr/local usually keeps things sane, but it has its moments as well, especially as stuff installs simultaneously to /var, /lib, /etc, and other obscure places.
Windows file sharing worked well, once I figured out how to configure it. System Preferences, Sharing icon. Then you check “Windows Sharing” and click the “Start” button to enable it. There’s an accounts button to enable/disable individual accounts too. Not bad overall, and Apple certainly went with a more secure default configuration than some Windows machines I’ve seen out of the box.
The included screensaver collection is pretty sparse. There are some pretty good download sites for cooler ones though. The backgrounds are similarly sparse. I assume they do this because they expect you to put your own pictures and media on there to compensate. I prefer a few from Apple themselves, and a couple listed on Phill Ryu’s top 10 list.
Aside from all of the above, there haven’t been any real huge difficulties. Spotlight (“Search” in Windows-land or
locate in Linux-land) is very quick, and also does some pretty hardcore indexing. It’s generally pretty snappy, but high-hit searches can sometimes be annoying since your selection loses focus as new results are queued up. Closing programs will probably forever challenge me. The red circle in the top left corner simply closes the window. It doesn’t close the application. To do that, you have to click the application name on the top bar, and then select Quit. Slowly getting the hang of that, and the Dock is nice enough to indicate what you have running in case you forget.
In the next installment: The sky’s the limit: The Mac experience 1 month later.