Weird PHP Error after FreeBSD port upgrade (PHP Warning: PHP Startup: Unable to load dynamic library)

Today I upgraded the port on my FreeBSD box using portmaster tools:

portmaster -Dai

After that, I found that the PHP gave the following weird error:

php -v

PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20060613/memcached.so' - /usr/local/lib/php/20060613/memcached.so: Undefined symbol " php_session_create_id" in Unknown on line 0

PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20060613/mysql.so' - Cannot open "/usr/local/lib/php/20060613/mysql.so" in Unknown on line 0

PHP 5.2.12 with Suhosin-Patch 0.9.7 (cli) (built: Apr  6 2010 15:50:36)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies

In order to solve this problem, you will need to rebuild the port. In my situation, I need to clean up, uninstall, rebuild and install the affected ports:

Memcached: /usr/ports/databases/pecl-memcached

MySQL: /usr/ports/databases/php5-mysql

——————————————————————————————
Update on 2010.04.13:
Your situation may be different from mine. The tricky part is to rebuild the port at the right location. For example, if your PHP complains about pdo.so, you can rebuild the port at the affected location:

/usr/ports/database/php5-pdo

If you are not sure where does the port locate, you can search it on Google or find it with the following command:

find /usr/ports/ -name "*pdo*"

——————————————————————————————

In each affected port, run the following commands:

make clean
make deinstall
make
make install && sync
make clean

After that, restart the PHP by restarting Apache:

sudo apachectl restart

and run the php command again:

php -v

The error should be gone:

PHP 5.2.12 with Suhosin-Patch 0.9.7 (cli) (built: Apr  6 2010 15:50:36)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies

Our sponsors:

Recharge the battery using Wi-Fi signal, does it worth it?

Today I read an article about Airnergy, a product developed by RCA to recharge the portable device using Wi-Fi signal. I think the idea is pretty interesting because wireless power(not battery power) is a main research area in the next 20 years.

Here is the link to the article:
RCA Airnergy claims to charge gadgets using ambient WiFi signals

I think the comment from Gruph Norgle is pretty interesting:

In the EU the maximum legal Wifi transmission power is 100 milliwatts, however, on average 802.11 devices transmit at 50mw. Now in accordance with the inverse square law, at a distance of 5 meters, the power is reduced to 1 / (5^2) * 50mw = 2mw. Two milliwatts at 5 meters. Assuming they have a respectable electrodynamic induction efficiency of 75%, they will be able to convert 75% of that 2 milliwatts back into electricity: 1.5 milliwatts.

It takes 50 times that to power a single LED. This means that if their internal battery is 3 volts, 3000mAh it will take about 5000 hours to charge it to full capacity.

So, how long does an iPhone battery(3.7V, 1400mAh) get fully charged from zero?

Required power = 3.7V * 1400mAh = 5.18Wh
Supplied power = 1.5mW = 0.0015W
Hour to get fully charged = 5.18 /0.0015 = 3453.33 hours = 4.72 months

4.72 months??!!

–Derrick

Our sponsors:

Enough “Rails Surprise”! Goodbye Ruby On Rails.

Couple months ago, I published an article about Ruby On Rails. I was wrong.

The idea of Ruby On Rails is really good. You can create a very simple database-driven web application (i.e., User can add, browse, remove and search records) in less than half an hour. There is no way to do something similar in such a short time using other programming languages. However – perhaps this is the tradition of the Rails development team, it comes with surprise (“Rails Surprise”) every time after upgrading the Ruby gems component. They either make your Rails application couldn’t start, or some features in your apps are not functioning after the upgrade.

What kind of people should stick with Ruby On Rails?

  • Someone is big fan of Ruby/Gems/Rails.
  • Someone has plenty of spare time.
  • Someone likes to sharpen his/her debugging skill – To debug the backward incompatibility mess introduced by the Ruby/Gems/Rails core development team.
  • Someone is patient and is willing to spend number of hours(could be days) to look for workaround.

I am neither. I think I already have enough “Rails Surprise”. And I will make my own web application framework from now on (The code name is called ICEPIZZA by the way). It will be simple, elegant and backward compatible.

–Derrick

Our sponsors:

iPhone or Google’s Nexus One?

I am thinking to get a smart phone and I am undecided whether I should get an iPhone or Google’s Nexus One. In general, I think Apple’s product is designed with fashion in mind while Google’s product is designed toward to programmers. I am okay with either one.

Today I read an article from Harvard Business Review. The author mentioned a feature that is missing on Google’s Nexus One. I think it is pretty important and it may change my mind to go with iPhone.

Here is the link.

Google’s Nexus One: Can Openness Win?

Our sponsors:

[Solved]Shared object “libtokyocabinet.so.8” not found

After upgrading the Tokyo Cabinet on my FreeBSD 8 system, I could not start Tokyo Cabinet:

ttserver
/libexec/ld-elf.so.1: Shared object "libtokyocabinet.so.8" not found, required by "ttserver"

After some investigations, I solved the problem.

1. First, go to the library directory. In my case, it is /usr/local/lib.

cd /usr/local/lib

2. Display all the libtokyocabinet.so:

ls libtokyocabinet.so*

which returns:

lrwxr-xr-x  1 root  wheel    24B Jan  9 20:17 libtokyocabinet.so -> libtokyocabinet.so.9.4.0
lrwxr-xr-x  1 root  wheel    24B Jan  9 20:17 libtokyocabinet.so.9 -> libtokyocabinet.so.9.4.0
-rwxr-xr-x  1 root  wheel   778K Jan  9 20:17 libtokyocabinet.so.9.4.0

So the solution to this problem is pretty obvious. The application is looking for libtokyocabinet.so.8 but a newer version of this library is available. A soft-link is good enough to solve this problem:

sudo ln -s libtokyocabinet.so libtokyocabinet.so.8

Here is the expected result:

ls libtokyocabinet.so*
lrwxr-xr-x  1 root  wheel    24B Jan  9 20:17 libtokyocabinet.so -> libtokyocabinet.so.9.4.0
lrwxr-xr-x  1 root  wheel    18B Jan  9 20:26 libtokyocabinet.so.8 -> libtokyocabinet.so
lrwxr-xr-x  1 root  wheel    24B Jan  9 20:17 libtokyocabinet.so.9 -> libtokyocabinet.so.9.4.0
-rwxr-xr-x  1 root  wheel   778K Jan  9 20:17 libtokyocabinet.so.9.4.0

Now I run the Tokyo Cabinet again, and the problem is gone!

ttserver
2010-01-09T20:26:12-06:00       SYSTEM  --------- logging started [13244] --------
2010-01-09T20:26:12-06:00       SYSTEM  server configuration: host=(any) port=1978
2010-01-09T20:26:12-06:00       SYSTEM  opening the database: *
2010-01-09T20:26:12-06:00       SYSTEM  service started: 13244
2010-01-09T20:26:12-06:00       INFO    timer thread 1 started
2010-01-09T20:26:12-06:00       INFO    worker thread 1 started
2010-01-09T20:26:12-06:00       INFO    worker thread 2 started
2010-01-09T20:26:12-06:00       INFO    worker thread 3 started
2010-01-09T20:26:12-06:00       INFO    worker thread 4 started
2010-01-09T20:26:12-06:00       INFO    worker thread 5 started
2010-01-09T20:26:12-06:00       INFO    worker thread 6 started
2010-01-09T20:26:12-06:00       INFO    worker thread 7 started
2010-01-09T20:26:12-06:00       INFO    worker thread 8 started
2010-01-09T20:26:12-06:00       SYSTEM  listening started

Our sponsors:

[Solved]Fedora Linux Repository Error ([Errno 14] PYCURL ERROR 6)

I was having trouble to update my Fedora Linux system by running sudo yum update.

sudo yum update
Loaded plugins: presto, refresh-packagekit
Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora.
Please verify its path and try again

sometimes I see different sets of error:

http://download.fedoraproject.org/pu...ta/repomd.xml: [Errno 14] PYCURL ERROR 6 - ""

or

http://download.fedoraproject.org/pu...ta/repomd.xml: [Errno 14] PYCURL ERROR 7 - ""

After searching these error messages on Google, I found tons of the workaround methods. Unfortunately, none of them works! Finally, I came up a way to fix this problem.

The reason why you see this error message because your system could not connect to the main Fedora server(At the time of writing this blog, fedoraproject.org has been downed for at least 4 days.), so that your computer is not redirected to any Fedora mirror servers. The easiest way to fix this problem is by specifying a mirror server in your yum repository configuration file.

First, let’s find a mirror that is closed to your location:

Fedora Mirror (Fedoraproject.org)

or

Google Cache

If you have any trouble to access the information, here is a copy of the list:

North America

ftp://limestone.uoregon.edu/fedora/extras
http://limestone.uoregon.edu/fedora/extras
ftp://fedora.bu.edu/extras
http://mirrors.kernel.org/fedora/extras
ftp://mirrors.kernel.org/fedora/extras
rsync://mirrors.kernel.org/fedora/extras
ftp://ftp.muug.mb.ca/pub/fedora/linux/extras/
http://www.muug.mb.ca/pub/fedora/linux/extras/
rsync://rsync.muug.mb.ca/fedora-linux-extras/
http://mirror.hiwaay.net/redhat/fedora/linux/extras/
ftp://mirror.hiwaay.net/redhat/fedora/linux/extras/
rsync://mirror.hiwaay.net/fedora-linux-extras/
ftp://mirror.phy.olemiss.edu/fedora/extras/
http://mirror.phy.olemiss.edu/mirror/fedora/extras/
http://fedora.mirrors.tds.net/pub/fedora-core-extras
ftp://fedora.mirrors.tds.net/pub/fedora-core-extras
rsync://fedora.mirrors.tds.net/fedora-core-extras
http://mirror.cpsc.ucalgary.ca/mirror/fedora/linux/extras/
ftp://mirror.cpsc.ucalgary.ca/mirror/fedora/linux/extras/
rsync://mirror.cpsc.ucalgary.ca/fedora-linux-extras/
http://www.gtlib.gatech.edu/pub/fedora.redhat/linux/extras/
ftp://ftp.gtlib.gatech.edu/pub/fedora.redhat/linux/extras/
rsync://rsync.gtlib.gatech.edu/fedora-linux-extras/

Europe

http://sunsite.mff.cuni.cz/pub/fedora-extras/
ftp://sunsite.mff.cuni.cz/pub/fedora-extras/
rsync://sunsite.mff.cuni.cz/fedora/extras/
ftp://alviss.et.tudelft.nl/pub/fedora
http://ftp.lug.ro/fedora/linux/extras/
ftp://ftp.lug.ro/fedora/linux/extras/
http://ftp.uni-bayreuth.de/linux/fedora/linux/extras
ftp://ftp.uni-bayreuth.de/pub/linux/fedora/linux/extras
rsync://rsync.uni-bayreuth.de/fedora-linux-extras
http://ftp1.skynet.cz/pub/linux/fedora/extras/
ftp://ftp1.skynet.cz/pub/linux/fedora/extras/
ftp://ftp.tu-chemnitz.de/pub/linux/fedora-core-extras/
http://wftp.tu-chemnitz.de/pub/linux/fedora-core-extras/
ftp://ftp.chl.chalmers.se/pub/fedora/linux/extras/
ftp://ftp.udl.es/pub/fedora/linux/extras/
http://ftp.udl.es/pub/fedora/linux/extras/
rsync://ftp.udl.es/pub/fedora/linux/extras/
ftp://gd.tuwien.ac.at/opsys/linux/fedora/extras/
http://gd.tuwien.ac.at/opsys/linux/fedora/extras/
rsync://gd.tuwien.ac.at/opsys/linux/fedora/extras/
http://fr.rpmfind.net/linux/fedora/extras/
ftp://fr.rpmfind.net/linux/fedora/extras/
rsync://fr.rpmfind.net/linux/fedora/extras/
http://mirror.etf.bg.ac.yu/fedora/linux/extras
ftp://mirror.etf.bg.ac.yu/fedora/linux/extras
rsync://mirror.etf.bg.ac.yu/fedora/linux/extras

http://mirror2.etf.bg.ac.yu/fedora/linux/extras
ftp://mirror2.etf.bg.ac.yu/fedora/linux/extras
rsync://mirror2.etf.bg.ac.yu/fedora/linux/extras
ftp://klid.dk/fedora/linux/extras/
http://klid.dk/homeftp/fedora/linux/extras/

Russia

http://ftp.rhd.ru/pub/fedora/linux/extras/
ftp://ftp.rhd.ru/pub/fedora/linux/extras/
ftp://ftp.chg.ru/pub/Linux/fedora/linux/extras/
http://ftp.chg.ru/pub/Linux/fedora/linux/extras/
rsync://ftp.chg.ru/fedora/linux/extras/

Taiwan, Asia

http://ftp.isu.edu.tw/pub/Linux/Fedora/linux/extras/
ftp://ftp.isu.edu.tw/pub/Linux/Fedora/linux/extras/

Australia

http://planetmirror.com/pub/fedora/linux/extras/
ftp://ftp.planetmirror.com/pub/fedora/linux/extras/
rsync://rsync.planetmirror.com/fedora/linux/extras/
http://mirror.pacific.net.au/linux/fedora/linux/extras/
ftp://mirror.pacific.net.au/linux/fedora/linux/extras/

In my example, I will use the following parameters:
Mirror: http://fedora.mirrors.tds.net/
Version($releasever): 12
Architecture($basearch): x86_64

If you are not sure how to determine the version and the architecture, you can type:

cat /etc/redhat-release && uname -a

It should say something like:

Fedora release 12 (Constantine)
Linux 2.6.31.6-145.fc12.x86_64 #1 SMP Sat Nov 21 15:57:45 EST 2009 x86_64 x86_64 x86_64 GNU/Linux

Next, run the following:

sudo nano /etc/yum.repos.d/fedora.repo

and edit the following from:

[fedora]
...
baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/

[fedora-source]
baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/$releasever/Everything/source/SRPMS/

to:

[fedora]
...
#baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/
baseurl=http://fedora.mirrors.tds.net/pub/fedora/releases/12/Everything/x86_64/os/

[fedora-source]
...
#baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/$releasever/Everything/source/SRPMS/
baseurl=http://fedora.mirrors.tds.net/pub/fedora/releases/12/Everything/source/SRPMS/

Now, let’s do something similar to another file:

sudo nano /etc/yum.repos.d/fedora-updates.repo
[updates]
...
#baseurl=http://download.fedoraproject.org/pub/fedora/linux/updates/$releasever/$basearch/
baseurl=http://fedora.mirrors.tds.net/pub/fedora/updates/12/x86_64/

[updates-source]
...
#baseurl=http://download.fedoraproject.org/pub/fedora/linux/updates/$releasever/SRPMS/
baseurl=http://fedora.mirrors.tds.net/pub/fedora/updates/12/SRPMS/

Now, try to run the update again by:

sudo yum clean all
sudo yum update

It should work now. Enjoy your update!

Thoughts:

The reason why this problem happens because the Fedora server is down for at least 4 days(From 12/31 to 1/4, 2010, for four days.), and the problem is not fixed! Yes I know it is in the holiday, but it is not an excuse.

One reason why my company prefers using Fedora Linux is that it has a long history and it is backed by Red Hat. Now the quality of their service seems going down. (Their servers have gone down multiple times in December, and each down time lasted longer than a day.) I think it is probably about time for us to move to a different Linux distribution, such as Ubuntu.

Fedoraproject.org has downed.

FYI, I personally use FreeBSD for all of my server applications.

–Derrick

Our sponsors:

Installing from FreeBSD ports without prompt

When I configure my FreeBSD box, I like to install the applications from the ports instead of using pkg_add, because I can customize the configurations and optimize the compile process for my systems. However, if an application comes with lots of dependencies, it will take me a long time because I will need to sit in front of the computer and choose the options for each applications. It is a very time-consuming process.

So, how to make the process automatic? Here is the trick:

To use the default options, simply do:

sudo make -DBATCH install clean

Or view all of the options at the beginning:

sudo make config-recursive
sudo make install clean

Hope these two tricks will save you few hours.

–Derrick

Our sponsors:

Installing XAMPP on Fedora 12 64-bit system

I was installing XAMPP on Fedora 11 64-bit today, and I saw this famous message:

sudo /opt/lampp/lampp startapache
XAMPP is currently only availably as 32 bit application. Please use a 32 bit compatibility library for your system.

The message is very clear that XAMPP doesn’t like 32-bit system. So, we will need to cheat XAMPP that the system is 32-bit. First, we will need to install some libraries:

sudo yum -y install glibc.i686 libgcc.i686 libstdc++.i686

and now, we need to skip the 32-bit annoying check. Use Nano or your favorite editor to open this file: /opt/lampp/lampp

sudo nano /opt/lampp/lampp

Replace the following from:

# XAMPP is currently 32 bit only
case `uname -m` in
       *_64)
       if /opt/lampp/bin/php -v > /dev/null 2>&1
       then
               :
       else
               $de && echo "XAMPP gibt es zur Zeit nur als 32-Bit Applikation. Bitte verwende eine 32-Bit Kompatibilitaetsbibliothek fuer Dein System."
               $de || echo "XAMPP is currently only availably as 32 bit application. Please use a 32 bit compatibility library for your system."
               exit
       fi
       ;;
esac

To:

# XAMPP is currently 32 bit only
#case `uname -m` in
#       *_64)
#       if /opt/lampp/bin/php -v > /dev/null 2>&1
#       then
#               :
#       else
#               $de && echo "XAMPP gibt es zur Zeit nur als 32-Bit Applikation. Bitte verwende eine 32-Bit Kompatibilitaetsbibliothek fuer Dein System."
#               $de || echo "XAMPP is currently only availably as 32 bit application. Please use a 32 bit compatibility library for your system."
#               exit
#       fi
#       ;;
#esac

Now run the following the start XAMPP:

sudo /opt/lampp/lampp startapache

Wow! Everything is working great!

–Derrick

Our sponsors:

nginx vs Tornado Web vs Apache Performance Benchmark

Let’s put the nginx, Tornado and Apache and see who is the winner.

What to test:

A simple Hello World webpage.

How:

ab -n 10000 -c 300 http://myserver.ip

Test Environment:

OS: Ubuntu 9.10 (32-bit) / Linux 2.6.31
CPU: Pentium Celeron M 1.5 GHz
Ram: 512 MB
Apache: 2.2.12
PHP: 5.2.10
Python: 2.6
Tornado: 0.2
nginx: 0.6.13

Result:

Apache

Server Software:        Apache/2.2.12
Server Port:            80

Document Path:          /
Document Length:        13 bytes

Concurrency Level:      300
Time taken for tests:   5.295 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      2863146 bytes
HTML transferred:       130143 bytes
Requests per second:    1888.58 [#/sec] (mean)
Time per request:       158.850 [ms] (mean)
Time per request:       0.529 [ms] (mean, across all concurrent requests)
Transfer rate:          528.05 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    8 151.0      0    3028
Processing:     0  122 602.0     48    5289
Waiting:        0  122 600.8     48    5284
Total:         10  130 622.1     49    5292

Percentage of the requests served within a certain time (ms)
  50%     49
  66%     50
  75%     50
  80%     51
  90%     53
  95%     63
  98%     68
  99%   5271
 100%   5292 (longest request)

nginx

Server Software:        nginx/0.6.13
Server Port:            8000

Document Path:          /
Document Length:        13 bytes

Concurrency Level:      300
Time taken for tests:   3.172 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      2230000 bytes
HTML transferred:       130000 bytes
Requests per second:    3152.12 [#/sec] (mean)
Time per request:       95.174 [ms] (mean)
Time per request:       0.317 [ms] (mean, across all concurrent requests)
Transfer rate:          686.45 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2  68.3      0    3057
Processing:     0   70 359.1     27    3164
Waiting:        0   70 359.1     26    3164
Total:         10   72 365.6     27    3169

Percentage of the requests served within a certain time (ms)
  50%     27
  66%     27
  75%     27
  80%     27
  90%     28
  95%     29
  98%     32
  99%   3157
 100%   3169 (longest request)

Tornado Web:

Server Software:        TornadoServer/0.1
Server Port:            8888

Document Path:          /
Document Length:        12 bytes

Concurrency Level:      300
Time taken for tests:   5.109 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      1680000 bytes
HTML transferred:       120000 bytes
Requests per second:    1957.33 [#/sec] (mean)
Time per request:       153.270 [ms] (mean)
Time per request:       0.511 [ms] (mean, across all concurrent requests)
Transfer rate:          321.12 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   32 309.3      0    3035
Processing:    33  103  28.5    103     375
Waiting:       33  102  28.5    103     375
Total:         36  135 311.3    103    3154

Percentage of the requests served within a certain time (ms)
  50%    103
  66%    105
  75%    108
  80%    112
  90%    116
  95%    126
  98%    313
  99%   3121
 100%   3154 (longest request)

What do these numbers mean?

In a given time, if nginx and Tornado Web can handle 1.66 and 1.036 times more requests than Apache, respectively! In the other words, the server is more efficient and it can use the saved resource to do something else!

–Derrick

Our sponsors:

Tornado Web Server – Very Fast!

I just did a benchmark comparison on Tornado Web Server and Apache + PHP server. The result is pretty amazing.

What to test:

A simple Hello World application.

How:

ab -n 1000 -c 300 http://myserver.ip

Test Environment

OS: FreeBSD 7.1
CPU: Pentium III 933 MHz
Ram: 256 MB
PHP: 5.2.9
Python: 2.5.4
Tornado: 0.2

Result:

Apache + PHP:

Concurrency Level:      300
Time taken for tests:   3.515 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      255000 bytes
HTML transferred:       12000 bytes
Requests per second:    284.50 [#/sec] (mean)
Time per request:       1054.499 [ms] (mean)
Time per request:       3.515 [ms] (mean, across all concurrent requests)
Transfer rate:          70.85 [Kbytes/sec] received

Tornado Web Server:

Concurrency Level:      300
Time taken for tests:   1.907 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      168000 bytes
HTML transferred:       12000 bytes
Requests per second:    524.48 [#/sec] (mean)
Time per request:       571.993 [ms] (mean)
Time per request:       1.907 [ms] (mean, across all concurrent requests)
Transfer rate:          86.05 [Kbytes/sec] received

What do these numbers mean?

Tornado Web Server can handle 1.84 times more requests than Apache + PHP server in a given time!

–Derrick

Our sponsors: