Michal Čihař - Archive for 5/2007

I just came to another decision point. Curently new Gammu API is quite in good shape (even most of functions are documented), but I think whether it's time to push in also some other big changes, which I would like to see, or just wait for things to settle down before starting other major changes.

For application developers (using C API, Python ones won't notice any of those changes), it would be definitely better to do all changes in one big bang. However I'm really affraid of possible impacts on stability, because extreme big changes. I'm still more and more convinced about stabilizing current code and keep those big changes for later time.

When talking about this, I should also mentions change I want to introduce :-). First is switch to wchar_t instead of own UCS-2-BE encoding. This will help a lot in possible errors on allocating memory for strings and also allow us to use libc functions for string operations. The second change is even bigger - make all storages scalable to avoid problems with hardcoded limits. But for this change it should be possible to add compatibility API functions, so that users don't have to notice anything.

I never knew, that someone would certify few lines of Python code, but Softpedia did so:

   Your product "IMAP utils 0.2" has been tested by the Softpedia labs and
   found to be completely clean of adware/spyware components.

   We are impressed with the quality of your product and encourage you to
   keep this high standards in the future.

   To assure our visitors that "IMAP utils 0.2" is clean, we have granted
   it with the "100% FREE" Softpedia award. Moreover, to let your users
   know about this certification, you may display this award on your
   website, on software boxes or inside your product.

I still wonder why simplest "product" I ever released is getting so much publicity…

Recently spam checking stopped to be enough to prevent my mailbox to grow to incredible sizes, so I had to look for some possibility to block viruses and other malware. The obvious choice went to open source anti-virus Clamav.

Setting up was pretty easy, especially when there are tons of howtos on the net (e.g. Installing and configuring Exim 4 on Debian). All I had to do was to install Clamav and configure Exim to talk to it and reject unwanted stuff.

And what are results? Quite impressive - 154860 caught viruses in last 24 hours.I wonder that lots of them were also caught by SpamAssassin, because I definitely didn't receive that much malware in a day.

I just released new version of Gammu, you can download it from download server. The biggest change is new API. It is probably not yet completed, but I want to release it right now to receive feedback from other developers. Full list of changes:

• Support for some new Nokia fields.
• Made SMSD mode case insensitive.
• Fix iCalendar export typo (Alin Năstac).
• Better compatibility with Sharp phones.
• Completely changed public API to avoid too often ABI changes.
• See PORTING file for changes you have to do.
• Dropped autoconf support, use CMake instead.
• Please note that new API is still work in progress!

goText (Java apllication for your phone to send messages onver GPRS) has just received support to send messages to Czech Vodafone network. It is using public SMS gateway, the only drawback is that you have to detect captcha used on this page. But it still is cheaper than sending regullar SMS :-).

To use this service, add following URL to your goText services:

http://www.gotext.org/pub/cz-vodafone.php

New version of simple todo manager called Ukolovnik has been just released. Version 0.7 comes with following changes:

• Development switched to subversion.
• Added support for CSV export.
• Added support for vCalendar export.

Steve, I know that caching usually helps. But from all test I've made with MediaWiki installation on phpMyAdmin wiki, I can see that enabling any caching slows things down quite a lot.

With memcached based caching, each request takes about 15 seconds, if I add XCache backend for variables, it slows down things to 10 seconds and I receive same results with file based caching. So it doesn't seem to be problem with memcached, but rather MediaWiki issue. Unfortunately it's quite a lot of PHP code to investigate and I didn't find anything obvious in low level caching interface.

So say good bye to variable caching, opcode cache is enough for now and MySQL seems to handle the load quite well.

Same time I complained about not up to date xcache package, I wrote to current maintainer whether I can adopt it. As he promptly agreed to this, we now have up to date package in Debian archives.

The only thing I messed down is that I did upload in hurry and didn't check which all bugs I can close by it. Today it turned out that all opened bugs could be closed, so I made another upload just to close those bugs ;-).

As I wrote in previous post, memcached didn't help as expected with wiki performace, so it was time to look for something else.

Since I'm using lighttpd, I still considered using of XCache, but the Debian package is not really up to date (now it even does not install with current php), so it was too much effort.

But today I decided it's time to try it. I built package from current version (you can get it on debian.cihar.com), installed and it seems to increase performance a lot. Most visible it is on wiki pages, which now take about quarter of time to process. I only hope it won't have any stability impacts, but it survived fine stress tests I did so far.

I've been using memcached for some time on phpMyAdmin wiki and it seemed to help. But recently the performance went down. I didn't have time to investigate it till today and it turns out to be caused by memcached. When I switch it off, page load time goes from 16 seconds to 0.25 seconds.

I tried to search for some similar problems on the net, but I didn't succeed. So for now wiki runs without memcached and I will look at other possibilities of caching later.

Update: If you're interested about versions, it is MediaWiki: 1.7.1, PHP: 5.2.3-1 (cgi-fcgi), MySQL: 5.0.41-Debian_2-log and I have enabled persistent connections to MySQL.