Sydney Linux Users Group (SLUG)

As well as other events, SLUG typically holds regular meetings on the last Friday of each month. Our meetings are held at Google Sydney.We have a map of the area and directions for taking public transport.

You will need to sign-in to enter the venue. This can be performed when you arrive, but to save time we recommend that you do so at the Anyvite link provided in the meeting announcement. If you are unsure, please sign up as a 'maybe'. This allows us to organise adequate catering, meeting space and facilities. You do not need to create an account to indicate your attendance.

We normally send out an announcement a week or two before each meeting. To receive these notifications, you can subscribe to our low-traffic announcements mailing list, RSS feed or ical calendar feed.

These meetings present talks on various topics, aimed at both experienced and new Linux users.

• Participation
• List of Events (feed)
• Past Talks
• Guide for Speakers

If you're interested in speaking to SLUG, please see our Call for Participation.

Details of our next meeting:

Meeting Details

Meeting Schedule

Bird of a Feather (BoF) Sessions

Hacker Space

Dinner

Links

[1] http://tinyurl.com/ParkingPyrmont
[2] http://wiki.slug.org.au/howtogetthere
[3] http://slug.eventbrite.com/
[4] http://www.slug.org.au/meetings/meetingformat

SLUG meetings follow a standard meeting format with a common first half, and then dividing after the break. This is to provide two streams of content catering to both new and experienced Linux users.

The standard meeting agenda is:

18:15: Doors Open

18:30: Announcements, News, Introductions

Introduction to SLUG, Q&A, "What has Linux done for/to me lately?", SLUG News & Discussion

18:45: General Interest talk

The General Interest talks are designed to be of an intermediate level. Previous topics have included:

• SLUG Forum: "Package Management Systems comparison"
• Conrad Parker: Sweep
• Adrian van den Dries: Zope

19:30: Break/Intermission

Refreshments available in the foyer. We request that you make a gold coin donation to cover our expenses.

19:45: Split into two groups for:

• In-Depth talk. Previous topics have included:
  • Bruce Badger: "Smalltalk"
  • Peter Miller: "AEGIS"
  • Jeff Waugh: "Open Mosix clustering"
• SLUGlets. quick talks/demos and discussion of Linux and Free Software

8:30pm: Dinner

How do I join the list

The easiest way to join the SLUG mailing list is to use the Mailman web interface. In the Subscribing to SLUG section, enter the email address you want the list messages to be sent to, and a password. This makes sure your subscription can't be changed by anyone else - without it they could maliciously unsubscribe you.

If you prefer to subscribe using email, send a message to slug-request@slug.org.au with subscribe in the subject line. If you click on the link provided, your mailer should have all of this entered correctly, so you just need to send it.

You will then be sent a confirmation email; reply to this and you're on your way!

Subscribing to the digest (a less voluminous list, replacing many smaller emails with fewer, albeit larger compilations) is also very easy. If you're using the web interface, there is an option to receive the digest below the password fields. If you'd prefer to use email, you should put subscribe digest in the subject line.

How do I leave the list?

Why on Earth would you want to do that?!? ;-)

The easiest way to unsubscribe is to use the Mailman web interface. In the SLUG Subscribers section, type in your email address and hit the Edit Options button. You will be able to unsubscribe there, after entering your password.

You can also unsubscribe using email. Send email to slug-request@slug.org.au with the subject "unsubscribe password", where "password" is the password you were sent when you joined up.

Note: If you are only temporarily leaving the list - perhaps for that long-awaited holiday - you can simply set the "no mail" option on the Mailman web interface, or by sending set nomail on to slug-request@slug.org.au.

What other things can I do with my subscription?

There are many options and settings available with out mailing list software. The best way to find them out is to log into your options page on the Mailman web interface - down the bottom in the "SLUG Subscribers" section - or by sending "help" to slug-request@slug.org.au.

Argh! What's this about a password?

The new mailing list software uses passwords to make sure that you are you, and your prankster best friend who thinks that unsubscribing you would be funny, is not.

You can retrieve your password using the Mailman web interface. In the "Slug Subscribers" section, type in your email address and hit the "Edit Options" buttion; you will be able to retrieve it there. You can't do this via email.

Who do I contact about the mailing list itself?

You may want to contact us if you're having trouble with the mailing list software, or something has gone wrong.

Email the list administrators at slug-owner@slug.org.au. They are usually quick to reply, though please remember that the SLUG mailing list is driven by volunteers - not cron jobs - and they do take flames personally.

What other mailing lists are available, and what are they for?

slug

The main discussion list, slug@slug.org.au, is where all the discussion goes on. Everything related to installing, maintaining, developing on Linux or Free/Open Source Software is on topic for this list, from configuring your ADSL modem on a 386 with 4MB of RAM up to rolling out a highly available global mailserver network.

slug-chat

Everything that isn't on topic for the main list, such as the social ramifications of 4WDs versus bicycles, or distribution flamewars, are the reason for the slug-chat@slug.org.au mailing list. If you have any hesitation about the on-topicness of a post, you should immediately edit the To: header and send it to slug-chat.

activities

activities@slug.org.au is where the committee, and others, discuss the organisation of SLUG events. If you are interested in getting more involved with the running of SLUG, or if you just want to check that the committee are doing their job correctly, then this is the list to be on.

announce

Finally, if you want to be kept aware of SLUG events but you don't want to read every single email that goes to the main list, you should subscribe to the announce@slug.org.au mailing list. This very low volume list is solely for SLUG event announcements - meeting announcements, and extracurricular events such as workshops and social events.

You can subscribe to any or all of these at the main main Mailman list overview page.

What kinds of questions can I ask on the list?

Well, if it's Linux-related, it's appropriate. That normally covers a lot of other Free Software or Open Source projects, such as Apache or Perl.

As Linux has become more popular, there have been less development and highly technically-oriented questions on the list. Don't feel that you can't post these sorts of questions! There are lots of coders and gurus on the list who enjoy getting their teeth into thorny problems - your questions and ideas are very welcome.

Inappropriate questions are usually ignored, rather than flamed. If you don't receive an answer, either we don't know one (not very common!), or you may be asking the wrong audience. Often enough, someone in the know will direct you to a better source.

Are there any rules I should be aware of?

We don't really have any rules. Being the Sydney Linux User Group, it's pretty evident what we're interested in, and how we go about it! :-) As a rough guide, though, you may want to be aware of the following points:

• Stick to the subject. It's all about Linux and Free Software from here on in, although we do talk about lots of general UNIX. We have a few resident non-Linux UNIX gurus whom we know and love (they're often plotting and planning for a Linux takeover in their place of work anyway!)

  If your post is off-topic, you'll likely be pointed to slug-chat. This list is the Pandora's Box of SLUG's mailing lists. There is nothing that is too off-topic for slug-chat (although some interesting discussions have been pointed back to the main list!).

• Please don't post in HTML format! If you are using Outlook or Netscape Messenger, please turn off HTML formatting for your posts to the list.

• Delve and research. If you will be asking a question, before you post to the list, try to find the answer in the available documentation or the list archives. The Linux Documentation Project is a good place ot start. Failing that, a search on Google will often yield answers.

• Be nice, there is no need to be rude. Avoid expressions that may be interpreted as aggressive towards other list participants, even if the subject being treated is particularly relevant to you and/or controversial.

• The SLUG mailing list is not a place to complain about other operating systems.

• Don't drag on with controversies. Don't try to have the last word. You will eventually have the last word, but meanwhile you'll have lost all your sympathy credit. We hardly ever have on-topic flamefests here anyway. :-)

• Don't flame the newbie! As we are a Linux User Group, this is very important. No matter how l33t you are, you too were once a newbie. Also remember that we're often seen as a representative of the "Free Software Community" and could scare great people away from "The Cause". A great document to read that touches on this is the Linux Advocacy mini-HOWTO.

Why isn't the Reply-To: header set to reply to the mailing list?

Please read "Reply-To" Munging Considered Harmful by Chip Rosenthal.

How do I reply to list posts?

If your mail client has a "Reply to List" feature, use that. Evolution has this in the Actions menu. Mutt has some features for handling mailing lists, including handling replies neatly.

All other mail clients should have a Reply to All feature. Reply to All will make sure that both the author of the mail you're replying to and the list will get a copy of your mail. Double-check your To: and CC: fields before you send to make sure that slug@slug.org.au is in there somewhere, otherwise it won't make it to the list.

Why does the mailing list allow posting by anybody, instead of just mailing list subscribers?

The FAQ that caused the most vehement flamewars in SLUG history was answered with a formal vote by financial SLUG members.

We believe that an open posting policy allows greatest access to interested bystanders and casual users.

Is anything being done to prevent spam email from being sent to the mailing lists?

Yes. The SLUG server runs a variety of explicit filters as well as a highly tuned spamassasin install. Despite this there is still some spam that makes it through occasionally.

Wouldn't a closed list be the best defence against spam?

Maybe. However it also makes it difficult for the occasional poster to contact the SLUG mailing list. A vote of the SLUG financial membership in October 2003 voted to keep the list open.

SLUG's monthly meeting features several talks of varying length.

We're always looking for new talk offers, and talk offers should be sent to activities@slug.org.au and CCed to committee@slug.org.au. If you're not a member of the Activities list, just send it to the Committee. We also suggest that you post your suggestion on our Wiki. You will need to supply us with the following information:

• a title of the talk
• an abstract/summary of the talk to put in our announcement (a few sentences or a paragraph is fine)
• whether the talk is intended to be a General Talk, an In-Depth Talk or a SLUGlet (see below for explanations on what these are)
• at which meeting(s) you are available to deliver your talk

Don't worry if you can't immediately supply these. We can help you through it. We recommend that you use the SLUG Activities list to discuss your content with the community to maximise its relevance and quality.

SLUG talks can be on any topics that would loosely come under the heading of "Open Source Software" or "Free Software". We're open to talks about software, about projects, about features, about tools, and about the Open Source and Free Software movements, and issues surrounding them.

Our membership are primarily hobbyists and professionals, however our meetings are open to the public.

Giving a talk at SLUG would be an excellent way to prepare for more formal speaking situations

With speaker permission, SLUG records video footage of the talks given at meetings, and other events. The slides and video footage are available under the Creative Commons ShareAlike License unless otherwise noted.

• Talks from 2005
• Talks from 2004
• Talks from 2003
• Talks from 2002

If you're interested in speaking to SLUG, please see our Call for Participation.

If a talk that you'd like to see isn't online yet, or if you gave a talk but we don't have the slides, please contact the committee.

Details of previous talks can be found in the archived meeting announcements here and in the announces mailing list archives.

This guide is © Mary Gardiner 2003-2004. This guide is available for redistribution and modification under the terms of the Creative Commons Attribution Licence

Introduction

This document is a short guide to preparing and presenting a talk at the Sydney Linux Users Group, and should be useful for other groups too. It is intended for speakers who are comfortable with their topic area but do not have much public speaking experience.

This guide covers the type of talks given at SLUG; preparing your SLUG talk; and giving your SLUG talk.

The type of talks given at SLUG

There are three types of talks given at SLUG meetings: general talks, special interest talks, and SLUGlets.

General talks

Length: 30 minutes (plus question time). In some months the organisers might combine two 15 minute general talks.

General talks cover a topic of interest to most of the SLUG audience. General talks need to be interesting to the majority of SLUG attendees, which means that your talk must not assume a large amount of familiarity with Linux and Free Software, but must still be interesting to people who do have this familiarity. Examples of good general talks include: overviews of new or little known Free Software user applications; overviews of significant revisions of major applications (such as user level overviews of new major kernel releases); and talks about the Free Software community — for example a talk about contributing to Free Software.

The aim of a general talk should be to give the audience members something new to try at home.

Special interest talks

Length: 30 minutes (plus question time). In some months the organisers might combine two 15 minute special interest talks.

Special interest cover a topic of interest to a subset of SLUG attendees. Special interest talks run in parallel with SLUGlets, so you can tailor a special interest talk to a specific audience. Talks with reasonable amounts of assumed knowledge, including talks aimed primarily at programmers or systems administrators, are suitable special interest talks, as are talks about specific uses of Free Software such as running a Free Software project or running a business that uses Free Software that might not be of interest to all attendees.

SLUGlets

Length: 10 minutes to 45 minutes. However speakers must not prepare 45 minutes of material — instead, they should prepare material for a tutorial and discussion. This will mean that the speaker will probably only talk for one quarter of their allocated time.

SLUGlet sessions run in parallel with the special interest talk. SLUGlets sessions have a tutorial format, and talks given at SLUGlets sessions should be shorter and allow for — and encourage — a great deal of interactivity. Ideally, SLUGlets speakers run a discussion, rather than give a talk. SLUGlets should be introductory level, accessible to newcomers to Linux.

Preparing your talk

What do you want to say?

In short: say what the audience wants to hear. The SLUG membership comprises mainly Linux hobbyists and some Linux professionals. Most attendees have a few years experience with Linux, but some don't.

If you're giving a general talk, you will need to pitch your talk at all of these people, so you will need to have something to say to both people new to Linux and to people who have been using Linux for a while. If you don't think your talk appeals to both groups, consider giving another talk type instead. Loosely, the aim of a general talk should be to get audience members thinking "hey, that's cool" and hopefully give them something to try at home.

If you're giving a special interest talk, you can afford to assume the audience is already interested in your general topic area, but you can't assume that they necessarily know much about it. Hence, special interest talks have tended to converge on walking people through a particular framework — whether it is features of a programming language, or architecture of a Free Software app. Picking the audience of a special interest talk might be tricky — be prepared to work through introductory material faster than you intended, or to spend your entire talk giving what you had intended to be introductory material.

If you're giving a SLUGlets talk, your material will need to be introductory level. You should definitely attend at least one SLUGlets session before attempting to run a SLUGlet tutorial.

The best way to gauge the audience would be to attend a few SLUG meetings, ideally talks in the same area as yours. Listen to the audience: were the questions above or below the level of knowledge assumed for the talk? Which parts of the talk were the questions about? Aim your own talk at the level of these questions.

In any case, presumably you are giving a talk about something that enthuses you, so you need to consider how to enthuse the audience. Your own enthusiasm helps here.

SLUG members are generally interested in practical demonstrations and concrete facts. Technical people are leery of unsupported claims, so support claims you make.

Sticking to the time limit

People whose last experience of public speaking was when they were a child are often surprised when their talk runs over-time. It is extremely common for this to happen: over-time talks are much more common than under-time talks. SLUG welcomes speakers who are relatively inexperienced at giving extended talks. However, this means that some of our speakers don't know just how short 30 minutes is.

30 minutes is not a long time to talk about something. 10 minutes is far shorter. It sounds like a long time to people who haven't done formal public speaking since school, but it isn't.

Here is a rough guide to what you can cover in 5 minutes, in 10 minutes, and in 30 minutes.

If you speak using slides, 5 minutes is about 5 slides, including an introduction slide. A good demo, demonstrating one simple thing fairly solidly, lasts about 5 minutes once you allow for opening the window, starting the program, finding where you are on the screen, demonstrating, explaining, and finishing off. So if you're giving a 5 minute talk, you have room for exactly 1 good demo without slides. If you're not giving a demonstration, you can cover a couple of points fairly shallowly.

10 minutes is about 7 slides (the slides to minutes ratio falls for longer talks). You probably still only have time for 1 demo, but you can probably afford 1 point and a demo; or 2 or 3 points with about 2 slides each. If everything you say is to be covered by demos, you would have time for 2 demos.

A 30 minute talk is about 15 or 20 slides. Experienced speakers will tend to require less slides. A good 30 minute talk might consist of 3 or 4 major points, with 2 or 3 sub-points (1 sub-point per slide) each.

If your entire 30 minute talk is a series of demonstrations, you can probably do 4 or 5 demonstrations. For each major point you intend to cover by talking, subtract 1 demonstration.

Be sparing with your slides. The more slides you have, the more likely it is you will go over-time.

There is not too much chance you will run under-time. It is extremely rare for that to happen at meetings like SLUG's. Your main concern should be finishing in the time available. If you are worried that you have too much or two little, test-run your talk in front of an audience and time it. You will talk about 10% faster than your fastest rehearsal.

If you do run over-time during your talk, a meeting organiser will probably try and hurry you up, and you may have to cut your talk short, since it's important that the meetings run to time. There's nothing really wrong with this happening, but you'll feel more comfortable if you've got your material roughly matched to your time constraints.

You might want to make the last third or so of your material "optional extras" like demonstrations, or in depth explanations of some things skimmed over earlier in the talk. If you have done this, you can drop the last third if you are running out of time without leaving out the meat of the talk.

Making good slides

As is pointed out later, your audience can read your slides and listen to your talk at the same time. Don't put your entire talk on your slides or the audience will get bored listening to you say what they have already read from your slides.

Don't prepare the structure of your talk by doing your slides, or your slides will read like speaker's notes. Prepare an outline of your talk separately, and prepare your slides using that outline. The titles of your slides should follow the outline: major points get their own section of the slides, minor points become the title of an individual slide.

Make sure your text and slide background strongly contrast: light text on a very dark background or dark text on a very light background. Make sure your font is fairly large (something like 28 point seems to work OK but this will vary based on your slide software).

Any individual slide should contain either text or a figure of some kind.

Slides are excellent for presenting any data that is better presented visually than explained verbally. There are plenty of examples of information that should be presented visually: diagrams of the subparts of a project; graphs showing the general trend from a bunch of figures; and tables comparing features in different projects. If you have this kind of data to present, show it in a slide rather than trying to explain it, or worse still, reading out lists of numbers.

Some kinds of text are also better read by the audience than read out loud. A good example is code listings: code listings are both boring and hard to follow when read out loud, whereas short code segments are easy for programmers to understand if read from your slides. Other examples of text that should go in your slides and not be read out include sample configuration files and sample commands.

Stick to 1 diagram or example per slide. Examples should be as trivial as you can make them while still showing whatever you want them to show. In particular, keep code listings to 15 lines at the absolute most.

Most speakers also use their slides to give short summaries that basically follow the structure of the talk. This is also useful, as it helps orient audience members and allows them to tune in to interesting parts of the talk. It also supplements the talk: the information on the slides might help them follow an otherwise difficult part of the talk by emphasising the important details or facts. These slides are normally bullet-point style.

On text slides of this type, stick to 4 or 5 bullet-points. Each bullet point should be at most a very short sentence. You can use the bullet-points to give a summary of your talk, but make sure your talk is bigger than the slides: it should substantially elaborate on the slides. Don't put all the meat in the slides, just the basic points. Another approach is to use the bullet-points as the basis for a discussion in your talk. For example, use the bullet-points to list facts or statistics that you want to discuss and compare.

Have a concluding slide that contains important reference materials and any contact details you want to share (speakers normally give an email address). Leave this slide up at the end of the talk so that people can copy information from it. It should definitely include the homepage(s) of the project(s) you were discussing, if any.

Resources

• Akkana Peck's Using Linux for Presentations Mini-HOWTO, which describes Linux slide tools.

Giving your talk

Speaking

The three most important things to do physically are to speak slowly, speak loudly, and to look at the audience.

If you can remember, smile at the audience. Smiling is a positive feedback loop: they'll smile back, which will make you smile more and feel happy and confident. They'll react well to you being happy and confident.

If you're nervous about speaking, make your introduction especially long. This gives you lots of time to settle in, and since it's introductory material, if you're a bit soft or fast at the beginning, the audience won't miss the meat of your talk.

Every once in a while, probably major breaks in your talk, consciously take a few breathes, slow down, and speak up. Pauses between major points are a good idea anyway, they bring the audience back on board.

Using slides

The most important tip I can give you about using slides is that your audience can read them too. Most of the audience members can read them much faster than you can read them out loud, in fact. The audience does not want you to read your slides to them, because by the time you've done that, they've had the chance to read them three times.

There are some important exceptions to this, particularly vision impaired people, but in general you should think of your slides and your words as separate yet complimentary sets of information. You're being given the opportunity to present information two different ways: visually and audibly. Use them to present information in different ways.

Keeping all this in mind, you should also try and make your talk understandable without your slides. It will flow better, and it will be accessible to people who can't read the slides. It will not be practical, as pointed out earlier, to do things like read out code listings, but you should explain what they do and what concepts they illustrate. For charts, explain briefly the general trend that is visible in them. Don't expect leave crucial pieces of information entirely for the slides to explain.

Your slides are an excellent way of conveying information like the outline of a talk, a set of definitions, or the major points. You may want to supplement this information by paraphrasing it, which will give the audience an alternative way of thinking about what you're saying, and will also help vision-impaired audience members. Paraphrasing is good, further explanation is good, but reading your slides out loud is a waste of people's mental bandwidth.

Giving demos

It is extra important to rehearse demonstrations. Don't ever give a demonstration that you haven't rehearsed.

During your rehearsals ask yourself "how much of the set up can I do before the talk?" Make a list of what windows you need open, what programs you need running, and see if you can start them before the talk. If you can't, at least you'll know which steps to carry out.

If you need to set up any hardware, for example speakers, arrange with the meeting organisers to do this at the start of the meeting.

A very important thing to keep in mind for demonstrations is that you will need to make fonts very large if anyone is to read anything you are demonstrating. If anything needs to be read, make sure the font in the appropriate application (e.g. your terminal or your browser) is around 24 points. Make it this large in your rehearsal so that you know that all the text will fit on the screen. Also, as with slides, make sure there is a high contrast between background and foreground colours.

Dealing with the audience

If you are enthused about the topic, you will enthuse the audience. In general, provided you approach the topic in a way that will interest SLUG members you won't encounter hostility in the audience. Make sure you're prepared for polite criticism of your subject matter (not of you!) though.

The most common problem is the audience member who uses the opportunity to ask a question as a soap box, followed by the audience member who feels compelled to answer your questions or give your speech for you.

Before your talk, tell the meeting organiser or MC whether or not you will take questions during your talk. If you don't want them, the MC will ask people not to interrupt. Even if you do want them, the MC will probably interrupt long discussions to let you keep talking (once two audience members begin talking to each other rather than to the speaker, they certainly should be interrupted or the talk will derail).

Even if you do want questions, if someone asks a question that has a long answer tell them that you'll discuss it during question time or in person. If someone asks something that's answered later in the talk, tell them that.

Democracy during question time does not work, but fairness does. If someone is getting carried away with a barrage of questions, disputes or answers, call on someone else and mentally put them at the end of your question queue.

SLUGlets do not have separate question times, and SLUGlet talks are audience directed, so much of this advice does not apply. For a SLUGlet, make sure that the discussion is not dominated by the loudest audience members, but you may let the audience carry the discussion as much as they and you are comfortable with.

Acknowledgements

Thanks to Andrew Bennetts for proof-reading this guide and for the tip about adding an optional bit to the end of your talk to drop if necessary. Thanks to Robert Dale, who taught Macquarie University's useful COMP495: Academic Presentation and Writing Skills course in 2003, and who patiently sat through a bunch of my rehearsals later that year. Much of the material in this guide about timing and rehearsals draws on that course. In particular, that's where the tip about presentations being speedier than rehearsals by 10% comes from. Thanks to Toss Gascoigne and Jenni Metcalfe from Econnect Communication who gave a speaking workshop to myself and other vacation students at CMIS in February 2002. That workshop taught me a great deal about audience-oriented (as opposed to speaker-oriented) talks.

Linux Australia runs a jobs database for advertising and searching for jobs. As well as the jobs listing on the web site, you can subscribe to the mailing list that the jobs ads are sent to as they are posted.

SLUG also runs its own jobs mailing list. It's a moderated mailing list for people looking for Linux related work, and employers offering jobs that require experience with Linux or related software. If you wish to advertise a position, send an e-mail to jobs@slug.org.au and we'll approve it.

If you're an employer with a Linux- or FOSS-related job to offer, these are great places to find people with the skills you're after. They run as free services to the Linux community and allow you to post any jobs that specifically require Linux or FOSS skills. To ensure that your message is accepted, be sure to follow the directions on the sign-up page for each list.

If you apply for a job through any of these lists, please let the recipient know where you found the advertisement. Hopefully this will encourage employers and recruiters to use our jobs lists even more!