So reading a Macbook’s ambient light sensor in Linux is just reading off /sys/class/hwmon/hwmon2/device/light – That seems easy and good, a far cry from having to write a C program.

The problem? Linux’s granularity of the read is way too low.

In MacOSX, the sample program returns numbers in at least the hundreds range. I can see the numbers change if I try very hard to cover where I think the sensors are. I get nonzero readings even in late afternoon when the room is nearly dark. In MacOSX, the light sensors felt super sensitive.

In Linux, the kernel returns an ordered pair like (12, 0) if I turn on my bright spotlights. If you put a piece of tape over the the webcam like a lot of people do, you get something more like (9, 0).

First disturbing thought: No matter what the ambient lighting looks like, Linux gives you zero for the right-hand-side sensor.

Even more disturbing: If I turn on just my regular 60W light I get all zeroes. From Linux’s point of view there’s no difference between no ambient light at all and having about 800 lumens dispersed in a small room. Heck, I get zero even during the day, right next to a window (so I live in an apartment – we get crappy lighting in apartments, but still). Compared to MacOSX, in Linux the light sensors seem so insensitive they are practically useless.

If we get zero even during the day, what point is reading from the light detectors? I can’t even tell night from day, or a darkened lecture hall from a brightly-lit classroom.

Short of reading the kernel source code is there even a way to figure out why granularity is so low?

Months after the thought came up and my first failed trials, I have finally managed to install (so to speak) Ubuntu on my Mac, and I have to say Ubuntu disappoints on many small details. Coming from a pre-GNOME traditional Unix background, that’s some major disappointment I’m talking about. My major disappointment is with the trackpad. With Ubuntu the Mac’s trackpad is barely usable. Right-clicking doesn’t work, even with the ”Accessibility” option turned on. Heck, even single clicking often doesn’t work because the system would register some tiny, stray vertical movement so you would end up clicking the wrong thing. The system also often registers stray horizontal movements (so that, for example, when you’re scrolling through a page the browser would suddenly switch to a different tab, or even a different app). So it seems that the Mac’s trackpad isn’t actually any better than what Windows laptops have; all the perceived usability is in the software drivers and Apple has done a lot of work making sure the drivers are tweaked to screen out stray movements. Keyboard input also disappoints. The ”English (Macintosh)” mapping does not map the non-breaking space, and Chinese input does not seem to work. (Maybe Ubuntu is trying too hard to be “smart” and I need to disable all the modern stuff and go back to xkb and scim… or maybe it’s debugging and bug report time….) It’s also a major surprise to see that Emacs-style editing keys work on MacOS X but not in Ubuntu. With more than one input method installed, simply clicking the input menu would often, inexplicably, switch to a different input method. The Character Map is completely writing-script-based so you can’t pick out punctuation marks and other non-letter symbols; I had to resort to using printf in the terminal to get the symbols I need. All in all a disappointment, and in the meantime I’ll need a bigger (and hopefully faster) USB stick.

I have been having trouble getting Mercurial running on my Mac. Basically, I have been getting this error message:

ImportError: dlopen(/usr/local/lib/python2.7/site-packages/mercurial/osutil.so, 2): no suitable image found. Did find: /usr/local/lib/python2.7/site-packages/mercurial/osutil.so: mach-o, but wrong architecture

So, by chance, today I found out that if I use an account that is different from the one I normally use, Mercurial actually ran. Since this wouldn’t make any sense if the installation didn’t work, the installation must have been actually working, and the problem I had been experiencing must have been the result of incorrect user-specific configuration.

I did a little investigation and it turned out that this line in my .bash_profile was the culprit:

export VERSIONER_PYTHON_PREFER_32_BIT=yes

I have no idea why I had this line or what put it there (or whether I put it there myself and if so why). But now I’ve had it disabled and Mercurial is finally running…

This means getting Pidgin running will now be a distinct possibility…

The past few days have been especially unproductive. My Mac’s hard drive is dying — again, but this time apparently for real. The odd thing is that while the drive is obviously dying, it has logged zero SMART errors. All the usual culprits — reallocated event count, offline uncorrectable, and UDMA CRC error count — are zero. Yet I can’t even get a short offline test to run — it always interrupts at 20% with a “Host reset”. In any case, I managed to finish a Time Machine backup, after getting a large drive and running Time Machine for three days. Then I got another smaller drive, restored the backup onto the smaller drive, and — Voilà… it did not work. Putting the boot into verbose mode showed “Waiting for DSMOS”, which is essentially just a mystery error. It turned out that Time Machine excluded /private/var and so almost 2GB of files were missing. Since the internal disk was not dead yet, I was able to copy all the missing files (plus more missing files in /Library/Caches) to the external drive. This time it finally booted — slower than before, but at least it booted. Getting the “Waiting for DSMOS” mystery solved was major frustration, especially since lots of things in MacOSX are either undocumented or, in single user mode, simple don’t work. Some things are so broken it just doesn’t make any sense: For example, I managed to corrupt the new disk’s HFS+ journal simply by remounting it read-only, then I found that fsck was not able to see there was corruption, nor was able to clear the corruption (if fsck -fy fixed all problems, then it can reset the journal, but didn’t). Clearing the journal required venturing into the recovery disk — which now takes forever since the internal disk is dying — to run the diskutil command, which in Apple’s infinite “wisdom” does not work in single user mode. If you think Apple is just neglecting the command-line interface, then you are wrong. When I first tried to install Lion onto the external drive I gave up after 5 minutes, because I could not connect to my school’s Wi-Fi network. I was able to type in my user name and password, but it was asking me for a keychain user name and password, which in recovery mode of course do not exist. The GUI was just as neglected as the command line. My skepticism of Apple products used to be solely based on their decision to not use X11 as their GUI’s foundation, but this debacle has caused me to become even more skeptical. Their recovery tools are completely neglected — not only the command-line based single user mode, but the 100% graphical Recovery Disk interface. The Mac has turned out to be even less tested than I thought. No wonder the new iPhone has problems; it’s a miracle if it didn’t.

So my attempt to prevent triple beeps has failed. But the temperature control script has been written; maybe somone else will find a use for it. People with Macs that have a ventilation system that actually works, I guess.