Difference between revisions of "Bootcamp 2008 Review"
m (Protected "Bootcamp 2008 Review" [edit=sysop:move=sysop])
Revision as of 18:10, 27 May 2008
I thought I’d write a review of the 2008 OpenVMS Advanced Technical Bootcamp, as it might be of interest to others to look at the Bootcamp from a newbie’s perspective. Although, I should perhaps warn you that my observations may be skewed by the fact that – due to the work I’ve been doing on an emulator – I am more familiar with OpenVMS from an Alpha processor’s point of view than from an end-user’s point of view. The time I have spent as an OpenVMS user has been spent mostly in the debugger, debugging imaginary hardware’s failures (which are the kind of failures real hardware wouldn’t even dream of).
Perhaps I should first explain why OpenVMS has become my favourite operating system in just five years. Since university (Eindhoven University of Technology, electrical and information engineering) I’ve been mainly involved in Windows and UNIX support and development. I will not mention which flavour of UNIX, but it’s supposedly the brightest celestial body in our sky. I can only guess that the reason that OpenVMS doesn’t appear brighter is that the design philosophy and internal concepts are light-years apart from each other. When I first ran into OpenVMS five years ago, my first thought was “this is a bit weird,” followed by, “but it’s really well designed.” My personal perception of OpenVMS is derived from looking at it from the outside, studying the OpenVMS IDSM (Internals and Data Structures Manual, nicknamed Infernals and Data Struggles), and studying old source code listings (the VMS 5.5-1 ones). It seems to be one of the very few OS’es I’ve encountered where people actually sat down and thought everything through before they started coding. It’s a much more homogenous OS than UNIX, and has less of a “hacked together” feel to it. Unlike other OS’es, security and clustering are parts of the design that are nested into the core of the OS, which is one of the reasons why you can achieve such amazing uptimes with OpenVMS clusters, and why in 30 years there have only been 19 CERTS security warnings have been issued on OpenVMS (cf. Windows: 1745, the UNIX I used: 346, Linux: 1790).
Over the past two years, while working on the ES40 Emulator, I’ve met several notable members of the OpenVMS community. I met some of these wonderful people at Technical Update Days in the Netherlands, but I met most of them online, on forums and through e-mail, and the occasional Skype phone call. During the Bootcamp, I finally met many of these people in real life for the first time.
What struck me most at the Bootcamp was the overwhelming sense of community. After just a week, you feel like you belong to a whole new family, and it’s sad to leave them all behind in the end.
Another thing is the extremely high level of the sessions. This is a technical event, and you’ll know it. You won’t find many marketing types at this event; most attendees are weather-seasoned technical engineers. Lots of the sessions are delivered by (ex-) OpenVMS engineers, people who have put together large, disaster-tolerant clusters, and other highly ingenious people. The really neat thing is that because everyone has their own specializations, there is the ability to learn something new for everyone. There are sessions during the daytime each day; two plenary keynotes (such as the OpenVMS roadmap, that details some of the future development plans), and two free-choice blocks. One block may contain one, two or three different sessions, and for most blocks, there are about 15 different tracks to choose from. If this explanation isn’t clear to you, you should check out the agenda on http://www.hp.com/go/openvms/bootcamp.
The presentations that I found most valuable were Colin Butcher’s presentation on designing fault-tolerant clusters, and Rob Eulenstein’s session on software-induced machinechecks. The first posed interesting questions that should be taken into consideration, like, “when a system fails, HOW would you like it to fail”, given that even the best designed system may fail sometime when confronted with a sufficiently severe disaster. For some systems, like a stock trading system, you want the machine to stop processing the data and to stop taking orders when things fail, because preserving consistent trading records is even more important than uptime. For air traffic control systems, you want your system to hang in there with its last breath, because to stop working at all would have catastrophic consequences. This way of looking at things was a real eye-opener. Rob’s session took a look at machinechecks, that at a first glance appear to be the result of hardware failures, but were found to be caused by software. Seeing Rob walk us through a post-mortem of a couple of crashes provided me with some valuable insights.
ES40 Emulator Presentation
I had the huge honour of joining these speakers and deliver a presentation on the open-source ES40 Alpha emulator on Wednesday evening. Although this was officially a night off for attendees, about thirty of them joined the session (in a room set up for twenty). Among these people were some well-respected OpenVMS engineers. We went on for about three hours (four hours for some); well over the intended hour-and-a-half.
On other evenings, there were various special events, preceded by wonderful diners; on Monday, it was time for OpenVMS stories. We could line up and deliver our stories, while a professional jury (Richard Bishop, Andy Goldstein, Leo Demers, Robert Deininger, Rob Brooks, Forrest Kenney, and a VMS Ambassador whose name unfourtunally I do not recall) took notes, and occasionally banged a large gong (an indication that your story was considered boring and you should shut up). They let it be known beforehand that they could be bribed with alcohol, and a few people tried this, with beer or sissy drinks. This appeared to have no influence on the outcome though. Everyone who told a story was allowed to choose a gift from a table with cool VMS-related items (most of them either quite old and/or unique), and the jury results determined the order in which these people could choose.
On Tuesday was the Partner Roundhouse. This is a tradeshow-like event for HP Partners. Personally, I found this the least interesting part of the Bootcamp. Though some of the partners present are highly knowledgeable, and have interesting things to show, to many of them OpenVMS is just another platform for their product, and some of these have no knowledge about OpenVMS at all. I don’t mind educating these people about OpenVMS, but I find it hard to believe that their presentation would appeal to people who know OpenVMS well.
Thursday evening was the awards dinner. I was there late, having been offered the opportunity to explore the MIT media lab in the afternoon, together with my good friend (since last week) Tore Bekkedal, one of the youngest OpenVMS enthusiasts at the Bootcamp, and an exceptionally bright computer geek. Fortunately, I was not too late, as I found out – to my astonishment – that I was awarded the award for the best Birds-of-a-Feather session. I didn’t know that there would be such an award.
Another thing that was tremendous fun was the Friday-morning keynote; a recreation of the disaster-tolerant demonstration movie that HP created. Alan Frisbie and Colin Butcher manned two switches, while the attendees voted on who should be given the honour of switching off his half of the cluster. This was to show that the system wasn’t rigged in any way to favour one system over the other. The system managed to fail over in even less time than during the filming of the HP movie.
The final blast came when Andy Goldstein, OpenVMS engineer from day one, took me, Alan Frisbie, and Tore Bekkedal, on a private tour of the famed ZKO3 facilities (OpenVMS development team offices and lab). As HP will move out of this facility next month, this was a last chance to get a look around the place where it all happened.
In retrospect, I can only find two faults with the Bootcamp; one is that you’re presented with an almost impossible choice, because you can only choose a relative few of the many sessions that are offered. The other is that it is all over very suddenly. You’ve been going ahead full speed all week, and all of a sudden the last session is over and that’s it. It’s a very ambiguous feeling, because it feels like you’ve known many of the people at the bootcamp for the longest time, and at the same time it feels like the week has just whizzed by way too fast.
My final note on the Bootcamp has to be a huge thank-you to Susan Skonetski, OpenVMS Ambassador extraordinaire, who probably spent months putting everything together, and who took care of all of us in a truly magnificent manner. Sue, you’re the best, and the OpenVMS community just wouldn’t be the same without you.