I’ve been using Lobotomo’s Fan Control preference pane and daemon to control scud’s fan speeds since I installed OS X.

It’s useful because it means you can idle with quieter fans in a cool environment, but still have them rev up to max before you burn your fingers. However, one thing that’s annoyed me for a while is that you only really control the floor and ceiling thresholds of a linear response curve.

In my experience (engineers or physicists can correct me), at a constant CPU load, there are multiple equilibrium temperature/fan-speed combinations, but they’re not collinear. In the original Fan Control, the response curve is linear. Taking a hint from gamma correction, I have patched Fan Control 1.2 to use an exponential curve. Where T is the temperature, the target fan speed F is governed by the equation:

I also reduced the minimum upper threshold temperature to 60˚C.

You can browse the source in git or download the binary installer. I’ve only tested on scud (running Leopard). Feedback is welcome as comments here on the blog.

exponential curve screenshot

Of course, there may be more effective measures to combat a hot macbook pro.

try figuring this one out with bleary eyes

My personal favourite terminal font, neep alt isn’t readily useable from OS X.

None of the Proggy fonts are as clean as Monaco, although Proggy Tiny 11 comes close.

• lower-case “a” should be double-storey, so it doesn’t look anything like lower-case “o”
• zero “0″ should be slashed
• lower-case “l” should have a serif on the bottom like lower-case “t”, and not look like numeral “1″ or upper-case “I”.
• upper-case “U” and “V” differ by at least 7 pixels
• gentle curves rather than blocky rectangles, please

It’s disappointing that Monaco can get so much right and get lower-case “a” wrong. Still, if anyone wants to port neep alt to a format OS X and iTerm can handle (even if it’s only at 13pt semicondensed)… I tried once with fontforge but it was pretty broken.

The scary thing is that when searching, I blindly fell into the pool of ignorance displayed in this circa-2004 Cocoa-dev thread. To be fair, the OP was more concerned about iterator functionality than a list implementation, but most of the responses seemed oblivious to:

• The iterator design pattern
• The time-complexity advantages of a linked-list implementation over arrays and deques (NSArray) and hashes and trees (NSDictionary and NSSet)

Take Nicko van Someren’s insertion:

Building a doubly-linked list requires the object to gain forward and backward pointers and the only way to do this in Objective-C is to subclass the things you want to list. The problem is that the type system in Objective C is much more dynamic than in C++ and people are therefore far more inclined to write code that neither knows nor cares about the type of object that gets passed in. An initial reaction might be to build a linked list of some sort of node class and have each object in the list hang off a pointer in the node, but this does not really do what you need since it’s hard to work out which node refers to a particular object. So, all in all building code in Objective C to make generic lists of all subclasses of NSObject is a bit of a pain.

WTF? First of all, of course adding iterator functionality to member types is silly. He seems to dismiss the second approach (list of nodes, with pointers to members) for an even sillier reason. What does “it’s hard to work out which node refers to a particular object” mean? He’s still hung up on members having inverse awareness of their container. That’s what the iterator is for, damnit!

I think Pandaa said it well:

I strongly suggest everyone who contributed to this confusion read up on basic computer science.

So I guess not all Cocoa developers are oblivious to DSA.