weBLOGic

Official binary releases from the Mozilla Corporation by default do not render Indic fonts correctly. The reason is official binary release is not compiled with pango support. Pango is a font rendering engine with focus on l18n. The pango layout engine is basically designed in context with gtk+ widget toolkit. Pango works on multitude of platforms like Linux, MacOSX and M$.

Most of the Indic scripts fall under Complex Languages which require special rendering. To enable this under Firefox we need to recompile the source with just one extra option i.e. –enable-pango.

Marathi (Devnagari) fonts rendered by official binary release is shown in image below.

Marathi fonts rendered by custom built Firefox is shown in image below.

You can clearly see the difference in font rendering.

Download and build Firefox

To compile Firefox, download firefox source from mozilla.org after selecting source directory under appropriate version (2.0.0.5 in this case). The source itself is 35 MB, after bunzipping it expands to whopping 345 MB.

tar xjf firefox-2.0.0.5-source.tar.bz2
cd mozilla

Next step is to create a configuration file. There is a utility for building configuration file (called mozconfig) from Mozilla located here, which makes life a little easy.

It is better to create mozconfig file which include existing build options. You can view the official binary release build option by typing about:buildconfig in address bar of official release Firefox. Below are build options used for binary release:

–enable-application=browser –enable-update-channel=release –enable-update-packaging –enable-official-branding –disable-debug ‘–enable-optimize=-Os -freorder-blocks -fno-reorder-functions -gstabs+’ –disable-tests –enable-default-toolkit=gtk2 –enable-xft –disable-freetype2 –enable-svg –enable-canvas –enable-static –disable-shared

As can be seen here official release Firefox is not compiled with pango support. As you can see, this build is going be static with just one extra option i.e. –enable-pango. The mozconfig file created for custom compilation looks like the one shown below:

# Options for client.mk.
mk_add_options MOZ_CO_PROJECT=browser
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/ff-opt-static

# Options for ‘configure’ (same as command-line options).
ac_add_options –enable-application=browser
ac_add_options –enable-update-channel=release
ac_add_options –enable-update-packaging
ac_add_options –enable-official-branding
ac_add_options –enable-pango
ac_add_options –disable-debug
ac_add_options ‘–enable-optimize=-Os -freorder-blocks -fno-reorder-functions -gstabs+’
ac_add_options –disable-tests
ac_add_options –enable-default-toolkit=gtk2
ac_add_options –enable-xft
ac_add_options –disable-freetype2
ac_add_options –enable-svg
ac_add_options –enable-canvas
ac_add_options –enable-static
ac_add_options –disable-shared

Please note that in above file I have used –enable-official-branding which makes use of all the trademarked logos while building. However, you should not use this if you are planning to distribute binary, unless you have obtained express permission from Mozilla. Read Mozilla Licensing Policies. As long as you are building it for yourself, you can use anything you want.

Assuming your Mozilla source is in mozilla directory, you can keep this file in this top level source directory with name .mozconfig as a convension. Actually you can keep this file anywhere and export a shell environment variable MOZCONFIG pointing to an absolute path to this file. But this is volatile.

I personally prefer to keep it in top level source directory and export path as a precautionary measure. Next is to issue make command.

export MOZCONFIG=/absolute/path/to/mozilla/.mozconfig
make -f client.mk build

While compilation process is on, you can get caffeinated enough so you can stay up for further tests. On my Celeron 1.7 GZ laptop with 768 MB memory it took freakin 2.5 hours to finish compilation. Most of the compilation is CPU hogging, with constant average CPU usage nearing 95%. This sent load average on my machine to a soaring 4 to 7. Most of the compilation time I had a table fan spinning in full swing facing my lappy as it started heating up like anything in first few minutes itself.

Only last step where it binds some big object files together and finally the firefox-bin binary is memory intensive. It took most of my available memory and all of the CPU bringing other tasks on lappy to a screeching halt.

Big Phat Warning: The official document states that it requires 1.5 GB disks pace for static and XULRunner builds, mine took 2.7 GB. So keep at least 3 GB of disks pace free on the partition where you are compiling Firefox. You WILL run into troubles if its your root partition with /tmp on it and is filled to the brim.
Initially I had just 2 GBs of disk space free on root partition. I thought it would work but did not consider the disk space used by /tmp and space used by sources. Obviously in first try it failed due to lack of disk space. Next I freed up some more space. After everything was compiled properly it took around 2.7 GB of disk space.

After the compilation is complete you can test the new build by running file /absolute/path/to/mozilla/ff-opt-static/dist/bin/firefox. Once you are satisfied with the new build, you can create a tar file which then you can copy on any location you want and run from there. This can be created by running command

make -C ff-opt-static/browser/installer

This would create file firefox-2.0.0.5.en-US.linux-i686.tar.gz in mozilla/ff-opt-static/dist/ directory. That completes building Firefox from source.

The memory footprint did not change for custom built Firefox compared to that of official release. Being static build, memory footprint is rather large (34MB resident and around 14 MB shared) compared to other applications. Its same for official release as well as custom build. I am yet to detect any memory leaks in my build.

Most of the documentation you can find on developer.mozilla.org.

If you connect fat32 usb mass storage device your machine under Debian etch, it won’t automount. The reason as specified is “The vfat file system does not yet fully implement sync-mounting.” So if you want it to automount, you simply need to add “vfat” to the FILESYSTEMS variable in configuration file /etc/usbmount/usbmount.conf.

My file /etc/usbmount/usbmount.conf looks like this (only relevant part):

FILESYSTEMS="ext2 ext3 vfat"
MOUNTOPTIONS="sync,noexec,nodev,noatime"

It was a child’s play to configure Linux for GPRS. There was hardly anything considerable I did to get it working. I connect using my mobile, Nokia E50 with Nokia Connectivity Cable (data cable) CA-53 on my historic laptop Acer TravelMate 240.

Before I start, about my system:

Hardware: Acer Travelmate240 with 2.4 GHz Intel Celeron and 768MB memory.

OS: Debian GNU/Linux, Kernel 2.6.8-2-686 (precompiled, from Debian apt system)

So this is how it goes. I connected my USB connectivity cable CA-53 that came bundled with E50. As soon as I connected mobile to the cable, phone poped a message on its screen as shown in the image below.

I selected cancel here. If you select OK, it will treat it as a USB storage media. At this time dmesg registered messages as shown below.

usb 3-1: new full speed USB device using address 7
scsi2 : SCSI emulation for USB Mass Storage devices
Vendor: Nokia Model: E50 Rev: 1.0
Type: Direct-Access ANSI SCSI revision: 02
SCSI device sda: 2011917 512-byte hdwr sectors (1030 MB)
sda: assuming Write Enabled
sda: assuming drive cache: write through
/dev/scsi/host2/bus0/target0/lun0:
Attached scsi removable disk sda at scsi2, channel 0, id 0, lun 0
USB Mass Storage device found at 7
usb 3-1: USB disconnect, address 7
scsi2 (0:0): rejecting I/O to dead device
SCSI error: host 2 id 0 lun 0 return code = 4000000
Sense class 0, sense error 0, extended sense 0

As you see, the device is detected correctly and it has also detected my 1GB microSD card.

Next, it poped a screen asking to select mode. Here I selected “PC Suite” as shown in image below.

At this stage dmesg showed following messages:

usb 3-1: new full speed USB device using address 3
drivers/usb/class/cdc-acm.c: Ignoring extra header
cdc_acm 3-1:1.10: ttyACM0: USB ACM device
usbcore: registered new driver cdc_acm
drivers/usb/class/cdc-acm.c: v0.23:USB Abstract Control Model driver for USB modems and ISDN adapters

As can be seen from these messages, mobile phone is detected as v0.23:USB Abstract Control Model driver for USB modems and ISDN adapters. It also registered the drivers for our device. The line

cdc_acm 3-1:1.10: ttyACM0: USB ACM device

shows that our device is detected as ttyACM0. It means it is placed under /dev/ttyACM0.

Next, since I was not using my built in modem, I did not have a /etc/wvdial.conf file. So I created a /etc/wvdial.conf file with following contents:

[Dialer Defaults]
Init1 = AT+CGDCONT=1,”IP”,”airtelgprs.com”
Modem Type = USB Modem
Phone = *99#
Password = “”
Username = “”
Modem = /dev/ttyACM0
Baud = 460800

In this file, first line is an initialization string. You can obtain this string from your GPRS service provider. If you are lucky and the help desk guy/girl not clueless, you will get this info. In India, my service provider is airtel. Fortunately in the second call to helpdesk, I found the right guy who had a clue about what Initialization string is :). So armed with this info, it is really trivial to write a configuration script.

In connect string, the part after equals sign, i.e. AT+CGDCONT=1 can be different. “IP” is the IP which will be dynamic mostly. Next is the Access Point Name*, which, in my case is “airtelgprs.com”.
Next line specifies a name for this modem, which can be any arbitrary name you want. Third line specifies the number to dial, in my case it is *99#. You have to obtain this from your service provider. For my network username and password is blank. But wvdial does not like blanks. So you need to supply something there as I did, an empty string. The line starting with “Modem” specifies where our device is located. You can keep the Baud rate as it is.

Next I ran the command wvdial in a shell. Here are the messages from wvdial:

swordfish:/etc# wvdial
–> WvDial: Internet dialer version 1.54.0
–> Cannot get information for serial port.
–> Initializing modem.
–> Sending: AT+CGDCONT=1,”IP”,”airtelgprs.com”
AT+CGDCONT=1,”IP”,”airtelgprs.com”
OK
–> Modem initialized.
–> Sending: ATDT*99#
–> Waiting for carrier.
ATDT*99#
CONNECT
~[7f]}#@!}!} } }2}#}$@#}!}$}%\}”}&} }*} } g}%~
–> Carrier detected. Waiting for prompt.
~[7f]}#@!}!} } }2}#}$@#}!}$}%\}”}&} }*} } g}%~
–> PPP negotiation detected.
–> Starting pppd at Mon Dec 25 21:54:16 2006
–> pid of pppd: 18155
–> Using interface ppp0
–> local IP address 10.148.27.10
–> remote IP address 10.6.6.6
–> primary DNS address 202.56.230.5
–> secondary DNS address 202.56.230.6
Caught signal #2! Attempting to exit gracefully…
–> Terminating on signal 15
–> Connect time 2.5 minutes.
–> Disconnecting at Mon Dec 25 21:56:50 2006
swordfish:/etc#

You may use other tools like KPPP or whatever you prefer instead of wvdial.

* GSM GPRS/EDGE cellular data networks use a mechanism called an APN (Access Point Name) to determine how a Mobile Station (MS), communicates via the GSM network to a host site (i.e., how the carrier network passes IP traffic to the host network). An APN determines what IP addresses are assigned to the mobile station, what security methods are used, and how the GSM data network connects to the customer’s network.

It is the world’s biggest crater in basaltic rock. Located in Buldhana district of Maharashtra, India. Co-ordinates: 19 degrees 87 minutes longitude (N) and 76 degrees 43 minutes latitude (E). Scientists estimate its age to be ~50000 years. The meteorite hit the Deccan basaltic trap near Buldhana. The thickness of basaltic rock around this region is believed to be between 30 to 1000 meters. The basaltic rock is in many layers or flows in this region[1]. These flows were created by volcanic activities over several million years.

The meteorite hit created the crater which is about 165 meters deep and 1830 meters in average diameter. This meteorite hit exposed a few basaltic layers at the rim of crater. The elevated rim around the crater is 12 to 15 meter in height. It is covered with 5 meter ejecta over it. The rim can be clearly seen in the satellite image[3]. The rim is mostly made of ejecta blanket spread over the distance of 1.5 kilometers around the crater with slope of 4-7 degrees and approx 15-30 degrees inclination at the inner edge of the rim.

Early in the 19th century, when a scientist pointed out this crater, it was believed to be a volcanic crater. Almost one and a half century this belief was intact. In 1961 two scientists named N. C. Nandy and V. B. Deo. They found breccia in drilling done at site. Breccia is another feature of shocked rocks found in impact craters.

This inference was reasserted by the studies conducted by Eugene C Lafond and Robert S Dietz in 1964. They conducted a survey and studied the crater. Based on their study they concluded that the crater is not of volcanic origin but it is of impact origin.

For the support of their conclusion they provided several reasons.
1 The crater is highly circular in diameter and has a characteristic depth-to diameter ratio of an impact crater.
2 The crater has a raised rim, about 20 m above the surrounding.
3 The surrounding rock dips away from the crater edge at inclinations of 15-30 degrees.

The theory of impact crater was further affirmed when V. K. Nayak of Center for Advanced Studies in Geology, University of Sagar, M.P., India, found glass like objects near the site. In drilling he also found breccia with shocked features, broken and twisted, highly oxidised. All these features indicated towards high velocity impact.

In 1973, some US scientists along with India scientist from GSI worked together to establish its impact origin. They discovered breccia with shatter cones and material containing maskelynite. Maskelynite formation requires very high pressure almost 4 lakh times the average atmospheric pressure on the Earth. And this is created only during hypervelocity impact. No volcanic process can form maskelynite. Thus impact origin of Lonar crater was proved. Three other scientists estimated its age to be about 52000 years.[4]

[1] http://www.virtualexplorer.com.au/journal/2003/12/tewari/
[2] http://www.mantleplumes.org/Deccan.html
[3] http://www.whoi.edu/hpb/viewImage.do?id=20170&ppid=153&sid=67&cl=2&isProj=1
[4] http://www.khagolmandal.com/index2.php?option=com_content&do_pdf=1&id=4

Here is a “Sad PHP Poem” Martin posted on php-general list.

======================

List: php-general
Subject: Re: [PHP] Sad PHP Poem
From: “Martin Alterisio”
Date: 2006-06-26 6:07:43
Message-ID: 52dbac0f0606252307q109d866fp59a86d35f099c43e () mail ! gmail ! com
2006/6/26, Ligaya Turmelle

:
>
> Martin Alterisio wrote:
> >
> >
> > A sad poem of an algorithm where solitude brought excessive use of cpu
> > cycles and memory allocation for redundant data (it copied over and over
> > again the same image till all memory was filled with it)
> >
> > ——————————
> >
> > $timeWaiting = 0;
> > while (!$you->near($me)) {
> > $me->thinkAbout($you);
> >
> > switch (true) {
> > case $timeWaiting < 5:
> > $me->wait($you);
> > break;
> >
> > case $timeWaiting < 10:
> > $me->worry();
> > break;
> >
> > case $timeWaiting < 20:
> > $me->lookFor($you);
> > break;
> >
> > case $timeWaiting < 40:
> > $me->worry();
> > $me->lookFor($you);
> > break;
> >
> > case $timeWaiting < 80:
> > $me->worry();
> > $me->cry();
> > $me->lookFor($you);
> > $me->lookFor($you);
> > $me->lookFor($you);
> > break;
> >
> > case $timeWaiting < 160:
> > $me->worry();
> > $me->cry();
> > $me->drink();
> > $me->lookFor($you);
> > $me->lookFor($you);
> > $me->lookFor($you);
> > $me->thinkAbout($you);
> > $me->thinkAbout($you);
> > $me->cry();
> > $me->lookFor($you);
> > $me->lookFor($you);
> > $me->drink();
> > $me->drink();
> > break;
> >
> > default:
> > throw new CantLiveWithoutYou();
> > die(”alone”);
> > }
> >
> > $timeWaiting++;
> > }
> >
> > $me->happy = true;
> >
> > ——————————
> >
> > I hope you enjoyed the poem and the fact that I didn’t ask you to fix it
> or
> > find the bug in it =D
> >
> > PD: Run in your web server at your own risk.
> >
> >
> >
> See we do have a softer side. Outstanding!

I was a hard man till she threw me a ImNotSoSureAnymore exception =S

PD: I’m on fire today, maybe AJAX and the greek muses are behind my
inspiration

===========================

Do not dig here until 12000 AD : Hazardous and Radioactive waste buried here

Yes, that is the warning that will prolly be displayed on The Waste Isolation Pilot Plant, or WIPP. It is an underground repository licensed to safely and permanently dispose of transuranic (TRU**) radioactive waste left from the research and production of nuclear weapons.

The facts about WIPP are stunning for example: it is built to last for next 10,000 years; USD 9 billion spent on this dump; it will accommodate waste of 40 years; the storage is 2,150 feet underground. After knowing these facts, one obvious doubt came to my mind was ‘how the hell will they ensure its safety against earthquakes?’. But as I dug deep, I found that it is located in the remote Chihuahua Desert of Southeastern New Mexico, project facilities include disposal rooms mined 2,150 feet underground in a 2,000-foot thick salt formation that has been stable for more than 200 million years. This cleared my doubt that it will remain safe for a few thousand years to come (wishful thinking?).

How is TRU’s safety ensured while transporting to the WIPP facility? An organization named TRANSCOM is responsible for monitoring its safety from beginning to end, which has facility to monitor movements round the clock. It uses satellite communication and computer networks to monitor. The control center houses databases containing scheduling, routing, shipment content and emergency information about each WIPP shipment. Vehicles transporting waste to WIPP are tracked by satellite. It has a stateful monitoring and planning systems in place in case of abnormal events and changes in weather or road conditions.

Guarding the facility for its lifetime isn’t a very appealing idea when we look at its budget. So will it be guarded? for how long and who will guard it? Well, the facility will be guarded for next 100 years after 2033 AD, until when outside experts with the task to design a 10,000-year marking system for the WIPP (Waste Isolation Pilot Plant) site, and estimate the efficacy of the system against various types of intrusion. The goal of the marking system is to deter inadvertent human interference with the site. The panel of experts was divided into two teams. This is the report of the A Team; a multidisciplinary group with an anthropologist (who is at home with different, but contemporary, cultures), an astronomer (who searches for extra-terrestrial intelligence), an archaeologist (who is at home with cultures that differ in both time and space from our own), an environmental designer (who studies how people perceive and react to a landscape and the buildings within them), a linguist (who studies how languages change with time), and a materials scientist (who knows the options available to us for implementing our marking system concepts). The report is a team effort. There is much consensus on the design criteria and necessary components of the marking system.it will be full. Guarding it will be responsibility of US Energy Department. After that it will be abandoned. That is when prolly the caution message will be displayed all around the place: “Do not dig here - forever!!”.

That said next question came to my mind was ‘who will ensure that the message will reaches to everyone who may or may not understand English?’ Actually this is one question that will rise only after 2030. But for curious, the answer is its not just the English in which they will be displaying the message. The message will be displayed in many languages like French, Arabic, Russian, Chinese, Navajo and provision for any contemporary languages that might exist then. But are language enough for communicating the danger message? Will there be any illiterates? Perhaps there will be people whose language isn’t there warning them.

To address this subject I will be writing another blog article in a day or two.

** TRU: All TRU elements are heavier than uranium, have several isotopes, and are man made. Key radionuclides found in TRU waste include americium-241 and several isotopes of plutonium (plutonium-238, plutonium-239, plutonium-240 and plutonium-241). The half lives of many are considerably longer than 20 years. For instance, the half-life of one isotope of plutonium 24,000 years. (Reference: http://www.wipp.energy.gov/library/acrsl/Chapter1.pdf)