Fazal Majid's low-intensity blog

Sporadic pontification

Fazal

Making Mac OS X sleep from the command line

In a previous article, I showed how to use Wake-on-LAN to remotely wake a sleeping Mac. I often log on to my home Mac remotely using SSH via my Solaris home server, waking it in the process. With the default settings, the machine will go back to sleep after a few minutes of inactivity.

I recently changed my system defaults to never make the machine sleep, however, because OS X’s sleep functionality will cause the system to sleep even when active Unix jobs are running, like long compiles. That is because the OS has no way of distinguishing between live applications and background daemons. There does not seem to be a command-line utility allowing the user to put the machine to sleep, however, so I quickly wrote one, using Apple Q&A 1134 as a starting point.

You can download the command and source code (including a Panther binary) here: macsleep-1.0.tar.gz (Tiger and Intel users, see below for 1.1)

Restrictions: this command will only work if the user ID it is being executed from matches the user ID of the currently logged on user (not a problem for me because I have auto-logon enabled).

Update (2003-12-06):

Mike Harris reports another similar utility already exists, SleepNow.

Update (2005-11-30):

Kalvis Jansons suggests using AppleScript and the System Events application introduced in 10.3 to achieve the same results, using the following shell script:

#!/bin/bash
osascript << EOT
tell application "System Events"
     sleep
end
EOT

Update (2006-04-02):

I have rebuilt the program for Tiger in both Intel and PowerPC flavors, as well as a universal binary. The new version is macsleep-1.1.tar.gz. The source code itself is unchanged.

Escape from TiVo

I cancelled my TiVo service today, after more than two years with it. I upgraded to a Panasonic DMR-E80H, which offers more capacity than my old Sony SVR-2000, but the main reason for the upgrade was the fact I have for some time lost any vestigial trust for TiVo (the company). They spam you with advertising in the user interface (one of the items in the PVR main menu is a rotating ad), expropriate a portion of your precious hard drive space for the said spam, track your usage patterns behind your back, and have a nasty habit of disabling features in software releases.

The Panasonic is pretty much a hard-drive VCR with a DVD recorder (well, at least it can automagically determine the time and time zone to avoid the dreaded blinking “00:00”, let’s see how well it copes with Daylight Savings Time). The user interface is not as streamlined as TiVo’s (among other things, it is annoyingly modal and does not have an online program guide or the permament 30-minute buffer that allows TiVo to “pause” live TV), but it is capable of editing recorded programs (i.e. excising advertisements). Its chief redeeming feature is that it is not a networked device, and as such cannot be remotely disabled whenever the manufacturer feels like stooping lower to appease advertisers and copyright pigopolists that seem to matter more than paying customers. It is also unable to send back detailed activity data to be analyzed by advertisers riding roughshod over privacy.

First steps in Medium Format

I bought a used Hasselblad 500 C/M last week. I took my first shots last week-end (this is my first medium format camera, and I had to learn how to load it and process 120 format roll film). Today I installed an Epson 3170 scanner capable of scanning medium format negatives (at the highest quality settings of 3200 dpi at 48 bits, this yields 52 megapixel files weighing 300MB each!). The quality is simply amazing, even more than you could expect with the 4x larger negative area than 35mm. Here is a preview scan of one of the shots (the inner marketplace courtyard, Ferry Building, San Francisco), and a 3200 dpi blow-up of the upper left corner of the frame:

Ferry building

Ferry building

Technical details: taken on 2003-10-24, Hasselblad 500 C/M, Carl Zeiss Planar 80mm f/2.8 CF, Fuji Neopan 400 processed in Ilford DD-X, exposure 1/250s at f/4.

Panther’s Linux pandering

I installed Mac OS X 10.3 “Panther” on my iMac yesterday, after a false start. I prefer to do a virgin reformat and reinstall rather than use the upgrade options, and I made a backup on my WiebeTech Fire800 external hard drive. When that turned out to be thrashed, I thought the installer had reformatted both drives. It turns out there is an incompatibility between Panther and Firewire drives using the Oxford 922 chipset, firmware revision 1.0.2, at least when connecting a Firewire 400 Mac to a Firewire 800 drive. After upgrading the firmware to 1.0.5, everything is back to normal. Fortunately I have off-site backups for most of my files. Normally, I would have a second backup on a drive that I specifically selected because it uses a different Firewire bridge, the Indigita-powered EZQuest Cobra+, but as Murphy would have it, it was back at the manufacturer for replacement after the hard drive in it started failing. Never assume anything…

An interesting thing is there are some changes to the Panther BSD core that are clearly designed to make it more familiar for Linux users, at the risk of breaking things for previous OS X users. The default shell is now bash rather than tcsh. Some userland utilities like tar are now the GNU rather than BSD version. Terminal.app sets the environment variable TERM to xterm-color (it used to be vt100), another Linux idiom. vi has been replaced by vim, a close, but not strictly identical substitute.

Since I burned out of the Linux constant upgrade treadmill in 1993 (after having had to recompile gcc and the kernel three times in a week just to install applications), I appreciate system stability like the one provided by Solaris, and have very mixed feelings about these changes.

Dissecting the ENUM hype

I have seen some hype building up about ENUM (RFC 2916) recently, suggesting that ENUM will finally make Voice-over-IP (VoIP) leapfrog traditional telephony.

First of all, what is ENUM? It is simply a means for a VoIP program like Microsoft Windows Messenger or Apple’s iChat AV to find how to reach a correspondent from a phone number. First-generation VoIP programs required users to enter the IP address of their correspondent to call them, or to use non-standard or semi-standard directory services like Microsoft’s short-lived ILS. Since most people wouldn’t recognize an IP address if it bit them on the nose, this limited the market to geeks or incredibly determined penny-pinchers. With ENUM, if you know my phone number, say (415) 359-0918, or if you use the ITU-T E.164 international numbering standard, +1 415 359 0918, you would find the IP address of my VoIP phone/program by looking up 8.1.9.0.9.5.3.5.1.4.1.e164.arpa in the DNS. This is the reversed E.164 phone number, with e164.arpa tacked onto it, the way you can do reverse domain name lookup of the IP address 198.144.198.154 by looking up the PTR record corresponding to 154.198.144.198.in-addr.arpa. The .arpa is a legacy of the days when the Internet was bankrolled by the US ARPA, now the Defense Advanced Research Projects Agency (DARPA), and cause no little grumbling from people who would rather have a more “neutral” root e164.int.

This is a clever hack, allowing VoIP clients to leverage the DNS infrastructure, rather than building new protocols or even leveraging existing ones like LDAP. Every modern computer from Palm PDAs to Windows PCs to IBM mainframes have built-in DNS clients (although few support the ridiculously over-engineered new NAPTR resource record introduced for ENUM in RFC 2915). LDAP client libraries are nowhere near as widespread. Implementing ENUM is thus relatively easy, in the order of a few days of work at most, assuming the underlying name client software is not hardwired for IP address resolution only. In a similar way, a few years ago a group of young turks unsuccessfully proposed the ITU set aside an international country code for VoIP calls (the decimal IP address would be encoded as a 12 digit phone number). The old ITU proposal addressed the issue of getting conventional phones to reach an IP address, ENUM addresses how to reach a conventional phone number from an IP phone.

That said, while ENUM simplifies some of the logistical issues of managing a federated namespace or numbering plan, the bulk of the effort in transitioning to VoIP lies elsewhere:

  • Making IP phones as convenient as traditional phones (waiting 5 minutes for Windows to boot does not quite qualify).
  • Providing the same level of resiliency as the old network, for instance in case of power failure (when I was in Telecom school, one of our teachers always insisted on the fact when phones fail, people can die because emergency services are not dispatched any more).
  • Providing gateways between traditional telephony and IP telephony, and finding a sound business model to pay for it.
  • Figuring out how billing and compensation will be handled
  • Increasing competition by allowing direct calls when both users are VoIP capable, without having to know this explicitly beforehand.
  • Improving the ubiquity of IP connectivity, specially residential broadband and wireless.
  • Improving IP network quality of service, since Quality of Service approaches do not scale and end up being even more inefficient than the old network.

ENUM does not address the chicken-and-egg syndrome that is slowing VoIP adoption. A significant proportion of telephone calls is now carried over IP, for instance AT&T and MCI have both declared their intent to migrate over half their voice traffic to IP by 2005. But that is invisible to end-users, and not accessible – you won’t be able to dial an AT&T user by the IP address AT&T uses internally for them. AT&T will not give it to you because then they would not be able to bill you for it the way they can bill other telcos with interconnect agreements.

As the global E.164 numbering plan is controlled by the ITU and delegated to Telcos, ENUM will not by itself make it possible to create new phone numbers that are not controlled by Telcos. A competitive service provider could petition to obtain a number range, the way Vonage obtained US phone numbers for its VoIP service, but telephone billing has assumptions on the structure of phone numbers deeply embedded within it, probably inextricably. After all, it has taken carriers over ten years to learn to bill calls towards mobile phones in Europe differently by detecting they have a leading 6 digit.

Conceivably, the ENUM NAPTR resource records could be served from any domain name, not just one under e164.arpa. One could imaging that in the future, instead of giving a nineteenth-century style phone number (the first Strowger automatic phone exchange was installed in New Haven, Connecticut in 1891), you would give out a domain name (“call me at fazal.majid.info“) or something that looks like an email address. But that is not what ENUM offers (today), in part by design.