...making Linux just a little more fun!

December 2003 (#97):


The Mailbag

HELP WANTED : Article Ideas
Submit comments about articles, or articles themselves (after reading our guidelines) to The Editors of Linux Gazette, and technical answers and tips about Linux to The Answer Gang.

James Roberts has agreed to coordinate the Windows Defectors series long requested in this section. His first article appears in this issue. Tom Brown and Petar Marinov have also expressed interest in writing for this series, and Tom's first article is in this issue too.

2-Cent Tips and The Answer Gang columns will be returning next month.

GENERAL MAIL

Clarification to TAG 93 #5

Sun, 16 Nov 2003 23:30:24 -0600 (CST)
Robert

Hi.

Ben came up with the right fix to the "unresolved symbols in /lib/modules/`uname -r`/foo.o" error; however, his reason is flawed.

If the distro kernel uses a module to enable foo and the rebuilt kernel omits foo, or puts it inside the kernel, there is no place for depmod to insert the kernel module and it'll complain about the unresolved symbols. (If the required module is not available, the error will be something like "Device not found". It's been several years since I puzzled this one out, and I don't remember the specific error.) The fix, as Ben said, is to either rename or delete /lib/modules/`uname -r`/ before running "make modules_install". Or build a kernel of a different version, but I don't think that's within the scope of the OP's question.

HTH 

The intended recipient of this message is the readership of the world
wide webzine "Linux Gazette". Any responses or discussion with the Answer
Gang or any LG editor may be published worldwide. Please don't reveal my last
name, email address, or company.  ...This notice supersedes any and all other
attached restrictions.
Thanks!
Thanks so much Robert! What with the October/November confusion as we spin up at our new home, it's continuity like this which keeps us going strong :) Plus, it allows me to sneak in a chance to remind everyone, you can contribute to Linux Gazette even if you're shy. We don't mind at all. -- Heather

[Regarding moving to .net] Thank you!

Sat, 1 Nov 2003 13:33:00 -0800
Rick Moen (the LG Answer Gang)
Question by Jack Townley (jack1953 from att.net)

Thank you for saving the Linux Gazette. What they did to linuxgazette.com sucks!

Thanks for writing, Jack. If you'd like to help us, at this point, getting the word out to people would be much appreciated. For example, submit the story to your favourite Linux news sites.

The staff here all changed our signature blocks to mention its new home, for instance. Note, most of the news sites who care seem to have caught on... so I'd say the next thing is, tell everyone you know who has a link to us to fix 'em to point at the Linux Gazette site they really want. -- Heather

Long Live LinuxGazette!

Mon, 3 Nov 2003 16:41:55 -0800 (PST)
Dave Bechtel (kingneutron from yahoo.com)

--Mad Propz to all of you for getting out from under the Evil Corporate Thumb(TM). :) Best wishes for the future issues, and keep up the good work!

(Thanx for all the great stuff you've done!)

I'm glad he gave us a translation. :) -- Mike
Thanks for a particularly silly sig block, though I do tend to snip them unless one of the Gang commented to 'em. And thanks for joining us at our new location :D -- Heather

Like the Phoenix

Tue, Nov 18, 2003 at 08:00:52AM -0500
Ben Okopnik (the LG Answer Gang)
Question by James A. Hess (jah from ipsg.com)

Ben, et al,

Thank you for continuing and resurrecting the Linux Gazette. I clicked on my old link to LG this morning and was depressed by what I saw. The format is terrible, the "articles" were of dubious quality and my favorite features were missing.

Fortunately, it wasn't too hard to find you again. Keep up the good work.

Thanks, James! We certainly plan on it; being able to create without censorship and interference was one of our main motivations in making this move. Good to see that you and many other folks recognize this move as a positive one; we certainly think it is, and look forward to bringing the best content we can produce to our readers.

Best wishes, Ben Okopnik

CMS

Tue, 25 Nov 2003 07:35:00 -0600 (CST)
Terry Therneau (therneau from mayo.edu)

A small suggestion from someone who has enjoyed your magazine for some time. In the page describing why you have moved to a new domain, not everyone (including me) will know what "CMS" means.

Take the editorial suggestion, or not. Do accept my thanks for your
work in creating the magazine.

PS. I've been using Unix since '79 or so, including scanning most of the source code to V6, installing Berkely 2.1 on a PDP 11/34, and thinking that our new VAX 11/750 was a powerhouse. To me CMS means "Cambridge Monitor System", a terminal based front end to the IBM mainframes, and the only OS I've used on a screen that was worse than using punch cards.

Terry Therneau

Good point. Sometimes we underestimate the variety of backgrounds our readers come from.
CMS means "content management system". Generically it means any systematized workflow for producing and maintaining documents. Every system needs some way for the author to write the document and submit it, and for the editorial staff to approve/deny it, make corrections, set meta-information like the title and bio, publish it, and maintain it after publication. In that sense, Linux Gazette has always had a content management system of some sort or another.
However, in the context of web services, CMS means a certain kind of software for handling the workflow, one that is web based. That's what we mean by "linuxgazette.com has a CMS". Most CMS' in this sense handle at least the editorial steps through the web via HTML forms. Some also expose this interface to the authors for the initial submission. A few also allow editing the article text through the web, although others handle this in the traditional way (the staff puts the file directly in a certain directory without using the web interface). Since many LG articles have images and supplemental files, the interface has to either handle these too, or else get out of the way so the staff can install these manually. Various CMS' include Plone (a Zope system), PHP Nuke (Linux Journal uses a heavily customized version of this), Drupal (used by Linux Ghoulzette, as we affectionately call that other zine -- well, it was Halloween when they unveiled it) :) , Slashcode (used by Slashdot), wikis, blogging tools, etc.
Many people think Linux Gazette left linuxgazette.com because of the CMS, but that's only partially true. For me personally, the CMS was only a minor problem - one that I feared the worst of, but that I was willing to allow a good try. The main reason I left was the lack of editorial oversight, which was significantly affecting the quality of LG content. Nobody at SSC is giving the authors feedback to help them improve their content or to generate article ideas. Many authors had stopped contributing to LG because of this, but indicated they would return to LG if it reverted to its traditional self.
The arguments against a web CMS are that HTML forms are cumbersome and inconvenient, you can't use your existing favorite software tools, it would take a lot of work to graft in the features LG already enjoys, and why fix something that ain't broke. The "lot of work" part can be seen at linuxgazette.com, where they are trying to integrate a text-friendly format (for blind readers), an all-in-one-page format ("TWDT"), better author attribution, a system for managing images, etc -- features we already have had for years. Most off-the-shelf CMS software does not have these features, and grafting them in often requires kludging around the program's design. -- Sluggo

Thanks for the X windows resolution article

Sat, 15 Nov 2003 23:29:53 -0500
Jonathan S. Romero (jo875452 from pegasus.cc.ucf.edu)

Hello,

Thanks for hosting the X windows resolution change article at
http://www.linuxgazette.net/issue52/tag/9.html

I was having problems because a game I was running kept changing the resolution and not setting it back to the original when it was done.

I never imagined it was as easy as CTRL-ALT-+

Thanks,

Jonathan S. Romero

Linux Gazette reborn!

Wed, 5 Nov 2003 16:05:44 +0000 (GMT)
Luca

Thank you. This is great news for me. I don't think there is a Linux place in the web I loved and love more than (the old) Linux Gazette.

You made the right choice.

Thank you, Luca. It is nice to know that there are readers out there that appreciate the efforts that all of us at Linuxgazette.net are putting to good use.

:)

-- Thomas Adam

Play Encoded DVDs in Xine

Sat, 8 Nov 2003 23:54:12 -0800
Thomas Adam

Hey All,

This is going to seem really picky, but this article:

http://linuxgazette.net/issue94/kolp.html

demonstrates some rather poor techniques for compilation. Firstly, LeeAnne suggest that one compiles their programs as 'root' -- ERRM, bad idea. Secondly the use of "-" as a prefix for tar's options is not needed and can even lead to some ambiguity.

Any chance the author can be made aware of this?

It was published by Jeff, and he didn't put her e-mail address on her author page. I don't know whether she asked him not to, or that was his policy, or what. But we don't have her address. Maybe she'll see your message in the Mailbag.

-- Mike Orr (aka. Sluggo)

GAZETTE MATTERS

Technical changes in LG

Sat Dec 6 22:31:44 PST 2003
Sluggo (LG Editor)

As you can see, LG has a new look. Rob Tougher responded to our longstanding request for somebody to make a stylesheet for LG, and it looks great! He also helped me extensively to update the templates and Python scripts that generate LG, to implement the new look.

We've tried hard to make it reasonable for both graphical and text browsers. Let us know if anything blows up or you have any suggestions. The biggest problem we've seen is the menu being vertical instead of horizontal in Netscape 4. If anybody is still using Netscaoe 4.

[logo image]

We have a new logo, in order to get away from SSC-originated artwork and to distinguish our site from theirs. Actually, the "new" logo is a variation of Michael Hammel's "Gandhi" logo, which long-time readers will remember. We're not sure yet whether this logo will be temporary or permanent.

The pale yellow margin was chosen to complement logo color.

The TWDT version has a special style to be more printer-friendly. The left and right yellow margins are eliminated to prevent printers from drawing a toner-wasting large gray rectangle on each side.

Please help get the word out

Sat, 1 Nov 2003 17:15:01 -0800
Rick Moen (the LG Answer Gang)

If you're reading this then you already know that this issue can be found at: http://linuxgazette.net/issue97/

and probably guessed that this note was really written just after 96 released.
Let us know if there are any news sites who don't know about the move by now. You can let them know too, or have us send them a note. -- Heather

The only problem is that most readers are unaware of that, not having heard of the switchover to http://linuxgazette.net . Alternate formats include (aside from TWDT.html) a new PalmDoc version, suitable for reading on PDAs.

Also, if you know sites running Linux Gazette mirrors, please let their admins know. We've contacted the official mirrors, but there are lots we aren't even aware of, who are probably wondering why they aren't getting a November issue. (They need to redirect their mirroring scripts.)

-- Cheers, Rick Moen

At the time this was drafted, Phil Hughes was still swearing off the "monthly Table of Contents" style. Their linuxgazette.com site issued one anyway, thus many automated mirrors actually did get a November issue, albeit a drastically different and underpowered, barely edited, edition. If you see the old content on a site please advise their webmaster of the existence of both sites and our move to linuxgazette.net. If they'd like to come up to date with us, we'll gladly help with mirroring scripts. If they want to mirror both, we're fine with that too... -- Heather

apology (about submission policies)

Mon, 3 Nov 2003 18:27:31 -0800
Heather Stern (Linux Gazette Technical Editor)
Question by Tom Brown (tfbrown from ceinetworks.com)

Sorry for jumping the gun with my previous email. I realist now that sending you an email wasn't the right procedure.

Oh, that's quite alright! The small handful of us who edit LG are used to people sometimes responding directly to articles; I presume my name was made fairly easy to pick up :)

After checking out the guidelines for answering questions, however, I'm still at a loss. Mailing lists? (Don't hit. I told you I was a Linux n00b.).

Ok. Here's how it works. And TIA for the chance to clarify any points in our "FAQ" documents that really do need clearing up; after a while it gets a little more fuzzy, and that make it hard for us to truly look at them from a n00b's perspective. A fresh set of eyes does help.

If you've got a question in the realm of Linux, maybe "The Answer Gang" can answer it. Even if one of them can't alone, they might be able to, ahem, gang up on it.

Even rather new people might have tricks up their sleeve; anyone interested in watching the ebb and flow of questions, and possibly answering a few here and there, is invited to join the "tag" list - effectively becoming a member of The Answer Gang, too. It's all volunteer, so if you can't answer anything, you're welcome not to say much, and just lurk. You might surprise yourself and answer a few anyway. If this happens a lot you'll be offered a chance to raid the TAG fridge for some muchies and your beverage of choice.

We pride ourselves on possibly curmudgeonly and very human replies, because we're real people, not worrying so much about the clean white polish of a paper-white magazine. I have, however, occasionally warned people not to be too mean in their answers as things stray off topic. As I said then, the mantra of the overall magazine is "Maiking Linux Just A Little More Fun!" not "making the Borg kids cry." Various topics are considered bad, like people sending in their homework assignments without even poking around in some URLs and researching in search engines a little. We've tried to provide some help for folks who are about to ask - querents can read our "ask-the-gang" document - but generally we try to have some fun with Linux and get people going so they can have fun here too.

Anyway, my apologies. Tom Brown.

Please, take a look throughout the site, and let us know what you think about any of it that you like. Or especially any parts that confuse and annoy... so we can improve ourselves.

-- Heather

Is LG too strict or not strict enough?

Sun, 2 Nov 2003 21:33:50 -0800
Sluggo (Linux Gazette Editor)

Phil Hughes (the publisher of linuxgazette.com) claims that a main reason for eliminating the Editor was that readers were complaining we were too selective about what we publish, so they either felt they could not be authors or were too intimidated to ask. I was surprised to hear that because I never felt we were heavy-handed, but that's what he says.

For the record, I receive some three hundred articles every year, and publish all but three or four of them. The only ones I've rejected were advertisements disguised as articles, mindless Microsoft bashing (which belongs in comp.os.linux.advocacy), material we've covered extensively before, advocacy pieces that said nothing more than "Linux is good, try it" (you're preaching to the choir), and articles whose English was so bad that readers wouldn't understand significant points.

In every case I try to work with the author. Advertisements I send to News Bytes, or have the marketer get some employee to write a "balanced" article from a user's perspective. If it's an overpublished topic, I ask the author to elaborate on certain portions -- what we're looking for is new information -- or I notice areas in the author's expertise and ask them if they're willing to write an article about that. That's actually one of the fun parts of being an editor: giving article ideas to people based on things they've said. Articles with bad English I either proofread myself, find a translator or proofreader, or ask the author to find a proofreader. In most cases, the article either becomes acceptable or the author writes a different article for us. And sometimes the author goes on to write better articles later and becomes a regular contributor.

In addition, some articles had incorrect technical advice that, if followed, would make newbies shoot themselves in the foot. You don't mess around when talking about boot sectors, backups, security or corrupting data: you make sure that at least those parts are right. In every case I was able to tell the author myself how to fix the article, or sent it to The Answer Gang for technical review, and the article was published.

This all is what goes into the process of "editing", and it seems to be what linuxgazette.com is objecting to in their attempt to have an editorless zine. As of November 2, they added one paragraph to the author FAQ I wrote, saying in part, "There is no editor as such and we're relying on authors to be self-editing.... Additionaly, assume that your article is publishable, at most we'll take a cursory glance at it, spell-checking and grammar are the author's responsibility." (http://linuxgazette.com/faq/author.html, question 1, paragraph 2) My position is the everybody needs a little help sometimes, and it's the editor's job to be that help.

As for reader complaints that we're too strict, I have not heard that even once from readers during my four years editing LG. Instead, in Slashdot comments and in other places, I see the opposite: readers wish we were more selective. Only a very few readers express an opinion either way, but that's the direction of all the opinions I've heard.

If you think LG is too strict -- or not strict enough -- in its article selection, please let us know.

LDP have the other issue 96

Wed, 5 Nov 2003 03:36:45 -0800
Rick Moen (the LG Answer Gang)

Quoting Jimmy O'Regan (jimregan@o2.ie):

See: http://www.tldp.org/LDP/LG/current

I can pretty much guarantee that you're seeing, there, just the operating of an automated mirroring script, pulling down files from the former LG.com site without supervision. It'll get straightened out eventually, with time. Maybe they'll decide to mirror both. ;->

Pity about the name confusion, but with luck the two periodicals will diverge over time (if both persist).

(We at LG.net's staff had no idea the former site would produce more issues: They'd lead us to believe they were moving entirely away from monthly issues, and adopting entirely dynamic CMS-based content. The staff considered that format incompatible with publishing a magazine, and failed to reach agreement on that with Phil Hughes over many months. That was one of the reasons we took Linux Gazette elsewhere -- so it wouldn't cease to exist. Therefore, LG.com's subsequent "issue #96" came as a complete surprise.)

[Heather] I'd like to note for the record that the actual inquiry I first made that led to the hosting we now have, was prompted by wondering whether SSC would continue to host us when none of our staff worked there anymore, NOT anything about stylesheets, layout, or automation. We didn't even know all those months ago who'd press enter on the Python command that sets the ball rolling for release. I just asked and T.R. was kind enough to say whatever we needed to do, he'd support.
When, a couple months later, SSC claimed that changing the site was being looked into so they could reduce personnel involvement - the word "costs" was used several time - I noted that we could reduce their cost to zero by moving away. We asked why fix what isn't broken. The claim was made - and I still haven't seen any real RFC822 messages to support - that readers claimed it was hard to submit. This potential about moving was shushed with "no, of course we'll support LG" and our "technical advice" was solicited for the new plans. Then the evil CMS buzzword was brought up, we debated about it ... um, vigorously. In the spirit of actually having our opinions sought. "Evil" I say because it had come up and either failed even basic marketing or been hoist by its own petard a couple of times before. (See the timeline if you care.)
As it is I regret now (in 20/20 hindsight) taking as long to support a move away as I did. I regret taking the flack that I did when I simply commented - in verbose answergang fashion - on the technical failings that cause "content managed" sites to fail to be magazines by nature. But I don't own a TARDiS. All I can do is move forward.
[Mike Orr, aka Sluggo] Yes, although these aren't the only reasons we switched. Ppl keep on dwelling on monthly issues and CMS, but the latter played only a minor role in my choice to participate, and the former played even less. I came back because:
[Heather] As of release time, the staff of The Linux Documentation Project are discussing what to do about the split project, and which to carry or point to. This really got into discussion mid November, and they probably want consensus; Jimmy O'Regan said they're pretty confused. I can't blame them, since my efforts to support even a college-try at CMS by announcing the preparation and the imbalanced opinions of it among the LG staff far enough ahead to get readership response in either direction were squished too.
[Jimmy O'Regan] To see TDLP thread: send an empty message to discuss-thread.5315@en.tldp.org
[Rick Moen] Web access here: http://lists.tldp.org
You'll want to use the left-side hyperlink on the name of the mailing list, in order to browse instead of search.
[Sluggo] The most ironic thing is, Heather had had the linuxgazette.org domain registered for years. But when Phil promised her early this year that he wouldn't change LG, she let it expire. Then when he did change it and we wanted linuxgazette.org back, it was too late, a cybersquatter had snapped it up. That's why we're linuxgazette.net instead of linuxgazette.org.

Debian

Thu, 13 Nov 2003 11:05:24 +0000
Jimmy O'Regan (the LG Answer Gang)

...the Debian package for issue 96 went up; and it's the "right" issue.

Debian url: http://packages.debian.org/unstable/doc/lg-issue96.html

transition of the ml

Sat, 15 Nov 2003 17:48:14 -0800

I was wondering why my tag accout got so few posts lately, so I looked again and found the new ml.

I hope you noticed mention of the new mailing list on the old one, and my posted suggestion to LQO subscribers that they join us over here.

Wasn't it somehow possible to transfer the old subscribers to the new list?

SSC has all the mailing lists' rosters set to be accessible to the listadmin, only. We've asked Phil Hughes for help in transitioning; he emphatically refused.

And maybe the list subscription page should be a little more prominent, I only found it by chance...

http://linuxgazette.net/tag/ask-the-gang.html definitely needs something near the top. Anywhere else?

-- Cheers, Rick Moen

We're looking into some style improvements; tho not so drastic as going "automatic" about it. Readers, let us know what you want. Better yet, let us know what you need if the site's normal layout gives you trouble. Stuff like this :) -- Heather
This page edited and maintained by the Editors of Linux Gazette
HTML script maintained by Heather Stern of Starshine Technical Services, http://www.starshine.org/

Published in Issue 97 of Linux Gazette, December 2003

News Bytes

By Michael Conry

News Bytes

Contents:

Selected and formatted by Michael Conry

Submitters, send your News Bytes items in PLAIN TEXT format. Other formats may be rejected without reading. You have been warned! A one- or two-paragraph summary plus URL gets you a better announcement than an entire press release. Submit items to bytes@lists.linuxgazette.net

Legislation and More Legislation

Jon Johansen

The Register has reported on Jon Johansen's latest contribution to the controversial arena of digital rights management. He has created an open source software utility that dumps the content of a protected Quicktime encoded music track to a more easily handled format. Some seemed to find these actions upsetting, though most Register readers seemed to be more upset by the antics of the RIAA.

Johansen is likely to remain in the news as his retrial on charges relating to his involvement in the DeCSS code has just begun in Oslo. Though acquitted in a lower court, the case (which began five years ago) has been appealed.

Broadcast Flag

The Register has also reported that the FCC in the US has approved the controversial Broadcast Flag. Though the FCC claims that the measure is necessary to prevent piracy, the Electronic Frontier Foundation contends that the rules will

"[force] manufacturers to remove useful recording features from television products you can buy today"
The archive of EFF documents relating to the Broadcast Flag regulations can be browsed online at http://www.eff.org/IP/Video/HDTV/

It appears that there may be some loopholes in the detail of the regulations relating to export of non-DRM enabled equipment. The full implications of the rules will of course become clearer over time.

Diebold

Two contentious issues: electronic voting and the DMCA, have been at the centre of a recent story regarding the Diebold company. Diebold specialises in ATMs, electronic voting systems and similar products. However, their voting products have not been without their problems, the extent of which was starkly highlighted in emails leaked from the company.

Once the emails started to circulate on the internet, Diebold sought to lock down this embarrassing material by invoking the dreaded DMCA. Happily for the American electorate, the Online Policy Group, backed by the EFF, brought legal action against Diebold and forced the company to back down.

This is an important win, as the integrity of the voting system (and people's ability to verify it) is fundamental to the functioning of any democracy. As Scott Granneman has pointed out, e-voting has had a chequered history, and it is imperative that it be properly exposed to public and expert scrutiny. This is not just an American issue, as electronic voting machines are being installed in countries around the world. Some, such as those in Australia, use open-source software and operating systems, but many (for example the system being deployed in the Republic of Ireland) leave a lot to be desired in terms of transparency and openness.

DMCA

Three DMCA snippets from The Register

Linux Links

Creating your own Knoppix CDs

Basic concepts or real-time operating systems [courtesy LinuxToday].

Design an application for GRID

Hardware for P2P Radio

Knoppix as a system rescue tool

Linux Weekly News reports on the fork of Linux Gazette.

Ian Murdock, rethinking the Linux distribution business model (courtesy LinuxToday)

Tips from veteran Linux programmer Spence Murray

Joe Brockmeier on how to build Debian packages.

At O'Reilly-net Joe Stump has taken readers through start middle and finish of setting up an advanced mail server, configuring delivery, webmail, secure POP3 and IMAP, and spam and virus checking.

News in General

Kernel Exploit

As mentioned below, several Debian project machines were recently compromised by an attacker who took advantage of an exploitable flaw in the 2.4 series of kernels. Though this integer overflow in the brk system call was not initially thought to have serious security implications, now that an exploit is loose in the wild it is very important that sysadmins patch their systems. The problem has been fixed in the 2.4.23 release of the kernel.

Kernel Backdoor Closed Before it Opened

A recent attempt to insert backdoor code into the Linux kernel has been thwarted by the vigilance and openness of the open source development process.

Linux in Libraries

Linux In Libraries (LIL) is an electronic mailing list/user group dedicated to utilizing the Linux operating system in academic, public and special libraries as an alternative affordable solution for public access computing.

Distro News

2-Disk X Window Embedded Linux

2-Disk X window embedded Linux is a tiny net-centric Linux that aims at portable secure remote system usage. It contains many utilities including: X Windows, vncviewer, rdesktop, a Web browser, a file manager, a text editor, a terminal, a window manager, a menu system, a dialog system, X scripting facilities, and many others. It aims to work from 1 or 2 floppy disks in any remote location. The FAQ is particularly good.

ADIOS

NewsForge recently reported on the ADIOS boot CD. It includes some features not so common on boot CDs, such as User Mode Linux and Security Enhanced Linux.

Debian

Debian GNU/Linux has been updated. The new version, Debian GNU/Linux 3.0 (r2), mainly adds security updates to the stable release, along with some corrections of serious bugs.

Several Debian servers were recently compromised by a local kernel exploit. Fortunately, the attacks were noticed and it has been confirmed that the archives were not tampered with. The investigation report makes for interesting reading.

From Debian Weekly News Jonathan Oxer wrote about caching Debian packages in order to save bandwidth when updating or installing multiple Debian machines.

Linux From Scratch

The Linux From Scratch community has announced the release of LFS-5.0. This release features a new method with strong emphasis on building a correct compilation environment and base libraries independent from the host system. Release 5.0 features the Linux kernel version 2.4.22, the GNU C Library (glibc) 2.3.2, the GNU Compiler Collection (gcc) 3.3.1 and a bootloader change from LILO to GRUB, amongst other package upgrades. The book's explanatory texts have also been enhanced, providing an even richer learning experience while you build your own customised, hand-crafted Linux installation.

Mandrake

Mandrake Linux 9.2 ISOs are now available for download, including the new LG CD-ROM fix.

Mandrake has also released MandrakeMove "...a new product based on Mandrake Linux 9.2 that provides a complete personal desktop operating system on a bootable CD".

Red Hat

News that Red Hat will discontinue maintenance and errata support for Red Hat Linux 9 from the end of April 2004. This also marks the end of the Red Hat Linux product line. To some extent, the Fedora Project will carry the torch from now on.

SuSE

It has been announced that Novell is to acquire SuSE Linux. This is an interesting development, to say the least.

Vector

Vector Linux 4.0 review.

Software and Product News

Distcc

Distcc is a distributed C/C++ compiler.

Vorbis

The Ogg Vorbis CODEC project has released new versions for all its tools and software. Libogg 1.1, vorbis-tools 1.0.1, libvorbis 1.0.1 and OggEnc 1.0.1 are included.

QicsTable for Qt

ICS has announced the release of QicsTable, a sophisticated grid/table GUI object. With QicsTable, developers can present large tables of information using a familiar spreadsheet-like user interface paradigm. This makes their applications easier for end users to understand and use. Built on the Qt framework from Trolltech AS, applications written with QicsTable run without changes on Windows, MacOS, Linux, and UNIX based systems. QicsTable is being released under both the GNU Public License (GPL) and a commercial license that includes access to source code.

Apache 2.0.48 Released

The Apache Software Foundation and the Apache HTTP Server Project have announced the eleventh public release of the Apache 2.0 HTTP Server. This version of Apache is principally a bug fix release.

Also recently released is an update to the Apache 1.3 codebase, the new version is denoted 1.3.29.

Linux on FPGA Design and Verification Board

Semiconductor distributor The Memec Group and embedded Linux and eCos consulting firm Mind have collaborated on a port of Linux and RedBoot to Memec's Virtex-II Pro Development Board. The board is used to design and verify applications based on the Xilinx Virtex-II Pro Field Programmable Gate Array (FPGA) family.

Mod_python 3.1.2 Beta

The Apache Software Foundation and The Apache HTTP Server Project are pleased to announce the 3.1.2 Beta release of mod_python.

Some feature highlights:

Also available is the stable version 3.0.4.

EduWave

The Middle East's e-learning platform, EduWave, is to be made available on the Linux platform following a deal between IBM and Jordanian IT company Integrated Technology Group(ITG).

Mick is LG's News Bytes Editor.

[Picture] Originally hailing from Ireland, Michael is currently living in Baden, Switzerland. There he works with ABB Corporate Research as a Marie-Curie fellow, developing software for the simulation and design of electrical power-systems equipment.

Before this, Michael worked as a lecturer in the Department of Mechanical Engineering, University College Dublin; the same institution that awarded him his PhD. The topic of this PhD research was the use of Lamb waves in nondestructive testing. GNU/Linux has been very useful in his past work, and Michael has a strong interest in applying free software solutions to other problems in engineering.

Copyright © 2003, Michael Conry. Released under the Open Publication license unless otherwise noted in the body of the article. Linux Gazette is not produced, sponsored, or endorsed by its prior host, SSC, Inc.

Published in Issue 97 of Linux Gazette, December 2003

Windows Defectors: Why Linux Is Worth Migrating To, Sometimes

By James Roberts

[James has agreed to coordinate the "Windows Defectors" series long requested in the Mailbag. This series is for those new to Linux who come from a Windows background. In spite of the series title, it's not just for those who have stopped using Windows completely. People who still like Windows, use Windows grudgingly, or deal with Linux-Windows integration in LANs will also find the information useful. Unlike LG's other series, this one will be written by multiple authors, since there is such an interest on writing on this subject. The next article in this issue (by Tom Brown) is also a Window Defectors article.

We're considering changing the series title to something less negative (e.g., "Linux For Your Mom", "Leaning Towards Linux", "Windows Immigrants Help Box", "c:\>, Drive-In for Windows Users", "At Liberty Under the Hood", "Linux Incognito" -- all suggested by Petar Marinov), but we're leaving it as "Windows Defectors" initially because that's what it has been known in the Mailbag. -Sluggo.]

"Those who ignore history are doomed to repeat it." -George Santayana

Have you heard that quote before? I expect so - and that's part of the point of the quote. This is the first article in a series aimed at the many people who are interested in Linux, but currently use Windows. It aims to ask, and perhaps answer, questions such as:

What's the context?

All such discussions have a context, and the context I intend here is that of the Small and Medium Enterprise, or SME. I'm not addressing the issues for the single desktop, or for the large multinational corporation. In fact, for both these extremes the issues are arguably simpler: at one end it's just personal choice of platform, at the other the resources are available to implement customised solutions as needed. But it is the SME area that has in the current, somewhat-recessive economic circumstances, consistently been identified by the IT industry as the last largely untapped potential growth area. I'm referring here to small installations of between two and a hundred desktops and servers. This SME area is price-sensitive, hasn't upgraded for years, has no IT management: it's where Linux can make a difference, and it's where I reckon it's hardest for Linux to enter - for reasons that I will describe later. If the problems can be solved here, then Linux will become 'sticky' at this level of the 'ordinary' user.

In this first article I'd like to set the scene, and this is why I started with the Santayana quote. I've noticed that people with a UNIX background often have had little contact with those who have been weaned on DOS - and vice versa. The target business that I'd like us to keep in mind is a small office - say eight or ten users altogether - and if this small office has a history in computing, it will generally have been in DOS and Windows.

So let's review where this typical office is now, and how it got here. It's a long and somewhat sad story, but in the end, you'll maybe see why, once, Windows NT was better for our clients than XENIX/SUN, and why now Linux may be better than NT.

Anti-flame note

Before we start, let me state that I am convinced that GNU/Linux is a masterly piece of work on the whole, and an astonishing achievement. Since it's made by humans however, it's not perfect, and inevitably it's the imperfections that I'll have to emphasise. The alternative options are also imperfect, that's why we're looking at Linux. But in some areas the alternatives may have strengths that GNU/Linux lacks. Please take the comments in the appropriate light. I also have to say that all trademarks are acknowledged.

Blast from Past

I'd like us to think back ten years or so - at which time (by mere coincidence) I'd just joined a small UK SME VAR as hardware tech. Within about ten days of starting I'd been bumped up into a systems and end-user support role as well. The VAR was then primarily a Novell reseller and customiser, and I quickly got to know the advantages and disadvantages of Novell 3.1. At that time most of the clients were solicitors (lawyers), and their systems typically were running a Novell server on a i386 or i486 with SCSI drives, with up to twenty-five diskless net-booted i386 workstations, running WordPerfect.

Overall the server/diskless workstation was a very good fit for the clients' needs; it was reliable, fast (the 10 Mbps network was faster than contemporary IDE drives) and easy to maintain (all the configuration files were in one place).

It was also abstruse, non-intuitive (indeed, counter-intuitive at times) and completely non-user-friendly. Any minor configuration error was often fatal. But it did work, and did the job well.

Enter the Band-wagon

Then Windows for Workgroups came along. We could put a network of twenty-five peer-to-peer workstations into a site for much less than we could do a Novell installation. Not only that, all the hardware was readily available and used standard parts (the diskless workstations needed specific types of PSU and weren't easily upgradeable). Moreover, with the Windows system, the clients had the illusion of a familiar system - most of the decision-makers who wanted to introduce networked systems already had Windows boxes at home. Also the clients could install their own extra software packages without invoking our aid (and paying for it).

Pretty soon we were installing a lot more Windows for Workgroups than Novell. Of course, it didn't take long for the downside to be apparent - no central installation of applications, no central control of rights, no user controls whatsoever, big problems with workstation backup, insecure peer-to-peer networking. So our recommended system included a Novell server, which solved some (but not all) of these problems.

Then Windows NT came out - and it was cheaper than Novell, both for the server and for the client access licences. And for the client, again it gave the illusion of familiarity - it looked like Windows. And for me, it came from the architect of Digital VMS - it was written by someone who did know what they were doing.

Meanwhile, Novell had changed their OS completely to version 4, which no one I knew found easy to use. They had introduced large-scale management tools, which merely muddied the waters for our typical installs of 5 to 10 clients, and it cost more than version 3.x.

Pretty soon we were selling networks made up of Windows for Workgroups workstations with a Windows NT 3.51 server, for a much lower overall cost than the previous Novell-plus-diskless workstations solution, and with pretty reasonable reliability and performance. Of course, building all the workstations took time, so I developed a custom cloning system that could build ten identical workstations in about fifteen minutes each.

Nixing XENIX

By then (and we are getting to 1995 or so), we had become pretty well-known and had a good reputation for looking after clients, so more than one solicitor came to us to replace their 286/386 XENIX-based system, which was by then getting pretty long in the tooth (like me now!). I never installed any RS232 terminals, but I removed a lot. They'd done a good job for their owners, but the replacement - with Windows 95 on the desktop and Windows NT 3.51 on the server - was like jumping forward a whole epoch, compared with the 9600 baud green-screen serial terminals in previous use. Was Windows actually as reliable? Well, yes, given the age of the systems being replaced, it was in fact more reliable.

So things went on, and as they went on the problems of this Windows computing paradigm - which had always been apparent in contrast to the Novell/diskless paradigm - became more and more cogent.

Windows 95 was effective - it's a masterpiece of forward and backward compatibility in my view - but it was not stable. It crashed easily. It was not secure. It was big, and the interactions within the systems were unpredictable. Add third-party software (and a different mix of such software on every box) and problems would arise that no-one reliably could solve. We got used to reformatting and reinstalling.

Windows 98 was better, and more reliable, but much bigger again, for no very good reason. It still crashed unpredictably, and took even longer to fault-find or reinstall. Windows NT server was pretty darn stable (after a few service packs), and so we all looked forward to Windows NT 4 coming in 1996, with the back-end stability of NT and the new interface of 98.

I adopted NT4 workstation as my personal desktop as soon as it was released, but I had to dual-boot with 98 because NT4 did not run games well - and I like games. However, NT workstation was too expensive to sell into our clients in general, so our standard install was Windows 98 on the desktop and Windows NT 4 server on the back end, and this worked pretty well.

Setting Sun

In 1996/7 we sold this system into various sites that were running Sun Solaris/SPARC. It was interesting how this came about. Why ever would someone using Sun SPARC workstations want Windows? Well, for freedom, odd as this may seem given the current context.

At the particular sites in question, 'the Sun' was under the exclusive control of 'The System Administrator' - who would install only what they wanted to install, after triplicate written requests, passed back up to company HQ and triple signed off by company IT. Maybe. Meanwhile the workers and researchers, who just wanted to get things done, were bringing in their own Windows machines and running SPSS or MathCAD or some custom sample analysis software on them just to get the work done, and meanwhile the new spectrometers in the lab came with Windows-based software that had to be copied BY HAND to the UNIX system! Yes, Windows and Windows networking at that time actually represented more 'Freedom' for these people, and eventually the lab Sun systems were retired and sold off.

Do I feel shame? No! I remember two issues. One was concerning a video lead for a monitor. The video lead - which if I remember correctly was standard apart from the blanking off of one pin - was $150, about, from Sun. I could source the same lead (apart from the blanked hole) for $7. And the price of a network card? Don't ask. Meanwhile, it took twenty minutes to link the lab pc talking to the machinery into the network - something that had been on request for a year. Any company that exploits a monopoly in this way develops users who detest it. Yes, any company.

Back in the future

So we get up to 1999 and Windows 2000 Pro. Windows 2000 is as good as Windows has got. It was pretty solid, pretty easy to use, fast, adequately tuned, and a good desktop system. But Windows 2000 Pro had a deliberately broken networking model, presumably to force a contrast with Windows 2000 server. Windows 2000 Workstation would only handle ten clients; this was reminiscent of the Intel tricks with the 486 series. The Outlook mail/groupware client was also broken, in that core functionality had been moved to Exchange server, and as far as I could see for one reason only: to make clients buy Exchange server. I didn't like this. But Windows 2K was still a good bet for our clients, although it was getting really overblown in size and slower and slower every issue.

The Plague years

Then the viruses started to really hit.

Then Windows XP came out.

We don't sell XP, if we can help it.

We have a few problems with it. We don't like the licence (it's a potential problem for most solicitors/lawyers and anyone else with a duty of confidentiality), we don't like the desktop (it's an insult), we don't like the vulnerabilities, or the slow performance, or the sheer undocumented mass of it all. But that's not the real problem. The real problem we have is that soon we won't be able to get Windows 2000 any more.

There's a problem in another area too. Many of our clients are running Windows NT 4 server. It's very solid. It works. It does the job. But there will soon be no more security updates or support for this version, and we will have to migrate clients to something else. Windows 2000 server, 2000 AS or especially Windows Server 2003 are a ridiculous overkill for an office with six client machines, as well as being much more expensive and needing huge hardware resources to run. So what else can we install to replace NT4?

Enter the Penguin

Now, back in 1993 I had ran into Slackware, presented as a cover disk with Personal Computer World UK. I installed it and played with it, but it didn't do anything I needed. Nonetheless, I kept an eye on GNU/Linux and installed most builds of Slack, then Red Hat. We bought in a pre-configured GNU/Linux Slackware box in about 1996 to run as our mail server, initially on dial-up and then ISDN, and over 5 years it never crashed. The PSU failed one day, and I managed to migrate the system to a different box and a bigger hard drive and get it all working again (I never was sure how). Many people say that Windows is unstable. With the NT series and all relevant patches on supported hardware - I just don't think that's true. I've had Win NT 4 boxes stay up for years. But that GNU/Linux could so easily match or exceed this performance impressed me.

Moreover, GNU/Linux has over the last few years transformed its graphical desktop capacity. Not only are there lots of interestingly geeky X-desktops available, but two mainstream competitors for Windows 2k/XP, with generally enhanced capabilities.

Two years ago, with the launch of XP and the developments in Samba, I decided to seriously evaluate the potential of Linux for replacing Windows NT 4 on the backend with a GNU/Linux box running Samba. I installed every mainstream distro I could get, on every box I could test it on. I played with it, broke it, fixed it (sometimes) and did my sums. Then we put some test boxes into clients, mostly as mail servers/file servers with AV integrated, and they have on the whole been working flawlessly ever since.

But all is not sweetness and light. There are some problems to overcome in retro-fitting GNU/Linux into a Windows network, and now I've given the history I've just laid out, I hope you'll see them a little differently.

Next month I'll start discussing what sorts of problems we've encountered and how we've tried to work with them.

[BIO] James is the coordinator of LG's "Windows Defectors" series.

Copyright © 2003, James Roberts. Released under the Open Publication license unless otherwise noted in the body of the article. Linux Gazette is not produced, sponsored, or endorsed by its prior host, SSC, Inc.

Published in Issue 97 of Linux Gazette, December 2003

Windows Defectors: I Don't Think We're In Redmond Anymore, Toto

By Tom Brown

Before I begin, I want to warn you. I'm a very opinionated person. I expect things to work well. I expect computers to work my way, not the other way 'round. When I get new software, I expect to be able to put the manual in a drawer, then use the software's basic functionality with few hassles. I'm also a control freak, which is why I like C/C++ over something like Visual Basic. Ease of use gets you only so far. As I said, I expect things to work well, which is why I decided to give Linux a try.

I've programmed on a lot of different operating systems in the last 20 years, starting with the venerable Commodore 64 in the early 80's. In that time, I've discovered that, despite the venting of various zealots, each operating system has its appropriate place in the digital universe. Amigas focused on multimedia (TV shows like Babylon 5 and Seaquest used it to generate 3d scenes), Macs focus on the printed page (most ad agencies and print shops depend on it), and Windows focuses on taking over the world (sorry, cheap shot). Diversity is a good thing.

My introduction (!) to the world of Unix came quite a while ago, when my boss gave me a month to benchmark the same database on SCO, HP/UX, and Solaris (sort of a "let's see if he can breathe underwater" exercise). I liked the flexibility and stability of Unix, but wondered what joker came up with the cryptic commands (ls to read a directory? Rename a file by moving it? Huh?). My favorite was the somewhat recursive SCO user manual of the time, where you had to know what a command did before you could look it up to see what it did.

It wasn't until Mandrake 8.2 came along that I seriously considered using Linux. Having experienced Unix through remote terminal connections, I didn't expect too many surprises. Ha! I'd like to share with you my introduction to Linux from my own rather unique perspective.

Off to see the Wizard

The target machine for the installation was a 2.53GHZ Pentium 4, with 512MB of memory, two 80GB IDE hard drives set in a Raid 0 configuration (which means that a file is written by sending sectors to alternating drives, giving you faster reads and writes) using a Promise Raid controller built into the Intel motherboard, and a standard 60GB IDE drive. I wanted to put Linux on the Raid drive, but ran into my first problem. The installer didn't recognize the Promise controller. Instead, it saw the two Raid drives as separate volumes. That's where I had my XP installation at the time, so I absolutely wasn't going to risk mucking it up. I decided to use the non-Raid IDE drive for Linux.

The voice of experience: Before you start a Linux installation, have a list ready of the hardware in your machine, including brand names and model numbers. If you already have Windows on the machine, this info is easy to get. Mandrake is pretty good these days auto-detecting hardware, but there's always that one last bit it fails to identify. If the installer doesn't recognize your monitor, you may have to enter its max resolution by hand, so keep the monitor manual handy.

Mandrake, as with the latest Red Hat distro, supplies a wizard to walk you through the installation process. Once you know where you want to put things, it's smooth sailing. You can use the installer to partition your hard drive, but I recommend having a copy of Partition Magic handy to divvy the drive up beforehand. That lets you resize an existing partition without wiping out existing data. It comes in handy if you need to tweak things later.

Another tip: Don't accept the default installation packages. Make sure you have enough disk space, and install everything. It's easier to do it now than later. If you think you'll never need the programming packages and kernel source, for example, you'd be surprised!

Many how-to books give you a simple method to boot a Linux partition from Windows, and this generally works.

Except in my case. Booting Windows with the Raid volume as the first drive meant that the Linux partition was on the second drive. But when Linux was installed, it thought it was on the first drive. It was trying to boot "hdb1" as "hda1". Hmmm. You can't get there from here. Of course, since Linux didn't recognize my Raid controller, it couldn't boot Windows. It seems you can't get here from there, either. I ended up setting Linux to boot Windows using an invalid drive spec. This fails, of course, but when it does, you simply hit a key, and Windows starts up. Say what? This only works if you have only one regular IDE drive. If you have a second, the boot-up fails, because it tries to boot the second IDE drive instead of the Raid volume. The real solution, of course, is to move Windows off the Raid volume. I think I'll leave that to my yearly Windows reinstall (What? You don't reinstall Windows every year? Didn't you get Bill's memo?).

If I Only Had a Brain

Sometimes, I can be really stupid. I can't leave well enough alone. A few weeks after the successful install, with everything working fine, I decided to upgrade the computer's memory from 512MB to 1GB. I burn some home movies to DVD, and keep my CD audio collection on the computer, so the extra memory would come in handy.

Only, Mandrake won't boot with the extra 512MB! The scroll lock and caps lock LED's on the keyboard started flashing, but nothing appeared on the screen. For those of you in the Windows world, this flashing indicates what is called a "kernel panic". This is just what it sounds like. The Linux kernel (the core logic of the OS) gets to a point where it doesn't know what to do next, and it freaks out. One web site suggested I reduce the amount of memory used by Linux. It worked, for Mandrake 8.2. But not, as it turned out later, when I upgraded to Mandrake 9.0!

You know that part in the Wizard of Oz, where Dorothy starts down the Yellow Brick Road, and it's going in tiny circles? That was me. As much as I really wanted to use Mandrake, I wasn't about to give up on the extra memory. So, I wiped Mandrake from the computer, and started all over with Red Hat 8. Other than a different look to the wizard, it was Deja Vu All Over Again. Same Pew, Different Church. You get the picture. Red Hat installed easily, and it was finally time to get to know Linux. I promised myself I wouldn't change anything else (for a while).

There's No Place Like /home

In Windows, each user has an entry in the Documents and Settings directory on the "C" drive. The Linux equivalent is the user's "home" directory, which bears the user's login name, and is located in the path "/home" (reminder: Linux separates directories with a slash, not a backslash as in Windows and DOS). Everything in there defaults to being private to that particular user. A user can structure their "home" directory any way they want, and their changes don't affect anyone else. Once you leave "/home", however, Linux directories can be confusing to a Windows user.

Here's a short list of the important Linux directories, and what goes in them:

/home: This contains all the user directories in the system, except for root.

/root: This is root's home directory. Never login as root (the Linux equivalent of the Administrator in Windows)! Always login as yourself and use the "su" command to give yourself root privileges for specific commands. The reason is that programs and scripts can do a lot of damage when run as root. The damage can be due to a hostile program, or just your own (ahem!) stupidity (been there, done that, got the t-shirt).

/bin: Programs and scripts essential to boot and/or repair the system. Some of these are used by other programs.

/sbin: Programs and scripts used by system itself, and by users to administer the system.

/boot: Programs and scripts used to start Linux.

/etc: Configuration files. You may well find yourself editing some of these, but do be careful, and backup the file before you make a mess of it (voice of experience #2).

/lib: Routines that are shared between programs. Sort of like DLL's (I hear some choking from the Answer Gang at that analogy).

/tmp: A place to store temporary files.

/usr: This directory contains contains all programs (/usr/bin) and libraries (/usr/lib) that aren't essential for the system to boot and undergo emergency repairs. /usr takes up 90% of the disk space on many systems, so many sysadmins keep it on a separate read-only partition. Any information that is host-specific or varies with time is stored elsewhere.

/var: Contains variable data files. For example, you'll find logs here. This directory allows /usr to be read-only, since anything that is written to during system operation is in /var.

/opt: This directory is reserved for the installation of add-on application software. For example, Oracle uses this to contain its binaries, and the files they use. This directory is a standard used on some Unix systems. Its use on Linux systems has been controversial.

There are in addition, directories that only look like directories. They are special, and have a specific purpose:

/dev: Each "file" inside this directory represents a hardware device on the computer.

/mnt: This directory (or one of its its subdirectories) is conventionally used as a location to mount temporary filesystems like floppies. Once mounted, the floppy's contents appear to be physically located in the path "/mnt/floppy". Think of it as assigning a drive letter to a network drive in Windows. However, other Linux distributions mount floppies onto /floppy instead.

/proc: The "files" that appear in this directory aren't really files at all, but represent the programs currently running, information from the Linux kernel. You can write to certain "files" to modify the kernel's behavior, but the changes last only until reboot.

Additional information on these directories can be found by referencing the Filesystem Heirarchy Standard.

Pay No Attention to the Man Behind the Curtain

One of the biggest concerns I had moving from Windows to Linux is support for the various devices in the machine. You're more likely to find hardware supported on an older machine than one that's state of the art. A good example of that is my Promise Raid controller. I can work around it by using another drive, but it means I'll continue to use Windows to access that 160GB of space.

Another example is my nVidia graphics card. I have a Gforce 4 ti4200, and only relatively recently has nVidia supplied a driver for it. Now, if you're used to the nice way Windows installs device drivers, you're in for a real "treat". The installation of the driver (in Red Hat 9, my current flavor of Linux) was as follows:

1. Reboot Linux in command-line mode (not in GUI mode).

2. Run the nVidia installer. If the kernel isn't one it expects, it builds one for you (remember, I warned you to have programmer tools and kernel source installed).

3. Make config file changes, per the instructions that came with the installer.

4. Reboot Linux into GUI mode.

Now, if you update the kernel, you need to do this all over again, so the nVidia installer can re-build the kernel. Not exactly as simple as running "setup.exe", is it? Personally, I think it should be that easy, but that's an argument for another time.

That having been said, most of my hardware was recognized and used properly. I can burn CD's on my DVD burner. I can watch home movies on DVD. My Creative sound card works well (it didn't work at all in earlier versions of Linux). The latest version of Red Hat (version 9) works even better on my laptop than it does on my desktop, because the laptop is slightly older (a Compaq Presario 1800T).

DVD Note: If you want to play movies (the kind from Hollywood) in Linux, you need a library of routines that can defeat the DVD copy protection. Yes, this is illegal, and a violation of the DMCA. I use Windows to play DVD's for now. Not wanting the MPAA to knock on my door, I can't identify the software needed to play them in Linux, but you can probably google for it. You may have to learn Norwegian, though.

Flying Monkeys

Another concern I had with moving to Linux is losing familiar applications. While Red Hat comes with a version of Open Office, I was tempted by Ximian, which promised better integration, through a customized Open Office, and other additions. I was particularly interested in Ximian's implementation of a "Network Neighborhood", which used an Open Source program called Samba to access shared Windows directories from Linux. While Samba can be installed separately, you have to configure it yourself. Ximian claimed to do it for you.

Ximian installs from the web, rather than downloading a tarball or a zip file. This can be a problem if you're installing to a machine that doesn't have a fast Internet connection. (I wouldn't suggest you do this over a dialup connection). It installed to my laptop easily, and works as advertised. Its implementation of "Network Neighborhood" was nice. It saw all printers and shared directories on my home network, without any tweaks or configuration. Sweet.

Well, now that you're suitably impressed, I'll disillusion you.

The problem came when I next used the Red Hat Network up2date program (sort of like Windows Update) to apply the latest patches. No go. It seems that Ximian replaces parts of the OS with its own customized bits, causing dependency errors during the update process. As a result, I could no longer apply all the patches. I couldn't even add some packages from the install CD because of this (I said this before: install everything).

I hope Ximian solves the conflict problem, because I'd really like to use it.

And Your Little Dog, Too

As with anything else, Linux has its annoyances. At least, from a Windows perspective.

Both Red Hat and Ximian default to using the Gnome desktop, but I prefer using the KDE desktop. KDE is an optional install, another reason to just install everything the first time around.

RPM package dependencies. This is more than annoying if you haven't a clue how to fix it. You just want something installed. If the computer knows what's wrong, it should just fix it, or tell you clearly what's missing. Tip: Run "rpm" from the command line instead of double-clicking on the package icon, using the verbose option to see what went wrong.

Another annoyance involves modems. Most of them these days are what's called "winmodems", which mean they depend on Windows to work. They're useless in Linux, and ones that do work aren't always easy to find.

At the risk of offending everybody, vi. It's the most commonly used text editor in both Unix and Linux, and was originally designed to be used over a slow modem connection on an 80-character-by-25-row screen. How slow? Try 300 baud. Today there are lots of alternatives, such as Emacs (in both command line and X-Windows versions), as well as various programming IDE's that do syntax highlighting, but if all you're doing is editing config files now and then, these may be overkill. If what you really want is something like Notepad, then you have a choice of using Kedit (KDE desktop) or Gedit (Gnome desktop). Voice of experience #3: Keep a printed copy of the vi command keys somewhere handy. You'll need it when you have to edit a config file or shell script and X-Windows isn't running (or won't run because you accidently trashed it). Don't say I didn't warn you.

The installation of programs and device drivers is an unholy pain in the boot sector. Some vendors, such as Borland with their Kylix and J Builder tools, make program installation a whole lot easier, but even they have some room for improvement. And I've already said my two cents worth about installing device drivers.

Disk partitions don't always automount. Mandrake scans your drives, and sets up icons for any FAT partitions it finds, but in Red Hat, you have to crack open the manual and do it yourself. It's not hard, but it's a pain. Reading the manual, after all, is the option of last resort.

You can't just eject the CD-ROM as you do in Windows. You have to unmount it first. I know it's just a mouse click (or a CLI command) away, but, hey, I'm lazy!

Help is a little too scattered for my taste. You have two places to find manual pages, as well as separate GUI help files. I'd like to have everything available and cross-referenced in one place, preferably available from the GUI. Some systems have a command "xman", which is a GUI version of the "man" command, but I haven't seen it in Red Hat. On the plus side of Linux, there is a ton of HOWTO guides out there, covering a wealth of topics, so I guess it balances.

The Open and Save dialog box isn't as elegant as the one in Windows, and is a bit jarring if you go back and forth between operating systems as I do. Rather a small nit to pick, but there you go.

Ding-Dong the Witch is Dead

Linux has some outstanding positives going for it. Here are favorites from my rather twisted point of view (your mileage may vary):

In my opinion, Linux in general, and the KDE desktop in particular, has one of the best, most flexible GUI environments around. Sometimes, I wish I could replace the Windows desktop with KDE. Then again, sometimes I wish Windows itself was just a shell on top of Linux (dream on, fool).

Another great feature of Linux is the ability to copy-and-paste almost anywhere using the 3rd mouse button. Just highlight the source text, and click the middle mouse button to paste into the current cursor position. Simple, and oh-so-elegant. This is the sort of job one does repeatedly, and with Linux I don't have to remove my hand from the mouse to do so. This must sound strange to most Linux folk, who hate taking their hand from the keyboard to use the mouse. So, I'm a little strange. Be nice, I've been a prisoner of Windows.

The security available for files is so much better than in Windows. Linux gives you a much finer control over what you can do with a file. For one thing, consider that a Linux file needs execute permission before it can be run. Windows, on the other hand, will let you run just about anything. Once you get used to it, you'll want this level of security in Windows, too (but you can't have it: nah..nah...nah..nah..nah).

Command Line Interfaces can color-code the directory listings (and the "dir" command works without having to create a shell alias or shell script for it), which is a feature I had in my DOS days using a program called 4DOS.

Any command that needs "root" (think of it as the Windows "administrator") privileges to work will prompt for the root password before it proceeds. Good grief, Toto, does this mean that administrative jobs can't be run behind my back from my login id? I had always known that both Unix and Linux had better security options than Windows, but this is great. In Windows, I had to give myself Administrator privileges, or log in as Administrator, to perform certain tasks. In Linux, I can be an ordinary user, and still have the power to get things done.

Linux also has a powerful alternative to the "fast user switch" in XP for logging in as root.. It's called the "su" command. Type it into a command line by itself, and it prompts you for the root password. From that point on, only that command line, and the programs it starts, are run with root privileges. The rest of your screen stays as you.

Yes, their commands are strange, and a bit cryptic, but shell scripts in Linux make DOS batch files look like something out of the early 80's (oh, wait...). A shell script is something like a batch file, but with enough power to replace most "C" programs in daily use. There are two main flavors of shells: cshell and bash. Of the two, bash is more commonly used in Linux. Microsoft is going to add a new command line interface to its Longhorn release, and it sounds a lot like a Linux shell (probably proprietary and incompatible, of course). That should give you a hint how powerful Shells and Shell Scripting are.

Mozilla! Goodbye Internet Explorer! Goodbye Outlook and Outlook Express! I've been using Mozilla Firebird for my browsing, and Mozilla Thunderbird for email for a while now, and have begun using both in Windows as well. Thunderbird does a wonderful job killing spam.

Open Office 1.1! Everything I normally do in Microsoft Office I can do here, including save documents in MS formats. I use this too in both Linux and Windows.

The Gimp! I had no need of an expensive graphics editor, just to clean up pictures from my digital camera, but I needed something better than MS Paint. I tried Gimp simply because it was free (yes, I admit to being a cheapskate), but was shocked to discover how good this program is. It's not quite as easy to use as MS Paint (that's because MS Paint doesn't do a whole lot), but when you need something that's more powerful, you've gotta check it out. Now, I do have a nit or two to pick with the program (like, give me the option to put all those separate windows on a MDI form, so I can find everything), but on the whole, this is the image editor I use in both Linux and Windows. I may even read the manual for once!

I could go on, but you can see the trend here. If a program is so good it gets me to use it in both Linux and Windows, you start wondering why use Windows at all. In fact, I use Windows mostly for gaming these days, and little else.

I may just throw away my ruby slippers, Toto. Linux has a ways to go to satisfy Mr. Picky here, but I think I'm already home.

[BIO] Tom has been a software developer since the early days of the Commodore 64, with such commercial classics as Prototerm-64 and Colorez-128, and has seen lots of operating systems come and go. Every one he's liked is either discontinued (OS/2) or out of business (Commodore Amiga). He currently likes Red Hat Linux, which won't be supported after April '04. As a result, we've been trying to get him to fall in love with Windows, but so far no luck.

Copyright © 2003, Tom Brown. Released under the Open Publication license unless otherwise noted in the body of the article. Linux Gazette is not produced, sponsored, or endorsed by its prior host, SSC, Inc.

Published in Issue 97 of Linux Gazette, December 2003

Recent Events, and Trademark Actions by SSC, Inc.

By Rick Moen

Casting our minds back to early on October 28, 2003: The entire Linux Gazette staff (unanimously) decided to take the magazine to new hosting for the first time since time-strapped founder John M. Fisk gratefully turned over guardianship of the publication to SSC, Inc. and publisher Phil Hughes in 1996.

There were a number of reasons for this; one of the two biggest was SSC's covert deletion of material (including entire articles) from back issues, and, repeatedly, totally ignoring our questions about those removals, after we found out. We tried one last time on October 26: After 48 hours of no SSC reply to those inquiries, we decided upon departure.

So, early that Tuesday the 28th, we wrote a very polite letter to Hughes, thanking him for seven years of assistance and asking his assistance in our transition. We also asked him to fix SSC's (assumed inadvertant) violation of past authors' copyrights in its recent republications of old articles. As of December, those violations are still ongoing, e.g., replacement of the authors' copyright notices with SSC corporate copyright notices (falsely claiming them to be SSC property) on these two articles:

http://www.linuxgazette.com/node/view/58
http://www.linuxgazette.com/node/view/61

Our October 28 letter notifying Mr. Hughes of the staff's departure can be read here, and is recommended:

http://lwn.net/Articles/57161/

The above was approximately the state of affairs when we went to press for the November (#96) issue, as reflected in that issue's Brief History of Linux Gazette article. This article aims to update LG readers on developments since then.

The first and most crucial involves the other chief reason Linux Gazette left its longtime home at SSC: Mr. Hughes and his webmaster had been consistently giving us staffers the very clear message that they intended to change LG to have only dynamic Web content, with no more monthly issues and no editors. In effect, there would be no magazine, and the http://www.linuxgazette.com/ site was slated to become another Slashdot-style news/discussion site.

In essence, this would have meant the end of Linux Gazette in all meaningful senses. LG was already starting to erode since the summer, because several authors had stopped contributing articles in protest over the editor's elimination, and the quality of the remaining articles was going significantly downhill. The staff's options were thus to either let this continue to happen, or to move the magazine.

Many have commented that they felt SSC has a moral right to run the Gazette, because of founding editor John Fisk's 1996 hand-off to Mr. Hughes and his company. However, on October 28, the question we faced was not whether SSC had the right to run it, but rather whether it had the right to kill it, over the staff's objections.

The foregoing is an important point to realise, because the situation was then changed on us a second time, immediately after the November issue went to press: After we announced on October 28 that the magazine would be continuing elsewhere, SSC apparently reversed policy and decided to resume publishing magazine issues — using uncredited paid SSC employees to assemble material. We knew nothing of this until we noticed the unheralded, surprise appearance of a second Linux Gazette magazine (at linuxgazette.com).

Accordingly, although the staff regret the confusion resulting from this situation, it was not our idea, and it resulted from a sudden SSC policy change outside our knowledge or control. We're doing everything we can to alleviate the confusion. We also note that even though SSC has reinstated monthly editions, they have not said one word about reinstating an editor.

We are likewise doing everything we can to avoid conflict with SSC in this matter, and to discourage intemperate actions and commentary. Unfortunately, this attitude has not been reciprocated:

1. The very same day it received our notice of the magazine's departure, SSC, Inc. suddenly filed a US $300 fee and trademark application #78319880 with the USA Patent and Trademark Office (USPTO), requesting registration of the name "Linux Gazette" as a service mark (explained below). On that form, SSC certified that it had used the mark in commerce starting August 1, 1996.

2. SSC retroactively started adding the symbol "TM" to its instances of our magazine name on its site. "TM" is an unregulated symbol used to assert existence of a commercial brand identity for goods offered for sale. The same concept applied to commercial services is technically called a service mark, and can be publicly asserted with an "SM" symbol (not "TM").

3. On December 3, 2003, we received a letter from Phil Hughes at SSC, Cc'd to our DNS domain registrar, claiming "Linux Gazette" is an SSC trademark and that our possession and use of the linuxgazette.net domain violates SSC's commercial rights. SSC's main intent appears to be seizure of our domain name via invocation of ICANN's Uniform Domain-Name Dispute-Resolution Policy (UDRP), without any need to prove their entitlement in court.

Our attempt to assess and respond to this attack on our Internet presence — sprung on us right at our publication deadline — is part of the reason for this issue being delayed, for which we apologise. (The other reason was our desire to change the logo and layout, and this required updating several templates and scripts.)

Here is is a brief explanation of the relevant portion of trademark law. (I'm not an attorney, so people needing to make business decisions should consult appropriate legal experts, rather than my analysis.)

Trademark law, in essence, recognises your stake in any commercial "brand" you establish in the market. Contrary to popular misconception, you as a trademark owner cannot prevent others from using your brand identity in the general sense — but you are entitled to stop others from offering competing commerical goods or services (within the same trade or industry) using your brand to mislead your customers into thinking you produced or endorsed them.

For example, in hanging out my shingle as "Viking Network Consulting[SM]", I'd be establishing a brand identity within my profession: In legal terms, my firm's name would be recognised as a service mark. I would thus be entitled to bring civil suit to suppress sales of "Viking Firewall Installation" services by competitors, on grounds of likelihood of my customers thinking I'd produced or endorsed those.

Notice that the reach of a trade or service mark, if valid and legitimately owned by you, extends solely to (1) uses by others in commerce, (2) within your trade or industry, and (3) in the same geographical area. I would not be able to enjoin a different Viking Network Consulting from operating in Trondheim, nor Viking Senior Computer Volunteers from giving non-profit help to retirees.

Broader geographical coverage applies if you pay US $300 every ten years to USPTO, certifying you used the mark in commerce, within your field of business, before any other applicants. This is what SSC claimed, in its application to USPTO. If granted by trademark examiners, such registration entitles the owner to put "®" (a legally regulated symbol) next to the mark, rather than just the toothless "TM" or "SM" insignia.

This gets us neatly back to the question of who "owns" Linux Gazette. It's a fair question. The copyright question is clear: All material remains the property of each individual contributor and is issued under an open-source licence (OPL 1.0) — an arrangement LG instituted early on because LG was always an explicitly free magazine. To quote founding editor John Fisk in issue #8 (Aug. 1996), who wished to explain his vouchsafing of LG (a free magazine) to SSC, a commercial company:

So, after chatting at some length with Phil Hughes about this, I've decided to turn the Linux Gazette over to the Linux Journal. I think that the Gazette has demonstrated the "proof of concept" — that a freely available and open-to-all online publication is a great means for sharing information and ideas. There are a number of great things that could be done with this and I'm excited about the Gazette continuing on in this tradition.

Also, please know that the Linux Gazette has been, is, and will continue to be an absolutely free publication. I can't stress this enough: I know that many folks feel passionately about keeping Linux from any commercialization whatsoever. I happen to disagree with this as it's my feeling that a free and a commercial side can peacefully coexist and actually encourage and support each other. That said, I've really enjoyed knowing that the Gazette has been freely available to all and that it will continue to be so.

We agree that SSC had a well-established moral claim to LG leadership from John M. Fisk, and maintained that custodianship well for seven years. Our view changed during the year 2003, with SSC's announced plans to (in effect) kill the magazine as such, and with its refusal to account for its surreptitious deletions from the linuxgazette.com back-issues archives and their mirrors.

Consider, for comparison's sake, a hypothetical situation in which Linus Torvalds announces his intent to shut down the Linux kernel project. The situation is closely parallel: You have a collective effort headed by one party, but in which copyright is retained by each individual contributor, and material is issued under an open-source licence. We'd be sorry to see Linus go, but I doubt we'd dally more than about a minute before forking the kernel and moving it elsewhere. If he later changed his mind and resumed work on his fork, things would be awkward (just as they are now with two Linux Gazettes), but we would not say ours had suddenly became an imposter kernel.

Moving on from moral claims, there are legal ones:

SSC's recent legal claim to hegemony over the name "Linux Gazette" strikes us as outrageously unmerited, and cheeky: (1) We see no indication that Fisk assigned SSC commercial rights over Linux Gazette. If anything, Fisk made the opposite intention crystal-clear. (2) Separately and in addition, SSC's claim to have used the name in commerce starting August 1996 seems, to our knowledge, materially false. We can find no offering of commercial services under that name by SSC or anyone else. And last (also separately and in addition), (3) the attempt to use commercial trademark law as a ploy to strong-arm us — a 100% non-commercial, volunteer-staffed community project — is monumentally outrageous: It's inherent in the nature of trademark law that non-commercial uses simply cannot infringe trademark. Period.

A study of the Gazette's eight years of history suggests there's no way in Hades it can be reasonably claimed to have been ever a service offered in commerce, not in 1996 and not today. As we hope to point out in our draft response to SSC's attempted ICANN UDRP domain-snatching, SSC's acceptance of financial underwriting for LG from other Linux firms (cited by Hughes as justifying his alleged trademark) doesn't make it a service offering in commerce; it makes it a charity. We think that can be shown to anyone's satisfaction, including a judge.

We'd like to stress that we still have no intention to undermine or attack SSC. In fact, we worked out on November 5 one of numerous ways the two Gazette initiatives could work in harmony. (This is transcribed from an IRC discussion:) 

Frank: anyone feeling sorry for Phil yet, btw? *G*
JimD: Frank, actually yes.  I have been for several days.
Frank: yes, me too...
       I feel sad that he feels to need to be like this... 
       but I do not feel sorry enough not to call him on this situation...
JimD: I won't let my sympathy for him deter me, either.
Rick: jimd:  Second your comments, and it reminds me of a related point:
      When you've embarrassed someone, it's advantageous if you can offer
      him a way out, rather than putting his back up against the wall.
      I've been guilty of doing the latter, in disputes with people.
JimD: I can't see a good way for us to offer Phil *another* way out of all
      this.  We've offered several.
Rick: It's a point.
      I had a half-baked notion, which I'm trying to recall right now.
      Supposing LG.com operated its CMS, and generated content on there. 
      They can do Web-things with it as desired.  The Web contributions
      then are one of the diverse sources of candidate material for the LG
      newsletter (per OPL) that is published monthly by the LG.net editors,
      canonical location LG.net, but then mirrored to lots of other places
      including LG.com.
      If Phil objected to particular content in any issue, he would have
      the option of not mirroring that entire issue.
      Other mirrors of course also inherently have that right.
      Advantages:  Saves face, doesn't require any domain transfers.  Phil
      gets Web toys, we get a monthly magazine, of which there then is 
      only one.
      Nobody has to rename.  Nobody gets censored.
      Also, the editors get editorial control over the magazine, SSC gets
      editorial control over the Web stuff (other than the magazine).
      SSC remains free to disclaim its links to the magazine mirror with
      "SSC, Inc. does not necessarily endorse blah blah."
      SSC can continue to claim that it's asserting trademark over the name,
      but not try to register it.  The editors can disregard the trademark
      claim in knowledge that successful assertion of trademark allows you
      ONLY to bar competing use of the mark in commerce that falsely
      tends to convince customers that those competing goods are endorsed 
      or produced by the trademark owner.
      (See:  Lanham Act, US Code — easily googleable).
JimD: I don't think Phil is in the frame of mind to take such an option
Rick: A point, too.  Maybe in time.
JimD: Yep.

At present, indeed, SSC appears in absolutely no mood to work with us, but only to work on us, e.g., by launching surprise attacks on our Internet presence. However, the door remains open on our end, and we continue to regard SSC as our natural friends and allies in the long term. We hope they'll eventually remember, despite injury to their pride (but nowhere to their commercial interests), that they caused an entire Linux-community institution to walk out en masse.

Readers should rest assured that we are acting to prevent seizure of our Internet domain, and will take other measures as required to protect our name. We are Linux Gazette and will continue to do our best at being that. Our readers deserve no less.

Suggested reading

[BIO] Rick has run freely-redistributable Unixen since 1992, having been roped in by first 386BSD, then Linux. Having found that either one sucked less, he blew away his last non-Unix box (OS/2 Warp) in 1996. He specialises in clue acquisition and delivery (documentation & training), system administration, security, WAN/LAN design and administration, and support. He helped plan the LINC Expo (which evolved into the first LinuxWorld Conference and Expo, in San Jose), Windows Refund Day, and several other rabble-rousing Linux community events in the San Francisco Bay Area. He's written and edited for IDG/LinuxWorld, SSC, and the USENIX Association; and spoken at LinuxWorld Conference and Expo and numerous user groups.

His first computer was his dad's slide rule, followed by visitor access to a card-walloping IBM mainframe at Stanford (1969). A glutton for punishment, he then moved on (during high school, 1970s) to early HP timeshared systems, People's Computer Company's PDP8s, and various of those they'll-never-fly-Orville microcomputers at the storied Homebrew Computer Club -- then more Big Blue computing horrors at college alleviated by bits of primeval BSD during UC Berkeley summer sessions, and so on. He's thus better qualified than most, to know just how much better off we are now.

When not playing Silicon Valley dot-com roulette, he enjoys long-distance bicycling, helping run science fiction conventions, and concentrating on becoming an uncarved block.

Copyright © 2003, Rick Moen. Released under the Open Publication license unless otherwise noted in the body of the article. Linux Gazette is not produced, sponsored, or endorsed by its prior host, SSC, Inc.

Published in Issue 97 of Linux Gazette, December 2003

Using the HTML::Template module

By Ben Okopnik

Recently, I needed to generate a Web page - the Linux Gazette's "Mirrors and Translations" page, actually - based on the contents of a database. Perl is famous for its ability to connect to almost any database via a common interface, given its DBD::DBI module kit; however, the challenge in this case came from the front end, the HTML generation. Sure, I could use the CGI module to output whatever I needed - but in this case, I already had the static page that I wanted to create, and saw no reason to rewrite all the static content in CGI. Also, the final product was not to be a CGI file but a generated HTML page. In fact, everything in this case hinted at templating, a process in which I would use the static HTML with a few special tags and a script which would then apply processing based on those tags. This made especially good sense since it drew a clean separating line between writing HTML and creating code, very different tasks and ones for which I have different mental states (layout designer vs. programmer.)

As with anything in Perl, TMTOWTDI - there was a number of modules available on CPAN (the Comprehensive Perl Archive Network) that could do the job. However, I had used the HTML::Template module in the past, and the job wasn't particularly complicated (although HTML::Template can handle some very complex jobs indeed), so that's what I settled on. My first task was to hunt through the HTML, removing the dozens of repetitive stanzas and replacing them with the appropriate tag framework that the module would utilize later. We had also made the decision not to display the maintainers email addresses, even in the munged form that I use to deter spammers; those of you who use our mirrors and want to thank these fine folks for making LG available should be able to find an address link on the mirror site without much trouble.

Fragment of the old page (there were several dozen entries like this): 


...
<A name="AU"></A>
<DT><B><font color="maroon">AUSTRALIA (AU)</font></B></DT>
<DD>
<STRONG><FONT COLOR="green"><TT>[WWW]</TT></FONT></STRONG>
<A HREF="http://www.localnet.com.au/lg/index.html">http://www.localnet.com.au/lg/index.html</A>
<BR>
<SMALL>
Maintainer: Jim McGregor &lt;<A HREF="mailto:nospam@here.please">nospam@here.please</A>&gt; &nbsp;
</SMALL>
<P>
</DD>

<DD>
<STRONG><FONT COLOR="green"><TT>[WWW]</TT></FONT></STRONG>
<A HREF="http://www.eastwood.apana.org.au/Linux/LinuxGazette/">http://www.eastwood.apana.org.au/Linux/LinuxGazette/</A>
<BR>
<SMALL>
Maintainer: Mick Stock &lt;<A HREF="mailto:nospam@here.please">nospam@here.please</A>&gt; &nbsp;
</SMALL>
<P>
</DD>

...
Single-stanza replacement for all the entries (new template):

...
<a name="<TMPL_VAR NAME=FQDN>"></a>
<dt><b><font color="maroon"><TMPL_VAR NAME=FQDN> (<TMPL_VAR NAME=TLD>)</font></b></dt>
<dd><strong><font color="green"><tt>[WWW]</tt></font></strong>
<a href="<TMPL_VAR NAME=HTTP>"><TMPL_VAR NAME=HTTP></a>
<br>
<strong><font color="red"><tt>[FTP]</tt></font></strong>
<a href="<TMPL_VAR NAME=FTP>"><TMPL_VAR NAME=FTP></a>
<br>
<small>
Maintainer: <TMPL_VAR NAME=MAINT>
</small>
<p>
</dd>

...
Now, the challenge had shifted away from generating the HTML to just dealing with code. What I needed to do was sort the data into groups and subgroups - that is, there would some number of "country" headings, some number of "mirror" headings under each of those, and either one or two (WWW, FTP, or both) hosts plus a maintainer under each "mirror" heading. In programmatic terms, these are known as "nested loops", and are not that difficult to code. However, translating that into HTML terms could be an exercise in kind of language abilities of which your mother would not approve... if it wasn't for HTML::Template.

Note: Using HTML::Template is normally very simple; in fact, learning the basics of using it usually takes only a minute or two (see the example at the top of "perldoc HTML::Template".) However, in this instance, we're creating nested lists - a rather more complex issue than simple variable/tag replacement - and thus, the coding issues get a bit deeper. However, this isn't due to HTML::Template; if you think about the issues inherent in modeling what is already a complex data structure and then transferring that structure into a "passive" layout language... truth to tell, I'm somewhat surprised that it can be done at all. Kudos and my hat's off to Sam Tregar (author of the module) and Jesse Erlbaum (the man responsible for TMPL_LOOP.)

References

The area that seems to strike fear into the heart of neophyte programmers, more so than anything else, is the topic of references. Particularly in Perl, where everything is supposed to be warm, fuzzy, and easy to understand. However, understanding references and objects - in my opinion - are the very things that take one from being a Perl user to a Perl programmer. I'm going to simply show how references work with a bit of an explanation, but the real comprehensive reference for references :) is included with the standard Perl documentation. Simply type "perldoc perlreftut" at your command line for a good introduction, and be sure to take a look at "perldoc perlref" for the complete documentation.

First, in order to understand how the data structure must be laid out to create the pattern that we need, let's take a look at that pattern. Fortunately, in Perl it's easy to lay out the data structures to match what they represent (whitespace is arbitrary, so you can follow your preferences - but see "perldoc perlstyle".) What we'll want to do here is build the structure that contains all the values we want to assign within the loop as well as the names which are associated with those values. Those of you with a little Perl experience are nodding and smiling already: the word "associated" points very clearly to the type of variable we need - a hash! Taking a single "row" (per-country entry) - Austria, as a random example - here is how it looks: 


%row = (
	tld	=> AT,
	fqdn	=> Austria,
	sites	=> [
			{ 
			  http	=>  "http://www.luchs.at/linuxgazette/",
			  maint =>  "Rene Pfeiffer"
			},

			{ 
			  http  =>  "http://info.ccone.at/lg/",
			  maint =>  "Gerhard Beck"
			},

			{
			  http	=>  "http://linuxgazette.tuwien.ac.at/",
			  ftp	=>  "ftp://linuxgazette.tuwien.ac.at/pub/linuxgazette/",
			  maint	=>  "Tony Sprinzl"
			}
		   ]
);
The above hash, %row, matches our requirements exactly: its keys will be used to match (case-insensitively) the tag names in the HTML, and the values associated with those keys will be used to replace those tags. That is, every instance of <TMPL_VAR NAME=FQDN> in the template will be replaced by "Austria" while this entry is being processed. Here are some of the less-obvious points of the above structure:

As we create a "row" for each country, we will need to store all of them in a list. Each entry in this list must, of course, contain a reference to each row that we have built: 

# Add the hashref to the end of the array
push @mirrors, \%row;
Note the '\' preceding the %row; this stores a reference to %row rather than the hash itself (stuffing a hash into an array would result in a generally unusable mess - key/value pairs in effectively random order as array elements.) This is a standard mechanism for creating multidimensional arrays, lists-of-hashes, etc. in Perl.

And - one more time, with gusto - HTML::Template's param() subroutine, as most other subroutines in Perl and many other languages, expects a reference to the array rather than the array itself: 


# Create a new HTML::Template object
my $t = HTML::Template -> new( filename => "mirrors.tmpl" );

# Pass the listref to param()
$t -> param( MIRR => \@mirrors );
"And", as Austin Powers would say, "Oi'm spent." Those of you scared of the Big Bad References may come out from under the bed now. :)

Looking at it from the other end, the matching part of the template for this loop looks like this: 


<dl>
<TMPL_LOOP NAME=MIRR>

<dt><b><font color="maroon">
<a name="<TMPL_VAR NAME=TLD>">
<img src="gx/flags/<TMPL_VAR NAME=TLD>.jpg" border="1">
</a>
<TMPL_VAR FQDN> [<TMPL_VAR NAME=TLD>]
</font></b></dt>

<TMPL_LOOP NAME=SITES>

<dd>
<TMPL_IF NAME="HTTP">
<strong><font color="green"><tt>[WWW]</tt></font></strong>
<a href=<TMPL_VAR HTTP>>
<TMPL_VAR HTTP>
</a><br>
</TMPL_IF>

<TMPL_IF NAME="FTP">
<strong><font color="green"><tt>[FTP]</tt></font></strong>
<a href=<TMPL_VAR NAME=FTP>>
<TMPL_VAR NAME=FTP>
</a><br>
</TMPL_IF>
<small>
Maintainer:
<TMPL_VAR NAME=MAINT>
</small>
<p>
</dd>

</TMPL_LOOP>
</TMPL_LOOP>

</dl>
To recap what we're looking at, there are two loops defined in the above template, one inside the other: <TMPL_LOOP NAME=MIRR> and <TMPL_LOOP NAME=SITES>. Note that the outside loop corresponds to the name of the parameter key that we assigned when passing the data construct to param(), and the name of the inside loop is the same as the key associated with the groups inside the hash we created.


However, fine as the above may be for static data that we can simply type into those anonymous hashes in the 'groups' listref, static data isn't often what we get in the real world. Databases are updated, file contents change - and we obviously need to reflect this in our HTML. So, let's take a look at a code fragment that does this: 

for $tld ( @tlds ){
	# Set some temporary (per-loop) variables
	my @sites;
	my %row;
	my %line;

	# Here's the inner loop!
	for ( grep /^$tld/, @mirr ){
		# Parse the CSV into fields
		my @rec;
		my %site;
		s/\\,/&comma;/g;
		@rec = split /,/;
		s/&comma;/,/g for @rec;

		# Mirror listings don't require much data
		$site{ http  } = $rec[2];
		$site{ ftp   } = $rec[3];
		$site{ maint } = $rec[4];
		# Load it up!
		push @sites, \%site;
	}
	
	# Outer loop vars
	$row{ tld } = $tld;
	$row{ country } = $country{ $tld };
	# Ref to the inner loop, attached
	$row{ sites } = \@sites;
	
	# ...and load up the total into the array to be passed to param()
	push @mirrs, \%row;
}

# Feed the data to the hungry HTML::Template object
$t -> param( MIRR => \@mirrs );
By the way, the data we're reading in looks like this: 

AT,,http://www.luchs.at/linuxgazette/,,Rene Pfeiffer,nospam@here.please,
AT,,http://info.ccone.at/lg/,,Gerhard Beck,nospam@here.please,
BE,,http://linuxgazette.linuxbe.org/,,Cedric Gavage,nospam@here.please,
CA,,http://blue7green.crosswinds.net/hobbies/lg/,,Jim Pierce,nospam@here.please,
Now we have a highly dynamic chunk of code that will process the data that we give it, generate the necessary data structure on the fly, and feed it out to the template. Voila!

If you want to see the complete script that I wrote for this project, go here; the template can be found here. If you would like to see the latest generated page, go here. If you would like to change the way the page looks and do something great for the Linux community, join the folks on the list and become a mirror maintainer: commit some of your disk space and bandwidth and let the Linux Gazette "mirrors and translations" person - that's me! - know about it here.

Happy Linuxing to all!

Source material: (I was going to write "References"... :) 

perldoc perlreftut
perldoc perlref
perldoc HTML::Template
Motivation:

My annoyance at the lack of good documentation for nested loops under HTML::Template. :)

picture Ben is the Editor-in-Chief for Linux Gazette and a member of The Answer Gang.

Ben was born in Moscow, Russia in 1962. He became interested in electricity at the tender age of six, promptly demonstrated it by sticking a fork into a socket and starting a fire, and has been falling down technological mineshafts ever since. He has been working with computers since the Elder Days, when they had to be built by soldering parts onto printed circuit boards and programs had to fit into 4k of memory. He would gladly pay good money to any psychologist who can cure him of the recurrent nightmares.

His subsequent experiences include creating software in nearly a dozen languages, network and database maintenance during the approach of a hurricane, and writing articles for publications ranging from sailing magazines to technological journals. After a seven-year Atlantic/Caribbean cruise under sail and passages up and down the East coast of the US, he is currently anchored in St. Augustine, Florida. He works as a technical instructor for Sun Microsystems and a private Open Source consultant/Web developer. His current set of hobbies includes flying, yoga, martial arts, motorcycles, writing, and Roman history; his Palm Pilot is crammed full of alarms, many of which contain exclamation points.

He has been working with Linux since 1997, and credits it with his complete loss of interest in waging nuclear warfare on parts of the Pacific Northwest.

Copyright © 2003, Ben Okopnik. Released under the Open Publication license unless otherwise noted in the body of the article. Linux Gazette is not produced, sponsored, or endorsed by its prior host, SSC, Inc.

Published in Issue 97 of Linux Gazette, December 2003

Songs in the Key of Tux: Songwrite

By Jimmy O'Regan

Hello and welcome to Songs in the Key of Tux. Over the next few issues I hope to introduce some of the many packages available under Linux for musicians. The topics I intend to cover include guitar tablature (this article), music typesetting, sound recording with home studio software such as Ardour and Ecasound, and creating electronic music with some of the various synthesisers around.

If you have any questions or suggestions, please feel free to e-mail me, but please bear in mind that I use a dial-up connection, and pay by the minute - so please don't send me sound files without clearing it with me first. If you think I haven't covered something in enough detail, I'll be happy to go over it again - everything in this series is open to suggestion, including the name (I was going to go with Tux#, but that might have confused Mono/.Net fans).

Songwrite

As well as a being a computer fanatic, I'm also a guitarist. In a recent lull between bands, I decided to start learning music theory; or at least, enough to create my own tablature. A friend introduced me to GuitarPro on Windows, which I still need to use for Internet access (Winmodem), and using it I eventually managed to learn enough of the basics to create my own tablature.

I wasn't satisfied with this however, and searched in vain for a suitable Linux-based program. At first I tried KGuitar, but it wouldn't compile for me, and the only binaries I found lacked MIDI support; I'm still learning, so I need to hear a playback of almost everything I enter to make sure it's right.

[Songwrite screenshot]

I saw Songwrite mentioned a few times, but was put off using it by the screen shots available on the program's website; Songwrite is based on GTablature, but the author didn't appreciate the API changes of GNOME 2, and rewrote GTablature using Tk, and renamed it Songwrite. I find Tk intolerably ugly, and try to avoid it whenever possible, but I was tempted into giving Songwrite a try after seeing how far the program has come in the past year.

Guitar Tablature

Guitar tablature is the lingua franca of rock guitarists; many are self-taught, or received only basic instruction, and do not read music. Tablature shows the fingering layout of a song, and is therefore easier for guitarists to understand. Most of the tablature available on the Internet shows just the fingering for a song, in ASCII text. For example, an E minor arpeggio looks like this:

e|-----------------0--------|
B|--------------0-----0-----|
G|-----------0-----------0--|
D|--------2-----------------|
A|-----2--------------------|
E|--0-----------------------|

However, in the past few years, several programs have become available which allow guitarists with some knowledge of music theory to have their songs played back to them on the computer, removing the ambiguities of plain text, and the need for guitarists who can't read sheet music to own the CD. It was only a matter of time before Linux guitarists would feel the need themselves, and create software of their own.

[E-minor arpeggio]

Songwrite is one of the few tablature programs available for Linux, and despite its' early version (I'm using version 0.12), it is quite capable. Among its features are:

Songwrite does have its limitations though; for example it can only support x/4 and x/8 rhythms (though in practise this isn't much of a problem), it has no support for harmonics, and though it supports string bends, it doesn't support releasing the bend, or whammy bar type bends. Songwrite is under active development though, and important new features are being added with each release, so it will hopefully only be a matter of time before it matches the software for Windows; perhaps even beat them - none of those programs can handle non-standard harmonics; but Songwrite's interface means it won't have to undergo any major overhaul to add this support.

[Note properties]

GuitarPro support

GuitarPro is the most popular of the Windows-based tablature programs, and several sites, such as MySongBook.com, have been set up so that people can share their favourite tabs with one another, and other Windows programs support the format. Supporting GuitarPro's format is therefore very important to anyone who wishes to make the transition from Windows, or to gain access to the thousands of pre-made tabs available in this format.

Having previously tried a pre-release version of KGuitar, I didn't have high hopes for Songwrite's GuitarPro import. There are several problems; it can't handle non-standard note durations (though it does support triplets), its recognition of repeated bars and linked notes is hit and miss, it doesn't recognise tempo changes and it has difficulty importing complicated tabs. Some of the features it lacks are not a problem when it comes to GuitarPro import, however; though it has limited support for non standard time signatures, it still manages to play back simple files without a problem.

Getting started

When you first run Songwrite, you are faced with a blank screen. Entering notes is as simple as with other programs: you click the line representing the string you wish to enter upon, and type in the number of the fret. To play it back, simply hit the space bar.

Entering chords is just as easy; and as a bonus over other programs, Songwrite can copy and paste any combination of notes and chords, rather than just individual bars. You simply select the area of music you wish to copy, and middle-click to paste. This also allows you to place chord fragments on other string groups.

Another feature unique to Songwrite is the ability to enter notes at any point in a bar; in other tablature programs you would have to enter rests before the next note. This is useful if you are transcribing music and aren't sure which chord or note is being played, or if the music starts late in the bar - lead fills and vocal harmonies can be entered much more quickly with this feature.

[Selecting an area of music]

Things to watch out for

When pasting, click on the highest string used in the chord. For example, if you wish to paste a G5 chord as a C5 chord, then you should click on the G string. If you click lower, Songwrite will add extra strings to your fret layout.

e|-----------|
B|-----------|
G|--------5--|
D|--5-----5--|
A|--5-----3--|
E|--3--------|
    G5    C5

If you try to do something Songwrite doesn't support, it may end up as part of your file. I've had it add strange rhythms to files, thinking that the change had simply rejected. If you get an error message, use the Undo function, and check to see if anything noticable has changed.

The competition

Songwrite has only two main competitors at the moment (though there are several programs to help with the preparation of simple ASCII tabs) - KGuitar and Gnometab. KGuitar is possibly the best option for guitarists new to music theory; the most recent version added the ability to click the rhythm of a riff with the mouse button - KGuitar then attempts to figure out the note durations and time signature. I can't comment on how well this feature works, however, as I still can't get it to compile. From the version I have tried, however, I can say that the chord tool is wonderful.

I haven't tried out Gnometab, so I can't comment on it; though I can say that it has the best looking interface of any of the tablature programs I've seen.

Examples

For the more adventurous types who may be interested in using songwrite, I'm attaching a tarball of GuitarPro files. A lot of them don't import, but I have confidence in the development of Songwrite, so I'm including them to "future-proof" this article. For the time being, however, I've also included midi files, so you'll know what they should sound like in the meantime. [examples.tar.gz]

Links

[BIO] Jimmy is a single father of one, who enjoys long walks... Oh, right.

Jimmy has been using computers from the tender age of seven, when his father inherited an Amstrad PCW8256. After a few brief flirtations with an Atari ST and numerous versions of DOS and Windows, Jimmy was introduced to Linux in 1998 and hasn't looked back.

In his spare time, Jimmy likes to play guitar and read: not at the same time, but the picks make handy bookmarks.

Copyright © 2003, Jimmy O'Regan. Released under the Open Publication license unless otherwise noted in the body of the article. Linux Gazette is not produced, sponsored, or endorsed by its prior host, SSC, Inc.

Published in Issue 97 of Linux Gazette, December 2003

Using DCOP from the command line

By Jimmy O'Regan

Introduction

DCOP is KDE's IPC/RPC mechanism. If you understood that sentence, please feel free to skip the next paragraph.

DCOP stands for Desktop COmmunications Protocol, IPC stands for Inter-Process Communication; RPC stands for Remote Procedure Call. In essence, they are means by which two programs can communicate, whether on the same machine or across a network. In this regard, DCOP is similar to Microsoft's OLE Automation: it provides a simple way for developers to provide access to the functions available in an application.

KDE was originally attempting to build a CORBA-based component system (the GNOME project originally started as this project, but became a desktop project in a disagreement over the license the Qt widget set was using), but it was decided that CORBA was too complicated, and two simpler systems were introduced; KParts, for embedded components; and DCOP.

A DCOP enabled application registers at launch time with the DCOP daemon, and registers its functions. When queried, the dcop daemon provides a list of running processes and the functions they provide. This enables a range of applications, such as the DCOP browser, or the DCOP to XMLRPC daemon; but the one I'm going to look at is 'dcop', which allows shell access to DCOP.

Unlike other systems, such as GNOME's Bonobo or Microsoft's Automation, DCOP does not provide an activation system; only running processes are listed by DCOP. Activating the application is left up to the user.

This article is about using DCOP to control KDE applications from the command line; links are provided at the end of the page to developer information for those who wish to delve deeper into this technology.

Using DCOP from the command line

The 'dcop' program provides command line access to the DCOP system. The syntax is:

dcop [application] [object] [function] [arguments ...]

To see which applications are available, enter 'dcop' with no arguments

$ dcop
khelpcenter
kwin
kicker
kword-4354
kded
knotify
kio_uiserver
kalarmd
kcookiejar
konsole-4300
korgac
klauncher
kdesktop
klipper
ksmserver

Let's have a look at klipper, the KDE clipboard service:

$ dcop klipper
qt
klipper

We can assume that klipper is the object we're looking for here; the default object (i.e., the one you want, to control the application) is normally given the same name as the application, with or without "IFace" appended, or is marked as "default":

$dcop klipper klipper
QCStringList interfaces()
QCStringList functions()
QString getClipboardContents()
void setClipboardContents(QString s)
void clearClipboardContents()
int newInstance()
void quitProcess()

Now, I think the most interesting functions here are setClipboardContents and getClipboardContents. In fact, I've been using setClipboardContents in a konsole window to add the shell output above:

dcop klipper klipper setClipboardContents "$(dcop klipper klipper)"

Now, to be honest, this isn't the best example, as it's a lot quicker to use the mouse than to type that, but it can become a lot more useful if set as an alias, e.g.

alias klip="dcop klipper klipper setClipboardContents"

I've always thought it would be useful to have post-it notes available from the shell - DCOP makes that possible.

$dcop knotes KNotesIface
QCStringList interfaces()
QCStringList functions()
int newNote(QString name,QString text)
int newNoteFromClipboard(QString name)
ASYNC showNote(int noteId)
ASYNC hideNote(int noteId)
ASYNC killNote(int noteId)
QMap notes()
ASYNC setName(int noteId,QString newName)
ASYNC setText(int noteId,QString newText)
QString text(int noteId)
ASYNC sync(QString app)
bool isNew(QString app,int noteId)
bool isModified(QString app,int noteId)

So let's add a note:

dcop knotes KNotesIface newNote "A note" "Stuff I want to keep track of"

Sure enough, a bright yellow note pops up.

Let's see what notes are available:

$dcop knotes KNotesIface notes
1->A note

After adding a few more nonsense notes, maybe I want to have them in a text file, so I wrote a silly script to go with a silly idea:

#!/bin/bash
n=$(dcop knotes KNotesIface notes|awk -F- '{print $1}'|tail -1)
dcop knotes KNotesIface notes > $1
echo >> $1
for ((i=1;i<=$n;i++));do echo -n "$i: "; dcop knotes KNotesIface text $i;echo;done >> $1

Summary

DCOP is a powerful means to control KDE applications. As more and more developers recognise its usefulness, we get closer to a nice blend of desktop eye candy and scriptability.

Links

[BIO] Jimmy is a single father of one, who enjoys long walks... Oh, right.

Jimmy has been using computers from the tender age of seven, when his father inherited an Amstrad PCW8256. After a few brief flirtations with an Atari ST and numerous versions of DOS and Windows, Jimmy was introduced to Linux in 1998 and hasn't looked back.

In his spare time, Jimmy likes to play guitar and read: not at the same time, but the picks make handy bookmarks.

Copyright © 2003, Jimmy O'Regan. Released under the Open Publication license unless otherwise noted in the body of the article. Linux Gazette is not produced, sponsored, or endorsed by its prior host, SSC, Inc.

Published in Issue 97 of Linux Gazette, December 2003

A simple Pulse Width Modulation trick with Linux/RTAI

By Pramode C.E.

In an earlier article, I had discussed the basics of realtime programming with Linux/RTAI. This article demonstrates a nice trick which you can do on your home machine, provided you are willing to hook up a simple circuit to your parallel port (and, of course, run an RTAI patched kernel). I also demonstrate elementary use of:

Be careful when you play with PC hardware - don't come looking for me if you burn up something!

The Trick

You want to make an LED light up, slowly. It gets brighter, brighter, brighter.... It should then go off - again, little by little. This should keep on repeating. By controlling the current flowing through it, we can control the brightness of the LED - but trouble is, our PC parallel port gives us only two voltage levels - low (0V) and high (around 5V). As this can't be varied, we will only be able to bring the LED on and make it go off - instantaneously - which is not what we would like to do.

Pulse Width Modulation

Imagine that you are cycling along a road, in a rather peculiar way. You pedal hard for 3 seconds, then you sit idle for 7 seconds - again, you pedal hard for 3 seconds and sit idle for 7 seconds. If you keep on doing this, you will cover the distance between two points in a certain amount of time - by dividing the distance by time, you get an `average' speed. What happens to this average speed if you increase the amount of time pedalling? It surely goes up, and if you decrease the pedalling time, it goes down. In a similar way, instead of applying a constant DC voltage on the LED, we apply a signal of a fixed frequency (say 1KHz, period of 1ms). The LED will burn brightly if out of the total 1ms period, the signal stays high for say .8ms and low for only .2ms. By varying the duty cycle of the signal (keeping the frequency fixed), we will be able to deliver variable levels of power to the circuit, making it brighter and dimmer. We are now able to do analog control in a purely digital manner!

[waveforms]

The Hardware

You won't need anything more than an LED (preferably a bright one) and a 1K resistor. The resistor and the LED should be connected in series between pin number 2 (an output pin) and pin number 25 (ground) of the parallel port. The 8 output pins (2 to 9) of the parallel port can be accessed via IO port 0x378. Writing a 1 to 0x378 will result in only pin number 2 going high; writing 0xff will result in all pins going high - you write some other pattern and you can control the logic level at any of the pins.

[LED schematic]

The resistor is to limit the current flowing through the circuit to a few milli amps. The trouble is that the LED will burn only feebly when you limit the current through it. A solution is to use a transistor as a switch.

The Software

The basic idea is simple - we write a real-time task which will turn on the LED, sleep for some time, turn it off, and again sleep for some time. The total on plus off time is 1ms. Initially, the on time would be 0 and off time, 1ms. In the next iteration, the on time would become 1*1microsecond and off time would become (1ms - on time). In the next iteration, the on time would be 2*1microsecond, and so on. In the 1000th iteration on time would be 1000*1microsecond, ie 1ms and off time would be (1ms - on time), which would be 0. Once we reach here, we start bringing down the on time so that it ultimately becomes 0 and off time becomes 1ms. This process is repeated. So, in 1 seconds time (each iteration takes 1ms, and we have 1000 iterations), the LED will go from off to the brightest possible level and in the next 1 second, it comes down to its off state slowly.

Here is the code which implements this idea: 


#include <linux/kernel.h>
#include <linux/module.h>
#include <rtai.h>
#include <rtai_sched.h>

#define STACK_SIZE 4096

#define MIN_ON_PERIOD 0 
#define TOTAL_PERIOD 1000000 /* 1ms */
#define NSTEPS 1000
#define STEP_PERIOD 1000

#define LPT1 0x378


static RTIME on_time, off_time, total_period;
static RT_TASK my_task;

enum direction {DOWN, UP};

static void pwm_task(int n)
{
	int step = 0;
	static int dir = UP;
	
	while(1) {
		outb(0xff, LPT1);
		rt_sleep(on_time);
		outb(0x0, LPT1);
		rt_sleep(off_time);
		if(step == NSTEPS) {
			dir = !dir;
			step = 0;
		}
		step++;
		if(dir == UP) on_time =  nano2count(step*STEP_PERIOD);
		else if(dir == DOWN) on_time = total_period - nano2count(step*STEP_PERIOD);
		off_time = total_period - on_time;
	}
}

int init_module(void)
{
	RTIME now;
	
	rt_set_oneshot_mode();
	rt_task_init(&my_task, pwm_task, 0, STACK_SIZE, 0, 0, 0);
	start_rt_timer(0);
	
	on_time = nano2count(MIN_ON_PERIOD);
	off_time = nano2count(TOTAL_PERIOD);
	total_period = nano2count(TOTAL_PERIOD);
	
	now = rt_get_time() + total_period;
	rt_task_make_periodic(&my_task, now, total_period);
	
	return 0;
}


void cleanup_module(void)
{
	stop_rt_timer();
	rt_busy_sleep(10000000);
	rt_task_delete(&my_task);
}
The pwm_task's code should be easy to understand.

Because RTAI ensures us that realtime tasks would always meet their deadlines, penalizing only non-realtime tasks, we see that the PWM generation process continues smoothly even when the system is heavily loaded. The time `step' of 1 microsecond in our code will be difficult for RTAI to achieve, but we won't be getting any visual indications regarding it (unless we use an oscilloscope to watch the waveform). Also, ours is just a `fun' program!

Sending Messages

Tasks can send messages to each other - a message is a simple integer value. Here is a small program which demonstrates message passing: 


#include <linux/module.h>
#include <rtai.h>
#include <rtai_sched.h>

#define LPT1_BASE 0x378
#define STACK_SIZE 4096
#define TIMERTICKS 1000000000 

static RT_TASK tasks[2];

static void task_sender(int t)
{
	int msg = 0xab;
	RT_TASK *r;
	r = rt_send(&tasks[1], msg);
	rt_printk("sender: r = %x\n", r);
}

static void task_receiver(int t)
{
	int msg;
	RT_TASK *r;

	r = rt_receive(&tasks[0], &msg);
	rt_printk("receiver: msg = %x\n", msg);
	rt_printk("receiver: r = %x\n", r);
}


int init_module(void)
{
	RTIME tick_period, now;

	rt_set_periodic_mode();
	rt_task_init(&tasks[0], task_sender, 0, STACK_SIZE, 0, 0, 0);
	rt_task_init(&tasks[1], task_receiver, 0, STACK_SIZE, 0, 0, 0);

	rt_printk("sender = %x\n", &tasks[0]);
	rt_printk("recevier = %x\n", &tasks[1]);
	tick_period = start_rt_timer(nano2count(TIMERTICKS));
	now = rt_get_time();
	rt_task_make_periodic(&tasks[1], now + tick_period, tick_period);
	rt_task_make_periodic(&tasks[0], now + 2*tick_period, tick_period);
	return 0;
}

void cleanup_module(void)
{
	stop_rt_timer();
	rt_busy_sleep(10000000);
	rt_task_delete(&tasks[0]);
	rt_task_delete(&tasks[1]);
}
The recevier task starts executing at the next timer tick. It immediately inovkes rt_receive. The first argument is address of the RT_TASK object corresponding to the sender task. Because the sender is not yet active, task_receive blocks. At the next timer tick, task_sender becomes active and sends the `message' 0xab to task_receiver. The receiver task comes out of the block and prints the received message as well as the address of the RT_TASK object corresponding to the sender task.

Using Mailboxes

A mailbox is a convenient mechanism using which multiple tasks can communicate with each other. Let's look at a small program: 


#include <linux/module.h>
#include <rtai.h>
#include <rtai_sched.h>

#define LPT1_BASE 0x378
#define STACK_SIZE 4096
#define TIMERTICKS 1000000000 

static RT_TASK tasks[2];
static MBX my_mbx;

static void task_sender(int t)
{
	int msg = 0x12cd, r;
	r = rt_mbx_send(&my_mbx, &msg, sizeof(msg));
	rt_printk("sender: r = %d\n", r);
}

static void task_receiver(int t)
{
	int msg, r;
	r = rt_mbx_receive(&my_mbx, &msg, sizeof(msg));
	rt_printk("receiver: msg = %x\n", msg);
	rt_printk("receiver: r = %d\n", r);
}


int init_module(void)
{
	RTIME tick_period, now;

	rt_set_periodic_mode();
	rt_task_init(&tasks[0], task_sender, 0, STACK_SIZE, 0, 0, 0);
	rt_task_init(&tasks[1], task_receiver, 0, STACK_SIZE, 0, 0, 0);

	rt_mbx_init(&my_mbx, 4*sizeof(int));
	tick_period = start_rt_timer(nano2count(TIMERTICKS));
	now = rt_get_time();
	rt_task_make_periodic(&tasks[1], now + tick_period, tick_period);
	rt_task_make_periodic(&tasks[0], now + 2*tick_period, tick_period);
	return 0;
}

void cleanup_module(void)
{
	stop_rt_timer();
	rt_busy_sleep(10000000);
	rt_mbx_delete(&my_mbx);
	rt_task_delete(&tasks[0]);
	rt_task_delete(&tasks[1]);
	
}

A mailbox is represented by a static variable of type MBX. We create a new mailbox by calling rt_mbx_init. The second argument is the size of the mailbox. The sender task calls rt_mbx_send and stores a message `msg' of size `sizeof(msg)' in the mailbox. The receiver task receives the message by calling rt_mbx_receive. The receiver will block until all the bytes of the message have been received (or until some error occurs).

Conclusion

I started exploring Linux/RTAI out of curiosity, but I am being tempted to learn more. I hope my excitement becomes contagious and more readers start tinkering on their own. Just don't forget to tell us about your experiments!

[BIO] As a student, I am constantly on the lookout for fun and exciting things to do with my GNU/Linux machine. As a teacher, I try to convey the joy of experimentation, exploration, and discovery to my students. You can read about my adventures with teaching and learning here.

Copyright © 2003, Pramode C.E.. Released under the Open Publication license unless otherwise noted in the body of the article. Linux Gazette is not produced, sponsored, or endorsed by its prior host, SSC, Inc.

Published in Issue 97 of Linux Gazette, December 2003

Let There Be Music

By Shuveb Hussain

Linux multimedia has been a field buzzing with activity. Many open minds have now contributed to make Linux a decent multimedia platform. Today many projects exist that make a large number of multimedia activities possible under Linux. If you need a good introduction to various sound utilities under Linux, you should read an excellent previous article on Linux Gazette found here.

I wanted to include sound in one of the apps I was writing and began googling the web. I learnt that there are many libraries that make it possible to decode common compressed sound file formats like Ogg Vorbis or MP3. Playing sound on to your speakers is no big deal either. In this article, we'll see how to decode Ogg Vorbis and MP3 files by writing simple programs. This article has been written with beginners in mind, so Linux gurus, sorry for too much explanation of the simple stuff.

Programming the Sound Card

Before we actually get into the details of programming the sound card, it would be actually helpful to know how sound data is recorded, stored and played back on our computers.

Sampling

When sound is to be recorded, we ought to choose the quality at which we want to do it. One main criterion that determines sound quality is the sampling rate. Take for example music, it is just frequency that varies over time. If we want to record sound digitally, we note down the frequency of the sound at a fixed rate. This is known as the sampling rate. The higher the sampling rate, the better the quality of the music. For example, CD quality audio has a sampling rate of 44100 per second or 44100 Hz. This technique is used by devices called ADCs or Analogue to Digital Converters and is called Pulse Code Modulation or PCM.

Bits and Channels

When sound is sampled, fixed number of bits are used per sample and there are one are more channels. The number of bits at which the data is sampled is known as the resolution of the sampling. The most common form is a 8 bit unsigned byte or 16 bits. Data for different channels is maintained separately. For example, CD audio has two channels, Left and Right (Stereo). If you make a simple calculation, to record CD quality audio at a resolution of 8 bits, for 1 second it would take: 

		2 x 44100 = 88200 bytes

	(Number of channels x sampling rate)

Now that we have enough information on the theory lets get started with the actual programming. There are actually a few ways to program the sound card. In the early Linux days, when drivers were being written, two separate groups were formed. Open Sound System or OSS was a group that wrote many device drivers and even included binary modules from sound card manufacturers who were reluctant to provide hardware specifications, or provided specs, but not without the driver developer signing an non-disclusure agreement. Since the hardware guys were reluctant to give out specs to individuals, OSS went on to create 4Front Technologies, a company. One more group ALSA, or Advanced Linux Sound Architecture wrote drivers only for those sound cards whose manufacturers were ready to give out specifications. ALSA drivers are now very popular. They have been included in the 2.6-test kernel too.

Note that ALSA provides an OSS emulation layer, so if you program for OSS your program might work on systems with OSS or ALSA. In this article, I'll try and explain OSS programming since it's simple and is present in majority of the systems.

Remember that under UNIX/Linux, all the device drivers have a file system interface, usually under the /dev directory. Most of the file related sytem calls like open,read,write,lseek,close work on these devices. The device files may be considered hooks in the file system from where the device drivers keep listening for requests. As an example, the file /dev/hda1 is the file that represents the interface for the first partition on the primary master IDE hard disk. If you open it using the open system call, you would be returned a file handle like in all file operations. If you now try and read from it, you would actually read data from the first sector of this partition! Similarly, a forward lseek will move the file pointer forward. To skip a sector, you'd lseek forward the size of a sector. Please don't fiddle around with your hard disk device file, its rather dangerous. Writing rubbish on to the partition will render it unuseable. You'll mostly have direct access to hardware devices only as root.

Having said that, lets move on to some code. This code should run as non-root without issues. In case there are problems accessing the device file, su as root and chmod and grant access. Ofcourse you should have a sound card thats known to work under Linux. Save typing by getting the source from here. Don't forget to download the demo.pcm file. 

/*
	oss.c plays a raw PCM 22KHz sample sound on the sound card
	
	Important  -  Make sure the demo.pcm file is is the current directory
	before you attempt to run this program.
*/

#include < sys/types.h >
#include < sys/stat.h >
#include < sys/soundcard.h >
#include < sys/ioctl.h >
#include < unistd.h >
#include < fcntl.h >
#include < errno.h >
#include < stdlib.h >

#define SECONDS 5 //playback seconds

int main() 
{
	int fd;
	int handle = -1;
	int channels = 1;         // 0=mono 1=stereo
	int format = AFMT_U8;
	int rate = 22000;
	unsigned char* data;
	
/* Open the file corresponding to the soundcard for writing, DSP stands for Digital Signal Processor */
	if ( (handle = open("/dev/dsp",O_WRONLY)) == -1 )
	{
		perror("open /dev/dsp");
		return -1;
	}
/* Tell the sound card that the sound about to be played is stereo. 0=mono 1=stereo */

	if ( ioctl(handle, SNDCTL_DSP_STEREO,&channels) == -1 )
	{
		perror("ioctl stereo");
		return errno;
	}

	/* Inform the sound card of the audio format */
	if ( ioctl(handle, SNDCTL_DSP_SETFMT,&format) == -1 )
	{
		perror("ioctl format");
		return errno;
	}
	
	/* Set the DSP playback rate, sampling rate of the raw PCM audio */
	if (ioctl(handle, SNDCTL_DSP_SPEED,&rate) == -1 )
	{
		perror("ioctl sample rate");
		return errno;
	}
   
	// rate * 5 seconds * two channels
	data = malloc(rate*SECONDS*(channels+1));
	
	if((fd=open("demo.pcm",O_RDONLY))==-1)
	{
		perror("open file");
		exit(-1);
	}

	/* read the data contained in the demo file to the allocated memory */
	read(fd,data,rate*SECONDS*(channels+1));
	close(fd);
	
	/* just write the data to the sound card! This will play it. */

	write(handle, data, rate*SECONDS*(channels+1));

	if (ioctl(handle, SNDCTL_DSP_SYNC) == -1)
	{
		perror("ioctl sync");
		return errno;
    	}

	free(data); //Be good, clean up.
	close(handle);
	printf("\nDone\n");
	return 0;
}

The program listed above plays a raw PCM, 22 KHz, Stereo data file for 5 seconds. The program does three simple things:

a. Opens the sound device
b. Sets the playback parameters
c. Writes the data to the device

The open()/write()/close() system calls are the same ones used for normal files. To set the device playback parameters, we use the ioctl() (Input/Output Control) system call. The ioctl() system call is used to communicate with I/O devices and set their parameters. It might also be seen as a trick to decrease the number of invidual system calls. Its known as the programmer's swiss army knife. The signature of the ioctl() sytem calls is :

int ioctl(int fd, int command, ...)

The first parameter is the file descriptor of the device, the second parameter is the request/command passed to the device and the rest of the parameters are command specific [See man ioctl_list for a list of commands]. Examine this:

ioctl(handle, SNDCTL_DSP_SPEED,&rate)

This ioctl() call sets the DSP playback rate, the third parameter is the actual rate passed to the device driver.

There are three main ioctl() calls used in the example program. The first one sets the number of channels to be used for playback, the second one sets PCM format and the third, the rate. Since this is all the device needs to know, we next write the PCM data right on to the device file and the device plays it for us. We then flush the device with the final ioctl() and release the memory allocated for the PCM data. Thats it, we are done.

Music storage formats

Man, just to play 5 seconds of 22KHz sound data in the previous example, 220 KB of raw PCM data was needed. 

	
	22,000 x 5 x 2 = 220,000
	(sample x seconds x channels)
	
	So to play 1 minute of CD Quality audio, one would need:

	44,100 x 60 x 2 = 5292000 bytes or roughly 5 MB!

Audio CDs store raw PCM data, but to store music efficiently in computers, and to stream or share it over the Internet, music is compressed to reduce file size and decompressed on the fly during playback. If you can see, the sampling rate is fixed, no matter what the nature of the music being played. Imagine silence being sampled for a few seconds, it would still consume the same amount of space as a loud rock number would for the same given time. Raw audio files don't compress well since there is very little data repetition which is important for good compression. Different audio formats use different techniques to reduce the size of the resulting file. The most common technique is to remove sound that the human ear doesn't care about, or to compress the audio stream depending on the music being played. The most popular format for music lovers is unargueably MP3. Since MP3 is now shrouded in patent issues, Ogg Vorbis is now welcome among members of the open source community. Both formats achieve the same reduction in size and are able to maintain audio quality with minimal loss.

Lets see how to play Ogg Vorbis files on our system, since we know how to tell the sound card to play raw audio data. For us to play Ogg Vorbis format files, we first need to decode it or in other words, convert it to raw PCM data. This will be done by libvorbisfile. This library presents decoding at much a higher level than libvorbis, which is quite low level, but allows relatively more fine grained control. Its really simple from here: We provide the library with the input data from a Ogg Vorbis file and the library provides us with the decoded raw PCM format data which we feed right into to sound card. Source available here 

#include < sys/types.h >
#include < sys/stat.h >
#include < sys/soundcard.h >
#include < sys/ioctl.h >
#include < unistd.h >
#include < fcntl.h >
#include < errno.h >
#include < stdlib.h >

#include "vorbis/codec.h"
#include "vorbisfile.h"

int setup_dsp(int fd,int rate, int channels);


char pcmout[4096]; // 4KB buffer to hold decoded PCM data.
int dev_fd;

int main(int argc, char **argv)
{
	OggVorbis_File vf;
	int eof=0;
	int current_section;
	FILE *infile,*outfile;

	if(argc<2)
	{
		printf("supply file arguement\n");
		exit(0);
	}

	if ( (dev_fd = open("/dev/dsp",O_WRONLY)) == -1 ) 
	{
		perror("open /dev/dsp");
		return -1;
	}

	infile=fopen(argv[1],"r");
	
	if(infile==NULL)
	{
		perror("fopen");
		exit(-1);
	}   

	if(ov_open(infile, &vf, NULL, 0) < 0) 
	{
		fprintf(stderr,"Input does not appear to be an Ogg bitstream.\n");
		exit(1);
	}
	
	char **ptr=ov_comment(&vf,-1)->user_comments;
	vorbis_info *vi=ov_info(&vf,-1);
	while(*ptr)
	{
		fprintf(stderr,"%s\n",*ptr);
		++ptr;
	}

	fprintf(stderr,"\nBitstream is %d channel, %ldHz\n",vi->channels,vi->rate);
	fprintf(stderr,"\nDecoded length: %ld samples\n",(long)ov_pcm_total(&vf,-1));
	fprintf(stderr,"Encoded by: %s\n\n",ov_comment(&vf,-1)->vendor);
  
	if(setup_dsp(dev_fd,vi->rate,vi->channels-1))
	{
		printf("dsp setup error.aborting\n");
		exit(-1);
	}

	int count=0;
	
	while(!eof)
	{
		long ret=ov_read(&vf,pcmout,sizeof(pcmout),0,2,1,&current_section);
		if (ret == 0)
		{
			/* EOF */
			eof=1;
		}
		else if (ret < 0)
		{
	      		/* error in the stream.  Not a problem, just reporting it in
			case we (the app) cares.  In this case, we don't. */
		}
		else 
		{
			printf("Writing %d bytes for the %d time.\n",ret,++count);
			write(dev_fd,pcmout,ret);
		}
	}

	ov_clear(&vf);
	fclose(infile);
	
	if (ioctl(dev_fd, SNDCTL_DSP_SYNC) == -1) 
	{
    		perror("ioctl sync");
		return errno;
	}
	close(dev_fd);
	fprintf(stderr,"Done.\n");
	return(0);
}

int setup_dsp(int handle,int rate, int channels)
{
	int format;

	if ( ioctl(handle, SNDCTL_DSP_STEREO,&channels) == -1 ) 
	{
		perror("ioctl stereo");
		return errno;
	}
	
	format=AFMT_U8;
	if ( ioctl(handle, SNDCTL_DSP_SETFMT,&format) == -1 )
	{
		perror("ioctl format");
		return errno;
	}
	
	if ( ioctl(handle, SNDCTL_DSP_SPEED,&rate) == -1 )
	{
		perror("ioctl sample rate");
		return errno;
	}
	
	return 0;
}

To compile this program use the following command 
gcc oggplay.c -oggplay -lvorbisfile -I/path/to/vorbis/header/files -L/path/to/vorbis/lib/files

If the library file or the header files are in the usual locations like /usr/lib and /usr/include, then you can skip the -I and -L command line switches. All major distibutions ship with the vorbisfile lbrary, if your system doesn't seem to have it installed, you can always download it from here. You can also visit the Ogg Vorbis site here. You need the development header files if you need to compile the program.

The setup_dsp function opens the dsp device, sets the three main parameters, channels, format and rate. You need to remember that these are the three most important parameters to set for audio playback. In the main function, other than the error checking, we have only two main things going on. The Ogg Vorbis file supplied as shell arguement is opened and user comments and information about it is printed. The sampling rate and channel information is extracted from the information structure filled up by the ov_open() library function and passed on to the setup_dsp function. The program then enters a loop where bytes decoded from the Ogg Vorbis file stream and placed into a buffer. This raw PCM data contained in the buffer is then played by writing to the dsp device which has already been setup. This loop continues until end-of-file is reached, finally things are cleaned up and exit happens. That wasn't difficult or was it? Thanks to libvorbisfile, decoding is so easy and straightforward.

To decode Ogg Vorbis files, the obvious choice is libvorbisfile, but if you want to decode and play MP3 files, there are a lot of libraries that can do the job. One library thats popular is the smpeg library which is capable of decoding both video and audio streams. One more library I came across is libmad. We'll select smpeg and use its audio decoding capabilities alone. You can further explore its MPEG video decoding capabilities if you are interested. A sample application plaympeg is also provided that demonstrates the useage of the library. For Video playback, smpeg uses SDL, which is a very simple to use yet a very capable graphics prgramming library. There are many many more libraries around, but smpeg is provided by many Linux distributions and that made me choose it. The popular gtv MPEG video player is a part of the smpeg package.

Here is an example program that plays MP3 files. Please note that smpeg library plays the decoded MP3 stream directly on the sound card. We don't get to handle any PCM stuff. Also available here 

#include < stdio.h >
#include < stdlib.h >
#include < string.h >
#include < signal.h >
#include < unistd.h >
#include < errno.h >
#include < sys/types.h >
#include < sys/stat.h >
#include < sys/ioctl.h >
#include < sys/time.h >

#include "smpeg.h"

void usage(char *argv0)
{
	printf("\n\nHi,\n\n%s \n\nThis is the normal useage.\n",argv0);
}

int main(int argc, char *argv[])
{
    int volume;
    SMPEG *mpeg;
    SMPEG_Info info;
   
    volume = 100; //Volume level
    
    /* If there were no arguments just print the usage */
	if (argc == 1) 
	{
	        usage(argv[0]);
	        return(0);
	}

	mpeg = SMPEG_new(argv[1], &info;, 1);

        if ( SMPEG_error(mpeg) ) 
	{
            fprintf(stderr, "%s: %s\n", argv[1], SMPEG_error(mpeg));
            SMPEG_delete(mpeg);
        }
	
        SMPEG_enableaudio(mpeg, 1);
        SMPEG_setvolume(mpeg, volume);

        /* Print information about the audio */
        if ( info.has_audio ) 
	{
            printf("%s: MPEG audio stream\n", argv[1]);
            
	        if ( info.has_audio ) 
		    printf("\tAudio %s\n", info.audio_string);

        	if ( info.total_size ) 
			printf("\tSize: %d\n", info.total_size);
	        
		if ( info.total_time )
			printf("\tTotal time: %f\n", info.total_time);

		/* Play it, and wait for playback to complete */
		SMPEG_play(mpeg);
        
		while(SMPEG_status(mpeg)==SMPEG_PLAYING);
        	SMPEG_delete(mpeg); //release the struct
	}
	return(0);
}

You need to compile this program after you install smpeg which can be found here. Please note that smpeg needs SDL to be installed as a pre-requisite. To complie, you need to provide the paths to include files and library files. To make this process easy, the smpeg package provides a simple utility named smpeg-config. Compile the program with the following command: 

gcc playmp3.c `smpeg-config --cflags --libs` -I/usr/include/SDL

Please note that its not the single quote character that encloses the smpeg-config command, its the character thats present along with the tilde (~) character in US layout keyboards, sometimes called a backquote. This character instructs the shell to inject the output of the enclosed command into the actual command line. If you run the smpeg-config command separately, you'll know what I am talking about. Replace the -I/usr/include/SDL command option with -I < your SDL path >. Even though we don't use any of the SDL functions, we need to provide gcc with the SDL header file path because smpeg.h uses it internally. RPM users should install both the smpeg and the smpeg-devel packages for the program to compile.

The library function SMPEG_new allocates a new internal object, while filling up an SMPEG_info structure which contains information about the MP3 file. In the program this information is printed and playback begins by calling SMPEG_play. Thing is this call returns immediately which is really good when you're dealing with MP3s in an application program because it lets you do other things. Since we have nothing else to do in the program, we wait until the file has finished playing. SMPEG_delete then releases memory previously allocated by the library and we are done.

I hope this article finds use in some of your programing ventures. I'd like to hear from you folks. Do get in touch for any clarifications or criticism. I can be reached through shuveb@shuvebhussain.org.

Linux Zindabad
(Means long live Linux, in Hindi which is India's primary and national language)

[BIO] Shuveb is a pervert by social compulsion sitting in a small but historical city in southern India. He thinks life is neither a Midsummer Night's Dream nor a Tempest, it's simply a Comedy Of Errors, to be lived As You Like It. Apart from being a part time philosopher, he is a seasoned C programmer who is often in confusion about what the * does to a pointer variable.... APR Bristol is the company that pays him for learning Linux.

Copyright © 2003, Shuveb Hussain. Released under the Open Publication license unless otherwise noted in the body of the article. Linux Gazette is not produced, sponsored, or endorsed by its prior host, SSC, Inc.

Published in Issue 97 of Linux Gazette, December 2003

A Look At Jython

By Rob Tougher

This article discusses Jython, a software project that aims to provide seamless integration between Java and Python. This article requires a basic understanding of both languages.

Introduction

There are many different programming languages. The Language List, a comprehensive database of computer languages, puts the number at around 2500. Having different languages is advantageous to developers - each language has features that are well-suited to certain classes of problems. For example, when I'm transforming XML, XSLT is my tool of choice (this is a popular method of rendering HTML for dynamic web sites). When coding server-based applications, I prefer languages such as Java, C++ and Python. I think the general advice for programmers is to "use the right tool for the job".

One noticeable drawback in this abundance of languages is the inability (or extreme difficulty) in reusing code written in one language from another language. For example, say you had written a database library in Java, and wanted to reuse that library in Python. You could write a glue layer, using a technology like COM, CORBA, sockets, or SOAP, but that layer would take time to write. It would be nice if this glue layer already existed, ready to be consumed with little or no effort expended.

Enter Jython. The goal of the Jython project is to provide seamless integration between Java and Python. The project contains two main tools:

This article provides a basic introduction to Jython. First I'll describe installation, next I'll talk about the jython interpreter, and I'll finish up with a discussion of the jythonc compiler. I'll use the following naming conventions when referring to the different interpreters, compilers, and projects:

Installation

To use Jython on your system you need two pieces of software: the Java SDK, and the Jython distribution.

You can get Sun's latest Java SDK for Linux (1.4.2) at the main Java site. Sun distributes the SDK as a single binary file that you can download and run on your Linux machine. After the install completes, the remaining step is to create an environment variable named JAVA_HOME, and set its value to the root directory of the Java installation. I set this variable as part of my ~/.bashrc file: 

#
# For the 1.4.2 sdk
#

export JAVA_HOME=~/apps/j2sdk1.4.2_01
export PATH=~/apps/j2sdk1.4.2_01/bin:$PATH

Notice that I set the PATH environment variable also - I do this so that I can access the Java command line tools (java, javac, jar, etc) from any directory.

The latest release of Jython (2.1) is distributed from the main Jython site. The Jython project provides a graphical installer written in Java and packaged as a single Java *.class file. When you run the installer you are presented with a graphical setup wizard, which asks you to specify the installation type, agree to the license terms, and specify the target directory for installation. When the install completes, you are ready to use Jython on your machine. It is useful to update your PATH and CLASSPATH variables to point at the newly installed Jython distribution. I do this in my ~/.bashrc file: 

#
# For Jython
#

export JYTHON_HOME=~/jython-2.1/
export PATH=$JYTHON_HOME:$PATH
export CLASSPATH=$JYTHON_HOME/jython.jar:$CLASSPATH

To check that your installation succeeded, type "jython" at the command prompt: 

prompt$ jython
Jython 2.1 on java1.4.2_01 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>>

If you see the above, you've successfully installed Jython.

Using The Jython Interpreter

The jython interpreter is a Python interpreter implemented in 100% Java. It allows you to write Python code that accesses Java classes.

The latest stable version of jython, released in December of 2001, implements features of Python 2.1. Python, however, has already reached version 2.3. This means that Python features unique to versions 2.2 and 2.3 are unavailable in the current stable version of jython:

An alpha version of jython, available for download at the Jython site, implements a mixture of Python 2.1 and 2.2. The Jython group characterizes this alpha version as an unstable and experimental release that contains significant known issues. In other words, use the alpha version at your own risk.

Besides lacking recent Python language features, jython is missing some Python modules in its library implementation. On top of that, there is little documentation describing which modules are supported and which are not. If you want to know if a module is supported, the FAQ suggests attempting to import the module in question. If the import fails, you can try to copy over the corresponding *.py module from the CPython implementation. As a last effort you can request help on the public mailing lists.

While the Python support in jython is restricted to version 2.1, the Java support is completely up-to-date. You can use _any_ Java code from inside the jython interpreter. This includes the standard Java 1.4.2 libraries, libraries written by third parties, and your own custom libraries.

For example, you could use Java's Abstract Window Toolkit (AWT). The AWT is a graphical windowing library that provides widgets for creating user interfaces (windows, buttons, text areas, etc). You could write Python code that accessed the AWT, and then run that code using the jython interpreter.

Here's an example of using AWT functionality from within Python: 

#
# file: AWTTest.jy
#

#
# Import the AWT classes.
#

from java.awt import Frame
from java.awt import Panel
from java.awt import Button
from java.awt import TextArea
from java.awt.event import ActionListener


#
# Define the TestButtonAction class. TestButtonAction
# inherits from the Java ActionListener interface.
#

class TestButtonAction(ActionListener):

        def actionPerformed(self, e):
                textArea.append("Test Button Clicked!\n")


#
# Create the Frame, Panel, Button,
# TextArea, and TestButtonAction objects.
#

frame = Frame("Hello World")
panel = Panel() 
button = Button("Test Button")
buttonAction = TestButtonAction()
textArea = TextArea()


#
# Put everything together and show
# the window.
#

button.addActionListener(buttonAction)
panel.add(button)
panel.add(textArea)
frame.add(panel)
frame.pack()
frame.show()

You can run this using the jython interpreter: 

prompt$ jython AWTTest.jy

Running this code should produce a window similar to the following:

[screenshot]

The example creates a window and adds a Button and a TextArea to it. When you click the button, the text "Test Button Clicked!" is appended to the TextArea's contents. The example displays a few key features of Jython:

Using The Jythonc Compiler

The second tool that the Jython project provides is jythonc. jythonc compiles Python source code into Java bytecode. This Java bytecode can be executed using a standard Java Virtual Machine.

(Java bytecode is the intermediate language that the Java Virtual Machine executes. When you compile a Java source file using javac, the compilation output is a file with a *.class extension. This file contains Java bytecode, which you can execute using the Java Virtual Machine. For more information about Java bytecode and the JVM, check out The Java Virtual Machine Specification )

jythonc suffers from the same feature lag as the jython interpreter - the latest jythonc release implements features from Python 2.1. Furthermore, the alpha version of Jython contains a jythonc compiler that is basically unchanged since the last release. It looks like jythonc will be stuck at version 2.1 for a while.

When compiling a Python class with jythonc, you need to provide extra information about each publically accessible method in your class. This information includes the return type, arguments, argument types, throws clause, and access control declaration (private, public, or protected). You can provide this information in one of two ways:

For example, you could write a Java Servlet in Python (servlets are Java classes that run inside servlet containers, like Tomcat and Jetty, and respond to web page requests). You could create a Python class that derives from HttpServletRequest, compile that class into bytecode using the jythonc compiler, and run that bytecode inside of a servlet container.

The following is a simple servlet written in Python: 

#
# file HelloWorldFromJython.py
#

import os
from javax.servlet.http import HttpServlet


class HelloWorldFromJython(HttpServlet):

        def service(self, request, response):

                response.setContentType("text/html")
                out = response.getOutputStream()
                print >>out, """<html>
                                <head>
                                        <title>Hello World Servlet</title>
                                </head>
                                <body>
                                        <p>Hello World From Jython!</p>
                                        <p>os.getcwd() == """ + str(os.getcwd()) + """</p>
                                </body>
                                </html>"""

You can run this example using Tomcat. Tomcat installation is pretty straightforward - it only requires downloading the distribution and extracting it to your hard drive. You should create an environment variable named TOMCAT_HOME and set its value to the Tomcat root directory: 

#
# For Tomcat.
#

export TOMCAT_HOME=~/apps/jakarta-tomcat-4.1.27/

The next step is to compile the Python servlet with the jythonc compiler (note that the CLASSPATH environment variable needs to be updated to include the servlet.jar archive): 

prompt$ export CLASSPATH=$TOMCAT_HOME/common/lib/servlet.jar:$CLASSPATH
prompt$ jythonc --deep HelloWorldFromJython.py

processing HelloWorldFromJython
processing javaos
processing string
processing UserDict
processing copy
processing repr
processing javapath
processing re
processing sre
processing sre_constants
processing sre_compile
processing copy_reg
processing sre_parse

Required packages:
  java.lang
  org.python.core
  java.io
  javax.servlet.http

Creating adapters:

Creating .java files:
  sre_constants module
  javaos module
  sre module
  javapath module
  re module
  string module
  sre_compile module
  copy_reg module
  HelloWorldFromJython module
    HelloWorldFromJython extends javax.servlet.http.HttpServlet
  UserDict module
  sre_parse module
  repr module
  copy module

Compiling .java to .class...

[snip]

The jythonc compiler creates a directory named "jpywork" in your current directory. This directory contains the *.class file output of the jythonc compilation, along with supporting files.

The next step is to deploy the binary *.class files to the Tomcat server's webapps directory. Normally you would create a new web application for your servlets, but for this example you can use the existing "examples" web application that ships with Tomcat. Create a new directory inside of that web application and copy the class files to it: 

prompt$ mkdir $TOMCAT_HOME/webapps/examples/WEB-INF/classes/HelloWorldFromJython
prompt$ cp jpywork/*.class $TOMCAT_HOME/webapps/examples/WEB-INF/classes/HelloFromJython/

Next add the jython.jar archive to the webapp's lib directory (if the directory doesn't exist, create it): 

prompt$ mkdir $TOMCAT_HOME/webapps/examples/WEB-INF/lib
prompt$ cp $JYTHON_HOME/jython.jar $TOMCAT_HOME/webapps/examples/WEB-INF/lib/

Now that the Python servlet has been compiled and deployed to the Tomcat server, and the jython.jar archive has been included in the lib directory, you can run the Tomcat server: 

prompt$ $TOMCAT_HOME/bin/startup.sh

Using CATALINA_BASE:   /home/robt/apps/jakarta-tomcat-4.1.27
Using CATALINA_HOME:   /home/robt/apps/jakarta-tomcat-4.1.27
Using CATALINA_TMPDIR: /home/robt/apps/jakarta-tomcat-4.1.27/temp
Using JAVA_HOME:       /home/robt/apps/j2sdk1.4.2_01

You should be able to access your Python servlet using the following URL:

The servlet will produce output similar to the following: 

prompt$ wget http://yourmachine:8080/examples/servlet/HelloWorldFromJython/HelloW
orldFromJython

prompt$ cat HelloWorldFromJython

<html>
	<head>
		<title>Hello World Servlet</title>
	</head>
	<body>
		<p>Hello World From Jython!</p>
		<p>os.getcwd() == /home/robt/apps/jakarta-tomcat-4.1.27/bin</p>
	</body>
</html>

Conclusion

This article served as an introduction to the Jython project. For more information about the subjects presented in this article, check out the following links:

[BIO PEN] Rob is a software developer in the New York City area.

Copyright © 2003, Rob Tougher. Released under the Open Publication license unless otherwise noted in the body of the article. Linux Gazette is not produced, sponsored, or endorsed by its prior host, SSC, Inc.

Published in Issue 97 of Linux Gazette, December 2003

Ecol

By Javier Malonda

The Ecol comic strip is written for escomposlinux.org (ECOL), the web site tha t supports, es.comp.os.linux, the Spanish USENET newsgroup for Linux. The strips are drawn in Spanish and then translated to English by the author.

These images are scaled down to minimize horizontal scrolling. To see a panel in all its clarity, click on it.

[cartoon]
[cartoon]
[cartoon]

All Ecol cartoons are at tira.escomposlinux.org (Spanish), comic.escomposlinux.org (English) and http://tira.puntbarra.com/ (Catalan). The Catalan version is translated by the people who run the site; only a few episodes are currently available.

These cartoons are copyright Javier Malonda. They may be copied, link ed or distributed by any means. However, you may not distribute modifications. If you link to a cartoon, please notify Javier, who would appreciate hearing from you.

Copyright © 2003, Javier Malonda. Released under the Open Publication license unless otherwise noted in the body of the article. Linux Gazette is not produced, sponsored, or endorsed by its prior host, SSC, Inc.

Published in Issue 97 of Linux Gazette, December 2003

Mozilla Firebird - A review

By Raj Shekhar

1. Firebird  
2. Installation  
3. Making it the default browser in GNOME  
4. What's Good  
5. More tips  

1. Firebird

I have been using Mozilla Firebird for some time now and have stopped my search of a better browser. I had used Mozilla earlier, but it was so bloated that I switched to Galeon. However, if I had a beefier system, I would have been happy with Mozilla, bloat or no bloat. Mozilla took a lot of time to startup and came bundled with a chat client and a mail reader, which I seldom used. On the other hand its `tabbed windows' reduced a lot of desktop clutter. The Firebird is a spin-off from Mozilla. The project aims to develop software that is smaller and faster than Mozilla by extracting and redesigning the browser part of the application suite.

The developers of Firebird started out with the aim of creating a browser to provide an efficient (speedy, easy to use, useful) web access. According to the Mozilla Firebird 1.0 Development Charter:

The goal was, and is not to have more or less features than any other client (Mozilla included) but to have the right set of features to let people get their jobs done.
From what I see, I must congratulate the developers on a job very well done.

2. Installation

Using RPMs
I used the RPM to install Firebird on Red Hat 9.0. I am sure the hints provided here will prove useful for installing on another RPM based system. I used the RPMS for Red Hat maintained and built by Dag Wieers. If you want to locate the RPMs for your own distribution, try searching at rpmseek. Use `mozilla-firebird' as your search string.

After downloading the RPM, you can install it from the command prompt
rpm -ivh <package-name>

If you had installed Mozilla or Galeon earlier, you should have no dependency problems. Otherwise, you may have to search, download and install other packages too to solve the dependency problems. Again the best places to find the packages are rpmseek, Rpmfind.Net and Rpm pbone.

If you installed Firebird using the RPM package provided by Dag Wieers, then you can launch Firebird by giving the command mozilla-firebird. If you installed using the package provded by some other repository, type rpm -ql <package-name>|grep -i /usr/bin. That will provide you the command to launch Firebird.

Using official Firebird Release
Disclaimer I installed from a RPM and not from the official Firebird Release.

You can get Firebird from the Mozilla Firebird download page. At the time of writing, the website recommends to install Mozilla Firebird 0.7. There are downloads available for GTK (9.1 MB) and GTK2 and XFT (8.6 MB). Read the How To Install section to learn more on installation.

I will give a brief outline of the installation process. After you have downloaded the appropiate tarball from the above mentioned links, login as root. Unzip the files into the directory `/usr/lib/'. Next, issue the command
chown -c -r root:root /usr/lib/mozilla-firebird
In case you unzipped the tarball into a different directory, remember to substitute the proper name of the directory. That's all to the install process. To launch your brand new browser, issue the command
/usr/lib/mozilla-firebird/MozillaFirebird
However, if you want to make it your default browser in GNOME and want to avoid the hassle of typing the full path every time, see the next section.

Installation in Windows
If you have a 100% Linux shop, you can safely skip this step. However, if you have to use Windows, I would strongly suggest that you consider switching from Internet Explorer to Firebird. I tested it out on a Windows 2000 PC. As in Linux, you have to just unzip the files, click on the `MozillaFirebird.exe' and that is the end of the installation process. The first time it starts up, Firebird imports your IE bookmarks and also asks you if you would like to make Firebird your default browser.

3. Making it the default browser in GNOME

Login as root and in your `/usr/bin/' directory create a file called `firebird-remote'. Put the following lines into it

 
#!/bin/sh
/usr/lib/mozilla-firebird/MozillaFirebird  -remote "openURL($@, new-tab)" ||
exec /usr/lib/mozilla-firebird/MozillaFirebird "$@";
Just change the directory locations to suit your installation. Use chmod a+x /usr/bin/firebird-remote to assign everyone the permission to execute the script. That is all the work required by you as root.

In case you are wondering what this shell-script does, here is a brief explanation. When Firebird is invoked with the `-remote' argument, it does not open a window, but instead connects to and controls an already-existing process. The argument `openURL (URL, new-tab)' creates a new tab displaying the specified document. If you would rather have it open a new window, use `openURL (URL, new-window)' instead. The page remote control of unix mozilla has more explanation about this. Thie above script first checks if we already have a Firebird running and displays the page in a new tab. If it does not find one, it creates a new process and displays the page in it.

Next, if you wnat to make Firebird your default browser in GNOME, you have to edit the file `~/.gnome/Gnome'. You will find it contains a directive
 
[URL Handlers]
http-show=nautilus "%s"
https-show=nautilus "%s"
:
[ other non-interesting suff ]
:
Add or edit the lines so that it becomes
 
[URL Handlers]
http-show=firebird-remote "%s"
https-show=firebird-remote "%s"
ftp-show=firebird-remote "%s"
:
[leave this portion unchanged]
:
Thats all to it. Your default browser for GNOME and its associate apps like Evolution is now Firebird.

4. What's Good

Firebird packs quite a lot of power under its hood. The feature I like the most is tabbed-browsing. When you Ctrl + click on a link, it opens on a page in background Tab. This way, you go on reading the current page and the new page gets loaded in the background.

Firebird stops annoying popup windows dead in their tracks. This is a good example of a good thing implemented in a very non-intrusive manner. When it blocks a popup window, it displays an icon in the status bar. Clicking this icon shows a breakdown of the popup that Firebird stopped when loading the current page. You can then allow some or all of the popup windows to be shown.

Quite a few people think Free Software means an ugly user interface. Firebird is aesthetically designed, with nice icons and colors. If you are not happy with the default look-and-feel, checkout the themes collection on display. Some themes simply change the colors of Mozilla Firebird, others can change every piece of the browser appearance. I have switched from the default theme to the LittleFirebird theme, which reduces screen-space usage.

Firebird allows enhancing of the basic browser by use of extensions. If there a particular feature which you think Firebird lacks, check out the extensions available. In all probability, you will find what you need there.

5. More tips

Plugins
Whenever Firebird comes across a page which needs some particular plugin to be installed, it asks you whether you want to install the plugin or not. It then takes you to the download page of that particular plugin. However, you can get all the major plugins from Mozilla Plugin Support page for Linux (or the Windows page).

Block opening new windows
Firebird doesn't stop web pages from opening in new windows (i.e using the target="_blank" or the illegal target="_new" properties.) you can tweak your settings to do this. In the address bar, if you type about:config, it takes you to the browser's settings page. Use the `Filter' to find the string browser.block.target_new_window, right click on it and Modify the value to true.

Increase text size
If you find the text size of a site too small, you can increase it by using the Ctrl + + key.

There are more tips on the Tips & Trick page.


This document was generated on December, 4 2003 using texi2html

[BIO]

I work for Yahoo! Bangalore (and I think it is the best place to work :-) ) as an Operations Engineer.

I am a staunch supporter of Free Software and the No Software Patents campaign. In my free time, I try to keep a semi-regularly updated blog.

Copyright © 2003, Raj Shekhar. Released under the Open Publication license unless otherwise noted in the body of the article. Linux Gazette is not produced, sponsored, or endorsed by its prior host, SSC, Inc.

Published in Issue 97 of Linux Gazette, December 2003

Tux