After trying to find a simple and elegant way to make my applications talk to each other over the network (and being tired of digging through all the socket related C API every time), I found a very nice network abstraction framework.

ThoMoNetworking is completely Objective-C, requires less then ten lines of code to use, and works both on the desktop and on all of Apple's mobile devices (iPhone and iPad). A disk image with the framework libraries, source code, documentation and examples are available from the developers' site. Some of the limitations of the library are also pointed out there, and you should read them before using it.

ThoMoNetworking gives you client and server classes that connect automatically via Bonjour - nothing to do on your side. Pass an object to the server, and it will pop out at the client, and vice versa. If you want, have your object distributed to all connected clients in one go. It couldn't be much simpler. ThoMoNetworking is under an MIT-like license so you can use it in almost any way you want. The full license text is included in the download package.

[crarko adds: I haven't tested this one, but did look through the disk image to make sure the source code was there, for debugging and verification purposes. You may also need to rebuild this if the target SDK changes.]

One feature which is sorely missed by owners of multiple Macs is the ability to easily share their calendars and contacts between their computers. There are third-party software solutions, such as Mark/Space's The Missing Sync, but they cost money. There are also web services that offer calendar and contact synchronization, but they either cost money (such as MobileMe), or they are not completely dependable and compatible (such as Plaxo and Google).

Apple has another solution for you, in addition to MobileMe, and that's to get Mac OS X Server. Among other things, the server edition of OS X has a built-in calendar and contacts server. As of the Snow Leopard version, both are based on the newest standards -- CalDAV for calendars, and CardDAV for contacts. All you need to do from your client computer is to subscribe to the server from within iCal and Address Book, and you are all set for bi-directional sync.

Fortunately enough, these portions of OS X Server are also open-source, and are known as the Darwin Calendar and Contacts Server. The two servers are still separate projects (written in Python and based on the Twisted framework), and are very much under development.

The CardDAV server was only released in early 2010. Consequently, a lot of the installation, configuration and operation is only half-baked, and it takes some work to get to the point of the famous Apple "it just works" (well, they do want you to buy OS X Server). Nevertheless, once you have everything up and running, this is exactly what you get: the most dependable way to sync your calendars and contacts within a local network or over the internet, for free. You can designate any Mac on your network to be the server, and it will serve itself as well.

To help get this working, I've written up a detailed tutorial on how to get both CalDAV and CardDAV running on a Mac, thereby turning allowing you to easily sync contacts and calendars through that Mac.

[robg adds: While I've got the author's permission to replicate his how-to here, the reality is that, at over 8,000 words with a slew of associated images, I don't have the time available to reformat the article for displaying in the macosxhints template. So if you're interested in reading about syncing via CalDAV and CardDAV servers, visit the linked site.

To protect this hint, in the event that the original site ever vanishes, I've also created a PDF from the how-to, and placed it on the hints server: CalDAV and CardDAV how-to (1.38MB). I'd use the linked site first, though, as it's likely to be updated at some point.]

This hint is for people trying to optimise their wireless signal reception in strange places. I recently had to get a wireless network operating over 100 meters away from the base station, and in a metal shed -- not the best environment for microwave communication!

This hint basically does the same job as AP Grapher, but can be run from the command line or over SSH -- so I was able to have someone else carry my MacBook Pro around the shed while I stayed near the wireless router and fiddled with its antennas.

I ssh'd into my MacBook Pro from a computer at the router, and ran the following command in Terminal: This periodically displays the received signal strength indicator (RSSI), basically the power of the microwave radio signal from your router.

The value is in dBm, which is a logarithmic scale so that an increase of 10 units means a factor of 10 increase in power; an increase of 20 means a factor of 100 increase in power; etc. Watching this reading, I was able to position the router and antenna for maximum signal strength at various places in the shed.
The airport -I command alone displays other useful information about your airport connection, like the network name, channel, authorization mode, and the noise on the microwave signal.

After installing the OS X Snow Leopard 10.6.3 update, I found that I could no longer write to Samba (SMB) volumes shared from my Linux server (running Ubuntu 9.10 Karmic Koala) that I had mounted on OS X.

Whenever I tried to copy a file from OS X to the mounted Samba drive, I got this error message:

The operation can’t be completed because you don’t have permission to access some of the items.

To solve the problem, turn off Unix extensions in your Samba server (Ubuntu 9.10 in my case) by adding the following line to smb.conf in the global settings block, and then restarting Samba:

unix extensions = no

You might also need to unmount and re-mount your Samba volumes from OS X after you make this change. More details on what caused this problem can be found in this blog post.

Watching someone else working on his Mac (especially in a bigger network environment with many servers) showed me that not everyone seems to know that there are different types of servers, and different ways to mount them in Finder. And not everyone really uses the best way -- although there is never the best way and everyone has to find his/her way for the best workflow handling. But did you know all the following ways of mounting a server?

Read the rest of the hint for 10 different ways to mount a server share....

One of Snow Leopard's advertised new features is the much more ambitious 'wake for network access' functionality. What was previously a setting only used by geeks and network administrators -- people who readily knew what a 'magic packet' was and how to send one -- has now been expanded and simplified to make it into a feature any user could understand and make use of. A lot of work went into making it just work in any environment.

Unfortunately for those of us who were already happy with the wake on Ethernet access feature as it was in Leopard and before, they fixed what, in our case, didn't need fixing. In Snow Leopard, if you enable waking for network access, your Mac will periodically wake up every two hours (possibly sooner), no matter what. Mind you, it's a special new 'lightweight wake' with the display staying off, and it'll go right back to sleep in about 20 seconds. Still, I absolutely hated the periodic hard drive and fan noise, the apparent pointlessness and wastefulness of it all.

A comment in mDNSResponder's open source code offers some explanation:

we still want to wake up in at most 120 minutes, to see if the network environment has changed. E.g. we might wake up and find no wireless network because the base station got rebooted just at that moment, and if that happens we don't want to just give up and go back to sleep and never try again.

In my case, the network environment is static and only I could change it. I don't use wireless wake, Back to My Mac, or AirPort Extreme's sleep proxy. So how do I turn off this auto-wake feature then?

The open command in Terminal will, when given a vnc://1.2.3.4 (or vnc://hostname) protocol argument, open the Screen Sharing app and connect to IP address 1.2.3.4 (or hostname).

[robg adds: I was certain we'd covered this tip somewhere before, but all I can find is a brief mention in this comment to this hint about dict:// URLs.]

At my office, I needed to find a way to turn of the wireless network when someone plugged in their network cable. I also did not want them to be able to turn the wireless network back on until the network cable was unplugged. I came up with the fallowing solution.

I created a launchDaemon called com.companyname.ethernetmonitor, and saved it in /System » Library » LaunchDaemons: This will watch the System Configurations folder for changes. This folder changes when you plug in a network cable, turn on AirPort, etc. When it changes, a script called turnOffAirport.sh, stored in /Library/Scripts, is run to see if the Ethernet connection has a company IP address:

#!/bin/sh
if ifconfig en0 | grep 155.144; 
then /usr/sbin/networksetup -setairportpower off
else
exit 0
fi

This helps keep the user from grabbing two IPs (our wireless and wired network use the same set of IPs), and also helps prevent a few other odd issues when a user is connected to both wireless and Ethernet networks.

After trying to script the login window multiple ways, I have come up with the perfect solution; this works 100% of the time when tested under OS X 10.4 and higher. We use this to log in computer(s) through Apple Remote Desktop by sending this script to computers sitting at the login window. This is great in a computer lab situation, where you may need to log in all the computers at once.

This method requires the username and password fields, but as long as you have a list of users with "Other..." displayed in the login window, it will work fine. Here's the script: Some notes:

• Initially the script will help "wake up" computers before attempting to go further by simulating a few Down Arrow keystrokes.
• Any computers that are not on the username and password login window screen will be "encouraged" by clicking the Down Arrow multiple times and selecting that option. (It does not hurt anything to run this if the screen is already at the username/password fields.)
• The script will fill in each field, and does not depend on the correct field being highlighted -- unlike other scripts we have seen and used in the past.

[robg adds: I haven't tested this one.]

I connect to my Mac at work quite frequently when I'm home, and I found something interesting. At work, I have a fixed IP address...except when I need a VPN connection to access certain servers that I administer. When I connect to the VPN, I get a different IP address that's dynamically assigned (i.e., I never know the exact address, only the subnet).

Given the snow storm on the East Coast, I worked from home and connected to my Mac at work. I had forgotten to terminate a VPN connection I had going the previous day, but I was able to connect to my Mac anyway, even though I entered my Mac's usual address when I connected, rather than the VPN-supplied address.

Even more startling was that I maintained my connection even when terminating the VPN connection. To confirm, I restarted the VPN connection on my remote Mac, yet I didn't lose my remote session. In the past, I would have to reconnect, hoping I had properly guessed my Mac's VPN-assigned address.

Just another example of thoughtfulness from Apple.