USENIX Update

Yesterday’s Women in Tech Panel was moderated by Lois Bennett, who was joined by panelists Carolyn Rowland, Máirín Duffy, and Deb Nicholson. Lois started the discussion with the question, “Is there a problem?”

Carolyn responded, “I didn’t think there was a problem because I’ve adapted, I think.” She said that she tried fitting in by being “like a guy” in how she dressed, talked, and interacted. “I wanted to fit in and be accepted for how smart I was,” she said, adding, “Women sometimes want to feel like women, not like men.” After a while, Carolyn noticed, “It took over who I am.” She asked the question, “Did you down play femininity because you wanted to? Or because you felt you needed to?”

Máirín agreed with Carolyn, saying, “IRC and mailing lists basically made me cry.” She focused on university-based projects, but by her senior year in college, she wanted to make a difference in open source. She got an internship at Red Hat, which then helped her make face-to-face contacts with people.

Deb pointed out that something about the open source community makes it less inviting than the proprietary software community, which has a higher percentage of women participants. An attendee spoke up and shared an experience at her office. Seven men and one woman were interviewed for a position, and ultimately one of the men was hired based on his existing skill set. She pointed out that statistically, the woman wouldn’t get chosen because she might not have as much experience. Deb said that studies show that men consistently overestimate their skill set, whereas women consistently underestimate.

Forking a Child Process

The panel also discussed whether women are penalized for wanting to start a family or for already having children. Carolyn, who has three children, said that when she was pregnant, she went to work every day and had to overcome the fact that she was pregnant and a baby was on the way, whereas her husband didn’t have to carry that with him to the workplace. Two days after delivering each child, Carolyn was back online, making sure her colleagues knew she was still plugged in and not going anywhere. She felt extra pressure to be productive from home when her baby was sleeping, for example, which was pressure her husband didn’t have to deal with at work.

Deb pointed out that other industries offer generous paternity leave and suggested that the IT industry could unionize and commit to a 40-hour work week (which didn’t raise any objections from the audience). Carolyn pointed out that men can’t really understand pregnancy and maternity leave, saying, “If you were my supervisor, I’d be worried about it.”

Máirín said that she and her husband are discussing starting a family, which wasn’t something she was thinking about when she was evaluating potential employers. She wonders whether women self-select out of IT careers because they start families, and she said that one of her friends left the industry until her child was two or three years old. Máirín notes, however, that her employer, Red Hat, has a strong internal community of women who network and support each other.

IRC You

The topic moved to women working with other women, and there is an assumption that if there are two women in an office together, they will like each other and be friends, which isn’t always the case.

Deb said that a lot of men don’t think they are sexist or part of the “problem,” but she pointed out that in an IRC channel, for example, if one loud person is sexist and not one else speaks up about it, a new person in the channel will assume that everyone else agrees with the loud one. She said that being silent while someone louder and more obnoxious represents your community doesn’t help.

Grok

What about recruitment? Máirín talked about the success of the GNOME Project’s Summer of Code. At first, no women applied. The next time around, a GNOME Women’s Summer Outreach program was launched. They took a more neutral approach to promoting the event — instead of focusing on anything competitive or game-related, they talked about the opportunity to learn new skills and earn money. The first year of the new effort, 10 women participated, which encouraged the sponsors to fund more years. She asked, “How are you wording your job postings? Where are you posting them?” Computer labs, for example, have been successful for GNOME outreach promotions.

Culture is slow to change, but Carolyn points out that you can adapt to a culture if you understand it. “We have to adapt because we are the minority,” she says. Still, any culture can be more inviting. She points out that LOPSA could have a mentoring effort to help women adapt without having to hide themselves. “I think that LISA has gotten better and women feel safer here,” she adds.

Action Items

At the end of the panel discussion, Máirín shared the notes she’d been taking. She summarized the talk with the following action items:

1. Do not be quiet. If you see funny business going on, say something.
2. Try to spread awareness that there is a problem.
3. Make sure you have training opportunities in the workplace.
4. If you are a woman in IT, reach out to other women and consider mentoring.
5. Women need to watch their communication (be assertive, don’t say “I think,” sound confident).
6. For women in tech events, invite non-women, too [few men showed up for the panel discussion, and there was discussion about how some men felt unwelcome to attend].
7. Change meeting formats to be more inclusive so everyone has a chance to talk.
8. Make your work more visible (self-promotion).
9. Have a women’s mentorship community (like the one in Red Hat, for example).
10. Review your recruitment strategy (check company website — is it all white men?).
11. The medium is the message (maybe a blog is more comfortable for you than communicating in IRC, for example).

I’ll add this other thought: LISA has a decent turnout of women each year, but we’d love to see more women (and new faces in general) join us. If there’s anything we can do to make LISA — or other USENIX events — more inviting to you, please let us know. And if LISA ’11 was your first time attending a LISA event, we’d love to hear feedback about your experience.

A special thanks to Nicole Forsgren Velasquez for generously sharing her talk notes for this article!

I’m sitting in the Mozilla BoF at LISA’11 and they just now announced that beginning with Mozilla 10 (currently in the Aurora status, which is similar to Alpha), not only will plugins become compatible by default, but that upon release, it will be the first “Extended Support Release”.

The support term that Mozilla will offer will be”about one year”. No new features will be backported from later revisions, but security updates will be added.

By default, Mozilla will still prompt users to upgrade to newer available releases, but this notification can be disabled.

Mozilla’s development efforts will continue with the “rapid release” cycle, but this extended support offering is meant specifically to allow corporate users to satisfy security and stability requirement testing.

The extended support release is a welcome change after Mozilla changed the release structure of Firefox in the summer of 2011. The “rapid release” schedule of incrementing major version numbers between releases was meant to keep the releases fresh and allow addition of new major features. When the policy was announced, enterprise administrators rebelled, citing the need to conduct thorough testing before new major versions could be implemented throughout an infrastructure.

This move should placate most of the naysayers by providing sufficient time for administrators to test and implement the new browser versions.

For more information, including further details on the release schedule, you can see the official Extended Support Proposal on Mozilla’s wiki.

Adam Moskowitz has been around LISA for a while…long enough, even, that he actually chaired my first LISA conference, back in ’09 (yes, I’m that new here). He’s been in IT for even longer, and over that time period, he has made a study of public speaking in a professional capacity.

The Workplace Presentations class isn’t designed to make the attendees the next Winston Churchill – great public speaking only comes with practice – but to help the sysadmins come to grips with speaking in front of their peers and coworkers.

Adam’s class follows four basic tenents:

1. Prepare

Build your ideas using tools conducive to the exercise. For example, PowerPoint, while being a sufficient presentation software, is relatively poor at helping you organize ideas. Mind mapping tools, or even just a whiteboard or notepad.

2. Practice

There is a distinct physiological response in our brains to speaking out loud, rather than only mentally. Adam mentioned that his favorite spot to practice a particular phrasing was in the shower, but that it is ideal to do at least a run-through in the room you’ll be giving the final presentation in, if only to take into account the lights, podium and lectern locations.

3. Relax

Being nervous before speaking in front of the public is completely normal. Fear of public speaking commonly exceeds fear of death, taxes, and velociraptors. Too often, we use our minds as an echo chamber, and overwhelm ourselves through our own fear. To eliminate this kind of pain, it’s paradoxically better to not overanalyze your presentation immediately prior to the event. Adam suggests reading a book, listening to music, or even practice yoga or breathing exercises. Get your mind off of the subject at hand.

4. Present

The volume of advice given by Adam was really pretty overwhelming, but all of it was sound. The most important pointers were to face the people to whom you are speaking. Don’t turn around and look at your slides – keep the computer displaying your slides in front of you. Don’t stand at the computer and hit the space bar to advance slides unless the remote pointer (RF only, to avoid line of sight problems) fails.

In Adam’s words, body language helps 10% of the time, and hurts 90%. Be aware of what your body is doing. If you’re like most people, you’re not aware of what your body is doing – it’s hard to do, so Adam suggests that you actually go through the effort of video taping yourself giving the presentation, if you want to go the extra step. Speaking as someone who has seen himself give a presentation on camera, it’s utterly frightening how different you look and sound from the outside.

Finally, if you are serious about getting good at public speaking, there are groups like Toastmasters who exist solely for improving your speaking skills. If that’s not your style, join (or start!) a local system administrator or user group and give a presentation there. Whatever your disposition, there are lots of opportunities to get better at public speaking.

As noted sysadmin B. Knowles said, “if you liked it then you shoulda put a [monito]ring on it.” John Sellens was back on Monday with another morning session — this one focused on using Nagios to monitor just about anything. Nagios is a host and service monitor with a long history, and a longer list of uses. One example of how Nagios can be used in unexpected ways involves a rotating amber beacon plugged into an IP-enabled PDU. When an exception occurred, Nagios would execute a command that turned on the power to that particular socket on the PDU, giving a visual indication that something had gone wrong.

Of course, Nagios isn’t a toy, but that example goes to demonstrate how flexible Nagios can be. This flexibility comes from the split between the Nagios Core, which is basically a polling and reporting engine, and the user interface. The checks and notifications are arbitrary external commands that get run. While a rich variety of plugins are available, rolling your own is easy. If you can extract the data you want and parse it appropriately, the check is practically written. All you need is to return the correct exit code (depending on the state) and an optional string.

Like any training with the word “advanced” in the title, the opening portion served to ensure everyone was at a certain base level of familiarity. John covered some of the compile-time options (is “–enable-embedded-perl” really necessary? John argues that it’s better to keep the core and plugins truly separate, but “–enable-event-broker” is a recommended option), as well as post-install tips (remember to setup the named pipe by running ‘install-commandmode’).

The next topic was configuring Nagios through the use of the configuration files. The main nagios.cfg allows for the definition of a configuration directory with the cfg_dir directive. Like /etc/cron.d/ or any other *.d/ directory, any number of configuration files can be placed in this directory and will be loaded by Nagios at start time. This makes managing Nagios configuration much easier because each host and service can have a separate configuration file.

Configuration is very flexible. It’s possible to have services not send alerts outside of business hours for low-criticality systems, or to send initial alerts to a different person depending on who is on-call that week. Services can be defined as dependent on others so that your Nagios server doesn’t waste time trying to check services that are down. Unfortunately, with large installations, configuration can be very complicated as well. Using the -V argument to the nagios binary causes the configuration to be checked for syntactical correctness before use.

Where Nagios really gets interesting is in large-scale deployments. The Nagios server that my group uses currently runs almost 30,000 active checks from a single server. As you can imagine, the performance is a little on the sub-optimal side. Fortunately there are ways to scale up Nagios installs. Perhaps the easiest is to simply have several servers. These can also watch each other so you solve the “who’s watching the watcher?” problem.

Tools like DNX (Distributed Nagios eXecutor) can spread the load by passing some of the check-running off to satellite nodes. These nodes can come and go (or die) as they please and the Nagios service will continue to run. Using parent/child and host/service dependencies helps eliminate checks when a target is down. The “use_large_installation_tweaks” option in nagios.cfg reduces the number of forks() a check uses and is more efficient at freeing memory used by child processes.

There’s much more information in John’s slides, and even more in the Nagios documentation. Now if only we could all agree how to pronounce it.