MESSAGE
| DATE | 2009-08-05 |
| FROM | Ruben Safir
|
| SUBJECT | Re: [NYLXS - HANGOUT] closest I've found to a conference HOW-TO
|
On Tue, Aug 04, 2009 at 08:36:27AM -0400, Contrarian wrote:
>
> But it's a LUG HOW-To
>
Date and place for installfest?
Ruben
> Finally found this with "Rick Moen" without "conference"
>
>
> Recipe for a Successful Linux User Group
> http://linuxmafia.com/faq/Linux_PR/newlug.html
>
>
> Recipe for a Successful Linux User Group
>
> by Rick Moen
>
> Last revised: 2008-11-13
>
> Having seen (and run) quite a few Linux user groups (LUGs), and
> observed some thrive and others die, I can hazard some firm
> recommendations. If you're thinking of starting a LUG, or are running
> one now, please ponder these lessons, drawn from other LUGs'
> experience. In fact, please consider reviewing this list from time to
> time, as a kind of checklist.
>
> 1. You need a Web page.
>
> I can't stress this enough. The Internet is crucial to Linux: It made
> Linux possible, and is where everything happens. If your group isn't
> on the Net, it might as well not exist.
>
> By "the Net", I mean not just Web pages, which are its most-visible
> service, but also mailing lists, Usenet newsgroups, and ftp file
> archives, among other things. It's your source for software, the forge
> where open-source tools are designed and crafted, your method of
> publication, your social club, and your research library.
>
> Each major function of your group should have a Web page: If you start
> doing InstallFests, create an InstallFest page.
>
> 2. Your Web page needs a reasonable URL.
>
> The usual http://www.some-isp.com/~username/lugname/ URL isn't good
> enough: You want people who know no more than the group's name to find
> you easily. For that, http://www.lugname.org/ is ideal in the USA --
> and you can use similar formulas elsewhere, such as
> http://www.lugname.org.au/ . Consider choosing a group name whose
> Internet domain isn't taken (check at
> http://www.internic.net/whois.html, for com/org/net domains), and then
> paying to register that domain and have an ISP virtual-host it. It's
> not that expensive.
>
> Given that this is the Linux world, the odds are that one or more of
> your core volunteers owns a co-located Internet host, and will be
> willing to host your pages and domain for free.
>
> The odds are that your Web page will start out somewhere less
> desirable, such as a subdirectory of someone's home page, or a free
> hosting service such as Geocities -- but you should aim towards having
> your own domain, in the longer term.
>
> Remember that the Net is world-wide: If the best/cheapest hosting is
> at (say) a friendly LUG site on another continent, take it.
>
> 3. You need a regular meeting location.
>
> Changing meeting locations risks losing attendees like mad. Why?
> Because some will come to the prior meeting location, instead, get
> discouraged, and maybe even conclude that your group has folded -- and
> also because finding out how to get there, where to park, whether the
> neighbourhood's OK to walk in, etc., is a strain on people, each time
> you move.
>
> The location doesn't have to be impressive: I've seen a college
> cafeteria suffice for one group, and a small downstairs room in
> someone's house do well for another. It just has to be reliably
> usable.
>
> 4. You need a regular meeting time.
>
> "Regular" usually means following an easily-remembered-and-used
> formula, suitable for people's calendars, pocket planners, and
> PalmPilots -- such as 4th Thursday. Don't get fancy with things like
> "every other Thursday": Make it so anyone with a calendar can easily
> figure out when the next meeting will be.
>
> 5. You need to avoid meeting-time conflicts.
>
> Check out the schedules for nearby technical events: Linux user
> groups, Perl groups, and whatever else your target audience is likely
> to want to also attend. Don't pick recurring dates that those other
> groups are already using. Hint: 1st & 2nd Tuesdays, Wednesdays, and
> Thursdays are over-popular meeting days: Their attraction is that
> they're easy to remember -- and mid-week days are generally good for
> people. But, in my immediate vicinity (for example), there are four
> competing groups sharing first Tuesdays.
>
> 6. You need to make sure that meetings happen as advertised, without
> fail.
>
> One LUG in my area fell apart largely because the president set an
> aggressive meeting schedule, and then failed to show up to unlock the
> meeting room. Would-be attendees then looked up the next meeting date
> on the Web, showed up, found a locked door, and (soon) give up on the
> group entirely. So, if possible, have multiple people arrange to show
> up early. Also, post signs/flyers near the meeting site.
>
> If you need to cancel or reschedule an event that you've already been
> advertising as "upcoming", don't simply remove the original listing on
> your Web pages: Continue to list it, prominently marked as
> cancelled/rescheduled.
>
> 7. You need a core of several Linux enthusiasts.
>
> LUGs have succeeded wonderfully on the strength of ongoing efforts
> from as few as four energetic and inquisitive people. That's really
> all you need, but one or two are not enough. E-mail is terrific for
> coordination.
>
> Your core enthusiasts don't need any Linux knowledge initially, but
> must be "self-starters", and must have Internet access and know how to
> use it well.
>
> 8. Your core volunteers need out-of-band methods of communication.
>
> By that, I mean outside your user group's regular electronic means of
> communication. One college LUG operated all e-mail mailboxes used by
> its officers through the LUG's Web server machine, which then went
> down at the beginning of summer recess. It thus proved the proverbial
> "single point of failure" for group communications. Most officers
> change residences at the academic year's end, and there weren't even
> summer LUG meetings scheduled for regular dates, so the LUG nearly
> collapsed because its principals lacked any means of getting back in
> contact with one another.
>
> Having circulated a list of stable non-LUG e-mail addresses, telephone
> numbers, and/or postal addresses would have averted this
> near-disaster.
>
> 9. You need to get on the main lists of LUGs, and keep your entries
> accurate.
> * http://lugww.counter.li.org/
> * http://nlug.org/webring/
> * http://www.redhat.com/opensourcenow/
> * http://www.linux.org/groups/
> * http://dmoz.org/Computers/Software/Operating_Systems/Linux/User_Gr
> oups/
> * http://dir.yahoo.com/Computers_and_Internet/Software/
> Operating_Systems/Unix/Linux/User_Groups/
>
> Assign someone in your group to re-check your LUG list entries
> periodically, say, every quarter. You'll be amazed at how inaccurate
> they become over time. Keep a list of all the places where you have
> such entries, and also a "publicity" list (of places you send notices
> of upcoming events). Sometimes, it helps to print these out and use
> them literally as checklists.
>
> An inaccurate LUG-list entry is often much worse than none at all:
> When it directs prospective members to an obsolete URL, or tells them
> the wrong meeting date, that actively hurts your membership effort.
>
> So, before submitting an entry to any LUG list, do some spot checks on
> the existing entries' general level of accuracy. Widespread inaccuracy
> (e.g., dead links, wrong information on meeting dates and places) may
> indicate a hidden gotcha: Some lists are so badly maintained that
> their staffers ignore corrections you send in. For example:
> * http://www.currents.net/resources/usergroups/usanc.html
>
> That list is a trap for the unwary LUG leader, in accepting additions
> but appearing to ignore correction/update notices: Once your entry
> becomes out of date, it stays that way.
>
> (Some will have noticed the dropping of linux.com's longtime LUG list:
> The site's owner, VA Software Corporation, decided around September
> 2002 to blow away seemingly all pages not aimed solely at the Fortune
> 500. Oh well. No big loss.)
>
> (More sadly, SSC, Inc. summarily deleted the GLUE = Groups of Linux
> Users Everywhere directory some time in 2005 and replaced it with a
> Web redirect to www.linuxjournal.com. That extensive LUG database and
> information exchange will be sorely missed, and it's a shame SSC
> offered nobody in the Linux community any opportunity to adopt the
> site.)
>
> 10. You must have login access to maintain your Web pages, as needed.
>
> An unchanging page that someone else created for you isn't good
> enough: You need to be able to fix/edit/enlarge your site on short
> notice. Typically, this requires login access via ssh [1] (or telnet,
> if necessary) to the hosting Web server's command shell.
>
> A number of Linux groups attempt to get by with a static page on some
> site to which they themselves lack maintenance access -- for example,
> on a parent group's existing Web site. The convenience isn't worth the
> disadvantages: Don't go that route.
>
> 11. Design your Web page to be forgiving of deferred maintenance.
>
> Much as we'd like our LUGs' "upcoming events" and other time-sensitive
> information to be always current, it isn't going to happen: Sometimes,
> you don't re-check and update them for a week or two. Therefore,
> always list several months' upcoming events. (You know when they'll be
> because you have a meeting-date formula, right?) That way, when you're
> unavailable for Web-page maintenance for two months running, the Web
> page will still include current meeting information.
>
> Somehow, my local LUGs' webmasters seem resistant to that simple idea,
> with the result that most list only one upcoming meeting at a time,
> which, for three quarters of the month, because of the inevitable
> deferred maintenance, ends up being last month's date.
>
> The whole point of listing specific upcoming meeting dates is to make
> it unnecessary for casual visitors to work out when the next (say) 2nd
> Tuesday will be, by doing it for them. But that effort is wasted when
> the only meetings shown are already past: It makes new LUG members
> that much less likely, and additionally may lead some to think your
> LUG is now defunct.
>
> 12. Always include the day of the week, when you cite event dates.
> Always check that day of the week, first, using gcal [2] (or cal).
> gcal is your friend.
>
> Why always include the day of the week, on event listings? Because
> that gives viewers their best shot at remembering your event, how many
> days away it is, and how it fits into their schedules.
>
> Additionally, the fact that you've furnished the correct day of the
> week for each date reassures visitors that you haven't messed up and
> listed the wrong date (which happens depressingly often) -- in effect,
> a cross-check. Conversely, take care not to list a meeting's date
> correctly, but with the day wrong. That conveys the (probably
> accurate) impression that your event calendar can't be trusted.
>
> It doesn't hurt to print out the current year's "gcal" listings, for
> reference whenever you're doing calendar work. Mark significant
> holidays for your country on it: You can get them from
> http://www.religioustolerance.org/main_day1.htm,
> http://www.web-holidays.com/,
> http://www.mozilla.org/projects/calendar/holidays.html,
> http://www.apple.com/downloads/macosx/calendars/, etc.
>
> 13. Place time-sensitive and key information prominently near the top
> of your main Web page.
>
> Don't banish all meeting information to your events page, or tuck it
> into an unobtrusive text box for aesthetic reasons: Ensure that the
> most prominent items on your site are the ones viewers need most.
> Consider using "STRONG" or "EM" HTML tags on particularly important
> items, such as your date formula (e.g., "second Tuesdays at 7 PM").
>
> Displaying time-sensitive information prominently is useful not only
> because that tends to be what viewers seek most often, but also
> because such text calls your attention to itself, when it needs
> updating. Think of this as comparable to putting perishables near the
> front of your refrigerator, date-stamp outwards.
>
> 14. Include maps and directions to your events.
>
> Some prospective members will be comfortable with maps, others with
> directions; you'll want to help both. Maps can be generated (for the
> USA, at least) on Yahoo Maps, Google Maps, MapQuest, or MSN Maps
> (formerly MapBlast). Have them as links for each listed event
> location. If there's a trick to parking nearby, describe it. If public
> transit is available, give details.
>
> Remember: Directions and maps are (particularly) for people who aren't
> yet members, not for your existing "in-crowd". The Web page for one
> LUG near me used to omit maps and directions, giving only the meeting
> date/time and the name of the building where it met. Don't fall into
> this common trap of making your pages useful only for existing LUG
> members.
>
> One of the themes of this essay, in fact, is: Try at intervals to look
> over your LUG's public information as if you were an interested
> newcomer. Does your public information (e.g., your Web pages) tell
> prospective members what they need to know? Is the most important and
> most time-sensitive information also the most prominent? If not, you
> need to redesign it.
>
> 15. Emphasise on your main page that your meeting will be free of
> charge and open to the public (if it is).
>
> Believe it or not, some prospective members will assume your group
> costs money, unless you say otherwise. This is especially true of
> people accustomed to traditional user groups, which generally must
> charge dues to finance their dead-tree-media newsletters and other
> money-intensive operations. (See addendum #1.)
>
> Conversely, if there will be an attendance fee (e.g., to pay for
> dinner), say so prominently, with the other event details.
>
> 16. You'll want to include an RSVP "mailto" hyperlink, on some events.
>
> Set up an e-mail alias of "rsvp-at-groupname.com" pointing to the real
> mailbox of one or more volunteer, and include it as a link on event
> listings when you need an advance head-count (e.g., at restaurants).
>
> Other aliases you'll want -- if you operate your own Web server -- may
> include "webmaster", "postmaster", "president", "webteam", and "help".
> If you use such aliases consistently for roles people fill, you'll be
> better equipped to handle smoothly the inevitable turnover in
> volunteers, over time.
>
> 17. Use referral pages.
>
> Over time, you'll find it desirable to reorganise your Web documents,
> rename pages or directories, or move the whole site (or part of it) to
> a different Web server. That's inevitable -- but don't forget that
> other Linux groups, user group lists, search engines, and assorted
> individuals will have already created links to your old URLs, without
> telling you they've done so. Thus, if you just move/rename your Web
> documents, you will break one means by which interested parties are
> accustomed to finding you.
>
> The cure is to leave a "referral page" at the URL where the document
> used to be, guiding the user to its new location. Get in the habit of
> doing this whenever you would otherwise leave nothing where there used
> to be a page: It's better than their getting a 404 error.
>
> Here's an example:
>
>
>
>
>
> New location for FOO Home Page
>
>
> The FOO home page has moved! The new location is > HREF="http://www.newlocation.com/">http://www.newlocation.com/
>
>
>
> 2008-11-13 note: A correspondent wants me to replace the above with a
> recommendation of doing httpd status code 301 (permanently moved page)
> redirects inside the Web server configuration file. This is indeed
> ideal -- for those who have access to reconfigure and then restart the
> relevant Web server, and who also have mastered configuration of that
> particular software. (Naturally, "permanent redirect" details differ
> between Web server packages.) The problem with the above-described
> META refresh technique is that spammers' pages use it to try to trick
> search engines, and so the engines discount the "page rank" (etc.)
> value of such links.
>
> Other aspects of site configuration can complicate implementation of a
> 301 redirect, such as whether the httpd maps multiple domains to the
> same IP. Anyway, if interested in this sort of webmaster neepery, you
> know how to search for it. (If tempted to use Apache httpd's
> "mod_rewrite" code as opposed to "Redirect permanent" or "Redirect
> 301" directives for such a project, best of luck to you.)
>
> 18. Make sure every page has a revision date and maintainer link.
>
> It's traditional to put some variation on "Send feedback to [link]" or
> "Copyright (C) 2000 by [link]", or "Webmaster: [link]" where "[link]"
> is the maintainer's name with a "mailto" hyperlink. And there's a good
> reason for this tradition: It ensures that "feedback" comments -- from
> sharp-eyed readers who catch errors, omissions, and ambiguities in
> your public information -- will reach the right person. Make it easy
> for the public to help you, and some of them will.
>
> Putting a date stamp at the bottom of each page, whenever you update
> it, reassures visitors that the site really is current. You may know
> that it's a living site with current data, but newcomers won't. Dead
> sites with obsolete data are far too common on the Web, and the date
> stamp marks your page as freshly edited. (Equally, it reminds you of
> when you last overhauled the site.)
>
> Need I mention that the worst-maintained LUG sites in my area lack
> revision dates and maintainer links? It's true.
>
> 19. Check all links, at intervals.
>
> Probably your pages will contain numerous links to external sites, as
> well as to other parts of the same site. The remote sites can and do
> move around (or disappear) without your having heard, and local links
> can and will break because of your own imperfect maintenance.
>
> There's a quick and easy way to catch all such breakage: Open your Web
> browser and clear its cache, which makes all links appear as unread.
> Now, visit each link in turn. If you do this at intervals (e.g., every
> six months), you'll at least find any broken links, and maybe other
> people's referral pages for remote pages that have moved.
>
> It's possible (but a non-trivial task) to find all sites that link to
> your pages, by analysing your Web server's log files. That knowledge
> will prove useful when, for example, your Web site moves or gets
> substantially reorganised. (You can then advise the other webmasters.)
> If you're feeling ambitious, try to find them. Search engines are
> useful for that task: Google, Infoseek, Altavista, and others. (Don't
> forget dejanews.com, for searching Usenet posts.)
>
> One tactic that doesn't work: putting a note to webmasters on your
> site, asking them to let you know of links to it. I had such a request
> on my Bay Area Linux Events page (http://linuxmafia.com/bale/) for
> seven years, with zero responses.
>
> 20. You may want to consider establishing a LUG mailing list.
>
> Any reasonable Linux host (machine) with a constant Internet
> connection can run mailing-list software. GNU Mailman
> (http://www.list.org/), for example, is easy to set up and administer,
> and comes with automatic Web-archiving for your mailing list. Many
> groups find it useful to have both a main discussion list and a
> low-volume announcement-only list.
>
> Do not announce your upcoming meetings only to your mailing lists: By
> definition, those will reach only existing members. The whole point of
> having a public presence (e.g., Web pages) is to both serve existing
> members and attract new ones.
>
> Some commercial services let you set up "free" mailing lists on their
> servers, where their gain lies in revenues from mandatory ads
> auto-appended to all posts, plus of course the ability to sell your
> subscription list to other advertisers. Beware that you may find
> yourself not the "owner" of your own list, in the event of a dispute
> over its management.
>
> Some groups have founded Web-based discussion forums, instead of
> e-mail mailing lists, either on their own servers or on commercial
> services. I have yet to see one that wasn't stagnant and inbred. The
> advantage of e-mail mailing lists is that e-mail is universal and
> convenient for people, generally.
>
> If you do run LUG mailing lists, someone will have to function as list
> "owner", taking care of administrative requests and enforcing list
> policy. The latter category will include dealing with job recruiters:
> Many LUG lists have been overwhelmed with job ads from professional
> recruiters, sometimes posted multiple times a day. A policy that has
> worked well at one LUG is to require that all job ads be submitted to
> a club officer, who then posts it with a subject header starting with
> the string "JOBOFFER:" That way, the jobs postings' volume can be
> controlled, and people not wanting to see them can filter on subject
> headers.
>
> 21. You don't need to be in the Internet Service Provider business.
>
> Leave the ISP business to the professionals. You won't be able to beat
> their prices, so don't try. When the moochers in your crowd ask for
> dial-in lines and shell accounts on the group's Web server, say "No."
>
> 22. Don't go into any other business, either.
>
> I hear of LUGs being suckered into the strangest, most cockamamie
> business schemes. Don't: Don't try to be a Web design firm, a
> technical support firm, a network design consulting firm, or a LAN
> cabling contractor. Or any other business. Not even if you're told
> it's for a wonderful charitable cause.
>
> Along the same lines, remember that you are not a convenience for job
> recruiters: If allowed, they will spam your mailing lists and abuse
> every possible means of communication with your members. Nor are you a
> source of computers for the underprivileged, a repair service for
> random people's broken PCs, or a help desk for non-Linux operating
> systems and applications. Believe it or not, you will be pestered by
> all of the above sorts of strangers, on the "nothing ventured, nothing
> gained" theory.
>
> 23. Walk the walk.
>
> It's painfully grotesque to see so-called Linux user groups mailing
> out announcements using MS-Outlook, Eudora, or Netscape Messenger for
> MS-Windows (or MacOS), or other proprietary mailers for legacy
> operating systems -- and visibly maintaining their Web sites using MS
> Front Page, Adobe Page Mill, or other junkware -- and hosting their
> LUG mailing lists on Yahoo Groups (formerly eGroups and Onelist,
> formerly MakeList) or Google Groups. Fortunately, these LUGs are in
> the minority, but they convey the message of Linux being suitable in
> neither desktop nor server roles.
>
> If you are going to promote and explore Linux, you need to use it. If
> you don't know what good, open-source tools for Linux exist to create
> and manage Web sites (such as Bluefish, Screem, Mozilla Composer,
> Amaya, Quanta Plus, and PHP), then ask around. Ditto for mail user
> agents: Ask around, and you'll hear about excellent native-Linux
> mailers such as Mutt, Mozilla Thunderbird, Sylpheed, KMail, Mahogany,
> Balsa, Aethera, Evolution, Pronto, and Spruce. Ditto for mailing list
> hosting: It's just unbelievably feeble and lame to have Yahoo Groups,
> Google Groups, Topica, or some other "free" commercial service run
> your mailing list when GNU Mailman comes already set up and working on
> major Linux distributions, complete with automatic Web archiving and
> Web-based administration -- plus you can even add to it mnoGoSearch as
> an archive search engine, if you wish.
>
> Don't volunteer to look like losers in public: As the saying goes, a
> LUG needs to "eat its own dog food".
>
> Addendum #1: A note about parent groups.
>
> Many a LUG has gotten started as a sub-group of a more-established
> parent, usually a general-purpose computer user group. For example,
> SVLUG (http://www.svlug.org/), one of the world's largest LUGs, when
> founded and for many years thereafter, was technically a SIG (Special
> Interest Group) of the Silicon Valley Computer Society (SVCS).
>
> The advantage to such an arrangement is that you can gain insurance
> coverage, incorporation, and acknowledged non-profit tax status,
> without having to handle the paperwork and expense of those efforts,
> yourself. Depending on the people involved, the relationship can also
> create genuine symbiosis (such as SVLUG having provided free Internet
> services for SVCS).
>
> There are also offsetting disadvantages: Established PC user groups
> are often in decline, and tend to be run by people devoted to legacy
> proprietary OSes who have no understanding of Linux or open-source
> software. The potential for culture clash is a serious one, and the
> odds are that your LUG members will have little interest in the parent
> group's other functions.
>
> Old-line PC user groups tend to have annual dues of US $40 and up, for
> all members, and often charge admission for their monthly meetings.
> They adopt this model in order to finance their paper-published
> newsletters, (sometimes) to rent meeting space, and to pay sundry
> administrative costs such as telephone and corporate-filings fees.
>
> By contrast, a LUG can operate with expenses approaching zero: Its
> publications can be Web-based. Notices can be sent via e-mail instead
> of on flyers. Meeting space can usually be gotten for free at ISPs,
> colleges, pizza parlours, brewpubs, coffeehouses, computer-training
> firms, Linux-oriented companies, or other friendly institutions, and
> can therefore be free of charge to the public. Having thus arranged to
> have roughly zero revenues as well as expenses, there is little need
> for tax-exempt status or incorporation. About the only thing you
> forego without incorporation is insurance and liability-protection,
> which shouldn't be a problem for modestly careful people.
>
> So, the advantages of having a parent group are somewhat smaller than
> would appear at first glance. You may find the parent group trying to
> dictate your sub-group's policies, including the content and location
> of its Web pages, and unhappy with your members who disregard the
> parent group and fail to pay its membership dues. This has led some
> Linux SIGs to split off from their parents as independent LUGs. Others
> quickly become the tail that wags the dog, as with SVLUG and SVCS.
> Some groups achieve other long-term arrangements, with varying degrees
> of happiness on both sides.
>
> Be aware of the issues and possible outcomes, in any event.
>
> Addendum #2: LUG checklist.
>
> The following checklist may be useful for your group, once
> established.
>
> 1. Web page:
>
> a. Meetings:
> [ ] Current meeting info? Is it prominent?
> [ ] Day of the week? Beginning time? Ending time?
> [ ] Double-checked day/date matches against a calendar?
> (E.g., is the "Friday, March 28" you listed an error, because the 28th
> is a Thursday?)
> [ ] Location?
> [ ] Map?
> [ ] Directions (car, public transit)? Parking tips?
> [ ] Information on the next several meetings?
> [ ] RSVP mailto link on meetings where this is needed?
> [ ] Note that meetings are free and open to the public (if they are)?
> [ ] If there's a special fee, is it disclosed next to the event
> listing?
> [ ] If location / time / date formula has changed recently, is this
> noted prominently?
> [ ] Have you checked for event conflicts with other nearby groups, or
> with holidays?
>
> b. General:
> [ ] Includes event date-formulas (e.g., 4th Tuesdays)? Prominently?
> [ ] Maintainer mailto link?
> [ ] Last-revised date?
>
> c. Periodically (maybe every quarter):
> [ ] Checked all links on your site for dead links?
> [ ] Checked your Web server's logs for pages requested but not found?
> (You'll want to put a referral page at that URL.)
> [ ] Read all your Web content attentively for outdated content?
>
> 2. Other, periodical:
> [ ] Reviewed/updated all LUG lists that have entries concerning your
> group?
> [ ] Reviewed all sites that link to yours? Advised their webmasters of
> needed corrections?
>
> Addendum #3: Additional materials.
> * You will certainly want to also read my Linux User Group HOWTO.
> * Paul L. Rogers's Linux Advocacy HOWTO makes a good
> companion-piece.
> * Don Marti's Linuxmanship essay should be required reading for all
> Linux activists.
> * Eric S. Raymond's Conventions at Lightspeed addresses the running
> of larger events by hacker-types.
> * Kenneth R. Kinder's Linux Myth Dispeller is a bit outdated, but
> still good.
> * The redoubtable Christopher B. Browne has similar pages.
>
> [1] ssh is a protocol for encrypted remote login (and inter-system
> file transfer), protecting both your login authentication and the
> subsequent session data against third-party eavesdropping. Despite
> needing supporting software at both ends (server and client), it is
> rapidly replacing telnet, because the latter is horribly insecure and
> a leading means of account theft and system break-in. The best-known
> implementation is also named ssh. Client software is available for
> every consumer OS: See my list at http://linuxmafia.com/ssh/.
>
> [2] gcal, the GNU calendar program, is a simple perpetual calendar
> utility included on typical Linux systems. Typing "gcal" shows the
> current month, while "gcal 2000" shows the twelve months of that year.
> On some systems, it will be named "cal".
> _________________________________________________________________
>
> Copyright (C) 2000-2008 by Rick Moen, rick-at-linuxmafia.com.
> Verbatim copying, distribution, and display of this entire article are
> permitted in any medium, provided this notice is preserved.
> Alternatively, you may create derivative works of any sort for any
> purpose, provided your versions contain no attribution to me, and that
> you assert your own authorship (and not mine) in every practical
> medium.
|
|
