The relationship between Dell and Apple has historically been hit-or-miss. Mostly miss. At times the companies have seemed on the verge of a friendly relationship, while more often the strong-headed leaders of each firm have gone public with the extent of their disdain for each other.

This charming interplay will be missed – because 2006 will mark the beginning of the end for Dell Inc.

When Dell gets desperate, they try to imitate Apple. Way back in 1993, Apple had just lost their head of Powerbook Engineering, John Medica, who left to head up Dell’s flagging laptop division. While Dell was out shopping they also picked up Eric Harslem, at that time the head of Apple’s desktop division. Apparently Dell thought they could buy the leaders of these talented groups and walk away with some of Apple’s computer design magic. Medica knew better than this, and immediately upon joining Dell entered into negotiations with Apple to license PowerBook design technology for Dell’s upcoming 486 laptop.¹ I don’t think this deal ever came to fruition – if it had, the Dell laptops might be less of a friggin’ nightmare than they are.

To be fair, the copycat game has gone both ways. One thing Dell has been widely praised for is its manufacturing expertise. The above-cited article mentions in passing Dell’s “totally integrated manufacturing resource-planning system,” which had recently been overhauled with brand-spanking new “logistics, order-fulfillment and quality-control systems.” Taking an early lead in these areas made it easier for Dell to become an early leader in online direct-to-consumer sales. These systems at Dell possessed all the qualities that Steve Jobs, in 1997, must have noticed were lacking in Apple’s own manufacturing operations.

In 1997, journalists were running around patting each other on the back for brilliantly predicting the imminent demise of then-struggling Apple. It became so de rigueur to lambast Apple, that even high-ranking executives who usually act with decorum found it irresistible to launch a hearty guffaw and spittle in Apple’s direction. Such was the case for Michael Dell, when he made the famously arrogant statement that the best strategy for “fixing Apple” would be to “shut it down and give the money back to the shareholders.”² Ouch!

Steve Jobs felt the sting, as well. In a press event held shortly after Dell’s comments were made, Apple announced their own revamped manufacturing and online sales apparatuses. In schoolyard fashion, the event culminated in the presentation of a large graphic of Michael Dell’s face superimposed over a bulls-eye target symbol. “We’re coming after you, buddy,” Jobs said to a titillated crowd.³ At the time, I was 22 years old and working in the Mac OS System Updates group. We watched the event over closed-circuit Apple television, and were charged by the comments. It was true – times were tough for Apple, and we needed a forceful leader. We didn’t want to give the money back to the shareholders. We wanted to kick Dell’s butt!

Dell’s comments have lived on in infamy as Apple has steadily risen from the smoldering ashes of 1997. The successes of the iMac, Mac OS X, and the iPod have made Apple one of the most successful technology companies in recent history. As Apple has healed its wounds, Dell has desperately tried to imitate its success, peppering its product line with Apple knockoffs like the G5-ish PowerEdge 6500 and the Shuffle-ish DJ Ditty. (Actually, the DJ Ditty may owe more to BIC Lighters for its design philosophy.) What’s most intriguing is that Apple’s momentum hasn’t slowed down. In fact, it seems to be gaining with each passing month. Dell was wrong.

But what’s more interesting is that Jobs was right! Apple is “coming after you, buddy.” In 2005, with Apple on the brink of releasing Intel-powered Macintosh computers, Dell has once again taken to making public commentary on Apple’s future. This time, it’s with a distinctly higher level of ass-kissing, as he senses the impending doom of his own company (hyperbole mine). In June, Dell apparently told Fortune columnist David Kirkpatrick that he would be happy to offer Mac OS to his customers (full text subscription only). Yeah, I bet you would! Before your company goes under!

So, when am I going to get to my point about the demise of Dell? It’s pretty simple. I don’t believe Dell can compete with Apple in the consumer PC market. Same goes for all the other vendors whose selling points are “relative ease of use and reliability.” Nobody buys Dell computers because they are cheap. They aren’t that cheap! They buy Dell, or HP, or Sony, because they’re afraid to put together their own computer. These PC manufacturers capitalize on the fact that even PC users want things to be as simple as possible. They don’t want to shop around for graphics cards and hard drives and ethernet cards that work well together. To the extent that the PC world has needed a “good to go” manufacturer, these companies have filled the order. But none of them can fill the order like Apple can.

A much under-discussed aspect of the new Intel Macs is that, as far as I have been able to glean, Apple has no plans to restrict the ability of users to install Windows on the machines. And why would they? That’s the secret weapon! In the market for a new laptop? Has to run Windows? Why buy a Dell when you can buy a Powerbook with all the same abilities, a sexier design, and the added bonus of being capable of running Mac OS X? Apple is about start selling PCs, and the slightest bit of marketing or consumer word-of-mouth about this fact should ignite a huge increase in hardware sales for Apple at the expense of other Intel-based computer manufacturers.

When’s the last time you sat in a room with a bunch of Linux/Unix nerds? Have you noticed what kind of computers they use? Sure, there are a bunch of PC-compatible laptops, but in many rooms I’ve observed that perhaps the majority of these users are using Apple Powerbooks. Why? Because people like nice hardware. Apple gained many of these customers without selling them on Mac OS X. They install Linux, BSD, or Darwin on their machine and otherwise continue their GTK/X-Windows/Whatever lifestyle as they did before. These users are the warning bell for Dell’s collapsing customer base. People who run Windows in 2006 will be doing so more and more often on Apple hardware.

When Apple releases their first Intel-based computer, it will also be the first computer in history that has the ability to triple-boot Windows, Mac OS, and Linux, all with full performance and compatibility. When the computer maker whose designs have been the envy of the technology world for decades suddenly becomes the most compatible player on the block (Apple!?), you’re looking at a dangerous combination.

Let’s imagine a hypothetical analogy. You’ve got all the car makers in the world. The Fords, Toyotas, Porsches, etc. They all make cars, and people don’t love them, but they don’t hate them. They get them from point A to point B, and some of them are even somewhat well designed. Now imagine the “Superlacar” that looks prettier and performs better than any on the market. It’s sexier than a Maserati, safer than a Volvo, and more fuel efficient than a Toyota Prius. The only problem is it runs on corn oil, while every other car on the market runs on gasoline. A small niche of the public buys into the car because it’s just too sexy to pass up. They make excuses for the vats of corn oil they keep in their garage. They argue into the night with Honda owners that the Superlacar is a better choice, because it’s just so sexy, reliable, safe, and (in the long run) affordable. The Honda owner agrees with most of the points, but it’s damn inconvenient to store those giant vats of corn oil! For most people, it’s just not worth it.

When Superlacar announces that, from this day forward the vehicle will run on gasoline, every other car maker in the world is screwed.

Why isn’t everybody talking about this? It could be that I’m wrong and everybody else, who seems to be dancing around like Dell, Sony, HP, Lenovo, etc. are going to stick around indefinitely, is right. I could also just be missing the like-minded commentary, but I’ve seen surprisingly little analysis of just how devastating Apple’s move could be for the existing PC juggernauts.

Andy Serwer raised a question in Fortune Magazine about Dell’s future: “Could this be the end of Dell as we know it?” But his analysis looks only at Dell’s recent slump in the PC market.⁴ Boy, if he thinks Dell is screwed without Apple in the picture, then Dell may be even worse off than I think!

Tim Beyer’s made good analysis of the Apple situation in his Motley Fool article earlier this year. He speculates that Apple’s intentions are “to lure those buying computers from Dell – or Gateway, or Acer, or even iPod partner Hewlett-Packard – into trying a Mac.” Indeed, with Apple-designed Intel hardware on the market, it’s hard to imagine anybody bothering with the “value added” PC manufacturers. They don’t even have to run Mac OS X. If it’s a matter of spending a few hundred extra dollars to have a PC that looks like their iPod and meets Apple’s high component quality standards, they’ll pick Apple over Dell every time.

The icing on this cake? I own a Dell. It was my first experience with PC hardware ownership, which means it was also my first experience with the “privilege” (necessity) of having to buy industry-standard replacement parts when things “just break.” And this is the “user-friendly” end of the PC hardware spectrum? The damn thing sucks. I have to keep a PC around, particularly for porting work that I do from Windows to the Mac, but everything about this box makes me cringe. It’s been a few years since I bought it, so I’m due for an upgrade. But my next PC will run on Apple hardware. I expect yours will, too.

Adiós Dell, y gracias por las memorias.

(Gratuitous Spanish bookends on this article are sin buena razón.)

What I love about the web and blogging is the chaotic and largely egalitarian nature of publicity and “exposure” that the medium offers. In 2005, a computer programmer of modest means can fire up MarsEdit and get a message to the world as quickly as he or she can type it. Some of you who slog through my loquacious posts have probably figured out that I can type pretty quickly. If nothing else, I do get words into the pipe!

But what’s really interesting is the changing nature of the world – the recipients of my words at any instance in time. Unlike the New York Times, the Economist, or Jane magazine, blog readers may come and go in giant or subtle waves of attention and distraction. If you’re using a news aggregator, my “magazine” may show up on your doorstep every few days, but it’s also exceedingly easy to “recycle” it before giving more than a cursory glance at the subject line. The world on day one of this blog was much different than the world today. Tomorrow, I may write the most interesting thing ever penned, while my readers have an especially tough day at work and “mark all as read.” And right at this moment, you’re reading this blog for the first time and we share a particular kinship as I observe the synchronicity of it all.

Every so often, the world gets all shook up, and I experience an influx of new readers – more than I could possibly hope to attract by mere internet inertia. Some pass through town, while others stick around – inevitably adding to the quality of the blog and this microscopic community. Today’s link from John Gruber’s linked list is an excellent example of this. A week or so ago, I got a similar surge from a Stepwise.com link. What’s cool about the “link and surge” nature of blogging is that completely fresh groups of people are pushed into the dark recesses of the internet. A thousand pumps of different sizes bringing writers and readers together who would otherwise never meet. These passers-through bring ideas and observations that sometimes clash with mine and often resonate – just like real life. I’m stoked!

I’m reminded of the comments made by Joel Spolsky in an ITConversations podcast, where he compares the urban studies of William Whyte to online social spaces, arguing that increasing participation improves the “quality of life” on the web in the same way that, for instance, bustling public parks are better and safer for the community at large. Though we all yearn for occasional moments of solitude in abandoned fields at sundown where we can engage without humiliation in sissy meditation postures, most of the time we’re happy to have kids running around screaming and blowing bubbles. It keeps the crackheads at bay.

A modest example of the benefits of participation came from one of today’s new readers. Jan Lehnardt wasted no time in finding and building upon my “Terminal At Selection” script, which makes it a snap to open a Terminal window targeted at your selection in the Finder. While he appreciated the solution I provided, it was more or less useless to him as an avid user of iTerm, a third party (free) alternative to Apple’s built-in utility. He offered his improvements to the script, which I’ve happily accepted and incorporated into the latest revision, available for direct download here. By editing a variable at the top of the script, you can easily adjust the script to work with whichever of the two Terminal applications you prefer.

Thanks, Jan. And thanks to everybody else who has popped their head in for the first time over the past day. I hope you find something worth coming back for, and I look forward to seeing your contributions in comments and email.

I ran into a search problem recently in one of my Xcode projects. Every time I conducted a particular search (in this case, the search term was “CFString”), my screen was littered with a series of cascading Xcode exception dialogs that look like this:

On the one hand, it’s great that Xcode goes out of its way to convey internal exceptions to the user. It means that they are less likely to just “let slide” exceptional conditions that would otherwise show up only in an archaeological dig through the system’s console log. On the other hand, when they spray dozens of them out at me while I’m just trying to search my project, it gets to be a real hassle to close them all after every search.

When I run into these kinds of errors from Xcode, I immediately start thinking of where my latest project backup is. It’s probably some kind of internal project format corruption. The last thing any of us wants to do is trash a project file and start from scratch, so it’s a good idea to keep backups of the project files (probably along with all your other sources, in the Subversion repository).

In this case I thought I’d be curious and try to get to the bottom of the problem. Since each of these dialogs corresponds to a raised NSException inside Xcode, I thought I’d attach with gdb and see what’s going on at the point of exception. This is what the top of the stack looks like while one of the annoying dialogs is being generated:

#0  0x928f9508 in -[NSException raise] ()
#1  0x95464098 in -[TSException raise] ()
#2  0x928f935c in +[NSException raise:format:] ()
#3  0x929c1794 in mutateError ()
#4  0x928e7a00 in -[NSCFString replaceCharactersInRange:withString:] ()
#5  0x928e7968 in -[NSConcreteMutableAttributedString replaceCharactersInRange:withString:] ()
#6  0x928f2a60 in -[NSConcreteMutableAttributedString initWithString:attributes:] ()
#7  0x98fc1004 in -[PBXFindResult initWithBookmark:textBookmarkResolvable:] ()
#8  0x98fc0e58 in -[PBXReferenceBasedBatchFinder reportBookmarks:findable:] ()
#9  0x98fbff3c in -[PBXTextBatchFinder doSomeFinding] ()
#10 0x98fbfd08 in +[PBXBatchFinder _backgroundBatchFinderNotification:] ()

Something to do with bookmarks! Well, I don’t even have any bookmarks in my project. Did I screw something one of those times I hit Cmd-D instead of Cmd-Shift-D to “Open Quickly?” I decide to set a breakpoint on the call to initWithBookmark:textBookmarkResolvable:, along with some exploratory breakpoint commands. I asked gdb to report to me what the bookmark argument looks like (“po” is short for “print-object”, useful for displaying Cocoa objects). I left my “raise” breakpoint, set to automatically continue, so I can tell what kind of circumstances immediately precede it. This is a “trap the thief” technique for pinpointing the misbehaving code. I let Xcode run wild and then look at the logged breakpoint information for clues as to what led to the assertion.

(gdb) b initWithBookmark:textBookmarkResolvable:
Breakpoint 15 at 0x98fc0ed8
(gdb) command 15
Type commands for when breakpoint 15 is hit, one per line.
End with a line saying just "end".
>po $r5
>c
>end

With the breakpoints in place, I return to Xcode and invoke my troublesome search. Looking back at the logged output in gdb, I see the following snippet (newlines added for readability):

Breakpoint 15, 0x98fc0ed8 in -[PBXFindResult initWithBookmark:textBookmarkResolvable:] ()
<PBXTextBookmark:0x08133700:rtn=2:fileRef=
<PBXFileReference:0x05e08d80:rtn=61:65562A49085CB7C5007AD50E:name='HackCFSocketStream.h'>
:timestamp=0:char-range={5485,8}:line-range={5485,8}:<range-type-0>={5485,8}>

Breakpoint 14, 0x928f9508 in -[NSException raise] ()

So, Xcode doesn’t like “HackCFSocketStream.h”? Aside from its obviously questionable name, what has it done so wrong? I take a look at my search results and sure enough, no HackCFSocketStream.h. Not only are the dialogs I’m getting annoying, they represent missing search results in Xcode!

I decide to try to narrow the problem down by doing a limited search on only the “bad boy.” I select the HackCFSocketStream.h file in Xcode’s files and groups tree, and do another search, this time selecting the “In Selected Project Items” scope-limiting option.

Son of a gun! No error dialog. It must be particular to doing a global search. I switch back to “In Project” and search again. No more bug. Gah! I seem to have “fixed” the bug by asking Xcode to limit its search scope to only the problematic file. I tried a few more problematic files, repeating the same identification method with gdb. Same results! Explicitly searching a selected file fixes the bug, apparently forever.

I tried to mix up the procedure a little bit. Instead of selecting the problematic file itself, I select the group that contains it. The bug still exists at this scope, but again, as soon as I select only the problematic file and search, the situation is resolved.

What I’m left with is a situation where I have a painstaking, yet effective method of ridding the project of this bug. Unfortunately, I have to wait until I encounter a search term that finds a problematic file. Then I have to identify the file and go in and do the magic cleansing search.

I suppose I might try to write a script or something that goes through and explicitly searches each file in the project. Will that clean things up? I should probably just revert to a backup project and hope for the best.

Update – More data points:

• It appears that it’s not searching the “problem file” but actually just viewing it in the Xcode editor that causes it to be “fixed.” I guess Xcode is probably reindexing or something when this happens. Rebuilding the index for the entire project does not fix the problem. So I guess I could work around this by writing a script to go through and open an editor window for every file in my project. We’ll see.
• A “problem file” is only problematic for a particular search term (or set of search terms, perhaps). For instance, a search of “text” in my source base causes a failure on a given file, but searching for another term present in that file brings it up just fine.

Update 2: The “fix” achieved by selecting an item is not permanent. It turns out that the error occurs only if the “bad file” is not currently open in Xcode. By selecting the file, it becomes open and stays open until explicitly closed. By explicitly closing the file (Cmd-Shift-W), I am able to reproduce the error again.

Update 3: Case Closed!

My curiosity wouldn’t let me leave this alone, and I finally tracked down the root cause of the problem. I have produced a very simple test project that exhibits the problem. If you’re curious, you can download the project here. Look at the single source file “TestSource.cp” for instructions on how to reproduce. I know enough about this problem now to summarize it in fairly brief form:

I tried to get it shorter than that, but I can’t! So what’s the bottom line? If your source file contains a multi-byte UTF8 character, Xcode mistakenly tallies the bytes instead of the characters when computing the offset into that line. In most cases, this just means that the contextual highlighting of the search result is slightly off, but if the “overshoot” caused by these multi-byte characters causes a search result range to exceed the end of the line, then it causes the very unsavory runtime exception I’ve described in this article.

This is better demonstrated by example. For instance, in the test project I’ve linked to, the UTF8 encoded source file contains a line like this:

Each of those bullets surrounding my initials is encoded in the file by the UTF8 bytes “e2 80 a2”. So what happens if I do a search for “Bullets” in this project? If the file is open, I get the expected result:

But if the file is closed, Xcode is not so savvy and interprets the file apparently on a “byte == character” basis:

See how the emboldened portion of the result is exactly 4 characters “too far?” That’s because the two bullets take 6 bytes, and Xcode assumes that two bullets should take only 2 bytes. The difference is the “slop” that gets inappropriately added into the range.

When the slop in the range takes you beyond the scope of the line, you get an exception. If I search the project for “danger”, I observe the edge case, beyond which no further range can be safely returned for the given line:

Searching for “dangerous” is just that. You’ll end up witnessing one of Xcode’s friendly error dialogs.

In summary: any UTF multi-byte character in your source file steals “safely searchable” characters from the end of the line. If any search in your project yields results that are at the ends of lines with multibyte characters, you will likely witness an exception and fail to see your search in the resulting pane.

Radar 4377633.

Workaround: Save your source files as some other encoding than UTF8. I don’t really know which encoding is best. I guess I need to figure this out. For this particular project, which had become a mish-mash of UTF8 and MacRoman encoded files, I decided to switch all the UTF8 files back to MacRoman. I won’t be able to initialize UTF8 strings with non-MacRoman typed constant values, but at least I’ll be able to search my project in peace!

The main reasons I write in this blog are for the fame and the glory. These will come some day, won’t they? Running a close third is the fact that, as I accumulate entries in this repository, the articles become part of the “Internet Reference Book,” upon which we all rely for “instant and easy answers” to the problems that vex us.

I recently installed a piece of software on my blog that records the “referring site” for people who end up clicking their way onto my blog through another site’s page. It’s been illuminating to discover just how many of these visitors are sent by way of Google or other search engines. In these cases, the particular query the user entered is contained in the referral listing. It’s fun, though a bit disconcerting to see that sometimes people other than myself type “daniel jalkut” into search engines. I also get a lot of false hits – folks I feel sorry for. They were looking for “dog sweater.com” and AOL decided that this entry was the #1 hit. Rude awakening! I also gets lots of knitting hits, and the occasional Perl or UNIX nerd whose query happens to match something I wrote in my mostly Mac OS X-centric posts.

It’s really gratifying to see searches come in where I just know this was the pot of gold they were looking for. One of my most popular posts is the “Automatic Build Sub-Versioning in Xcode” entry. I get about 2-3 search referrals per day for this page, with queries like “subversion automatic build number” or “xcode subversion script.” This is very gratifying because I’ve often been that person searching Google, praying for an easy answer. I like to imagine the person stumbling upon my site and thinking, “Yes! Now I have time to watch Letterman tonight!”

By putting “gems” in my blog as I discover them or become aware of their relative uniqueness, I am also building an archive for my own future reference. If I’m at a client’s office and don’t remember the details of some particularly brilliant tip I posted to the blog, I can just search my own pages and come up with it instantly. Over time these answer boxes serve not only the internet at large, but us forgetful authors as well!

Today I was looking at some enhancements for my FastScripts utility, and I realized I could accomplish something very cool – if only I could get notifications from the system whenever the frontmost application changed. Hmph. No NSApplication or NSWorkspace notifications for this. What am I going to do? I searched the list archives at CocoaBuilder.com for “front process changed.”

A few items down the list of search results, I see an item called “Cheezy Hack To Get ‘Front App Changed’ Events.” OK, so I’m not the first person to run into this. Maybe this will help me out. Wait a minute. I’m the author of the post! It turns out that over a year ago, I figured this problem out. Before I had a blog to put bits of wisdom like this into, I would occasionally post them on lists like Cocoa-Dev.

This post is exactly the type of entry that might end up as a blog entry nowadays. A hard-won bit of wisdom that I want others to benefit from without having to work quite as hard. Thanks to Google and Cocoabuilder.com, it’s part of the Internet Reference Book, even though it predates my blog.

I took a look at my post. It started to ring a bell. I grabbed some of the sample code out of the write-up and searched my FastScripts project for it. What do you know? I’m already generating “front application changed” notifications in the application. I had to add this functionality to make application-specific keyboard shortcuts work. Doy hickey! All I have to do to leverage this into the new part of my application is add an observer for the NSNotification.

It’s amazing that I forgot this so quickly, but a powerful testament to the internet and the concept of personal “idea archives” that I was able to recover the solution so quickly.

Got a good idea? Write it down! Don’t write it down just anywhere – write it down in a Google-indexed web page. You’ll be grateful you did. And so will we!