The PLO Irresponsibility

I've never thought the governing parties of the Arab world have reached this scary level of incompetence and deficiency. I'll let this paragraph from Swisher's book about the November 2000 Camp David Summit speak for itself:

"But not all the fault could be shouldered by the United States and Israel. At the beginning of 1999, there were hardly any Palestinian lawyers representing the PA in negotiations; this was an astounding deficiency, given the complexities of the issues and the impact any results would have on the lives of future generations of Palestinians. Mahmoud Abbas, known by his patronymic, Abu Mazen, held a law degree but had never practiced as an attorney. Many within the PA leadership including Arafat has disrupted their university education years earlier, when they devoted their lives to becoming revolutionaries in the PLO. Improvising became a signature trait, even at crucial stages of diplomacy: Palestinians would often arrive at complex negotiations with little but scribbled notes and scratch pads. Their preparation was no match for the Israelis who were well funded and well organized. Israeli delegations usually comprised legal advisers, academic strategists, and professionals from the military and intelligence echelons. As one veteran observer of these discussions described, the PA often showed up at meetings still trying to define their rock-bottom positions, while the Israelis sat patiently with laptop computers and CD-ROMs containing well-developed, intricate plans and fallback positions for each scenario. When the time to put forward a definitive Palestinian position on final-status issues appeared on the horizon, the Palestinians realized the need to improve their own competency ..."

A new direction ..

For a long time, this blog has focused only on Unix related information which is very limiting at best. I think it's time to change, especially cause I've been focusing on a number of other fields as well.

A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. -- Robert Heinlein

Sorry .. You Should Not See My Google Search Query

Privacy is everyone's right and you must not be a criminal for assuring your privacy. Imagine the following scenario:

1- You have a good business idea in mind
2- Naturally, you search Google or Yahoo! for your business idea to see if it's already implemented. If a business implementation exists, you are usually interested in their business growth and venture capital.
3- You find a company that only implements the not-so-new part of the idea
4- Bingo, your future competitor logs include your business thoughts. Bad, isn't it?

Unfortunately, this happens everyday cause of the HTTP Referer header. It's done in the web protocol for the web servers' good, but in situations like above, it's not really desirable. Sniffing the network traffic of a Google search query = 'Good Idea' reveals the details:

1- Here is the search query going to the Google servers as a GET request:
GET /search?q=Good+Idea&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a HTTP/1.1
Host: www.google.com
...

2- Once you click on one of the results, Google lets you hit its servers once more to know which answer you've already chosen:
GET /url?sa=t&ct=res&cd=1&url=http%3A%2F%2Fcoaches.aol.com <-- cut -->
Host: www.google.com
Referer: http://www.google.com/search?q=Good+Idea&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a
...

3- After collecting the needed info to improve its algorithms, Google servers send us a redirection message to let the browser go to the original website URL:
HTTP/1.1 302 Found
Location: http://coaches.aol.com/business-and-career/tamara-monosoff/invention-good-idea
Cache-Control: private
...

4- Our client/web-browser follow the received redirection message and send an HTTP request to the wanted result URL. While doing so, it resends all the headers sent at step 2, including our unwanted Referer header that includes our Google query:
GET /business-and-career/tamara-monosoff/invention-good-idea HTTP/1.1
Host: coaches.aol.com
...
Referer: http://www.google.com/search?q=Good+Idea&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a

5- Unfortunately, by now, possibly your query is stored in your competitor logs. The above situation occurs for every link you click on from the Web search results page :-(.

Protection:
The Referer header is usually used by servers to know what their visitors are searching for, thus being able to improve the website content and to know the content that really matters. Although of all above good, and if you still want to disable this header as I do, you can simply configure Firefox to do so by typing the 'about:config' URI and then by setting the 'network.http.sendRefererHeader' variable to zero.

Final Note:
It's already understood that Google queries are sent in plain text and is seen by every hop/router from you to Google (including any government-monitored sea-bones) and naturally by Google itself, but at least, it's not sent directly to your future competitors :).

Long Story Short: The old x86-32 Linux 1GB Memory limit problem [*]

You'll find lots of articles around the internet discussing the old 1GB Linux i386 memory limit, but I found no one that presents the problem in a short and direct manner. I hope below four points can fill this gap:

The usual programming practice is that every address points to a single byte, changing this means changing lots of current programs core code and algorithms. --> (1)

The 4GB address space needs to be shared between user-space and kernel space. If it wasn't shared, as in Ingo Molnar's 4G/4G patch, a TLB flush would occur for every transition from user-space to kernel space. --> (2)

The usual split was 3GB for user-space and 1GB for kernel-space. This means the kernel can not map more than 1 GB of virtual memory addresses in its Page Table Entries. --> (3)

Each memory dereference in an x86 protected-mode processor passes through its MMU unit, so to access a memory frame, a translation must exist from a virtual address to the frame's physical address. --> (4)

From (4) and as said, in (3), we only have 1GB of available kernel virtual addresses. Thus, the kernel can not access more than 1 GB of memory.

(*) Speaking of kernels with no HIGHMEM support enabled.