wnd's weblog

Introducing Woclema, weblogging software for discriminating people

Weblogs. Or blogs. They seems to be everywhere. Everybody but me blogs. Should I start a blog of my own? Most weblogging software seem to run on PHP and MySQL (see Wikipedia article on weblog software), and I shun both. What a perfect opportunity to waste countless hours in reinventing the wheel.

Embrace Woclema, weblogging software for discriminating people like yourself. :-) Written in Perl and using PostgreSQL as database engine, highly original name Woclema stands for Weblog, Originally Command Line Editable/Manageable. Woclema comes with sophisticated front-end which, erm, allows you to feed in your entries using your favourite text editor and shell, be it combination of zsh/vim, Bash/Emacs, or any of the countless combinations.

Seriously though, Woclema really started as simple Perl/PostgreSQL weblog thingie that could be edited and maintained with command line tools. Woclema supports entry categories, user comments, and permanent links (as long as primary keys in DB stay the same). It uses CSS for layout, so it should be fairly easily themed. Currently there is no spam protection for comments, nor any kind of interface to post or maintain the weblog using web-browser. However implementing neither should be a problem.

Woclema does not have any kind of markup language, nor does it hold your hand to prevent you from hurting yourself. It allows editors to insert HTML without artificial limitations. It does not allow others to do the same -- for comments, text is HTMLized, i.e. potentially dangerous characters are written as entities such as <.

Grab the sources and join the revolution in weblogging software. :-)

Optimisation with GCC and its impact on performance

There has been lot of discussion about compiling GNU/Linux from scratch, and performance boost related to it. I have never been a big believer of this -- except for applications such as multimedia encoding. How much does optimisation really matter?

From what I learned, optimising for athlon-xp (or i686) instead of i386 will get you around 15% performance boost with processing multimedia content, but for amd64 it's all the same.

See full article.

System tray for non-Gnome/KDE environments

Some time ago I accidentally discovered Ktray. To quote the website: "KTray is a system tray which holds dock icons of any application. It is independent from the kde kicker and so it can be used with any window manager." As a die hard user of Fvwm2, I didn't know what to think. Basically I never liked the idea of having unnecessary clutter on the screen, but I also acknowledged that system trays actually did serve a purpose. Not often, but it did. With this thought I left the page open in my browser until I could look further into it.

About two week ago I found myself trying to compile Ktray for my installation of Debian. It was nine o'clock in the morning, and I was supposed to go to work. However the compiling didn't go too well -- in fact, I couldn't even run the configure-script successfully. configure.ac (or maybe it was configure.in) wasn't very helpful as it was looking for KDE libraries using KDE-macro instead of pkg-config. I tried installing several development packages for KDE and QT, but nothing would help. Finally, I closed the tab in my browser, deleted my work directory, and left to work. I was a little upset about this, and wondered, if I should try to create a similar application, but for KDE and Gnome.

This morning, for some reason, I remembered my earlier experience with Ktray. I opened my start page in a browser, and typed in a search for "kde tray stand-alone". The second hit I got was stalonetray. First of all, stalonetray is a live project. Unlike Ktray, is has been updated this year, and not just two years ago. Second, it would also support freedesktop.org system tray, which obviously includes Gnome system tray. This would be exactly what I was thinking of. On top of everything else, stalonetray is already included in Debian unstable.

However things never go that smoothly. While stalonetray does pretty much what it promises, it's not perfect. I want to run stalonetray swallowed in FvwmButtons, which I have set up to also include FvwmPager, xclock, and xbiff. Stalonetray grows bigger to accommodate more icons. I don't want my FvwnButtons to grow bigger. See the conflict? There appears to be no option in stalonetray to make it retain its size, and add scroll buttons or something else instead. In addition to that, I cannot force the icon size to something specific. Sometimes stalonetray shows X-Chat's icon in 48x48 pixels, sometimes in 24x24, and sometimes it first grows the window for 48x48-pixel icon, and then resize the icon to 24x24 -- without shrinking the window back to its original size. Also, stalonetray does not shrink when icons are removed.

I have somewhat mixed emotions about stalonetray. The idea is great -- effectively Gnome and KDE system tray for Gnome/KDE-independent environments with minimal dependencies. It works, but there's lots of room for improvement. I keep starting stalonetray outside FvwmButtons from .xsession for now, but I have the feeling I will soon get rid of it. At least until the next time.

Photos from Lauttasaari, Helsinki, Finland

Movial was having our annual summer party, and while I'm not much of a party-going type, it was perfect opportunity to walk around private areas of Lauttasaari without drawing too much attention. The pictures do not try to tell a story or anything, they're just a set of pictures from there.

Photos.