So Apple’s new music store sells songs for 99¢ per track. That sounds suspiciously like a micropayment (or at least a “minipayment”) system to me. Lots of excellent insite into CC based payment systems deleted — seriously, go read the article! [ Tales from the Red Shed]

I had been wondering the same thing since Apple launched the store– how did the work out a reasonable mini/micropayment system. Having actually purchased a couple of items now, I have noted a significant delay– upwards of 10 hours– between purchase and arrival of the email “for your records” receipt.

That delay may simply be due to the overwhelming purchase traffic through the store (let us all hope so!) or it may be because of some of the purchasing scenarios described in the aforementioned article. I have no idea.

In the Fortune article it is mentioned that the record company takes an average of 65 cents per track sold. That leaves an average of 34 cents per track to cover expenses and make some money. Likely, a big expense is bandwidth and one of the best ways to eliminate rampant consumption of bandwidth is to limit the customer to one-download-per-purchased-item (as they currently do). However a 34 cent/song margin is large — large enough to support a big chunk o’ transaction charge being shipped off to the CC company.

However, there is a another reasonable scenario under which Apple may be operating to support a micro/mini-payment based store.

In particular, the credit card companies have long recognized that micro/mini-payments are a potentially huge market. Not only does the customer desire the convenience of being able to use a CC to make small goods/services purchases, but micropayments often lead to the customer decoupling the act of making a purcahse from the act of paying the bill. This has long been a powerful marketing ploy — if you can successfully get the consumer to stop considering consuming your goods/services with paying a quantitative amount of money, there is less hesitation to consume.

The credit card companies have been investing billions of dollars in building huge networks that can handle potentially 10s of billions+ transactions/day where every transaction must be cleared in a matter of seconds. (There was a really interesting article on all of this in a recent Forbes, but I can’t find an URL.)

Clearly, it would have been in Apple’s best interests to have approached the credit card clearing companies with a proposal to work out a deal that would support the implementation of a micropayment based purchase/payment model. Any reduction in the extremely high transaction costs that are the tradition– the very same costs that are designed to discourage people from making lots of small transactions– would contribute greatly to Apple’s profit margin on goods sold through the music store.

Similarly, the launch of the Apple Music Store has the unique characteristics of making a really huge amount of media noise while being accessible only to a niche market [Macintosh owners with a US billing address]. At least initially. This provides an excellent opportunity for the companies involved to gauge the public’s reaction without actually having to commit to a stupendously large potential market.

If the reaction to the Mac specific store is good [and it seems to be], then the entrance into the much larger Windows (and others) markets can be done with the confidence that the micropayment model– something that is very attractive, yet very scary, to the conservative consumer credit industry– has been proven both from an implementation and a public-relations standpoint.

I have no doubt that rolling out a Windows version of the Apple Music Store is rife with technical uncertainties that are way more difficult to deal with than on the Mac side, but that does not out weigh the potential business advantages to doing so. As well, choosing– consciously or by circumstance– not to address the insanely difficult/complex/political issues associated with distribution of music-by-wire into non-US markets has significant potential business advantages, as well.

If the Apple Music Store is successful in its focused initial incarnation, it will provide a tremendous source of negotiating leverage when it comes time to open up new markets. Obviously, the Windows market in the US was already announced “before the end of the year” and is on the path to release.

However, there are certainly still some legal & technical issues to be resolved. Will Apple continue to use their own DRM or will they integrate tightly with Microsoft’s DRM APIs and policies? If they choose to go with the Microsoft based DRM, how much can they affect the provided rights prior to release?

If the Mac/U.S. store is a rip-roaring success, said negotiations can be carried out with a result much more in Apple’s favor.

Likewise, solving the overseas distribution problem will be far easier if the interested parties– media, religious, and political– can see that profit is just a matter of implementation and not a question of whether or not anyone will buy the product.

It will be very interesting to see how the Apple Music Store evolves. It is amazing that Apple was able to negotiate all of the different distribution rights and payment rights that must have been required for even the 200,000 songs that are in the store now. Of those albums for which only partial downloads are available or for which a number of songs can be bought only with the full album, I wonder how much of that decision was actually dictated by the rights/distribution deals that had been worked out?

Slight digression: In particular, every unique performance of a song is an individual sound recording that may carry its own intellectual property characteristics that can be different than the other songs on the album. Every time a song is performed at a live show, that performance of that song is a new sound recording. Given guest musicians, union rules and venue, the set of property rights associated with a particular sound recording may be quite complex to resolve and achieving the rights to distribute might be prohibitively expensive. The ℗ symbol means “sound recording copyright” and implies that the particular performance of the particular song carries its own set of intellectual property rules that may be different than any other performance of that song. To further complicate matters, the song’s lyrics and score may have different copyrights that affect the sound recording copyright. Playing live ain’t all about jamming on stage with your closes friends– if some random person hops on stage from the audience to play two notes on a harmonica and you suddenly might find yourself without the ability to actually sell a recording of that portion of the performance. (Yes, I did spend some time in the distribution end of the recording industry).

Apple has certainly solved a bunch of problems that no other company had solved in a single package (a number of other products exist in this space– and some have seen some success… it is way too early to tell how Apple’s track record might compare). However, a lot has not been said. Historically, it will be interesting to see how the store contributes to the corporate balance sheet– to see how successful the Music Store really is. Looking ahead, it will be fascinating to see how the success of the store is leveraged by Apple into more opportunities and used to open new markets.

Of course, Apple is not the first to make a foray into a digital delivery based media market. Nor will they be the last. How other companies leverage Apple’s success– be it fiscal or purely technical, in the end– will make for some very interesting markets and business models in the coming years.

What is prebinding and when does it need to updated?

Bill Bumgarner

Really Short Answer

Under 10.1, prebinding never needed to be updated on anywhere as regular of basis as a lot of people assumed.   The only time prebinding information would be out of date is if you installed an application on the boot volume via drag-n-drop.  In that case, only that application’s prebinding information would be out of date and updating the prebinding would only affect the freshly installed app’s launch time.

Under 10.2, prebinding information is automatically updated as a normal part of system operation.  There is no need to ever manually update prebinding information.

Currently, most of my day is spent in OpenStep 4.2 working on porting a Very Large Body of Code from NeXTSTEP 3.3 to OS X / Cocoa. My current task is converting the NIB files from NS to OS as OS X can open OpenStep NIBs, but not NeXTSTEP NIBs. To complicate matters, the apps to be ported made relatively heavy use of InterfaceBuilder Palettes that are not going to be ported (obsoleted by new API). So, the port from NS->OS of the NIBs is actually not just a straight conversion as I’m also converting objects on the fly from one object model to another.
Very interesting stuff, really.

As we no longer have any Intel hardware that can run OpenStep, I’m running OS 4.2 under VPC for windows. It is faster than the native OpenStep-on-Until box I used 5 years ago. By jumping to full screen mode, you can’t even tell that Windows is the host OS!

Furthermore, it is possible– even easy– to configure VPC to allow the OpenStep box to have its own separate IP address. Once done, configuring OpenStep is exactly the same process it has always been (i.e. easy).

So, I’m no logged into an OS 4.2 box running under VPC that is mounting my home account, has all of the environment variables and defaults, etc.

Works flawlessly. Quite the retro-computing experience!

It is obvious that the incredible noise that the RIAA (and, now, the MPAA) are generating in regards to the supposed ‘rampant piracy’ of music via the Internet– the supposed bazillions of $$$s lost– is just a show to distract the world from some other ploy.

I was in the China Town area of Manhattan a few days ago. Had some awesome soup dumplings and other delicacies at a hole in the wall that few tourists ever visit– ping me if interested.

While walking up Mott street to Canal– then a couple of blocks on Canal to the subway stop– I passed at least a dozen street vendors who each had several hundred CDs for sale. All were current hits and weird collections. All were $10/one, 3/$20, etc and everything was negotiable.

Unless the record companies have started distributing shoddy quality– lots of poorly aligned/printed K cards and booklets– loosely packaged CDs, most of the CDs were pirated copies.

In my 5 minute walk, I probably saw close to 2,500-3,500 CDs for sale and most of the vendors wer in the process of making a sale.

Now, of course, the copy protection “schemes” that the industry has used so far will do no good in this situation. To bulk copy that many CDs requires professional level equipment — the kind of stuff that is perfectly happy copying whatever the hell happens to be on the disc, red book compliant or not.

There is no proof– considerably proof otherwise– that downloading a song or album represents a lost sale.

Evidence and common sense would indicate that, if someone were willing to pay $10 for a pirated copy of Britney Spears latest dribble that is packaged to look somewhat legitimate, that individual is pretty much guaranteed not to drop $18 on a real copy.

Until I see any evidence that the RIAA/MPAA actually cares about real acts of theft of their materials that happens every day on the street corners of major cities around the country– as well as through mail order and online– I cannot take anything they say regarding piracy through downloads even remotely serious.

This is a response to a message posted to the cocoa-dev mailing list. It contains a bunch of URLs that I need to remember across new environments and, as such, I thought I’d blast it into Radio so it goes on my “permanent record”

On Saturday, April 27, 2002, at 07:54 AM, Mark Weinstein <markfoo; wrote:

I am a software developer in the Seattle area and have recently moved from the Windoze platform over to the Mac and have several observations that I would like to make. Please understand that I am not flaming Apple (or anybody else for that matter), but it makes it much easier to understand why software developers don’t flock to develop for the platform.

Heh… I would imagine that whole ‘other 95%’ thing might has something to do with it, as well. Having been a long time NeXT developer, the Macintosh software market seems positively huge in comparison. Kind of like the difference between potential Windows customers and potential Macintosh customers.

(I stuck with NeXT and, now, OS X because– frankly– sitting in front of a Windows box makes me nauseous in fairly short order. I would have to replace far too many keyboards to even ship a single app.)

1) I have been a software developer for a little over 20 years, and never in my life have I seen such poor documentation. I have attempted to work with Cocoa, Carbon and even WebObjects and have found that any documentation that I have found that was even worth reading was not from Apple. In addition to the quality of the documentation, it is nearly impossible to even find anything more than quick samples here and there. If people are being actively recruited as developers, why aren’t they getting any support or training out of the recruiter?

Microsoft’s documentation and their developer program is certainly impressive in both the sheer volume of materials they ship you and the quality of a lot of the documentation. My experience over the last 20 years of development work has been a bit different. Microsoft provides excellent documentation, Apple provided excellent docs up until the introduction of Carbon, Rhapsody and the precursors to OS X.

In the early days, NeXT provided excellent documentation, as well. Not only did you have reams of straight reference materials, but NeXT provided excellent concept and architecture documentation.

As OS X has evolved, the documentation has improved immensely. These days, finding the appropriate documentation is more of a challenge than anything else. There is actually a fairly good reason why the docs have been lagging for some time and are just now starting to catch up (not that I’m attempting to make excuses for the state of the docs, simply that I can understand and even sympathize with the state they are in).

Namely, the Cocoa, Carbon, and WebObjects SDKs had been moving sideways until relatively recently. Cocoa is fairly solid these days, but Carbon and WebObjects is changing and evolving in fairly significant ways. Because of this, any documentation written against these APIs often must be massively revised with any major release.

Given the nature of the documentation– highly technical documentation that requires heavy engineering involvement to produce– it consumes a tremendous amount of engineering effort to keep everything up to date. Unfortunately, engineering resources are not cheap and time is not plentiful. I can understand (but don’t necessarily like) that Apple would make the decision to let the documentation slip a bit until it stops moving sideways.

This is exactly what appears to be happening. The Cocoa APIs are solid– there have been additions, but no major architectural revisions recently. As of the April development tools seed, executing the command….

find /System/Library/Frameworks -name '*.html' -exec grep -l 'forthcoming' {} \;

…reveals that there is not a single ‘description forthcoming’ left in the documentation for any of the Cocoa related frameworks. Likewise, as of WebObjects 5.1 [update whatever], the WO documentation has been moved forward to a similar state.

Core and Carbon– less so Carbon than Core– still has a number of ‘description forthcoming’ bits throughout the docs, but both of those APIs are still evolving.

On the non-reference front, there is quit a lot of examples and taks/concepts guides available. Again, the challenge is largely one of finding them.

For Cocoa:




Excellent starting points for figuring out where all the useful Cocoa documentation lives. The second document is particularly useful to those new to the Cocoa development platform. Scan through the last document to gain an understanding of some of the vocabulary used throughout the rest of the documentation.


Contains a tremendous wealth of examples that exercise particular chunks of API or implement particular concepts



This is the book to read to gain a relatively deep understanding of Objective-C. However, it is also of value to programmers of other OO languages as it provides an awesome overview of OO architecture and implementation methodologies. This is a very mature document; I believe one of the first version shipped with, at least, NeXTSTEP 1.0– maybe earlier– in 1990. However, it is not obsolete/out of date!

The first link leads to the Apple Developer Connection site– likely not news to anyone here– from which you can access any number of very useful resources. If you haven’t done so, register for a free ADC account as that will give you access to various software seed (though not as many as the $500/year select membership) and give you the ability to file bug reports and feature requests via the third URL. (And do file bug reports / feature requests. As long as your report or request is clearly written and contains the appropriate information– version # of the system, build # of the PBX tool suite– Apple really does read the things and really will fix the problems or add the feature (if it makes sense to do so, obviously).

The gateway to all of Apple’s mailing lists. Well, not all, but to a vast majority of the lists that are pertinent to developers. Obviously, you have already subscribed to cocoa-dev, but there may be some other lists that are of interest. If you aren’t sure whether or not a list is useful to you, subscribe in Digest mode. This will limit the # of emails/day you receive from the list– for cocoa-dev, I typically receive somewhere around 3 to 6 digests a day– and will reduce the clutter in your mailbox.

The Omni Group (awesome company — buy their stuff! — they offer the mailing lists completely voluntarily and, beyond the, in each post, I have never seen Omni use the lists for marketing purposes) also has a number of mailing lists of interest to developers. The Omni lists tend to have more traffic and, for whatever reason, tend to have a bit more rampant advocacy then the Apple Lists. Digest mode is definitely the way to go on these lists as macosx-dev alone often has well over 100 messages posted per day (many more, in some case). WebObjects-dev is likewise– I have seen digests with up to 120 messages in it.

The first three links all lead to a boatload of information about Cocoa and OS X development (and OS X development, in general). The last link leads to a page full of links to man0y other sites.

Apple offers a bunch of excellent Cocoa training. Big Nerd Ranch offers excellent Cocoa training, as well, and I hear that their training facilities is quite cool. Aaron– the primary dude behind BNR– has been doing Cocoa and Cocoa related training for a long, long time.

Finally, there are some excellent books out there for Cocoa development. Aaron Hillegas’ “Cocoa Programming for Mac OS X” is available now and does a wonderful job of teaching the developer how to write real world Cocoa apps in an effective manner. On the horizon, Simson Garfinkel and Mike Mahoney have rewritten what was the definitive how to program NeXTSTEP book in the early 90s. The new version is title “Building Cocoa Applications : A Step by Step Guide” is quite excellent.

Of the two, I would actually recommend picking up both. I had the opportunity to act as technical editor on both books and, as such, had a close look at the content. They are really two very different books; the Hillegas book tends to focus on higher level APIs and architectures while the Garfinkel/Mahoney book is oriented more to building a complete application that exercises everything from the unix command line through to high level features. The two books complement each other extremely well.

For WebObjects:


Combining the last software updater update of WO 5.1 with the recent update of the JDK, Apple now ships relatively complete reference documentation with WebObjects. It is hard to find because– unlike Cocoa, Carbon and the Core– there isn’t an index into the documentation available from within PBX (that I have discovered).

I have found three quite workable solutions:

– configure JavaBrowser correctly and it will display javadoc style docs inline as it does the classes. Out of the box, JavaBrowser is nearly useless. I wrote a shell script that will rewrite all of the path preferences for JavaBrowser such that the next time JB is launched it’ll basically have every class and piece of documentation either shipped with the system or installed in the standard extensions directory. The second link leads to a page that describes the script and provides a link for downloads.

– LaunchBar (can be had via the third URL). With LaunchBar installed and correctly configured, I can type (cmd)-(space)WOTF(cr) and LaunchBar will open the WOTextField.html documentation. Very useful.

– If you happen to have a decent Internet connection, searching the documentation is as easy as plugging the class name into the field at the top right of the fourth URL’s page. If someone were motivated, it would be trivial to rip out that form such that you had a minimal version of it on the local hard drive, thus saving the initial round trip to load a page where 95% of the content has nothing to do with the desired search.

Of course, all of this has pertinence to Cocoa development to varying degrees.

The OmniGroup hosts the quintessential development mailing lists related to WebObjects. webobjects-dev and the eof developers mailing list are likely the two most relevant lists. Apple has an announce list, but that’s it. There is also a ‘WebObjects-newbies’ list hosted at yahoo– as its name implies, the questions tend to be more novice in nature.

For Carbon / Core:

Basically, Carbon/Core documentation can be found from the same general locations as the WebObjects and Cocoa documentations and resources. The one big difference with Carbon/Core is that the header files often provide a lot of additional information about the APIs that haven’t made it into the documentation. Unfortunate but, as mentioned earlier, the APIs are still somewhat in flux which greatly impedes the creation of documentation.

The Core differs from Cocoa/WebObjects in that the source for parts of the Core is available within the Darwin CVS repository. Follow the instructions at the first URL to obtain the source.

2) Now, I admit that I am not a strong C programmer, but I can certainly get by. I have started to work with Cocoa and found that in general, it seems really nice and stable. What I find annoying is that there is no documentation on the very few frameworks that currently exist for Cocoa. I have been scraping help off of a few web pages here and there, but I certainly don’t have enough information to build a full application. I have searched Apple’s web site and tried to go through their sample code, but have found few Cocoa samples that did me any good.


(Assuming you did find all the docs mentioned above along with the concepts guides, etc…)

It sounds like you might be looking for something that isn’t there. When learning Cocoa, developers with a lot of deep experience using any of the myriad of APIs available for application construction are actually at a disadvantage until the epiphany happens.

In particular, +the Cocoa Epiphany+ is the moment when the developer realizes that, yes, in fact, the Cocoa frameworks really will do all the work for you.

One key difference with Cocoa development over a lot of other GUI toolkits is that the developer’s code is written in a more passive context.

In Carbon (more old style than new, but the new style stuff is still really hairy to set up), you typically have to write your own event loop and take care of all of the event dispatching within that loop– even for functionality (such as the functionality associated with a Quit or Hide menu item).

With Cocoa, the only event handling code you ever write is for features that deviate from ‘standard application behavior’. Have a look at the TextEdit source for a decent (though there is some cruft that could go away) example of this; fonts, rulers, cut/copy/paste, text selection, text editing, multiple document management, save as/to, revert, printing, hiding, services, spelling, speech, open recent, a basic about panel, handling of graphics in editable text, etc. are all given to you by the AppKit. There is very little custom code in TE and what is there is basically only the code necessary to make the AppKit behave like a text editor.

Another key to success: Don’t pick a fight with the APIs. It is generally unnecessary and you will lose. If something seems like it is a whole heck of a lot harder than it “should” be, it is extremely likely that you are attempting to make the APIs behave in a fashion that is not natural to their architecture. Step back, read some docs, do some googleresearch, and re-approach the problem. A large part of the time, you’ll discover that there is a much better way to solve the problem at hand without writing tons and tons and tons of code.

3) Is Carbon a permanent or temporary technology? I ask because while I want to develop applications for the Mac, I do not want to use Carbon if time is not on my side in the long run. In addition, the majority of the sample code on Apple’s site is still built in CodeWarrior! I have been working with and learning how to use Project Builder and Interface Builder from every bit of documentation I find! Why are code samples still being distributed in CW?

Rephrase the question: How long until all of the software that sells mac systems– Office, PhotShop, Illustrator, etc.etc.etc.– no longer has any dependencies or ties to Carbon?

Until that happens, Carbon is here to stay.

Most of the examples on Apple’s site are still in CodeWarrior because even porting them straight to PBX requires more work than is warranted. Most of the sample code presented as CW projects would need to be rewritten to properly exemplify whatever APIs they are supposed to demonstrate.

This is another case where the samples will improve in quality over time as the APIs stop moving sideways and start moving forward.

In any case, there is a lot of very useful functionality in Carbon and Core. It is easily accessed from Cocoa. Almost all of the recent ‘train hacks’ (I write little apps on the commute to/from the office) have a handful of calls into Carbon/Core to take advantage of APIs that don’t yet have an ObjC wrapper.

Which brings us to the next point….

4) How long will it be before we actually see Cocoa frameworks for the applications like QuickTime? I have a client right now that wants some software developed to process video and due to the lack of documentation and support that I have been able to find, I had to refer back to the PC. Nobody hates doing this any more than me, but I didn’t really feel that i had an out.


QuickTime is a cross platform API/implementation and, as such, it needs to have an API that is easily integrated into many different development platforms. An ANSI-C compliant procedural API is about as cross-platform as you can get.

However, don’t let this stop you from using QuickTime in Cocoa applications. Cocoa provides an NSMovieView and NSMovie class. These classes are simple wrappers around the display of a QT movie and a QT movie itself. The NSMovie object implements the method -QTMovie that returns an opaque pointer to the QuickTime movie encapsulated within the object. With this pointer, you can manipulate the movie’s contents via the standard QuickTime framework’s API.

Again, this is a case of APIs that are still shifting a bit impeding certain other solutions from coming to fruition. As well, wrapping a complex, general purpose, procedural API with a set of ObjC classes that intelligently provide access to that functionality in a general purpose fashion is actually very hard.

Even once done, maintaining the OO wrappers can be costly in that the wrappers have to be modified to track any changes made in the underlying procedural APIs. Certainly, this is also an issue when you have built your own specific purpose wrapper, but to a much lesser degree in that your specific case solution doesn’t exercise the entire underlying API and is not trying to express all functionality possible.

However, it is trivial to hide the procedural calls behind opaque data types and a decent set of classes to wrap the APIs in the fashion you need.

It is likely that Apple will make an ObjC accessible version of the QT APIs available someday. Until that happens, don’t let the lack of it stop you from using Cocoa / OS X!

Again, I do understand that migrating to a new technology like OSX can be frustrating. I would love nothing more than to literally throw my Windoze boxes out the window, but until I can successfully develop a useable application on the Mac, I am stuck with it.

That’s the key; Apple is still migrating to OS X. There are still chunks of API and functionality that need to moved across. Even with the rock solid (I haven’t had a machine crash in months), totally kick butt, 10.1 release we have in our hands now, it is– by no means– a complete migration!

WWDC should be very interesting this year as I believe we are going to see huge strides on the migration front. Overall, the OS “feels” like most of the core issues– stability, performance, etc– have been addressed to the point where Apple is focusing a lot of effort on new development.

Keep in mind, as well, that Apple has “bet the farm” on Cocoa (and WebObjects)! iPhoto is a Cocoa-only application; it doesn’t even run on OS 9. As well, most of the applications that ship with the operating system are written primarily against Cocoa with the few odd calls into Carbon/Core/Hidden APIs. The one notable exception is the Finder. Unfortunate in that the Finder still has some fairly serious usability issues about it.

If anyone has any ideas or suggestions for me, I would love to hear them and
am very excited about being a new member of the Mac community!

Hopefully there’ll be one or two nuggets above that you haven’t stumbled across elsewhere…


Wake up. Breathe….
…. keep breathing.

Paul Boutin writes: I see this slow surfing every time I fire up the aging Windows laptop with just 64 megs of RAM that I need to use now and then to do some work with my Lycos job. This old machine can load pages faster than my newer PowerBook running OS X 10.1.4 on 192 megs of RAM (Yeah, I know my RAM is still too low to get the most out of OS X…). But with OS X’s true multitasking capabilities and my work style – I flip between applications and tasks frequently – the slower browsing speed is not a deal breaker.

Gee, that’s funny, on all of the machines I use– from G3 iMacs through to my powerbook G4, I don’t suffer from this problem. I use LaunchBar to switch between apps and, as such, my hands area already on the keyboard and ready to go and the delay between app switching takes about the same time it takes for my brain to focus on the various windowsthat just popped forward.

First– get more memory. Memory is cheap, even with the recent price increased. 512MB is my minimum. Not because OS X, in itself, is a memory hog (though the graphics layer certainly is), but because the operating system will take advantage of every last byte of available memory to buffer access to the disk.

Virtual memory is great, but only hitting the disk once to bring in a hunk of data is far, far superior.

On a powerbook, this is especially crucial as portable hard drives are slow, Slow, SLOW! Any virtual memory activity on a powerbook is guaranteed to be noticeable simply because the drives are slow.

(I would suspect sticking a bunch of memory in your ‘book will also increase battery life by decreasing page swaps… but I haven’t remotely qualified this at all.)

I also try to avoid slow applications. I find that a lot of the carbonized applications out there are not very well engineered. The same can be said for Cocoa apps, but the very nature of Cocoa means that the core still plays well with the rest of the operating system.

Instead of IE, use OmniWeb 4.1b4. It is faster than IE by leaps and bounds. It doesn’t pause very often, either– something that drives me batty with IE.

Chimera– though very alpha– is blazingly fast, as well.

Obviously, it isn’t OS X that makes browsing slow. It is a combination of bad engineering or good engineering for a completely different system [OS 9] that has been ported, but not fully optimized, for OS X. iCab, Opera, and Mozilla all suffer from this– they are all nice browsers and each has their attractive strenghts, but they all feel like they have not been optimized properly.

I have also found that some applications– all Carbon so far– have a nasty habit of consuming a bunch of CPU when doing basically nothing. Microsoft Word will “idle” at 50% CPU utilization unless you turn off live word count, for example.

Certainly, there is a great need for optimization throughout OS X. Given the history of the operating system from the NeXT day, it very much appears that history is repeating itself. Every release of the NeXT operating system very much followed the ‘Make It Work, Make It Right, Make It Fast’ philosophy of software development.

It seems that some of the third party developers are stopping the Carbon parts in between Right and Fast. It works Right, but it isn’t Fast because the code still assumes an OS 9 – like operating environment.

If you need a really good bag for your laptop, nobody makes better bags than Tom Bihn I have a Brain Cell snapped inside of a Brain Bag.

The TiBook snugly fits inside of the brain cell and the cell has hard padding on all sides. It snaps inside the brain bag via four snaps such that the weight of the laptop is evenly distributed across my back.

The brain bag is, by far and away, the best and most comfortable bag I have ever owned or tried. Highly adjustable, roomy, and fits on the body perfectly– even a heavy load is easily balanced and sits comfortably on your back for long periods. It is also extremely well built.

I also picked up a Snake Charmer from Tom Bihn. I keep a complete set of cables, a small FireWire HD, and any AC adaptors in it at all times. The see through sides make it trivial to grab exactly what I need quickly and easily.

Tom Bihn is an excellent company. A friend put an order in with 2 day delivery because his current bag broke about 3 days before he was to travel for a week on business. FedEx screwed up such that the delivery would not arrive in time. He called Tom Bihn to ask if he could order a new set with overnight delivery and return the original order upon return from a trip, the nice folks at TB asked what was up and, upon hearing his tale of woe with FedEx, offered to ship him a new order overnight express without charging him a dime!