The only work I have to do before releasing MaraDNS 1.3.13 is to re-verify that all of the regressions pass, and to perform a standard stress test I like to do before making a new MaraDNS release. The release should be done next week sometime.
The snapshot can be downloaded by clicking on this link
The reason for the delay in making a new snapshot of MaraDNS is because I decided to use Linux again. Ubuntu Linux, even. It took me the last three days to make the appropriate backups, install Ubuntu, and then struggle with getting VMplayer to work in Ubuntu 8.10.
I had a number of problems with VMware player, which I have touched on in previous blog entries. One is that the CentOS 5.2 guest was not correctly set up to handle key repeat speed in a consistent manner. I fixed this by adding divider=10 clocksource=acpi_pm to all of the kernel entries in /etc/grub.conf (in the guest operating system); here is what my grub.conf looks like:
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-92.1.22.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-92.1.22.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet divider=10 clocksource=acpi_pm
initrd /initrd-2.6.18-92.1.22.el5.img
title CentOS (2.6.18-92.1.1.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-92.1.1.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet divider=10 clocksource=acpi_pm
initrd /initrd-2.6.18-92.1.1.el5.img
title CentOS (2.6.18-92.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-92.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet divider=10 clocksource=acpi_pm
initrd /initrd-2.6.18-92.el5.img
Note that this solution is CentOS-specific; search on vmware.com's web site for the "magic recipe" to add to other distributions' kernels.
Another is that the arrow keys and a bunch of other keys do not work. There are two solutions posted various places on the internet; the one that works best for me is the one where we just define all of the keys that don't work with VMware player. I added the following lines to /etc/vmware/config (in the host operating system):
xkeymap.keycode.108 = 0x138 # Alt_R
xkeymap.keycode.106 = 0x135 # KP_Divide
xkeymap.keycode.104 = 0x11c # KP_Enter
xkeymap.keycode.111 = 0x148 # Up
xkeymap.keycode.116 = 0x150 # Down
xkeymap.keycode.113 = 0x14b # Left
xkeymap.keycode.114 = 0x14d # Right
xkeymap.keycode.105 = 0x11d # Control_R
xkeymap.keycode.118 = 0x152 # Insert
xkeymap.keycode.119 = 0x153 # Delete
xkeymap.keycode.110 = 0x147 # Home
xkeymap.keycode.115 = 0x14f # End
xkeymap.keycode.112 = 0x149 # Prior
xkeymap.keycode.117 = 0x151 # Next
xkeymap.keycode.78 = 0x46 # Scroll_Lock
xkeymap.keycode.127 = 0x100 # Pause
xkeymap.keycode.133 = 0x15b # Meta_L
xkeymap.keycode.134 = 0x15c # Meta_R
xkeymap.keycode.135 = 0x15d # Menu
xkeymap.keycode.107 = 0x137 # Print Scrn
Finally, I had serious problems with sound playback stuttering, making it impossible for me to play back all of a single .mp3 file in my Windows XP guest operating systems. I fixed this problem by adding the following lines to the .vmx file for my Windows XP guest operating systems (this is a modification to the relevant .vmx file on the host operating system):
sound.virtualDev = "es1371"
sound.highPriority = TRUE
sound.buffering = "10000000000.0"
sound.copyDelayFactor = "1000000.0"
sound.directSound = "false"
sound.ignoreOverflows = "true"
sound.maxLength = "2048"
sound.smallBlockSize = "1024"
sound.virtualrealcorrection = "10000000000.0"
pciSound.priorityBoost = "true"
I also have these lines describing sound in the /etc/vmware/config file:
sound.Autodetect = true
sound.fileName = "-1"
sound.maxLength = 64
sound.smallBlockSize = 32
But I don't think this second batch of lines help; I had problems until adding the first batch of sound-related lines to my .vmx files.
And, oh, it's only possible to play sound on one VMware guest at a time, and not while playing sounds from other sources. I only use one VMware guest at a time that needs sound (my CentOS 5.2 guest doesn't), and have disabled all sounds in my host's Gnome user interface.
Now, observe that all of these issues are Linux-specific issues. I tested; the Windows XP 32-bit host doesn't have any of these issues (except for the CentOS one, which is caused by the Linux kernel). This is my annoyance with Linux: Things just work on Windows. Things don't work on Linux without spending days tweaking things, for a variety of reasons, mainly serious problems with Linux's sound architecture.
This is why I'm going to use a minimum of applications in Linux; the only real application I will use is VMware, and just do all my work from inside virtual machines I set up. This way, I only have the headache of configuring a minimum of applications:
- The VMware player
- The firewall (I will describe how I set up ufw to protect my system in a future blog entry)
- The core operating system (including things like the sound card, the networking, the video card, etc.)
So, yeah, progress is being made in Linux. It might even be ready for the end-user desktop one of these years.
