Coding goldfish

I have installed Mono 1.9 on Ubuntu. This release also contains the first production release for MonoDevelop, version 1.0. Since it was only just released, it is not yet available as a package to be installed through the Synaptic package manager. So you have to do it manually. I ran into a multitude of problems, so I describe what I had to do below. I hope this post can make your life easier.

Step 0: Describing the scene

The installation was done on Ubuntu Desktop 7.10. There was already an older version of Mono installed, but different Mono versions can be installed side by side.

Step 1: Downloading Mono

Mono can be downloaded on http://www.go-mono.com/mono-downloads/download.html. There is no Ubuntu or Debian specific package, so I used the download for “other Linuxes”, giving me the file mono-1.9_5-installer.bin.

Step 2: Adding missing libraries

At the end, the installer does some checking on whether you have the right libraries needed for Mono to run. They are not needed during the installation itself, but for Mono or MonoDevelop. On my fairly out-of-the-box Ubuntu system, I was missing 5.

I did the installation first, and then found out about the missing libraries. I recommend you to do it the other way around. This way, if the installer doesn't complain, you know you have everything.

1. libglitz1: check in Synaptic whether the package libglitz1 is installed. It provides the library libglitz.so.1. If not, add it.
2. libnspr4-dev: check in Synaptic whether the package libnspr4-dev is installed. It provides the libraries libnspr4.so, libplc4.so and libplds4.so. If not, add it.
3. libgailutil17: check in Synaptic whether the package libgailutil17 is installed. It provides the library libgailutil.so.17. If not, add it. I had a more recent version of this package installed (libgailutil18), but Mono need the version 17. Synaptic could not find this package at first, so I had to add the Debian site as a software source for Synaptic. Instructions on how to add this source is provided on http://packages.debian.org/etch/i386/libgail17/download. Choose a mirror close to you. Once the source was added, the package showed up in Synaptic.

Step 3: Installing Mono

Make the file downloaded in step 1 executable by executing

chmod +x mono-1.9_5-installer.bin

Then launch the installer with root permissions

sudo ./mono-1.9_5-installer.bin

I kept the default settings proposed during installation, which installed mono in the folder /opt/mono-1.9/.

There are some special remarks (http://mono-project.com/InstallerInstructions) for this installer, especially around problems with the installer not running in GTK graphics mode, but I didn't encounter them.

Now that we got so far, let's try to get MonoDevelop going.

Step 4: Editing /opt/mono-1.9/bin/monodevelop

MonoDevelop was written in C#, so it needs mono to run. The shell script /opt/mono-1.9/bin/monodevelop is used to fire up mono to run MonoDevelop. I had to edit this file in two places to straighten out paths.

The variable MD_BIN_PATH on line 56 holds the path to where MonoDevelop is installed. I changed it from

MD_BIN_PATH=/usr/lib/monodevelop/bin

to

MD_BIN_PATH=/opt/mono-1.9/lib/monodevelop/bin

As of line 90, there are 4 different exec lines to start MonoDevelop with the right parameters. In each of them, I changed

/usr/bin/mono

to

/opt/mono-1.9/bin/mono

Step 5: Launching MonoDevelop as root

When I launch the command

/opt/mono-1.9/bin/monodevelop

from the terminal logged in as root, MonoDevelop starts with one warning:

WARNING [2008-03-31 20:44:03Z]: Inotify watch limit is too low (8192).
MonoDevelop will switch to managed file watching.
See http://www.monodevelop.com/Inotify_Watches_Limit for more info.

To increase the Inotify watches limit, type

echo 16384 > /proc/sys/fs/inotify/max_user_watches

at the terminal prompt before starting MonoDevelop. The more permanent solution is to add the line

fs.inotify.max_user_watches=16384

at the end of the /etc/sysctl.conf file. I tried both ways, and they both did the job.

Step 6: Launching MonoDevelop as a normal user

When I launch the command

/opt/mono-1.9/bin/monodevelop

from the terminal logged in as a regular user, it doesn't work. There were 3 things that I had to do before it worked.

Step 7: modifying the .bashrc script

During install, mono has added 4 lines to the .bashrc script of the root user, because I installed mono under the root account to have the necessary access rights on folders. These lines are

export PATH="/opt/mono-1.9/bin:$PATH"
export PKG_CONFIG_PATH="/opt/mono-1.9/lib/pkgconfig:$PKG_CONFIG_PATH"
export MANPATH="/opt/mono-1.9/share/man:$MANPATH"
export LD_LIBRARY_PATH="/opt/mono-1.9/lib:$LD_LIBRARY_PATH"

The same lines were added to the root's .profile file as well.

Now a small warning, because this has caused me a lot of headaches. I don't work directly on my Linux computer, but access it from a Windows computer using NoMachine tools. See my other post about this tool. I don't know if it has anything to do with what I will describe next, but I just give it as a background.

I copied the four lines above from the .bashrc file from the root folder and added them to my own .bashrc file. Next time I logged in (through remote desktop), I got an Xwindows initialization error and could no longer log in to my Linux machine. I had to use SSH to get in console mode and use a text editor (Nano in my case) to remove the 4 lines from the .bashrc file to restore my remote desktop access. Not a clue what was wrong.

I left it to be, shut down all computers, and went to sleep. Next day, I did added these 4 lines again, and now it works! No login problems anymore. No idea what I did wrong. Probably something due to all the trial and error I did, which I can never reproduce again.

Step 8: .config/MonoDevelop folder

Trying again to launch MonoDevelop under my own account gave me the following error.

ERROR [2008-03-30 00:32:06Z]: Add-in error (MonoDevelop.Core.Gui,1.0.0): Add-in could not be loaded: The required addin 'MonoDevelop.Core,1.0.0' is not installed.
Mono.Addins.MissingDependencyException: The required addin 'MonoDevelop.Core,1.0.0' is not installed.
at Mono.Addins.AddinSessionService.ResolveLoadDependencies (System.Collections.ArrayList addins, System.Collections.Stack depCheck, System.String id, Boolean optional) [0x00000]
at Mono.Addins.AddinSessionService.ResolveLoadDependencies (System.Collections.ArrayList addins, System.Collections.Stack depCheck, System.String id, Boolean optional) [0x00000]

This problem has already been reported many times on the web, and the fix is typically to just erase everything in that folder, so I did. MonoDevelop uses this folder to store its config.

Step 9: undefined symbol: gzopen64

Ok, trying again to launch MonoDevelop under my own account. Now I get the following error:

monodevelop: symbol lookup error: /usr/lib/libxml2.so.2: undefined symbol: gzopen64

To fix this, replace the file libz.so.1.2.1 in /opt/mono-1.9/lib/ with libz.so.1.2.3.3 from /usr/lib. Credits for this solution go to D. Dobrev.

Step 10: The moment you have all been waiting for

In a console window, I tried again

/opt/mono-1.9/bin/monodevelop

and MonoDevelop launched. A moment of joy.

Recently, I've purchased a second hand Pentium 4 PC to play around with Linux. I had used Linux a little back in 1994 till 1996 when I was in college, but never really touched it again since. Once installed, I wanted to access this PC through remote desktop so I don't need a dedicated screen or a KVM switch to use it. Just a PC connected to the LAN. 

I installed Ubuntu Desktop 7.10 and SSH was activated by default. I have the PuTTy client installed on my Windows PC and could immediately connect to the Linux box. But this is only console access, not desktop access.

Through Google I came to NoMachine NX product range. Next to remote desktop, it seems that their products are also more Citrix-like solutions but I haven't investigated in detail since that was not what I was looking for. They have a free edition that allows for two concurrent connections. The reviews I found were very positive, so I decided to give it a try.

Installation was very easy. The NX free edition exists of 3 packages, client, node and server, which have to be installed in this order. I choose the Debian packages (deb) as I'm running Ubuntu. On downloading, FireFox immediately proposed to open the downloaded .deb file with the GDebi Package Installer, making installation as easy as can be.

On my Windows PC, I installed the NX client. This is a classical install, nothing special. When I tried to connect to the Linux box, it worked immediately. I didn't have to change anything in the config of the NXserver for it to work. Great! The only thing I had to change was the keyboard layout. It looks at the settings of X windows rather than Gnome.

There is only one strange behaviour. I have to switch the numlock off on my Windows PC for it to work through the NXclient on Ubuntu. In a message from 2004, NoMachine announced version 1.3.1 which resolves a “NumLock and cursor keys mix-up” bug, but apparently it re-appeared 4 years later in the version 3.1.0 I installed.

There are different reasons for having an audit trail on your data. Some companies have to because of legal obligations, such as Sarbanes-Oxley or FDA regulations. But I also find it very useful for debugging purposes. It shows you what was in your database at any point in time.

So how to implement an audit trail? Different visions exist. The one I prefer is to use a shadow table for each table that exists in the database. Every time a record is inserted, updated or deleted in a table, the record is also inserted in the corresponding shadow table. For inserting the record also in the shadow table, I use triggers on the original table that will fire whenever something happens. Other names you may encounter on the web for shadow tables are archive table or audit table.

The big advantage of this method is that if originally you did not foresee audit trailing, you can add it afterwards. The only thing you need to do is add the triggers on the base tables and create the shadow table. No changes have to be made to stored procedures or applications working with your database.

To make the implementation of the audit trail easier, I wrote a script to automate the creation of shadow tables and triggers. You can download the code here. If you would like some more background, please see my article on the subject on Code Project.