Wed, 31 May 2006
The other Iva
A week ago, I wrote about using Ekiga as a
videophone. Iva found another interesting way to use Ekiga - as a toy for
Iva. We call the remote echo test (ekiga.net has
sip:500@ekiga.net test number), enable the video loopback,
and put the audio to the speakers.
Iva gets extremely excited when she sees and hears herself (with a little
delay) in the softphone. She yells "Hello, Iva!" to the microphone, and waves
to the picture of herself. I think that because of the latency and because
usually people hear themselves in a different tone when they are speaking
than when the recording of their voice is being played back, she probably
thinks that the girl in the picture is not herself. I hereby appologize to
ekiga.net for abusing their bandwidth :-)
Anyway, I think the video telephony is definitely useful - now I can see my family even when I am at work. The only problem is that the picture of myself (which I have to display in order to stay in the viewing angle of the camera) it is pretty confusing: The image is displayed in a straight way, while my brain probably expects to see myself in a flipped image like in a mirror. So staying in the picture is difficult even with a visual feedback - I often move myself to the opposite side than I need to.
0 replies for this story:
Reply to this story:
Tue, 30 May 2006
MIME::Words and UTF-8
We use the
MIME::Words
package from CPAN to handle encoding
and decoding
the RFC 1522-style
e-mail headers (those =?UTF-8?Q?something=20something?=-like texts).
Long time ago I have found that this package had a bug - when encoding two
adjacent words the inner whitespace should be added to the first or the second
word, because the whitespace between the two adjacent encoded words is discarded
during decoding. When moving our system to UTF-8, I have decided to install
a new MIME::Words module, and I wondered whether this bug is fixed.
In the manpage, they wrote:
It does not comply with the RFC-1522 rules regarding the use of encoded words in message headers. You may want to roll your own variant, using encoded_mimeword(), for your application. Thanks to Jan Kasprzak for reminding me about this problem.
So they did not fix the problem reported 3-5 years ago, they just acknowledged its existence (even with my name :-). The module also does not handle multi-byte characters (in UTF-8 strings) correctly, and defaults to the ISO-8859-1 encoding instead.
I have decided to fix this module, solving both the problem of two adjacent encoded words, and the problems of encoding/decoding from/to the multibyte strings. Here is the patch for MIME::Words and UTF-8. Hopefully they will apply it soon.
9 replies for this story:
adelton wrote: Encode.pm
I'd say that Encode with the encoding 'MIME-Header' is my favorite way to go nowadays.
Yenya wrote: Re: Encode.pm
Hmm, it apparently works, but it does not say a word about it in the Encode.pm manpage. Moreover, it encodes the whole string as UTF-8 Base-64, which misses the whole point of it (encode only non-ascii parts). So you cannot do Encode::encode("MIME-Headers", $the_whole_message_headers_part);
Yenya wrote: Encode.pm
It apparently has broken line wrapping: it produces lines > 75 chars, and when the encoded line is slightly over 80 chars, the result is "newline-space-encodedword-newline-space-encodedword" instead of "encodedword-newline-space-encodedword".
adelton wrote: ASCII parts
perl -CSAD -MEncode -e 'use utf8; print Encode::encode("MIME-Header", "Krtek Simonsen"), "\n";' Krtek Simonsen So for ASCII-only data, it gives you that string back. As for the Base-64, you can use MIME-Q to have the string more readable: perl -CSAD -MEncode -e 'use utf8; print Encode::encode("MIME-Q", "krteček"), "\n";' =?UTF-8?Q?krte=C4=8Dek?=
adelton wrote: Formatting
Blueeehee -- how do you post a snippet of code here?
Yenya wrote: Re:: Formatting
Try encoding "maličký ježeček a jeste nejaky ascii text" - it gets encoded to Base64 as a whole. With MIME-Q it is even worse.
adelton wrote: As for the folding ...
As for the folding, yes, MIME-B does start with newline+space, while MIME-Q does not. Therefore MIME-Q is nicer. ;-) Anyway, since Encode is in the standard Perl distribution, I think that this module should be used whenever it is good enough for the task at hand. So maybe patching Encode::MIME::Header (instead of MIME::Words) is more useful?
adelton wrote: Patch for Encode::MIME::Header
Does this change to $re_especials look reasonable? How is it with wrapping unencoded words? my $re_especials = qr{$re_encoded_word|(?:\ +|^)[\x00-\x7f]+(?:\ +|$)|$especials}xo;
Yenya wrote: Re: Patch for Encode::MIME::Header
I will test it (hopefully) soon, sorry for the delay
Reply to this story:
Thu, 25 May 2006
Kernel upgrades, crashes
Yesterday I have upgraded the kernel in our main server to the newest stable, 2.6.16.18. The server ran pretty historical kernel 2.6.11.10, because newer kernels had some problems in XFS on this setup. But even the older kernel has crashed from time to time. The 2.6.16.18 booted fine, I did few additional tweaks, and put the server back to the production use. Today, however, some problems appeared:
We have found that NFS clients using volumes from this server cannot lock
files using fcntl(). According to tcpdump,
the server just did not respond to the RPC locking requests. However, the
same kernel version on a different server, and with the same line in
/etc/exports, worked correctly, even with file locking.
I think the difference was in the NFS server utils, which are older
in the prodution system (RHEL3) than in the other server (FC3). However,
I couldn't recompile newer NFS utils, because it depends on the newer
version of Kerberos libraries. I was about to reboot the server back to
the older kernel, when it
crashed on me. I am back on 2.6.11.10 and I will probably wait till we upgrade
this box to RHEL4. If the problem is the same then, I will probably make
it a Red Hat problem.
When testing the NFS with the newest kernel on that other box, I have found
that the 3ware driver
does
not work with the iommu=off boot option.
I wonder if akpm is right about the kernel getting buggier.
Moreover, it seems that the Tyan S2882 board does not boot correctly, when
the power-on memory test is interrupted by pressing the Escape
key (MCE is reported, or the server just silently reboots when loading the
kernel). At first I thought the server was dead, when even the original
kernel refused to boot.
0 replies for this story:
Reply to this story:
Tue, 23 May 2006
Videophone
For a long time, Ekiga (and GnomeMeeting before that) had support not only for voice, but also for video. I did not have time nor hardware to test it yet. Today I have finally managed to borrow some webcams from my Windows section coworkers.
The good news is, that apparently everything works more-or-less correctly.
I have plugged in the first webcam (labeled Creative Labs),
using lsusb discovered that it is in fact an OV-511 device,
using Google I have found that there is indeed a driver named
ov511, even included
in the standard kernel. After compiling and installing this module, Ekiga
immediately worked (I had to use the V4L driver, not V4L2),
and I was able to do both audio and H.264 video transmission while
calling their test URL sip:500@ekiga.net.
Even calling home worked (after enabling the video support on the remote Ekiga). The only slight annoyance with this (rather old) webcam is, that the viewing angle is too narrow, and I had to be careful not to move my head too much in order to stay in the picture.
The second webcam was newer - Logitech QuickCam 4000 Pro. It can be driven
by a Philips USB webcam driver,
which is also included in the mainstream kernel. When trying to use this webcam
with Ekiga or Mplayer, only a gray rectangle was shown. I had to use the
setpwc utility to
change the camera settings in order to get a reasonable image instead of
a gray rectangle. Sample settings are shown in the PWC webcam wiki (see the question
about setpwc for the sample parameters).
I was surprised how easy it was to setup a software videophone under Linux. There are some projects left to the future explorations - for example using a built-in microphone in the webcam, or using the servos and some motion detection software to keep the head in the picture. Finding a good SIP softphone for Windows for my inlaws would also be an interesting project.
0 replies for this story:
Reply to this story:
Sat, 20 May 2006
Japanese exam
After one semester of the Japanese language course, I took part in an exam yesterday (together with Oozy). It was my first exam after maybe eight to ten years.
I think I managed to learn both Hiragana and Katakana well, but I am weak at vocabulary. Fortunately the exam questions did not contain any words I did not manage to memorize.
I have made one mistake, which I am ashamed of: I wrote the MU (ム) letter instead of MO (モ) in the transcription of the term "leMOn tea". Apart from that, the exam was OK, and we have passed. We want to enroll to a summer course, so that we can start from the third level instead of the second one the next semester.
0 replies for this story:
Reply to this story:
Fri, 19 May 2006
Wikipedia walks
It is interesting what can be found by just following the internal links on Wikipedia pages: I have looked up the phrase D'oh! (being non-native English speaker I really did not know its origin). Then, of course, I clicked on the page about Homer Simpson, and I have found that he is (apart from other categories) listed in a fictional alcoholics category.
So I wondered who else is considered to be a fictional alcoholic, and found Misato Katsuragi, my favourite Neon Genesis Evangelion character, listed there (well, is starting a day with a single can of beer considered being an alcoholic?).
I then followed to the page about Rei Ayanami. It contains an insane amount of details, speculations, and trivia. The most interesting information for me was, that even Rei's surname is taken from the WW2 Japanese ship (I already knew that some Evangelion characters' surnames are taken from the WW2 Japanese ships - for example Akagi or Sohryu - but it seems almost all of them are (see the question 3.4 in the previous link).
From general English catch phrase to Japanese destroyers in five or so clicks. Not bad, isn't it? Also, it seems that Wikipedia is especially strong in fictional characters. I have found such a big number of details there to which even a "specialized" site like AnimeNFO or AniDB cannot compare.
0 replies for this story:
Reply to this story:
Wed, 10 May 2006
Lock bumping
I always enjoyed reading Surely You're Joking, Mr. Feynman!, including the part about Feynman's hobby of lock-picking. As with computer security, I believe that for any massively deployed security technology (including the locks), security-through-obscurity is not a way to go, because the black hats have a big headstart there. Today a friend of mine sent me an interesting set of links about a new (or maybe not so new?) lock-picking technique, called lock bumping.
Firstly, here is a video from some Dutch TV, describing the lock bumping, and then there is a paper on lock bumping (PDF), written by people from Toool - The Open Organization Of Lock Pickers. The method itself is pretty interesting - it needs just a regular key with the deepest possible set of cuts.
I wonder whether the lock in my house is vulnerable to this attack - it is not listed by Toool as vulnerable, but who knows? I want to try this myself, but I am short of time these days ...
Anyway, this paper reminds me of the "Master Keyed Lock Vulnerability" paper, and I think the full disclosure is slowly taking off even in this area, which is a good news.
1 replies for this story:
Vasek Stodlka wrote: My Mul-T-Lock is vulnerable too
The question is - is it good or bad? I had allways been scared what happen, if i loose a key. Now i know that i can help myslef, but my perfectly safe armored door is not so safe for me now. :/
Reply to this story:
Tue, 09 May 2006
Why not microkernels?
I teach UNIX at our faculty. When thinking about the general principles of the operating system design, I still find the 1992 debate between prof. A. S. Tannenbaum and Linus Torvalds quite interestng. Today, a new paper by prof. Tannenbaum on this topic has been discussed on SlashDot. I think this comment neatly sums the problem up:
Kernels don't often crash for reasons related to lack of memory protection. It's quite silly to imagine that memory protection is some magic bullet. Kernel programmers rarely make beginner mistakes like buffer overflows.
Kernels crash from race conditions and deadlocks. Microkernels only make these problems worse. The interaction between "simple" microkernel components gets horribly complex. It's truly mind-bending for microkernel designs that are more interesting than a toy OS like Minux.
Kernels also crash from drivers causing the hardware to do Very Bad Things. The USB driver can DMA a mouse packet right over the scheduler code or page tables, and there isn't a damn thing that memory protection can do about it. CRASH, big time. A driver can put a device into some weird state where it locks up the PCI bus. Say bye-bye to all devices on the bus. A driver can cause a "screaming interrupt", which is where an interrupt is left demanding attention and never gets turned off. That eats 100% CPU. If the motherboard provides a way to stop this, great, but then any device sharing the same interrupt will be dead.
I think the problem is often the same with any other academic research versus the real world (sometimes even for research at our faculty - no, I would not be more specific here :-) - usually it is much more simple and nice to create something for research purposes only, and it is much harder, dirtier, and often not better than other (non-"scientific") approaches to apply the results in the real world.
1 replies for this story:
Milan Zamazal wrote:
I don't think there is any special separation of academic research and the real world in comparison with other areas. Problematic design can occur anywhere. Making something cleaner while introducing unwanted complexity elsewhere is a common mistake. And things are worse in business, because business often has the power to actually spread its inventions. BTW, a very typical example of making things clean while making them more difficult is Scheme (trying to "fix" Lisp).
Reply to this story:
Sun, 07 May 2006
Dual seat X and the evdev driver
I use dual seat X11 config (two graphics cards, two mice, two keyboards) at home. I had problems with this setup in Fedora 5, because this distribution is based on X.org release 7.0. Today I have finally made this working.
Firstly some background: in pre-7.0 versions of X.org/XFree86, the X server
needed to be patched. The first part of the patch implemented the keyboard
driver for the Linux event interface (/dev/input/eventN devices),
in order to use the USB keyboard, and the second part removed the code which
disabled all the other VGA cards present in the system when starting the X
server, disabled VT locking/switching code, etc.
Now it seems the 7.0 release is much cleaner with respect to multi-seat
configs. The X server has options for interoperability with other X servers
running on the same host (-sharevts -novtswitch -isolateDevice),
and there is a brand new evdev driver, which implements
the event interface handler not only for keyboards, but also for mice.
There is a big problem, though: the evdev driver in FC5 is not compatible with XKB.
Because Pavlína is back home and she needs the second head working,
I have decided to try to solve this. I have installed the new
xorg-x11-drv-evdev package from Rawhide (together with the
rest of X packages). It mostly works, but I had to patch (fd.o bug #3912) the XKB files
for the new "evdev" keyboard model. My keyboard config in xorg.conf is now the following:
Section "InputDevice"
Identifier "USBKeyboard"
Driver "evdev"
Option "Protocol" "evdev"
Option "Device" "/dev/input/event1"
Option "XkbModel" "evdev"
EndSection
The new driver does not support any other device name than eventN, so I had to hardcode the device name to the config, instead of using the udev-based rule for symlinking to the right device (in case the devices are plugged in or recognized in a different order).
I use the following command to set up the US+CZ keyboard:
setxkbmap -model evdev -keycodes evdev us,cz_qwerty -option grp_led:scroll,grp_mode:switch,grp:shift_toggle
So finally, the multi-seat config is working for me even in FC5. And it seems the X.org 7.0 took much cleaner path to this than the previous releases. It is still not without glitches, but I think the direction is correct. The most important part is, that the multi-seat config is now supported in the X.org release, without patching and recompiling the X server.
4 replies for this story:
lzap wrote: Card?
What graphics card do you use?
Yenya wrote: Re: Card?
00:13.0 VGA compatible controller: NVidia / SGS Thomson (Joint Venture) Riva128 (rev 10) 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (rev 01)
carlos gomes wrote: patching the XKB files?
"It mostly works, but I had to patch (fd.o bug #3912) the XKB files for the new "evdev" keyboard model" How do you do that? How to patch the XKB files?
Yenya wrote: Re: patching the XKB files?
The patches are described in that freedesktop.org bug #3912, AFAIK.