Wallpaper from Houghi (click image above
to enlarge; non-lossy PNG version)

With Novell’s release of XGL and Red Hat’s answer to all that eye candy, one begins to wonder if flame wars could awake over X — an Open Source graphics and interaction component.

An advantage to free software is that it is an environment where competition can thrive, choice is always available and different solutions exist for the same problem. However, it’s also fair to say that free software is disadvantaged where competition breeds, choices are forced on unsuspecting users and diverse technologies fight each other.

Related item: Next Generation of X

HIS item serves as a brief introduction and a pointer to a mailing list analysis tool. The tool in question is capable of producing statistics for mail that is stored in a standardised form, namely the MBOX format. The tool is called MailListStat, MLS being the memorable abbreviation.

I am currently generating statistics for mailing lists where I am most active, but there is a pitfall. Messages are not always RFC-compliant and, as a result, a certain number of messages gets discarded by MLS. Consequently, statistics do not reflect on the true figures and facts. I have changes the code and re-compiled it, but it was a “mend-and-break” situation. I could never get the desired results and only borked the package progressively. So, eventually I chickened out and aborted my initiative. The author of the tools admits there are some issues related to message headers interpretation. In the mean time, it seems as though I definitely gave up on this.

UPDATE: As of this morning, I am able to use the tool perfectly well. By saving mailing list archives in Horde/IMP, I am able to make the header both uniform and acceptable as input to MLS.

Related item: Newsgroups Statistics

N programming, efficiency always entails a cost. Contrariwise, simplified and inefficient code is often easier to understand. Where can balance be found? Can it ever be found? Efficiency is often preferred by so-called ‘power users’, whereas others opt for simplicity. Consequently, when negotiating projects, either at code-level or when deciding on UI design, flame wars may arise among developers or avid users.

Let us consider code optimisation. If the programmer wants to go all the way, (s)he could optimise by shortening variables, removing excessive spaces, and stripping out newlines. In such circumstances, interpreted code will be quicker, albeit less meaningful when an error arises and goes verbose. This is nothing like bytecodes and JIT, but similar rules should apply.

Good code should be well-structured, easily-readable, elegant, and well-documented. If the code is compiled, all comments should definitely stay in tact rather than ever be stripped. Automatic documentation can fit nicely in the source rather than be generated and made peripherally available, e.g. via Web pages. The only exception is debugging ‘bits’, which could definitely slow down program execution. As long as the developer keeps the original and saturated version of the code public, however, nobody need get entangled in closed-source traps.

On to an exciting prediction, with lowered file sizes and optimised code, programs could scale better on Wi-Fi-driven Web servers which run on a PDA in one’s pocket. Such server must be properly taken good care of, as well as the Internet connection, which is as vital as that of a synapse. With the growth of smaller devices, the need for efficiency is better realised.

EARCHING of the Web is no exact science. If it was, its exhaustive exploration would be infeasible. The more formidable search engines amass information from million of Web sites, each containing huge lumps of information — both textual and media. That information, in turn, could be interpreted and/or indexed in a variety of different forms. Rarely is the content truly understood, which is my personal motivating for knowledge engines.

Mathematics and physics could be argued to be inexact sciences as well, at least when a variety of man-made, non-fundamental fields are introduced. Think of computer science, for example. Its fundamentals assimilate to this complex problem, which is searching the World Wide Web. It is associated with ad-hoc solutions. Computational theories which relate to Turing machines are not tractable enough to make a most correct and efficient algorithm ever crop up and stand out.

Don Knuth has written his popular series of books on the issues of correctness and efficiency in common algorithms. It proves an elegant reference to many computer science practitioners. Problems which are simple, such as element or number sorting, are still handled differently by different algorithms and their efficiency is dependent upon the architecture involved, the scale of the problem, and its nature. Search algorithms likewise, which is why they should be engineered differently depending on a number of key factors. Hence, judgement of the quality of search engines cannot be done objectively, but only ever be estimated using test cases and artificial scoring schemes.

Still, everyone wants to discover the perfect recipe to outperforming Google. Others try to reverse-engineer their algorithms and cheat (fame and riches owing to ‘Google juice‘ that is channelled to one’s site/s). Many of us continue favour and recommend Google, which brings the largest number of referrals to most sites in existence. There is a danger here though. Large search engines are the main target for deceit and they are easily confused by spam inasmuch as they are inclined to pick up rare and valuable content.

Quality of search is probably in the mind of the searcher and the result of hearsay — somewhat of a ‘cattle effect’. Even engines that spit out cruft might be defended unconditionally by their innocent users. This may lead the competition to forfeiting the battle and invest fewer resources (e.g. datacentres) in the attempt to catch up. Phrases like “Google it” do not help either as they promote a search monoculture at best.

Related item: Search Engines and Biased Results

NE of the deterrents to a publishing developer are support queries, which follow a premature or ‘half-baked’ releases. Maintenance of code and replies to support queries become a necessary evil. Then come the bug reports, the question, the requests and the complaints, which can truly be a handful.

Here is my humble perspective on ways to prevent a chaotic support-bound life:

• The amount of queries depends on the extent to which you encourage or enable people to contact you
• If everything is properly documented and explained, expect a quieter time
• Programmers are notorious for writing code quickly, but neglecting to do the rest, which is ‘housekeeping’. Document your code properly as if you address support queries before they have been summoned by angry users.

Many of us vehemently loathe support-related E-mails. My public E-mail address was excruciating yet self-maintaining feedback system. That is also where bugs get reported and projected back to the public.

HIS morning I found (and began playing with) a GPL‘d newsgroups statistics tool (homepage of the project). I compiled it from source code without the QT GUI and off I went experimenting. In case you choose to run that tool as well, there is an ample manual for its command-line mode.

I have reported a serious documentation bug to the author — a bug that cost me a fair bit of time. To quote the report, in case this helps somebody else:

In Turquoise 2.2, the help bit says:

Usage: turqstat [options] outputfile areadef(s)

Shouldn’t the ourputfile precede the [options]? It took me a very long
time to realise that.

Having run it successfully ‘off-line’, script invocation has been made a weekly cron job (i.e. a job which is scheduled to run repeatedly by a daemon). I decided that I can only post its output to forums where:

• My participation is noticeable and is decent
• My presence goes back a long time into the past
• The amount of involvement and activity is high, or else there is not much to gauge. Statistics become uninteresting otherwise.
• Nobody else generates statistics already

For the time being, I will generate and publish statistics for the search engines and Palm newsgroups only.

Consider reading this intersting article on the role and impact of Firefox extensions. Below is the foreword.

If you have any doubts about the source of innovation in information technology, you should look at the Mozilla web site. I just counted 1,028 extensions contributed by the community. Then take a look at the themes section. Even the colossus of Redmond with its billions of dollars hasn’t mustered that kind of development effort for IE from its community over the years. Now, let’s get familiar with underlying reasons.

Related items on Firefox extensions:

• Firefox Essentials
• Firefox FTP Client
• Firefox for Web Design
• Favourite Firefox Extensions