You are currently browsing the category archive for the ‘general’ category.

Apple has just released Mac OS X 10.5.3 update and the changes are not earth shattering.

Here is a list of changes in Leopard OS X 10.5.3 posted at Apple Support.

Most important to me would be this one:

“Addresses reliability issues when performing a full restore from a Time Machine backup.”

[Hint: don’t install the Leopard 10.5.3 update for a week or two if you aren’t suffering from any of the problems fixed in the list of changes. Why? Remember 10.5.1? That was a fiasco that led to so many problems that 10.5.2 was quickly released to “fix the fixes”. Basically, let others find the bugs within 10.5.3 and have Apple fix those before you install the update. If there are any major issues with this latest release, you’ll avoid the worst of them by waiting a couple of weeks. I’m actually still using 10.5.0 since it’s rock solid and the updates released since don’t affect my day-to-day usage. I’d rather have reliability than having all the software that I don’t use up-to-date.]

That’d be pretty annoying to use Time Machine religiously and when finally disaster strikes and your backups aren’t fully useable? Ouch.

Regardless, I’d still recommend SuperDuper! for bootable Leopard backups in concert to Time Machine file backups, since Time Machine’s backups do not give you a bootable backup disk to restore from. If Time Machine backups are all you have, you’d have to reload Leopard from DVD, then restore your settings and documents from Time Machine.

With SuperDuper! you could simply connect the drive you used via FireWire/USB, reboot your Mac, hold down the alt key, select your SuperDuper backup and be working from that drive like nothing has changed.

Even more hard-core, you could simply remove the failed drive within your Mac, install the SuperDuper disk in its place, boot, and theoretically you should be operating normally as if nothing had happened.


A good alternative browser to Safari on Mac OS X Leopard is Camino. Camino is based on Mozilla’s Gecko engine, so it operates much like Firefox on Mac, but a hell of a lot quicker.

Camino just released version 1.6.1 (May 20, 2008), which fixed stability and security issues from their last major release, 1.6, which was made available a month before that, so the latest release should be pretty solid.

Having offered Camino as an alternative to Safari, I actually not only still use Safari, but I also use Firefox, basically the three major browsers on Mac. Why the heck would I do this? Each browser has its benefits.


Best mix of speed, features, and compatibility. I still find certain javascript/ajax issues such as with Google Documents drop down menus, but not much beyond that. Did I mention blocking of all Flash Ads and Pop-ups, with exceptions or white-lists available for both? Hot.


Best overall website compatibility. Lets face it, Apple still has a ways to go before Mac penetration gets beyond even 15% of the user base that Windows has. As such, most websites are optimized or tested for “Internet Explorer” and none other. This can lead to rendering issues on Mac browsers such as Safari and Camino. Firefox is the least susceptible to these compatibility issues, which are generally due to Internet Explorer not being standards compliant. But, that’s another story for another time, by another blogger.


Fastest browser. Faster than both Camino and Firefox. Safari is what I think of as a “light browser”: a lean, mean, browsing machine. This was the first browser for Mac and it’s the most “integrated” with the operating system. But, it lacks some “power-user” features that I can’t live without on a day to day basis. For example: text or link searching using “forward slash” or “single quote”. In Camino simply hit the “forward slash” key, start typing, and Camino will move to the next word containing the string of characters you are typing. Hitting Ctrl + G will move to the next match. The same works with “single quote” link searching. Once the link you’re searching for is found and highlighted, simply press Enter/Return and the link is opened. This is seriously efficient and fast browsing, much much faster than messing around with a mouse or trackpad and hovering the mouse pointer over the correct few centimeters of display in order to open links. Try this inline search feature on Camino and I bet you will love it.

Safari has its own search/find feature that’s pretty tight as well, highlighting the word you’re searching for and darkening the rest of the page. This is great for serious text reading on big documents, but for navigating and general surfing, I’d much rather have Camino’s inline search with keyboard navigation.

In a follow-up to my previous post on the best laptop screen – MacBook Pro 15″ LED backlit screen, I’ve discovered why the laptop screen is quite different in displaying the same photo as compared to something like a Samsung SyncMaster 206bw which I use as my secondary display.

It comes down to screen gamut [pronounced gammet], or how many colors a display can accurately represent. For example, a black and white display has less gamut than a color CRT with a dead electron gun, which in turn has less gamut than a fresh new Apple MacBook Pro LED screen.

Viewing a dedicated display like the Samsung side-by-side with any laptop screen, will make the laptop screen look “washed-out” in terms of color, simply because the laptop screen cannot produce as many different colors. At extremes you’ll have one color replace another, for example, light reds replacing what should be orange hues (which is the most notable deficiency in colors of the MacBook Pro LED screens).

This doesn’t mean the MacBook Pro LED screen is bad, it’s actually the best in terms of color gamut amongst all of the previous Apple laptop screens.

For a more in-depth discussion of color gamut on the MacBook Pro 15″ LED displays, check out these posts from James Duncan Davidson and Rob Gailbraith.

With large files, sometimes it’s easier handling them split into many smaller files.  In order to rejoin the files one typically uses a file joining program.  I came across two that could possibly perform file joins: MacHacha and Split & Concat.

Turns out that MacHacha has some issues, perhaps related to Leopard, as after reaching the last file of a 75 part file series, it simply hung on searching for the next part (which didn’t exist).

Split & Concat on the other hand, handled the files without issue and has the option of specifying the output directory though the Options button before the start of a join session.

My vote goes to Split & Concat for file joining software on Mac OS X.

  1. Vista sucks.
  2. OS X rocks.
  3. Web Apps.
  4. Mac Bling.
  5. Mac at Last Gen PC Price.
  6. Bootcamp parachute.

Points 1 & 2 are self-explanatory.

3. Web Apps

People are no longer afraid of not being able to run their Windows apps because… nearly everything is becoming a web application. The only thing you need to run a web app is a web browser, which is free and already installed.

Most devastating to Microsoft’s crumbling empire was/is GMail. Email is the most used Internet service. Everyone gets email (even possibly the AOLers).

GMail virtually eliminated spam. And now, everyone has a GMail address.

GMail, is a web app.

Web App = Operating System Agnostic. Bye-bye chains of Windows servitude.

4. Bling

People like to show off their richesse. Ladies will buy a thousand dollar Louis Vuitton handbag to hold a set of house keys. Why not a sleek sexy Macbook Pro to hold their SSH keys?

5. Price… not so bad

Macs are more expensive than a similarly equipped PC. Regardless, with a Mac you’re getting more style, functional form, sexiness, and envious looks from the Dell drones. Mac’s are simply “badass”. Walk into any Apple flagship store and everything will make sense.

Now, consider the purchase price a current Mac. Most people buy a new computer every 3 to 5 years. The price of their last computer was likely similar or even more expensive than the current Mac / Macbook they’re eyeing. Perhaps this is why Mac sales can grow, even in a recessionary economy.

6. Bootcamp

The idea of plunging into uncharted waters of Mac-land is a scary prospect to the long-term PC crowd, myself included. Knowing that if you really needed to, you could jump back into Windows with a quick reboot, or through VMWare Fusion while still running OS X… is the golden parachute.

Bootcamp eliminated the worry of becoming the prodigal son and returning to the Windows scene, tail between legs.

Even if the newly converted enlightened never touch bootcamp, simply having it as an option, handholds a lot of people through the Windows to OS X transition and sells a lot of Macs.

Brilliant marketing.

Have I forgotten anything? Have your say by leaving a comment.

The Best Laptop Screen available on the market is on a MacBook Pro “Santa Rosa” (named that for their use of the Intel Core 2 Duo chips using the “Santa Rosa” line, i.e. 2.2Ghz and 2.4Ghz speeds). Alright, that’s a bit of a strong statement. The Best Brightness on a Laptop Screen… is found on a Macbook Pro 15.4″ Santa Rosa model. The 17″ MacBook Pro’s still do not feature the LED backlit screen.

UPDATE 080519: MacBook Pro LED color gamut review.

UPDATE: 1920×1200 LED backlit display MacBook Pro 17″ models are now available.


Why is the MacBook pro backlit LED laptop screen so good?

Instant Screen brightness control

Instant changes to the brightness of the screen, brighter or darker, which is perfect for those who use their laptop on batteries often and thus have a relatively short “sleep display” time. For example if you don’t do anything on your laptop for 1 minute, the screen will go black due to the lamp inside the screen turning off to save battery power. Inside old school LCD screens is a fluorescent tube which performs the lighting of the LCD transistors which are creating colored pixels. The problems or drawbacks with fluorescent backlit LCD screens is that the tubes need time to warm up before reaching their full stable luminosity or brightness. Thus, each time the lamp turns off and cools, and then is relit, there will be a period of time where the brightness of the screen is constantly growing as the tube reaches full temperature. LED’s, Light Emitting Diodes, don’t suffer from this problem and reach maximum stable brightness, instantaneously.

If Apple could fine tune their ambient light sensor control software to be more “fuzzy” and less “on/off”, the automatic screen brightness control would be useful. At the moment, the light meter is simply too jittery. Pass your hand over the sensor for an instant, and the screen’s brightness dims because it thinks the ambient lighting has changed. Quite simply, this is retarded. The lighting control software should be taking ambient light measurements and use a moving average as the target luminosity rather than try to adjust the screen brightness instantly with every flicker of light reaching the sensor. The human eye doesn’t adjust that quickly (think about waking up to someone slamming open the shutters or turning on the lights… ouch), so why try to make the MacBook Pro screen brightness change so quick?

LED backlighting uses less energy

The second reason LED backlit MacBook Pro screens are great: they use less energy. This is a simple fact of life (or physics I suppose) that LED’s use less energy than fluorescent tubes, to produce the same quantity of lumens or light power. Lower power consumption on a laptop is always a good thing since that is one a laptop’s main goals: to work on a limited power supply, for as long as possible.

Drawbacks of MacBook Pro 15.4″ LED backlit screens?

Weak Color Richness

The light produced from LEDs is “whiter” than that of fluorescent tubes. By “whiter”, I don’t mean it has less soul, but rather its higher in the color temperature scale, often measured in Kelvin. The effect is similar to that of Xenon lamps in car headlights. The inert gases used in Xenon lamps produce a light that is higher on the color temperature scale and have a bluish white cast. That bluish color is actually white, but we’re so used to old school incandescent lighting that we’re accustomed to a yellowy orange color in our light bulbs. Thus, on a MacBook Pro LED backlit LCD screen, the color appears more washed out and less rich than that of fluorescent backlit screens. For some, this will be a difficult thing to get over, especially art and design professionals for whom color is critical. For the average user, unless they are using a secondary display side by side with their MacBook Pro’s screen, they will not notice the difference. Until you have a point of reference, it is very difficult to tell that the color on a MacBook Pro is different at all. I happen to use a Samsung Syncmaster 206bw with my Santa Rosa MacBook Pro, thus, I can tell the difference in color richness, and it’s significant. Adjustments to the color on my LED backlit screen cannot bring more richness to the colors either. It’s simply a basic difference in lighting and no amount of adjustment to color balance can make LED light appear like fluorescent light.

Conclusion on LED vs. Fluorescent backlit LCD screens?

The constant instant brightness is noticeable every time I bring my screen out of sleep. The difference in color is only noticeable if I have the exact same window displayed on both of my screens simultaneously and I look back and forth between them. Thus, the good outweighs the bad, and you have to search for the bad in order to find it, whereas the benefits are always immediately visible.

I would choose the LED backlit screen again if I had to redo my order.

Error: uncaught exception: Permission denied to call method FireFox/Mozilla browser fix / solution:

  • Go to address “about:config” in Firefox (i.e. type that in the address bar and hit Enter)
  • Search for “signed” in the filter bar
  • Double click the item “signed.applets.codebase_principal_support” to change its value to “true”
  • Create (or edit if already present) the “user.js” file found in the below directories. By default this file does not exist so create a new blank user.js file if you don’t find it in the following paths (as specified on
    • On Windows Vista/XP/2000, the path is usually %AppData%\Mozilla\Firefox\Profiles\xxxxxxxx.default\, where xxxxxxxx is a random string of 8 characters. Just browse to C:\Documents and Settings\[User Name]\Application Data\Mozilla\Firefox\Profiles\ on Windows XP/2000 or C:\users\[User Name]\AppData\Roaming\Mozilla\Firefox\Profiles\ on Windows Vista, and the rest should be obvious.
    • On Windows 95/98/Me, the path is usually C:\WINDOWS\Application Data\Mozilla\Firefox\Profiles\xxxxxxxx.default\
    • On Linux, the path is usually ~/.mozilla/firefox/xxxxxxxx.default/
    • On Mac OS X, the path is usually ~/Library/Application Support/Firefox/Profiles/xxxxxxxx.default/
  • Place the following lines within user.js:

    user_pref("", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.sites", "");
    user_pref("capability.policy.XMLHttpRequestToAnySite.CDATASection.nodeValue", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.Element.attributes", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.Element.childNodes", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.Element.firstChild", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.Element.getAttribute", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.Element.getElementsByTagName", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.Element.lastChild", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.Element.nodeName", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.Element.nodeType", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.Element.parentNode", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.Element.tagName", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.Element.nextSibling", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.Element.previousSibling", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.HTMLCollection.length", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.HTMLCollection.item", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.Text.attributes", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.Text.childNodes", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.Text.firstChild", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.Text.getAttribute", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.Text.getElementsByTagName", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.Text.lastChild", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.Text.nodeName", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.Text.nodeType", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.Text.parentNode", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.Text.tagName", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.Text.nextSibling", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.Text.previousSibling", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.XMLDocument.documentElement", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.XMLDocument.getElementsByTagName", "allAccess");
    user_pref("", "allAccess");
    user_pref("", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.XMLHttpRequest.responseText", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.XMLHttpRequest.responseXML", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.XMLHttpRequest.send", "allAccess");
    user_pref("capability.policy.XMLHttpRequestToAnySite.XMLHttpRequest.setRequestHeader", "allAccess");
    user_pref("capability.policy.policynames", "XMLHttpRequestToAnySite");
  • Edit the line containing” and replace that URI with whatever URI you are developing on (or publishing to). For me it happens to be Normally it would be just “localhost” for most people or localhost:3000 for Rails project developers.
  • Save the user.js file
  • Exit out of Firefox or other Mozilla based browser. If on Mac OS X, fully quit Firefox by hitting Cmd+Q, don’t just close the current browser window (which leaves Firefox still running in the background).
  • Launch FireFox again.
  • Exit out of Firefox again. The config file that Firefox actually uses to control the browser is called “prefs.js”, not “user.js”. user.js is the file that we, the end user, are supposed to make changes to, which are then copied over to prefs.js when Firefox is loaded. For whatever reason, the prefs.js file will not be updated with the contents of user.js until you exit Firefox, launch it, exit again (at which point prefs.js will be updated), then launch Firefox once more and your changes are ready for use.

After the above steps are completed, you should be able to make XMLHttpRequest calls cross-site / cross-domain with your AJAX code without Firefox/Mozilla security getting in the way.

The bevy of user_pref settings above creates a new site security policy that allows the listed XML HTTP Request commands to be performed from “” to any address. Normally, Firefox will only allow XMLHTTP Request calls within the same domain. For example if you were on domain, Firefox would not allow the website to make XMLHTTPRequest calls to since this was a major exploit that crackers would use to hide their evildoings in the background of apparently benign sites.

In general the security policy that Firefox has setup by default is a good idea. Setting up a new security policy as we have done above is generally safe as it only allows the site “” to make cross-site/cross-domain XMLHTTPRequest calls of any sort listed. Any other domain would not be allowed to use this site policy.

This post originally started out due to the desire to develop AJAX Toolkit based s-controls outside of their Ajax Tools IDE (yeah, their naming schemes leave something to be desired), which runs on their “no software” platform.  Of course I ran into huge problems with Camino / Firefox and cross domain XMLHTTPRequest scripting security issues.  The result of which is this post on how to get around the cross site scripting issues and develop javascript based s-controls on your local machine, using your preferred IDE (go go Textmate).

Z Movie Club, the sister site to Z Book Club (the online book club site) has been launched.

Z Movie Club is an online movies club site where you can browse, find and discuss movies online with other movie fans.

Z Movie Club is not a site where you can download films directly, but rather, use partner sites such as MovieLink, Blockbuster, NetFlix, Amazon to rent, purchase, or download movies or do all three.

I hope you find the site useful, interesting and enjoyable. Please stop by and check out some online movies at Z Movie Club.

Z Movie Club Online Movies Home

Online Movies at Z Movie Club - Club Page - V for Vendetta

If you notice some weirdness with Online Movies at Z Movie Club, apologies. I’m still smoothing out the kinks after the launch.

If that title makes no sense to you, well… that’s good, cause you probably didn’t spend the last three hours trying to figure out why gzip compression is not working on Javascript files being served from your Apache 2.x web server.

For those of you unlucky enough to understand what I’m talking about (and thus stuck scratching your head at why Apache 2.x with mod_deflate is not compressing javascript, css, etc. files… the reason is (drum roll please): gzip compression is handled transparently by all modern browsers. Furthermore, HTTP/1.1 enabled browsers will check their cache to see if a copy of the file requested is in the cache and will not download the same file from server if present locally. Apache still receives a request for a file that is in cache, but only to check that the file version is the same, and if it is the same, Apache will not serve the file. This is the key to understanding why Apache logs report no compression on files served to a HTTP 1.1 compliant browsers… it’s cause the file was not actually sent to the requesting browser.

"GET /javascripts/prototip.js HTTP/1.1" -/- (-%)
"GET /javascripts/prototip.js HTTP/1.1" 2649/9002 (29%)
"GET /favicon.ico HTTP/1.1" -/- (-%)
"GET /javascripts/prototip.js HTTP/1.1" 2649/9002 (29%)
"GET /favicon.ico HTTP/1.1" -/- (-%)

In the above snippet of a mod_deflate log, the first line is Apache “serving” the prototip.js file, with 0Bytes [compressed] / 0 Bytes [uncompressed] (0% compression rate). The reason? The file is cached at the browser and thus the file is not actually sent.
The second line is after clearing the browser cache. It shows that prototip.js was sent to the browser as a 2649 Byte compressed file from an original uncompressed 9000 Byte file, which gives a compression rate of 29%. The favicon.ico file (for the little icons your see beside your site name in browser window tabs) is sent uncompressed due to it not being one of the file types we specified in http-vhosts.conf, therefore, no compression was applied to the file.

There is a good chance that I’m talking straight outta my butt on this. If you know better than I on this subject, please do leave a comment and let me know what’s really going on.

For reference, here is the pertinent part of my http-vhosts.conf file, with comments/junk removed.

78 AddOutputFilterByType DEFLATE text/html text/plain text/css
80 AddOutputFilterByType DEFLATE text/javascript application/x-javascript
82 BrowserMatch ^Mozilla/4 gzip-only-text/html
83 BrowserMatch ^Mozilla/4.0[678] no-gzip
84 BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
85 DeflateFilterNote Input input_info
86 DeflateFilterNote Output output_info
87 DeflateFilterNote Ratio ratio_info
88 LogFormat '"%r" %{output_info}n/%{input_info}n (%{ratio_info}n%%)' deflate
89 CustomLog /var/www/ deflate

I know you’re itchin’ for some good old HTTP Compression RFC (Request For Comments) 2616 reading so here it is.

If you’re having troubles booting off of a backup of your Leopard OS X install made by SuperDuper!, you’re not alone.  SuperDuper! full system backups are not bootable under Leopard. If you try to boot off a SuperDuper! created backup on an external USB disk or external firewire disk, the Mac OS X boot screen with the spinning/twirling little circle will continue forever.

ShirtPocket, the maker of SuperDuper! notes on their homepage that their SuperDuper! product is not fully compatible with Leopard, but they do not say what incompatibilities exist.  As far as I can tell SuperDuper! under Mac OS X Leopard does not:

  • Backup all personal settings such as backgrounds, menu bar items, dock preferences, keyboard preferences, etc.  Consider all of this information lost if you are planning to back up only with SuperDuper!.  You cannot use this backup to transfer your personal settings using Migration Assistant. Some things such as user accounts, passwords, files, etc. will transfer OK using Migration Assistant and SuperDuper! created backup, but nearly all other settings will not be transferrable.
  • Backup all Applications properly, such as LittleSnitch (outgoing network traffic firewall). Count on having to reinstall certain software when trying to restore from a SuperDuper! backup.

For now, consider Time Machine your preferred backup provider until SuperDuper! manages to fix the incompatibilities with OS X Leopard.  ShirtPocket makes great products and they have a stellar pricing model (unlimited trial, but pay for it if you use it).  Also, SuperDuper! is extremely easy to use and hopefully it has a niche that allows it to work side by side with Time Machine.