Hi Don,

Hmm ... IIRC, "the GIMP" -- either version -- will load a ton of
plug-ins at the first time it is run by root -- and will then
automatically force a core dump and process that into an executable
which has everything pre-loaded. Emacs does the same thing.

If you always started it as a user, and never as root, it would
never get the chance to do the "core dump and turn into executable" magic,
so it would always be slow to start.

I was running GIMP 2 as root when I observed it to be slow. I might have
persisted with it for longer, except that the version I had was also
very unstable. So it didn't seem worth the trouble.


And when I tried it to get the timing I discovered that it still
loaded all the plug-ins -- it was just tolerable because of the much
faster system.

Hmm ... looking through the command-line options for the 2.0.2
version, I find this which may be of interest:

================================================== ====================
--no-shm
Do not use shared memory between GIMP and its plu-
gins. Instead of using shared memory, GIMP will send
the data via pipe. This will result in slower per-
formance than using shared memory.
================================================== ====================

Perhaps that was the default for the version which you had.
There are some other options which may also be of interest:

It's possible, but I'm doubtful (see my note about speed below). I
suspect GIMP 2 was loading as fast as it could on my system.

================================================== ====================
-d, --no-data
Do not load patterns, gradients, palettes, or
brushes. Often useful in non-interactive situations
where startup time is to be minimized.
================================================== ====================

Thanks. That's a useful option. Did you get it from the man page? The
man page for my version of GIMP 1.2 doesn't work. Not sure why. I think
perhaps the documentation is online instead. But I tried the --no-data
option with GIMP 1.2 and it reduced the start-up time by about a second.
So with GIMP 2, it would likely be a worthwhile reduction.

Note also that you can define a "swap-path" to it -- which is
supposed to be more efficient if you give it a partition of its own to
work with. At the moment it is a filesystem made on a zfs array (which
requires Solaris 10 to have that available) -- and I have the array on a
set of FC-AL (Fibre Channel) drives which are noticeably faster.

[ ... ]


I certainly don't notice the long delay -- but with two 1.2 GHz
CPUs, I guess that I would not. :-)

O.K. It does still load the plugins at start time, and it takes
15 seconds from the [Enter] key to it having everything displayed and
ready to work. I guess that with your 300 MHz CPUs, it would take on
the order of a full minute -- depending on how much of that is the disk
speed instead of the CPU speed.

Maybe you're more patient than me. GIMP 1.2 takes 4 seconds to load on
my Ultra 2. I'd have said GIMP 2 probably took 15 or 20 seconds to load.
But I'm always opening and closing it, so I really notice the time it
takes to load.


Well ... if it takes 15 seconds on my system, it should take
nearly a minute on yours (1.2 GHz per CPU vs 300 MHz per CPU).

I'm certain GIMP 2 didn't take a minute to load. I would have been going
crazy with impatience if it did :-). I'd estimate more like 15 to 20
seconds. Which suggests that perhaps clock speed isn't the limiting
factor. Maybe it's the amount of RAM or disk speed instead?

And I tend to start it up and then work my way through a large
number of images before shutting it back down, so the startup time is
not that much of a matter. It doesn't feel any slower than starting a
web browser. :-)

[ ... ACard and IDE DVD burners ... ]


I am using one quite frequently for a DVD burner mounted in my
SB-2000. It shows up as:

================================================== ====================
'_NEC ' 'DVD_RW ND-3520A ' '1.04' Removable CD-ROM
================================================== ====================

The main thing is to be sure to go to ACard's own site, and look for the
one which is 50-pin SCSI instead of 68-pin SCSI, at least if you intend
to use it as an internal drive.

I had a 68-pin one, which would not make a bootable DVD drive,
especially in the system, and it took forever to argue with the system
over whether to use narrow or wide SCSI, since both ends were
identifying as wide, but the internal connection to the DVD-drive was
only narrow SCSI. :-)

I had a similar problem with a Teac SCSI CD-Rom. I couldn't seem to make
it bootable, until I discovered that an unexpected combination of
jumpers on the back of the drive did the trick. I don't remember the
combination of jumpers, but I wrote it down on the top of the drive. I
can check if you want to know.


This was the problem of the system negotiating transport
protocols, with both ends knowing that they were wide SCSI capable, and
not realizing that there was only a narrow SCSI path between them. It
worked fine when plugged into a 68-pin external interface.

And the Toshiba 1401 SCSI DVD drives will only boot on a Sun
with the latest firmware in the drives -- and likely a fairly recent
firmware in the computer's OBP too.

But it works fine in the system with the 50-pin version of the
ACard bridge card.

I'll bear the ACard in mind. Probably sometime soon I will need a means
of back up which exceeds the capacity of a CD-Rom.

snip

I was thinking in comparison to a Sun Ultra 2? I figured at the time
that my free 2 x 300 MHz Ultra 2 was probably the better machine, but
was never quite sure. That bright purple case had an effect on my mind.


Remember -- this one was a 75 MHz CPU. About the only time it
*might* do better than the Sun Ultra-2 would be if you were doing
something which was almost exclusively *heavy* floating-point math.
That one had a separate floating-point processor which was as fast as
(or faster than) the integer math. I think that the SB-2K may well be
equally designed for very fast floating point.

I remember being told that the Indigo 2 had hardware which made it very
fast at alpha blending, though I never fully understood what that was.


I have no idea either.

And there were at least three versions of the Indigo 2.

Teal case color:

CPU R4000 faster integer math, but not particularly fast floating point

CPU R8000 floating point is at least as fast as integer math, but only
a 75 MHz CPU clock.

Purple case color

CPU R10000 -- faster version of the R8000 -- 150 MHz I think.

I've got the R8000 version.

My recollection is that the best processor was the R10000 195 MHz. I
think there was also a processor which topped 200 MHz, but that it was
generally regarded as being inferior to the R10000 195 MHz.

I did have a Personal Iris for a while. Probably weighed about 80 lbs. I
gave it to a computer museum.


Got tired of heating the house with it?


Note that your Personal Iris machine is only about twenty pounds
heavier than the Sun Blade 2000 with dual 1200 MHz CPUs, and up to 8GB
of RAM.


I was a bit reluctant to part with the Personal Iris actually. It was a
very interesting machine and built like a tank.


Sounds very much like my SB-2000.


But it had the Year 2000
problem


While the SB-2000 still has new versions of Solaris 10 for free
download, so no problem with the Y2K. Also -- even if you don't want to
upgrade the whole OS, it has the locally-compilable time zone database
kept in:

/usr/share/lib/zoneinfo/

You can download the latest database (such as the last Daylight Savings
Time change) compile and install it and everything just keeps on working.
It even has the source for the date(1) command and such if you have
something old enough to need a replacement.

I'll bet that your Personal Iris system had the same database
hidden somewhere in the system. Try "man zoneinfo". (Yes, I know that
you don't have that program.

I didn't actually experiment with it much. I wish I had. It would have
been interesting. But the machine was old, and I was doing other things.
I just booted it up a couple of times. I chose to use the Ultra 2 with
Solaris 9 as my main workstation instead, because it was newer and
faster. But the Personal Iris was fascinating. Everything was huge, even
the SCSI terminators.

I also heard that Irix was plagued with far more serious bugs than
Solaris. And now Irix is pretty much unsupported, I believe. SGI nearly
went bankrupt, didn't they?

Best wishes,

Chris