Archive for February 2007

Monday, February 26, 2007 [Tweets] [Favorites]

Experiences in Web Hosting

Paul Kafasis:

Major hosting provider Dreamhost.com had a scheduled but overly-long downtime this weekend, and conversations on Web hosting have come up several times since. At Rogue Amoeba, we’ve gone through a several Web hosts over the years, and seen at least two die off in the process. As such, I thought I’d detail our own experiences with Web hosting, and provide a bit of advice.

I’m currently using DreamHost. I like their features, and the server is much faster than the one I had at Pair, but the recent downtime has been a problem. I wish I could simply pay DreamHost more to get higher reliability.

Saturday, February 24, 2007 [Tweets] [Favorites]

MacBook Pro Woes, Part 3

Friday evening, my MacBook Pro arrived back from its repair. The hard drive was replaced this time, and so far everything seems to be working properly. This was the third repair, and so far the MacBook Pro has been broken or in transit for 31 of the 77 days I’ve had it (40%). Hopefully, those days are now behind me, because when it’s working it’s a terrific Mac.

Thursday, February 22, 2007 [Tweets] [Favorites]

Red Sweater Acquires MarsEdit

Congratulations to Daniel Jalkut who has acquired MarsEdit. Kevin Walzer writes:

…growth through acquisition is especially unusual among solo developers, for no other reason than the substantial capital investment it requires. But if any product represents a safe bet, it’s MarsEdit, which was first developed by Brent Simmons and became part of NewsGator after NewsGator purchased Brent Simmons’ company. And Daniel is an extremely skilled developer: it’s safe to assume that he will be adding a lot of cool features to MarsEdit, making it even better than ever.

Wednesday, February 21, 2007 [Tweets] [Favorites]

Mail’s “Sending…” Source

Pierre Igot:

Once you click on the “Send” button, the message actually disappears from the “Drafts” mailbox, and the “Sent” mailbox changes to “Sending…”

…where is the message that is currently in the process of being sent? It’s not in the “Sent” box, as we have just seen. It’s no longer in the “Drafts” box either, as you can see in the screen shot. (The message count next to it is back down to nothing, i.e. zero.) So where is it? Well, that’s the kicker: It is nowhere. It is not in any visible part of the user interface in Mail.

Tuesday, February 20, 2007 [Tweets] [Favorites]

Selectors vs. Named Arguments

Jesper:

Here’s a very simple proof that selectors aren’t named arguments

Yes, let’s put this to rest once and for all. Objective-C methods have the same kind of arguments as C functions. Objective-C simply uses a syntax that mixes the arguments in with the method name.

Monday, February 19, 2007 [Tweets] [Favorites]

Proof That √2 Is Irrational

Mark Dominus:

In short, if √2 were rational, we could construct an isosceles right triangle with integer sides. Given one such triangle, it is possible to construct another that is smaller. Repeating the construction, we could construct arbitrarily small integer triangles. But this is impossible since there is a lower limit on how small a triangle can be and still have integer sides.

Seven Steps to Remarkable Customer Service

Joel Spolsky:

The second implication of fixing everything two ways is that eventually, all the common and simple problems are solved, and what you’re left with is very weird uncommon problems. That’s fine, because there are far fewer of them, and you’re saving a fortune not doing any rote tech support, but the downside is that there’s no rote tech support left: only serious debugging and problem solving. You can’t just teach new support people ten common solutions: you have to teach them to debug.

Sunday, February 18, 2007 [Tweets] [Favorites]

Memory Barriers

Peter Ammon shows how memory barriers can protect against processor synchronization issues without the expense of locks:

The lesson here is something you already knew, but I’ll state it anyways: Multithreading bugs are very delicate. There is a real bug here, but it was masked by the fact that the kernel scheduled them on the same processor, and then by the fact that the variables were too close together in memory, and once those two issues were removed, (un)lucky timing usually masked the bug anyways.

Friday, February 16, 2007 [Tweets] [Favorites]

xkcd on Lisp

Get thee to a punnery.

Wednesday, February 14, 2007 [Tweets] [Favorites]

C Is the New Assembly

Daniel Jalkut (paraphrasing John Gruber):

He suggests that a typical developer will write everything in Ruby or Python, and then do performance testing. Anything that needs a speed-up can be redone in Objective-C. You know, that “slow” dynamic variant of C :)

This analysis is foreboding, because it’s exactly what programmers have always done when they switched to a higher level language. 10 years ago a programmer would be more likely to “switch to assembly” for a much-needed performance boost. Has it come to this?

Yes, it has. However, I’d like to add a few points. First, while in general it’s true that “scripting” languages are slow(er) and Objective-C is fast(er), this is not always the case. I suspect that common computations using lots of arrays, dictionaries, numbers, strings, etc. are faster in Python than in Objective-C/Cocoa due to less memory management and dispatch overhead. Likewise for text processing, since in the scripting languages the regex engine works directly with the native string type. Of course, Objective-C has the potential for very high performance if you drop below the object level or use Objective-C++.

Second, achieving better performance by recoding in Objective-C doesn’t work quite the same way as recoding parts of a C program in assembly. The difference is the bridge. A hybrid application must be developed with careful attention to bridging overhead, which can be a much bigger performance drain than the fact that the scripting language isn’t compiled down to native code. You must decide early on which areas of your application will use Objective-C objects and which will use scripting-language objects.

If you do everything with Objective-C objects, you can recode select objects in Objective-C to improve performance, but the ones coded in your scripting language (the majority) will be doing a lot of bridging, and you won’t be able to take full advantage of your scripting language because you’re limited to the Objective-C object model.

On the other hand, if you do everything with scripting-language objects you can avoid a lot of bridge overhead (within your own code—you increase the overhead when Cocoa needs to talk to your code), but it becomes more difficult to improve performance by recoding an object in Objective-C. Doing so will make that object locally faster but will add overhead due to the fact that the rest of your code now has to talk to this object via a proxy.

Regular Expression Performance

In this very well written article, Russ Cox explains why most current regular expression implementations have exponential running times for certain patterns, while Ken Thompson’s NFA implementation from the 1960s is linear for all inputs. Cox suggests that the NFA approach is compatible with modern regex features and that this is how regular expressions should be implemented. My hunch is that the current recursive backtracking implementations would be faster and use less memory for most real-world, non-pathological inputs and that they have better engineering characteristics, such as being easier to understand, debug, extend, and modify. Perhaps there are clever tricks that can be employed with the NFA implementation, but I suspect that this is an area where the theory is very nice but doesn’t lend itself to an efficient and modular implementation. Thus, I favor a hybrid approach where the simpler pathological patterns are dispatched to a Thompson NFA and the rest are handled in the normal way. (Via John Gruber.)

Tuesday, February 13, 2007 [Tweets] [Favorites]

MacBook Pro Woes, Part 2

My MacBook Pro arrived back from Apple today. Contrary to what I was told would happen, they did not replace the broken hard drive. In fact, the repair sheet doesn’t even mention the drive. It only says that they re-installed the OS and tightened one of the heat sinks on the logic board.

I called Apple, and the guy kept trying to tell me that if the drive had needed to be replaced then they would have done so. If Apple Hardware Test doesn’t report any problems, then I should consider the Mac fixed. (I’m pretty sure AHT doesn’t scan for bad blocks.) For some reason, he didn’t have access to the report of the repairs that had been done, though he could see that the original problem report mentioned bad blocks on the drive. Eventually he transferred me to a product specialist who immediately understood the problem and said that of course they should have replaced the drive. So Apple’s sending me another box, and we’ll try the mail-in repair again.

Friday, February 9, 2007 [Tweets] [Favorites]

More Fun With Autorelease

Mike Ash:

How many of our apps sit quietly ticking away in the background, accumulating ever larger autorelease pools that only get drained once we bring them forward? It makes you wonder.

Thursday, February 8, 2007 [Tweets] [Favorites]

Breaking the Myth of Megapixels

David Pogue has re-done the test, this time using the zoom on a Canon EOS-1Ds to take photos of the same subject at different resolutions, rather than downsampling using Photoshop. (Also, for some reason the smallest resolution for the test has increased from 5 MP to 7 MP.) I still don’t think this is measuring the right thing. The relevant question is not how a lower-resolution image taken with a high-end camera looks, but rather how the image from a lower-resolution camera compares with the image from a higher-resolution camera. By trying to control for differences in cameras by always using the same camera, the test is failing to measure what it’s supposed to. Before it measured Photoshop; now it measures the zoom lens.

The article’s point seems to be that people with older cameras shouldn’t feel pressured to upgrade to newer (or more high-end) ones. The newer ones have more megapixels, but megapixels don’t really matter. However, accepting the megapixel premise doesn’t prove the point. If megapixels don’t matter, then we should be comparing other factors, such as lenses and sensors. Surely these have improved over the years; they’re just less salient than the number of megapixels. As constructed, the test shows that if you have an EOS-1Ds and want to print at 16-by-24, there’s no need to zoom in on your subject. But if you want to know whether your camera from 2005 is obsolete, you should compare its photos with ones taken by a current camera. The results would only be valid for the two cameras you happened to compare, but at least they would say something about those two cameras. Measuring the zoom on an EOS-1Ds says nothing about your camera or the one the salesperson is showing you.

Purely Functional Queues

Eric Kidd:

Haskell has been tying my brain in knots. Sure, it keeps teaching me all sorts of amazing things, but it’s also forcing me to relearn the basics.

Right now, I’m trying to implement simple data structures in Haskell. It’s challenging, because most typical data structures are based on updating pointers, and Haskell doesn’t allow that.

Tuesday, February 6, 2007 [Tweets] [Favorites]

Thoughts on Music

Steve Jobs:

So if the music companies are selling over 90 percent of their music DRM-free, what benefits do they get from selling the remaining small percentage of their music encumbered with a DRM system? There appear to be none.…Convincing them to license their music to Apple and others DRM-free will create a truly interoperable music marketplace. Apple will embrace this wholeheartedly.

Update: 2lmc spool points out that, currently, people selling their music on the iTunes store are not given the choice to opt-out of DRM.

Cancel or Allow

I think this is one of the better “Get a Mac” ads (via John Gruber). Too bad Apple never made an ad about Abort, Retry, Ignore.

Monday, February 5, 2007 [Tweets] [Favorites]

MacBook Pro Woes

I was excited to get a MacBook Pro in December. The new Core 2 Duo machines are very fast (having four cores wouldn’t matter much for what I do), have a reasonable RAM ceiling, have good external display support, and a 200 GB drive can, as Rentzsch says, hold me. (I apparently have more data than he does, but I don’t need access to different OS versions on the go, so I have those partitions on an external drive.) I thought the MacBook Pro would make a good main Mac, and I would no longer need to synchronize with a notebook, a process that had become more difficult now that my desktop and notebook had different processor architectures.

So far, the switch has been a mixed bag. I liked using the MacBook Pro, but after the first full day of use it wouldn’t turn on, even in target disk mode. The hard drive isn’t removable, but through my extremely good luck it died in the middle of a backup, after all of the changed files in my home folder had been copied. Apple replaced the logic board, and all was well.

About five days later, I started seeing various crashes and freezes while backing up. Sometimes even the Finder froze. After running various repair programs, everything checked out. I zeroed the drive, did a clean install, and that seemed to fix everything.

In mid-January, the freezes returned. DiskWarrior reported a disk malfunction. Drive Genius reported bad blocks. I did a 7-pass zero with Disk Utility, and everything started working again.

A few days later, I started seeing problems with LightScribe. It kept stopping in the middle of burning a label. Everything else remained fine, though.

At the end of January, I started seeing freezes again, but Drive Genius said the drive was fine, and DiskWarrior found only minor problems.

Yesterday, DropDMG reported an error while backing up a particular file, and I found that the Mac would freeze whenever it tried to read that file. I also found that numerous system fonts were no longer working.

Today I ran Drive Genius, and it found some more bad blocks. I decided to send the MacBook Pro to Apple. The guy on the phone was very nice and didn’t ask me to perform any additional tests. In retrospect, I probably should have given up on this drive sooner. He promised that Apple would replace the drive, rather than try to repair it. I’ve written down the drive serial number from System Profiler to make sure. It’s annoying that every time I call Apple they ask if I want to extend my AppleCare beyond the first year.

These problems have cost me time, but I don’t think I’ve lost any data. I’ve been careful to have both clones of my hard disk (made with SuperDuper) and archives of individual folders (made with DropDMG and cataloged with CDFinder). The former are essential so that I don’t waste too much time getting up and running again, and the latter are essential so that if I later find out that a file was damaged, I can go back and find an older version of it that’s not. My really important data is stored in either EagleFiler or Subversion, both of which can verify that the files have not changed since their last known good states. However, while this backup strategy has worked, I did learn some things and recognized the importance of others that I had been less sure about:

  1. You must have a recent clone of your whole drive. I didn’t always insist on this, but it’s such a time-saver. Even if you have backups of all your folders, it takes too long to copy everything back into place. And these days I depend on a lot of Unix stuff for development that’s scattered and thus not easy to backup or restore.
  2. You need SuperDuper and its Smart Update. I like to make complete clones—and for this you don’t need Smart Update or SuperDuper—because (a) I don’t want to depend on the integrity of files that weren’t recently copied, and (b) doing a complete clone is a good way to check that all of your data is readable. It helps spot problems sooner. But, you also need to clone regularly—more than once a day—and SuperDuper can complete a Smart Update while I’m having lunch. rsync is a possible alternative, but it’s still buggy.
  3. You must have a backup Mac that can boot from the clone. Even if your main Mac ends up not needing repairs, you need to be able to continue as normal while you’re checking it. Storage use has increased so much faster than storage speed that it’s easy to waste a whole day running a few disk utilities, re-formatting, and restoring from a clone—if you don’t have a backup Mac.
  4. You need at least two reasonably up-to-date clones. Clone A is newer, and that’s what you’ll switch to as soon as you discover a problem. However, you can’t restore from Clone A while you’re using it, since it’s not a good idea to copy files that are in use. And restoring can take up to four hours, even for a comparatively small notebook drive. So you need a Clone B that you can restore from while you’re using Clone A. Later, you can Smart Update the original drive from Clone A, and that will only take 20 minutes or so now that it’s been primed with Clone B.
  5. The other reason to have two clones is so that you can continue to have two clones. If you’re now using Clone A as your main system, then you only have one clone backup. In order to return to the state of having two clones, you need Clone B so that you can create Clone C while using Clone A.
  6. Software like Drive Genius is good for telling you when there is definitely a problem, but if it reports a clean bill of health, take that with grain of salt. Keep notes of any strange behavior so you can see if it recurs.
  7. Archiving DVDs off-site is a good idea, but you should also keep copies of the recent archive DVDs locally on a hard drive, so that you can access the data more easily.
  8. Notebook drives are slow. Really slow. It’s hard to really appreciate this until you use the same Mac with a different drive.
  9. No matter how silly I’ve felt making more backups than I would probably need, there always seems to come a time when I’m glad that I have them.

Sunday, February 4, 2007 [Tweets] [Favorites]

ReadyBoost

I don’t really follow the Windows world, but I happened to read Peter Lewis’s article in the print edition of Fortune, where he mentions a new feature of Windows Vista called ReadyBoost. If your PC doesn’t have very much RAM, plug in a USB flash drive, and your PC gets faster. That sounded odd, since flash memory—whether in an iPod, a camera, or a USB key—has always seemed slow to me. After reading more about ReadyBoost, it turns out that flash memory is slow at sustained transfers, but that its access time is about ten times that of a hard disk. After all, there’s no platter to rotate and no head to be out of position. Even an iPod shuffle is faster than a hard disk for random 4K reads.

Vista uses the flash memory as a cache for parts of the virtual memory swap file, and this is apparently a big win for small page-ins. It routes bulk page-ins to the hard disk, even if the pages are on the flash, because with large transfers the disk will be faster. Flash drives wear out after a comparatively small number of writes, so apparently there’s also some kind of lazy writeback from the hard disk to the flash, reducing the number of writes so that the flash’s life will be extended to 10 years. All in all, I think this is pretty clever. The funny part is that Windows uses different drivers to connect to Plays For Sure devices, so they can’t be used with ReadyBoost. If you want to use your MP3 player to speed up your PC, get an iPod.

Programmers Don’t Like to Code

Jonathan “Wolf” Rentzsch wrote an excellent rebuttal to Scott “Dreaming in Code” Rosenberg:

Programmers desire to rewrite because they know that after starting with a clean sheet of paper and building it all again, at the end they’ll understand the whole. Programmers write code to learn.…Bad source bases irritate programmers because it shakes their foundation of understanding necessary to solve the problem. I reject the explanation that programmers capriciously want to rewrite code for the fun of it.

Update: also check out the responses he got.

Why You Should Be Using Disambiguated URLs

Simon Willison:

Links to (and within) your site should never, ever end with index.php / index.html / default.aspx / any default directory index filename.

The whole point those defaults is that you can link to the containing directory to see their content, resulting in a shorter and prettier URL. If you’re linking to them directly you’re missing out on a golden opportunity to disambiguate your URLs.

Whither GCC Technologies?

Randy B. Singer notes that GCC’s gccprinters.com Web site is for sale. Are they out of business?

Thursday, February 1, 2007 [Tweets] [Favorites]

Interarchy Interview

John Gruber interviews Peter N Lewis and Interarchy’s new owner, Matthew Drayton:

I’ve enjoyed working on Interarchy, but I have been doing it for a dozen years now, and it is time to try something else. The problem with having a successful program like Interarchy is it essentially stops you from working on anything else that doesn’t succeed as well as it does.

ATPM 13.02

The February issue of ATPM is out: