« December 2005 | Main | October 2005 »

Wed, Nov 30, 2005

... and my PowerBook killed itself :-(

Well, well, well... Not so well, actually. Last week my 12" PowerBook G4 (1st gen. 867 Mhz) died. It started with freezes that went away after some seconds, went on with scrambled graphics and crashes (no kernel panics; complete freezes that required a forced reboot) and a black display after wake from sleep. Then there was a final crash with scrambled graphics during checking mail (which corrupted my e-mail database), and I have not been able to boot into Mac OS X since. I can reach target disk mode, but the display shows (usually) vertical lines that change their position and colour whenever the firewire symbol moves across the screen:

This looks pretty much like the problems that led to the iBook Logic Board Repair Extension Program - and the serial number of my book falls within the range of eligible machines (UV321...), only it's a PowerBook G4 and not an iBook G3... Apple Hardware Test reports the following video ram error: "2NVD/1/4: 0x8". The book is out of warranty, but I phoned Apple support nonetheless to ask if there's a repair program for PowerBooks. There is no such program (yet?) and they had not heard of any PowerBooks or iBooks with such failures (which is hard to believe). They said they were really sorry but such a failure can happen to a graphic card after 2.5 years, and they wished me a nice day. Thank you.

Sure, this can happen to one or the other PowerBook and maybe I just had bad luck (and maybe today's hardware is not built to last that long any more). But if you read current reports, these failures seem to be quite common, at least for iBook G4s. As the 12" PowerBook shares many components with the iBook G4, this may be a general design flaw which Apple should take care of (regardless of expired warranties, just like they did with the iBook G3).

This is not a matter of warranty anyway, but a matter of consumer satisfaction and trust in the brand. Getting the book repaired is not an option, as a new iBook (with twice the speed) costs only a little more. But why should I buy a new iBook now if current books still have these problems and if I cannot be sure that Apple will show accomodating behaviour when such hardware failures happen again?

There used to be a time when Apple's quality (both software and hardware) was so excellent (and worth the extra price) that you could actually rely on your Mac. But times, they are a-changin' (Mr Jobs, you know this song?). It feels strange if out of three computers at your office, your two Macs are dead (see my previous posting) and only the cheap Windows PC is working...

Posted by Thomas Much at 11:31
Categories: Apple & Mac OS X

Xcode 2.2 killed my system ...

Just a little warning if you intend to update your Xcode 2.1 to version 2.2. On my iMac G5 (rev. B) it killed my startup volume...

I had Mac OS X 10.4.3 running on that machine, all software updates applied, the startup volume was verified successfully and the permissions had been repaired. I did a complete Xcode install (all options selected) over a complete installation. All was working well until the installer reached the Java documentation postflight script... I got a lot of "mismatch in rm pattern" messages (unfortunately, I did not save the install log), and after a very long time the installer finished.

Now the kernel_task (pid 0) was hogging memory... When it reached 1.5 GB (out of 2 GB physical memory), I tried to shutdown the system (did not work, I had to do a forced shutdown). Afterwards, I could not boot any more into Mac OS X... Which was quite understandable, since half of my System folder was deleted, and many bundles in the Applications directory had some of their resources deleted, too. Unfortunately, I could not reinstall Mac OS X with "Archive & Install", as my startup volume was corrupted now and could not be repaired. I suspected some hardware error, but Apple Hardware Test reports everthing as ok (knock on wood... I do not need two dead Macs, see my next posting...).

So, take this as a warning to make backups on a regular basis (I'm glad I did). And before installing Xcode 2.2, you might want to uninstall the previous version first. As my iMac hardware works ok, I still suspect a software bug in the Java documentation postflight script - even after a completely new reinstall of Mac OS X 10.4.3 and Xcode 2.2 I get some strange errors from the script (yes, this time I saved it ;-):

run postflight script for Java 1.4 Reference Documentation
postflight[641]: /bin/mkdir -p "//System/Library/Frameworks/JavaVM.framework/Versions/1.4.2/Resources/Documentation/Reference"
postflight[641]: rmdir: //Developer/ADC Reference Library/documentation/Java/Reference/1.4.2: Directory not empty
postflight[641]: PSSniffer error: Not a directory
postflight[641]: ***** Errors found during indexing. *****
postflight[641]: Rerun pbhelpindexer with the '-d' debug switch for a complete transcript of the errors and associated files.
run postflight script for Developer Documentation
postflight[670]: mv: rename //Developer/ADC Reference Library/documentation/Java/Reference/1.4.2/appledoc/api/dummy.html to //Developer/ADC Reference Library/documentation/Java/Reference/1.4.2/appledoc/api/index.html: No such file or directory

Posted by Thomas Much at 10:47
Categories: Apple & Mac OS X

Sun, Nov 27, 2005

iCab 3.0 Beta 371

iCab 3.0 Beta 371 was released to registered users on Wednesday. It contains a comfortable new cache browser in the Tools menu.

Here's Alexander's list of changes since beta 368:

  • Small correction for images with 16Bit per Pixel and a color table with 65536 entries.
  • Workaround for a problem where ATSUI displays text in a strange way when the text contains "FormFeed" characters (ASCII 12).
  • Solves a problem with missing "</A>" end tags in HTML code.
  • There's a new menu item in the Tools menu: "Cache Browser". The Cache Browser allows to inspect the current content of the Web Cache (this was also possible in older versions of iCab, but less comfortable). There're several ways to display the cache content:
    • List View
      The content is listed with information about URL, file type, dates, file length. Some checkboxes allow to exclude or include certain file types in the list, so the list will include only the data you're looking for. A special "download" link allows to easily "download" (save) a file from the cache into the download folder.
    • Image View:
      All the images that are in the web cache are displayed as thumbnails. From here it is easy to save the images to disk via Drag&Drop or the contextual menu.
    • Audio, Video, Flash View:
      All the Audio, Video or Flash files in the cache are listed. A "download" link allows to easily download (save) the file. A "preview" link allows to preview the file (if possible without the HTML code where the file was embedded originally).
  • The Default StyleSheet for the <HR> element is modified to improve compatibility with other browsers.
  • When embedding HTML documents in web pages using OBJECT instead of IFRAME elements, it could happen that the embedded documents was invisible if the size of the OBJECT element was defined in a very special way.
  • Changed the behaviour of iCab when it encounters HTML elements which where found in HTML tables at a location where they are absolutely forbidden.
  • Workaround for misplaced HTML elements in OPTION elements where they are not allowed.
  • iCab could freeze if JavaScript code tries to move a HTML element in front of itself with the "DOMCoreNodeInsertBefore" method.
  • Alternate StyleSheets which are not meant for the screen where nevertheless listed in the StyleSheet menu.
  • Opening web pages from within the Hotlist was internally treated like opening from the History. Therefore loading the page from the cache was preferred.
  • Now iCab supports the "Internet Shortcut" files of the Internet Explorer for Windows as well.
  • Attributes which were definied multiple times in XHTML documents are now reported as error.
  • Workaround for block element which are nested in an inavlid manner and which are redefined as "table-cell" via CSS. Because of the wrong nesting it could happen that the resulting layout was a mess in this case.
  • Web Archives in which frame pages are saved were not displayed correctly in certain circumstances.
  • Workaround for a certain issue with Java under MacOSX: When iCab processes certain events while the Java engine is started, the Java engine is never giving up the processor and so iCab is never able to do anything again.
  • On some "dotmac" login pages the login/logout button was not visible.
Posted by Thomas Much at 15:10
Categories: iCab & InScript

Fri, Nov 11, 2005

iCab 3.0 Beta 368 at your Services

Two days ago iCab 3.0 Beta 368 was released to registered users. The two prominent new features are support of the System's "Services" menu and support of alternative stylesheets (you can switch between them in the "StyleSheets" submenu of the "View" menu).

Alexander mentions the following changes since beta 364:

  • Bugfix for "display: table-cell"; in some rare circumstances iCab did not create the missing table for such a table cell, if there's none defined by the StyleSheet.
  • Fixes a small ssue when activating alternative StyleSheets.
  • Small workaround for a bug of "classic" MacOS which mixes up the ATSUI colors and the Quickdraw colors when printing.
  • If JavaScript code did submit multiple forms on the same page at the same time and redirects the results in different frames/iframes, iCab did process all the form submits in the context of the original page and redirects the result afterwards to the frames. But beause only one form can be submitted this way (other form submits would overwrite the first or would not happen at all). Now iCab will process the submits in the context of the frames/iframes where the results should be send to. This way the submits can't overwrite each other anymore.
  • Workaround implemented for the Windows Media Player Plugin, which could not be recognized as "bundle" or "plugin" file.
  • The "Services" menu is now supported.
  • The JavaScript statement getElementsByTagName('html') didn't return the HTML element.
  • When typing in some text the mouse cursor is hidden now.
  • TIFF images with alpha channel but where certain information tags were missing could crash iCab before.
  • Bugfix for "hover" effects with "small-caps" text.
  • The "click()" function of JavaScript did also set the focus to the "clicked" element. But some web sites don't woirk anymore if this happens.
  • When clicking links with a "fragement identifier" (#xyz), which link to another location within the same site, iCab did not add the new fragment identifier to the URL of the location toolbar.
  • If iCab was configured to confirm each "quit" command and the user tried to quit directly from within the kiosk mode, but canceled the quit command from there, iCab did not leave the kiosk mode correctly and most parts of the menu bar was disabled afterwards.
  • iCab now supports alternative StyleSheets which are defined on web sites. You can select an alternative StyleSheet in the submenu "StyleSheet" of the "View" menu (where you can also select one of your own user defined stylesheet, if you've added some in the "StyleSheet" preferences). Most web sites don't provide any alternative StyleSheets, but some do.
  • Bugfix: Accessing attributes of element nodes which were created with XMLHttpRequest() (via JavaScript) sometimes only returned empty strings.
  • Bugfix for the BUTTON element. Sometimes a click on the button element was delivered to its content so the element could not process the click itself.
  • Bugfix: Accessing attributes of element nodes which were created with XMLHttpRequest() (via JavaScript) could cause a crash.
  • iCab could not display the source code of RSS feeds in its own source code window.
  • iCab now also supports "Content-Encoding: gzip". This is important for servers which send compressed data even if the browser doesn't allow this.
Posted by Thomas Much at 22:58
Categories: iCab & InScript

Sat, Nov 05, 2005

Acid2 - the truth about Safari, iCab and Konqueror

The latest Mac OS X update (10.4.3) contains a new Safari version 2.0.2 that passes the Acid2 test (if you're not sure what this test is all about, take the guided tour). This has raised some interest in the media if and when other browsers will pass this test, too. Unfortunately, there has been a lot of misconception about the winner and the runners-up. So, here's the truth about the Acid2 race.

Fact 1

  • On 2005-04-27 Apple's Safari was the first browser that successfully passed the Acid2 test, but it was an Apple internal version only.
  • On 2005-05-18, an internal iCab version passed the test, too, and was available to registered users on 2005-05-20 - second place! A public preview was released on 2005-06-06.
  • Konqueror passed the test on 2005-06-04 and was available as a nightly build almost instantly - third place.

Later on, nightly builds of Safari became available here, and on 2005-10-31 Safari was the first officially released Acid2 compliant browser. The initiatiors of the test race, webstandards.org, have published the official results here and here.

Fact 2

iCab uses its own rendering engine and is not based on KHTML - in contrast to Apple's WebKit, which is based on KHTML. This way, the developers of Konqueror could use some of Apple's Acid2 fixes. The code that enabled iCab to pass the Acid2 test was written completely by Alexander Clauss.

Posted by Thomas Much at 23:58
Categories: Browsers, iCab & InScript

Tue, Nov 01, 2005

Mac OS X 10.4.3 and the System keychain

When I updated my iMac G5 to Mac OS X 10.4.3 this morning (using the "Combo" update), I was prompted for the "System" keychain's password after every reboot:

System keychain

Obviously, the system tried to read the Airport password from the keychain - which was absolutely not necessary, as access to Airport was working flawlessly even if you pressed Esc or clicked "Abbrechen" ("Cancel"). And the correct password was hard to guess, since the System keychain's password is usually generated automatically (random).

There is a simple solution to this problem: Just move the file System.keychain from the folder /Library/Keychains to the trash (and drag it from the trash to a safe place, e.g. the desktop, afterwards - just in case). Reboot, enter the correct Airport password in the Network preferences and switch Airport off and on once. There haven't been any annoying alerts since, and removing the keychain doesn't seem to have any negative side effects.

Posted by Thomas Much at 19:09
Edited on: Tue, Nov 01, 2005 19:25
Categories: Apple & Mac OS X