changing the default JVM on OSX Leopard
I’ve been using a bit of Java lately, and the OSX 1.6 JVM seemed pretty stable.
JRuby is the next thing on my geek list, and that runs best on Java 6.
Although the 1.6 JDK was installed in the last system update, it’s not the default:
hypnotoad:Desktop $ /usr/bin/java -version
java version "1.5.0_13"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-237)
Java HotSpot(TM) Client VM (build 1.5.0_13-119, mixed mode, sharing)
hypnotoad:Desktop $
hypnotoad:~ $ ls -l `which java`
lrwxr-xr-x 1 root wheel 74 30 Apr 10:07 /usr/bin/java -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java
hypnotoad:~ $ cd /System/Library/Frameworks/JavaVM.framework/Versions/
hypnotoad:Versions $ ls -ld Current*
lrwxr-xr-x 1 root wheel 1 30 Apr 10:08 Current -> A
lrwxr-xr-x 1 root wheel 3 30 Apr 10:07 CurrentJDK -> 1.5
I know what you’re thinking. Don’t.
Re-pointing those symlinks seems to work, but in fact
it breaks all your GUI apps (the ‘A’ is for AWT)::
hypnotoad:Versions $ jconsole
2008-05-20 23:26:20.524 jconsole[680:10b] Apple AWT Startup Exception : ** -[NSCFArray insertObject:atIndex:]: attempt to insert nil
2008-05-20 23:26:20.525 jconsole[680:10b] Apple AWT Restarting Native Event Thread
Instead, you want to open
/Applications/Utilities/Java/Java Preferences.App
and tell it you want to use 1.6:
hypnotoad:~ $ java -version
java version "1.6.0_05"
Java(TM) SE Runtime Environment (build 1.6.0_05-b13-120)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_05-b13-52, mixed mode)
hypnotoad:~ $
( ignore the text about ‘when an applet is executed in this browser’ - Intel Safari is 32-bit, and if you’re on PPC you don’t get JAVA 6 anyway ).
That Steve Jobs has a great sense of humour.
this site best viewed in…
This mornings WebKit nightly build rendering the Acid3 test:
And look! Firefox painted me a beautiful picture too:
That’s lovely, sweetheart.
Guess who’s not regretting switching a couple of months back.To be fair, Opera apparently scores very highly too (both its users must be delighted).
portal on OSX under Crossover
Unless you live under the sea, you know a few ways to run windows apps on a Mac. Obviously, the only ‘windows apps’ worth having are games, which means DirectX support. Options include:
- BootCamp is pretty fast, but rebooting into windows is no way to spend your time.
- Parallels somehow trashed my BootCamp partition. We hates it.
- VMware Fusion has DirectX support, and Unity mode (which lets apps run in ‘native’ windows).
a golden hammer to crack a nut
VMware runs a full Windows install, which has plenty of downsides:
- you waste a windows install worth of disk space (a big deal on a laptop)
- you waste a lot of ram running another OS
- windows needs baby sitting : patching, virus scanning
- you need a windows license
- you need a VMware license
- (pet hate) my Dvorak keyboard layout, trackpad gestures etc. don’t carry over into VMware
The real problem here is that I’m using a virtualized OS to run 1 program.
I’d argue that most people don’t want a Windows installation, they just need to run a few Windows apps (I’d also argue that’s true on non VMed Windows machines, but that’s another rant).
merlot the magician
WINE is an implementation of the win32 APIs on *NIX. Instead of a VM, you just run .EXEs on your UNIX machine.
Back in my NetBSD days, I used it to run things like Morpheus and Kazaa - setup was a bit fiddly, but performance was good and it saved me having to reboot.
Crossover is a commercial app that lets you run multiple WINE ‘bottles’ (essentially a directory tree and a config file). There’s a free 30 day trial and it supports Steam, so thought I’d try it out. Choose ‘Steam’ from the list of supported apps, Crossover makes a new bottle for it, installs some fonts and off we go:
After creating a Steam account, it set off and downloaded Portal from the Net. Installation couldn’t have been easier, and Crossover plays nicely with OSX - clicking links in the Steam app opens webpages in Safari, for example. Hardware support is impressive - the microphone works fine, for example :
cd install gotcha
When you insert a Windows CD, Crossover runs Setup.exe and builds a bottle for the app on the fly.
You can get stuck at the ‘please insert disk 2’ messages; OSX can’t eject because Crossover has the disk in use.
Just open Terminal.app and run ‘sudo umount -f /Volumes/Orange\ Box’.Then hit F12 to eject the disk, put in disk 2 and let OSX remount it.
tweak settings
I run it windowed because I want to see my desktop (otherwise I might as well BootCamp and be done). A nice man has some very useful launch options for Orange Box on a Macbook - my Macbook Pro seemed happy with :
-heapsize 512000 -width 1440 -height 900 –window -novid
you will be baked, and then there will be cake
Crossover costs around 30 quid with an education discount.
Civ4 for mac is 40 quid (and no cheaper on ebay). Windows Civ4 is about a tenner. So Crossover and Civ4 pays for itself, whether or not you get Windows for free. A few of my old PC games look like they’d work too.
I’d rather buy native Mac games where possible, but this is seems like a good solid fallback.
why I hate your freedom
Happy New Thing.
So anyway, Adam Leventhal found out AAPL hamstrung DTrace w.r.t. certain apps on Leopard (iTunes at least). Cue inevitable Slashdottian outrage.
When source code gets released under a license everyone (so long as they follow those terms) gets to port, extend, or shout about how your license isn’t free at all really. They can even choose to ignore you, or to provide really shitty implementations. None of the above makes them ‘evil’.
Some of OS X is open source, some is proprietary, and some is riddled with DRM. iTunes is in the last category. It’s Apples main cash cow; if it was reverse engineered they’d lose a competitive advantage, scare their movie/music business partners away, and the terrorists would win.
OSX ships with a full toolchain and part of that is Instruments - a GarageBand-like frontend to DTrace. It’ll probably be the first contact with DTrace a lot of coders get. I’ve only tinkered with it, but right away you can see why it’d make DRM fans twitchy. Running iPhoto under Instruments let me see down into the Cocoa API calls. I now know how atomic preference changes are implemented at the system call level. Basically, it’s fucking great.
It was really nice of Apple to give it out for free, just like it was nice of Sun to give us DTrace, ZFS and NFS. Telling either company how they should release any of those products makes you a bit of a deRaadt in my book.
ZFS, Leopard and baseless speculation
Just upgraded my work mac to Leopard. Took an hour, worked flawlessly.
Of course, the first thing I did was stick in a USB stick with holds half a zpool from my Solaris Express box at home:
planb:~ $ zpool import
pool: sticky
id: 4692054964394431575
state: FAULTED
status: The pool is formatted using an incompatible version.
action: The pool cannot be imported.
Access the pool on a system running newer
software, or recreate the pool from backup.
see: http://www.sun.com/msg/ZFS-8000-A5
config:
sticky UNAVAIL newer version
mirror DEGRADED
dsk/c6t0d0 UNAVAIL cannot open
disk3 ONLINE
planb:~ $ zpool import sticky
cannot import 'sticky': pool is formatted using a newer ZFS version
i.e. ” I know this is half of a mirror, but it’s a newer ZFS version than Apples”.
what’s new pussycat?
So I reformatted the disk on my Solaris 10 update 4 box:
vera / # rmformat
Looking for devices...
...
...
3. Volmgt Node: /vol/dev/aliases/rmdisk0
Logical Node: /dev/rdsk/c4t0d0p0
Physical Node: /pci@0,0/pci8086,4c43@1d,7/storage@7/disk@0,0
Connected Device: Kingston DataTraveler 2.0 PMAP
Device Type: Removable
vera / # zpool create sticky c4t0d0p0
This is how it looks on Solaris 10:
vera / # zpool status sticky
pool: sticky
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
sticky ONLINE 0 0 0
c4t0d0p0 ONLINE 0 0 0
errors: No known data errors
vera / # zfs list /sticky
NAME USED AVAIL REFER MOUNTPOINT
sticky 85K 1.87G 24.5K /sticky
So I copied a bit of data on, zpool exported and stuck it back in the Mac.
planb:~ $ zpool import sticky
planb:~ $ zpool status
pool: sticky
state: ONLINE
status: The pool is formatted using an older on-disk format. The pool can
still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'. Once this is done, the
pool will no longer be accessible on older software versions.
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
sticky ONLINE 0 0 0
disk3 ONLINE 0 0 0
errors: No known data errors
planb:~ $ zfs list
NAME USED AVAIL REFER MOUNTPOINT
sticky 30.8M 1.84G 30.7M /Volumes/sticky
planb:~ $ ls -l /Volumes/sticky/
total 3
dr-xr-xr-x+ 4 root sys 6 7 Nov 00:10 local
planb:~ $ touch /Volumes/sticky/bummer
touch: /Volumes/sticky/bummer: Read-only file system
Much better.
pussy galore
Now for the crazy conspicacy theory bit:
planb:~ $ zpool get all sticky cannot get property 'name': pool must be upgraded to support pool properties cannot get property 'bootfs': pool must be upgraded to support pool properties cannot get property 'bootfs': pool must be upgraded to support pool properties
i.e. “this zpool format doesn’t support bootable volumes. but I do.”


