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, to 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.