For some years, there have been a few incompatability which turn users off linux. They are more configuration issues than anything else and probably windows is to blame, and specificly PuTTY. Let me explain the problems and then the solution.

Issue 1. UFT-8. UFT-8 is a Unicode encoding which uses variable length strings of 8 bit bytes to encode a character. The first 127 characters are the same as the ANSI characters which makes compatability easy. The problems start when the odd character above 127 gets thrown in but is not respected as the start of a unicode character. This is easily seen in man pages when ‘ turn into â. For the most part you can work around it but it is easy to fix.

The environment variable LANG indicates the current language. On modern linux distros which support unicode, it may well be set to something like ‘en_AU.UTF-8′. This indicates my language, country and unicode support. The simple fix is to set the language to ‘en_AU’ if my terminal does not support unicode.

Now this is all fine until you start using PuTTY to connect from windows, which I find most windows users do. Now your login script has to be able to turn of UFT-8, only if you are using PuTTY. Read on…

Issue 2. Colors. There are a number of factors which impact on the default color selection for programs like ls and vim. The biggest seems to be the terminal type as specified by the TERM environment variable. Common values are linux, vt100, vt220 and xterm. (There are hundreds of others). Now unfortunatly, assumptions are make like ‘the linux console background color is always black’ and ‘the xterm background color is always white’. This do not hold true, mostly because TERM indicated the terminal ‘emulation’, not the terminal it’s self. For example, by default, PuTTY reports that it does xterm emulation but it is clearly a windows program and is only emulating this. This issue is a bit harder to solve because there are many places were color information can come from (see /etc/profile.d/vim.sh). The TERM variable should match your terminal or your output will not be correct and expecting all users to correctly reconfigure there terminal is not realisting. A server side solution is required.

Solution Part 1. Anyone who has accidently viewed the contents of a binary file may well have ended up with PuTTY written all over the screen. This is a giveaway that you can query the terminal for information. (This is also a security issue, but for now it works in our favour.) (If you did view a binary file and now your text is broken, try the ‘reset’ command). Many terminals respond the the character 0×05 by sending the terminal type as a string, just as if the user had typed it on the keyboard. This is obviously quite an old feature (no one would design anything like that these days would they?) but luck for us it works by default with PuTTY.

A program which runs a login time can send an 0×05 and read back the string. This is not as easy as it should be because PuTTY does not ‘press enter’ when it is finished so you have to switch into noncanonical mode to read it. Still, it is possible to write a program which will report the terminal you are using.

Solution Part 2. If you find that your terminal is PuTTY and it is reporting xterm emulation then you can ‘correct’ some assumptions by altering the color ls configuration and the LANG environment variable.

Solution Part 2b. By correcting the COLORS environment variable (used by color ls) then you can make vim decide what color scheme to use. This is easly added to your .exrc

Implementation. Here are 3 code snippits. The first can be added to your ~/.bash_profile (or a global like /etc/profile.d/z_putty.sh). The next is for ~/.exrc or perhaps a gloabl vim rc file like /etc/vimrc. The third is the source to the answerback prorgram. See the code for compile instructions.

I will eventually package all this into a .rpm because we will be using it on our new servers. It will probably be available from http://www.chrysocome.net/

bash profileeval `/usr/local/bin/answerback`
if [ "${ANSWERBACK}" ] ; then
if [ "${ANSWERBACK}" = PuTTY -a "${TERM}" = xterm ] ; then
echo "Terminal is ${ANSWERBACK}. Assuming dark background."
# Assume a dark background. This is not the assumes default for an xterm
# so we will reverse the default colorls setting
if [ "${COLORS}" = /etc/DIR_COLORS.xterm ] ; then
COLORS=/etc/DIR_COLORS
eval `dircolors --sh "$COLORS"`
fi
# PuTTY does not support UFT8 so we will remove that from our LANG
export LANG=${LANG/.*/}
else
echo "Terminal is ${ANSWERBACK}"
fi
fi

For the past week or so I have been working on a case mod for my mythtv box. Basicly it is a $45 SHAW case from MSY. I have mounted the 5.1 amp in the front of the case. This required cutting the sides and lid of the box to create the stepped lid. I then altered the front panel by cutting part of it away and mounting it lower down (and 180deg around). All the cutting was done with an Ozito high speed rotary tool (aka Dremel)

It also has a customised disk mount section in the front. The final case has integrated IR receiver and IT transmitter and wireless mouse receiver.

I have also installed a Coolermaster Hyper TX cpu cooler which is working very well and I have cut some extra holes in the power supply so the cpu cooler blows directly into the power supply. I still need to find a better fan for the power supply.

I still need to build something to house the IR transmitter but plans are underway. I just need to wait for some things to finish recording.

Once I installed everything and had the machine running, I decided the hard disk was getting too hot tucked away under the cdrom. I built another mounting bracket to go on the right hand side and have mounted a 5V fan blowing onto the disk. This is working well.

Once I complete the project I’ll try taking a better photo and post that.

I have a simple problem. I want to view japanese characters under Windows. I am implementing unicode support in a new program I am working on and I need to test it with japanese. I managed to get it working under linux ‘yum groupinstall “japanese support”‘ which I though was tricky to figure out. Well imagine the trouble in windows. I fool heartedly went to the MS web site. It seems that people only use japanese in Office XP. That was news to be but none of the MS downloads work. I eventually found a web site which had instructions, but the only way I can install the 230 meg of required crap is from the windows install CD. I have the CD, but I don’t have a CD-ROM in the computer. I hate windows.

I have started getting spam comments on my blog. I just marked 37 comments as spam. The default settings seem to be working in keeping the messages for moderation. When I get a chance I’ll investigate the spam filtering options in wordpress but for now I have set all comments to be moderated.

For those who don’t know, a Linux ‘live’ CD is a boot CD which contains a working linux installation. It allows you to run linux programs without installing linux onto the hard disk of the computer, much like a high tech boot disk.

I have toyed in the past with customising the gentoo live installer to work with PXE but it was mostly a hack. We had the need to create a live CD which has php and a custom php script. The solution was to build a real live CD, based on CentOS 4. CentOS recently released a live CD, and the build scripts but no instructions for building your own. I have figured out a procedure and here it is http://www.byteclub.net/wiki/CentOS_Live

I just added my 2c about Inner Classes to the WIKI but it got me thinking again about a feature I think is lacking in modern languages. Having slipped out of the top 10 blogs, I felt it was time to share my idea.

The feature is automatic type conversion. When you have some pseudo code like this:

It does not work. The problem is that although foo is compatible, the compiler wants me to explicitly say so. The solution is to add an explicit type conversion like this

DoSomeProcess(TMyChildClass(foo));

But this becomes a problem if the conversion is not type checked until run time. If for example I had:

var
p : Pointer;
begin
DoSomeProcess(TMyChildClass(p));

I have valid code but I get a run time error because of the invalid type cast. So, the explicit type cast is for shutting up the compiler, not for making my code correct.

The compiler complains because it knows what type to expect, and given that it knows, I think it should be able to implicitly cast my parameter like this:

DoSomeProcess(foo);

and I get the same result. If the type is correct, it works and if not I get a run time error.

What about preventing programming bugs? Well I guess some kind of syntax is required to allow the automatic conversion. Each language would have to pick it’s own syntax but in delphi, it might be something like this: