SGI Software Usability II (IRIX 5.1 memo)

Larry McVoy lm at mcvoy.com
Fri Oct 13 00:59:10 AEST 2017


On Thu, Oct 12, 2017 at 04:55:27PM +0200, Don Hopkins wrote:
> https://www.cs.virginia.edu/~cs415/reading/irix-bloat.txt <https://www.cs.virginia.edu/~cs415/reading/irix-bloat.txt>
> > x The window system (Xsgi + 4Dwm) is up from 3.2 MB to 3.6 MB, and
> > x the miscellaneous stuff has grown as well.  As I type now, I have the
> > x default non-toto environment plus a single shell and a single text
> > x editor, jot.  The total physical memory usage is 21.9 megabytes, and
> > x only because I rebooted IRIX yesterday evening to reduce the kernel
> > x size.  Luckily, I'm on a 32 megabyte system without Toto, or I'd be
> > x swamped by paging.
> > x
> > x Much of the problem seems to be due to DSOs that load whole libraries
> > x instead of individual routines.  Many SGI applications link with 20 or
> > x so large DSOs, virtually guaranteeing enormous executables.
> > x
> > x In spite of the DSOs, large chunks of Motif programs remain unshared,
> > x and duplicated in all Motif applications.
> One of the main advantages of NeWS was that all the apps shared the same user interface code. 
> SGI went down that road a little bit but not far enough with 4Sight, their own merged X11 + NeWS + GL window system they did before Sun developed OpenWindows X11/NeWS.
> The 4Sight window frames and desktop pop-up menu were implemented in NeWS by PostScript code running in the server, and the menus used a NeWS overlay canvas to draw the menus in a hardware overlay plane, so it didn???t have to repaint the graphics underneath when the menu popped down.
> But SGI???s desktop apps and clients themselves didn???t use a NeWS user interface toolkit (except for NeMACS of course), and they eventually gave up on NeWS because Sun wasn???t being very helpful or supportive, and went down the path of Bloatif instead. 
> Shared libraries weren???t universally supported, and even when they were, the ecosystem hadn???t completely converted yet. 
> The SunView libraries were so big, that in the absence of shared libraries, Sun would compile all the common SunView desktop applications into one giant happy executable ???tooltool", to simulate monolithic shared libraries just between those apps. The names of all the different tools were hard linked together to the same giant universal desktop mega-app clusterfuck, which would run a different main loop depending the name it was invoked with. 

That must have been really early on because by the time I got to Sun (4.0?
Maybe 4.1?) shared libraries worked properly.


More information about the TUHS mailing list