Just got my Rhino from Emperor Linux

After about 6 years of hesitation, I got a new laptop. The old one was getting embarrassingly slow. Given my past horrible experiences with Dell's customer service, I had decided to buy from another manufacturer. Then, I stumbled upon EmperorLinux which delivers Linux based laptops on top of laptops from Lenovo, Sony and Dell. When contacted, the salesperson at EmperorLinux seemed very knowledgeable and helpful, so instead of buying from Dell, I ordered my new laptop from them. It is a Dell Latitude E6550 rebranded as Rhino Linux.

In addition to a glitch on the graphics card, the laptop weighs 17% more than expected. Dell advertises the Latitude E6550 at 2.3 kg with a 4 cell battery and without an optical reader. According to the user manual, the 4 cell battery weighs .24 kg. The laptop actually delivered weighs 2.7kg, albeit with a 6 cell battery and without the optical reader, or 17% more than advertised. One might argue that the 6 cell battery weights more than a 4 cell battery. Well, the 6 cell battery weighs 325g, or just 90g more than the 4 cell one. After removing the battery, the laptop weighs 2.375 kg. In other words, the laptop actually delivered with its battery and optical reader removed, still weighs more than what is advertised by Dell (2.3kg) for the given laptop with a 4 cell battery.

So, either,

1) Dell builds their laptops on a planet with a different gravitational pull,
2) the laptop will loose weight after some exercise,
3) Dell makes false declarations about the weight of their products.

Page links with Wicket

The default urls created by Wicket do not look very nice. For instance, let IndexPage be the home page of our ShopApplication. Assuming shop is your application's context name and wicket the path where you mapped the Wicket filter, then by default, the url for the IndexPage will be akin to
http://somehost/shop/wicket/index?wicket:interface=:0:headerPanel:index2::ILinkListener::. I said ugly didn't I?

Wicket has a mechanism for prettifying URLs. In ShopApplication, you can instruct wicket to "mount" a page on a specific path. Here is the code.

public class ShopApplication extends WebApplication {
  @Override
  public Class getHomePage() {
    return IndexPage.class;
  }
  @Override
  protected void init() {
    mountBookmarkablePage("index", IndexPage.class);
  }
}

Wow, that was easy!

Now, assume you have a navigation panel, included on all the pages of your application, where you list links to the various pages of your application. Here is the markup:

<table cellpadding="0" cellspacing="0">
   <tr align="center">
     <td><a class="menuitem" href="index">Index</a></td>
     ... other pages
   </tr>
  </table>

We are referencing the mounted path "index" directly. How convenient is that? Although, convenient such references do not work correctly. The navigator will translate it into http://somehost/shop/index instead of the correct http://somehost/shop/wicket/index.

For bookmarkable links such as "index", Wicket offers the <wicket:link> tag instructing Wicket to to automatically create bookmarkable
link components for the links inside the tags. So let's try that.

<tr align="center">
  <wicket:link>
    <td><a class="menuitem" href="index">Index</a></td>
    ... other pages
  </wicket:link>
</tr>

The above is easy enough and will work, as long as all your pages are in the same java package.

Indeed, the <wicket:link> tag doctors url references with respect to the java page of the current page belongs to, but if the page is located in a different package, then the urls will be rendered incorrectly. Bummer.

So, we seem to be stuck. Googling for "wicket url mountBookmarkablePage" you will find an article by R.J. Lorimer on controlling Wicket URLs which did not go far in reducing my level of confusion. After further investigation, I found an example which caters for the use case we've been discussing so far, that is the nice-url example.

The nice-url example, after mounting the Home page as "/the/homepage/path", simply adds a BookmarkablePageLink to the Home class on another page, namely Page1. Here is the relavant code.

<a wicket:id="homeLink" href="#">[go back]</a>

public class Page1 extends WicketExamplePage {
  public Page1(PageParameters parameters)  {
    add(new BookmarkablePageLink("homeLink", Home.class));
  }
}

which magically works, in the sense that when the link for the url is rendered, it will somehow contain the mounted path "/the/homepage/path". How does BookmarkablePageLink know that Home is mounted on "/the/homepage/path"?

It does not know. Instead, it invokes the
urlFor(IPageMap pageMap, Class pageClass, PageParameters parameters) method defined in its parent class, Component. This method will in turn ask the request cycle the page is associated with to find the correct url. The request cycle will eventually go through all mount points, asking them whether they apply to Home.class. The first mount point which applies will then be asked to encode the Home page, returning the mounted path. The exact details might vary, but from a 100 feet point of view, wicket does reverse lookup to see which mount point maps to a given page which goes to explain the aforementioned magic.

IDEA open sourced

Coming across Cedric Beust's comments on IDEA going open-source, I thought I'd chime in. Cedric makes valid points, in particular about the unfulfilled expectations after open sourcing a product. As he points out, Jetbrains is unlikely to be flooded with patches and additions from the community, floating them back to the top.

Cedric also correctly identifies that open-sourcing software is an attempt to regain mind-share. He unfortunately qualifies the effort as "last-ditch" which is where I disagree. Companies have to make strategic decisions all the time. Companies live and die by strategic decisions. Who would have guessed 10 years ago that IBM would have survived its transition to services as decided by Louis V. Gerstner? Instead of "last-ditch", in my humble opinion "just-in-time" would be a better qualification for Jetbrains' recent decision.

According to scientific surveys conducted around a glass of beer, people who use IDEA on a daily basis absolutely love it. I am not one of them. But when a company enjoys such a dedicated following, it seems premature to predict its imminent doom.

As Cedric put it, I wish the best to IDEA. I really do.

How the US is burning the furniture without even realizing it

The US budget deficit has reached astronomical proportions. Admittedly, the same holds true in European countries. However, European economies attract less of the world's savings than the US does.

According to various sources, in 1945 only 10% of the US government's spending was deemed incompressible, in 2009 approx. 80% of government spending is qualified as such. Given that it is politically unacceptable to raise taxes, and given that by definition incompressible spending cannot be reduced, the US government needs to find alternative ways of reducing its deficit in order to keep the ballooning budget deficit under control. If not, the whole financial system is menacing to crumble. One politically cheap way to raise money is to go after tax evasion.

In the latest revision of the Greenbook, the Obama administration proposes new measures to track down and eliminate tax evasion. To keep it short, various financial institutions referred to as "Qualified Intermediaries", even if they are based outside the US, if they serve US persons or deal in US titles (shares and derivatives), are now required to abide by strict and cumbersome rules. For a bank and its clients based outside the US, it is increasingly impractical to deal in US titles or the US banking system in general.

In addition to the Greenbook, the Patriot Act makes it unpleasant to have a banking account in the US. For example, when a person living, say in Denmark, wants to transfer funds from her US account to an account in her name at her home town in the Denmark, she has to justify the transfer with a signed letter (email won't do). From the US view point this is justified by the need to combat terrorism. However, from the view point of that Danish person living in the Denmark, the administrative overhead is cumbersome at best, and plain ridiculous at worst.

For a country which in the past managed to attract 85% of world-wide savings, the Patriot Act combined with latest steps described in the Greenbook, carefully engineered to stop tax evasion under the "no escape" principle, instead of raising more money for the government, are likely to precipitate America's continued impoverishment.

The irony of it all is that various governmental actors are all acting rationally in the best interest of the US but the end result might well be a new world order with the US playing a lesser role.

GIT migration

A few years ago, I watched Linus Torwald's presentation on git. I was so thoroughly put off by his style that I did not give git another thought for several years, that is until recently. Hearing more and more about git, I recently raised the question of migrating the logback project to git on our mailing list and the ensuing discussion had me convinced.

Here is a recount of the steps I've taken to migrate logback to git from SVN.

First, I installed git on our Linux servers. Nothing newsworthy there. Gitosis' installation on those servers was equally uneventful.

Installing git on Windows was more of an ordeal. Supposedly, on Windows git is officially supported with cygwin, which I've been using daily for over 10 years. Git just did not work me with cygwin. Migrating to cygwin 1.7-beta was not much of a help. Fortunately, the msysgit project provides a solution for Windows.

The next step was to create a git repository from our existing SVN repo which was as easy as invoking "git svn --stdlayout --no-metadata -A authors.txt clone http://svn.qos.ch/repos/logback" where authors.txt is a file mapping login names to user names. The --no-metadata flag tells GIT to drop noisy references to the SVN url and other useless details.

My next step was to allow anonymous reading of the git repository, which as easy as starting git-daemon which was part of the core git package (installed by gentoo).

Git makes it very easy to fork projects. On github, you can track work done on forks, which was one of the arguments that convinced me to switch to git hub. However, pushing to github is slower than pushing to git.qos.ch, our dedicated git server. The idea is to push to git.qos.ch on a regular basis and to githib with lower frequency (say once a week). To add a remote server, the command is "git remote add github git@github.com:ceki/logback.git". Once github is added as a remote server, pushing to it is as easy as invoking "git push github master".

Now that the essential pieces are in place, the next step was to better understand git's philosophy by reading the Pro Git book.

After much of the initial migration was done, Jukka Zitting observed that the branches and tags which existed in the SVN repository were missing. Since I had removed the original git repo which was created from SVN, I had lost the branch and tag information. I had to re-import from SVN. Since the initial import contained metadata which I no longer wanted, my newly imported repository was incompatible with the earlier git repository containing new work but missing the tagging information. I did not want to waste half-a-day's work. I saved the new work with the ' git format-patch -o ~/patches/ 088f.." command, where 088f.. stands for the SHA-1 of my earliest commit since the SVN migration. Such information is very easy to obtain from the git.qos.ch and github servers.

The next step was to create the tags from the latest git repository. Since tags can be created a posteriori, all you need is the SHA-1 of the snapshot you want to tag. The "git for-each-ref refs/remotes/tags" does give you exactly that. Here is sample output:

a8f066010596dc.. commit refs/remotes/tags/SLF4J_1.3.0
260b5f6f9d0f14.. commit refs/remotes/tags/SLF4J_1.3.1
d8eadb09a11dbd.. commit refs/remotes/tags/SLF4J_1.4.0
7011d1f3665e88.. commit refs/remotes/tags/SLF4J_1.4.1
5fd428e3dd03ed.. commit refs/remotes/tags/SLF4J_1.4.2
04a8c2c2cf4230.. commit refs/remotes/tags/SLF4J_1.4.3

Which can be easily massaged into:

git tag -a SLF4J_1.3.0 a8f066010596dc -m "SLF4J_1.3.0"
...
...

Once the tags are created locally, they can be pushed remotely with "git push origin --tags"

The quest for an AC Adapter for my Dell laptop (Part II)

The UPS delivery person left an InfoNotice(SM) at our door step on Friday the 10th July. The InfoNotice contained a tracking number which could be used at the UPS web-site to change the parameters of delivery. One of the proposed options was to return the package to the sender, which I quickly selected. By returning the erroneous package, Dell would get their merchandise back, proceed to reimburse me and the matter would be settled.

I was quite surprised to find a second InfoNotice in my mailbox on Monday the 13th. I called up UPS to learn why my cancellation request had no impact. The UPS customer service representative explained that UPS had a special deal with Dell. Only Dell could cancel a delivery; the recipient, the end-customer in this case, was not authorized to cancel a delivery. I called Dell to ask them to cancel but was told that canceling policy was an internal UPS matter. When I explained that UPS had told me to call them (Dell) because they were the only party which was able to act on the matter, the answer was invariably: "it is an internal UPS matter, call UPS".

So I called UPS again to explain the situation. The UPS representative told me that Dell was purposefully denying their capability to resolve the matter because they did not wish to cancel the order.

Since I am at the office during the day, I asked UPS if I could change the delivery address to my office, which is one of the options explicitly mentioned on the InfoNotice. The UPS representative told me that only Dell could change the final delivery address.

To be continued...

The quest for an AC Adapter for my Dell laptop (Part I)

The AC adapter for my laptop from Dell recently had its cable severely twisted so as to stop charging the laptop. The adapter is marked as belonging to the PA-9 family. I called Dell technical support and explained the problem to a technician. I gave him the serial number of my laptop which identified both my laptop and the buyer (me). He said that they could ship a replacement adapter forthwith. I asked the technician several times to confirm that item he was sending me was a PA-9. He said that it was indeed, and that I had nothing to worry about.

A few hours later, I received a written confirmation for my order. Lo and behold, the order was for a Kensington 450-11303 an adapter for the cigarette lighter of a car. I immediately wrote back to cancel the order. When Dell support wrote back, they claimed that the order had already shipped and could not be canceled. Moreover, Dell was not willing to take any further action, such as recognizing their error, before the shipment arrived. I am afraid that their strategy for dealing with this issue will be to drag it on until I give up. Anyway, time will tell.

Biased Locking in Java SE 6.0

As a result of the ensuing discussion in response to this blog entry, it is now pretty clear that the issue described herein is not specific to Java SE 6. Please do not reach any conclusions without reading the entire post, including the comments, and especially the comments.

Joern Huxhorn recently informed logback developers that locking in Java SE 6.0 was unfair. Indeed, Java documentation regularly mentions that one should not make assumptions about Java's thread scheduler. For example, the last paragraph of Thread Priority on the Solaris™ Platform, states:

Likewise, no assumptions should be made about the order in which threads are granted ownership of a monitor or the order in which threads wake in response to the notify or notifyAll method. An excellent reference for these topics is Chapter 9, "Threads," in Joshua Bloch's book "Effective Java Programming Language Guide."

If you actually bother to read the book, in Item 51, Joshua Bloch writes:

When multiple threads are runnable, the thread scheduler determines which threads get run and for how long. Any reasonable JVM implementation will attempt some sort of fairness when making this determination.

While Joshua Bloch's statement above is specifically about the JVM scheduler, I think that the notion of "some sort of fairness" applies to locks as well. The general principle is the same.

Here is a small java application called LockingInJava which illustrates the locking behavior in question.

public class LockingInJava implements Runnable {

 static int THREAD_COUNT = 5;
 static Object LOCK = new Object();
 static Runnable[] RUNNABLE_ARRAY = new Runnable[THREAD_COUNT];
 static Thread[] THREAD_ARRAY = new Thread[THREAD_COUNT];

 private int counter = 0;

 public static void main(String args[]) throws InterruptedException {
   printEnvironmentInfo();
   execute();
   printResults();
 }

 public static void printEnvironmentInfo() {
   System.out.println("java.runtime.version = "
       + System.getProperty("java.runtime.version"));
   System.out.println("java.vendor          = "
       + System.getProperty("java.vendor"));
   System.out.println("java.version         = "
       + System.getProperty("java.version"));
   System.out.println("os.name              = "
       + System.getProperty("os.name"));
   System.out.println("os.version           = "
       + System.getProperty("os.version"));
 }

 public static void execute() throws InterruptedException {
    for (int i = 0; i < THREAD_COUNT; i++) {
      RUNNABLE_ARRAY[i] = new LockingInJava();
      THREAD_ARRAY[i] = new Thread(RUNNABLE_ARRAY[i]);
    }
    for (Thread t : THREAD_ARRAY) {
      t.start();
    }
    // let the threads run for a while
    Thread.sleep(10000);
    
    for (int i = THREAD_COUNT - 1; i >= 0; i--) {
      THREAD_ARRAY[i].interrupt();
    }
    Thread.sleep(100); // wait a moment for termination, too lazy for join ;)
  }

  public static void printResults() {
    for (int i = 0; i < RUNNABLE_ARRAY.length; i++) {
      System.out.println("runnable[" + i + "]: " + RUNNABLE_ARRAY[i]);
    }
  }

  public void run() {
    for (;;) {
      synchronized (LOCK) {
        counter++;
        try {
          Thread.sleep(10);
        } catch (InterruptedException ex) {
          break;
        }
      }
    }
  }

  public String toString() {
    return "counter=" + counter;
  }
}

When run under Sun's JDK version 1.6.0_11 on a 64bit Dual Core AMD Opteron running Linux, here is what gets printed on the console.

java.runtime.version = 1.6.0_11-b03
java.vendor          = Sun Microsystems Inc.
java.version         = 1.6.0_11
os.name              = Linux
os.version           = 2.6.25-gentoo-r6
runnable[0]: counter=1002
runnable[1]: counter=0
runnable[2]: counter=0
runnable[3]: counter=0
runnable[4]: counter=0

Notice how only the first thread gets any work done. All the other threads are completely starved while waiting for the lock. The same application run with JDK 1.5 or older will have much more uniform results. Some threads will get more often access to the lock than others, but all threads will get some access. With JDK 1.6, access to locks is dispensed in a biased fashion. In other words, the thread currently holding the lock will always be favored compared to other competing threads. Sun calls it biased locking. It purportedly makes better use of CPU capabilities.

As for the argument about no guarantees offered about fairness, while true in letter, it is invalid in spirit. The argument is too punctilious and formalistic. Any developer reading the documentation will naturally assume that while there are no guarantees, the synchronization mechanism will not actively impede fairness.

Biased locking, as introduced in JDK 1.6, will affect thousands of unsuspecting applications. The fact that the bias is intentional does not make it less damaging. It's still a bug.

The Earth having an indigestion

We humans share a very flawed sense of proportion. We tend to consistently underestimate the relevance of certain events and overestimate others. Social psychologists refer to the general phenomena as cognitive bias.

Environmentalists stay awake at night worrying about global warming. One of the worst-case scenarios of global warming involves the release of methane, a greenhouse gas 21 times more potent than CO2, currently trapped under the sea. Recent studies reveal that thawing lakes of the northern hemisphere are releasing methane at an alarming rate. The more Earth temperatures increase, the more frozen lakes and permafrost thaw, the more methane is released into the atmosphere, the bigger the greenhouse effect, the more Earth temperatures rise. This vicious cycle, if unchecked, could wipe out most rainforests, destroy the fertility of many soils and leave the Arctic ice-free even in midwinter. Entire regions will become uninhabitable. Depending on where you live, your country might enter into a war with a neighboring country over fresh water resources.

Study of ice cores from Greenland and Antarctica show that increases of methane concentrations have occurred the past. According to the anthropic principle, given that life exists on Earth, especially in the form of Homo sapiens, conditions on Earth must be amenable to carbon-based life forms, including us. However, as anyone involved in the stock market knows, past performance is no guarantee for the future. Indeed, the Earth has sustained life for millions of years, however, that is no proof that it will necessarily continue do so in the future.

How is it that we don't seem to worry more about the environment? Is it because the problem is too big to lay on our frail shoulders? Is it because we lack proof about the impending catastrophe? Is it because of insufficient media coverage? Is it because we subconsciously know that, like our own death, Earth's demise is inevitable, so we don't wish too waste time worrying about it? What are the cognitive biases that we need to overcome in order to react more effectively?

Burrowing Animal as defined in R&A Golf Rules

The R&A takes its name from The Royal and Ancient Golf Club of St Andrews, which has continuous records dating back to its foundation in 1754. The first thing that struck me about the R&A rules booklet was its length, over 200 pages (French edition). The rules are presented in a dense and legalistic language. For example, here is the definition of "Burrowing Animal"

A "burrowing animal" is an animal (other than a worm, insect or the like) that makes a hole for habitation or shelter, such as a rabbit, mole, groundhog, gopher or salamander.

Note: A hole made by a non-burrowing animal, such as a dog, is not an abnormal ground condition unless marked or declared as ground under repair.

According to the Rules (25-I), if your ball falls into a hole dug by a rabbit, you are entitled to relief (lift your ball and drop it outside the hole), but not if the hole is dug by a dog. A hole is hole is a hole, but apparently not in Golf.

What about the groundhog? Clearly, since the groundhog lives in the burrow, it must be considered as a burrowing animal. So, if your ball falls into a hole dug by a groundhog you are entitled to relief according to rule 25-I.

Now, let us consider the case of the biological family of the Suidae to which pigs, hogs, and in particular wild boars belong. Although common in many regions of the world, including France, the wild boar became extinct in Great Britain and Ireland by the 17th century. Surprisingly enough, wild boar are known to dig holes for shelter and thus are burrowing animals in the sense of the Rules, even if no member of the Suidae family is mentioned in the definition of burrowing animal above, presumably because there are no wild boars in Scotland where R&A is located.

Having established that the wild boar is a burrowing animal, consider the case of a golf course nuzzled by wild boar in search of food, a common occurrence in France as attested by a google image search for "boar golf terrain" (in French). The damage caused by wild boars in search for food can be rather extensive. I have seen areas over 50 square meters damaged by wild boar as if ploughed through by a tractor.

Given the sheer size of the ground nuzzled by wild boar, it is almost certain that your ball will eventually fall into nuzzled ground. The question whether you are entitled to relief according to rule 25-I. You might argue that wild boar are burrowing animals and consequently rule 25-I applies. However, it might also be counter argued that wild boar are not widely known to be burrowing animals. Moreover, wild boar plough the terrain in search of food and not shelter. Let us just say that the applicability of 25-I is questionable in case of damage caused by wild boar.

Some Golf rules can be combined together to make a deliciously confusing cocktail. Consider the case of Rule 3-3 It states that "in stroke play, if a competitor is doubtful of his rights or the correct procedure during the play of a hole, he may, without penalty, complete the hole with two balls."

The rules do not mention the case of multiple invocations of rule 3-3. Can a player complete a hole with 3, 4 or even more balls and still comply with the rules?

Given that there is no upper bound to the number of provisional balls that a player can play (Rule 27-2), given a recurring ambiguity associated with provisional balls, e.g. your provisional balls falls into ground dug up by wild boar, in theory (ignoring time restrictions) there is no limit to the number of balls with which a player may complete a hole. There are of course physical limits.

According to Appendix III, that weight of a ball must not be greater than 46g. Assuming that all matter on earth is transformed into golf balls, and a giant player, e.g. Atlas, capable of carrying the equivalent of the Earth in golf balls, a Titan could complete a whole with 10^26 balls, that is roughly the equivalent of the debt (in Indian Rupees) we are leaving to the next generation.

Selling a car in Switzerland

Like most people, I have an uncanny tendency to be generous in criticism and frugal in praise. However, I think that the vehicle registry system in Switzerland, compared to neighboring countries, is so simple and well designed that it merits a few paragraphs of kudos.

Every car in Switzerland needs to be registered with the Vehicle Registration Service (VRS). As proof of such registration, the car owner gets a card colored in gray, called the "gray card". If and when the police stop a car, they always ask for the driver's driving license and the vehicle's gray card. The VRS will deliver a gray card for a given vehicle if and only if the vehicle is insured for damages caused to third parties. Anyone can register any car; all you need is an insurance certificate. In particular, you don't need proof of ownership.

License plates are the personal property of the owner with a distinct lifecycle than that of the vehicle. For example, when you unregister a vehicle by depositing the gray card at the VRS, you can keep the license plates! Moreover, your registration is still valid until midnight of the same day. Why does this matter?

Well, it matters because it allows for very a smooth procedure for selling or purchasing cars. Given a signed sales contract, as the owner or a representative of the owner, you can unregister a vehicle at the VRS, deliver the car to its new owner located anywhere within a day of driving range, pocket the agreed sum of money, unscrew the license plates from the car and drive home (in another vehicle). At no time is there overlap in the responsibility of the car owners. The fact that anyone in possession of the gray card can unregister a vehicle simplifies things to a large degree. A friend or your friendly neighborhood garage can perform all registration operations at the VRS on your behalf.

Considering the complexity of the issue, and the broken practices of other countries, Switzerland is a shining and rare example of an efficient bureaucracy. I mean efficient in the sense that it efficiently renders a service to the public. Other bureaucracies seem to be efficient at perpetuating their own existence.

Indoctrination and anger

The front page of every single European newspaper carries news about Israeli military operations in Gaza. At best the titles talk about a military "offensive" and at worst about "crimes against humanity".

While most reasonable people will grant Israel the right of self-defense, at least in principle, there seems to be an emerging consensus about the disproportionality of Israel's reaction. Undeniably, the victims on the Palestinian side vastly outnumber the number of Israeli victims. Without trying to minimize the loss of human life, innocent or not, illegitimate as well legitimate use of force is usually disproportionate. Let us not forget that each of the rockets fired at Israeli cities, is nothing less than an unsuccessful murder attempt. When nations are under serious threat, they react with whatever force they have got. Had the Russians been subjected to the same threats as Israel, they would be no Gaza to talk about. It would have been leveled to the ground as was the case in Chechnya and more recently but to a lesser extent in Georgia.

There are those who assert that the recent violence plants the seeds of hatred for future generations. But as Bret Stephens points out, how is a two-state solution is supposed to come about by allowing Hamas to rule half of a presumptive Palestinian state?

Still in "The Wall Street Journal", Zeev Maghen writes about the difference between hate and indoctrination. Of the thousands of articles on the Middle East I have read in the past 20 years, it is probably one of the best, chillingly so.

Is Apache a meritocracy?

Yes, it is, but in my humble opinion, not consistently.

Apache defines itself as a meritocracy. At the same time, the foundation's mission statement includes references to "collaborative software development". If I had to reduce the ASF into a single word, it would be collaboration.

The ASF is exemplary in the way it welcomes newcomers. Users are encouraged to post questions, however trivial, and developers are encouraged to make contributions, however minimal. The ASF culture is about openness and collaboration. Participation, even critical, is welcomed.

In his description of the ASF, Lars Eilebrecht talks about the chain of merit. A person is fist a user of software developed by a given Apache project, then becomes a committer, and later Project Management Committee (PMC) member, and usually after several years of devoted service, an elected member of the ASF. Thus, the "ideal" career path at Apache is user, committer, PMC member and ASF member.

In majority of cases, a project committer is usually also a PMC member. So, committer status is accompanied with voting rights. The said voting rights include veto power. If for any given decision, a committer votes -1 (a veto), then a 3/4 majority is required to override that veto. Given that a -1 vote effectively shuts down any proposal, most committers are very reluctant to use their veto rights. However, some committers not realizing the destructive power of their veto, make cavalier use of it.

Certain projects have an imbalanced committer structure, with one highly active developer, usually the project founder, accompanied by several less active committers. In such a project, given the 3/4 majority rule, it is entirely possible for a new and highly self-confident committer to bring a project to its knees by simply vetoing (or hinting at veto) new proposals. This deadlock can easily become permanent if the dissenting new committer can gain the support of just one additional other committer.

Had the Apache model been a completely fair meritocracy, a very active developer would have more voting power than a much less active developer. However, if the active developer dares to mention that he (or she) is more active, then, according to the currently prevalent ASF culture, he will loose a great deal of credibility. At present time, hinting at "leadership" or extra-merit is a socially unacceptable attitude at Apache. In other words, within the bounds of a single project and its associated group of committers, not only Apache is not a meritocracy, it involuntarily promotes a situation which can be described as "representation without taxation", a tongue-in-cheek reference to the slogan emblematic of the American Revolution.

In defense of the Apache model, I should observe that it is very simple. Treating everyone equal is the simplest representation model imaginable, and in case you had any doubts, simplicity is a highly desirable characteristic to have. The perfect equality in addition to veto powers gives everyone ample representation power, thus encouraging participation. As a committer, you cannot reasonably say "Why should I vote? My vote does not count." Nevertheless, the fact that a committer's representation powers does not increase proportionally with his contributions is cause for concern.

Do you think you can come up with a better model? If you do, I welcome your proposals describing social mechanisms where one's representation powers are adjusted according to one's contributions.

Interest in logback

One of the niceties of open-source development is that once in a while people will make valuable contributions. By valuable contribution, I mean code that shows intimate knowledge and understanding of the software. In my estimation, in the log4j project, we got one valuable contribution every semester, roughly speaking. In my astonishment, in the logback project, log4j's successor, we get a valuable contribution every two weeks, again roughly speaking.

I really can't explain it. Log4j has more users than logback. So it is definitely not the size of the user-base. You have two similar projects. They have similar code bases and similar architecture. Log4j is much better known, yet it is logback that gets the more frequent contributions.

Logback is newer, and has not reached 1.0 status, so perhaps developers feel more confident that their input will be acted upon. Also, logback is functionally richer so it may be more attractive to contributors. It may also be just luck, although given the nature of independent random processes I doubt it.

HTH or HTT?

Assuming we've got a long random string composed of the letters H and T, and only those two letters, which of the patterns "HTH" or "HTT" (overlap not allowed) do you think will occur more frequently?

For example, if overlap is not allowed, in the string "HTHTHTTH", both "HTH" and "HTT" occur once. However, if we allow for overlap, then "HTH" occurs twice and "HTT" once.

So, the question is, which of the patterns "HTH" or "HTT" (without overlap) do you think will occur more frequently? Will "HTH" occur at a higher, the same or lower frequency than "HTT".

You must give an answer.

To find out the answer run the Simulation application written in Java.

This question is an adaptation of the question asked by Peter Donnelly in his TED presentation on "How juries are fooled by statistics."

Subversion+Eclipse on Linux

I usually develop on Windows on a fairly fast PC. However, our continuous integration server runs on Linux. For some reason, some tests were failing intermittently on the integration server. Now, since the integration server was heavily used by other processes and the tests in question were time-sensitive, the next step was to fix whatever bug there was by developing on the integration server. This just shortens the patch+test cycle.

Installing Eclipse Ganymede on this Linux machine was a breeze. Everything just worked out of the box. Well, not everything. SVN integration was missing. Installing Subclipse did not work nor did Subversive, at least not until I stumbled upon Basilikk's blog entry on Eclipse 3.4 Ganymede and Subclipse 1.4.

The critical paragraph was:

The second alternative is to also install the SVNKit adapter. This immediately causes Subclipse to work, there is no need to uninstall the JavaHL adapter. Downside of this of course is that you are using a beta version of the adapter. Hopefully there will be a final version of this adapter and an update to Subclipse 1.4.x to include a stable SVNKit soon.

In short, selecting the "SVNKit Adapter" during the usual installation of Subclipse worked as a charm.

Android, the next big thing

While clients all over the world are lining up to buy iPhones, the next big hit make come from Google, in the form of Android. The iPhone is a tightly controlled platform whereas the Android platform is open. This difference may be deemed too geeky to make a difference. I beg to differ.

When people realize that they can make VoIP calls using nearby WiFi networks for free, or VoIP-to-PSTN calls for 20th of the current price, they'll go berserk.

There are two ingredients missing for this scenario to become reality. First, there must be an Android phone that people can buy off the shelf. Second, people need to start sharing their WiFi networks. This is not happening, or nearly not fast enough. Our minds are imprisoned by the notion that bits are scarce. Bob Frankston argues why this is the case but should not be.

Putting a face on evil

Samir Kuntar is the perpetrator of a truly gruesome act of violence committed almost 30 years ago. He was released yesterday, on July 16, 2008 as part of a prisoner swap between Israel and Hezbollah. While the negotiations leading to his release are the subject of controversy, I am also quite concerned and shocked by the hero's welcome he received in Lebanon. The guy murdered a little girl with the butt of his rifle, not exactly the kind of person you'd want to root for, especially not in a mass rally.

For me, he represents the face of evil. His nazi salute of the crowd (see photo) just clinches it.

Taking a step back, Sun Tzu said All warfare is based on deception." This general principle also applies to the Arab-Israeli conflict. Since 1974, the political and psychological aspects of the conflict have tremendous importance, perhaps even more than purely military considerations. Appearing as murderous fanatics on world TV is probably the last thing you'd want to do in order to win the hearts of minds of the wider public. What may seem like a Hezbollah victory today, may be viewed very differently tomorrow. This reminds me of a Zen Master story mentioned in the movie "Charlie's War".

Do you know the story of Zen Master and the little boy?

There was a little boy. On his 14th birthday, he gets a horse. Everybody in the village says "how wonderful, the boy got a horse" and the Zen Master says "we'll see." Two years later the boy falls off the horse and breaks his leg. Everybody in the village says "how terrible" and the Zen master says "we'll see." Then, a war breaks out, and all the young men have to go and fight. The boy can't because his leg is all messed up. Everybody in the village says "how wonderful" and the Zen Master says...

The iPhone this, the iPhone that

The new iPhone will be available for sale in Switzerland starting tomorrow. The local press is abuzz with the news. They claim that the iPhone is easy to use, the icons highly legible, the screen wider than the competition, its 3G technology allowing high-speed access to the internet. The iPhone this, the iPhone that.

But, no mention of Skype+iPhone integration. As a reminder, I carry around a telephone to transmit and receive sound, more precisely the sound of voice, mine and the person talking to me. Call and get called, without budgeting a second rent, is what I want from my phone. The ubiquitous Wi-Fi, plus Skype/iPhone combination would give me just that.

Unfortunately, it is not possible to run Skype over the iPhone. Sigh.

If you are looking for a start up idea, I've got one for you: build a phone based on Linux (or Windows), specifically designed to run Skype. I'd buy one, so would the rest of the planet.

Fighting spam with open-source tools

Being on many publicly accessible mailings lists exposes one's email address to spammers. So it happens that I receive a hefty amount of spam, i.e. 400 to 500 messages per day. Believe me when I say that pressing the "del" key for 15 minutes is not a good way to start a day.

Over the years I have tried several methods of varying complexity in order to cope with the scourge of spam.

We host our own email server. It uses Postfix. Postfix supports three strategies for filtering content. Initially, the "before queue, external" strategy seemed the most attractive to me. However, most of the examples on the web are based on the "after queue, external" strategy. So I decided to follow recipes found on the web for integrating SpamAssassin and postfix. Actually, the basic integration example found on the spamassassin wiki is an excellent start. Once you've got the basic version working, a simple variation thereof gives you the ability to quarantine messages. If you are not satisfied by just following recepies but would like to understand how the various pieces fit together, then you should read "Fighting Spam and SpamAssasin and Postfix".

Being essentially a rule engine, SpamAssassin can be integrated with other spam-fighting tools such as DCC and Razor. Given that we use Gentoo as our Linux distribution, for us this was easy as issuing the following two commands as root:

emerge mail-filter/razor
emerge mail-filter/dcc

I then had to change the following two lines in the /etc/spamassassin/local.cf file, from:

use_razor2  0
use_dcc  0

to:

use_razor2  1
use_dcc  1

SpamAssassin assigns a score for each message it filters. SpamAssassin was configured to consider messages with scores 6.0 or above as spam. Such messages have their subject lines modified to contain "**** SPAM ****" as a prefix. SpamAssassin, or any spam-figting tool, may incorrectly identify a legitimate message as spam. Such occurrences are called false positives. They must be avoided, unless you don't mind loosing legitimate correspondence.

To reduce the probability of false positives, we adopted a two pronged strategy. Messages high spam scores, 9.0 and above, are quarantined in a special directory accessible only to the system administrator. They are not delivered to the mailbox of users. However, messages scoring "low", between 6.0 and 9.0, are still delivered to the user, with "**** SPAM ****" added to the subject line. With most email clients, e.g. Thunbderbird, it is rather easy to create a filtering rule which automatically moves messages with a subject line containing "**** SPAM ****" to a special SPAM folder. We thus give the user an opportunity to double check low-scoring spam messages before deleting them.

With this configuration and in the last 24 hours, SpamAssassin has quarantined 700 messages as spam (scores of 9.0 or above) for our whole site. My own various mailboxes received 50 low-scoring spam messages. Since such messages are filtered automatically, I am not distracted by them. Only 30 messages reached my mailbox in pristine form, of which 20 were legitimate and 10 were spam. This is such as huge improvement over the 20 spam to one legitimate message ratio we had previously.

For the next couple of weeks I will be looking at the high-scoring quarantined messages to check whether legitimate messages were mistakenly identified as spam (false positives). I am happy to report that there were no false positives in the 700 high-scoring messages nor in the 50 low-scoring messages.