Remembering the Line Ride

I spent the holidays at Disneyland this year with my girlfriend and my family. We stood in numerous lines for hours on end during the busiest week of the year, waiting to see Disney’s take on classic rides such as the Haunted Mansion and Small World.

Their take was fantastic, but this post is not about that.

Standing in line for the Haunted Mansion, listening to people murmur about how agonizing the lines were, it dawned on me that not everybody understood nor appreciated the true origins of these amazing amusement parks. My sister certainly didn’t know, and neither did my girlfriend.

You may not either, so allow me to share a bit of history.

Back to the middle ages

Much of what we’ve come to enjoy in amusement parks originated from fairs in the Middle Ages [1]. The food, the shows. They were further inspired over time by other events and inventions throughout the centuries that followed. One of the innovations in amusement technology that really sparked the modern era of amusement park rides was a classic mechanical ride, the steam-powered carousel, built by Thomas Bradshaw at the Alysham Fair in 1861 [2].

The problem with technological innovations is that they overshadow the simpler pleasures that came before them.

The Line Ride

Long before the carousel, in 1733, people enjoyed a simpler tradition. The humble fairgrounds in those days were unlike the marvels we have today, but were still full of events for children and adults of all ages.

One of the most beloved traditions in those days was known as the Rope Line Ride, or the Line Ride for short. Long lines of rope, attached to tall stakes in the ground, would be laid out in all sorts of patterns, forming paths for the kids to traverse. Common patterns included the spiral, the back-and-forth, and the weave.

Participating in the Line Ride was simple. A person would start at one end, following the line, seeing where it took them (by a garden, perhaps, or a wall of funny drawings), eventually coming out on the other side.

Remember, these were the days when Kick the Can and Hoop Rolling were the rage. The Line Ride was so popular that it was often nearly full of people, but this gave them time to socialize and join together in the admiration of their surroundings.

Evolution of the Line Ride

Times change, as they often do. While once a fun and common attraction, the younger generations began to grow weary of the Line Ride. In 1861, Thomas Bradshaw, the aforementioned inventor of the steam-powered carousel, forever changed the Line Ride by making it a means to an end. He put the carousel at the very end of the Alysham Fair Line Ride.

Now, instead of simply enjoying the Line Ride for what it was, people were passing through it, with great impatience, just to get to the all-new steam-powered carousel.

A new tradition was born. The Line Ride no longer became an attraction itself, but rather simply the Line, a way to control the flow of people leading up to an attraction. This was seen as a very controversial change in its day — after-all, the Line Ride was a tradition going back over a hundred years — and with it came a distrust of the newer attractions by the older generations. Of course, time passed, and the Line became the norm.

The spirit carries on

While often forgotten as an attraction, the Line Ride’s spirit remains today in our terminology and our parks. We’re all familiar with celebrities walking down the rope line, or hearing about people “working the rope line.”

And, of course, the long, grueling lines leading up to the popular attractions at amusement parks and carnivals around the world.

A new adventure begins

Act 1, Scene 1

August 23rd, 2004. A young kid, not even 21, freshly dropped out of college, passionate about open source and programming. He walks into his new office at his new job at VMware, his first job, ready to start the day, eager to impress and meet his new co-workers.

Nobody was there. Thumbs twiddled.

10AM starts to roll around, and finally, the first sign of life. Over the next couple hours, more people show up.

Over the next week, he’s set up and learning the ropes. Working on his first bug, soon his first feature. Attending his first team get-togethers. Making his first Bay Area friends.

Over the next few months, his first birthday celebration at work. His first glass of champagne. His first real responsibilities.

Over the next few years, bigger roles, leadership roles. He began to get a feel for where he’s truly going in this silly little world.

This, of course, was me, on my first adventure in the tech industry.

I was lucky to be placed in a fantastic team full of smart, hard-working, dedicated, and fun software engineers and managers. We’d discuss architecture, brainstorm ideas, joke around, watch YouTube videos, play poker, watch movies, go to events. The web of awesome people extended throughout the company as well.

Over the past nine years, I worked on a great many things.

  • Eight releases of VMware Workstation, including a three-year effort to build Workstation 8.0 (a major undertaking).
  • VMware Server 1.0. I was the primary Linux developer, pulling caffeine-fueled all nighters to meet insane deadlines.
  • Player and VMRC, which powers the VM console for our enterprise products.
  • The core foundation used in Fusion and other products.
  • Icons and artwork for the Linux products.
  • I introduced Unity to Workstation. (Sorry, guys…)
  • Helped in the creation of the current generation of the View client for Linux.
  • More recently, I developed WSX, an experiment in developing a pure web client and console for accessing remote VMs anywhere, from desktops and tablets.

Not a bad run.

This Thursday, August 1st, 2013, I’ll be leaving VMware.

Revision 1: “Add the reviewboard”

Several years ago, I began working with my good friend David Trowbridge on an open source project for keeping track of patches and easing the review process. We spent many years in the open source world looking at raw diffs on bug trackers and in e-mails, and things weren’t that much better at VMware. As Mr. Wonderful says, “There has to be a better way!”

So we slaved away in the late nights and weekends, iterating and iterating until we had something we could use. We named this product “Review Board” (or “the reviewboard,” as our first commit says). We put it out there for people to play with, if anyone was interested.

There was interest. Review Board is now used around the world at companies big and small. We’ve continued to improve and grow the product and turn it into something that developers actually want to use.

We later built a startup around this. Beanbag.

It’s dangerous to go alone. Take this.

Earlier this year, we met a local entrepreneur as part of a program we participate in. We quickly developed a rapport, and he offered to help and advise us in our efforts to grow our business. It wasn’t long after that we started discussing funding, and where that could get us.

We started pitching, and he reached out to his contacts. Before long, we had what we needed to give this a try for a couple years.

Step 3: Profit?

There’s a lot of hard work ahead of us, but we’re up to the challenge. It’s both exciting and terrifying.

Leaving my team behind at VMware is hard, but everyone has been so supportive.

IMG_0720

Basically.

In the coming months, Review Board’s going to grow in exciting new ways. We’ll be gearing up for a new 1.8 release, releasing our first commercial extension to Review Board, and improving our SaaS, RBCommons. We have a pretty good idea where we want to go from here, and now we can better focus on making it happen.

It’s going to be an awesome adventure.

VMware WSX 1.0.1, and the new Community Page

Last month, we released WSX 1.0. Those following along with the beta knew what to expect, as it was largely our latest Tech Preview release with some more fixes thrown in.

Unfortunately, we also threw in a regression that we’ve since been working to fix. The console would, at times, stop displaying anything, just appearing black. Clicking the little Refresh button would fix it, but it was annoying and, to me personally, quite embarrassing.

Today I’m happy to announce that we’ve released WSX 1.0.1, which has fixes for the black screen issue, and also support for Windows domains in usernames (indicated by “MYDOMAIN\username”) when logging in.

Along with the release, we’ve also introduced the new WSX Community Page, where you’ll be able to find the latest releases, documentation, and discussions on WSX. I’ll be on there, as will some of our QA, to answer questions.

WSX, Meet Retina.

On Friday the 16th, an angel in white, glowing robes delivered a shiny new iPad to my desk, as heavenly music played softly in the background. (I may be misremembering the details.)

The most talked about feature of the new iPad is, of course, the shiny new retina display (a 2048×1536 resolution). A few apps really show this off, and text is certainly crisp, but a few people wondered aloud, “Is it really that big of a difference?” Yes, it is.

Naturally, I had to play around with getting WSX to show a retina-friendly desktop. See, by default, everything is scaled up 2x to simulate the resolution of the original iPad (1024×768), but they have some support in there for loading higher-resolution images. Turns out, with some tricks, you can also make the canvas retina-friendly.

So let me show off what my desktop here looks like with some apps open on the iPad 1.

Okay, that’s a bit crowded, but it’s only a 1024×768 resolution (minus some UI at the top of the screen). How about with the retina display?

Wooo. Looks pretty awesome, right?

Of course, the problem is that everything is very tiny. This is usable if you increase the DPI a bit, but I’m thinking about some magnifying support now. Still, pretty cool.

A Proud Moment: VMware Workstation 8

Today is kind of a career highlight for me. A moment I’m especially proud of. We just released VMware Workstation 8. Code-named “Nitrogen,” this release has been in the planning stages since around the time I joined VMware 7 years ago. It has been in active development for the past 3 years. Easily the longest development cycle we’ve had for Workstation, but also easily the best release we’ve ever done.

Previous users of Workstation will notice quite a lot of improvements to this release. We have a lot of changes, but I want to go into a few that I’ve worked on over the past three years, which I think are of particular interest.

Remoting

Remote Server Connection

This is the big one.

Workstation 8 can share VMs with other Workstation 8 clients. You can run a VM on one system (say, a beefy desktop machine in the back room) and access them from another (say, a light-weight laptop). All the processing happens on the machine running the VM. They can be made to start up along with the system, so you don’t even need Workstation running. You don’t even need X (on Linux).

Users of VMware Server or GSX should find this familiar. We’ve essentially succeeded the Server product with this release, with more features than Server ever had. For instance, one client can connect to multiple servers at once, alongside all your existing VMs.

That’s not all, though. You can also connect to ESXi/vSphere. As a developer, this is something I take advantage of nearly every day. I have an ESXi box running in my back room with several VMs for testing, and a couple for in-home servers. By running on ESXi, I minimize the overhead of a standard operating system, and gain a bunch of management capabilities, but previously I had to use vSphere Client to connect to it. Now I can just talk to it with Workstation.

Hear that, Linux admins? You don’t need vSphere Client running on Windows to connect to your ESXi/vSphere box anymore. That’s a big deal. (Unless you need to do some more advanced management tasks — we’re more about using the VMs, and light customization).

VM Uploading

We also make it easy to upload VMs to an ESXi/vSphere box. Connect to another server, drag a local VM onto it, and the VM will convert and upload directly to it. Super easy. Developing a VM locally and putting it up on a server as needed is just a simple drag-and-drop operation now.

No More Teams

Thumbnail Bar

Teams was a feature that we’ve wanted to rework for a long time. For those who aren’t familiar with them, Teams was a way to group several related VMs together (say, parts of a test server deployment) such that they could be viewed at the same time with a little live thumbnail bar. It offered some support for private virtual networks between them, with each NIC being able to simulate packet loss and different bandwidth limits.

We felt that these features shouldn’t have been made specific to “special” VMs like they were, so we tore the whole thing apart while preserving all the features.

Now, every VM’s NIC can simulate packet loss and bandwidth limits. Any VMs already together in some folder or other part of the inventory can be viewed together with live thumbnails, just like Teams. Any VM on the local system can be part of any other VM’s private virtual network.

It’s much more flexible. The restrictions are gone, and we’re back to using standard VMs, not special “Team VMs.”

Inventory Improvements

Inventory Filtering

You may have noticed the search field in the inventory in my screenshots. You can now filter the listed VMs by different criteria. Show the powered on VMs, the favorites, or search for VMs. Searching will take into account their name, guest OS, or data in the Description field in the VM. The Description searching is particularly helpful, if you’re good at documenting/listing what’s in a VM that you may care about (IE6, for instance).

Favorites

Favorites was reworked. It used to be that every VM in the sidebar was a “favorite.” Now we list the actual local VMs, and we don’t call them favorites. Instead, you can mark one of the listed VMs as a favorite (by clicking a little star beside it) and filter on that.

UI Improvements

Folder Thumbnail View

We’ve streamlined the UI quite a bit. All our menus are smaller and better organized. Our summary pages are cleaner and highlights the major things you want to see.

We have new ways of navigating your VMs, which is especially handy on large servers. You now get a tab for any folder-like node in the inventory showing your VMs in either a list view (with info on power states) or a zoomable live thumbnail view showing what’s happening on each VM.

And Much More

That’s just a few of the major things. There’s many, many more things in this release, but the official release notes will cover that better than me. (Honestly, I’ve been developing and using this release for so long, it’s hard to even remember what was added!)

Tip of the Hat

A lot of great people worked on this release. The engineers that developed the various components across the company. The QA groups who have provided valuable testing to make sure this was a solid release. The product marketing and management teams who kept us going and help draft the goals of this release and market it. The doc writers who spent countless hours documenting all the things we’ve done. Upper management who allowed us to take a risk with this version. Our beta testers who went through and gave us good feedback and sanity checks. And many others who I’m sure I’m forgetting.

I said this already, but I’m so proud of this release and what we’ve accomplished. More effort went into this than you would believe, and I really think it shows.

And now that we’re done, we’re on to brainstorming the next few years of Workstation.

I Invented Port Knocking

Let me tell you about something that’s been bothering me for a while.

I invented Port Knocking. No, really. In 2002.

According to portknocking.org, it was invented by Martin Krzywinski in 2003. I’m not here to debate that he didn’t come up with the idea separately, and choose the same names (it’s a pretty good name for the technology). But I do want to make it clear, for the record.

Wait, hold on, what’s Port Knocking?

Oh, got ahead of myself there.

Port Knocking is a security method where you can cloak a network completely (close all ports or put them in stealth mode) and yet still allow access from any computer in the world, by way of a sequence of “knocks” on a predefined list of ports.

The server can specify a list of ports (say, 53, 91, 2005, 2131, 7) and monitor to see if there are attempts to open them. If an outside computer accesses each of these ports in sequence, without hitting any other ports, and within a time period, the server can open a select set of ports (separate from the knock list) to that IP address only.

In my original designs, before opening the ports after a successful knock sequence, an authentication port would be opened at a predefined port, which the client would have to access, exchanging credentials, before the ports would be open.

And why the controversy?

First, some history.

In mid-2002, I was 18 and interested in security, amongst other things. Along with writing code for Pidgin (then Gaim), and a couple other projects, I was fooling around with firewalls and such.

I had this idea one morning while in the shower to add another layer of security. I really wanted to be able to completely close off my network, but still access it when out of town. I can’t tell you how it came into my head. Just a moment of inspiration. I wasn’t even really looking for another project, just brainstorming, but I liked the idea too much. I started writing code and made it work.

It was a while before I discussed it publicly on my old blog on Advogato. There are many posts, but I’ll highlight a couple here, where I introduce what I was working on:

The blog is full of lots of old teenage angst, so ignore most of it, but I spend the next few weeks going over my progress, answering questions from people who are asking for more information, etc. I was very open about it.

At one point a couple months later, I realized this was stupid. I had a good idea. I should patent it. I took it down for a while. This was after I had already put up the sourcecode, though, and many people had it.

Now, in retrospect, I should have made this into a full-on open source project and gained the recognition myself, continued development. But I was too busy with other things and didn’t really want another major product on my hands. I remember at one point I thought, “maybe I can sell this to a security company, or patent it!”

And since then…

One day, I opened a magazine and saw “port knocking” on the cover. My heart skipped a beat. Somebody wrote an article on my port knocking! I opened the magazine and read through it. “Invented by… Michael Krzywinski? What?!” I re-read to make sure. It was all my terminology, my methods. I was floored.

By that point, he made a name for himself as the inventor. And again, I’m not trying to discredit him, because he very well may have come up with the same thing separately. But it stung, because I had a great idea, a year before he wrote a paper on it, and I didn’t promote it the way he did.

Lesson learned

This is one of those life lessons. You always regret what happened, but you use it to make better decisions in the future. These days, I’m happy working on some awesome products. My day job at VMware and my highly successful code review software, Review Board (for which we’ve recently started a company).

Now, if I have a good idea, I make sure it’s heard, and demonstrated, far and wide. Truly great ideas don’t really come that often, so when you have one, make sure you do something with it, or you may end up regretting it for years to come.

Sentience discovered in the Linux kernel

Ladies and gentlemen, after much experimentation, I have made a remarkable discovery. Perhaps the very first case of a sentient AI has been discovered, sitting right under our noses, in the Linux Kernel. With such a complicated codebase that has evolved greatly over the years, there are certainly more surprising places for it to spring up, but it’s still quite unexpected.

And where, specifically, has this sentience manifested itself? The suspend/resume code.

See now, like many of you, I’ve dealt with the instabilities of suspend/resume. I’ve considered it to just be buggy, unreliable, and possibly incompatible with my hardware. That is, until I realized that there’s a pattern. One that began to make a sort of sense.

A couple months back, I gave suspend/resume another shot, and to my surprise it worked. I figured that Ubuntu 10.04 finally fixed it, but it still wasn’t perfect. I still noticed problems.

The first thing I noticed was that when I unsuspended at work, I couldn’t use my volume keys. Everything else was fine, but my laptop’s volume keys didn’t register as a key press on anything. If I suspended again and brought it back home, the keys would work fine. If I suspended at home and resumed at home, I wouldn’t have the volume key problem. Weird, but just buggy, right?

It was a couple weekends ago when I suspended my laptop to take it somewhere. It wouldn’t suspend at all. Just hard-locked. This continued until the week, when it worked again. Last weekend? Same problem, couldn’t suspend. Monday, it worked fine.

It was then that I realized suspend/resume was breaking deliberately! See, my laptop feels more comfortable at home, less so at work but it tolerates it (with some complaining), but absolutely doesn’t want to leave during the weekend. It’s like a cat that just wants to be in a familiar environment, selfishly vying for your attention through mischievous acts. Look at it hard enough and the pattern emerges. It’s undeniable.

That got me thinking. What other possible instances of AI have we been misconstruing as bugs or random glitches? All those inter-connected street lights that occasionally shut off as you walk underneath them? Maybe they’re just shy, or they hate you. Maybe NES cartridges just found being blown stimulating.

So remember guys. Windows suspend/resume may work just fine. Mac too. But Linux’s suspend/resume isn’t a buggy pile of crap. It’s an intelligent buggy pile of crap, that just wants to be loved.