Michal Čihař - Archive for Jan. 1, 2010

I decided to upgrade my notebook to SSD disk. The disk replacement went easy, installed fresh Debian on it and now comes the tricky part how to properly tune system to use as much as SSD can provide.

The first obvious thing for me is changing IO scheduler. But which one to choose? Most of howtos seem to suggest noop or deadline, without stating benefits of each. For now I've chosen deadline, without string coninfidence, that I'm doing the right thing.

The next major part of tips includes removing filesystem journalling. Well I think journalling exists for good reason and disabling it won't help me much (no, I really don't want to wait for fsck after each crash).

The last tweak seems to be using tmpfs for any temporary data (/tmp) or even for logs. For /tmp it might make sense, on cost of loosing available memory (or swapping it out, what really does not help the SSD anyway). However I definitely don't want to loose my logs on every reboot.

Maybe I'm missing some bit, but the only important thing seems to be the IO scheduler.

After being noticed in blog comment about another theme for phpMyAdmin, I started to look for other hidden contributions for phpMyAdmin and I was surprised how many people did not even try to submit their code upstream. Have you ever considered trying to contact upstream?

Quick search on SourceForge.net revealed:

VisualMCD for phpMyAdmin

An Add-on for phpMyAdmin which enables user to create PDF Schema and Relation with a simple click and mouse moves. No more fastidious typing of table coords needed to create the PDF Schema.

Even though the SF.net history says it was released 440 days ago, it is actually dated back to 2003 and it obviously is not compatible with current code base. Also we have similar feature for few years now, so it was just duplicated effort.

phpMyAdmin theme: Paradice

Paradice is a Theme for the popular web-based database administration tool phpMyAdmin. You will find the development version here. All official releases will be made by the phpMyAdmin project.

This theme is just developed externally, but you can get it from our themes page

phpMyAdmin persian project

phpMyAdmin persian project

Something what seems to be dead from beginning. Anyway if you want to translate, please use our translation server.

MySQL Form Generator pour PHPMyAdmin

C'est un outil pour crr un site autour d'une base. Un gnrateur de formulaire. Sur base d'une DB Mysql.Projet prvu pour tre intgr PhpMyAdmin.mysql -> formulaire HTML+javascript avec le code PHP pour trater les soumissions de donnes.

Something we still don't have in phpMyAdmin, however the project is inactive for more than year.

pmahomme

Clean, modern and easy to use phpMyAdmin theme.

Theme which started this search, however it seems to fail for me right now.

phpMyDesigner

Plugin for phpMyAdmin. PhpMyDesigner is a tool written in PHP and Ajax. This CASE with WEB interface. ( MySQL )

This actually does not fit into this blog, because it is one of projects that got merged and are now part of our code base.

phpMySchema

phpMySchema is a tool written in PHP for generating an ERD or otherwise graphical view of your MySQL databse over the web. It is being developed to be used as a standalone script and as a module for phpMyAdmin.

Generally it looks like an interesting addition, however we can quite well compete with this after this year's GSoC, which added ability to export schema in various formats.

Around three years ago I've migrated my stuff to Subversion from GNU Arch. Last year I migrated most important/alive things to Git. Unfortunately not all, so I still needed to host SVN server on my own.

I think it's now time to get rid of it :-). In past weeks I've moved most Debian packaging stuff to some team/collab-maint repositories (being it Git or Subversion), because I really don't see need for hosting that stuff on my own.

The remaining repositories are mostly historical (with single exception of StarDict dictionaries conversion tools) and nobody will probably care if they are gone. Ah and there are some dead projects as well which were never finished and will never be :-).

Anyway svn.cihar.com is going to disappear soon and nobody will miss it.

For quite some time, I wanted to use subkeys for signing at some places where I do not want to have my certification key stored, however I trust this location enough to have signing key available. I knew it should be possible with subkeys, however I never found time to look at it.

First I needed to add new subkey which will be used for signing:

gpg --edit-key 42B7511D
> addkey

Now choose 4 (RSA for signing) and wait until new key is created.

The only remaining step is to transfer subkeys to the other location:

gpg --export-secret-subkeys 42B7511D > /tmp/key-sub.gpg
scp /tmp/key-sub.gpg other.place:

Import them there and deleting any unwanted (eg. encryption) subkeys:

gpg --import key-sub.gpg
gpg --edit 42B7511D
> key 1
> delkey

And it's done ... much easier than I expected :-).

Some weeks ago, I've started to change documentation structure of Gammu to move from separate documents here and there into one comprehensive documentation which would cover it all. As a tool to do this I've chosen Sphinx, simply because I felt most convenient with the format and outputs it provides.

So far the SMSD documentation has been converted from various places and formats, but it also opened up a question - how to deal with translations? So far we used po4a to translate man pages, however using it for generated man pages is slightly complicated (there are some macros which po4a does not understand and it seems to break encoding on the way).

Translating whole new documentation is something what is unlikely to be finished, especially considering fact, that the only real existing translation so far is Czech which was done by me.

For now I decided to keep old translated man pages and postpone the decision, but considering current situation, I will most likely just drop the translations for man pages unless I find some good solution how to translate Sphinx documents (po4a should be able to do that, but it will probably need some tuning).

Once in a time when looking at my Debian Developer's Packages Overview, I just start to think there is way too much bug reports for phpMyAdmin package in Launchpad. Today the threshold was 30 :-).

Managing them is usually not that hard, because vast majority of them are just duplicates of same issue. Basically all problems come with the fact that dbconfig-common really does not behave nicely when database server is not configured and user tries to configure it. I know people should just answer no to first question, whether to use dbconfig-common, but they don't and it then horribly fails.

Today I finally decided to ignore all errors from dbconfig-common in our packaging scripts, so you will get an error, but the package will be installed. As it seems that this is what most Ubuntu users expect after all.

This also shows huge difference between Debian and Ubuntu users - such bug has never appeared in Debian bug tracker, but has zillions of duplicates in Launchpad in various incarnations (LP#618852, LP#621569 and the most favorite LP#456674).

Okay, adding comments lead exactly to the expected situation of spam comments, so I just added fccv and started using typepad to help me in fighting with spam. I hope it will catch most of it (it would catch all I've had to delete manually so far) and will avoid false positives.

For some time (probably since upgrade to 1.0) it looks like my Piwik installation did not log URLs and page titles from visitors. Simply all URLs and page titles logged were blank.

While I still postponed the investigation of this, I was pretty sure it must be some configuration issue and not a bug, so I felt reluctant to report this.

Today I finally found time and copied upstream global.ini.php to my installation and it seems to do the trick. I should better care of upgrading next time :-).

PS: Any volunteer for packaging piwik for Debian?

As there was started project for German-Czech dictionary, I've quickly added it to my conversion scripts and these dictionaries are now available in StarDict format as well.

Don't expect much right now, the project has just started and contains only few words :-).

PS: Authors are aware of dicts.info and other free dictionaries and want to cooperate somehow.

One of reasons of recent move my blog to custom Django based application was use of comments. Today I've finally found time to enable support for them, so you can provide me feedback directly without mailing me or reposting on some planet where my blog is syndicated.

I hope it will not turn into fight with spam bots, for now I'm using only protection Django has built-in.