It is very simple actually, as the configuration of a proper machine is already included in the OpenMSX distribution. If you are curious, look for these files: machines/Gradiente_Expert_1.1/hardwareconfig.xml and extensions/DDX_3.0/hardwareconfig.xml.

All that remains to do is to find the correct ROMs and use the correct command line options. Finding the ROMs is quite easy: ask Google. Put the ROMs in ~/.openMSX/share/systemroms/. The final command line should be something like:

$ openmsx -machine Gradiente_Expert_1.1 -ext DDX_3.0

• Uses a buggy TLS implementation.
• Has activated encryption for s2s connections starting in February.

As GTalk connectivity is very important for any open Jabber server, many servers have published workarounds for the problem. Here is a patch for jabberd2. A new release (2.2.7.1) of jabberd2 was also made to address the issue.

I have jabberd2 2.2.4 in my server. For some reason, I could not make 2.2.7.1 work because of some problems with the Berkeley DB back end. I ended up applying this patch to 2.2.4 and it fixed the problem. I also created a bug report in the Fedora Bugzilla, so maybe a fixed package will be pushed as an update.

As usual, there are some sore spots. And I seemed to attract a lot of bugs this time. For example, among the most common bugs in F9, I got two: "Synaptics touchpad touching to tap doesn't work" and "Samsung hard disks crash the installer". The last one was a real problem and I ended up upgrading using YUM, which I don't recommend if you have a lot of installed packages and have to suffer ridiculous Brazilian "broadband" speeds.

But it gets better. I was hit by more obscure stuff: While installing Fedora on the university cluster I discovered that Anaconda doesn't work right now with static IPs. I ended up setting a DHCP server just for installing Fedora. Also, due to a rewrite GDM XDMCP support is broken. I must be one of the two guys who still use XDMCP to power an old terminal and share the (relatively) powerful desktop. I worked around it by enabling KDM instead of GDM.

The annoying thing about these bugs is that most of them were found on the beta testing period of F9, and none were corrected for the final release. At least, I don't have to feel guilt for never trying one of the preview releases. ;)

Finally, this isn't a bug proper, but I hope I can help someone with the same problem. If your numeric keypad stops working mysteriously, go to the "Assistive technology" preferences and disable the "Mouse keys". It was enabled magically during the upgrade and took me bit of time to figure it out.

interface eth0
{
        AdvSendAdvert on;
        MinRtrAdvInterval 30;
        MaxRtrAdvInterval 100;
        prefix 0:0:0:1::/64
        {
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr off;
                Base6to4Interface eth1;
        };

};

And so I did. Like 99.999% percent of Internet users I don't have a native IPv6 connection, but enabling a IPv6 tunnel on Fedora is very, very easy. I decided for the simplest type of tunnel, called 6to4. This type of tunnel is very convenient as I don't need to register it anywhere nor do I need to ask permission to anyone. It is based on the kindness of people that run 6to4 routers in the IPv4 Internet at the 192.88.99.1 anycast address. Usually people disregard this type of tunnel as being slow, but routing from Brazil to the world is already so slow I found the performance acceptable. Besides, there isn't much yet to do in the current IPv6 Internet.

Enabling a 6to4 tunnel on Fedora is ridiculously simple. First put the following lines in /etc/sysconfig/network:

NETWORKING_IPV6=yes
IPV6_DEFAULTDEV=tun6to4
IPV6FORWARDING=yes

The last line is only required if you are going to share the IPv6 connection with a local network. The rest of this recipe assumes you are. Now find the configuration file for the interface connected to the Internet. If it is eth1 the file should be /etc/sysconfig/networking/devices/ifcfg-eth1. Put the following lines there:

  IPV6INIT=yes
  IPV6TO4INIT=yes
  IPV6_CONTROL_RADVD=yes
  IPV6TO4_ROUTING="eth0-:1::1/64 wlan0-:2::1/64"

Once again, the last two lines are only required if you have a local network you want to provide with IPv6 connectivity. If not, remove the extra lines and you are set. Restart the interface and you are connected to the IPv6 Internet! When using 6to4, probably due to the performance concerns, Fedora prefers IPv4 addresses. So, go to a IPv6 only site (like http://www.ipv6.bieringer.de/) to test it. And remember to define a IPv6 firewall. Your current iptables firewall only covers IPv4, use ip6tables to create a IPv6 one.

A nice thing about this setup is that a 6to4 tunnel gives me a whole /48 netblock based on my IPv4 address. So, no NAT in my local IPv6 network! The last two lines lines above allow the networking scripts to control the RADV daemon and to create IPv6 addresses to other interfaces (besides the one you are actually configuring). Just treat the /48 of your 6to4 address as a prefix and create a /64 netblock for each interface. Create a /etc/radvd.conf file with an entry like this for each interface:

interface eth0
{
        AdvSendAdvert on;
        MinRtrAdvInterval 30;
        MaxRtrAdvInterval 100;
        prefix 2002:XXXX:XXXX:1::/64
        {
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr off;
        };

};

Where 2002:XXXX:XXXX is your automatically configured 6to4 adress. Start RADV daemon and the hosts in you internal network should receive an automatically generated address.

For me, the next step would be to do the same to this site and add a little bit more content to the IPv6 Internet. Unfortunately, the Xen kernel used by my VPS provider doesn't support stateful iptables support for IPv6. I though IPv6 support on Linux was a done deal, but this critical functionality was only added about and year ago in kernel 2.6.20. It seems IPv6 may be a bit farther in the future than I expected. But it was surely fun to set it up anyway.

PulseAudio is one of the great features introduced in Fedora 8. I really enjoyed the good work that went into integrating PulseAudio and Fedora. It really is seamless, except for the odd bug in alsa and proprietary applications. Here are two things I discovered regarding pulse audio.

First: PulseAudio shows a simplified but functional interface to control sound, and to support Alsa applications transparently, it appears as the default virtual device hiding you hardware device. Problem is, if the hardware device is muted or has the volume set too low, there is nothing you can do through the PulseAudio interface to make sound work. Obvious as it seems, you have to first enable and adjust the volume of the relevant inputs in the hardware device, and then be able to enjoy PulseAudio. You can use the alsamixer -c [0...7] command, changing the -c argument until you find your hardware device, set it up, and you are ready to go. The good news is that, once it is done, applications (such as Skype) won't be messing with your hardware device as PulseAudio hides it.

Second: to enable the PulseAudio daemon in you GNOME session, you need to go to System|Preferences|Hardware|Sound and enable ESD. That's really stupid, they should have changed the label, but this control really creates an instance of the PulseAudio daemon. If it isn't running, sound won't work. I discovered this because ESD gave me a lot of problems in the past and have been deactivated in my GNOME preferences for a long time. It never occurred to me to enable it to fix Alsa applications that suddenly stopped working. But, again, once you discover that, everything just works.

Remember people: release early, release often!

diff -ru openser-1.2.2-tls.orig/modules/postgres/db_res.c openser-1.2.2-tls/modules/postgres/db_res.c
--- openser-1.2.2-tls.orig/modules/postgres/db_res.c    2007-08-16 11:23:05.000000000 -0300
+++ openser-1.2.2-tls/modules/postgres/db_res.c 2007-11-25 08:23:53.000000000 -0200
@@ -572,6 +572,7 @@
         * If this is not done, a memory leak will happen.
         */
        for (col = 0; col < ROW_N(_row); col++) {
+         _val = &(ROW_VALUES(_row)[col]);
           switch (VAL_TYPE(_val)) {
             case DB_STRING:
               LOG(L_DBG, "PG[free_row]: %p=pkg_free() VAL_STRING[%d]\n", (char *)VAL_STRING(_val), col);

The silver lining in this was that it was quite easy to find a solution to this problem. Before OpenSER I used for some time the original SER, and I can tell you, it is almost impossible to find some help on the web. Both because SER is a lousy name to base a Google search :) and because the project isn't quite transparent as a proper open source project should be. So, congratulations to the OpenSER developers! And remember, release early, release often!

As my version of K9Copy is newer than the one packaged by Livna, I will keep it a bit longer. When Livna catches up, I will remove it from the site. See, I actually like being obsoleted. :)

GTK2 had this same bug about 5 years ago, and they solved it by creating the "cedilla" input method, and selecting it according to locale. Guess the Emacs guys will have to go the same route. Meanwhile, a simple workaround is to fire up Emacs in a ISO-8859-1 locale: "$ LC_ALL=pt_BR emacs" and as soon as the program opens up, select "Options|Mule|Set Language Environment|UTF-8". It isn't pretty, but as I use the US keyboard only rarely this works for me.

If you are an user of the hash driver, you can't rely on the provided tools to maintain your installation. The recommended way of cleaning old messages signatures doesn't work for this driver. Also, the hash-based database has to be cleaned from time to time or it will grow too big, but the tool to do it (cssclean) just doesn't work. To handle these problems, I first had to patch DSPAM so I could get a working cssclean. The main patch was created by Frank Cusack and you can get it in his aptly named message "cssclean is a redheaded stepchild" to the dspam-dev mailing list.

The second patch isn't strictly necessary (and I fear it might violate some design principle of DSPAM), but it keeps cssclean from resetting the statistics of the database. I really can't remember where I found it, so I post it here:

diff -ru dspam-3.8.0.orig/src/tools.hash_drv/cssclean.c dspam-3.8.0/src/tools.hash_drv/cssclean.c
--- dspam-3.8.0.orig/src/tools.hash_drv/cssclean.c      2006-05-27 18:00:36.000000000 -0300
+++ dspam-3.8.0/src/tools.hash_drv/cssclean.c   2007-06-27 19:18:51.000000000 -0300
@@ -167,7 +167,7 @@
     header = offset;
     filepos += sizeof(struct _hash_drv_header);
   }
-
+  bcopy (old.header, new.header, sizeof(struct _hash_drv_header));
   _hash_drv_close(&new);
   _hash_drv_close(&old);
   rename(newfile, filename);

Finally, I run the following script monthly using cron:

# Clean hashes and signatures.
for u in /var/lib/dspam/data/*/*.css; do
    /usr/bin/cssclean $u
done
find /var/lib/dspam/data -name *sig -type f -mtime +30 -exec rm -f {} \;

Probably you will have to adapt it to the file locations of your DSPAM installation.

So, I need microsecond precision for the sleep. It is widely known that this is impossible in Java 1.4 without some native code. Fortunately, in Java 5 it's pretty easy to get nanosecond precision and this blog entry is very, very informative. Briefly, if you want to measure a time delta with nanosecond precision use System.nanoTime(), if you want to schedule a (possibly recurring) event with the same precision use the ScheduledThreadPoolExecutor class. I ended up using the former for my code.

But now, the weird part. Along with System.nanoTime(), Java 5 introduced the Object.wait(millis, nanos) and Thread.sleep(millis, nanos) methods for high resolution sleeps. Take a look at the source code for the implementation of these methods here (gotta love free software!). See. These methods just round up or down the millisecond argument using the nanosecond argument and call the millisecond only version of the methods. It took me some time and a bit of frustration to notice this. Annoying. You might be wondering: how the heck is ScheduledThreadPoolExecutor implemented then? The answer is another sleep method introduced in Java 5: LockSupport.parkNanos. This one actually works, as it uses a different native implementation.

In the tweaks section of the FC6 image at Jailtime.org it is said:

To resolve tls issues, issued the following commands (*):
  # cp /lib/i686/nosegneg/lib* /lib/i686/
  # ldconfig

The problem with this hack is that when you upgrade your glibc, the copied files will remain and will conflict with the new updated files. This is not theoretical, right now if you download and run the image, then execute yum upgrade your VM is hosed. End result, segmentation faults all around and you VM won't boot anymore.

To avoid the problem, remove all files copied into /lib/i686:

# rm -f /lib/i686/libpthread* /lib/i686/libc* /lib/i686/libm* \
        /lib/i686/librt* /lib/i686/libthread_db*

The alternative to fix TLS problems is proposed on the Jailtime.org site itself:

An alternative to the tweak above is to use the following commands:
  # echo "hwcap 0 nosegneg" > /etc/ld.so.conf.d/libc6-xen.conf
  # ldconfig

But it came with the cryptic warning that "This alternative did not work in the jailtime image however". Well, it does work with the Jailtime.org image.

By the way, after this issue was solved, I was able not only to update FC6, but to upgrade to F7 using Yum. The only extra step necessary is to make sure in the newly installed /etc/rc.d/rc.sysinit has the /sbin/start_udev line is commented out. Also, for some strange reason, the libgcc and libstdc++ packages have a higher version number in FC6 than in F7, so you will have to update these two by hand. Besides that, just follow this procedure.

I setup Pyblosxom as a non-root user, serving it from my public_html. To do this in Fedora you have to uncomment in the httpd.conf files the lines controlling UserDir directories and add the following to enable CGI from the public_html:

<Directory /home/*/public_html/cgi-bin/>
    Options ExecCGI SymLinksIfOwnerMatch
    SetHandler cgi-script
</Directory>

With that out of the way, just install Pyblosxom as described by its documentation. The only twist in my setup is that I hide the name of Pyblosxom CGI script from my URLs and make the root of my page redirect to the blog root. This is accomplished with a bit of Apache rewrite magic. Put this .htaccess file in your public_html:

RewriteEngine on
RewriteBase /~replace-with-your-user-name
RewriteRule ^$ blog/ [R=permanent]
RewriteRule ^index.htm.*$ blog/ [R=permanent]
RewriteRule ^blog$ cgi-bin/pyblosxom.cgi
RewriteRule ^blog/(.*) cgi-bin/pyblosxom.cgi/$1

Configuration of Pyblosxom is best covered in its manual, but here is a tip I missed the first time. When customizing a flavour (and that's exactly like maintaining some server side includes), you can just copy the default html.flav dir to your local flavour dir; Pyblosxom will always pick the locally defined one overriding the default, so you don't have to call it anything different than "html".

Besides Pyblosxom, some HTML and CSS, I use the following Pyblosxom plug-ins:

• pystaticfile.py: To have some non-blog entry, non-dated pages rendered with the same layout.
• pagetitle.py: To have the entry title display at the page title (be sure to read the documentation in the source file).
• wbgarchives.py: For compact archive links.

There are many other plug-ins available, and it doesn't seem to be really hard to code a new one in Python.

For a long time I have kept copies of fMSX lying around in my hard disk, in case I want to play some of the memorable games of my childhood. Problem is, I was having a hard time compiling it in recent systems. When looking for a alternative, I investigated OpenMSX and instantly recognized I had found the holy grail of MSX emulation. OpenMSX does not emulate one MSX implementation, it implements all of them. It isn't just a matter of playing the games, you can really relive the hardware with it.

For example, I was able to boot a Gradiente Expert 1.1, with the DDX-3.0 floppy controller and a MegaRAM cartridge just like it was 1988. I'm really sorry now that I haven't managed to make images of all my floppies.

As an extra bonus, OpenMSX is very Linux friendly and very easy to build. So I created a RPM package of it for Fedora, instead of just installing in my home dir. I don't know if I will be able to properly maintain it, but if you are interested check the OpenMSX RPM link in the nav bar.

As it isn't available in the Livna repository, I created a RPM of it for Fedora. Check the K9Copy RPM link in the nav bar.