Tue, 29 May 2007
Closed Development
Today, my mutt has crashed when
reading a particular spam message. I have looked into this problem,
and discovered that mutt crashes only on our
RHEL4 system (which has
mutt-1.4.1-12.el4), and not on
Fedora systems
(mutt-1.4.2.2-5.fc6).
Report nothing, expect nothing. So I have looked up mutt bug
reports in Red Hat Bugzilla.
I have not found anything related, so I have
filled
a new bug. I have suspected that the problem has been fixed upstream,
so I have ran diff(1) of the RHEL4 source and Fedora source.
And indeed, the difference in handler.c was exactly
the fix
for this bug.
Further communication with Red Hat people discovered that the same bug has already been reported for Fedora Core almost two years ago! I have not found it earlier, because it was marked as "security sensitive", and thus not public.
I think those "private bugs" in Red Hat Bugzilla are severely flawed. I can
understand that they need to keep some reports private for a few days,
for example to be in sync with other vendors from vendor-sec.
But keeping a two years old closed bug private lacks any sense.
I think they should change their policy for private bugs so that
the "private" flag would be strictly time-limited (say to one month).
When longer privacy is needed, it could be explicitly prolonged.
And, of course, no "private" flag on closed bugs.
The same problem is with security update notifications which some Linux vendors (like Red Hat or SUSE) send: they usually refer to the Common Vulnerabilities and Exposures name of the bug fixed, but by the time I get the notification and want to check in the CVE database whether the systems from other vendors are affected as well, CVE still lists the vulnerability as private, with no details available. Talk about making the life of their customers easier :-(
Thu, 24 May 2007
Playing With Multicast
We have our hot-spare router back from repair, and it has been working for a week without crash so far. So I have finally got a chance to play with new features of our network without having to fear that I lose the whole network in case of a misconfiguration. The first thing which was long overdue was native multicast (the second one being native IPv6 on all our networks).
It seems that the basic multicast sending and receiving data works - the following example uses VideoLan Client:
stream-server$ vlc -vvv MyFavouriteAnime.avi --sout udp:239.123.45.67 --ttl 2 stream-client$ vlc -vvv udp:@239.123.45.67
However, it seems only some of the multicast-able hosts on my network can answer to the ping -t 2 -c 2 224.0.0.1. So far I have not figured out
what to do in order to make the remaining hosts answer the above ping.
The Linux multicast routing, on the other hand, is a very sorrowful area.
The HOWTOs are many years old and obsolete, the routing programs like
mrouted or pimd are not being worked on anymore.
The mailing lists and discussion boards are full of questions without
answers, like this one at KernelTrap.
For example, on my router the /proc/sys/net/ipv4/conf/*/mc_forwarding
files are read-only, and the /proc/net/ip_mr_cache file is empty
no matter what I do.
I have yet to try some more tricks mentioned in the above KernelTrap thread. But nevertheless, my dear lazyweb, does anyone have a working Linux-based multicast router?
Wed, 23 May 2007
Bedna 2007
Last weekend I have took part in another puzzle-solving game, Bedna, this time with a team Abpopa. This was my first Bedna, and I think it is interesting to compare it to another similar games like TMOU or Svíčky.
Firstly, Bedna was only in the city of Prague, so there was almost no need for orientation with map, unlike TMOU, where the checkpoints are sometimes very hard to find, especially during the night. Also there were almost no adjancent checkpoints with bigger distance between them. And the weather was nice, even the temperature during the night was above zero. So after 22 hours of Bedna I was less tired than after 17 hours of TMOU.
The second difference was the types of puzzles used there. I think most of them was of the type which can be solved even at home, without being somewhere outside. In other words, Bedna is more focused on puzzles themselves than on the "whole experience" of working hard and not giving up in extreme conditions.
And probably the biggest difference was the system of splitting the competing teams apart for few first hours of the game: they used six different checkpoints for stage 2, which were organized in a cycle. So during the first part of the game, only one sixth of the teams were nearby. This was slightly unfair, as not all distances were equal, but it was definitely way better than the first stage of TMOU 2006.
Bedna has a system for SMS-based communication, which they used for calculating intermediate results (so every team knew its ranking after each stage, and where the best teams were located), and as a last resort help: every stage had a timeout, and the solution was sent to the team after this timeout. This was slightly demotivating, especially at one stage, when we've got the SMS few minutes after finding the correct solution.
The game (as many others) had some bugs: the organizers had screwed up the loop of substages of the stage 2, but this has been neatly fixed by sending SMS notification to the teams. The biggest bug probably was the stage 10, which none of the teams solved. The three teams which went through this stage where those who had arrived to the stage soon enough to get a SMS with solution before the end of the game.
As for our team, an unofficial 12th place is not so bad. We have solved everything, but arrived to the stage 10 too late. We were slow to solve the stage three, just because (from the experience from the similar games) we have tried to solve the task exactly, and spent too much time in it. Anyway, Bedna 2007 was nice, and I look forward to the next year.
Wed, 16 May 2007
Gnome Terminal
A command of the day is the following one:
gconftool-2 --set -t string /apps/gnome-terminal/keybindings/help disabled
From the usability point of view it is pretty annoying, when
gnome-terminal interprets the F1 key as
a command for opening the help window.
Firstly, a pretty straightforward application like this one
does not need any help for basic usage. And for the advanced usage,
the help is already accessible from the menu bar. And the second reason is
that the F1 key (which is rarely used itself) is located too
close to the often-used Escape key on most laptop keyboards.
It was rather annoying when in vim I've got the help window
instead of the Escape key.