Russell Coker: Things you can do for your LUG
A Linux Users Group like most volunteer organisations will often have a small portion of the membership making most of the contributions. I believe that every LUG has many people who would like to contribute but don’t know how, here are some suggestions for what you can do.
Firstly offer talks. Many people seem to believe that giving a talk for a LUG requires expert knowledge. While it is desired to get any experts in the area to share their knowledge, it is definitely not a requirement that you be an expert to give a talk. The only requirement is that you know more than the audience - and a small amount of research can achieve that goal.
One popular talk that is often given is “what’s new in Linux”. This is not a talk that requires deep knowledge, it does require spending some time reading the news (which lots of people do for fun anyway). So if you spend an average of 30 minutes a day every week day reading about new developments in Linux and other new technology, you could spend another minute a day (20 minutes a month) making notes and the result would be a 10 to 15 minute talk that would be well received. A talk about what’s new is one way that a novice can give a presentation that will get the attention of all the experts (who know their own area well but often don’t have time to see the big picture).
There are many aspects of Linux that are subtle, tricky, and widely misunderstood. Often mastering them is a matter that is more related to spending time testing than anything else. An example of this is the chmod command (and all the Unix permissions that are associated with it). I believe that the majority of Linux users don’t understand all the subtleties of Unix permissions (I have even seen an employee of a Linux vendor make an error in this regard while running a formal training session). A newbie who spent a few hours trying the various combinations of chmod etc and spoke about the results could give a talk that would teach something to almost everyone in the audience. I believe that there are many other potential talk topics of this nature.
One thing that is often overlooked when considering how to contribute to LUGs is the possibility of sharing hardware. We all have all the software we need for free but hardware still costs money. If you have some hardware that hasn’t been used for a year then consider whether you will ever use it again, if it’s not likely to be used then offer it to your LUG (either via a mailing list or by just bringing it to a meeting). Also if you see some hardware that is about to be discarded and you think that someone in your LUG will like it then grab it! In a typical year I give away a couple of car-loads of second-hand hardware, most of it was about to be thrown out by a client so I grab it for my local LUG. Taking such hardware reduces disposal costs for my clients, prevents computer gear from poisoning landfill (you’re not supposed to put it in the garbage but most people do), and helps random people who need hardware.
One common use for the hardware I give away is for children. Most people are hesitant to buy hardware specifically for children as it only takes one incident of playing with the switch labeled 240V/110V (or something of a similar nature) to destroy it. Free hardware allows children to get more access to computers at an early age.
Finally one way to contribute is by joining the committee. Many people find it difficult to attend meetings, so attending a regular meeting and a committee meeting every month is difficult. So if you have no problems in attending meetings then please consider contributing in this way.
A common way to debug a network server is to use 'telnet' or 'nc' to
connect to the server and issue some commands in the protocol to verify
whether everything is working correctly. That obviously only works for
ASCII protocols (as opposed to binary protocols), and it obviously also
only works if you're not using any encryption.
But that doesn't mean you can't test an encrypted protocol in a
similar way, thanks to openssl's s_client:
(including English!)
The string freeze of Debian Installer officially ended at 23:59
yesterday (Sept. 20th). Indeed, this was extended a bit to today, with
agreement by Otavio Salvador who I thank for this.
That allowed Zak to "save" Tagalog and also the Welsh and Latvian
translators to polish their work.
We now have to decide about some of these languages: those that failed
to meet the release criteria but were formerly activated in D-I. There
are four such languages: Amharic, Welsh, Estonian and Northern Sami.
Please find below the mail I just sent to debian-i18n and
debian-boot. I promised that this discussion would happen in
public. It will (but it will be short as we can't delay the release of
the installer for ages....and I think that my proposals are
reasonable!)
went to a concert (thanks to my flat-mate david).

I was already used to regularly receiving
Wow, don't even remotely remember anymore when I was last blogging about going to the cinema. Granted, I wasn't that often in recent times, but I haven't mentioned some movies... Whatever.
Yesteday I have been to cinema again, and we watched "
If you are working with Eclipse on a Java project, make sure to try a regular
(ant) build from time to time. The eclipse compiler sometimes differs quite a
lot in what it accepts (especially when it comes to generics it seems to be a
bit more clever) or considers a warning.No, I did not just disable a warning. Eclipse did report some
"serialVersionUID" warnings, but it missed lots of them, too. I have the vague
impression that the Eclipse java compiler didn't recognize that a class
implementing the "Externalizable" interface also should have a serial version
UID.And unfortunately I didn't find a way to reach the serial UID generation
quickfix without having an eclipse warning... Well, after all there is not
much wrong with starting the serial version at 1L.

(