...making Linux just a little more fun!
Last updated Jul 30 2004
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.
(Note that your email address will not be exposed to spambots by LG: just like the addresses on this page, it will not be presented in text form, and thus will not be harvestable.)
Read the rest of this FAQ for topic suggestions and formatting requirements and submit your completed article 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.
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:
We have all levels of readers, from newbies 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.
Articles not specifically about Linux are generally not acceptable, although an article about free/open-source software in general may occasionally be published on a case-by-case basis.
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.
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. (Occasionally we may accept an article about a non-Linux open-source topic.) 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 2-12 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.
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.
Create the file using any plaintext editor. Put a blank line between
paragraphs and begin each paragraph with
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 TitleNote 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 you bio.
<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
<pre>...</pre> around program listings,
output, configuration file text, and anything else which must line up
<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
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.
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. Also note that Word- or FrontPage-generated "HTML" is not acceptable; the hundreds or even thousands of markup tags created in the process are nearly impossible to parse into any semblance of useability. StarOffice/OpenOffice is a bit less virulent in its markup, but still painful; even plain text without any markup is preferable to any of the above HTML-mangling methods.
<p>before paragraphs (
</p>after paragraphs optional).
<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.)
height=attributes in the
<img src="misc/author/file1.jpg" alt="Description of picture" width="140" height="80">If the image is > 600 pixels wide, link to it rather than using an
<img>tag, or reduce it in size. PNG or JPG only, no GIFs.
<p style="width='80%'">). These will mostly be deleted, or overridden by the LG stylesheet.
<dd>are actually what you need.
'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.
"helvetica"(sans serif) and
"courier"(fixed-width). The default is roman (serif).
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:
The code for this example may be found <a href="misc/jones/trip.sh.txt">here</a>.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.
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.