October 2007 Archives

Yesterday, 2007-10-29 we had first ever meeting of Zagreb PerlMongers. There where three of us, and while that's not much, it's a start in organizing perl users here in Zagreb, Croatia.

So, now that you know that Zagreb.pm exists, watch out for official listing at Perl Mongers: Europe. We are still not there, but soon...

We will have another meeting as soon as we setup mail list and we'll try to do better public announcement before it... If you are perl monk near Zagreb, feel free to get in touch with me so we can keep you posted about progress.

Update: We now have (Croatian speaking) list at Google Groups so if you are interested in next meeting subscribe to list...

I have heard several complaints about Cisco VPN client for Linux. It's a kernel module, so it's a mess.

However, few days ago I had to connect to one site using Cisco VPN. I got even Windows client. Which didn't work from emulated Windows on my Linux box... What should I do?

First idea to search Debian packages proved like a right thing to do: I soon found vpnc which had all the tools needed for transition. Even tool to convert Windows Support_template.pcf to format sutable for vpnc!

I also wrote a short tutorial how to install and configure it which might be helpful.

Let me try to explain my mail system: I have multiple mailboxes on IMAP server (filtered by procmail) which are synced to my laptop using offlineimap on which I read them using mutt.

This configuration has served very well, in fact so well that I have been using it for last 5 years every 45 minutes while my laptop was on. My python-fu skills are very low, I just can't read language, sorry... I tried to learn it several times, and it's just somehow not readable to me without much effort. I don't really know why. Maybe my brain was forever influenced by begin and end in Pascal (which later turned out to be curly braces in other languages), but indentation is not working for me. But, offlineimap worked beside the fact that I promised myself to get rid of all critical python code after every mailman upgrade :-)

It had few hiccups, mostly from full disk, but cleaning some space always turned out to be solution. It worked so well that I recommended it to one very unsatisfied Evolution+IMAP user... Until today, that is...

Today I run out of disk space. I think. Then I cleaned some space. And got disk full message again. Strange? In fact no. I have configured news servers sometime in last century and I still do remember i-nodes. I use ext3 on this partition by the way.

Quick df -i reviled that I have, indeed, run out of i-nodes (sorry, Jakov, you weren't quick enough to see df output with 0 i-nodes :-)

Did you know that make clean in compiled Linux kernel tree can give you 26000+ i-nodes? I didn't. Now I know. However, couple of moments later I discovered that I have again run out of i-nodes again.

Nobody around (and I was surround by at least 5 very knowledgeable Linux users -- which is a benefit of being at Linux track of conference while running out of i-nodes :-) didn't know how to find a huge pile of small files which where eating my i-nodes.

Lucy guess revealed that there is something strange with my INBOX/tmp directory. ls just hung in D state (blocked on I/O) and find . (which should display files because it doesn't try to read them all in as ls does to have them sorted) just blocked in D state also.

So, I decided to do rm -Rf tmp. It has been running for more than two hours now. I got 700000+ of i-nodes back (probably even more by the time I finish this post).

Here are few lines from offlineimap log:

OSError: [Errno 28] No space left on device: '/home/dpavlin/Mail/INBOX/tmp/1192813332_0.6409.llin'

Last 50 debug messages logged for Copy message 319050 from INBOX prior to exception:

maildir: savemessage: using temporary name 1192813326_9.6409.llin

maildir: savemessage: using temporary name 1192813326_10.6409.llin

I don't really know from which run this log is. From one which failed, for sure. My maildir knowledge disappeared also sometime in last century when i replaced last qmail installation with postfix.

So, lazywab, my question is: What is tmp directory in maildir? Is it safe to just re-create it and let offlineimap re-sync my folders?

My INBOX has 6778 mails and I wouldn't want to loose them. I will make backup on server, but re-syncing them would be (slow, ADSL) pain which I would like to avoid. offlineimap has two-way sync, so my worries are not without reason.

Update: The correct procedure would be to erase correct directory in ~/.offlineimap and re-sync mailbox meta-data (which again took allmost 24 hours).

I still can't quite explain where did 2500000+ i-nodes went, but in the process new version of offlineimap went into Debian unstable so this might have fixed problem also. It working now, so life is good again...

I wanted to review my route to recent conference, and there are a lot of map servers out there. But, none of them offer good way to print map (analog copies are always useful :-)

I didn't really wanted whole map, I wanted just a part which I viewed. And than, I noticed that those parts already arrived on my laptop (because I can view them in browser). Parts? Packets? With a quick trip to tshark (wireshark but for terminal) I captured network trace of my browsing of route.

So, now I had all the tiles I needed to print out (to find my way through route) in pcap capture format. Quick CPAN search and I found Net::Analysis which seem to fit the bill. Simple HTTP transaction listener later and I have tiles saved in directories which are zoom levels and each tile has coordinates of tile.

Do I want to stitch them together by hand? Of course not, with handy misspelled tool will do that for you. It's written as cleanly as possible, and might be a good way to look at one possible way to write perl code (don't write too much!).

If you didn't checked links to source code, please have in mind whole working implementation is under 3k of perl code!

It does have dependency on CPAN, but just imagine how much time would I spend writing TCP session reassembly and/or multiple-format image handling it I didn't used CPAN.

Off to the road now...

As I have complained several times before, I have problems with my ATI Technologies Inc M52 [ATI Mobility Radeon X1300] card on IBM/Lenovo T60 (don't you just love those company name changes?!)

I have been tracking two git repositories for drivers:

• git://anongit.freedesktop.org/git/avivo/xf86-video-avivo
  Older reverse engineering effort to which I contributed PCI ID of my card
• git://anongit.freedesktop.org/git/xorg/driver/xf86-video-radeonhd
  Newer effort based on AMD specification which developers from Novell received ahead of rest of Open Source community

Last time I reviewed the problem, both of those drivers where broken for my box.

This time, I must report that avivo driver is now finding my card, and in fact, I'm typing this blog post using it :-)

Even xrandr is reporting something which seems sane:

Screen 0: minimum 320 x 200, current 1400 x 1050, maximum 1400 x 1400
VGA unknown connection 1280x800+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1280x800       60.0* 
   1280x768       60.0  
   1024x768       60.0  
   800x600        60.3  
   640x480        59.9  
LFP connected 1400x1050+0+0 (normal left inverted right x axis y axis) 305mm x 228mm
   1400x1050      60.0*+   50.0  
   1280x1024      59.9  
   1280x800       60.0  
   1280x768       60.0  
   1024x768       60.0  
   800x600        60.3  
   640x480        60.0     59.9  

I will have to plug in external monitor to test this out! /me happy

OOH, radeon-hd is showing just blank screen. So, don't give up upon avido driver yet!

The most useful hint for testing drivers from git is to simply do:

ln -sf /usr/lib/xorg/ /usr/local/lib/xorg

because both of those drivers have tendency to install into /usr/local by default (which is good), but then Debian installed Xorg won't find it. I could have done ./configure --prefix=/usr, but autogen.sh in git repository doesn't have that, and who wants to thing about small things all the time?!

In an effort to bring kernel 2.6 to D-Link DSM G600 device I have been playing with PowerPC emulators in an effort to boot Linux on them (with grand plan of writing support for DSM G600 device if at all possible).

As a start, I tried to boot DSM G600 Linux kernel with qemu. That didn't work quite well... So, I got detoured into trying to make PearPC to boot anything. Darwin kind-of worked until half of installation, but nothing else did. Shame, I really like PearPC debugging capabilities.

So I went back to qemu. And tried, and patched it, and tried again. Didn't help.

However, I had fortune to stumble upon dynamips which is Cisco 7200 (and other Cisco MIPS and PowerPC routers) which was written much more cleanly, and it was able to boot my unmodified DSM G600 kernel after just a few tweaks to load kernel ELF image at beginning of memory as opposed to address which is embedded in ELF file:

setup_arch: enter
setup_arch: bootmem
mpc10x:enter
mpc10x:exit2
Bridge init failed
arch: exit
Memory BAT mapping: BAT2=16Mb, BAT3=0Mb, residual: 0Mb
Total memory is 16777216.
Total memory = 16MB; using 64kB for hash table (at c01f0000)
Linux version 2.4.21-pre4 (dpavlin@brr) (gcc version 2.95.4 20010319 (prerelease)) #523 Wed Sep 5 13:07:36 CDT 2007
Host bridge init failed
Motorola SPS Sandpoint Test Platform
Port by MontaVista Software, Inc. (source@mvista.com)
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/sda3 console=ttyS0,9600
No OpenPIC found !
Calibrating delay loop...

It doesn't go much further than this, but than again, this is also great progress :-)

I also evaluated GXemul which is another multi-CPU emulator (supporting among PowerPC among other CPUs), but it doesn't have MMU implementation for PowerPC, so it wasn't able to map memory around which is needed for Linux boot (it seems). It's again shame, because it does have great debugging...

Anders Gavare answered my e-mail about MMU and I stand corrected:

GXemul has MMU (TLB) emulation for PowerPC. Unix-like OSes (such as NetBSD) require it.

However, different powerpc processors may use different kinds of tlbs, so it is possible that the specific PowerPC processor you want to emulate is not implemented in GXemul.

Now, I would really like to have support for qemu. However, qemu code is all but clean and simple, so this doesn't seem like possible goal, at least for me. But, if I continue to develop emulator based on dynamips or gxemul, I will have to write all hardware support myself.

More information about current status can be found in this forum post.

As I mentioned long time ago, I collected various Broadcom GPL releases and now have a git repository with ones that I was able to found.

Following versions are currently there:

• 3.00.01V
• 3.00.03
• 3.02.02V
• 3.04.01
• 3.04.02V
• 3.06.06
• 3.10.02

Tags are in flux (and will probably mirror branches anyway at some point). Right now different branches have distributions from vendors, but I have to clean a few of them which where imported before I created automatic procedure for import.

Please if you have any Broadcom bcm963xx development kit which is still not in tree, please send it in!

Version of development tree is included in version.make file at top-level:

dpavlin@host:/opt/bcm963xx$ cat version.make 
BRCM_VERSION=3
BRCM_RELEASE=10
BRCM_EXTRAVERSION=02

However, some manufacturers include own version numbers, but most of the time they leave original ones (if you apply some creative encoding to version number variants). However, to be completely sure that version isn't a duplicate you can checkout existing versions using:

git clone git://git.rot13.org/git/bcm963xx.git

Your pushes are welcomed :-)

Repository is quite big, about 600Mb, but it's on fast connection. However, ideas how to reduce that size (I don't think that there is so much changes!) is welcomed from someone who is better in git than me!

For quite some time, I have been happy user of OpenVZ virtualization. And for almost same amount of time, I have been writing vz-tools, a set of few utilities to make work with OpenVZ a joy:

• vz-optimize.pl was written first, and it tries to intelligently increase beancounter limits for VE until there is some requires left for virtual machine.
  Best usage would be to run some kind of stress-test on your VE, and then re-run vz-optimize.pl afterwards to allocate enough resources for VE.
• vz-create.pl is second useful tool which will create new VE from upstream Debian mirror and tweak it a bit (the way I like it)
• vz-clone.pl is latest addition to set of tools and it allows to create temporary clone of virtual machine for testing (of upgrades?) or QA

While those tools work well for me, they don't have much error checking, and most of parameters in them are actually hard-coded. Since, I am having presentation about virtualization on Linux on HrOUG this year, I will probably improve this tools a bit more.

However, I'm not quite sure if this tools would be of general use to somebody else. If it is, please drop me a note, and I would love to improve them a bit more...

Thanks to the amv-codec-tools we now have somewhat working decoder (using ffplay) and encoder (using ffmpeg) of AMV format which cheap s1mp3 players are using.

You can convert video using just Linux box which plays on hardware player (apart from glitz at the end where it sometimes reports format error), but luminance is all wrong: colors are much brighter then they should be. Oh, did I mentioned that frame is flipped so that you can't read text? ;-)

On the bright size, display on players isn't that good, so turning your player under slight angle might make picture quite good.

And player doesn't mind being turned upside-down for video playback...

Anyhow, if you wanted to quickly convert video to your player on Linux box, it has some use, at least for me...

We have part of decoder submitted into ffmpeg upstream, and home to have all part merged when we fix remaining issues. So, if you know something about jpeg, mjpeg or mpeg video, help with croma/luma issue is welcomed. Instructions for download and compile are short and sweet, so dive in!

My quest in finding faster X11 environment lead from WindowMaker to ion3, dwm and finally awesome. I would be very pleased with speed improvement if latest version of awesome didn't have xft support. Now I have to find and disable something I never needed in the first place, ehhh...

Have in mind that I do have laptops with more and more CPU power, so it's not that I use newer versions of software on some old crufty hardware (which I actually do from time to time, but that's not the point). Also, have in mind that I actually do like anti-aliased fonts but not in terminals and window managers.

What's wrong with anti-aliases fonts in terminals?

Glad you asked. Instead of trying to explain that (and failing), do a little test:

• Pick any anti-aliased font in your terminal of choice
• Execute find . in some directory with reasonable amount of files (home dir comes to mind)
• Notice flickering on scroll? After a while it gets better (I guess that xfs cache some anti-alias information)
• Now pick some fixed bitmap font and re-run find .
• If you didn't notice difference in speed and flicker of scrolling you might be using terminal without xft support or bitmap font already.

But, anti-alias can't be that slow!

Nice try... Let's try another experiment. Open your ~/.fonts.conf and add something like:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
 <dir>~/.fonts</dir>
 <!-- bitmap fonts -->
 <dir>/usr/X11R6/lib/X11/fonts</dir>
 <match target="font" >
  <edit mode="assign" name="hinting" >
   <bool>true</bool>
  </edit>
 </match>
 <match target="font" >
  <edit mode="assign" name="hintstyle" >
   <const>hintmedium</const>
  </edit>
 </match>
 <!-- antialias tweaks -->
 <match target="font">
  <test compare="more" name="pixelsize" qual="any">
   <double>9</double>
  </test>
  <test compare="less" name="pixelsize" qual="any">
   <double>15</double>
  </test>
  <edit mode="assign" name="antialias">
   <bool>false</bool>
  </edit>
 </match>
 <match target="font">
  <test name="weight">
   <const>bold</const>
   <const>black</const>
  </test>
  <edit name="antialias" mode="assign">
   <bool>true</bool>
  </edit>
 </match>
 <match target="font">
   <edit name="rgba" mode="assign"><const>rgb</const></edit>
 </match>
</fontconfig>

This is my current configuration, you might want to skip rgba part if your LCD or CRT is different than mine...

Now re-try browsing in firefox (iceweasel, whatever). Do you notice something? Yes, it's faster. Even on dual core T2500. Isn't that somewhat strange?

To be quite honest, I'm running vesa graphic drivers. But, that's because my T60 has ATI Technologies Inc M52 [ATI Mobility Radeon X1300] card which isn't supported under current unstable Debian with any other driver (fglrx from Debian and xf86-video-avivo and/or xf86-video-radeonhd from upstream git). So, I have something to say about drivers also...

Is there any way to make anti-alias faster? Does compiling my own fontconfig might make a difference? I'll have to find out one day if there isn't any response to this post...