Sun has a problem, and it is not a small one.

I had a bit of free time last Tuesday, so I took a poke at the wide-finder benchmark. (Took the day off work to host the local polling place, and voter turnout was very light.) The test machine is a 32-CPU Sun box running Solaris 10.

Did have a small off-by-one bug in my code, and got a core dump. Core dumps … right … I used to use these quite a lot … about 15-20 years ago. Been a long time since I’ve used a command line debugger on Unix. What is the name of the debugger? Oh, right - adb and mdb - I used to be quite proficient using these, but … I have pretty much zero interest in re-learning these old tools.

Bit of a pain when you cannot use the tools to which you are accustomed.

I switch quite a lot between Windows and desktop Linux when writing and testing new code. Both environments I have used for a long time, and I am entirely comfortable in both - through I tend to prefer the shell and tool chain under Linux.

Under Solaris I ran across a number of small irritations.

Checking free space, typed: “ps -Pm”. Nope. OK, I can kind’a understand not changing “ps” if there are any backwards compatibility problems with old scripts. Not that I’m overly sympathetic.

Fired up “top” to monitor process activity. Since “top” was around for old BSD machines (yes, I have been around that long), and “top” is not so much used in shell scripts, I was expecting a pretty current version. But on Solaris “top” is dumb compared to Linux. No auto-size the list of processes to fit the terminal. No per-CPU status. Maybe there is some other command on Solaris to do the same thing, but I do not want to go digging around to find what should be at my fingertips.

Add a dozen or so minor other instances where I issued a command, and Solaris said “Huh??”, then the need to re-learn an old debugger (that I might never use again) … and I quit … at least for a while.

Sun has a problem.

For their existing group of long-term customers, they need to maintain backwards compatibility, and that means not upgrading existing commands in any way that might break existing shell scripts. For existing and potential new customers who have become accustomed to the GNU and usual Linux tool vocabulary, trying to use Solaris is a royal pain in the ass.

This is a shame as the stuff done in Solaris beneath the layer of tools is pretty damn impressive.

Something rather odd about all this. Long ago - when my day job was working on Unix - for the universe of tools flowing by on USENET, the Sun systems were the golden standard. If a new piece of software was buildable anywhere, it probably was buildable on Sun. By in large, if you had a Sun box (and I did only briefly), then things pretty much just worked.

The problem is quite solvable. Disk space is cheap, and keeping both old-Sun and current-common tools on disk is a bit of PATH setup, but little more. (Without over-complicating the “man” pages, please.) There is some effort to distribute current-common tools, but I am not sure this is exactly mainstream from Sun’s point of view.

Wonder if someone at Sun has a plan … :)