Planet Linux Australia
Parallels Desktop for Mac was the first kid on the block to support virtualisation of other PC operating systems on Mac OS X. However, in the past fortnight, I’ve found out that:
- Parallels allocates just a tad too many unnecessary Quartz windows1, which causes the Mac OS X WindowServer to start going bonkers on larger monitors. I’ve personally seen the right half of a TextEdit window disappear, and Safari not being able to create a new window while Parallels is running, even with no VM running. (I’ve started a discussion about this on the Parallels forums.)
- Parallels does evil things with your Windows XP Boot Camp partition, such as replace your ntoskrnl.exe and hal.dll file and rewriting the crucial boot.ini file. This causes some rather hard-to-diagnose problems with some low-level software, such as MacDrive, a fine product that’s pretty much essential for my Boot Camp use. Personally, I’d rather not use a virtualisation program that decides to screw around with my operating system kernel, hardware abstraction layer, and boot settings, thank you very much.
VMware Fusion does none of these dumbass things, and provides the same, simple drag’n’drop support and shared folders to share files between Windows XP and Mac OS X. I concur with stuffonfire about VMware Fusion Beta 3: even in beta, it’s a lot better than Parallels so far. Far better host operating system performance, better network support, hard disk snapshots (albeit not with Boot Camp), and DirectX 8.1 support to boot. (A good friend o’ mine reckons that 3D Studio runs faster in VMware Fusion on his Core 2 Duo MacBook Pro than it does natively on his dedicated Athlon 64 Windows machine. Nice.) The only major feature missing from VMware Fusion is Coherence, and I can live without that. It’s very cool, but hardly necessary.
Oh yeah, and since VMWare Fusion in beta right now, it’s free as well. Go get it.
1 Strictly speaking, allocating a ton of Quartz windows is Qt’s fault, not Parallels’s fault. Google Earth has the same problem. However, I don’t really care if it’s Qt’s fault, considering that it simply means running Parallels at all (even with no VM open) renders my machine unstable.
You know that Which Operating System Are You quiz?
Well, they’re gonna have to expand it to include all six versions of Windows Vista, whenever that decides to be unleashed unto the world. Hello, six versions? With the starter edition only being able to use 256MB of RAM and run three applications at once? Even eWeek says that “you would be better off running Windows 98”. You know what, instead of choosing between Vista Starter, Vista Home Basic, Vista Home Premium, Vista Business, Vista Enterprise or Vista Ultimate, how about I just run Mac OS X or Linux instead, you stupid tossers?
Jesus, the excellent lads over at Microsoft Research (who produce some truly world-class work) must be just cringing when they hear their big brother company do totally insane stuff like this.
Whoops, those of you who had problems downloading Vimacs will find that the download links work properly now. (What the hell, people besides me actually use Vimacs?)
One of the features of the new video iPod (the “Generation 5.5” one) is that it handles videos bigger than 640×480 just fine. This shouldn’t be surprising for geeks who own the older video iPod that plays 320×240 video, since the alpha geeks will know that the older video iPods could play some videos bigger than 320×240 just fine.
A nice side-effect of this is that if you are ripping DVDs to MPEG-4, you can very likely rip them at native resolution: I had zero problems playing Season 2 of Battlestar Galactica on a new video iPod, and it had a native resolution of 704×400. (Note: This is with a standard MPEG-4 video profile, not H.264 baseline low-complexity.) This is pretty cool, since you can now hook up a little video iPod direct to a big-ass TV and know that video resolution is no longer a differentiating factor between DVDs and MPEG-4 video. Now if only the iPod had component video connectors available…
Where’s André in June?
- June 7-10: San Diego (for the History of Programming Languages III conference.)
- June 11-20: San Francisco (for Apple’s WWDC 2007 bash)
- June 20-28: Las Vegas
- June 24-28: Los Angeles
If you’ll be in town on any of those dates or going to HoPL or WWDC, drop me an email!
As an aside, HoPL III looks incredible: Waldemar Celes (Lua), Joe Armstrong (Erlang), Bjarne (C++), David Ungar (Self), and the awesome foursome from Haskell: Paul Hudak, John Hughes, Simon Peyton Jones and Phil Wadler. (Not to mention William Cook’s great paper on AppleScript, which I’ve blogged about before.) Soooo looking forward to it.
I always used to get confused between UCS-2 and UTF-16. Which one’s the fixed-width encoding and which one’s the variable-length encoding that supports surrogate pairs?
Then, I learnt this simple little mnemonic: you know that UTF-8 is variable-length encoded1. UTF = variable-length. Therefore UTF-16 is variable-length encoded, and therefore UCS-2 is fixed-length encoded. (Just don’t extend this mnemonic to UTF-32.)
Just thought I’d pass that trick on.
1 I’m assuming you know what UTF-8 is, anyway. If you don’t, and you’re a programmer, you should probably learn sometime…
I’m not too sure that I can go much farther
I’m really not sure things are even getting better
I’m so tired of the me that has to disagree
I’m so tired of the me that’s in control
I woke up to see the…
Sun shining all around me
How could it shine down on me?
You think that it would notice that I can’t take any more
Had to ask myself,
… what’s it really for?
Everything I tried to do, it didn’t matter
Now I might be better off just rolling over
‘cos you know I try so hard but couldn’t change a thing
And it hurts so much I might as well let go
I can’t really take the…
Sun shining all around me
Why would it shine down on me?
You think that it would notice that I no longer believe
Can’t help telling myself
… it don’t mean a thing.
I woke up to see the…
Sun shining all around me
How could it shine down on me?
Sun shining all its beauty
Why would it shine down on me?
You think that it would notice that I can’t take any more
Just had to ask myself,
… what’s it really for?
—Yoko Kanno and Emily Curtis, What’s It For
Trust in love to save, baby. Bring on 2007!
First, fuel costs are down:
Second, I actually finished an entire tube of Blistex before I lost the stupid thing. I believe this is the second time in my life that this has happened:
Fourth, my personal inbox looks like this right now:
Zero messages, baby. Yeah! (Well, OK, my work inboxes still have a ton of messages… but zero personal mails left is really pretty nice.)
Plus, this is being published from Auckland airport, on the way to San Francisco. Not a bad day at all.
If you haven’t had much experience with the wonderful world of multithreading and don’t yet believe that threads are evil1, Edward A. Lee has an excellent essay named “The Problem with Threads”, which challenges you to solve a simple problem: write a thread-safe Observer design pattern in Java. Good luck. (Non-Java users who scoff at Java will often fare even worse, since Java is one of the few languages with some measure of in-built concurrency control primitives—even if those primitives still suck.)
His paper’s one of the best introductory essays I’ve read about the problems with shared state concurrency. (I call it an essay since it really reads a lot more like an essay than a research paper. If you’re afraid of academia and its usual jargon and formal style, don’t be: this paper’s an easy read.) For those who aren’t afraid of a bit of formal theory and maths, he presents a simple, convincing explanation of why multithreading is an inherently complex problem, using the good ol’ explanation of computational interleavings of sets of states.
His essay covers far more than just the problem of inherent complexity, however: Lee then discusses how bad threading actually is in practice, along with some software engineering improvements such as OpenMP, Tony Hoare’s idea of Communicating Sequential Processes2, Software Transactional Memory, and Actor-style languages such as Erlang. Most interestingly, he discusses why programming languages aimed at concurrency, such as Erlang, won’t succeed in the main marketplace.
Of course, how can you refuse to read a paper that has quotes such as these?
- “… a folk definition of insanity is to do the same thing over and over again and to expect the results to be different. By this definition, we in fact require that programmers of multithreaded systems be insane. Were they sane, they could not understand their programs.”
- “I conjecture that most multi-threaded general-purpose applications are, in fact, so full of concurrency bugs that as multi-core architectures become commonplace, these bugs will begin to show up as system failures. This scenario is bleak for computer vendors: their next generation of machines will become widely known as the ones on which many programs crash.”
- “Syntactically, threads are either a minor extension to these languages (as in Java) or just an external library. Semantically, of course, they rhoroughly disrupt the essential determinism of the languages. Regrettably, programmers seem to be more guided by syntax than semantics.”
- “… non-trivial multi-threaded programs are incomprehensible to humans. It is true that the programming model can be improved through the use of design patterns, better granularity of atomicity (e.g. transactions), improved languages, and formal methods. However, these techniques merely chip away at the unnecessarily enormous non-determinism of the threading model. The model remains intrinsically intractable.” (Does that “intractable” word remind you of anyone else?)
- “… adherents to… [a programming] language are viewed as traitors if they succumb to the use of another language. Language wars are religious wars, and few of these religions are polytheistic.”
If you’re a programmer and aren’t convinced yet that shared-state concurrency is evil, please, read the paper. Please? Think of the future. Think of your children.
1 Of course, any non-trivial exposure to multithreading automatically implies that you understand they are evil, so the latter part of that expression is somewhat superfluous.
2 Yep, that Tony Hoare—you know, the guy who invented Quicksort?
Two years ago, I had a wonderful job working on a truly excellent piece of software named cineSync. It had the somewhat simple but cheery job of playing back movies in sync across different computers, letting people write notes about particular movie frames and scribbling drawings on them. (As you can imagine, many of the drawings that we produced when testing cineSync weren’t really fit for public consumption.) While it sounds like a simple idea, oh boy did it make some people’s lives a lot easier and a lot less stressful. People used to do crazy things like fly from city to city just to be the same room with another guy for 30 minutes to talk about a video that they were producing; sometimes they’d be flying two or three times per week just to do this. Now, they just fire up cineSync instead and get stuff done in 30 minutes, instead of 30 minutes and an extra eight hours of travelling. cineSync made the time, cost and stress savings probably an order of magnitude or two better. As a result, I have immense pride and joy in saying that it’s being used on virtually every single Hollywood movie out there today (yep, even Iron Man). So, hell of a cool project to work on? Tick ✓.
Plus, it was practically a dream coding job when it came to programming languages and technologies. My day job consisted of programming with Mac OS X’s Cocoa, the most elegant framework I’ve ever had the pleasure of using, and working with one of the best C++ cross-platform code bases I’ve seen. I also did extensive hacking in Erlang for the server code, so I got paid to play with one of my favourite functional programming languages, which some people spend their entire life wishing for. And I got schooled in just so much stuff: wielding C++ right, designing network protocols, learning about software process, business practices… so, geek nirvana? Tick ✓.
The ticks go on: great workplace ✓; fantastic people to work with ✓; being privy to the latest movie gossip because we were co-located with one of Australia’s premiere visual effects company ✓; sane working hours ✓; being located in Surry Hills and sampling Crown St for lunch nearly every day ✓; having the luxury of working at home and at cafés far too often ✓. So, since it was all going so well, I had decided that it was obviously time to make a life a lot harder, so I resigned, set up my own little software consulting company, and start working on Mac shareware full-time.
Outside of the day job on cineSync, I was doing some coding on a cute little program to build websites named RapidWeaver. RapidWeaver’s kinda like Dreamweaver, but a lot more simple (and hopefully just as powerful), and it’s not stupidly priced. Or, it’s kinda like iWeb, but a lot more powerful, with hopefully most of the simplicity. I first encountered RapidWeaver as a normal customer and paid my $40 for it since I thought it was a great little program, but after writing a little plugin for it, I took on some coding tasks.
And you know what? The code base sucked. The process sucked. Every task I had to do was a chore. When I started, there wasn’t even a revision control system in place: developers would commit their changes by emailing entire source code files or zip archives to each other. There was no formal bug tracker. Not a day went by when I shook my fist, lo, with great anger, and thunder and lightning appeared. RapidWeaver’s code base had evolved since version 1.0 from nearly a decade before, written by multiple contractors with nobody being an overall custodian of the code, and it showed. I saw methods that were over thousand lines long, multithreaded bugs that would make Baby Jesus cry, method names that were prefixed with with Java-style global package namespacing (yes, we have method names called com_rwrp_currentlySelectedPage), block nesting that got so bad that I once counted thirteen tabs before the actual line of code started, dozens of lines of commented-out code, classes that had more than a hundred and twenty instance variables, etc, etc. Definitely no tick ✗.
But the code—just like PHP—didn’t matter, because the product just plain rocked. (Hey, I did pay $40 for it, which surprised me quite a lot because I moved to the Mac from the Linux world, and sneered off most things at the time that cost more than $0.) Despite being a tangled maze of twisty paths, the code worked. I was determined to make the product rock more. After meeting the RapidWeaver folks at WWDC 2007, I decided to take the plunge and see how it’d go full-time. So, we worked, and we worked hard. RapidWeaver 3.5 was released two years ago, in June 2006, followed by 3.5.1. 3.6 followed in May 2007, followed by a slew of upgrades: 3.6.1, 3.6.2, 3.6.3… all the way up to 3.6.7. Slowly but surely, the product improved. On the 3rd of August 2007, we created the branch for RapidWeaver 3.7, which we didn’t realise yet was going to be such a major release that it eventually became 4.0.
And over time, it slowly dawned on me just how many users we had. A product that I initially thought had a few thousand users was much closer to about 100,000 users. I realised I was working on something that was going to affect a lot of people, so when we decided to call it version 4.0, I was a little nervous. I stared at the code base and it stared back at me; was it really possible ship a major new revision of a product and add features to it, and maintain my sanity?
I decided in my naïvety to refactor a huge bunch of things. I held conference calls with other developers to talk about what needed to change in our plugin API, and how I was going to redo half of the internals so it wouldn’t suck anymore. Heads nodded; I was happy. After about two weeks of being pleased with myself and ripping up many of our central classes, reality set in as I realised that I was very far behind on implementing all the new features, because those two weeks were spent on nothing else but refactoring. After doing time estimation on all the tasks we had planned out for 4.0 and realising that we were about within one day of the target date, I realised we were completely screwed, because nobody sane does time estimation for software without multiplying the total estimate by about 1.5-2x longer. 4.0 was going to take twice as long as we thought it would, and since the feature list was not fixed, it was going to take even longer than that.
So, the refactoring work was dropped, and we concentrated on adding the new required features, and porting the bugfixes from the 3.6 versions to 4.0. So, now we ended up with half-refactored code, which is arguably just as bad as no refactored code. All the best-laid plans that I had to clean up the code base went south, as we soldiered on towards feature completion for 4.0, because we simply didn’t have the time. I ended up working literally up until the last hour to get 4.0 to code completion state, and made some executive decisions to pull some features that were just too unstable in their current state. Quick Look support was pulled an hour and a half before the release as we kept finding and fixing bugs with it that crashed RapidWeaver while saving a document, which was a sure-fire way to lose customers. Ultimately, pulling Quick Look was the correct decision. (Don’t worry guys, it’ll be back in 4.0.1, without any of that crashing-on-save shenanigans.)
So, last Thursday, it became reality: RapidWeaver 4.0 shipped out the door. While I was fighting against the code, Dan, Aron, Nik and Ben were revamping the website, which now absolutely bloody gorgeous, all the while handling the litany of support requests and being their usual easygoing sociable selves on the Realmac forums. I was rather nervous about the release: did we, and our brave beta testers, catch all the show-stopper bugs? The good news is that it seems to be mostly OK so far, although no software is ever perfect, so there’s no doubt we’ll be releasing 4.0.1 soon (if only to re-add Quick Look support).
A day after the release, it slowly dawned on me that the code for 4.0 was basically my baby. Sure, I’d worked on RapidWeaver 3.5 and 3.6 and was the lead coder for that, but the 3.5 and 3.6 goals were much more modest than 4.0. We certainly had other developers work on 4.0 (kudos to Kevin and Josh), but if I had a bad coding day, the code basically didn’t move. So all the blood, sweat and tears that went into making 4.0 was more-or-less my pride and my responsibility. (Code-wise, at least.)
If there’s a point to this story, I guess that’d be it: take pride and responsibility in what you do, and love your work. The 4.0 code base still sucks, sitting there sniggering at me in its half-refactored state, but we’ve finally suffered the consequences of its legacy design for long enough that we have no choice but to give it a makeover with a vengeance for the next major release. Sooner or later, everyone pays the bad code debt.
So, it’s going to be a lot more hard work to 4.1, as 4.1 becomes the release that we all really wanted 4.0 to be. But I wouldn’t trade this job for pretty much anything else in this world right now, because it’s a great product loved by a lot of customers, and making RapidWeaver better isn’t just a job anymore, it’s a need. We love this program, and we wanna make it so good that you’ll just have to buy the thing if you own a Mac. One day, I’m sure I’ll move on from RapidWeaver to other hopefully great things, but right now, I can’t imagine doing anything else. We’ve come a long way from RapidWeaver 3.5 in the past two years, and I look forward to the long road ahead for RapidWeaver 5. Tick ✓.
svk—a distributed Subversion client by Chia Liang Kao and company—is now an essential part of my daily workflow. I’ve been using it almost exclusively for the past year on the main projects that I work with, and it’s fantastic being able to code when you’re on the road and do offline commits, syncing back to the main tree when you’re back online. Users of other distributed revision control systems do, of course, get these benefits, but svk’s ability to work with existing Subversion repositories is the killer reason to use it. (I’m aware that Bazaar has some Subversion integration now, but it’s still considered alpha, whereas svk has been very solid for a long time now.)
The ability to do local checkins with a distributed revision control client has a nice side-effect: commits are fast. They typically take around two seconds with svk. A checkin from a non-distributed revision control client such as Subversion requires a round-trip to the server. This isn’t too bad on a LAN, but even for a small commit, it can take more than 10 or 15 seconds to a server on the Internet. The key point is that these fast commits have a psychological effect: having short commit times encourages you to commit very regularly. I’ve found that since I’ve switched to svk, not only can I commit offline, but I commit much more often: sometimes half a dozen times inside of 10 minutes. (svk’s other cool feature of dropping files from the commit by deleting them from the commit message also helps a lot here.) Regular commits are always better than irregular commits, because either (1) you’re committing small patches that are easily reversible, and/or (2) you’re working very prolifically. Both of these are a win!
So, if you’re still using Subversion, try svk out just to get the benefits of this and its other nifty features. The svk documentation is quite sparse, but there are some excellent tutorials that are floating around the ‘net.
My dad’s been on a Steven Seagal action movie rampage, recently. How many friggin’ movies has this guy made, you think? A half-dozen? A dozen? Nope, thirty-two. And they’re all exactly the damn same, although some of them have hilarious titles (such as Today You Die, Half Past Dead and Out for a Kill) with equally hilarious taglines (“Whoever set him up is definitely going down”).
Please add Steven Seagal to the list of heroes who I want to be when I grow up. Life just can’t be that bad when you keep starring in action movies with hot Asian chicks in half of them.
It’s rare that I find a good, balanced article on the (dis)advantages of static vs dynamic typing, mostly because people on each side are too religious (or perhaps just stubborn) to see the benefits of the other. Stevey’s blog rant comparing static vs dynamic typing is one of the most balanced ones that I’ve seen, even if I think half his other blog posts are on crack.
I lean toward pretty far toward the static typing end of the spectrum, but I also think that dynamic typing not only has its uses, but is absolutely required in some applications. One of my favourite programming languages is Objective-C, which seems to be quite unique in its approach: the runtime system is dynamically typed, but you get a reasonable amount of static checking at compile-time by using type annotations on variables. (Survey question: do you know of any Objective-C programmers who simply use id types everywhere, rather than the more specific types such as NSWindow* and NSArray*? Yeah, I didn’t think so.) Note that I think Objective-C could do with a more a powerful type system: some sort of parameterised type system similar in syntax to C++ templates/Java generics/C# generics would be really useful just for the purposes of compile-time checking, even though it’s all dynamically typed at runtime.
One common thread in both Stevey’s rant and what I’ve personally experienced is that dynamic typing is the way to go when your program really needs to be extensible: if you have any sort of plugin architecture or long-lived servers with network protocols that evolve (hello Erlang), it’s really a lot more productive to use a dynamic typing system. However, I get annoyed every time I do some coding in Python or Erlang: it seems that 50% of the errors I make are type errors. While I certainly don’t believe that static type systems guarantee that “if it compiles, it works”, it’s foolish to say that they don’t help catch a large class of errors (especially if your type system’s as powerful as Haskell’s or Ocaml’s), and it’s also foolish to say that unit tests are a replacement for a type system.
So, the question I want to ask is: why are programming languages today so polarised into either the static and dynamic camp? The only languages I know of that strive to accommodate for the benefits of both are Objective-C, Perl (though I’d say that writing Perl without use strict is an exercise in pain, since its only three types are scalars, arrays and hashes), and (gasp) Visual Basic. Programming languages and programming language research should’ve looked at integrating static and dynamic typing a long time ago. C’mon guys, it’s obvious to me that both approaches have good things to offer, and I ain’t that smart. I think a big reason they haven’t is largely for religious reasons, because people on both sides are too blinded to even attempt to see each other’s point of view. How many academic papers have there been that address this question?
I hope that in five years, we’ll at least have one mainstream programming language that we can write production desktop and server applications in, that offer the benefits of both static and dynamic typing. (Somebody shoot me, now I’m actually agreeing with Erik Meijer.) Perhaps a good start is for the current generation of programmers to actually admit that both approaches have their merit, rather than simply get defensive whenever one system is critiqued. It was proved a long time ago that dynamic typing is simply staged type inference and can be subsumed as part of a good-enough static type system: point to static typing. However, dynamic typing is also essential for distributed programming and extensibility. Point to dynamic typing. Get over it, type zealots.
P.S. Google Fight reckons that dynamic typing beats static typing. C’mon Haskell and C++ guys, unite! You’re on the same side! Down with those Pythonistas and Rubymongers! And, uhh, down with Smalltalk and LISP too, even though they rule! (Now I’m just confusing myself.)
One o’ me good mates, sent me an email recently with a rather chortle-worthy summary of the HumanTerran plot of Starcraft I. Without further ado:
Raynor: Oh shit, nasty alien things with big teeth. Let’s put our faith in the supremely experienced commander who will save us (after I teach him how to build a command center, barracks and use the ‘repair’ button).
Zergling: Grrrrowl! Yummm!
Raynor: (shoots gun from his cool looking vulture bike)
Zergling: Gah! (dies)
Duke: Raynor. You’re a bad bad man. Why did you kill that cute little Zergling?
Raynor: It tried to eat me.
Duke: Well, tough. You should’ve asked me permission first because I’m the big boss of the Confedration and on one can take a shit unless I say so. Off to prison with you!
Raynor: Help! Get me outa here!
Mengsk: I’ll help! (opens the door) Hi. I’ve got this terrorist label but actually I’m a nice guy. The Confederation are the REAL baddies. Just to prove it, let me introduce you to my hot babe assistant. Remember, only good guys have hot babe assistants.
Kerrigan: Wha! you perv!
Raynor: Huh what? How did you you know that I was thinking about having hot monkey sex with you up against the side of my bike whilst wearing a ballerina’s tutu?
Mengsk: She’s a telepath.
Kerrigan: Well, yes. And you’re staring at my tits.
Duke: Erm… fellas? Sorry to bother you… my ship sorta crashed in the middle of all these Zerg and they want to eat me.
Raynor: Suck ass!
Mengsk: I’ll save you.
Mengsk: Well… Raynor will save you.
Raynow: WHAT!?!?! Oh… ok. (saves Duke)
Duke: Mengsk? YOU! I hate you with the white hot intensity of a thousand suns. I teach children to eat the liver of your dogs. You are a blight on all humanity and the scourge of the universe. The Confederation will never rest until we destroy you entirely!
Mengsk: Join me!
Mengsk: Cool… Duke, what’s say you and I go kill all your former buddies in the Confederation.
Raynor: uh… what about the Zerg?
Mengsk: No no. Much more important to kill Confederates.
Raynor / Kerrigan: uh… why?
Mengsk: Just do as you’re told.
Tassadar: Hey guys. We Protoss honour, respect and revere all sentient life. Therefore, we’re going to incinerate your planet.
Mengsk: Oh shit. That means we don’t get to kill Confederates. Kerrigan, go kill the Protoss so that I can use this Psi-transmitter gadget to lure Zerg to kill Confederates.
Kerrigan / Raynor: Erm… is this making any sense?
Kerrigan: I must do as I’m told because I’m a hot babe assistant. Ok, off I go to kill Protoss and lure Zerg and plant this Psi thingy.
Zerg Overmind: Who’s the hot chick in the catsuit. She’d look even cooler with green blood. I”m going to infest her… this will be fun. (infests Kerrigan) (Then Zerg go on to kill all Confederates)
Mengsk: YAY! All the Confederates died!
Raynor: You suck Mengsk. You too Duke. I’m leaving and coming back in a later chapter filled with vengenace to whomp your sorry asses. I’ll probably fall in love with Kerrigan since I’m the obvious hero and she’s the obvious heroine, but she’s infested with Zerg blood now… but I’ll use love to reach into the depths of her heart and rescue her and turn her back to the light side.
Andrew, please finish the Zerg and Protoss campaigns soon; we’d love to hear more.
I have the small honour of being a speaker at the maiden conference of MacDev 2009, a grass-roots, independently run, Mac developer conference in the UK that’s being held in April next year. MacDev looks like it’ll be the European equivalent of C4, which was absolutely the best Mac developer conference I’ve ever been to; I’d say it’s the Mac equivalent of Linux.conf.au. If you’re a Mac developer at all, come along, it should be great fun, and give your liver a nice workout. Plus, how can you ignore such a sexy list of speakers?
Update: My talk abstract is now available…
One reason for Mac OS X’s success is Objective-C, combining the dynamism of a scripting language with the performance of a compiled language. However, how does Objective-C work its magic and what principles is it based upon? In this session, we explore the inner workings of the Objective-C runtime, and see how a little knowledge about programming language foundations—such as lambda calculus and type theory—can go a long way to tackling difficult topics in Cocoa such as error handling and concurrency. We’ll cover a broad range of areas such as garbage collection, blocks, and data structure design, with a focus on practical tips and techniques that can immediately improve your own code’s quality and maintainability.
I am a great believer in getting the foundations right. Similarly to how bad code design or architecture often leads to a ton of bugs that simply wouldn’t exist in well-designed code, building a complex system on unsteady foundations can produce a lot of unnecessary pain. What are the foundations of your favourite programming language?
It’s 2008 and we’re still seeing buffer overflows in C.
For Mac developers in Australia, I’ll be speaking at the inaugural conference of DevWorld 2008, which will be held from September 29-30 this year in Melbourne. You can check out the full list of sessions; I’ll be giving the very last talk on that page: The Business of Development.
Coding is just one part of what makes a great product, but there’s always so much else to do and learn. So, what can you do to help ship a great product—besides coding—if you’re primarily a developer? In this talk, learn about important commercial and business issues that you, as a coder, can help to define and shape in your company, such as licensing and registration keys, adopting new technologies, software updates, handling support, your website, and crash reports.
Note that DevWorld 2008 is unfortunately only open to staff and students at an Australian university (“AUC member university”, to be exact), so unless you’re a student right now at one of those Unis, you’ll have to miss out on this incredibly exciting opportunity to hear me talk at you for an hour (snort). I hear the story behind this is that if this year’s DevWorld is successful, next year’s will be a more standard open conference. Anyway, hopefully catch some of you there in September!
Enter solid-state drives (SSDs). Unlike hard disks, SSDs contain no moving parts, and are made out of solid-state memory instead. This has two big advantages: first, SSDs don’t crash (although this is a small lie—more on that later). Second, since SSDs are made out of memory, it’s much faster than a hard disk to get to a particular piece of data on the disk. In other words, they have a random access time that are orders of magnitude faster than their magnetic cousins. Hard disks need to wait for the platter to rotate around before the head can read the data off the drive; SSDs simply fetch the data directly from a memory column & row. In modern desktop computers, random access I/O is often the main performance bottleneck, so if you can speed that up an order of magnitude, you could potentially make things a lot faster.
Unfortunately, while SSDs are orders of magnitude faster than a hard disk for random access, they’re also an order of magnitude more expensive. That was until May this year, when this thing appeared on the scene:
(Image courtesy of itechnews.net.)
That boring-looking black box is a 120GB Super Talent Masterdrive MX. As far as SSD drives go, the Masterdrive MX is not particularly remarkable for its performance: it has a sustained write speed of just 40MB per second, which is a lot lower than many other SSDs and typical hard disks.
However, it’s a lot cheaper than most other SSDs: the 120GB drive is USD$699. That’s not exactly cheap (you could easily get a whopping two terabytes of data if you spent that money on hard disks), but it’s cheap enough that people with more dollars than sense might just go buy it… people like me, for instance. I’ve had that SSD sitting in my lovely 17” MacBook Pro for the past two months, as an experiment with solid-state drives. So, how’d it go?
I’ll spare you the benchmarks: if you’re interested in the raw numbers, there are a number of decent Masterdrive MX reviews floating around the Web now. I was more interested in the subjective performance of the drive. Does it feel faster for everyday tasks? Is it simply a better experience?
The overall answer is: yes, it’s better, but it’s not so much better that I’d buy the SSD again if I could go back in time. With a hard disk, things occasionally get slow. I’m sure I’m not the only one to witness the Spinning Beachball of Death while I wait 5-10 seconds for the hard disk to finally deliver the I/O operations to the programs that want them completed. With a hard disk, launching a program from the dock would sometimes take 20-30 seconds under very heavy I/O load, such as when Spotlight’s indexing the disk and Xcode’s compiling something. With the SSD, those delays just went away: I can’t even remember a time where I saw the evil Beachball due to system I/O load.
The most notable difference was in boot time. A lot of people love how Mac OS X is pretty fast to boot (and I agree with them), but when you go to log in, it’s a very different story. If, like me, you’ve got about ten applications and helper programs that launch when you log in, it can take literally minutes before Mac OS X becomes responsive. I clocked my MacBook Pro at taking just over a minute to log in with my current setup on a hard disk (which launches a mere half a dozen programs); the SSD took literally about 5 seconds. 5… 4… 3… 2… 1done. What is thy bidding, my master? I wish I’d made a video to demonstrate the difference, because it’s insanely faster when you see it. 10x faster login speed is nothing to sneeze at.
However, aside from boot up time, normal day-to-day operation really was about the same. Sure, it was nice that applications launched faster and it booted so fast that you don’t need to make a coffee anymore when logging in, but those were the only major performance differences that I saw. Mac OS X and other modern operating systems cache data so aggressively that I guess most of the data you’ll read and write will usually hit the cache first anyway. The lower sustained write performance didn’t end up being a problem at all: the only time I noticed it was when I was copying large torrented downloadsfiles around on the same drive, but that wasn’t slow enough for me to get annoyed. The one benchmark that I really cared about—compiling—turned out to take exactly as long on the SSD as the hard disk. I thought that maybe it was possible that random I/O write speed was a possible bottleneck with gcc; it turns out that’s not true at all. (I’ll also point out that I was using Xcode to drive most of the compilation benchmarks, which is one of the fastest build systems I’ve seen that uses gcc; no spastic libtool/automake/autoconf/autogoat insanity here.) Sorry to disappoint the other coders out there.
Aside from performance, the total silence of the SSD was a nice bonus, but it’s not something that you can’t live without once you’ve experienced it. In most environments, there’s enough background noise that you usually don’t hear the quiet hard disk hum anyway, so the lack of noise from the SSD doesn’t really matter. It was, however, very cool knowing that you could shake your laptop while it was on without fear of causing damage to your data. I’m usually pretty careful about moving my laptop around while it’s on, but with an SSD in there, I was quite happy to pick up the machine with one hand and wave it around in the air (as much as you can with a 17” MacBook Pro, anyway).
So, with all the nice small advantages of the SSD, you may be wondering why it’s no longer in my MacBook Pro. Here’s some reviews of the disk on newegg.com that may give you a hint:
It turns out those reviewers were right. Two months after I bought it, the Masterdrive MX completely died, which seemed like a pretty super talent for an SSD. The Mac didn’t even recognise the disk; couldn’t partition it; couldn’t format it. So much for SSDs not crashing, eh?
While SSDs don’t crash in the traditional manner that a hard disk may, there’s a whole number of other reasons why it might crash. RAM’s known to go wonky; there’s no reason why that can’t happen to solid-state memory too. Maybe the SATA controller on the disk died. No matter what the cause, you have the same problem as a traditional hard disk crash: unless you have backups, you’re f*cked. Plus, since I was on holiday down at Mount Hotham, my last backup was two weeks ago, just before I left for holiday. All my Mass Effect saved games went kaboom, and I just finished the damn game. André not very happy, grrr.
So, what’s the PowerPoint summary?
- The Super Talent Masterdrive MX would be great buy if it didn’t friggin’ crash and burn your data with scary reliability. Even if you’re a super storage geek, avoid this drive until they have the reliability problems sorted out.
- The Powerbook Guy on Market St in San Francisco is awesome. They were the guys to install the SSD in my MacBook Pro, and were extremely fast (two-hour turnaround time), professional, and had reasonable prices. (I would’ve done it myself, but I’d rather keep the warranty on my A$5000 computer, thanks.) Plus, they sold me the coolest German screwdriver ever for $6. (“This one screwdriver handles every single screw in a MacBook Pro”. Sold!)
- The MacCentric service centre in Chatswood in Sydney is equally awesome. When the SSD died, they quoted me the most reasonable price I had ever seen for a hard disk swap in a MacBook Pro (have you seen how many screws that thing has?), and also had a two-hour turnaround time. Yeah, I know, decent Mac service in Australia! Woooooah.
- Back up.
- SSDs are great. I think they’ll complement rather than replace hard disks in the near future, and possibly replace them entirely if the price tumbles down enough. Next-generation SSDs are going to completely change the storage and filesystem games as they do away with the traditional stupid block-based I/O crap, and become directly addressable like RAM is today. Just don’t believe the hype about SSDs not crashing.
I, for one, welcome the solid state society. Bring on the future!
I feel like there’s been four stages to my life. The first stage was being a youngling at primary school: I don’t remember much from there except that I fantasised about handball being an olympic sport. The second stage was the PC demoscene, where I grew interested in many things that I love today about computing: art, music, and my first experience with a community and culture that you could love and immerse yourself in. The third stage was my twenties: an introduction to university, Linux, coding, the Mac, Haskell, research conferences, industry conferences, the working life, and balancing it all with healthy doses of relaxation, food and the beautiful world that Sydney had to offer. The fourth stage was tearing myself away from that fairly sheltered life and my emotional base, and moving to San Francisco.
I’ve been here for six months. It’s felt like two years. It has been a truly wonderful experience: making new friends, learning a new culture that’s both significantly but subtly different, and doing it all without my family nearby, who’ve been my anchor and support for the past three decades. Part of the motivation was proving to myself that I could make it on my own: prove myself worthy in the eyes of my peers, be social enough to make genuine friends here who I cared about and who cared about me, living on my own and simply paying the rent. Part of the motivation was to shake things up from a cruisy life in Sydney and experience new things. I’m glad to report that the experiment’s going pretty well so far.
San Francisco is a city of immense contrast. For every stupid hipster who thinks that owning a Prius absolves them of their environmental debt to society, there are remarkable individuals who understand and challenge the daunting realism of politics, lobbying, energy, transformity and limits to growth. For every poser upstart get-rich-quick guy chasing after VC funding for Facebook apps, there are the quiet anonymous developers at Apple, Google, and startups you’ve never heard of who work on all the amazing technologies that the entire world takes for granted today. The Tenderloin, so unpleasant to walk through, has some of the very best restaurants and bars that the city has to offer. The nouveau shiny high-rises of South Beach contrast with the destitute run-down feel of western SoMa, only a few blocks away.
It’s a make-or-break city: rents are insanely high despite the rent control laws, and there’s no lower-middle class population here because either you’re flying high, or you’re not flying at all. It’s natural selection in action: either you keep up with the pack and continue being successful, or you fall and become left behind. And so, in contrast to the relaxed lifestyle of Sydney, San Francisco is full of ambition. While it lacks the non-stop pace of New York or the late-night industry of Detroit and Chicago, the people here want to change the world, and they have the innovation, the smarts and the determination to do so.
The tech industry here is simply amazing. Despite being here for half a year, I’m still floored when I go to a party and every person I meet there ends up being a Web designer, or a coder, or a sysadmin, or a DBA, or a network engineer, or a manager of a bunch of coders, or a VC funding a tech company, or a lawyer or accountant or marketing or PR person working for a tech company, or a level designer or artist working for a games company. Even the girls. It boggles me. It’s like the entire Bay Area simply exists to build software and iPhones and tech solutions. I was truly daunted in the first few months to find out that everyone around me was, well, just like me. A few months ago, I was at my favourite little tea shop in San Francisco decompressing and minding my own business, when three people sat down next to me and started talking about VGA BIOS exploits. (Turns out that they work for VMware.) I mean, seriously?
I wouldn’t say that I’m totally acclimated to the Bay Area yet, and perhaps I never will be. Visiting Australia just a month ago reminded me just how different the two cities are in their lifestyles. People are always doing something in San Francisco: there’s so many interesting people there that you feel like need to divide your time between groups, let alone having time to yourself. Even the serious introverts there are out on most schoolnights. The people here are always switched on; even at a party, there’s an air of networking going on and the feeling of opportunities to be seized. You almost always end up talking shop at any event, because people here are defined by what they do: one of the very first questions you’re usually asked is “Where do you work?” or “What do you do for a living?”. In Sydney, asking that question so soon would just be a little bit weird. You usually save that for far later in the conversation, when you’re running out of things to say to the pretty girl to try to hook up with her. (And don’t even get me started about the American dating scene.)
And so, for all the wonderful parks, bars, tacos, restaurants, pirate shops and museums of the city; the incredible beauty and varied terrain of the North Bay; the charm and chilled suburbia of North Berkeley in the East; and the innovation and serenity of Silicon Valley just south, I still miss Sydney and the culture I grew up with for twenty years. I don’t mean that in a yearning way or mean to imply that San Francisco is somehow inadequate, because it rocks: I’m having a wonderful time experiencing new things, and it was the right decision to move here. This is where I should be at this stage in my life. Sydney will always be where my heart is, but right now, San Francisco is home, and it’s as fantastic as I hoped it would be.
R. A. Salvatore, Road of the Patriarch, p. 280:
The point of self-reflection is, foremost, to clarify and to find honesty. Self-reflection is the way to throw self-lies out and face the truth—however painful it might be to admit that you were wrong. We seek consistency in ourselves, and so when we are faced with inconsistency, we struggle to deny.
Denial has no place in self-reflection, and so it is incumbent upon a person to admit his errors, to embrace them and to move along in a more positive direction.
We can fool ourselves for all sorts of reasons. Mostly for the sake of our ego, of course, but sometimes, I now understand, because we are afraid.
For sometimes we are afraid to hope, because hope breeds expectation, and expectation can lead to disappointment.
… Reality is a curious thing. Truth is not as solid and universal as any of us would like it to be; selfishness guides perception, and perception invites justification. The physical image in the mirror, if not pleasing, can be altered by the mere brush of fingers through hair.
And so it is true that we can manipulate our own reality. We can persuade, even deceive. We can make others view us in dishonest ways. We can hide selfishness with charity, make a craving for acceptance into magnanimity, and amplify our smile to coerce a hesitant lover.
… a more difficult alteration than the physical is the image that appears in the glass of introspection, the pureness or rot of the heart and the soul.
For many, sadly, this is not an issue, for the illusion of their lives becomes self-delusion, a masquerade that revels in the applause and sees in a pittance to charity a stain remover for the soul.
… There are those who cannot see the stains on their souls. Some lack the capacity to look in the glass of introspection, perhaps, and others alter reality without and within.
It is, then, the outward misery of Artemis Entreri that has long offered me hope. He doesn’t lack passion; he hides from it. He becomes an instrument, a weapon, because otherwise he must be human. He knows the glass all too well, I see clearly now, and he cannot talk himself around the obvious stain. His justifications for his actions ring hollow—to him most of all.
Only there, in that place, is the road of redemption, for any of us. Only in facing honestly that image in the glass can we change the reality of who we are. Only in seeing the scars and the stains and the rot can we begin to heal.
For Rebecca, who holds that glass of introspection higher than anyone else I’ve ever known. Thank you for everything.