Devices

Start Directory Service debug logging automatically after the next restart on Mac OS X

There can be times when you need to troubleshoot Directory Services in Mac OS X during system starts up. Directory Services apparently sits above and below the kernel — depending on what each of those components needs to do — so having debugging capability early on in the boot process can help you hone in on problems.

To enable debug logging at startup, run the following at the command line:

$ touch /Library/Preferences/DirectoryService/.DSLogDebugAtStart

… and then, on the next restart, debug logging will be enabled. This is equivalent to running:

$ sudo killall -USR1 DirectoryService

… but the advantage is is that debug logging begins at startup, rather than whenever you can log in and start it manually.

Remove the file from the path above when you want to disable the logging for the subsequent restart. As a file whose name starts with a dot, you won’t see it listed by default in the Finder. (The Finder hides dot files by default.)

$ rm /Library/Preferences/DirectoryService/.DSLogDebugAtStart

When I ruled the world?

Does anyone else think that Apple has some ulterior motive for promoting Viva la Vida, the track on the new iTunes ad featuring Coldplay? That maybe its lyrics are indicative of something going on at Apple?

“When I ruled the world,” indeed.

No matter. I find it a fantastic visual treat and now the haunting music is stuck in my head. I would not be surprised if it were featured at WWDC 2008 in a few weeks.

Flat panel wake up and on screen display delay

Now that I have my dual-monitor Gateway FPD2485W setup, I’ve got a few complaints. Of course!

The two monitors take an awfully long time to wake up from their power-saving mode. Then, when they finally wake up — invariably at different times, the newer one first — I get the on-screen display (OSD) overlay telling me that they’ve chosen to accept the DVI input.

Well, duh, that’s the only video source hooked up to them, so it’s not helpful. This wouldn’t be so bad, but the OSD overlay stays on the screen for what seems like eons. Since the overlays are smack dab in the middle of the screen and are opaque, they block important visual elements like Mac OS X’s login window.

So far, I haven’t been able to find out how to get rid of the OSD overlay. If I could do that, I think I’d tolerate the wake up delay more readily.

Certainly, some of this is Gateway’s fault. I guess I can’t blame them much since they specifically don’t support Macs and that’s what I’ve hooked the flat panels up to. I could have gone with some brand that did advertise Mac support, but I didn’t. This must be my payback. Grin.

Get the UUID for a Mac with ioreg

UUIDs, used throughout the rest of Mac OS X for identifying disks and users and groups and whatnot, have now become the unique identifier for ByHost preferences. Or so I’ve been informed, in this article on the topic at AFP548, which told me that Ethernet hardware addresses are no longer en vogue for this purpose in Leopard.

So, to get the UUID for your Mac you can do the following step suggested in the article:

$ ioreg -rd1 -c IOPlatformExpertDevice | grep -E '(UUID)'
"IOPlatformUUID" = "10703BFC-6664-40C5-9331-E73FCE2C2E29"

Let’s expand upon this for a moment. Switch that grepping over to awk, and you get:

$ ioreg -rd1 -c IOPlatformExpertDevice | awk '/IOPlatformUUID/ { print $3; }'
"10703BFC-6664-40C5-9331-E73FCE2C2E29"

Note that you can strip the quotes in the same manner I did with serial numbers from ioreg:

$ ioreg -rd1 -c IOPlatformExpertDevice | awk '/IOPlatformUUID/ { split($0, line, "\""); printf("%s\n", line[4]); }'
10703BFC-6664-40C5-9331-E73FCE2C2E29

Well, that’s it. I’m not going to launch into any long performance analysis of this … at least, not right now.

To get Mac serial numbers in scripts, is ioreg or system_profiler faster?

This is not your average post about how to get the serial number for your Mac from the command line or a script. Instead of showing how to do it, I’ll examine a few ways you might do it with via the provided UNIX shells, and compare how quickly they run.

There are two major ways I’m aware of to get the serial number of a Mac from the shell: the ioreg and system_profiler utilities. The output of either generally needs finessing to be useful — at the very least, you’ll want to narrow down the results to just the serial number if that’s all the data you need.

(However, if you need more data, don’t prematurely optimize for speed. Calling either tool multiple times without caching the results would likely result in a performance penalty. I would suspect this would get worse if you’re calling one of the shell tools from within a Python or Perl script.)

Note that both shell tools require that your motherboard have a serial number assigned to it in order to show it to you. (You may not have this on a particular Mac if its motherboard has been repaired by replacement and your Apple Authorized Service Provider did not flash it with the serial number.) If you can’t see a Mac’s serial number in the “About this Mac” dialog box, you shouldn’t be able to read it with these other tools, either.

Let’s start with the ioreg utility.

$ ioreg -l | awk '/IOPlatformSerialNumber/ { split($0, line, "\""); printf("%s\n", line[4]); }'
W55512LPW3K

I realize you could get away without the printf statement but I kind-of like to make sure my output is formatted.

You could do the following, but it doesn’t return the raw serial number. Instead, the results are returned surrounded by quotes. (This is what I got off the MacEnterprise list, in a post by Dennis Lorenzen.

$ ioreg -l | awk '/IOPlatformSerialNumber/ { print $4; }'
"W55512LPW3K"

I found a negligible speed difference between various versions when I ran them with time, so stripping the quotes and using printf appeared to be reasonable. The extra processing arguably returns better output.

Most of the work appears to happen in ioreg. For example:

$ time ioreg -l | awk '/IOPlatformSerialNumber/ { split($0, line, "\""); printf("%s\n", line[4]); }'
W55512LPW3K
ioreg -l 0.10s user 0.14s system 97% cpu 0.252 total
awk 0.01s user 0.00s system 5% cpu 0.250 total

You can get the same result with similar performance via system_profiler. I actually didn’t expect that it would compare favorably, but it does. Here, I’ll use another example posted in that MacEnterprise thread:

$ time system_profiler SPHardwareDataType | grep "Serial Number" | awk '{ print $3; }'
W55512LPW3K
system_profiler SPHardwareDataType 0.04s user 0.04s system 29% cpu 0.263 total
grep "Serial Number" 0.00s user 0.00s system 1% cpu 0.262 total
awk '{ print $3; }' 0.00s user 0.00s system 1% cpu 0.260 total

But if you optimize a bit to eliminate the grep step — because it is superfluous if you’re already calling awk — you do get the fastest results I’ve come across. It’s worth noting that they have been variable results, especially but not always between the first time and subsequent runs. So, I wouldn’t be surprised if there was some other caching or other mechanism at work that helps make speed this method along.

$ time system_profiler SPHardwareDataType | awk '/Serial Number/ { print $3; }'
W55512LPW3K
system_profiler SPHardwareDataType 0.04s user 0.04s system 51% cpu 0.156 total
awk '/Serial Number/ { print $3; }' 0.00s user 0.00s system 2% cpu 0.155 total

Credit goes to the discussion of this topic on the MacEnterprise mailing list, but if you Google for the topic you’ll find a lot of hits and helpful information. I did a little bit of extra editing in awk to strip the quote marks and time the execution for the ioreg version. I’m also happy I did the timing so that I know that the system_profiler route does appear to be the quickest in overall execution and low in CPU usage.

Rick Falkvinge on mixing DRM and law

Rick Falkvinge responds to the European Commission about the inadvisability of mixing DRM and law (in English, despite the preamble in Swedish, even though he is the “founder and leader of the Pirate Party movement and leader of the Swedish Pirate Party”).

[Via Waffle.]

MagSafe power adapter is not?

If you read the reviews of the MagSafe power adapters on the Apple Store, many people are talking about their connectors fraying, melting, and otherwise developing dangerous damage. Quite a few of those posting reviews seem to want a recall.

I carry one of these around, so it’s worrisome.

I wonder how prevalent this problem really is. The power adapters are one of the lowest-rated items I come across in the store and they are heavily reviewed. Out of 471 reviews for the 85W model, the average is two out of five stars.

It is what is left in your pocket

I told Mike, via Curtis: “MacBook Air: It’s what left in your pocket if you buy one.”

I don’t like this price, $1799. Although it may sell, I don’t see the value proposition. At a different price, maybe.

I’m sure it’s really cool in person and a status symbol type of product … but we’ve had one of those in the Mac lineup already recently, and it was called the Power Macintosh G4 Cube. (I was there at the keynote when it was introduced. I have the “actual size” poster. I’ve got a Post-I™ on the poster which adds “Actual product lifespan: 11 months.”)

Maybe Apple’s recent history of defying sense and logic with its increasing sales will continue with this notebook. They sell more Macs than ever before, after doing very little to update the lineup since before the Intel Macs debuted. I don’t get it.

I want Apple’s system prices to go down, rather than up, but they’ve gone up lately. In 2008, we’ve seen a thin $1799 laptop, and an eight-core Mac Pro that costs $300 more than it did last year.

The MacBook Air also has an interesting set of compromises: no FireWire, one USB 2.0 port, no built-in Ethernet (although with a USB Ethernet adapter optional), no accessible components, and integrated battery. It’s almost a sys admin’s nightmare, unless I’m missing something.

Oh, and boo on the new acronym: “MBA.”

My online sales chat regarding the new Mac Pro models

I spent some time with an agent on the online sales chat in the Apple Store last night. I had a few questions about the new Mac Pro models, and I got some interesting answers quickly. I’d recommend using the online sales chat if you have questions about your Mac purchase.

First, I wanted to know if both the Radeon HD 2600 XT and the GeForce 8800 GT had display rotation support. This is more useful to me now that I have a display that can rotate. As it turns out, both cards do support this.

Second, I asked about the AirPort Extreme card, which is a BTO option, because I wanted to know if it could be added later as a customer installable part. (Some items are not installable in Apple computers by customers, unless you want to void the warranty. The list of items varies by model and you can never assume that even commodity parts like RAM and hard disks are CIP. To my knowledge, there’s no Apple Web page that collects this information.) The Wi-Fi card can only be added at build time, or by an Apple authorized service center later. On the plus side, I noted in the specs that it supports 802.11n as well as the a, b, and g standards.

As for the increased cost of the Mac Pro’s only off-the-shelf configuration, the agent did bring up that the minimum RAM had been increased to 2 GB, the default hard disk had grown from 250 to 320 GB, and the processor had jumped from a dual 2.66 to a quad 2.8 GHz CPU. These are all fine and good, but the model that was for sale on Monday was the same model that went on sale in August 2006. Due to the relentless march of technological advancement I’d expect something better in January 2008, and not necessarily with this price increase.

I’m still going to wait to see what comes out at Macworld Expo next week. The price increase on the Mac Pro makes me wonder whether room was being made for something new between the professional tower and the Mac mini / iMac models. I’m still one of those people who remember with fondness that at one point, Power Mac G4 towers were reasonable options for home computers, with a starting price around $1199. Ever since the Power Mac G5, this economical option for an expandable system has been lost.

Those who count the votes

Contrast this story at Daring Fireball, refering to this “Can You Count on Voting Machines?” story at the New York Times, with this article from our local paper regarding New York State’s tardiness in complying with the Help America Vote Act. Choice lines in the first two graphs:

“State officials took another step in New York’s slowest-in-the-nation process of implementing an election-modernization law by filing a court-ordered timetable for having accessible voting equipment by September of this year and replacements for lever voting machines by fall 2009.

Board of Elections officials, who were excoriated by U.S. District Court Judge Gary Sharpe last month for running afoul of the Help America Vote Act, said the plan calls for the board to decide Jan. 23 which machines counties can choose for the disabled.” [My emphasis, especially on “excoriated.”]

I’m all for accessible voting machines, if indeed our level-based ones and whatever alternatives are offered are not sufficient. But I’m a computer person, and as in the Daring Fireball commentary, I’m generally against implementing these new electronic voting systems just for the sake of having something new. There seem to be major problems with the systems that have been in the news, and I have a hard time wanting to lay our democracy on them at this time. Therefore, I have to wonder if New York State’s delay isn’t actually for the better.

(I wish I had a link handy at this very moment for the simple paper-based system I came across a few months ago, which sounded like a great solution that allowed anonymity, automated counting, and a verifiable vote.)

Syndicate content