Saturday, May 28, 2005

Open Source WRT54G

Forgot to tell you that I chose the Linksys mainly because the source is GPL'led, so you can download it and have a look at it. Also, other people than the supplier (CISCO) itself are able to fix any problem, and a lot faster than in a closed source setup. So to stimulate progress, and foster new development, we should buy these products. There are versions that support other functionality, like ssh, in the router itself. With the previous router, some years ago, I had to wait a while before it worked sufficiently well (it had some issues with passive mode FTP and its NAT tables), and it was not a good thing that I was totally depending on the supplier to fix it. Luckily, we are moving to a world in which communities can solve these problems themselves, and also support the units way longer than is ordinarily viable for suppliers.

Friday, May 27, 2005

New network infra

I experienced stalls in dowloading since my ISP increased the bandwidth to 8 Mbit/s. This is fairly hard to diagnose, at least for me. Some testing exposed that when I power cycled my ATM modem and router, the connection picked up again, and combined with resumable downloads it was only a slight nuisance. Worse was, that my websites also lost connections when there was an outage of this kind. Because I only had this trouble when there were very fast downloads, I suspected the modem or the router. The 8-port ethernet switch is rather new compared to the other boxes, so I guessed that was not it, and neither was the old Airport. So today I started with phase one: I swapped out the Netgear RP114 for a Linksys Wireless DSL router, that also gives me IEEE 802.11G instead of B. Although the helpdesk said it was probably the Alcatel modem that could not keep up, I observed that when I only reset the modem it did not restore the connection. So if I, apart from the increased throughput I already have, experience one other stall, the Alcatel also goes. Although I probably should try to tweak it first into the Pro version, that seems to have better throughput if one may believe the rumours.

Tuesday, May 24, 2005

GUI - thanks but no

I make GUIs, but I do not like them. I think assembler macros are still the best way to put parameters into a program or operating system. This is because the process is reproducible, you can check for errors before submitting them to a system in a much more structured fashion. It is much easier to make controlled procedures for promoting changes through environments to production systems this way (like you should and you know it).

Call me old fashioned, because I am. There must be an enormous waste of time and money going on because of pimply 'network administrators' (a job title we reserved for people knowledgeable in VTAM and the rest of SNA, and TCP/IP) type in different values in every pc they find and do not even write them down. Instead, everything that is of value should be in text format in version management. Disregard that at your own peril -- mess with GUI configuration dialogs and you could be out of a job somewhere in the future. JBoss uses XML configuration, and that is OK, we have them in SVN. Although XML is not made for people to read, it is the best alternative to date.

Sunday, May 22, 2005

Box the device

Lots of people who use Apple hardware and OS think the company can do nothing wrong. After spending the day developing in Panther and the evening restoring my backups on a fresh, zeroed-out all clusters install of Tiger (and about the same amount of time typing in serial numbers) I do not feel the same. This is because:

1) When a disk, or driver cache or other system software component fails, the machine should halt with a clear message of what is wrong, it should avoid the error by assigning spare clusters or boxing devices that deliver spurious interrupts on the bus. It should not crash and throw a nine fans in overdrive, scaring my wife and cats. It should have a service processor to take care of this, this should cost a minute fraction of the effort that is invested in the video card (that I did not choose myself because I have some graphics companies CTO machine).

2) This is the second machine of this type that gives me grief. The first went back after a week. Due to (1) I still do not know the problem, I suspect it is heat. Because the machines are designed to just about keep working, and not to fail cleanly when critical parameters are crossed, it is hard for me to trust it. This one worked a few months without a glitch, but boy am I glad that I do make backups.

3) They should license their OS for other machines, perhaps IBM. I would be tempted to buy an IBM machine that does have all diagnostics for a bit more money, but knowing there is parity on the memory and checking of other critical values. With AIX like it is now, that is no option, and neither is Linux. Or they should start building dependable machines, like that G4 I had for almost two years.

Saturday, May 21, 2005


All things worse than Murphy struck again, just because there is a deadline. While working away, I suddenly realized how to solve the rexxutil.dylib loading problem. Because the XCode 2 tools and certainly the gcc 4.0 compiler are not up to scratch yet to compile Open Object Rexx for the Mac, I had to restart from my Panther 10.3.9 disk with XCode 1.5 to compile the fix I just entered. It ran, the Sysxxx util functions are now automatically loaded by the interpreter and it looked like a 5 minute diversion from the productive weekend I planned.

Then the Mother of All Murphies struck when I restarted from 10.4.1. I did not, showing me an Apple and throwing the G5 in afterburner mode, which it apparently does when it loses all track of the temperature sensors and must assume that it is really *hot*. Our two cats came in the room to check out if there was danger.

It took me 10 minutes to figure out how to open the CD door on boot, repaired disk and disk permissions, set the boot partition again, and started. The jets took off immediately. Proceeded by resetting the NVRAM and PRAM as directed on the website (you should always have two computers hooked to the net).

Nothing. I did an archive and install, losing costly time in the future by now having to reinstall all commercial crap software from Adobe and Macromedia that I am using. Avoiding this time wasting on activation and serial number only must be a valid reason to switch to open source only.

After reinstall: the same. I guess there is a faulty track on the disk just where it reads the boot code, or otherwise there is some kind of error in the fastboot, kextchache or other caches that Tiger install did not solve. So I spent the rest of yesterdays evening moving work over to my other disk (you should have at least two disks in every machine) and booting from Panther. And (sigh, see yesterday) compiling emacs again. This time I am certain: their make clean, nor their make maintainer-clean cleans out all of the libraries, you have to do an uninstall, nuke the emacs directory, check out a clean cvs copy and ./configure and make bootstrap. But we're up again, and Object Rexx on the Mac has one error less.

Thursday, May 19, 2005

Emacs on OSX

Apple does deliver Emacs on OSX, but unfortunately a terminal window, character mode only version. What I use is GNU emacs, the Carbon port from Andrew Choi, who 'defected' to XEmacs; I do not have a standpoint here because I do not care and only want to use what works. Apple does have an Aqua port of Emacs on its website, that looks promising (great fonts!) but does not seem to be quite there yet.

What I would like to know is why Emacs, compiled from source on my own system, breaks on every OSX upgrade, now even from 10.4 to 10.4.1. I gather it has to do with C++ and GCC, which is changing its ABI every sub-release. Question that remains is why big apps as Motion and Office do not break.

For comparison, Java code keeps running all the time if it is post-1995-beta level. I've got mainframe (here we go again) load modules (what we would call binary executables) from the seventies that still run. This platform also switched from 24 to 31 bit addressing, and more recently to 64 bits. I guess those people were smarter.

This sums up the developements in the trade (a little jealous of someone else's tagline:

The old days: Smart People in front of dumb terminals
Now: Dumb people in front of smart terminals

Wednesday, May 18, 2005


Another gripe about JSF: its event handlers also fail silently if you mistype or mis-think a method name. These event handlers were modelled, as we read in the documentation, on the Swing event model. In Java bean events, which is the event model used by Swing, you register an eventhandler explicitly with an addXEventListener. This leaves the method pointer in a structure which is looped over when firing these events. In JSF, though, there is no registration. You indicate that you want a ValueChangeListener, its implementation is just a method signature of name and one Event parameter. Miss out one one of these, for example by mixing up the name when it is late, and you will never know, because it calls the other method and there is no diagnostics at all, neither at compile time nor at runtime.

It was commented that this is the point that I refer to some older mainframe software technology that just worked. I will refrain from that now, but just want to mention that CICS, ISPF and IMS DC all just work. It is the failure of the customer base to not employ these technologies anymore in new systems; this has to do with the powerless position IT managers are in nowadays and the general devaluation of standards due to the mickeysoft era.

On the whole, JSF is not bad technology, it just needs to be fixed to lower the frustration level.

Tuesday, May 17, 2005


JSF qualifies for the title of 'most frustrating software development infrastructure component' due to a few design and/or implementation features.

1) The symptom dumps are almost useless as they seldom point to your own code
2) It disregards null pointers so things just stop working without you having a clue where and why; one should be extremely alert for things to keep working
3) It is absolutely unclear why and when the cache of your web browser must be flushed; sometimes errors are already fixed; you go to sleep desperate and when you fire up the server the next day, everything works; on the other hand, working code fails at customer sites before you flush the caches

This does not mean I do not like it; there is just a great opportunity to improve the design and code so it will stop wasting other people's time.

I recently had another look at IBM's mainframe ISPF in the GML version. This is more or less the same idea, and of course IBM did not realise the gold they are sitting on; change the tags to xml, make a version of the compiler that spits out servlets and we are done.