What's it all about, Alfie?

Late yesterday I decided to do a Google search on NeXTSTEP and SSH to see if anyone had built an SSH client for NeXTSTEP. What I found was the 'commercial' version of SSH that came in two versions - 1.x and 2.x. I got both and tried to get them both to compile. The 2.x version was hopeless due to signal differences, and the 1.x version needed me to write strdup() - but that wasn't bad. In the end I have a 1.x version of SSH which is a lot better than telnet.

Yesterday was a little slow because I didn't spend much time in the office. There were a lot of things that needing doing around the house, and so most of the day was spent away from this wonderful playroom. It's nice to be back this morning.

This evening I got word from Joel that the ISP guys had finally gotten around to installing GTK 1.2.8 development includes and libraries so I could get back to building CIA on their machines. Thankfully, it built fine, so now I'm in the process of transferring up a few slides so that I can test the speed and overall functionality. It should be fine, but I have no idea as to the speed issue. My guess is that it's reasonably fast, but nothing to write home about.

I also spent a bit of time today writing out my goals/plans/etc. for CIA and sent them to the rest of the guys. I'm hoping that this starts the process to either get serious about CIA or get out. I don't really care which, but if they wait too long I'll decide for them in what I do professionally.

UPDATE: I did a similar run on sparky and the ISP hosting the CIA website. I used the Dako #6 run with the following options: '-op -om -m' so as not to impact the FFTW time on one machine and not another. What I got was:

Which means that the ISP is running at about 28.2% of sparky. This is nice to know so that I can get a reasonable idea of production runtimes by looking at the runtimes on sparky and then multiplying by 0.282. Not like it's brain surgery, but it's nice to know.

One of my current interests is the communication between machines for the purposes of solving a problem. Like having a 'calculation engine', or 'valuation server'... machines that did a non-GUI activity very fast and was available for anyone to use with a minimal of fuss. A few months ago I heard about XML-RPC and the more I read about it the more interested I became. I've always liked good, solid RPC designs - CORBA, RMI, but this is nice in that it has clients and servers for a host of languages - PHP, Perl, Tk, Python, C/C++, Java. These make it very easy to host on a platform that's just about anything you want, and have a client come in from just about anything.

This morning I decided to get into it a little more and picked up a PHP client/server implementation from Useful software that works fine on the PHP 4.03pl1 I have installed on sparky and barney. What I wanted to do was to set up a server on sparky and hit it from a client on barney.

The docs don't give you a lot of help here, but it doesn't take a lot to figure it out, either. Basically, you need to install the directory in a central location. I chose /usr/local/xmlrpc-php on sparky and /usr/xmlrpc-php on barney - these are reasonable defaults for Solaris and Irix, respectively. Then I edited the PHP files so the include() directives pointed to the installed directories. Finally, I linked the server.php file to my public_html directory on sparky and copied the client.php to my public_html directory on barney. I could then edit client to point to sparky and /~drbob/server.php.

At this point, I was able to go to barney and pull up http://barney/~drbob/client.php and it worked perfectly!. I couldn't have asked for a better result. The XML-RPC standard uses XML over HTTP, so it's a natural to have a server written in PHP. With all the capabilities PHP has, it's easy to see that any complex processing could be shelled out to any language and the only thing the PHP server needs to do is the basic interface. Very nice.

Now I'm in the neighborhood looking for a good project to use this on. One that comes to mind is the Quip Solver. It takes a cyphertext and a key and returns a plaintext. This would be OK, I suppose, but it's not exactly what I had in mind. Maybe I'll do it just for fun and practice... But I'm still looking for a better project.

Today I finally received the other half of my APC Smart-UPS 2000 that was supposed to arrive yesterday with the first half, but got lost on the truck and arrived today. After letting it sit for a few hours (as recommended by the docs), I moved it into place taking the 900VA UPS that was covering barney and putting it on wally. The 2kVA now covers tux and barney and is operating at a very low load. Excellent! It's nice to know that I can now put all three major machines on the net and have them protected nicely against outages.

Now I can see why people use NT - heck... I have two machines myself, and use them on a daily basis. But what's caused me trouble today is the DOS-Unix CRLF conversion problem. Specifically, The Weather Channel is now servicing two different pages/servers - one is Unix-based, and the other is NT-based. How do I know? One has redundant CR codes on every line and the other doesn't. Normally, I'd be OK with this, but sed doesn't allow for a regexp matching the control code. This makes it very hard to get rid of them. Thankfully, Solaris has dos2unix and it can strip the codes while leaving Unix files intact.

It just goes to show that once again, scraping screens is hard work when you can't pin down the screen to scrape. And while I understand load balancing, it really helps if the load balance between machines of the same type - at least of the same CRLF-design.

I also sent all my patches to the bidwatcher crew... I like the idea of having a single status line - as in the original version, but I understand the need for different UIs. Heck, we could even make it a preferences item and have them changed on the fly. Anyway, I sent in the patches and we'll see what they are going to do about it. I read on the forums that they are trying to get the 1.2.1 tar file updated, and maybe they'll incorporate these fixes and put up a 1.2.2. We'll have to see.

This morning I looked into two updates for some Open Source tools I use all the time - bidwatcher and GAIM. Now, previously I had said that I didn't like the stream of bugs in GAIM updates, but as long as I checked to see if the fixes I'd submitted are in, then I think it's a reasonable thing to try and compile it to see how it goes. Thankfully, it went well, and other than the problem of AOL blocking out the Oscar protocol from AIM-clones, it's fine.

I also tried to upgrade to bidwatcher 1.2.1 but the gzipped tar file on the site was improperly made and couldn't be gunzipped. Thankfully, the 1.2.0 file could be and I downloaded it and built it. What I saw was a very mixed bag, and as a result I'm staying with my modified 1.1.9.1 version.

The designers decided to update the code to make the right-clicking on the auctions easier, but then they added two status bars at the bottom of the window. Now I don't claim to be a UI expert, but that's almost by definition excessive. They have one for error messages and the other for bid status updates. Now if you have an error, then the bid status has got to be bad, and if you don't then you have no need to display an error, and the status is seen. Therefore, there's only reason to have one. One - that's all.

So I sent off a few messages to the bidwater forums and we'll see what happens. I think I'll patch the code to have a single status bar just because I can't imagine what on earth they must have been thinking of. The best solution is to use the status bar at the top of the window for all needs and leave it at that. Maybe that's what I'll put in and see how it flies.

I also need to make some calls about the interviews and call about the new 2kVA UPS for the office. Not a lot, but enough to keep me off the streets as they say...

UPDATE: I fixed the 1.2.0 version of bidwatcher to use a single status line - the one that already existed in the older version, but also allowed the new users to have their dual-status bar UI. I've emailed the maintainers to see if they're interested in the optional improvements. We'll see if they come back interested.

I called about the interviews and told the headhunters how it went. I also found out that one of the places I was really interested in was getting back in touch with them. It might be really nice to hear from a few of these places this week. Good.

Finally, I called about the UPS and it should be here tomorrow - they say. What I'm hoping for is to be able to switch out one of my 900VA for this new 2kVA and put barney and one of tux's supplies on it. I figure that's about 1000W which should give me about 23 min of support on the 2kVA. At 115 lbs. this is a serious UPS which is very much in need in this office. Anyway... then I'll take the 900VA and put it on wally the NeXTSTEP machine and get rid of that awful TrippLite that I never should have gotten in the first place.

Today I decided that I wanted to get into the more secure connections. Not that I think my systems are open to massive attacks, but there's a chance that something might be going wrong, and I want to at least have the tools to protect myself. So I got OpenSSL and OpenSSH and decided to figure them out.

The first thing is to build OpenSSL. It's easy and builds cleanly depositing itself into a reasonable place in /usr/local/ssl. Then build OpenSSH. If you've done it right, the defaults will make a working sshd - but you still have to get it to start up and shut down properly. So I spent a few minutes putting it into the chkconfig system on Linux and Irix, and then made a simple script for Solaris. Nice.

Now I have SSH running on all of the machines that touch the world, and that's good. I also have the clients on several others which is even better. Now I can get to places a little more securely. One of the nicest clients is PuTTY for Windows 95/98/NT/2000 - excellent piece of code.

Today I got the latest GAIM release - 0.11.0pre7 in the hopes that the MSN section would be fixed and then MSN, Yahoo, and AIM would all be working again. Well... the MSN section is functioning fine, but the Yahoo code is now generating a crashing error about memory allocation that I believe is related to the GDK/GTK code. When I try to login to Yahoo, I get "Out of memory during ridiculously large request." I've tried to track this down, but due to timing issues with the login, I can't seem to get it pinned down.

This is further complicated by the horrible error message that is given to me. When I try to narrow it down in gdb or ddd I get nothing. So I've sent off messages to the GAIM folks, and I hope they can shed some light on this. I'm getting a little tired of all this breaking, but I understand that this is what some folks do when they release code. What I need to do is to get things working and then stay on that release until I hear from these guys that they have a significant, stable release, then I can move to it.

UPDATE: - I've taken the time to track down all the possible issues and found the problem - sloppy coding by the developers. There is a routine called yahoo_parse_config() where a (char *[]) array is getting parsed for configuration values. This code makes two mistakes - first, is doesn't check at the top of the loop for empty strings, and secondly, it assumes that the result of a strchr() is going to be not-NULL. They then use this assumed value in a calculation for the size of a malloc-ed array. Bad Style. When I added the checks for the empty strings and then for the result of the strchr() everything worked. It's amazing when you look at it. All these problems could have been solved with just a little defensive programming. What a shame.

Anyway... I submitted a fix for both problems to the maintainers and we'll see if it gets incorporated into their code.

This morning I got the latest version of GAIM - 0.11.0pre6 and applied my patches to perl.c and built it. It had the same problem that I had seen earlier. So I decided to fix this guy. I looked into it and it failed at the exact same spot as before - in the call to XLoadQueryFont(). But I believed that this could not have been the problem as it was deep in GTK 1.2.8 which works wonderfully. So I searched on...

When I ran it in gdb or ddd, I sometimes got it to work. In fact, I could sometimes get it to work from the command-line. So I tried to turn off the optimization on aim.c and that seemed to help, but not 100% of the time. Then I noticed another problem that I've been having but thought nothing of - GdkSpell error.

One of the errors I had been getting is the GtkSpell error at the beginning of GAIM, and since I decided to fix all the problems starting at the top I thought I could fix this one and then get back to the original XFontQueryLoad() problem. So I found that while I had aspell and pspell, I needed ispell for GAIM. So I went to the Ispell web site (found it off of Google) and downloaded and installed it. Nothing much, but it's meant to be very cross-platform so there's no configure script, etc. Just hand-editing a few files. But inside of 20 mins I had ispell running.

All of a sudden GAIM worked all the time. I mean all the time. So I put the optimization on aim.c and it still worked. This was really good news. What I had stumbled upon is a problem in how they were handling the death of ispell when the user didn't have it. There must be a bug in there somewhere, but it could bt in GtkSpell or GAIM... I just don't care now. Since I have ispell it's fixed. Excellent!

I also talked to Joel this morning and he's reporting that with the latest changes I've made to CIA over 99% of the cell nuclei are being found. Good enough for me! I think that's a big high-five to myself for the work. We have to move it to the web hoster, but that's to come as we still don't have FFTW up there. I sent an email about doing it, and we'll see when it is installed. Lots of work to do there, but most of it is on the backs of the other guys so I can rest for a while.

Over the weekend I spent a bit of time trying to get sendmail working, and only managed to get it working when I changed the hostname on sparky to that horrible name whilch includes the IP address from MediaOne. What it did show me was that with the proper DNS, it would work fine.

One of the reasons for getting sendmail working was to be able to email folks from within bidwatcher via pine. When I tried to configure pine to use SMTP, I kept getting errors that I couldn't see completly. This time, I decided to give it a little more effort, and ended up getting a configuration that works - pretty much. The address that I'm sending from still has my login name as opposed to the MediaOne email address, but with a Reply-To: header, I'm able to make it so that people can reply to that email address. Not perfect, but it should work nicely.

While I was on it I looked into the idea that bidwatcher could pull up Netscape's mail feature, as that would be the best for me. If that could work, then I'd be able to keep all my sent mail in one place. Also, there's no problem with the sent address when you use Netscape. So I dug into the code for bidwatcher.

I was surprised to see that the code for launching a new web page and pulling up the email composer was so similar. I simply cleaned up the browser code, and used a lot of it to clean up the emailing code. It worked - well... almost. The problem is that now eBay is not providing the email addresses to people - instead, you have to compose your message on their web page, and they send it for you. I'm sure this is because of the off-market deals that eBay is trying to crack down on. I wish I could get my exchange idea running... Anyway, with the fix in, it looks like there's no need as eBay has changed the rules. Too bad...

Today also saw several phone calls regarding headhunters, and other folks looking to see if I was right for their firm. Lots of nibbles but nothing serious yet. To keep my mind occupied I have been doing some more CIA work - this time adding the ability to get the background histogram based on the filter used to locate features. The idea is that after filtering, the Her2 slide is basically shades of light blue. What we're trying to do is differentiate the non-cancerous cells in the fat from the fat - eventhough they are colored very similarly. My hope is that by removing the stained portion from the image we'll have two distinct peaks - one for fat, the other for cell nuclei. Then getting the cell nuclei would be a multi-step process: filter out the stained matter, histogram the rest, pick a filter based on the histogram, and then extract features from the result. It's possible, but I'm not holding my breath in case it doesn't work.

The runs of CIA are getting long as well... certain runs are well past 30 mins. on sparky, which means there's almost no chance that this will be a real-time system to the user. Even with 1.5GHz P4 machines, the run time would be minutes, and that's just not acceptable for a hold time. I've told the guys about this, and Joel assures me that a good UI can be fashioned. I agree, but it's a submit/request one and not real-time, which is what we were going for in the beginning. Oh well... the best laid plans of mice and men...

This morning I checked the Ximian web site to see what the status of Red Carpet was. Red Carpet is their maintenance tool for Linux that keeps your distributions up to date, along with Ximian GNOME and Red Carpet itself. Their previous work, Helix GNOME Updater, is an excellent tool that I've used for a long time. The initial release of Red Carpet had the problem of enforcing dependencies in Red Hat, and because of a foolish oversight in the making of the PostgreSQL 7.02 RPMs, I had to install them as --nodeps, which lead to problems. The update that I obtained today fixes that and several other things. Excellent work by the Ximian folks.

This afternoon I found out that the RealPlayer7 on my Linux machines has expired. So I go to Real Networks and see that they have finally started supporting Linux as well as they support Windows. There's a Linux RPM on their site for RealPlayer8 - the latest version. That's incredible news! So I get it, install it on my laptop, and test it. Looks good. Plays the content. I'd say I'm pretty happy now.

I upgrade my other Linux box, and then look at the Solaris/SPARC version. Uh oh... now we're getting more like the old Real Networks. They haven't updated the player for SPARC - it's still RealPlayer7, and the news from their support groups is that they have upgraded the UltraSPARC version, but they haven't upgraded the SPARC version. This is making me nervous because Real has the annoying habit of making their code expire, and that means that I need to see a new version of RealPlayer7 or 8 for SPARC really soon.

I then checked on the Irix situation, and again, if you run 6.5, they have RealPlayer 8. The problem is that it only supports the MIPS4 architecture - so barney is going to be out of luck there as well. It appears that Real is supporting the latest hardware eventhough older hardware is still very much in use. If I try to run the Real Player 7 for Irix 6.3, I get messages saying that it's can't decode certain content, and in reality, it doesn't decode any content at all.

So it seems as though sparky and barney are not considered to be viable hardware platforms by Real Networks. Well... I certainly understand their position, but I think they are as wrong as they can be. They need to embrace the Unix community to hedge against Microsoft and MediaPlayer. If they support Unix well then they have the ability to claim better interoperability, which is what a lot of web sites are going for. Look at Flash plugins... they're trying to support Unix, and it's done pretty well by them.

Anyway, the bottom line is that my Linux machines have RealPlayer8 and sparky has a lingering RealPlayer7 while barney doesn't have a functioning player. Gosh! I wish it were better supported.

Last evening I noticed that there was a new release of GAIM - the AIM/Yahoo/MSN instant messaging client that I run all the time. I downloaded it and patched the src/perl.c file to properly work with perl 5.005_03 on Solaris. You see, perl makes an assumption about the environment array - namely, that it is mutable. On Solaris/SPARC that is not the case, and moreover, there's no documentation/reason to believe that it should be. I've talked to the Perl folks, and they've patched their code but it's still in perl 5.005_03. So, I've got a work-around that I patch into GAIM (and other code that uses this same perl plug-in feature). Then I built GAIM.

What I found was that there was an error when I ran GAIM 0.11.0pre5:

        Gdk-ERROR **: BadShmSeg (invalid shared segment parameter)
          serial 61 error_code 131 request_code 131 minor_code 2
        Gdk-ERROR **: BadShmSeg (invalid shared segment parameter)
          serial 76 error_code 131 request_code 131 minor_code 2

that I traced down to a call to XLoadQueryFont() in the stack trace:

        gdk_font_load()
        gtk_style_new()
        gtk_widget_get_default_style()
        gtk_widget_peek_style()
        gtk_widget_init()
        gtk_type_new()
        gtk_window_new()

When I stepped through the call to XLoadQueryFont() I could occaisionally get it to work - but when it did, I didn't get the proper icons on the buddy list for expanding and collapsing the groups in my buddy list. I reverted to gaim 0.11.0pre4, and everything is fine.

I've posted a message on the GAIM SourceForge page, and we'll see if anyone comes up with something. I have a feeling that it's got something to do with the more lax Linux/i86 architecture versus the SPARC/Solaris platform. I've run into this with perl, and I can easily imaging that the 0.11.0pre5 is doing something that's throwing off the subsequent call to XLoadQueryFont(). In any case, I'm back to 0.11.0pre4 and it's working very nicely. We'll see what happens when and if I get an answer from the GAIM folks.

Some days I hate DHCP and MediaOne. OK... it's not DHCP, it's just MediaOne's use of it. If I had a fixed IP address then I could possibly work up a few DNS records somewhere that would point to the machines. Why's this important? Well... without forward and reverse DNS entries sendmail won't really function. At least I've tried, and the version on Solaris 7 isn't being helpful. I went through this on my NeXTSTEP 3.3 machine and got it working but the version of sendmail is changed and the configuration changes used in the version I have on NeXTSTEP don't do what's necessary on Solaris. Not that this is that surprising, but it'd be nice if sendmail had a simple configuration file default to hand off to another SMTP server. I know I could figure it out, but it's not that important, but it is a pain.

I tried sparky, barney and mao - representing Solaris, Irix, and Linux, and on each I was unable to simply mail out of the box because of sendmail. Oh... I can do it with Netscape because it allows me to communicate directly with the SMTP server, and put in a login to that SMTP server, and while sendmail seems to allow the specification of a great number of things, these don't easily pop up to be configured.

I know that if I had proper DNS I'd be able to handle this because the default configuration of sendmail on Linux does this fine - I've got it working on another host. It's just MediaOne who isn't allowing us to register names. What a pain...

For now I'm stuck with making my own mail client and sticking with Netscape. Looking at those two opportunities, Netscape is best.

UPDATE: I found a site called easyDNS that does exactly what I need. For $55/yr I can get a domain name registered (through them) and have their DNS servers hold the DHCP addresses of my machines. There are little clients for Linux/Solaris/Windows that send any DHCP-related IP changes to their service so that their DNS is constantly being kept up to date. With this, I could easily get DNS for my machines and then sendmail would be working just fine. Certainly something to think about.