All | 43 Folders | Accessibility | BoingBoing | Books | Computer Related | Family | Films | General | Hacking | Hobbies | Humor | Java | Links | Omni | OpenSolaris | Puzzles and Games

« Previous day (Jun 19, 2005) | Main | Next day (Jun 21, 2005) »
20050620 Monday June 20, 2005

Successfully Built Open Solaris

In my copious spare time, I've been working towards getting the recently released Open Solaris sources to build on my new Ferrari laptop (AMD64) under Solaris.

I'd already installed Solaris (Nevada - build 16), so I had an appropriate version of Solaris ready to work with. Last week I installed the Solaris 10 compilers by copying a directory hierarchy over from another Solaris x86 machine I have here. I downloaded the open and closed Open Solaris bits and the extra ON Build Tools bits from genunix.org, followed the instructions in the Release Notes and set the "nightly" build going. (Note that I've previously added software to the Solaris Companion CD, so I was very familiar with the way the build system is setup). That was last Friday. I then went home and left the build going. Note the build only takes a couple hours on my machine.

When I came in today, I found that the build had failed in three places (audioconvert, rpcsvc and ypserv) with errors such as:

Undefined                       first referenced
 symbol                             in file
_vector_con_                        convert.o
operator delete(void*)                            convert.o
operator new(unsigned int)                            convert.o
_pure_error_                        ../utilities/libaudio.a(Audio.o)
[Hint: try checking whether you are linking with the correct libC]

_ex_rethrow_q                       convert.o

I then decided to download the exact Solaris 10 compilers that were recommended by the Open Solaris people, unpacked them, and started another build going. That's just finished successfully, so I obviously had an early build of the Solaris 10 compilers, and that the problem I found is no longer there in the final bits.

I was also able to test that a simple build of a single tool with the build tree worked nicely with:

    % cd /export/home/richb/opensolaris/usr/src/tools/env
    % bldenv ./richb_opensolaris.sh
    [status information from bldenv]
    % cd /export/home/richb/opensolaris/usr/src/cmd/vi
    % touch */*.c */*.h
    % dmake all

In total, it probably took me a man person day to get everything built successfully. Not bad for such a large body of code.

So I'm now at the point where I can look at the bug database and see if I can generate any simple fixes for some of the bugs that are reported there.

I was disappointed to find that /bin/mp, the file pretty print program that I wrote in C about 18 years ago (based on the original version in Icon by Steve Holden), that's in Solaris 10, wasn't included in Open Solaris. I'm not sure what's going on there. I sure hope they decide to rectify that in the future. Having said that, the version of mp in Solaris 10 is about 12-13 years out of date, so perhaps it would be better to try to integrate the latest version that's available via SourceForge.

[]

[]

( Jun 20 2005, 02:13:52 PM PDT ) [Listen] Permalink Comments [1]

If Some Developers Built Houses?

David John Burrowes, one of the Interaction designers here at Sun, sent out a pointer to a piece in the UI Hall of Shame blog by Duncan Margetts, entitled If some Software Developers built houses?. It's worth sharing with y'all. Be sure to read all the comments. You see that what is considered a good design in one situation, doesn't always work in others.

I've been writing graphical software for 23 years and working with HCI (Human Computer Interaction) people (or whatever they are calling themselves this week) for about 15 years. I've worked with good ones and I've worked with, um, not so good ones. When they are good, it's a pleasure to work with them. Each person (the developer and the HCI designer) takes a passionate interest in trying to get it right. Great teamwork. Also when working on some software within the confines of a larger project (such as the DeskSet software within OpenWindows or desktop applications for the GNOME desktop), there are usually a set of HCI guidelines that help developers and UI designers do the right consistent thing.

But what about the same application across different larger projects? I wrote the calculator application ( calctool) in OpenWindows. The same code was the basis of the calculator in CDE (although I didn't write that), and now the same code has been the basis of the default calculator for the GNOME desktop. Each time, a different UI designer has been involved and each time, the look and feel has been different. Still, no matter how you look at it, they are all better then what I came up with, circa 1987. I don't know what I was smoking then, but ooh the colors man! (Looks like HP might still be making this version available).

Here's another piece entitled Dear Mr. Architect. The piece begins with:

Software developers frequently complain that the process of specifying and developing software is wildly irrational. If people built houses the way they built software this is what you might see:

As you can see from the article, designing something that will satisfy the needs of everyone that uses it, is not easy.

I'll leave you with a quote from Michael Tiemann, CTO of Linux vendor Red Hat:

"If people built airplanes the way they built software, nobody would fly".

This is for the most case true, but I wouldn't have a problem flying Donald Knuth Airlines. He used to pay a bounty for any bugs found in his TeX software, and nowadays for any typos found in any of his books. He doesn't have to pay out much money though because he does such an outstanding job in getting it correct before it's released. I wish all developers would take the same care (myself included). Of course, Professor Knuth didn't have to deal with a GUI for TeX, so who knows what his bug count would have been like in that situation.

[]

( Jun 20 2005, 08:16:08 AM PDT ) [Listen] Permalink Comments [3]