1. How do I become an author for LG?

New authors are always welcome; the Linux Gazette is dependent on Readers Like You for its articles. Although we cannot offer financial compensation (the LG is purely a volunteer effort), you will earn the gratitude of Linuxers all over the world, and possibly an enhanced reputation for yourself and your company as well.

If you haven't written for LG before, the first thing you need to do is send a short bio to (for examples, see our authors list) along with a 200x200 picture of yourself. This bio will be reused for future articles until you submit an updated one.

Read the rest of this FAQ for topic suggestions and formatting requirements and submit your completed article to (Exception: "2-cent Tips", i.e., short bits of technical advice, should be sent to ). If you're unsure about the suitability of the topic to LG, e-mail an abstract of your proposed article to the above address, and we'll happily give you feedback.

2. Acceptance policy

If your piece is essentially a press release or an announcement of a new product or service, trim it down to a URL and a paragraph or two and submit it toas a News Bytes item rather than as an article.

The following types of articles are always welcome:

• Technical articles of a HOWTO nature; how to set up a program, how to maintain it, "my experience running a program even if I'm not an expert", etc. An article discussing how you arrived at a solution by trial and error, and what problems you encountered along the way, will be of interest to many readers. These real-life experiences are one of the unique things that LG can offer, because that's exactly what's missing in most standard documentation.
• Articles demonstrating the use of Linux in an industry or environment where it might not be commonly expected.
• General Open Source issues - philosophical, political, etc.
• Software reviews, as long as it is a balanced review and not simply an advertisement. Comparing the pros and cons of this program with similar programs is a plus.
• Reports from conferences, etc.
• Anecdotes, lighthearted stuff, etc.
• New, creative, Linux-relevant topics - including those not mentioned above - may fit the bill, or may create a category of their own. As we move forward in parallel with the development of Linux itself, our ideas on presentation and content change as well - and your article may well be the agent of that change. Go wild... you never know till you try!
• For even more ideas regarding possible articles, look in the Mailbag for recurring questions. Explicit requests for articles appear at the top of the "Help Wanted -- Article Ideas" section.

We have all levels of readers, from neophytes to gurus. In order to appeal to both, the "howto"-type articles should be centered around an interesting topic or task - even a complex one is fine - but should also contain clear, explicit instructions sufficient to replicate your results. If you see an article that is too technical or not detailed enough for your taste, feel free to submit another article that fills the gaps. Realize, as well, that articles age as time passes; the fact that we've had an article on, e.g., VMWare within the last couple of years should not discourage you from writing one yourself provided that you have new, updated, or different information to convey.

Authors retain the copyright to their articles, but readers are free to copy and distribute the articles as much as they please. Note: We'll happily accept articles previously published elsewhere, as long as the original copyright essentially amounts to the above, and does not prevent the article being re-released under the Open Publication License (OPL). LG's official copyright statement (in short, the OPL without the optional clauses) is at http://linuxgazette.net/copying.html.

Articles should be written in simple HTML, or even plain text; most other formats, including HTML created in FrontPage or MSWord, will be rejected unless they are easily convertable to the two acceptable formats. Please read the LG author's crash course in HTML and the LG author's style guide below.

The following was written in response to an author inquiry:

The article must be about Linux, about programming normally done on a Linux platform, etc. LG has a wide variety of readers, so technical articles, tutorial articles, human-interest stories and humor are all accepted. Rejected are mindless Linux advocacy and Microsoft-bashing that you can find plentifully in the advocacy newsgroups, and articles that appear to badmouth or slander a company unfairly.

The biggest criterion is, "Does the article provide new and interesting information?" An article may overlap a previous article in content, but is it a 100% overlap or is there any new information or a different perspective? We do ask that authors use the LG search engine to look for previous articles about the same topic and link to them if appropriate. This makes it easier for readers to find all the useful information LG has on a certain topic.

There is no specific word limit on article length. Most articles are 5-20 screenfulls of text, but they can be of whatever length necessary.

For their first article or two, new authors are encouraged to send a short summary or outline before writing it to verify that it will be acceptable.

3. Deadlines

The article submission deadline is seven days before the end of the month, unless US holidays interfere (these would move the date back by their own length.)

Since we're not a paper magazine, we don't have a certain amount of space to fill. If you miss a deadline, don't fret; just send your article in anyway and it will go into the following issue.

4. LG's "minimal HTML" guide

Create the file using any plaintext editor. Put a blank line between paragraphs and begin each paragraph with <p>.

An actual HTML document contains headers and footers - i.e.

<html><head><title>...</title></head><body>

at the top and

</body></html>

at the bottom. In a Linux Gazette article, however, these are neither used nor at all useful, and will be removed if sent; instead, the first two lines of the file should be

author: your_last_name
title: Article Title

Note that there's no markup used around these lines: they are simply text, just as you see above. These will be used to generate the article and page title, as well as a link to your bio.

Place <h2>...</h2> around section titles, with a blank line above and below. You may use h3 for subsections, h4 for sub-subsections, etc, on up to h6. h1 is used by LG for the article title.

Place <pre>...</pre> around program listings, output, configuration file text, and anything else which must line up vertically. <pre> goes on its own line above the block, and </pre> on its own line below. Everything inside this block will appear in a monospaced font, and indentations and line breaks will be displayed verbatim.

To display a literal "<" in your article, type < instead. For ">", type >. For "&", type &. Otherwise, the browser will try to interpret them as parts of HTML tags rather than displaying them. Look especially closely at program listings since these symbols are frequently used in shell commands or mathematical expressions.

There are other HTML tags (br, em, strong, ul, ol, dl, img) you may optionally use to jazz up the document; see any HTML tutorial for their syntax and meaning.

5. Style Guide

Keep the HTML as simple as possible. Linux Gazette is read on a wide variety of browsers and hardware, and we try to accomodate as many readers as possible. CSS markup, for example, will always get removed - so don't bother adding it in the first place.

Please bear in mind that the Linux Gazette is distributed as part of several CDROM/DVD collections, and that many people read it off-line; as a result, any off-site links become useless, and pointing to, e.g., sample code on your web site destroys the article's readability and usefulness. There is, however, a limiting factor from the other perspective as well: many of our readers pay for their connections by the kilobyte, and large article attachments, particularly those that are not of broad interest, represent an unfair load on them. Therefore, the LG policy is an attempt at a compromise between the two: if your referenced content does not exceed 250kB total, please include it as part of your article submission; otherwise, please post it somewhere accessible and provide a link.

Good

• <p> before paragraphs (</p> after paragraphs optional).
• Standard markup tags (<a>, <em>, <strong>, <code>, <blockquote>, <ul>, <ol>, <dl>, etc).
• <h2> or <h3> around section headers.
• <pre> around program listings and output. (Please also make a text file of any program listings that are longer than 20 lines or so; see below.)
• Images. Include the alt=, width= and height= attributes in the <img> tag, i.e.

  <img src="misc/author/file1.jpg" alt="Description of picture" width="140" height="80">
  

  If the image is > 600 pixels in width, either shrink it or link it. Use PNGs or JPGs, make the file size as small as possible - and definitely no GIFs!

OK, but don't overuse

• Local style declarations (e.g., <p style="width='80%'">). These will mostly be deleted, or overridden by the LG stylesheet.
• Tables. Use mainly for columns of data; avoid for layout unless it's absolutely necessary. Often, <dt> and <dd> are actually what you need.
• Fonts and colors.

Bad

• Stylesheets.
• Underlining (<u></u>). This makes the text look like a link. Replace with <em>, and all will be fine with the world.
• Decorations and doodads on section headers. Sometimes these are tolerated for variety; other times, they go "poof".
• Extra <br>'s and  's to achieve precise indentation or vertical space. Much of that stuff will be lost anyway when people use a browser that is different from yours.
• Platform-specific fonts. The only words you need are "helvetica" (sans serif) and "courier" (fixed-width). The default is roman (serif).
• Javascript.

Name the article author.html (where "author" is the author's last name in lowercase). If you have images, program listings, or other companion files, place them in a subdirectory misc/[author]/ and have your hyperlinks point there.

If you have long program listings (e.g., longer than 20 lines or so) that do not require a line-by-line description, abstract them into a file called misc/[author]/[program].[language].txt and link to them in your article, thus:

(Get the <a href="misc/jones/trip.sh.txt">code</a> for this example.)

The ".txt" extension ensures the browser will not try to interpret the contents. Since it's a text file rather than HTML, you should not escape the "<", ">" and "&" characters.

6. After Submission

So, you've submitted your article. At the time that you wrote it, it was the most wonderful bit of prose ever released into the wild, flights of fact and fancy unparallelled in history - but now that the end of the month (and actual publication) approaches, you can see... umm, certain improvements that could be made. Not that there's anything wrong with the original, of course, but - a bit of clarification never hurts, right? So, you set out to revise your brilliant treatise and resubmit it...

If this is what you were about to do, STOP! What you'd be doing is creating a fork: a second, divergent version of the material. You see, at this point, the article has probably been proof-read, possibly heavily corrected with regard to the HTML, maybe even had some of the material moved around a bit - and all of this work would have to be re-done if you were to resubmit your original version with corrections. As a result, your "new" submission may well be rejected.

So, what, is correction after submission not possible?

It is - in fact, it's very easy if you follow procedure. That is, simply contact the editor () and say that you want to add/change/correct something. If it's a minor change, just submit a diff (i.e., show what you want changed) and we'll apply it. If the changes are more comprehensive than that, and it's not too close to the publication date ("too close" being a constantly-changing variable; you'll just have to ask and find out), we'll 'freeze' your article and send you the working copy, which you can then correct and send back to us. And don't forget, lest you get into a stew about getting it all done by the deadlines - there's always next month.

A good idea whose time has come

(thanks to Barry O'Donovan for setting a good example)
If you've written an article that mostly concerns or describes a specific piece of software, you may find it of benefit to notify the author of that software. Not only is it a pleasant and courteous thing to do, but they may have a salient comment - and you will have the security of having had your article vetted by the number-one expert. We will usually be happy to post the resulting exchange in the Mailbag section (assuming that you've asked your correspondent for permission to do so and had it granted.)

7. After Publication

What happens if I spot a mistake in my article sometime after publication?

Click on the "Talkback" link for that article, and email us your corrections, citing as much detail and context as possible (i.e., location of the error within the article, additional relevant information, etc.) We will do our best to bring it to our readers' attention by publishing it with the rest of that month's Mailbag.

But can't you correct it at your site?

Yes - but generally, there wouldn't be any point to doing so. Our mirror sites (http://linuxgazette.net/mirrors.html) pull down our _new_ content once a month, when we publish an issue. This means that the old content - including your article with the error in it - is now part of web history, essentially unchangeable. Note that this is not an effect of LG policy but simply an artifact of life on the Net; whatever you say publicly is usually archived - somewhere - forever. The best policy is to accept that as a fact of life and act accordingly.

There is one exception to the above - but it is mostly a goodwill gesture that we are only occasionally willing to make. If your error is going to result in ongoing repercussions - e.g., you have unwittingly insulted the Grand Poobah of Ungah-Bungah, and now every Ungah-Bunghese man, woman, child, and spectral tarsier wants to eat your toes for breakfast - we may change the content at our site just to "show willing", as the expression goes. If this is the case, feel free to write to our notoriously-cynical Editor-in-Chief (ben@linuxgazette.net) - although a letter of apology to the Grand Poobah would probably be a more efficient use of your time.