Leading items

lca2007: Christopher Blizzard

The keynote speaker on the second day of linux.conf.au 2007 was Christopher Blizzard, currently with Red Hat. His topic was "relevance," and, in particular, the relevance of the free software movement to the rest of the world.

One way to be relevant is to create top-quality products. There was an emphasis on the word "product," rather than "project"; Chris was talking about making things for people. The best products, he says, are those which genuinely change the way we live. The example he used was cellular telephones, which have truly changed the ways in which people communicate. Your editor, often reduced to communicating with his children via text message, is not convinced that all these changes are for the better, but the talk did not address this side of things.

The next slide was a marketing shot of the iPhone. Is this a product which will change how people live? Nobody in the audience was willing to argue that it was.

Then came Firefox - a project which Chris worked on for some years. Firefox "makes the web less annoying," and makes a point of respecting its users, which is important. It's still not clear that Firefox has changed the way people live, however. Even so, Firefox had some lessons to offer:

• You can't change the web from the back end. No matter how much good and innovative work is being done on the server side, the software which controls the user experience will shape the web. Firefox has been successful because it is "driving from the front," and influencing how the users see and work with the net.

• Going direct to users is important; you can't count on others to distribute your software for you.

• Stick to your core values. The Mozilla project gets significant amounts of money from its sponsors, but it is unwilling to consider sponsorships which would require user-hostile changes.

• Have a mission. A project will only produce a great project if it has a strong idea of what it is trying to accomplish.

How many years, asked Chris, has it been the year of the Linux desktop? Is Linux relevant for desktop users. In general, his answer was "no." Linux is showing up in interesting places, however: the Nokia N800, telephones, and the One Laptop Per Child project.

OLPC, says Chris, truly is a relevant project which will be changing lives. It has a well-defined mission - providing computing technology in a way which furthers the education of children in the developing world - and it is creating a product which furthers that mission. To that end, a number of interesting innovations have been made; these include the OLPC display (which, among other things, is readable in full sunlight), the mesh networking feature, and the ability to power it with a hand-operated generator. The sugar user interface also rates high on the list; it has tossed out much of the standard desktop metaphor in favor of a new design aimed at the OLPC's target user base.

So, based on this, how should a project make itself relevant? Chris suggests:

• Find an important set of clients, and work toward their needs. In the OLPC example, the clients are developing-world children (or, perhaps, the governments which represent them).

• Find good designers and trust them. Free software developers are often dismissive of the need for good design, but you cannot create a great product without it. Once you have found people who can do this design, you must trust them, even if their work takes you in directions which are surprising and unfamiliar.

• Make your product for other people. Doing so requires developing a certain amount of empathy for the intended clients and getting past the "itch scratching" mode of development.

A project which follows these guidelines, says Chris, has a good chance of being relevant well into the future.

Comments (9 posted)

Interview with Second Life's Cory Ondrejka

Cory Ondrejka, CTO of Linden Lab, has some serious programming credentials. Before joining Linden Lab in late 2000, he worked on US government projects and Nintendo games; as well as writing much of the original core code for Second Life, he also designed the Linden Scripting Language (LSL), and wrote the LSL execution engine. He talks to Glyn Moody about the background to Linden Lab's decision to take the Second Life client open source, how things will work in practice, and what's going to happen server-side.

When did Linden Lab start to think about the possibility of opening up Second Life's source code?

Was there any particular stimulus at that time?

Was the decision to open the viewer's code a difficult one?

Why did you choose GNU GPLv2 license for the code?

In fact, you already offer a commercial license, I believe?

When did you start the detailed preparatory work, and what did that entail in terms of preparing the viewer code for release?

Did you have to do much in terms of making the code more legible or more modular?

Could you say a little about these big changes that are coming through?

What are the things that you haven't been able to open source?

Why do you distribute binary copies of libraries that are almost certain to be found on any GNU/Linux system -- zlib and ogg/vorbis, for example?

In terms of the timing, Linden Lab's been very circumspect in talking about this move: the signals were later this year rather than at the beginning. Why is it happening now, much earlier than you originally indicated?

What do you hope to gain from open sourcing the viewer?

Were you surprised by the large number of positive comments on the blog posting that announced the move?

What are the resources that you've put in place to work with the community that you hope to build around the code?

What's he going to be doing, and how will the code submissions be processed?

You mentioned JIRA for issue tracking, what about the actual code management?

Will you be giving accounts on that to outside contributors?

To foster external contributions, how about moving to a plug-in architecture?

You've indicated that you view opening up the client as a learning experience for open-sourcing the server in the right way: what additional issues will you need to address here - presumably the proprietary Havok physics engine is going to be a problem?

What kind of things are you having to deal with?

Does that mean centralizing certain Second Life services?

Do you think that these future worlds will be part of the main Second Life geography or will there be portals from them through to your world?

Presumably you've also got to deal with issues like identity as avatars move between different worlds, and the tricky one of money?

What does that imply about the convergence of 3D virtual worlds with the Web?

Finally, once you've opened up the code to the client and server, what will be left for Linden Lab to make some money from?

Glyn Moody writes about open source and virtual worlds at opendotdotdot.

Comments (4 posted)

The Grumpy Editor's Guide to graphical IRC clients

This article is part of the LWN Grumpy Editor series.

IRC (Internet Relay Chat) is a venerable protocol which allows people to type messages at each other across the net. Your editor remembers a fascinating day in 1991, when observers in Moscow used an IRC channel to report on the Soviet coup attempt; it was an early example of the power the net would come to have. In subsequent years, however, your editor has had little time for IRC. Getting LWN together every week requires a strong focus on getting things done, and IRC can be a real productivity killer. Pretending that IRC does not exist has been most helpful in getting the Real Work done.

Recently, however, your editor has had reason to wander into IRC again. Having not done much in this area for a while, your editor lacked a favorite IRC client - or any IRC client at all. Thus began the search for the best tool for this particular job - and, eventually, this article.

Anybody who has investigated the topic knows that there is no shortage of IRC clients to choose from. It would appear that free software developers are often afflicted with this particular itch. There is no real hope of reviewing them all, so your editor will not even try. Instead, this review is restricted to graphical clients which appear to have a real user base and which are under active development. Your editor also lacks access to AOL instant messaging, MSN messaging, etc., so this review will be focused on IRC functionality. Some clients can work with many networks; that capability will be mentioned when appropriate, but it will not be reviewed further. Finally, your editor has little to say about channel operator commands, file downloads, or other such features of IRC; this article will focus on the basics.

Gaim

Gaim is a longstanding GNOME messaging client. It does IRC, along with AIM, ICQ, MSN Messenger, Yahoo, Jabber, Gadu-Gadu, and so on. If it's a messaging protocol, Gaim can probably handle it. Those using it for IRC only will find that Gaim brings a certain amount of baggage ("buddy lists" and such) which is not useful in that context, and that some of the terminology used ("rooms") does not quite match the IRC conventions. None of this is particularly problematic in real use, however.

The main Gaim window is tab-oriented, with each IRC channel in its own tab. This organization is space-efficient, but it can make it hard to monitor more than one channel - though the color-coded tab tags help. Tabs can be detached, however, allowing the user to fill the screen with single-channel windows. Gaim windows use smooth scrolling, a feature your editor got tired of back in the VT100 days; unfortunately, there appears to be no easy way to turn it off. On the other hand, users can turn off the insertion of cloyingly cute smiley graphics into the message stream.

Private messages result in the quiet creation of a new tab - something which can be easy for the user to miss. In general, the handling of private messages in IRC clients seems a little awkward.

Gaim has support for IRC servers which can authenticate nicknames with passwords. It also has a plugin feature which can be used to extend the client; available plugins add support for additional protocols, expose more preference options, perform encryption, and more.

Finally, on your editor's system, the Gaim client was a huge process. It should not be that hard to create an IRC client which requires less that a 50MB resident set, but the Gaim developers have not done that. Running Gaim made the whole system visibly slower. Gaim also doesn't take the hint when all of its windows are closed; one must explicitly tell it to go away by selecting "Quit" from the "Buddies" menu in the "Buddy list" window - something your editor found less than entirely intuitive.

Konversation

Konversation is a KDE-based client centered around IRC. Like many KDE clients, it is feature-heavy and visually pleasing.

Like Gaim, Konversation is based on a single window with tabs. In this case, however, there does not appear to be any way to detach the tabs into their own windows. One nice feature in Konversation is "remember lines," lines drawn in each conversation window when it goes out of view. When returning to a channel, the user knows just where to start reading to catch up on the new stuff. This feature gets a little aggressive at times, drawing several lines together in low-activity channels; one presumes this little glitch can be ironed out. Konversation also has an option to suppress all of the channel event lines (comings and goings) which tend to clutter up the conversation.

Konversation can handle passwords, but it required a bit more setup work than some other clients. Also available is a "URL catcher" tab which simply accumulates URLs posted on subscribed channels.

Overall, Konversation comes across as a featureful and useful IRC client. The documentation which comes with it is well-done and comprehensive; it helped your editor get past his initial questions ("how do I make it stop joining #kde?") quickly. Detachable tabs would make it nearly perfect.

ERC

Perhaps your editor is pushing it a bit by including ERC in this list. ERC is an emacs-based IRC client; it can be added onto emacs 21, and it has been bundled into the upcoming emacs 22 release. Emacs is a strongly graphical environment these days, and ERC offers all of the point-and-click configuration and operation options that the other clients reviewed here have.

ERC maintains a separate buffer for each open IRC channel. It tends to hide those buffers, and there is no simple tab bar for switching between them. It is a simple matter for an emacs user to configure the display as desired, with different channels displayed in different windows or frames. Somebody who is not familiar with the emacs way of doing things would have a harder time of it, however.

There is a separate buffer for managing the connection with the IRC server, and that is where private messages show up. It is probably safe to say that very few users will keep that buffer visible, with the result that private messages tend to go unnoticed. ERC also arguably features the ugliest, most unreadable channel list window of any of the clients reviewed.

Display is highly configurable. By default, ERC is less color-happy than most other graphical clients, a feature which your editor appreciates. There is a full list of options for filtering users and message types, performing text transformations, etc. And, of course, the experienced emacs user can simply attach elisp functions to any events requiring more involved customization.

There is no provision for marking the last-read text in ERC. This functionality is easily obtained by moving point off the end of the buffer, essentially saving the current location - but the user must remember to do it.

Overall, your editor likes the feel of working with ERC - but, then, he is known to be sympathetic to emacs-based solutions. There is no need to figure out how to search for specific text, for example - all of the normal text searching functions work as expected. Saving text or a partial log is straightforward. There is no one-line text window to type into; one simply types into the buffer and long lines are broken naturally. And so on. Emacs users will probably be happy with ERC; the rest of the world is unlikely to pick up emacs to be able to use it.

XChat

XChat is a popular client with a relatively long history. Your editor tried out the GNOME version of XChat on several networks. Finding servers was relatively easy, since XChat comes equipped with a long list built into it. One thing which becomes immediately apparent, however, is that XChat grabs the channel list in a blocking operation. The client can go completely unresponsive for several minutes until the listing is complete - not the friendliest introduction possible.

The main XChat window features a tree listing of servers and open panels on the left, and a display of one of those channels in the main pane. There does not appear to be any way to view more than one channel's traffic at any given time. The left pane marks channels with unread activity - with a separate mark if the only activity is enter and leave events.

The XChat feature list is long. It has a "last read" line in each window, though how it decides when something was read remains a bit of a mystery. It is not directly related to expose, focus, or mouse button events. Those who are relatively uninterested in actually reading IRC traffic can set up window transparency and background images. There is a plugin mechanism which can used to set up a URL grabber window or to script the client in Perl or Python. Moving the pointer over a correspondent's name yields a popup with that person's name and origin information. There is no password support, however. Unlike some other clients, XChat appears to have relatively little support for channel operator functions.

Graphically, XChat is reasonably pleasing, with a use of color which is not entirely excessive. Private messages are handled in a relatively straightforward and visible way - but the dialog for selecting a user to talk to is painful. Overall, it is a capable and easy client adequate for the needs of a large subset of IRC users.

SeaMonkey

Once upon a time, the Mozilla client looked as if it were about to grow to encompass the functionality of most other programs found on a typical desktop system. The Mozilla project eventually decided to redirect its efforts toward the more focused Firefox and Thunderbird tools, leaving the old, comprehensive application behind. There were users who did not like that state of affairs, and who dedicated some time to continuing its development. The result was the SeaMonkey project. Tucked into one corner of this tool is an IRC client.

Your editor's introduction to this tool was somewhat rocky. It offered up Undernet as one of its connection possibilities. Your editor decided to check it out and see what channels were available. After a long period where the client was completely unresponsive (attempting to list information for over 20,000 channels), it simply crashed. Note to the SeaMonkey developers: if you must crash, please have the courtesy to do so before making the user wait for a long network transfer.

When SeaMonkey is operating, it provides a single, tabbed window with nicknames on the left. There is no way to have more than one channel on-screen at a time. There is no password support. All told, the SeaMonkey IRC client ("ChatZilla") comes across as unfinished and rough compared to a number of the alternatives. Your editor has seen nothing here to convince him that web browsers need to support IRC too.

ksirc

Ksirc is a simple IRC client shipped with KDE; it does not appear to have a web page dedicated to it. It offers less help than many other clients; your editor's install of ksirc did not know about any IRC servers, for example. Once configured, however, it operates well enough.

The bulk of the interface is done through a single window, with each channel represented by a tab. It is possible to detach the tabs into separate windows, making it possible to see multiple windows at once. There is also a "ticker mode" where messages scroll by in a single-line window, but this mode did not render properly on your editor's system. A separate window shows the list of servers and open channels, but it does not appear to actually be useful for much.

Your editor appreciates restraint in the use of color, but ksirc, perhaps, takes the idea too far by default. The window is essentially monochromatic, dense, and difficult to read. The use of color can be configured, however, and there is a set of filters which can be used to highlight messages with text of interest. When the automatic colorizing mode is enabled, however, it has an unhealthy tendency to pick gray for some of the more active users - a bit of a pain considering that the window background is, by default, gray.

Overall, ksirc is a sufficiently capable tool for most needs. It gives the impression of having been left behind by some of the other KDE-based IRC clients, however, and of not getting much development attention in recent times.

Kopete

A more contemporary KDE client is Kopete. This tool, perhaps, is the KDE answer to Gaim; it appears to have support for just about any messaging protocol one can imagine. Once again, your editor only looked at the IRC functionality.

If ksirc is dense and hard to read, Kopete is the opposite. The default display is full of white space, divider bars, icons, smilies, and more. Here, too, it can be hard to follow a conversation for the simple reason that very little of it actually fits into the window. Kopete supports themes, however, and it does not take long to find a theme which makes a little better use of screen real estate.

At the outset, Kopete's interface is a bit intimidating. The small window that comes up seems to offer little in the way of interesting operations - joining a channel, say. For that, one must know to right-click on the little icon which shows up in the taskbar tray and wander through the menus. It all works fine once one gets the hang of it, but a new user trying to get started without having read the manual is likely to be frustrated for a while.

It is hard to miss private messages in Kopete - the application creates a new window and throws it at you. For the serious messaging user, there is a whole set of options for configuring just how hard the client tries to let you know about various sorts of events. About the only thing that is lacking is a "last read" line. With that in place, and with an appropriate theme, Kopete is a powerful and attractive tool.

KVirc

Finally, your editor tried out KVirc, which is a bit of a different approach to IRC clients. Unlike Kopete, which leaves the first-time user trying to figure out what to do, KVirc starts with a set of configuration windows - one of which even displays the GPL text for approval. The user ends up with a big window containing another for server selection. It would appear that just about every IRC server on the planet has been put into this dialog; it's a long list.

After selecting a server (and, perhaps. entering password information), the user encounters one of the more peculiar aspects of KVirc. Every channel has its own window, but all of those windows are contained within the big KVirc window. There is a background image in the big window, and the channel windows are all translucent. It is all visually striking, but your editor could not help wondering why the developers felt the need to implement their own window manager. It even has options for tiling all of the subwindows - with a choice of several different algorithms.

KVirc also has KVS, its own, special-purpose scripting language "inspired by C++, sh, perl, php and mIrc". There is a separate window for monitoring socket operations, no end of options for playing sounds, a set of anti-spam and anti-flood filters, and more. It's all powerful and striking, but it's hard to help wondering if all that brilliant development energy couldn't have gone into something more generally useful than another IRC client.

For people who spend much of their lives in IRC, KVirc might well be the tool of choice. It's visually striking, feature-rich, and users can script their own bots directly within the client. For your editor's purposes, however, KVirc is an overly heavy tool, wanting the full screen and ongoing attention.

Conclusion

Some readers will certainly note the biggest omission from this review: bitchx. It is, beyond doubt, a powerful client; bitchx was left out primarily because it is not a graphical client. Those who are determined to remain in the curses world are unlikely to be much interested in the other clients listed here, so there doesn't seem to be much point in trying to compare them.

So which client will your editor use when he wishes to be grumpy with others in real time, one line at a time? ERC probably remains at the top of the list, but XChat is also a useful and capable client. If your editor were a user of other messaging protocols as well, it would pretty much come down to Gaim or Kopete, depending on one's desktop orientation. Your editor's high-school son tends to quickly minimize windows when others walk into the room, but he would appear to have settled on Gaim.

In the end, however, just about any of these clients is adequate for the job. One cannot help but wonder why the free software community has produced such a large set of IRC clients. Yes, IRC is an important communication channel, and a well-designed client can make IRC more pleasant to work with, but it still does not seem like there would be room for that many applications doing essentially the same thing. One cannot fault developers for scratching an itch and giving the result to the world. Perhaps, once they have achieved the creation of the world-dominating IRC client, some of these developers will move on to the creation of something truly revolutionary.

Comments (37 posted)