zabbo

A significant number of my friends — not exactly newcomers to software! — have embraced OS X. With memories of the early days of the Mac, I was nervous. Allow me to share the story that finally pushed me over the edge.

A few months ago I spent an hour or so configuring X on my Dell X1 to support both the built-in LCD and an external LCD monitor. There were a few scary moments where I, being human, screwed up the configuration of which pipe went where and gave the laptop’s LCD some very bad refresh rates. Luckily it wasn’t damaged.

When I finally got it working the result was pretty cool! Windows flowed off of one LCD and onto the other. I had to logout and edit the config file to disable the second display, or change its resolution or anything, of course. That’s just how X rolls.

Then a week later Alice plugged that very same LCD into her MacBook Pro and it just worked. Live. We tried unplugging it with apps on the display being unplugged and they were moved back onto the remaining laptop LCD. Holy crap!

Step back for a moment and imagine that we’re talking about something other than the dizzyingly complex world of software and computers. An expert using tool A gets mediocre results after an hour of risky work and any user instantly gets superior results using tool B. Why on earth would anyone chose tool A?

That was roughly my line of thinking when Apple released the MacBook Pros with the Core 2 Duo. I broke down and ordered one. That was about two weeks ago and I’m happy to report that things have gone as well as I’d hoped they would. I haven’t had to fight the hardware support battles that are sadly present in the Linux world. I’m appreciating having apps that work nicely together. I think this is the first time that I’ve had the significant players in my contact game — phone, palm, mail app — all talking to each other.

I was down in the bay at Oracle HQ last week. I was asked to give a presentation. I threw together some slides with Keynote. I plugged the projector in and hit the “Play” button and had each slide on the projector and the presenters display — the current and next slides, time spent total and on the current slide — on the local laptop LCD. Even the most mouth-foamy Linux advocates had to admit that this was neato.

Don’t get me wrong. Linux is a fantastic tool for a non-trivial set of problems. Our customers certainly have some serious problems that they prefer to solve with Linux. My day job is still working with Linux. I’m damn good at it and I enjoy it. This leads me to Parallels, the current leader of the OS X PC virtualization pack. It was trivial use an FC6 ISO on the network to install Linux in a virtual machine. I now have a window, which I can full-screen if I so desire, that offers the comfortable Linux environment. Hence the title of this post — I didn’t give up Linux in exchange for OS X. I made it so I can use the modern desktop in OS X to avoid trivial hurdles while solving hard problems for people with Linux. I’m one happy camper. A hoopy frood, if you will.

I couldn’t end this post without mentioning Quicksilver. I was referred to it about a week into my OS X experience. I have been using computers for nearly all my life and I can say this with a straight face: Quicksilver has changed the way I interact with the computer. I will not attempt, and no doubt fail, to clearly describe it in depth. Tutorials exist for that level of introduction. I will, however, share this example of the keystrokes required to bring up my dad’s (a.k.a. Doug) entry in Address Book at any time: control-space, d, o, u, return. I now take this kind of warm-knife-through-butter efficiency for granted.

Part of my job at Oracle has involved working on a project called RDS. Over the past few months I’ve found myself failing to explain it clearly to friends who have asked what exactly this is. For their edification, if nothing else, I thought I’d take a few minutes to describe the project in more detail.

We can set the stage by laying out the basic properties of a certain kind of Oracle deployment that one often finds at customer sites. Imagine a few thousand processes on a handful of nodes. Each process is doing work and sending messages to many other processes. The one to many relationship starts to explain why this messaging is currently implemented with UDP with acknolwdgement and retranmission handled in the processes. Using TCP, for example, could mean holding a TCP connection open between each pair of communicating processes. The overhead of doing this adds up surprisingly quickly.

The attentive will quickly spot a problem with implementing reliability in the processes. If these processes are performing work that blocks waiting for IO, which they are, the acks that they send could be delayed. This could cause a sending process to spuriously retransmit a message that was in fact received but not acknowledged promptly. “Mmmm hmmm”, I might say to such an attentive person. This problem is seen under heavy load.

At some point Infiniband became an attractive potential solution to this problem. One of the things it can do is push reliability constructs into hardware so that the processes need not burden themselves with the task of promptly sending acks. uDAPL was attempted but didn’t work out. I get to avoid having to tell that story because I don’t know it — it was before my time. SDP is a socket API built on top of Infiniband which would take care of reliability, but it has per-process-pair overhead problems like TCP.

This is when RDS started to take shape. It was designed as a socket API which would let processes send messages from one socket to many recipient processes. Reliability is ideally provided by hardware and the cost of doing so should not increase significantly with the number of processes involved in communication. A prototype was written for the 2.4 kernel which implemented RDS on top of Infiniband.

This is when the Oracle messaging people started talking to me about getting involved. They were looking for an implementation for 2.6 that could also support RDS on top of commodity ethernet. As initially described it sounded like they wanted some ethernet level protocol. This explains my earlier blog post about RDS/eth. We hadn’t quite gotten to understanding each other at that point. It eventually became clear that they wanted a 2.6 implementation that supported RDS on top of various transports — “reliabile connection queue pairs” for Inifiniband and TCP for commodity ethernet.

That, in the end, is what has been built as is now available in a subversion repostory found off of http://oss.oracle.com/projects/rds/. It’s a kernel socket API which maintains connections between nodes and multiplexes messages between processes down those per-node connections. There are lots of interesting (and occasionally surprising) details, but perhaps those are better saved for another post. At least now I hope folks will have a better understanding of what it is I mean when I talk about “that freaking RDS thing.”