Airport Extreme disappoints

UPDATE: Apparently, firmware upgrade 7.3.2 fixed the disk access problems. I'm now able to use a USB-attached disk to AEBS just fine. Skype also started working fine some time ago (even before the firmware upgrade). The speed issue (not being able to exceed 8 Mbit/sec on 802.11g with all-Apple equipment) unfortunately still remains.

I got a brand new Airport Extreme Base Station (AEBS) this Friday. (Kirk hauled it for me from Las Vegas to Hungary - Apple gear costs roughly twice as much here than it does in US.)

I already own a 250GB external HDD, so I wanted to attach it to AEBS for either file sharing or, hopefully, wireless Time Machine backups.

(Too bad Apple officially said only three days later that they don't support Time Machine backups with AEBS. Meaning, if it works for you, you're lucky, but if it doesn't, you're on your own.)

Anyway...

My experience is that even when Time Machine is not involved, AEBS can't handle a USB drive at all. Just attaching the drive to the base station will cause it to come online much more slowly (needs several minutes after plugged in). Also, whenever I wanted to mount the drive through Finder on any of the Macs in the house and transfer a file to/from it, AEBS would become inaccessible in a minute or two, then spontaneously reboot. With no drive attached, it's stable as a rock.

Of course, you could claim that the drive is at fault. Now, the same drive works perfectly when attached to either my MacBook Pro, or to my iMac G5, both running Mac OS X 10.5.2. It was formatted and partitioned (single partition, GUID scheme, HFS+ journalled filesystem) on the iMac G5. As in, freshly reformatted and repartitioned once again in a desperate attempt to make it work with AEBS. Run Disk Utility's "Repair Disk" on it too, just in case.

Now, when the drive is attached to either Mac and shared from it, the other Mac can mount it wirelessly and even do Time Machine backups to it, without any problems. So, you know, the drive itself seems in order. But if I connect it to the AEBS, it kills the AEBS. AEBS firmware is also upgraded to latest, 7.3.1. I wanted to reduce the clutter on my desk by moving the HDD and its wires to the AEBS and am fairly frustrated with the inability to do so.

I repeat: the symptoms have nothing to do with Time Machine. With Time Machine off, and trying to access the drive over AEBS as a vanilla networked volume, AEBS dies in a minute or so. I suspect a firmware bug.

And then there's the speed.

My MacBook Pro is a first-gen Core Duo, meaning it can only use 802.11g, and can't be upgraded to use 802.11n. Still, 802.11g is 54 MBit/sec, right? Well, the fastest data transfer rate I could achieve moving data to the AEBS-attached HDD (before it crapped out) was a bit over 8 MBit/sec. On a distance of few feet between the devices. Not happy. I can understand various protocol overheads would chip off the bandwidth but I can't understand getting 14% of advertised bandwidth. Not even if it were half-duplex.

Okay, what about Ethernet access? I tried connecting over Ethernet to see whether the AEBS crashing problem is inherent to Wi-Fi, or is also present over Ethernet (result: it is present over Ethernet too). The MacBook Pro said the connection is 1000MBit/sec - fair enough, as both it and the AEBS are supposedly Gigabit Ethernet. Both devices use speed and duplex autoselect based on the cable actually plugged in. So, with 1000MBit/sec theoretical maximum speed, what effective throughput could I get? 72MBit/sec, tops. It ain't the HDD that's slow - it's a 7200RPM drive with USB 2.0, and when connected directly to the computer it is pretty much screaming fast.

And then there are application compatibility problems.

My wife Kriszti speaks quite a lot with her aunt over Skype, and with AEBS she experiences much more stalled audio/video over Skype. I actually subscribe to two broadband connections: a 4MBit cable and also a 1MBit ADSL as a backup. I moved the old router to the 1MBit ADSL (which previously wasn't available over wireless, being only a backup). When Kriszti had repeated Skype problems, I told her to switch to using the old wireless router, and lo and behold Skype works okay for her again, so her Mac tends to remain connected to the old router's wireless network (so our machines aren't on the same network, which is also a source of inconveniences). So: cable ISP with old router = Skype ok; cable ISP with AEBS = Skype not okay; ADSL ISP with old router = Skype okay. There's a pattern here, although in order to be able to claim with 100% certainity that it's a problem with AEBS, I'd also need to test Skype with AEBS connected to the ADSL line which I won't do now as it'd require too much uncabling/hauling/recabling.

So, we have a base station that crashes when you try to use an USB HDD with it, with disappointing speed figures, and apparently also causes problems for Skype traffic. The only really good point is that contrary to the old taiwanese no-name router I replaced, it has a better range and implements WPA/WPA2 in a manner that Windows laptops can also understand; both of these don't really mean anything to me, but it certainly makes the nice girl next door (who we give free Internet access in exchange for occasionally babysitting our kids) lot happier.

All in all, a disappointment.

Running Half-Life 2 natively on Mac OS X

I run Half-Life 2 natively on Mac OS X yesterday evening, in the same configuration I run it on Mac: 1280x1024 resolution, 8x anisotropic filtering, High Dynamic Range bloom rendering, all graphic settings set to "High". It run like charm. I'm impressed. Half-Life 2 was the only reason until today to keep a Windows XP partition on my Mac, and use Boot Camp. But it was inconvenient, the rebooting, even if I did it about once a week on a sunday afternoon for few hours of gameplay.

The magic behind this is called CrossOver Gaming.

Yesterday, I got an e-mail from Codeweavers where they announced CrossOver Gaming Beta. For those unfamiliar, CrossOver is a Wine-based Win32 API compatibility layer for Mac and Linux, allowing Windows application binaries to run natively under these operating systems on machines with x86 CPU architecture. I did test drive CrossOver earlier (that's why I was on their e-mail list), but it left me unexcited, not by its own fault, but really because I had no need for any Windows applications at the time.

I was intrigued by the CrossOver Gaming product though, as it does answer a need I have, namely playing a game I own without needing a reboot (VMWare fusion doesn't run Half-Life 2). Or needing a Windows license. The difference between "regular" CrossOver and CrossOver Gaming is that Gaming will see more frequent releases, will be more bleeding edge, basically less conservative as to what goes into it and frequently updated to accommodate game compatibility problems. You won't necessarily want that from a software that you use to run, say, your Windows-only accounting package, but for games, this model makes perfect sense.

Well, it works pretty much as advertised on the box. It knows of a bunch of "supported" applications, one of them being Steam (and all games available through it). It will install a surrogate HTML library (lacking Internet Explorer, right, there's no Microsoft-shipped mshtml.dll in the system) that allows Steam's built-in store browser to work, then download and install MSXML redistributables and Steam itself. Steam then launched, I logged into my account, downloaded Half-Life 2: Episode One, crossed fingers, and launched it.

It runs just as it did under Windows, and I think I couldn't say anything more praiseworthy about this CrossOver product, even in its beta. I'm totally buying this when it comes out.

I'll briefly mention that there is another player in this space, Transgaming, but unlike Codeweavers, they forked off Wine and aren't donating code back upstream to Wine, so if you need to choose, it seems as if supporting Codeweavers seems like a better option from the moral point of view, as Codeweavers do donate back to Wine. Also, Transgaming's Cedega product doesn't allow users running unaltered Windows games on Mac, only on Linux. They don't offer Cedega for Mac; they have Cider, but that's not a runtime but rather a library that developers need to link against to produce Mac-runnable versions of their games written against the Win32 API. So in reality, CrossOver is the only solution for running a Windows game natively under Mac OS X. Fortunately, it seems to be a good one.

Time Machine + FileVault experiences

I was reluctant to use Leopard's Time Machine "set it and forget it" backup because I also use FileVault (which basically mounts an AES-encrypted disk image in place of your home folder). The web was full of warnings how Time Machine does not work with FileVault, or does but it only backs up your home folder only when you log out, and you lose the ability to restore individual files through the GUI and need to fiddle with manually mounting the backed up images if you want to fish out something from them. Seeing however how I was getting undisciplined with my manual backup routine, I decided it can't be worse than having no backups, and went ahead and gave it a try.

At first, I was surprised to see that contrary to advertised, it did actually back up the encrypted disk image that hosts my home folder. It did it every hour. Every hour, it'd push the 30GB disk image over to the other drive. That filled it up, well, rather quickly.

Digging around, it turns out that the reason for this is that I kept using the Tiger-created FileVault, that uses a single file for the disk image. And Time Machine will happily back it up. 30 GB/hour.

So, next step was trying to upgrade to Leopard FileVault format, which uses a new "sparsebundle" disk image format, which is basically a folder with 8-MB files called "stripes" that hold the contents of the disk, plus some other files for tracking what's where. The ugly part of it is that in order to "upgrade" FileVault, you have to actually turn it off first (so it unpacks your disk image contents on the main filesystem), then re-enable it. I left it to decrypt over night (it probably only took an hour, but I left it there and went to sleep), then re-encypted in the morning (which took 40 minutes for 15GB of content). And then a secure wipe of the free disk space.

An immediate enormous benefit is that my disk image shrunk from 30GB to 15GB. That's right: my old disk image took 30GB even when it was hosting only 15GB of content, and no amount of compacting would've taken it lower. And it wasn't because of filesystem slack - inspecting the image with Disk Utility showed that there's indeed 15GB in there reserved but not used.

Now it's only 15GB, as I would expect it to be, with another 15GB reclaimed on my HDD. Hooray.

Another enormous benefit is that I no longer have Time Machine push 30GB over the FireWire every hour. Whenever I log out though, FileVault will compact the disk image (as it did in Tiger), and then Time Machine will back up - only those 8-MB stripes that actually changed, so the process is rather quick.

It is easy to understand why doesn't Time Machine back up the FileVault home directory while it's mounted - it would be too easy to back it up in inconsistent state as data is shuffled across stripes. Of course, I wish Apple engineers had more time to think about this, and solved it in a smarter way. I myself could tell them two better ways to handle this:

One: add a shadow file to the disk image while backing up to hold concurrent changes, merge changes into the image file upon backup finish. The underlying BSD foundation of the OS supports this. It would, however, probably create a perceptible temporary freeze of the system while the changes in the shadow file are merged with the disk image.

Two: create a similar encrypted disk image on the backup drive, mount it when the backup reaches the home folder, and just perform the whole Time Machine backup procedure between two disk images. I actually had a homegrown solution that did precisely this using rdiff-backup back on Tiger. Actually, when I first heard of Time Machine, I sort of hoped Apple will base it on rdiff-backup, and use this method to handle FileVault accounts.

rdiff-backup has the advantage that it can incrementally back up small changes in large files using the rsync algorithm (Time Machine copies whole modified file each time), and my method also preserved this incremental backup property in FileVault accounts, on a per-file basis, preserving both filesystem and backup semantics. I guess they lacked one smart guy in the engineering division for Time Machine, who was probably busy helping the iPhone division make their deadline... Oh well.

Anyway, now with tolerably fine-grained FileVault backups, I'm happy. Yes, I need to log out in order for my home folder to get backed up, but I was doing this for a while anyway, using CCC or Disk Utility to copy the whole internal disk to external. I used to do backups once a week; now I get automatic backup of the system every hour (which could come in handy if ever, say, a software install goes awry; never happened on Mac with me before though), and automatic backup of my home directory whenever I log out (which is not less frequent than once per week). Of course, the majority of my machine's state change happens in my home folder, so having its backup be more frequent than the system backup would of course be preferred, but such are compromises - I can't afford to run without FileVault.

(You might ask what happened with my homegrown rdiff-backup solution? It fell victim to my switch from a PowerPC to Intel Mac, as it would've required me to recompile a bunch of GNU stuff from source (rdiff-backup and its paraphernalia) which I didn't have time to do at the time of the switch, so it fell into oblivion...)

Java 6 on Leopard. Well, almost

So, it looks like there's finally a developer preview of Java 6 for Mac OS X Leopard. Am I happy? Nope. Why? Here's why:

		CPU Architecture
		PowerPC	Intel
CPU bits	32-bit		Machines I have
	64-bit	Machines I have	Machines running Java 6

It only runs on Macs with 64-bit Intel CPU. Now, I have a 64-bit PowerPC Mac, and I have a 32-bit Intel Mac, but no 64-bit Intel Mac, so no cake for me. Darn. Hopefully the final release will run on all hardware that Leopard itself can run on.

Boot Camp experiences

So, I used Boot Camp (2.0, the one that comes with Leopard) to install Windows XP on a small (16 GB) partition on my MacBook Pro. Reason being that Half-Life 2 won't run under VMWare Fusion...

I'll summarize the experience here, with emphasis on problems I encountered and how to get around them.

First, the good things. In contrast with older Boot Camp versions (1.0 and 1.1 for Tiger), you no longer need to burn a CD with Windows device drivers for Apple hardware. They are now included on the Leopard install DVD, so after Windows is installed, you just need to pop in the Leopard DVD into the drive, and let Windows autorun feature start up the driver installer from it. It will also install Apple Software Update in Windows, and it will presumably keep the drivers up to date (there are no updates right now, so I can't verify this. It will offer to install QuickTime and iTunes though...). Mac keyboard extras work perfectly (volume control buttons, brightness control buttons, eject button). All hardware - graphics, sound, wireless seems to be perfectly supported. The trackpad gestures also work as expected. I only maybe wish they could have made the Windows recognize Cmd+Tab instead of Alt+Tab for application switching...

Now for the first obstacle: Windows would not display image on the external display attached to my MacBook Pro no matter what I did. Others reported the problem on various message boards, with different proposed solutions. After several dead ends, I went exploring on my own. (Note: this solution works for MacBook Pro machines with an ATI chipset.) I ended up downloading ATI Catalyst Software Suite. It unpacks into "C:\ATI" folder by default. Within that is "C:\ATI\CCC" (for "Catalyst Control Center") folder, with a "setup.exe". It will tell you that it needs .Net 2.0 runtime to run. You can get it here.

So, install .Net 2.0 runtime, then the Catalyst Control Center (CCC). Don't try to install the full ATI suite, as it will not succeed, only install CCC. Launch CCC after installed. There is a tab where you can enable/disable various outputs and specify their order. Turns out the ATI chip in my MacBook Pro has 3 outputs (built-in display and two externals), of which two are enabled (built-in and one external), and one external is disabled. The trick is to disable the default enabled external output, and enable the one that was disabled! Voila, the external display lits up! (Regardless of whether you're connecting directly via DVI, or, as I do, through a DVI-to-VGA adapter -- there were reports on the net claiming only DVI displays will work. Fortunately, this is wrong.) Finally, you can use CCC to swap the order of the displays; if you want the external display to be the primary display (one carrying the start button and the tray (as I do)), you'll also do this.

That's all there is to it.

Second obstacle: with a newly created Windows partition, Spotlight had problems after booting back to Leopard. It started indexing it, and never finished. It was pegged at "3 minutes remaining" for about a day, and couldn't be used for searching during this time. This was particularly painful for me, as Spotlight in Leopard is so much improved that I use it all the time, especially as a lightning-quick application launcher. Solution was to disable Spotlight for the Windows partition. I guess you could do it using Spotlight preferences, but I did it by typing

sudo mdutil -i off /Volumes/Windows \HD

from Terminal. (Of course, your Windows partition might be named differently, i.e. "NO NAME" instead of "Windows HD".) This immediately stopped indexing, and Spotlight was usable again. This might be a problem for you if you keep some content you wish to search on your Windows partition, but since I only keep few games on it, it's not a big deal for me.

Other than these two issues, I experienced no problems and am a happy camper (pun intended).

13949712720901ForOSX

13949712720901ForOSX

Working Java 6 on Mac OS X - but not from Apple

Turns out there's a working Java 6 for both Mac OS X Tiger and Leopard. It is a port of the Java Research License licensed codebase for BSD, so to use it legally, you need to agree to JRL first. It's developed by a person named Landon Fuller, and he says on the page:

The Mac OS X work is based heavily on the BSD Java port, which is licensed under the JRL. The BSDs develop Java under the JRL; FreeBSD has negotiated a license with Sun to distribute FreeBSD Java binaries based on the JRL sources.

As the Mac port stabilizes, I am merging my work upstream into the BSD port, and in turn, it is a goal of the FreeBSD Java project to merge their work into OpenJDK. I've signed a Sun Contributor Agreement in preparation for this...

There are some minor features lacking (minor if you're like me, using Java for server side): sound doesn't work yet, nor is there a native Aqua Swing UI.

Via Charlie Nutter (who also perftested it with JRuby and sounds quite impressed).

New MacBooks finally have 3D graphics in hardware

I just noticed that new MacBook models ship with Intel GMA X3100 graphics chipset instead of GMA 950 in previous models. Notable difference is that X3100 has 3D rendering hardware - a shader processor with 8 execution units fully supporting transform & lighting, with support for DirectX 10.

That's quite a big news for people who previously dismissed MacBook as an option because of weak graphics chipset (i.e. people who'd dual boot into Windows for gaming).

On the downside, GMA X3100 still doesn't have dedicated RAM, and it'll actually take away 144MB of system RAM (160 if you use an external display), compared to 80MB that GMA 950 used, so YMMV.

Leopard firewall breaks Skype

Apparently, Skype.app on Mac self-modifies its application package. Leopard OTOH digitally signs application packages after you download them from the net and allow them to run, and also when you allow them to accept connections through firewall. Skype's self-modification causes the signatures to get invalidated. After this, Skype will completely fail to launch. It'll bounce twice in the dock, and that's it.

Options: (a) don't use Skype (b) disable firewall. Damn. I'm going with (a) until Skype fixes this. Actually, I tried disabling the firewall, and for me even that didn't help. Double damn.

Leopard so far

This Thursday, I upgraded my MacBook Pro to Mac OS X 10.5 Leopard. It was a holiday over here, so I had four days (Thursday to Sunday) to work out the wrinkles in case something didn't work. I did the usual precautions: mirror the boot drive to an external drive, boot from the mirror to make sure it works, then shut down the computer, physically disconnect the external drive, and only after all this start the OS install.

I decided to give myself a chance to avoid reinstalling everything, and thus chose the "Upgrade" option instead of a clean install. After an hour of DVD consistency check and an hour of copying files, the machine rebooted and I was greeted by a working Leopard. It went incredibly smoothly.

I proceeded checking whether everything works. First on the list was Cisco VPN Client which I need for work. I was sceptical, as the Cisco VPN client integrates tightly into the system, installing kernel extensions for networking. To my very pleasant surprise - it worked! Next was ssh, which also worked. VMWare also works, no problems there.

Then there's some more arcane stuff:

An unsupported printer driver for my Xerox Windows-GDI printer, cross compiled to a PowerPC binary from a Linux CUPS driver - works!

My heavily customized, start-on-boot MySQL setup - works!

There's of course no Java 6 yet, as discussed earlier, but the good news is Java 5 is at least upgraded from 1.5.0_07 (found in Tiger) to currently latest 1.5.0_13 in Leopard.

Eclipse 3.2.2 works overall. There are keyboard issues though. I.e. if I press Command+Shift+U ("Occurrences in File"), it brings up a context menu (to choose among "Identifier", "Implementing Methods", and "Throwing Exceptions"). However, both the menu and editor window receive the keyboard events for arrows, and when I hit Return, the context menu disappears altogether (without performing the selected operation), and the key is interpreted by the editor (i.e. inserts a new line...). That's one minor annoyance.

One of my pet peeves is also fixed finally: I can finally use the Return key to activate the "Allow" button in Keychain Access' "Copy to Clipboard" dialog. Oh, progress! Previously, if I didn't want mousing, I had to do Tab-Tab-Tab-Return. Still no keyboard equivalent to invoke the said dialog though... Also, the "new password assistant" palette now syncs with the password field, so I needn't copy/paste a generated password back to the main editor window of Keychain Access anymore. Yeah, small things, but they do matter.

Also, there was something amiss in my user account in Tiger - lots of programs forgot their license number when I logged off (Delicious Library and Disco most prominently), and it also lost my keyboard shortcuts whenever I logged off, so after a while I lost the habit of using custom shortcuts, as you can imagine... Upgrading to Leopard fixed both issues.

The system is noticeably snappier. Tiger had the tendency to stall under heavy load. "Heavy" is when I run a Terracotta server and two clustered Tomcat instance on the MacBook Pro, talking to a special Linux appliance running in VMWare, occasionally recompiling the code or interactively debugging from Eclipse. Oh, and running a BitTorrent client in the background to boot it. Now, Tiger did have issues with this even with 2GB of RAM, to the point of UI freezing up for 20-30 seconds whenever I switched applications with Command-Tab. Leopard tolerates such loads much better. I guess virtual memory management got smarter with regard to handling applications' working sets, and there are probably lots of minor kernel optimizations and reentrancy improvements. Overall, noticeably better. Lot less beachball sightings.

As for games: Diablo II works nicely even on an Intel mac (it's a PowerPC binary). Of course, only when you install it using the "carbonized" installer, the version on the CD requires Classic subsystem, which is gone from Leopard.

Age of Empires III has issues though. In single player, all is dandy, but playing in network is completely borked by network sync issues. Few seconds into a multiplayer session it'll say "Out of sync. Exit and try again". Truth be told, the other machine still had Tiger on it when my son and me tried it; I installed Leopard on it since.

After two days when I was sufficiently convinced that it works okay, I installed it on my wife's iMac G5 as well, and faced an interesting limitation. You know those custom iChat backgrounds Apple showcases as new iChat features? The ones where you can have the room behind your back replaced with a moving Niagara falls scenery? Well, you won't get them on a PowerPC Mac. I wanted to try it out for fun between our two machines, but the iMac's 2.1GHz G5 CPU is apparently not strong enough for them. Intel Macs only. Now, come on, Apple, I don't buy it. You probably just had a nice hand-optimized assembly with MMX and SSE instructions in there somewhere, and couldn't be bothered to port it over to PowerPC AltiVec. You know, the one you touted as being the superior vector unit. I think we're experiencing the first signs of PowerPC users falling out of grace. I don't want to sound dramatic, but I mean, I can maybe, just maybe understand a G4 not being strong enough for this task, but a 2.1 GHz G5? What about people with dual or quad G5s? This is a minor, but sad letdown.

Also, my MacBook Pro took on the habit of waking up at precisely 1:00:00 AM every night after the Leopard upgrade, without anything being set in the com.apple.AutoWake.plist file. Since 1 AM in my timezone (GMT+1) is actually midnight GMT, I suspected this to be some stray zero making its way into EFI or something. Pretty much, after I overwrote it by setting "Start or wake up every day" in Energy Saver to 9 AM, the phenomenon went away.

Well, that's it so far. I'm also fooling around with XCode 3. It's a very polished development environment, and I'm toying with the idea of creating some native Mac OS app. Y'know, just to unbox myself a bit from my "server side Java" box and try the "desktop app in Objective-C" world for change.

Scapegoating for Java crisis on Mac OS X

So, pretty much all Java developers working on Mac OS X are filling up the blogosphere (sorry for using the cheesy term) screaming how Apple left them behind not releasing Java 6 for Leopard. This article (via DF) summarizes the overall sentiment (and somewhat hysterical atmosphere). Apple's own java-dev list is another place where people are raising concerned voices.

It's understandable where this outcry comes from. Go to any major Java conference. The Mac laptops are totally over-represented in the audience.

I could well be among them. I'm guilty of amplifying the "Macs are everywhere" effect at conferences myself with my MacBook Pro. I too am a Java developer working on Mac OS X.

I just see a different perspective to things. First off, it always struck me as actually very unnatural that Sun ships Java for Windows, Linux, and Solaris, but does not ship it for Mac OS X. I don't feel let down by Apple here.

I feel let down by Sun.

Sun already publishes a JDK and JRE for three different OS platforms. How hard would it be for them to publish it for Mac OS X as well?

It appeared to me that Sun just recently started natively supporting OpenOffice on Mac OS X. The concept is not completely alien to them, then.

Looking realistically, what is the supposed rationale behind having Apple ship Java for Mac OS X? My educated guess is that the reasons are twofold:

One, OS X was originally so small marketshare-wise that Sun simply couldn't be bothered. They probably had they doubts about the success of the OS. So Apple undertook porting Java to increase the potential software base of the OS and its overall utility. Remember, Mac OS X at the time was still quite young. Hopefully this has changed by now, especially seeing how lots of Sun employees also use Mac OS X. So there's me hoping that in 2007, Sun could actually be bothered.

Two, Apple provided some Apple-specific functionality, like Swing that looks almost like native Mac UI, plus a Cocoa bridge (which is not updated to keep up with Cocoa improvements for quite some time, and is declared by Apple to not be updated ever again).

Don't get me wrong, but the vast majority of Java developers on Mac doesn't give a shit about either Swing or Java-Cocoa bridge, or anything else there might be. Java isn't doing particularly well on desktops; strong Java market is on the server side. As a consequence, vast majority of Java developers don't deploy their software on Mac OS X. They deploy it on enterprise irons that typically run Linux or Solaris. I'm in this crowd.

Let me repeat: I don't give a flying shit about Mac OS X specific Java functionality. If I wanted to write a Mac desktop app, I'd use Objective-C. If I wanted to write a cross-platform desktop app (ha!), I'd probably first talk myself out of it, and if I really couldn't, I'd go for SWT. I'd be more than happy with Java on Mac that allows me to do my command line and server side stuff. I wouldn't care that it has us an ugly looking UI with Swing (as it does on all other platforms, anyway).

And I firmly believe it is Sun's job to give us one, not Apple's.

If you're following what Apple is doing with its developer strategy, it'd be clear to you Apple doesn't have any interest in Java on Mac OS X, and I can't actually blame them for that. Apple is slowly abandoning lots of technologies. It is slowly abandoning Carbon (Carbon will have no 64 bit support, ever). Apple is slowly abandoning non-Cocoa QuickTime bindings (they too will have no 64 bit support). Apple's developer strategy is unification: everything is Cocoa and Objective-C.

In an interesting twist that seemingly (but only seemingly) contradicts what I wrote above about unification, Apple ships Ruby and Python bundled with the OS. However, please observe that both of these are (a) open source and (b) support compiling on Mac OS X in their mainline source code. That is to say, the original developers of the code provide OS X support by sprinkling required #ifdef blocks around the code. Apple just needs to take it and bundle it, without further tailoring. That's what they do. To Apple, Python and Ruby are just Darwin-level tools. And even if they didn't bundle it, it'd be trivial for anyone to compile them from the source and install. Fink and DarwinPorts can give you newer versions of either if you need them. Neither (a) nor (b) can be said of Java. OpenJDK is not Java. Not yet. Sun is definitely heading in the right direction with open sourcing Java, but they started too late to avoid this particular crisis.

Relying on Apple to deliver the Mac part of the WORA promise was a mistake, one that could be easily seen by anyone for years, as Mac users were getting their JDK updates with six months or longer delays compared to platforms serviced by Sun. Sun would've had plenty of time to act upon this mistake.

Again, is it Apple's fault that we don't have an industry-grade open-source Java implementation that supports Mac OS X in its mainline source code? I don't think so. If you want to be angry at someone, or better yet, you want to petition someone about the situation, please direct your energies at Sun.

UPDATES:

• OS X Java Definitive Timeline shows the problem of letting Apple - a party for who Java is low-priority business - take care of delivering it on its platform: worst lag in release schedule was 21 months for Java 1.4 to show up in Mac OS X.


• Also there, Comic: Apple’s Pathetic Java Support? Oh Really? saying

  Dear Steve,
  
  Writing your own JDK is really hard. Maybe you should follow Microsoft’s lead and let Sun do the dirty work?

  Well, yeah, if only Sun wanted to do it.


• In Shipping means prioritizing Gruber also reinforces my point:

  Perl, Python, and Ruby pretty much compile out of the box on Mac OS X. Apple doesn’t have to do much at all — at least relative to Java — to include them on Mac OS X. Why? Because that’s how these tools are designed and engineered — they’re made to “just build” on any Unix-like OS. It’s not Apple’s responsibility that Java isn’t like that — it’s Sun’s.

  He's also quite confident we'll see Java 6 in Mac OS shipped soon, if the timeline above is any indication.

Fastest Vista laptop is MacBook Pro

According to PC World's "The Most Notable Notebooks of 2007" article, of all laptops they tested this year, the one that runs Windows Vista fastest is - MacBook Pro! They conclude with:

... MacBook's score is far more impressive simply because Apple couldn't care less whether you run Windows.

(Via Daring Fireball)

MacHeist

Via Lifehacker:

MacHeist Bundle is a bundle of 10^* highly popular Mac shareware applications. This week only (which means for the next 2 days and 18 hours now), you can purchase them in a bundle for $49 instead of their combined list price of 308$.

Additionaly, 25% of your purchase goes to charity.

What are you waiting for?

^*To be completely honest, it's 9 apps at the moment. 10th app is TextMate, and it'll get unlocked (meaning a license code will be sent to everyone who purchased the bundle) if the total raised for charity reaches $100k. It's currently at $67k, so there's realistic chance to get TextMate too as part of the bundle.

AAC is better than MP3, Walkman instead of iPod, and what Think Different means to me

Fun fact I learned today: AAC encoding sounds better than MP3 at the same bitrate. Seen here. Re-ripping my CDs right now.

I also bought myself a new cellphone, a Sony Ericsson W850i, and despite some concerns I had initially, the gadget is just brilliant. It has a very decent digital music player built-in (Sony markets them under its Walkman brand) and comes with a 1GB memory stick (I can plug in a bigger one, up to 4GB, and am actively considering buying one), and I can just throw music files from my iTunes library to it using Mac OS X built-in Bluetooth File Exchange app, and it'll nicely index them and add them to its own library. Plays both MP3 and AAC, and recognizes Apple's proprietary iTunes metadata. Just sweet. Guess I'll defer buying myself an iPod for now. Kriszti and me are going on a longish trip to Graz for New Year, so we'll see how it holds up against prolonged use, battery life and overall experience-wise. The phone's contact list and calendar are also syncable with Mac's Address Book and iCal using iSync (after buying a plugin online for 1.43 GBP), a critical feature for me.

As a matter of fact, I initially bought a Samsung Z560, since it's the only phone on the continent at the moment offering HSDPA (think GPRS, only at 1.5MB/s!), but had to return it to T-Mobile after an hour of use and a short frantic search on discussions.apple.com after I realized that it can't sync with Mac, and is not likely it ever will. (Why? Because apparently Samsung has several divisions producing cellphones, 
and each of them uses a different sync protocol, and all of them are proprietary...)

And this brings me to the point of that I'm slowly learning what the Apple slogan "Think Different" might mean to me. It means "shake off your Windows-user assumption that any periferial device will work with your computer". I bought a laser printer earlier this year that only works with Mac after installing some cross-compiled Linux drivers. I bought a cellphone that doesn't sync with Mac (fortunately could exchange it for another). I've learned the lesson. I'm shopping for a joystick now, but am not even looking at anything that doesn't feature "Mac compatible" on the box. There's simply no such thing as "maybe it'll work". It's either "it is supported and then Just Works(tm)", or it is "don't even try". In very rare circumstances you can find stuff that is not supported, but works with more or less effort, but it is really a question of dumb luck. Like Sony Ericsson W850i (with a 3rd party plugin - although to be perfectly honest, Apple supports all Sony Ericsson phones, W850i is just too new, and next release of iSync will probably support it out of box), or my Xerox laser printer (works if you dare install a cross-compiled inux CUPS driver). Think Different = Don't Assume It'll Work. Get Used To Doing More Research Than When You Used Windows.

New Gear

I bought a MacBook Pro. It's a first-gen 15.4" 1.83GHz Intel Core Duo piece - it was the only one that the dealership could ship quickly, so I sacrificed 170 MHz per CPU core rather than having to wait one month for the machine to ship. I ordered a +1GB RAM stick and a bigger HDD, but they managed to screw up the order, so these will arrive next week. Sheesh.

The reason I bought a MBP: I need mobility. I realized that while my iMac G5 is an absolutely satisfying machine for all my work, it falls short if I need to do work, but kids insist that I take them down to a playground. Or we want to spend the weekend in our hobby garden out of town, and I want to have a computer with me for evenings. Also, lugging the 11kg 20" iMac is possible - I proved this to myself taking it with me from Szeged, Hungary to Reading, UK and back - but by no means a pleasant experience. (There were no problems with airport security, mind you - Heathrow has a policy that you must take your laptop out of the bag and have the bag and the laptop screened separately. I argued that my computer is not a laptop, and they let me not have to unpack it from its iLugger, thank God. The screening lady cheerfully said "Look, this guy carries a big computer screen with him!" to a passing colleague, so that I can feel like a complete dork.)

Anyway, I'm typing this on the MBP now, after a rather painless transition - all my files, applications, and settings were transferred automatically from the iMac. I had a strange incident though - when the setup got to setting up wireless, I forgot that my router is locked down and will only accept connections from predefined MAC addresses. After two unsuccessful attempts (I thought I forgot the password), the setup froze, and I had to reboot it. It was rather painless afterward though, but since the second time I opted to not transfer data from another machine (would take another three hours), I had to create a local account that I later deleted.

Also a hopefully minor problem - I have to reinstall Fink, so it's bootstrapping in the background as I'm writing this, fingers crossed it'll all work. The nice thing is, the Fink binaries transferred from the iMac actually worked after the migration, as the Rosetta (Mac OS X's built-in PowerPC CPU emulator) picks them up, but various update processes quickly notice that the CPU architecture suddenly changed to x86, and get mightily confused, so it looks like the best idea is to recompile everything from scratch. It does make me a bit anxious though. Fingers crossed, as I said.

Ok, so which one?

Problem at hand: Apple's line of Intel CPU equipped laptops is now complete, so you'd want to purchase one. Okay, but which one exactly?

The middle MacBook model and the middle MacBook Pro models look to me to have the best bang-for-buck value.

The only problem with MacBook is that I'd essentially have to start with throwing out the 2x256MB RAM modules and install 2x512MB third-party modules in them, or alternatively ordering it with at least 1GB BTO (whichever is cheaper). I'm running my current iMac G5 with 1.5GB RAM, and I definitely need at least 1 GB. So, that's already upping the price. With a MacBook Pro, I could keep the 1x512 MB and stick another 1GB in the second slot for 1.5GB (yeah, I know that using identical modules allows you double RAM transfer rates, but believe me, 1.5GB saves you a lot in transfer rates to and from a swapfile in return).

Also, would probably want to upgrade the HDD to at least 100 GB in the MacBook. The only real difference then between the MacBook and the Pro would be in the display size and the graphics chipset. Since I'm not really doing lot of 3D gaming, the graphics chipset is not much of an issue and a MacBook with 1GB RAM (80MB gone to the graphics chipset) and a HDD expansion would probably suffice me. The display size is not an issue as at home, I'll be connecting it to an external monitor anyway.

So, all in all, with 2x512MB RAM and 100GB HDD, a MacBook costs $1600, and the MacBook Pro costs $2200. For $600 extra, you get a bigger screen, a better graphics chipset, one ExpressCard slot. However, the advertised battery life is 1.5 hour shorter for MacBook Pro.

Well, looks to me that MacBook is winning on my pro/contra sheet, especially after applying a $600 saving to the "pro" side. I also just read the Ars Technica review of the MacBook, and they basically conclude the same. They even disclose that the HDD is very easily replaceable, so maybe it's worth not buying an upgraded HDD from Apple, but rather buy a beefy 120GB 7200RPM drive on my own instead.

April fool's day come late

Sounds like they're April 1 jokes, but they're not:

Apple officially supports dual-booting Windows and Mac OS on Intel-based Macs.

Microsoft offers its Virtual Server software free, with official support for running Red Hat Linux on it.

My head is spinning... (disclaimer: I can perfectly understand the market motivations for both moves. It's just that I didn't consider them very likely...)

Wore out a Mighty Mouse in 3.5 months

My iMac was shipped with a Mighty Mouse back in November last year. I'm sorry to report that I wore out its little scroll ball in only three and a half months of use - it no longer gives a clicky sound when I'm rolling it down, and accordingly doesn't detect the roll. (Scrolling up, left, and right still function normally, only the most heavily used scroll down doesn't.) At $49 retail price this is no cheap mouse, so I kinda expected it to sustain more wear... Just phoned the Apple dealership and they promised the service guys will look at it...

My brand new pointless obsession

The press is loud with performance comparisons of iMac G5 and iMac Intel systems, generally showing a mixed picture with an average advantage being on Intel's part. I was wondering how much compiler optimizations contribute to the performance differences. I mean, stock PPC binaries for commercial apps and even Mac OS X clearly can't be fully optimized for G5 given that they need to run on G3 and G4 processors as well.

Looking at default XCode settings for "Cocoa Application" project template, it defaults to instruction scheduling optimization for G4, not G5, although you can switch it to G5 (that equals -mtune=970 in GCC, I assume). In XCode, the GCC switch for enabling G5 specific instructions isn't even easily accessible! You need to rewrite the architecture string from the generic "ppc" to "ppc970", and sneak in the -mcpu=970 in the "Other C flags" setting, all manually -- XCode GUI won't assist you in any of this. Then again, probably no commercial software out there utilizes these settings in order for their software to be able to run on a pre-G5 CPU as well.

So, I'm currently obsessed with the following question: is it possible to build "Universal binaries" that carry not only two code versions - generic PPC and Intel, but three of them: generic PCC, PPC970, and Intel. I verified that XCode has no problems building the code if I modify the architecture setting to "ppc ppc970 i386". I could confirm that the generated executable indeed has these three platforms in it. However, the code was rather trivial, and - except for few debug symbols - the generic PPC and the G5 code was identical.

So, my current challenge is to create an executable that hosts PPC and PPC970 architecture code (as a matter of fact, Intel is pretty much irrelevant for this experiment), have the PPC970 code be fully optimized for G5, and have Mac OS X load it instead of generic PPC code on a G5 CPU.

Of course, I have very limited time resources to spend on this newly acquired "hobby" since this has nothing to do with things I do for a living, meaning I get to devote time to it only when I manage to sneak away from family for half hours on evenings. It's however a good vector for getting myself acquainted with generic hacking of this new OS platform. I really need a bit of an intellectual change of air, as I've been too Java focused for the last 7 years.

Taking out the pain from C development on Mac OS X

Those of you who know me know me mostly as a Java developer for the last, say, 7 years of my professional life. While that's true - Java work pay my bills - I also occasionally hack C. Not that it doesn't have Java implications; when I hack C, I hack the source code of JamVM, an open source interpeter-only Java VM. Well, I'm not hacking JamVM proper, but instead I have a private fork of it that is extended with detailed execution tracing; it is something I do as part of my academic research on dynamic slicing of Java programs.

Now, going from developing in Java back to developing in C can be, well, intimidating. When I started hacking JamVM, I was still using a Windows machine. Given how JamVM is a project built on UNIX, using standard automake/autoconf approach, I had a bit of a system mismatch there that for certain details unfortunately not even Cygwin could bridge. So I ended up with a Linux running inside a VMWare instance. Basic work was ok, but if ever I got a segmentation fault, I had hard time wrestling with gdb or any of its supposed GUIs, was wasting countless hours tracking down one bad pointer, and was really nostalgic for long gone years of my commercial C development using Microsoft Visual Studio. Visual being the key here.

Well, I'm working on a Mac now. And it's a whole lot different. First of all, the "official" compiler for Mac OS X is gcc. What does this mean? Well, among other things it means that all of Apple developer tools will seamlessly work with software projects built around the standard GNU automake/autoconf setup. That's right. And one of the most priceless tools (even though it is free) is Shark. Shark is an incredibly versatile profiler, and I was in a need of one, especially since my "instrumented" JamVM was running like molasses. At the university, we finally beat it into good enough shape to call it "correct", and following the "first make it work, then make it fast" maxim, it was time to subject it to some scrutiny and see how to make it faster.

Profiling was as easy as building the code the standard way, using make and make install from command line, launching Shark, starting the jamvm VM with a test Java program, and pointing Shark to its process (Shark's icon changes to red when it's collecting samples from a program - "scent of blood"? LOL). When done, it has awesome data analysis features that really let you find the bottlenecks in a blink of an eye - look at the above linked article for sample screenshots. It will even mark source code lines with little exclamation marks that when clicked present little popup bubbles with performance enhancement suggestions that apply to that line. Hell, if you really need it the stuff even allows you to inspect your code on the machine code instruction level and has a built-in help for all PowerPC machine opcodes!

So, Shark has shown that 80% of the runtime is spent in my tracing code, and most of that in writing the trace event stream to a file. With that knowledge, I introduced a 1MB in-memory buffer for the file, measured with Shark again and saw that the tracing overhead dropped to 57%. Better, but still not good enough. Shark discovered that after this improvement most of the time is now spent in lock spinning on a mutex - the trace stream is serial, but the Java programs are multithreaded, so I had to introduce a mutex to guard the writes. After pounding on this for a while, I realized that I could introduce small (16K) per-thread trace buffers, and only flush each of them into the 1MB file buffer when it either fills up, when the thread dies, or when the thread is forced to cross a write memory barrier as requested by theJava Memory Model. The mutex I used was now not acquired whenever generating a trace event, but only whenever the thread buffer had to be flushed to the file buffer. (Nota bene: I'm aware this will cause a reordering of events in the event stream such that executions of multithreaded programs that contain race conditions will be incorrectly analyzed - however, at the moment, I don't care about insufficiently synchronized programs as they're buggy anyway and have bigger problems than not being correctly sliceable).

After building the thread buffer feature, I started getting "Bus Error" when I run the new JamVM. This is the PowerPC equivalent of the dreaded "Segmentation Fault" on x86 that usually took me between two and four hours of meticulous debugging on Linux to track down. A little readup on the Apple Developer Connection site shown me how to configure an "external build system" (read: automake generated) project with an executable in Xcode, and launch it under its debugger. There was a handy "Auto-attach debugger on crash" option I checked. Sure enough, I started the program, and as soon as it crashed WHAM! I was instantly looking at the exact source code location, with exact stack trace and variables, much like what you're used to when debugging Java programs in Eclipse. Remember, I didn't build the program in Xcode - I built it using its standard configure/make/make install routine. Yet, since Xcode itself builds using gcc, it worked seamlessly. I found the reason for the crash in ten seconds, rebuilt and rerun, found another similar crash, fixed that too in a minute, and finally it run flawlessly. It was as easy as debugging a Java program.

After all was fixed, another run with Shark has shown that the tracing overhead was reduced to 13% of the total run time. We started from 80% - hooray! This is actually much better than it looks like - if you consider that the "useful" program time is say, 1 minute, then 80% overhead means that the ratio of useful to overhead is 20:80 and the program will run for 5 minutes (overhead generating 4 minutes of run time). 13% overhead means the ratio is 87:13, so the program will only run for 1 minute and 9 seconds. So it is practically four times faster than it was!

And the moral of the story? I was able to pinpoint performance bottlenecks and bad memory access errors in minimal time instead of wasting hours, thanks to really world-class Apple developer tools. It's really the same polished usability in these development tools that you're used to with end-user Apple applications: it just works.

At the moment, I'm using Eclipse CDT to work on the JamVM source code and honestly, it has excellent autocompletion even with a macro-heavy C source code like JamVM's, but I'm seriously considering trying to do all future source code editing in Xcode, as I'm sure there's some further nice surprises awaiting there.