I'm the speaker at LOPSA's New Jersey chapter on Thursday and at LOPSA's NYC chapter the following Tuesday. Obviously I have too much free time on my hands :-)
But seriously...
Thu, Jan 5 near Princeton: LOPSA-NJ. Title: "You suck at Time Management... but it isn't your fault"
Wed, Jan 11 in NYC: LOPSA-NYC. Title: "SRE@Google: Thousands of DevOps since 2004"
New members are always welcome!
Hope to see you there!
Tom
For a long time I've had some serious issues with CEOs putting such a focus on the stock price instead of customer satisfaction. I've usually figured that I was an outsider, too ignorant of how economics or how business works to know any better.
In fact, there was a time (about 5 years ago) that I was seriously considering going for an MBA so I could understand this all better. However I realized that what I really wanted to do was wait for various principles to be explained (like, "focus on shareholder value") and bring up my all my counter-examples. That's not a good reason to get an MBA.
I suffered through the 1990s when most companies started adopting this mentality. A lot of people today don't realize there had been a time when "shareholder value" wasn't the top priority of most businesses. There was even a time when that wasn't even a phrase people used! In the 1990s it became important to "align the average employee's priorities with that of the CEO" therefore we all got stock options. I saw managers at Bell Labs do things that otherwise would be considered stupid and harmful but with these new incentives "it's what we'll have to do".
Meanwhile I keep seeing examples of companies that don't focus on "maximizing shareholder value" doing really well: Apple for example. I'm glad my current employer focuses on "putting the customer first".
So, it turns out I'm not the outlyer. Other people, all smarter than me, have been writing about this too. Now Forbes Magazine, not exactly a bastion of socialist thinking, has published this article that (1) captures a lot of what I've been trying to express, (2) gives 3 specific legislative changes that would turn things around.
The Dumbest Idea In The World: Maximizing Shareholder Value
His recommendations include:
Repeal the 1995 Private Securities Litigation Reform Act
Eliminate regulation FASB 142
Eliminate the use of stock-based compensation as an incentive
Read the article for the details.
Tom
[This is still at 'first draft' quality, but I thought I'd post it sooner rather than later. Please ignore the typos for now.]
I recently twittered my delight that the FCC approval of "super Wi-Fi" is going to be regarded as a historic moment five years from now. I mean it.
Here's why:
In geek terms: This gives permission to treat the airwaves like Ethernet networking, not like Teleco networking. More modern and more flexible.
In non-geek terms, this decision by the FCC makes it easier to innovate. It makes it safe and easy to try new things With the possibility of experimentation comes new applications and ideas. It will be a game-changer.
Let me explain...
Let's first look at how spectrum is allocated today: In blocks. You want to do something "on the air", request a license, go through tons of approvals, put together a consortium of like-minded folks, wait months or years, and get a block of spectrum from frequency X to frequency Y in a particular geographic area. The process is so long that by now I've forgotten what the original idea was. Sigh.
Of course, when the FCC was created in the 1930s this made sense. We didn't know any other way and we didn't have the technology to do it any other way. Electronics were imprecise and stupid (and analog) so the best thing to do was to allocate big blocks and waste some space by putting gaps between those blocks to take into account "drift". It was centrally-controlled, graceless, but it worked. To manage a precious, rare, resource, it made sense. Did I mention this was the 1930s?
This is comparable to how telecoms traditionally have handled bandwidth. You may recall that a T1 line has 24 channels (DS0's) that are 64 kbit/s each. The total bandwidth of a T1 is 1.5 M but it is divided into 24 timeslots. If you are DS0 number 13, you know that your bits are transmitted 13 time units after each clock sync. If you don't have anything to transmit, zeros will be transmitted for you. It is wasteful and graceless but thats the best you can do in 1961 (which meant most of the design was done in the 1950s). That's nearly a decade before we landed a man on the moon and 20 years before the Commodore 64 first shipped.
Compare that kind of resource allocation scheme to Ethernet. On Ethernet every device that wants to transmit "listens" to see if anyone else it talking and as soon as there is silence "you just start sending". If two devices send at the same time it is considered a "collision" and both parties back off and re-try a random amount of time later. No central authority deciding who should talk when. Everyone just has to agree to use the same rules for how to back off when there is a problem. No central authority, just "benevolent self-interest" that requires everyone to follow the same rules: You follow the rules out of your own self-interest because if everyone does that, everyone can win: Talk when nobody else is and politely back off if you find you are interrupting someone.
It works because data protocols are done by computers that can think, look around, and retry when there is a problem. Analog electronics couldn't do that.
Also compare to how TCP/IP allocates bandwidth on the internet. Send all the data you want, ramping up to the max rate you can send. If there is congestion, the network drops your packets and you respond by slowing down. There is no attempt to allocate the perfect amount of bandwidth for you so that you don't have to deal with congestion. Your protocol follows specific rules on how to back off; and it works because everyone is following the same rules. Your protocol can try to cheat, but it is in your own self-interest to follow the rules and the rules are simple: Talk and and politely back off when there is an indication the system is overloaded.
Imagine if the telecom world or other old-school thinkers had tried to invent a data-networking system based on their old antiquated values? Every time you wanted to SSH to a host, first your protocol would contact some great authority in the sky, beg for an allocation of bandwidth, promise not to go outside that allocation, receive that allocation. With that allocation you would then start transmitting, always careful not to send more than you had promised. Once you were done you would notify the great authority in the sky and the bandwidth would be freed for use by others. But what if there wasn't bandwidth available? During the allocation request you would be given a busy signal (or sent to voicemail?) so you knew to try again later. At the end of the month you'd get a "phone bill" that would list every connection you've made with a dollar amount to be paid.
Now, obviously that's a silly way to run a network. Nobody would create a network like that... oh wait... someone did!
Do you think the telecom industry learned from experienced data network inventors? Heck no. In fact, the telecom industry's response to the internet and TCP/IP was ATM (the confusingly named "Asynchronous Transfer Mode") which was based on sending data in timeslots or "cells" that are 53 bytes each. (That's not a typo... yes, the packet size is a prime number!). The first stage of each session was an allocation process. You (your software) would talk to your nearest router and explain how much bandwidth you needed and for how long. It would negotiate on your behalf with every router between you and the destination to allocate your specified amount of bandwidth. That bandwidth would be allocated just to you. (more on that later) You then have this "virtual circuit" that you transmit your data on until you are done and then the routers de-allocate that bandwidth allotment.
Laughable? Yes. But from 1988 to 1995ish the telecom industry tried to "take over" the internet and force it to be replaced with ATM. Imagine every SSH session taking 0.5 to 2 seconds to start up as bandwidth was allocated to you. Of course, that didn't work well therefore the ATM Forum proposed that you allocate yourself a big chunk and use it for all your TCP/IP needs, doing your own suballocations from that larger block. In other words, they were going to give you a T1. In fact, "T1 Emulation" was a big feature of ATM equipment.
And... oh dear. You would you get a phone bill at the end of the month, listing all the connections you made and a sum total for you to pay. Insane. In fact, one of the jokes about ATM was that the acronym was "A Tariffing Mechanism".
ATM did have one concession to the way real-world data networks operate. The channels didn't have to be fixed sizes. They could be "variable rate". Also, if you weren't using your entire allocation the network could use the "spare" bandwidth for "best effort" protocols. In fact, a large part of the research around ATM was how to oversubscribe allocations and still assure that all bandwidth guarantees would be satisfied.
Here's the part I think is the most funny. The most complex part of an ATM system is all these mechanisms serve the purpose of assuring that the endpoints see a perfect network with perfect bandwidth allocation and perfect reliability and perfect fidelity. However, at the top of the protocol stack data you (your protocol) still has to do end-to-end error checking. Even if you are promised the network can not possibly drop or corrupt a packet, the top level protocols (the applications) still check for problems because the error may have been somewhere else: the cable between the computer and the perfect network, for example. Thus ATM went through all this hand wringing on behalf of upper level protocols that didn't need it, or find much utility in it. Here is a list of things that data protocols can handle on their own: missing packets, dropping packets, corrupted packets, data being sent too fast, data not being sent fast enough. Did I say "can"? They have to. Thus, ATM's generous offer to handle all of that for you is a waste of effort on ATM's behalf. It does, however, justify the ability for the ATM provider to send you a bill. What a great business model.
The fact that ATM didn't replace the internet was no accident. It was a huge effort to "push back" against some very big heavy weights. If you recall, these were the same years that small ISPs were being bought up by Telcos. Eventually all the major ISPs were entirely owned by Telecos. The equipment companies were entering the telecom space and didn't want to piss off their new telco customers. Thus, the people that needed to fight back against ATM were now all owned by megacorps that wanted ATM to win. Wired Magazine wrote the definitive history of this battle and I encourage everyone interest in internet history and governance to read it. The people in this story are heros.
This brings us back to the recent FCC decision.
The airwaves are allocated in blocks. It is wasteful, graceless and ham-fisted but it works. And most of all, it worked given the technology of the 1930s that created it.
The new regulations permit radio transmitters to share spectrum. As long as everyone plays by the same rules it all "just works". As long as everyone has an incentive to play by the rules, it will continue to work. The rules are both "the carrot and the stick". "The stick" is FCC penalties. "The carrot" is that if everyone plays by the rules, everyone will continue to be able to play.
So here's how it works. If you want to broadcast on frequency X, you listen to see if anyone else is broadcasting. If nobody is, you start broadcasting until you detect that someone else is broadcast at which point you have to stop broadcasting. It's a lot more technical than that, but that's the premise. It is like Ethernet and TCP/IP: Talk when nobody else is and politely back off if you find you are interrupting someone.
Of course, you probably are going to listen to many frequencies: scanning up and down for free frequencies so you always have enough available to send the data you have. One of the FCC concessions is that there will be a database of frequencies that are allocated "old school style" and devices will have to stay away from those. Devices will download updates from that database periodically. The database is geographic. The entries are not "don't use channel 9" but "In New York, Channel 9 is in use".
The frequencies that are now available include the "whitespace" airwaves (channels that are unused in the TV frequency range) as well as the gaps between channels that used to be needed due to "analog drift". Now that transmitters are digital they are more precise (they can stay within a more narrow frequency band) and self-correcting (no drift). Being able to use those gaps alone is a big innovation.
At last! Instead of going through tons of work to use any airwaves at all, we can simply build devices that know how to "talk when nobody else is", scan frequencies for available bandwidth, and sync up to a central database.
These are things that modern computers do very well.
None of this was possible until recently. In the 1970s a transistor radio might cost $10 and be so simple it might have come in a kit. Imagine if it had to scan frequencies and so on. With 1970s semiconductor technology it would be a million dollar product. Not something anyone could afford. Oh, and your hand-held radio would only fit in your hand if your hands were as big as the Statue of Liberty's.
Moore's law predicts the "march of progress" in semiconductors. It was easy to predict when such compute power would be affordable and therefore making it economically possible for such devices.
While Moore's law may be hitting the limits of physics, we are still benefitting from it. Ironically there are entire industries that have tried to deny its existence. The economic justification for creating ATM was based on the notion that silicon chips would never be sophisticated or powerful enough to be able to process variably-size, large packets; network speed would hit a limit if we didn't change everything to 53-byte packets. This is entirely true to anyone that is ignorant of, or denies, Moore's law. People that lobbied against "super Wi-Fi" and the use of whitespace also were ignorant of, or in denial about, Moore's law. Of course electronics could do this, it was a matter of time. The music industry was told, based on Moore's law, which year MP3 decoders would be inexpensive enough to put music on a PC, and what year it could fit on a portable player, and what year being able to download an MP3 would be economically feasible; their surprise when these things happened were either due to ignorance of, or denial about, Moore's law. The term "feigning surprise" is one way to describe how someone acts when predictions they've ignored all come true.
But I digress...
This new FCC regulation is a major step forward. It is a modernization of how we allocate wireless frequencies. It is an acknowledgement of Moore's law and the improvements digital electronics bring to the field. It is the gateway for new experimentation which will lead to new wireless applications and services.
Mark my words! Five years from now we'll look back at all the progress that has happened and point to this day as the historic moment that started it all, even though the announcement was mostly ignored at the time.
Well, ignored by everyone except you, dear reader.
Tom Limoncelli
(See you Dec 22, 2016!)
P.S. The only coverage of this FCC decision that I've been able to find has been in the foreign press. What's up with that? It's as if the U.S. incumbents are in cahoots to make sure it will be easy to feign surprise about this some day.
The problem with companies that used to support SOPA but have turned around, is that they supported it in the first place.
The problem with stopping SOPA is that the people behind it are committed to bringing it back in another form, some day, some how.
The problem with SOPA is that many of the bad things in SOPA are things that the U.S. government has been doing lately either unofficially or through "cooperation" with companies.
The defeat of SOPA will not be the end of the general problem.
The real solution is that we pro-internet, pro-innovation, pro-freedom folks need to be proposing our own legislation or, better yet, a constitutional amendment, which establishes freedom of speech, freedom to encrypt, and freedom to link as inalienable rights of all citizens.
One part of "The Cycle" is that you should keep a list of long-term projects and review it every few months. There are two specific times you should always review it: around budget time (this is where you record those great projects that are so big they'll require funding), and around New Years (the list usually inspires good New Years Resolutions).
The list has a couple "secret" functions. First, when your main todo list is growing out of control, it can be very useful to move some of the more audacious goals onto this list. Secondly, sometimes an idea is taking up brain-space and you just need to write it somewhere.
I'm told that the reward/pleasure system in the brain activates when you accomplish a goal. I'm also told that the exact same activation happens when you tell a friend an idea about a goal you'd like to accomplish. Thus, you don't feel the need to do the project any more if you've told someone about it. That's why I'd rather write it down on my list. It gets it out of the "front of my brain" so I can think about other things. Since I have more ideas than I could ever do, it also has the benefit of being an efficient "place where ideas go to die". However they are recorded so when I do my yearly peek at the list, if it still seems like a good idea I haven't lost it.
Every idea I have seems like the best idea ever when I have it. The test to see if it really is a good idea is if it still feels like a good idea months later.
A good place to store this list is anything private that is easy to access. You want to be able to whip it out and write something down any time. If it isn't accessible, I write the idea into my todo list for recording later. If you use a physical organizer having a page at the back of the notebook is a good place for this list. If you use a PDA or Smartphone, a "notes" page or similar is a good place.
We're almost to the end of the year. It is a good time to look at the list, add and delete things. Maybe there are items you'd like to discuss with your significant other, boss, mentor or coach.
Two years ago my new years resolution was to lose weight. I joined Weight Watchers and lost 40 pounds. I've kept 30 off, which was pretty much my goal. I'll be writing more about that in the coming months.
I haven't finalized my New Years Resolutions yet. However, if you'd like to post yours, feel free to write in the comments (even if you haven't finalized them, I'd love to hear your thoughts!)
Yesterday on the SysAdvent calendar Aleksey Tsalolikhin has an article about configuration management. It includes a comparison of how to the same in in various languages: bash, CFEngine, chef and Puppet. Seeing how the languages differ is very interesting!
A great explanation about "yield" followed by a discussion of coroutines and more:
In the sequel, he goes into even more detail and the uses all the information to write an operating system in Python.
USENIX Association LISA '10: 24th Large Installation System Administration Conference
(This "welcome" letter appeared on the USB stick given to all attendees. Since most people probably missed it I thought I'd repost it here.)
Message from the Program Co-Chairs
Dear LISA '11 Attendee,
There are two kinds of LISA attendees: those who read this letter at the conference and those who read it after they've returned home. To the first group, get ready for six days of brain-filling, technology-packed, geek-centric tutorials, speakers, papers, and more! To those that are reading this after the conference, we ask, "What's it like living in the future? How was the conference? What cool tips and tools did you take home with you to make your job easier?"
Being a sysadmin is kind of like living in the future. You work with technology every day that would make Buck Rogers jealous. Most of our friends are jealous, too. When LISA started 25 years ago, a "large site" had 10 computers, each the size of a dishwasher, with a few gigabytes of combined storage. Today our cell phones have 32GB of "compact flash," which is often more than the NFS quota we give our users.
Attending LISA is kind of like spending a week living in the future. We learn technologies that are cutting-edge-- little known now, but next year everyone will be talking about them. When we return from LISA we sound like time travelers visiting from the future talking about new and futuristic stuff. LISA makes us look good.
LISA rarely has a cohesive conference theme, but this year we thought it was important to highlight DevOps, as it is a significant cultural change. Although DevOps is often thought of as "something big Web sites do," the lessons learned transfer well to enterprise computing.
LISA has always been assembled using the sweat of many dedicated volunteers. It takes a lot of effort to put a conference like this together, and this year is no different. Most prominent are the Invited Talks committee (Æleen Frisch and Kent Skaar) and the Program Committee (Narayan Desai, Andrew Hume, Duncan Hutty, Dinah McNutt, Tim Nelson, Mario Obejas, Mark Roth, Carolyn Rowland, Federico D. Sacerdoti, Marc Stavely, Nicole Forsgren Velasquez, Avleen Vig, and David Williamson), but also important are the Workshops Coordinator (Cory Lueninghoener), the Guru Is In Coordinator (Chris St. Pierre), the Poster Session Coordinator (Matt Disney), and the Work-in-Progress Reports Coordinator (William Bilancio). We couldn't have done it without every one of them. Of course, nothing would happen without the leadership of the USENIX staff. We are indebted to you all!
Of the 63 papers submitted, we accepted 28. These papers represent the best "deep thought" research, as well as Practice and Experience Reports that tell the stories from people "in the trenches." We encourage you to read them all. However, the power of LISA is the personal interaction: introduce yourself to the attendees standing in line near you, strike up a conversation with the person sitting next to you. And remember to have fun!
Sincerely,
Thomas A. Limoncelli, Google, Inc.
Doug Hughes, D. E. Shaw Research, LLC
Program Co-Chairs
I've booked a BoF room at 9pm to give my talk "SRE@Google: Thousands of DevOps Since 2004".
Tuesday, December 6, 9:00 p.m.-10:00 p.m., Fairfax B
"Tom will describe technologies and policies that Google uses to do what is (now) called DevOps. Google doesn't just empower developers and operations to work together, we have a system that empowers all groups to be their own devops team. (This is based on my opening keynote at the Pittsburgh Perl Workshop.)"
(In an effort to get these out sooner rather than later I'm not spending a lot of time editing and proofreading. You've been warned.)
Daytime: Today I spent the day in the Advanced Technology Workshop.
What is a workshop? People need a space to spend an entire day (or half-day) to talk about a topic. There are workshops for people researching certain areas and their workshop at LISA is a once-a-year touchstone to meet in person, give presentations, share ideas, and so on. The Configuration Management workshop is in its 11th year. In fact, Puppet was inspired by a debate (argument?) at CMW a number of years ago. Other workshops are less research-y, like the one for sysadmins at government and military sites. The full list is here.
The Workshop I attended today is called The Advanced Technology Workshop. It is intended for very senior administrators, provides an informal roundtable discussion of the problems facing system administrators today. It is part support group and part talking about hot-topics. The discussion is relatively confidential so that people can speak freely. However notes are distributed after the fact to attendees.
Dinner: As the conference co-chairs, Doug and I have a lot of preparation to do for the Wednesday morning plenary. We decided to have dinner together and then finish what we needed to do. Most of it was finalizing the slides and rehearsing the dialog for the introductions and opening at the Wednesday plenary. We also met up with his old boss from many years ago and I got to hear some stories about "the old days".
BoFs:
LGBT: 7pm: I went to the "Birds of a Feather" (BoF) session called "Lesbian, Gay, Bisexual, Transgender, and Friends BoF". This was the 11th year (we believe) of this BoF. The room was packed. The first half was people introducing themselves. Everyone said their name, company and described their employer's HR policies related to LGBT people: does their non-discrimination policy include LGB or LBGT status, do healthcare benefits apply to same-sex partners, and so on. The second half we talked about industry news, conference insider tips, and what we can do to increase the number of women that attend Usenix.
SRE@Google: 9pm: Not to be confused with the Google Vendor BoF on Thursday night (where there will be plenty of beer and ice cream for everyone), this BoF was a talk by some guy from Google... oh wait, me! "SRE@Google: Thousands of DevOps Since 2004". First the talk compared software development in the 80s, 90s, and 2000s and how this changes operations (system administration). I then described Google's system administration practices that (1) help developers and operations work collaboratively, (2) drive both reliability and high change rates, (3) make it fun. Turn-out was huge, and the questions and comments were excellent. I'm glad I got to do this talk.
I got to bed by 11pm which was pretty important because tomorrow is a big day. The "technical conference" portion of the conference begins. This is 3 days of invited talks, papers, guru sessions and keynotes.
(In an effort to get these out sooner rather than later I'm not spending a lot of time editing and proofreading. You've been warned.)
Again woke up around 6am. Rehearse parts of the tutorial, got breakfast at the Sheraton Club on the 29th floor.
Tutorial: The Limoncelli Test: My first new tutorial in years! Based on this blog post, the tutorial lists 32 "best practices" that sysadmin teams should do. I had enough time to discuss half of them. At the start of the class I had everyone take the test, and then focused on discussing the ones that had a lot of "no" answers (by show of hands). An attendee wrote a very complimentary review of the tutorial. The "surprise" I had prepared was that for the entire last hour we talked about nothing but specific techniques for "creating organizational change" (which is a fancy was of saying "how to convince your manager and coworkers agree to these fantastic ideas you have). We talked about why people push back (mostly because they're authority is being challenged or they don't want the discomfort that comes from doing new things). The techniques for working on these issues involve various psychology tips to help you understand how people think and how to work from there.
Lunch: I had the lunch that comes with the tutorial sessions. It was mostly sandwiches: I had the roast beef.
Afternoon: I had free time in the afternoon. I spent some time at the CHIMIT workshop which seeks to help link researchers that study system administrators and the system administrators that are available to be studied.
Dinner: A random group of people that were standing around getting hungry decided to go to dinner. We split into two groups, one that went to PF Chang and another that went "somewhere that doesn't put peppers in everything". It was fun being at dinner in a group where I didn't know everyone. We talked about everything from networking, Puppet, politics and rock and roll.
I didn't go to any BoFs but there were BoFs for small sites, AFS users, software patents and other things.
I hung out and did the unofficial "hallway track". I got some one-on-one time with Philip Kizer (president of LOPSA) to talk about some ideas I had and ask about what the future plans are. I'm glad LOPSA is getting some focus and look forward to hearing more at their LOPSA Annual Meeting and Town Hall.
Later at night I hung out at the bar. Another event was in the hotel and it was a big event with a band, speakers and so on. When it emptied out they came to the bar too. You could tell who was who because LISA attendees were all in tshirts and the other group were in formalwear (suits and dresses). One of the speakers for their event was this famous actor and he was sitting right by us in the bar. I wasn't sure it was him, and William kept asking people to look and see if they thought it was him. About half the people we asked hadn't heard of his movies when we mentioned them. Eventually someone pulled up his picture on IMDB and we decided it had to be him. William finally went up to him and got his autograph. Win!
Later my brother showed up. Yup, my brother Ed works in IT and is at LISA this year! W00t!
At that point it was late so I went to bed.
Sunday I woke up around 6am, had breakfast at the hotel "club" on the 29th floor (great view!)
Tutorial: Time Management for System Administrators: In the morning I taught a half-day class on Time Management. This is the "personal" time management side of things: making your life more sane. I've taught this class at LISA every year since 2005-ish and this year the turn-out was HUGE (80+ people). No matter how many times I teach this I get new and interesting questions each time. After the tutorial I autographed books and answered questions.
Lunch: I had the lunch that comes with the tutorial sessions. Chicken, salad, etc.
Tutorial: Time Management: Team Efficiency: In the afternoon I taught my new(ish) tutorial on tools for helping your team work together. This is all material that is new since Time Management for System Administrators was published. (1) Making meetings not suck. Meetings that waste your time are evil and there are many good ways to reform bad meetings and escape the unfixable ones. (2) Tools that let the team delegate amongst themselves. You may be the only person that understands the guts of the backup system, but everyone should know how to do routine work like adding a new server, doing a restore, changing tapes, and so on. This is a matter of writing "service documentation" and "procedure documentation"... I know everyone hates writing docs, so we also talk about how to make it painless (hint: put a checklist onto a wiki is better than nothing; a little structure and you are almost entirely there. (3) tools for sharing information, and tearing down power structures that are based on information hiding, (4) tips for creating a more shared, collaborative, oncall/pager experience, (5) templates to use for things like design docs, department web site, and so on.
Dinner: Met two local friends and had dinner at Cheesecake Factory. More calories than is ethical to put on a plate.
Evening: Hung out in the "hallway track"... social spaces around the conference venue where people hang out and chat. I got the "inside scoop" about what is happening with the people in certain open source projects; this will help me make some decisions I've been needing to make.
Saturday, Dec 3:
Getting There: Since the conference is in Boston, I decided to take the train rather than fly. Amtrak costs about the same but is faster due to the lack of 2-hour wait for TSA and other airport things. I arrived in Boston at about 1pm, checked in at the hotel, changed, and went to the lobby to hang out.
Registration: Registration wouldn't open until 5pm so I hung out, talked with people, got some status updates from the Usenix staff about registration numbers and so on. Registration opened at 5pm spot on and I was 2nd in line :-) so I got registered fast.
Reunion: It was great to see so many familiar faces as people arrive. LISA is kind of one huge family. Kind of a "once a year family reunion" for people that know each other through technical mailing lists and other forums. It was particularly good to see people that haven't made it to LISA in years (hi Kurt!). It's also great to see so many new faces. I think everyone goes out of their way to make new people feel welcome. For example, around dinner time people form groups to go out and new people are recruited. Which brings me to...
Advice for new people: It's easy to be shy at a conference like this. Here's a tip to break out of that: It is always polite to turn to a person you don't know, stick your hand out (to shake their hand) and say, "Hi! I'm [your name]. What's your name?" This works great whether you are standing on line waiting for lunch, or sitting next to a stranger in waiting for a talk to begin. Some of the biggest opportunities to learn at LISA are from the other attendees. Strike up a conversation!
Dinner: Walked with a friend to an Indian restaurant called Kashmir on Newbury Street.
I went to sleep early because tomorrow was going to be a big day.
Sysadmin1138 attended my LISA 2011 Tutorial "The Limoncelli Test" yesterday and wrote this excellent summary. Check it out:
http://sysadmin1138.net/mt/blog/2011/12/lisa-2011-the-limoncelli-test.shtml
Thanks for the write-up!
Usenix has negotiated with the hotel to get the wifi fee waived for any attendee that stays in the hotel as part of the Usenix block.
When you sign in to the WiFi go through the process and agree to the $12.99/day (I think) charge, but when you check out it will be removed from your bill.
The conference hotel is the Sheraton Boston Hotel, 39 Dalton Street, Boston, MA
I'll be teaching 3 tutorials and one "guru" session. Plus, as conference co-chair I'll be on stage many other times too.
Watch this space: http://www.usenix.org/events/lisa11
Advice about the Guidebook app:
http://mph.puddingbowl.org/2010/02/org-mode-in-your-pocket-is-a-gnu-shaped-devil/
What will they think of next?
If you register for USENIX LISA'11 by the end of my birthday (today, Fri, Dec 2nd) your name will automatically be entered into a drawing for two 30-minute, one-on-one time management coaching classes with me.
(that's by midnight California time... even though I live on the east coast.)
This is a fairly exclusive offer. I normally only do time-management coaching for co-workers.
See you in Boston!
Tom
This weblog is licensed under a Creative Commons License.
