Hi Don,

A while back you gave me some advice about fixing my ailing Sun Ultra 2
workstation. Well, shortly after that it died completely. I posted
another reply in the "Shopmade grinder with winch" thread but I had to
use Google Groups. I think you may have missed the message if you're
blocking messages from Google Groups.

The same thing has now happened to me twice. With the first workstation,
it worked for about 10 days after the clock stopped keeping time. This
time, it worked for about a month. It leads me to believe that Ultra 2
clock problems are perhaps most often caused by motherboard faults as
opposed to a dead NVRAM battery. Anyway, I have now managed to build a
working Ultra 2 from parts with 2048 MB RAM. 2048 MB seems to make the
Ultra 2 slightly faster than it was with 1280 MB. I notice it when the
machine is booting up, which surprises me as I would have expected boot
speed to be limited by hard disk speed.

This means that perhaps my old NVRAM chips are worth preserving. You
mentioned a piece of software which could be used to stop the NVRAM
clock. I searched but couldn't find it online. Looking at the NVRAM
datasheet, it seems like it is not something which can be done with a
crocodile clip. The only reference I could find was for modifying the
contents of an ancient sun4c machine's NVRAM at the "ok" prompt, and I
couldn't immediately see how to use this information with a sun4u Ultra
2. Do you know of a source for software which can be used to stop the
NVRAM clock?

I think that's all there was of importance in the post. I speculated a
little about whether common applications such as Firefox and Nautilus
are able to make good use of multiple processors on Sun workstations.
I'm still not certain. But I think that's all.

Thanks for the help.

Best wishes,

Chris

On 2009-01-02, Christopher Tidy wrote:
Hi Don,

A while back you gave me some advice about fixing my ailing Sun Ultra 2
workstation. Well, shortly after that it died completely. I posted
another reply in the "Shopmade grinder with winch" thread but I had to
use Google Groups. I think you may have missed the message if you're
blocking messages from Google Groups.

I don't always read all threads to the end. That was one which
I skipped over a lot of, when I was overloaded with articles to read.

And I'm going to be heavily occupied Saturday and Sunday,
probably not even get to the newsreader on either day -- or perhaps near
midnight on Sunday.

The same thing has now happened to me twice. With the first workstation,
it worked for about 10 days after the clock stopped keeping time. This
time, it worked for about a month. It leads me to believe that Ultra 2
clock problems are perhaps most often caused by motherboard faults as
opposed to a dead NVRAM battery. Anyway, I have now managed to build a
working Ultra 2 from parts with 2048 MB RAM. 2048 MB seems to make the
Ultra 2 slightly faster than it was with 1280 MB. I notice it when the
machine is booting up, which surprises me as I would have expected boot
speed to be limited by hard disk speed.

When it is booting it is loading a lot of programs. With plenty
of RAM, it doesn't have to swap just loaded programs to disk while it is
loading the next one.

I've noticed a significant improvement in boot speed (and in
workspace startup speed) with my boost from 3 GB of RAM to 6 GB, and
want to go to the max of 8 GB for my Sun Blade 2000 to have plenty of
RAM for when I'm doing lots of image processing (which is what is coming
over the weekend, with someone else critically involved in the project
who can't get up here very often.

This means that perhaps my old NVRAM chips are worth preserving. You
mentioned a piece of software which could be used to stop the NVRAM
clock. I searched but couldn't find it online. Looking at the NVRAM
datasheet, it seems like it is not something which can be done with a
crocodile clip. The only reference I could find was for modifying the
contents of an ancient sun4c machine's NVRAM at the "ok" prompt, and I
couldn't immediately see how to use this information with a sun4u Ultra
2. Do you know of a source for software which can be used to stop the
NVRAM clock?

I don't remember for sure where I read about it, but it was
probably in the first hit on a Google search for "Sun NVRAM FAQ"

http://www.squirrel.com/sun-nvram-hostid.faq.html

This one was posted in February of 2004, FWIW.

And I see that the procedure only mentions the Sun 3/80 (68030
CPU) and the sun 4C (SS1 SS2 IIRC).

I'm not sure whether it would work on the Ultra-2 but I don't
see any reason why it should not, if you can get to the "ok" prompt.

Check the contents of your NVRAM chips (HOSTID and Ethernet MAC
address) and keep a hardcopy version in case you need to perform the
battery surgery which is documented in the website above.

I think that's all there was of importance in the post. I speculated a
little about whether common applications such as Firefox and Nautilus
are able to make good use of multiple processors on Sun workstations.
I'm still not certain. But I think that's all.

I depends on whether they are multi-threaded. Though they will
probably use other CPUs for plugins.

Remember -- I won't be able to do any responding until really
late Sunday -- and I now don't have time to read any more of
rec.crafts.metalworking, I've got to take a bath and get to bed to
prepare for tomorrow.

Good Luck,
DoN.

--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

DoN. Nichols wrote:
On 2009-01-02, Christopher Tidy wrote:

Hi Don,

A while back you gave me some advice about fixing my ailing Sun Ultra 2
workstation. Well, shortly after that it died completely. I posted
another reply in the "Shopmade grinder with winch" thread but I had to
use Google Groups. I think you may have missed the message if you're
blocking messages from Google Groups.


I don't always read all threads to the end. That was one which
I skipped over a lot of, when I was overloaded with articles to read.

That's fine. It happens to all of us!

And I'm going to be heavily occupied Saturday and Sunday,
probably not even get to the newsreader on either day -- or perhaps near
midnight on Sunday.


The same thing has now happened to me twice. With the first workstation,
it worked for about 10 days after the clock stopped keeping time. This
time, it worked for about a month. It leads me to believe that Ultra 2
clock problems are perhaps most often caused by motherboard faults as
opposed to a dead NVRAM battery. Anyway, I have now managed to build a
working Ultra 2 from parts with 2048 MB RAM. 2048 MB seems to make the
Ultra 2 slightly faster than it was with 1280 MB. I notice it when the
machine is booting up, which surprises me as I would have expected boot
speed to be limited by hard disk speed.


When it is booting it is loading a lot of programs. With plenty
of RAM, it doesn't have to swap just loaded programs to disk while it is
loading the next one.

I didn't expect it to make a big difference, because I thought that most
of the programs being loaded into RAM during the boot process would be
staying in the RAM. Also, once my old machine was up and running, it
often didn't use all the of the 1280 MB RAM. But I don't know of any way
of looking at RAM usage during the boot process.

I've noticed a significant improvement in boot speed (and in
workspace startup speed) with my boost from 3 GB of RAM to 6 GB, and
want to go to the max of 8 GB for my Sun Blade 2000 to have plenty of
RAM for when I'm doing lots of image processing (which is what is coming
over the weekend, with someone else critically involved in the project
who can't get up here very often.


This means that perhaps my old NVRAM chips are worth preserving. You
mentioned a piece of software which could be used to stop the NVRAM
clock. I searched but couldn't find it online. Looking at the NVRAM
datasheet, it seems like it is not something which can be done with a
crocodile clip. The only reference I could find was for modifying the
contents of an ancient sun4c machine's NVRAM at the "ok" prompt, and I
couldn't immediately see how to use this information with a sun4u Ultra
2. Do you know of a source for software which can be used to stop the
NVRAM clock?


I don't remember for sure where I read about it, but it was
probably in the first hit on a Google search for "Sun NVRAM FAQ"

http://www.squirrel.com/sun-nvram-hostid.faq.html

That's the information that I had seen, too. I was just thinking that
there might be a piece of software which makes the process easy, but I
could not find any mention of it on that page.

This one was posted in February of 2004, FWIW.

And I see that the procedure only mentions the Sun 3/80 (68030
CPU) and the sun 4C (SS1 SS2 IIRC).

I'm not sure whether it would work on the Ultra-2 but I don't
see any reason why it should not, if you can get to the "ok" prompt.

I tried the method intended for sun4c machines on my Ultra 2. I get the
error "Fast Data Access MMU Miss" after the second command.

My best guess is that the addresses for the Write and Stop bits given in
that document for the M48T02 chip are not the correct ones for the later
M48T59Y chip, which contains more memory.

From the M48T59Y datasheet I can understand the structure of the
register in which the Write and Stop bits are held, but I cannot
understand the syntax used at the "ok" prompt (or perhaps not: the
prompt is indicated by ?) to modify the contents of the register. I
cannot find any information online about this syntax other than the
NVRAM FAQ, which does not explain the syntax used to program the NVRAM
at bit level, as opposed to byte level.

I'm sure that someone with more knowledge could figure this out, but I'm
reluctant to experiment with my working machine in case it ceases to
work. It also seems that the two failures which I thought were caused by
dead NVRAM batteries were not, so perhaps the M48T59Y has a longer
lifetime than the M48T02. There do not seem to be any documents
referring to NVRAM problems with the sun4u machines using the M48T59Y chip.

Check the contents of your NVRAM chips (HOSTID and Ethernet MAC
address) and keep a hardcopy version in case you need to perform the
battery surgery which is documented in the website above.

For both the working motherboards I have, I've written down the details
displayed on the screen when the machine boots, such as the serial
number, ethernet address and host ID. For the machine I'm using at the
moment I've also saved a copy of the output of the command "eeprom -v".
Whether or not I need the extra details such as the system board serial
number, I don't know.

I think that's all there was of importance in the post. I speculated a
little about whether common applications such as Firefox and Nautilus
are able to make good use of multiple processors on Sun workstations.
I'm still not certain. But I think that's all.


I depends on whether they are multi-threaded. Though they will
probably use other CPUs for plugins.

I did a bit of reading online and came to the conclusion that Firefox is
multi-threaded, but that one thread handles the user interface,
JavaScript, layout and image decoding. Probably this thread sometimes
gets bogged down!

Thanks for the advice.

Best wishes,

Chris

On 2009-01-05, Christopher Tidy wrote:
DoN. Nichols wrote:
On 2009-01-02, Christopher Tidy wrote:

[ ... ]

The same thing has now happened to me twice. With the first workstation,
it worked for about 10 days after the clock stopped keeping time. This
time, it worked for about a month. It leads me to believe that Ultra 2
clock problems are perhaps most often caused by motherboard faults as
opposed to a dead NVRAM battery. Anyway, I have now managed to build a
working Ultra 2 from parts with 2048 MB RAM. 2048 MB seems to make the
Ultra 2 slightly faster than it was with 1280 MB. I notice it when the
machine is booting up, which surprises me as I would have expected boot
speed to be limited by hard disk speed.


When it is booting it is loading a lot of programs. With plenty
of RAM, it doesn't have to swap just loaded programs to disk while it is
loading the next one.

I didn't expect it to make a big difference, because I thought that most
of the programs being loaded into RAM during the boot process would be
staying in the RAM. Also, once my old machine was up and running, it
often didn't use all the of the 1280 MB RAM. But I don't know of any way
of looking at RAM usage during the boot process.

Well -- you might be able to start "top -S -d1 -u -d1 40" from
one of the rc start files to capture the top 40 processes.

[ ... ]

This means that perhaps my old NVRAM chips are worth preserving. You
mentioned a piece of software which could be used to stop the NVRAM
clock. I searched but couldn't find it online. Looking at the NVRAM
datasheet, it seems like it is not something which can be done with a
crocodile clip. The only reference I could find was for modifying the
contents of an ancient sun4c machine's NVRAM at the "ok" prompt, and I
couldn't immediately see how to use this information with a sun4u Ultra
2. Do you know of a source for software which can be used to stop the
NVRAM clock?


I don't remember for sure where I read about it, but it was
probably in the first hit on a Google search for "Sun NVRAM FAQ"

http://www.squirrel.com/sun-nvram-hostid.faq.html

That's the information that I had seen, too. I was just thinking that
there might be a piece of software which makes the process easy, but I
could not find any mention of it on that page.

This one was posted in February of 2004, FWIW.

And I see that the procedure only mentions the Sun 3/80 (68030
CPU) and the sun 4C (SS1 SS2 IIRC).

I'm not sure whether it would work on the Ultra-2 but I don't
see any reason why it should not, if you can get to the "ok" prompt.

I tried the method intended for sun4c machines on my Ultra 2. I get the
error "Fast Data Access MMU Miss" after the second command.

O.K. The Ultra-2 (and the rest of the ultra systems) at the
"ok" prompt are working with a FORTH interpreter, so you need to write a
program in that to get access to the EEPROM addresses. (Examples are
used for resetting the HOSTID and MAC address on Sun4u machines.)

My best guess is that the addresses for the Write and Stop bits given in
that document for the M48T02 chip are not the correct ones for the later
M48T59Y chip, which contains more memory.

Also -- there may need to be a different starting address when
you are working in that NVRAM on those systems.

From the M48T59Y datasheet I can understand the structure of the
register in which the Write and Stop bits are held, but I cannot
understand the syntax used at the "ok" prompt (or perhaps not: the
prompt is indicated by ?) to modify the contents of the register. I
cannot find any information online about this syntax other than the
NVRAM FAQ, which does not explain the syntax used to program the NVRAM
at bit level, as opposed to byte level.

It is working at byte level. You write 0x80 to set the
write-enable bit, then after you have entered the stop bit, you re-write
the contents of the time field, with a 0x0 where you had 0x80, so you
don't really care about the lost information in the lower bits.

I'm sure that someone with more knowledge could figure this out, but I'm
reluctant to experiment with my working machine in case it ceases to
work. It also seems that the two failures which I thought were caused by
dead NVRAM batteries were not, so perhaps the M48T59Y has a longer
lifetime than the M48T02.

Or -- perhaps those machines are not old enough to have problems
yet. Remember -- as long as the machine itself is powered up, the
battery gives effectively its shelf life. Only when the machine is
powered down is the clock running from the battery instead of from the
system power.

If you really want to protect them, wire wrap a board which does
nothing but apply power to the power and ground pins for the chip. Feed
it 5V and forget about it. (Even add a battery to provde power if you
lose power to another hurricane. :-) If you wire-wrap multiple sockets
(for multiple NVRAM chips) put a sticky-note on each one to tell which
system it belongs in.

You might want to wire the address lines, and other inputs to
ground, so it won't pick up noise and get weird possible settings.

There do not seem to be any documents
referring to NVRAM problems with the sun4u machines using the M48T59Y chip.

They just aren't old enough to have been sitting around
*unpowered* for ten years or so. :-) Start counting from when the
computer center retired the macines, not from when it was made.

Check the contents of your NVRAM chips (HOSTID and Ethernet MAC
address) and keep a hardcopy version in case you need to perform the
battery surgery which is documented in the website above.

For both the working motherboards I have, I've written down the details
displayed on the screen when the machine boots, such as the serial
number, ethernet address and host ID.

Good. Tape a copy to the machine itself.

For the machine I'm using at the
moment I've also saved a copy of the output of the command "eeprom -v".

What does the "-v" option do? It is present on my Solaris 10
one, but it is not documented in the man page under Solaris 10.

Same behavior in Solaris 2.6 on a SS-5.

Whether or not I need the extra details such as the system board serial
number, I don't know.

I think that the serial number is read from the board itself,
not from the NVRAM. In any case, it is present on the barcode label on
the system board.

I think that's all there was of importance in the post. I speculated a
little about whether common applications such as Firefox and Nautilus
are able to make good use of multiple processors on Sun workstations.
I'm still not certain. But I think that's all.


I depends on whether they are multi-threaded. Though they will
probably use other CPUs for plugins.

I did a bit of reading online and came to the conclusion that Firefox is
multi-threaded, but that one thread handles the user interface,
JavaScript, layout and image decoding. Probably this thread sometimes
gets bogged down!

O.K. Try moving to a Sun Blade 2000 with dual 1.2 GHz CPUs, and
8GB of RAM. You'll *still* find a browser coming to a halt from time to
time -- based on net delays to/from whatever site you are visiting.

Enjoy,
DoN.

--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

Hi Don,

Thanks for the advice. Sorry I've taken a week to reply.

I didn't expect it to make a big difference, because I thought that most
of the programs being loaded into RAM during the boot process would be
staying in the RAM. Also, once my old machine was up and running, it
often didn't use all the of the 1280 MB RAM. But I don't know of any way
of looking at RAM usage during the boot process.


Well -- you might be able to start "top -S -d1 -u -d1 40" from
one of the rc start files to capture the top 40 processes.

That's starting to sound complicated. For something which is a matter of
curiousity, anyway :-).

This means that perhaps my old NVRAM chips are worth preserving. You
mentioned a piece of software which could be used to stop the NVRAM
clock. I searched but couldn't find it online. Looking at the NVRAM
datasheet, it seems like it is not something which can be done with a
crocodile clip. The only reference I could find was for modifying the
contents of an ancient sun4c machine's NVRAM at the "ok" prompt, and I
couldn't immediately see how to use this information with a sun4u Ultra
2. Do you know of a source for software which can be used to stop the
NVRAM clock?


I don't remember for sure where I read about it, but it was
probably in the first hit on a Google search for "Sun NVRAM FAQ"

http://www.squirrel.com/sun-nvram-hostid.faq.html

That's the information that I had seen, too. I was just thinking that
there might be a piece of software which makes the process easy, but I
could not find any mention of it on that page.


This one was posted in February of 2004, FWIW.

And I see that the procedure only mentions the Sun 3/80 (68030
CPU) and the sun 4C (SS1 SS2 IIRC).

I'm not sure whether it would work on the Ultra-2 but I don't
see any reason why it should not, if you can get to the "ok" prompt.

I tried the method intended for sun4c machines on my Ultra 2. I get the
error "Fast Data Access MMU Miss" after the second command.


O.K. The Ultra-2 (and the rest of the ultra systems) at the
"ok" prompt are working with a FORTH interpreter, so you need to write a
program in that to get access to the EEPROM addresses. (Examples are
used for resetting the HOSTID and MAC address on Sun4u machines.)

That's useful to know. The "ok" prompt has always been something of a
mystery to me, even though I've figured out how to use it for a few
basic things.

My best guess is that the addresses for the Write and Stop bits given in
that document for the M48T02 chip are not the correct ones for the later
M48T59Y chip, which contains more memory.


Also -- there may need to be a different starting address when
you are working in that NVRAM on those systems.

Indeed. I was trying to figure this out from the data sheet, but failed.

From the M48T59Y datasheet I can understand the structure of the
register in which the Write and Stop bits are held, but I cannot
understand the syntax used at the "ok" prompt (or perhaps not: the
prompt is indicated by ?) to modify the contents of the register. I
cannot find any information online about this syntax other than the
NVRAM FAQ, which does not explain the syntax used to program the NVRAM
at bit level, as opposed to byte level.


It is working at byte level. You write 0x80 to set the
write-enable bit, then after you have entered the stop bit, you re-write
the contents of the time field, with a 0x0 where you had 0x80, so you
don't really care about the lost information in the lower bits.

How does 0x80 correspond to setting the write-enable bit to 1?

I'm sure that someone with more knowledge could figure this out, but I'm
reluctant to experiment with my working machine in case it ceases to
work. It also seems that the two failures which I thought were caused by
dead NVRAM batteries were not, so perhaps the M48T59Y has a longer
lifetime than the M48T02.


Or -- perhaps those machines are not old enough to have problems
yet. Remember -- as long as the machine itself is powered up, the
battery gives effectively its shelf life. Only when the machine is
powered down is the clock running from the battery instead of from the
system power.

Quite likely. Maybe I just need to wait a few years for the information
to appear.

If you really want to protect them, wire wrap a board which does
nothing but apply power to the power and ground pins for the chip. Feed
it 5V and forget about it. (Even add a battery to provde power if you
lose power to another hurricane. :-) If you wire-wrap multiple sockets
(for multiple NVRAM chips) put a sticky-note on each one to tell which
system it belongs in.

You might want to wire the address lines, and other inputs to
ground, so it won't pick up noise and get weird possible settings.

Good idea. This might be a simpler solution. I think I have a 5 V "wall
wart" adaptor somewhere. Or I guess I could just power up the unused
machine now and then, but that might not be so effective at preserving
the battery life.

Incidentally, what exactly does the phrase "wire wrap" mean? I think
I've followed your meaning, but I've not come across that phrase before.

There do not seem to be any documents
referring to NVRAM problems with the sun4u machines using the M48T59Y chip.


They just aren't old enough to have been sitting around
*unpowered* for ten years or so. :-) Start counting from when the
computer center retired the macines, not from when it was made.


Check the contents of your NVRAM chips (HOSTID and Ethernet MAC
address) and keep a hardcopy version in case you need to perform the
battery surgery which is documented in the website above.

For both the working motherboards I have, I've written down the details
displayed on the screen when the machine boots, such as the serial
number, ethernet address and host ID.


Good. Tape a copy to the machine itself.


For the machine I'm using at the
moment I've also saved a copy of the output of the command "eeprom -v".


What does the "-v" option do? It is present on my Solaris 10
one, but it is not documented in the man page under Solaris 10.

Same behavior in Solaris 2.6 on a SS-5.

I thought "-v" was a verbose option, which listed all the data stored in
the NVRAM. But it actually seems to give the same data as "eeprom"
alone, so the verbose option probably doesn't exist. I am probably
confusing it with "prtdiag -v", "prtconf -v" and "psrinfo -v".

Whether or not I need the extra details such as the system board serial
number, I don't know.


I think that the serial number is read from the board itself,
not from the NVRAM. In any case, it is present on the barcode label on
the system board.


I think that's all there was of importance in the post. I speculated a
little about whether common applications such as Firefox and Nautilus
are able to make good use of multiple processors on Sun workstations.
I'm still not certain. But I think that's all.


I depends on whether they are multi-threaded. Though they will
probably use other CPUs for plugins.

I did a bit of reading online and came to the conclusion that Firefox is
multi-threaded, but that one thread handles the user interface,
JavaScript, layout and image decoding. Probably this thread sometimes
gets bogged down!


O.K. Try moving to a Sun Blade 2000 with dual 1.2 GHz CPUs, and
8GB of RAM. You'll *still* find a browser coming to a halt from time to
time -- based on net delays to/from whatever site you are visiting.

The thing is, with a web browser, you often can't be sure what's causing
the delay.

At least with Sun machines, they don't seem to get slower with time like
Windows machines. One of my friends once said that Windows had a half
life of six months: i.e., the speed of your computer for most practical
purposes halves every six months.

Best wishes,

Chris

On 2009-01-14, Christopher Tidy wrote:
Hi Don,

Thanks for the advice. Sorry I've taken a week to reply.

I didn't expect it to make a big difference, because I thought that most
of the programs being loaded into RAM during the boot process would be
staying in the RAM. Also, once my old machine was up and running, it
often didn't use all the of the 1280 MB RAM. But I don't know of any way
of looking at RAM usage during the boot process.


Well -- you might be able to start "top -S -d1 -u -d1 40" from
one of the rc start files to capture the top 40 processes.

That's starting to sound complicated. For something which is a matter of
curiousity, anyway :-).

Normally, you can just use "top" to see what the most active
processes running are at any given time. The 40 there is to select 40
lines of output (for the top 40 processes), and some of the others are
to redirect a single snapshot to a file instead of constantly updating on
the screen as is the default (You are wanting to see this from before
you probably have a command line to use, which is why you put it in a rc
file so the machine runs it instead of you.

[ ... ]

I tried the method intended for sun4c machines on my Ultra 2. I get the
error "Fast Data Access MMU Miss" after the second command.


O.K. The Ultra-2 (and the rest of the ultra systems) at the
"ok" prompt are working with a FORTH interpreter, so you need to write a
program in that to get access to the EEPROM addresses. (Examples are
used for resetting the HOSTID and MAC address on Sun4u machines.)

That's useful to know. The "ok" prompt has always been something of a
mystery to me, even though I've figured out how to use it for a few
basic things.

Download a booklet from Sun's site on the commands present in
your major version of the OBP firmware.

My best guess is that the addresses for the Write and Stop bits given in
that document for the M48T02 chip are not the correct ones for the later
M48T59Y chip, which contains more memory.


Also -- there may need to be a different starting address when
you are working in that NVRAM on those systems.

Indeed. I was trying to figure this out from the data sheet, but failed.

The problem is that you have no way of knowing where it is
placed in the machine's address space -- it could start anywhere, and be
remapped anywhere else by the firmware.

[ ... ]

It is working at byte level. You write 0x80 to set the
write-enable bit, then after you have entered the stop bit, you re-write
the contents of the time field, with a 0x0 where you had 0x80, so you
don't really care about the lost information in the lower bits.

How does 0x80 correspond to setting the write-enable bit to 1?

The register uses the MSB for the write-enable bit according to
the data which we have. 0x80 is the symbol for hex 80, which in binary
is: 1000 0000 (Broken into upper and lower nybbles corresponding to the
digits in the hex number.) So -- it sets the MSB (the write-enable bit)
to 1, and all others to zero.

I'm sure that someone with more knowledge could figure this out, but I'm
reluctant to experiment with my working machine in case it ceases to
work. It also seems that the two failures which I thought were caused by
dead NVRAM batteries were not, so perhaps the M48T59Y has a longer
lifetime than the M48T02.


Or -- perhaps those machines are not old enough to have problems
yet. Remember -- as long as the machine itself is powered up, the
battery gives effectively its shelf life. Only when the machine is
powered down is the clock running from the battery instead of from the
system power.

Quite likely. Maybe I just need to wait a few years for the information
to appear.

:-)

And bear in mind that the Sun Blade 2000 (presumably and later
Sun machines) uses serial EPROMS for the NVRAM which does not need
battery backup -- and runs the clock chip from a coin cell in a holder
on the system board, so it no longer matters. :-)

If you really want to protect them, wire wrap a board which does
nothing but apply power to the power and ground pins for the chip. Feed
it 5V and forget about it. (Even add a battery to provide power if you
lose power to another hurricane. :-) If you wire-wrap multiple sockets
(for multiple NVRAM chips) put a sticky-note on each one to tell which
system it belongs in.

You might want to wire the address lines, and other inputs to
ground, so it won't pick up noise and get weird possible settings.

Good idea. This might be a simpler solution. I think I have a 5 V "wall
wart" adaptor somewhere. Or I guess I could just power up the unused
machine now and then, but that might not be so effective at preserving
the battery life.

Nope -- you need to power the chips *full* *time* to preserve
the battery life -- and they will eventually die just from shelf life
anyway. :-)

Incidentally, what exactly does the phrase "wire wrap" mean? I think
I've followed your meaning, but I've not come across that phrase before.

A method of construction which I like for quick-and-dirty
experiments. You don't have to make a PC board for it. Essentially,
each pin on each socket has a long square shaft with sharp edges. The
wire-wrap tool takes the 30 Ga solid wire and wraps it ten times around
the square pin under tension. There is enough pin length to allow three
wires to be terminated on there. There are tools which you can twirl
between thumb and index finger, or tools which operate by squeezing a
handle to get the 10 turns, or electrically or air powered guns for the
task. I have examples of all but the air powered version, and have
built entire CPU boards for a SWTP 6800 (to separate the baud rate
generation from the CPU clock generation so I could go to the full 2MHz
on the later 68B00 CPU chips). And I have built a special purpose
computer at work with mulitipile dual-port memory boards for a project.

It works quite well, and it is easy to revise the design at
need.

[ ... ]

For both the working motherboards I have, I've written down the details
displayed on the screen when the machine boots, such as the serial
number, ethernet address and host ID.


Good. Tape a copy to the machine itself.


For the machine I'm using at the
moment I've also saved a copy of the output of the command "eeprom -v".


What does the "-v" option do? It is present on my Solaris 10
one, but it is not documented in the man page under Solaris 10.

Same behavior in Solaris 2.6 on a SS-5.

I thought "-v" was a verbose option, which listed all the data stored in
the NVRAM. But it actually seems to give the same data as "eeprom"
alone, so the verbose option probably doesn't exist. I am probably
confusing it with "prtdiag -v", "prtconf -v" and "psrinfo -v".

BTW -- for most things, unless you have set unusual things into
the EEPROM settings, such as a special boot device, you can simply use
the command "set-defaults" at the "ok" prompt. This does nothing to
restore the HOSTID and the MAC address, unfortunately. :-)

[ ... ]

I did a bit of reading online and came to the conclusion that Firefox is
multi-threaded, but that one thread handles the user interface,
JavaScript, layout and image decoding. Probably this thread sometimes
gets bogged down!


O.K. Try moving to a Sun Blade 2000 with dual 1.2 GHz CPUs, and
8GB of RAM. You'll *still* find a browser coming to a halt from time to
time -- based on net delays to/from whatever site you are visiting.

The thing is, with a web browser, you often can't be sure what's causing
the delay.

Agreed.

My won favorite browser is Opera -- for the UltraSPARC machines
and several other flavors made by other companies, but not for the older
Sun machines. (Hmm ... it is compiled as 32-bit code, so maybe it will
work with the older systems -- if the needed shared libs are present.
Of course, I download the static version, so it is less sensitive to
changes in shared libs.

At least with Sun machines, they don't seem to get slower with time like
Windows machines. One of my friends once said that Windows had a half
life of six months: i.e., the speed of your computer for most practical
purposes halves every six months.

Well ... part of that is that they get bogged down with spyware
and malware which starts chewing up CPU cycles.

Also -- the filesystem needs regular defragmenting.

And Microsoft keeps "improving" them by loading yet more stuff
in there with every service pack. :-)

And -- it all still has to continue working with ancient
programs which make it harder to patch for fixing security holes. :-)

Enjoy,
DoN.

--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

Hi Don,

Well -- you might be able to start "top -S -d1 -u -d1 40" from
one of the rc start files to capture the top 40 processes.

That's starting to sound complicated. For something which is a matter of
curiousity, anyway :-).


Normally, you can just use "top" to see what the most active
processes running are at any given time. The 40 there is to select 40
lines of output (for the top 40 processes), and some of the others are
to redirect a single snapshot to a file instead of constantly updating on
the screen as is the default (You are wanting to see this from before
you probably have a command line to use, which is why you put it in a rc
file so the machine runs it instead of you.

I can't find "top" on my Solaris 9 system. In which directory is it
normally located? It isn't a command that was introduced with Solaris
10, is it? I guess it's possible that its directory isn't in my PATH.

I tried the method intended for sun4c machines on my Ultra 2. I get the
error "Fast Data Access MMU Miss" after the second command.


O.K. The Ultra-2 (and the rest of the ultra systems) at the
"ok" prompt are working with a FORTH interpreter, so you need to write a
program in that to get access to the EEPROM addresses. (Examples are
used for resetting the HOSTID and MAC address on Sun4u machines.)

That's useful to know. The "ok" prompt has always been something of a
mystery to me, even though I've figured out how to use it for a few
basic things.


Download a booklet from Sun's site on the commands present in
your major version of the OBP firmware.

Right. I'll have a look for that booklet. I haven't used the Sun
documentation website much since they started requiring a support
contract before you could download much of the documentation. But that
was a few years back. I think it may have changed back to being free.

My best guess is that the addresses for the Write and Stop bits given in
that document for the M48T02 chip are not the correct ones for the later
M48T59Y chip, which contains more memory.


Also -- there may need to be a different starting address when
you are working in that NVRAM on those systems.

Indeed. I was trying to figure this out from the data sheet, but failed.


The problem is that you have no way of knowing where it is
placed in the machine's address space -- it could start anywhere, and be
remapped anywhere else by the firmware.

[ ... ]


It is working at byte level. You write 0x80 to set the
write-enable bit, then after you have entered the stop bit, you re-write
the contents of the time field, with a 0x0 where you had 0x80, so you
don't really care about the lost information in the lower bits.

How does 0x80 correspond to setting the write-enable bit to 1?


The register uses the MSB for the write-enable bit according to
the data which we have. 0x80 is the symbol for hex 80, which in binary
is: 1000 0000 (Broken into upper and lower nybbles corresponding to the
digits in the hex number.) So -- it sets the MSB (the write-enable bit)
to 1, and all others to zero.

I think I see. Does the "0x" indicate that the other two characters
represent a number in hexadecimal?

I'm sure that someone with more knowledge could figure this out, but I'm
reluctant to experiment with my working machine in case it ceases to
work. It also seems that the two failures which I thought were caused by
dead NVRAM batteries were not, so perhaps the M48T59Y has a longer
lifetime than the M48T02.


Or -- perhaps those machines are not old enough to have problems
yet. Remember -- as long as the machine itself is powered up, the
battery gives effectively its shelf life. Only when the machine is
powered down is the clock running from the battery instead of from the
system power.

Quite likely. Maybe I just need to wait a few years for the information
to appear.


:-)

And bear in mind that the Sun Blade 2000 (presumably and later
Sun machines) uses serial EPROMS for the NVRAM which does not need
battery backup -- and runs the clock chip from a coin cell in a holder
on the system board, so it no longer matters. :-)


If you really want to protect them, wire wrap a board which does
nothing but apply power to the power and ground pins for the chip. Feed
it 5V and forget about it. (Even add a battery to provide power if you
lose power to another hurricane. :-) If you wire-wrap multiple sockets
(for multiple NVRAM chips) put a sticky-note on each one to tell which
system it belongs in.

You might want to wire the address lines, and other inputs to
ground, so it won't pick up noise and get weird possible settings.

Good idea. This might be a simpler solution. I think I have a 5 V "wall
wart" adaptor somewhere. Or I guess I could just power up the unused
machine now and then, but that might not be so effective at preserving
the battery life.


Nope -- you need to power the chips *full* *time* to preserve
the battery life -- and they will eventually die just from shelf life
anyway. :-)

I just looked at the data sheet again. I thought at first that the
battery was rechargeable, which would seem sensible, but it seems that
it is not. Thanks for pointing this out!

Incidentally, what exactly does the phrase "wire wrap" mean? I think
I've followed your meaning, but I've not come across that phrase before.


A method of construction which I like for quick-and-dirty
experiments. You don't have to make a PC board for it. Essentially,
each pin on each socket has a long square shaft with sharp edges. The
wire-wrap tool takes the 30 Ga solid wire and wraps it ten times around
the square pin under tension. There is enough pin length to allow three
wires to be terminated on there. There are tools which you can twirl
between thumb and index finger, or tools which operate by squeezing a
handle to get the 10 turns, or electrically or air powered guns for the
task. I have examples of all but the air powered version, and have
built entire CPU boards for a SWTP 6800 (to separate the baud rate
generation from the CPU clock generation so I could go to the full 2MHz
on the later 68B00 CPU chips). And I have built a special purpose
computer at work with mulitipile dual-port memory boards for a project.

It works quite well, and it is easy to revise the design at
need.

I seem to recall seeing circuits built like this under test in
laboratories before. Actually, I think I've seen one which had solder
over the wrapped wire.

For both the working motherboards I have, I've written down the details
displayed on the screen when the machine boots, such as the serial
number, ethernet address and host ID.


Good. Tape a copy to the machine itself.



For the machine I'm using at the
moment I've also saved a copy of the output of the command "eeprom -v".


What does the "-v" option do? It is present on my Solaris 10
one, but it is not documented in the man page under Solaris 10.

Same behavior in Solaris 2.6 on a SS-5.

I thought "-v" was a verbose option, which listed all the data stored in
the NVRAM. But it actually seems to give the same data as "eeprom"
alone, so the verbose option probably doesn't exist. I am probably
confusing it with "prtdiag -v", "prtconf -v" and "psrinfo -v".


BTW -- for most things, unless you have set unusual things into
the EEPROM settings, such as a special boot device, you can simply use
the command "set-defaults" at the "ok" prompt. This does nothing to
restore the HOSTID and the MAC address, unfortunately. :-)

Shame it doesn't fix the HOSTID and MAC address. Would be a useful feature!

I did a bit of reading online and came to the conclusion that Firefox is
multi-threaded, but that one thread handles the user interface,
JavaScript, layout and image decoding. Probably this thread sometimes
gets bogged down!


O.K. Try moving to a Sun Blade 2000 with dual 1.2 GHz CPUs, and
8GB of RAM. You'll *still* find a browser coming to a halt from time to
time -- based on net delays to/from whatever site you are visiting.

The thing is, with a web browser, you often can't be sure what's causing
the delay.


Agreed.

My won favorite browser is Opera -- for the UltraSPARC machines
and several other flavors made by other companies, but not for the older
Sun machines. (Hmm ... it is compiled as 32-bit code, so maybe it will
work with the older systems -- if the needed shared libs are present.
Of course, I download the static version, so it is less sensitive to
changes in shared libs.

My favourite browser is Netscape 7. Unfortunately I've had to switch to
using Mozilla Firefox for daily use as Netscape is no longer updated. I
still use Netscape 7 for Usenet, though. I tried Opera once, but never
liked the look of it much. I preferred the look of Netscape or Firefox,
and there didn't seem to be an advantage to using Opera.

At least with Sun machines, they don't seem to get slower with time like
Windows machines. One of my friends once said that Windows had a half
life of six months: i.e., the speed of your computer for most practical
purposes halves every six months.


Well ... part of that is that they get bogged down with spyware
and malware which starts chewing up CPU cycles.

Also -- the filesystem needs regular defragmenting.

And Microsoft keeps "improving" them by loading yet more stuff
in there with every service pack. :-)

And -- it all still has to continue working with ancient
programs which make it harder to patch for fixing security holes. :-)

I have never been sure how backward compatible Solaris is supposed to
be. I'm sure that on one occasion in the past I got a program intended
for Solaris 7 or 8 to run under Solaris 9.

Best wishes,

Chris

On 2009-01-21, Christopher Tidy wrote:
Hi Don,

[ ... ]

Normally, you can just use "top" to see what the most active
processes running are at any given time. The 40 there is to select 40
lines of output (for the top 40 processes), and some of the others are
to redirect a single snapshot to a file instead of constantly updating on
the screen as is the default (You are wanting to see this from before
you probably have a command line to use, which is why you put it in a rc
file so the machine runs it instead of you.

I can't find "top" on my Solaris 9 system. In which directory is it
normally located? It isn't a command that was introduced with Solaris
10, is it? I guess it's possible that its directory isn't in my PATH.

It is an open source program, so for Solaris 10 it is in

/opt/sfw/bin/top

I suspect that it is in the same directory for Solaris 9 -- *if* you
have installed the Software_Companion CD. Otherwise, you can download
the source and compile it yourself. This is one program which *has* to
be compiled on the OS version on which you need to use it, because it
has to dig deep into the kernel to get the information which it
displays. I've compiled it on a lot of systems over the years, each
automatically customized to the system under which I was compiling it,
including the ability to display the load on each of multiple processors
at need.

Here is an example from the system on which I am typing this,
cut off after what I intend to show:

================================================== ====================
load averages: 0.05, 0.04, 0.03 22:41:35
236 processes: 234 sleeping, 2 on cpu
CPU states: 90.8% idle, 0.9% user, 8.3% kernel, 0.0% iowait, 0.0% swap
Memory: 6144M real, 267M free, 663M swap in use, 7894M swap free

PID USERNAME LWP PRI NICE SIZE RES STATE TIME CPU COMMAND
728 dnichols 1 35 0 1576K 1336K cpu/0 0:01 3.02% find
7076 dnichols 1 59 0 175M 72M sleep 113.1H 0.25% Xsun
692 root 1 49 0 4136K 1752K cpu/1 0:01 0.20% top
696 noaccess 25 59 0 202M 98M sleep 101:39 0.04% java
7227 dnichols 1 59 0 4848K 1888K sleep 21:52 0.04% xeyes
556 root 1 59 0 2288K 800K sleep 59:57 0.02% rpc.rstatd
7242 dnichols 1 49 0 10M 5480K sleep 0:36 0.02% dtterm
7296 dnichols 1 49 0 10M 4752K sleep 0:32 0.02% dtterm
16739 dnichols 1 49 0 5696K 2576K sleep 4:59 0.02% perfmeter
16729 dnichols 1 49 0 5624K 2528K sleep 5:18 0.02% perfmeter
================================================== ====================

Note that in the "STATE" column, you will see that most
processes are showing as "sleep", but one is "cpu/1" and one is "cpu/0".
Naturally, one of the two will always show as "top", since it has to be
active to run the software to display the information.

If you have four CPUs , you will see all four on there, if the
system is busy enough. Normally most processes are using little enough
of the system so they fall off the bottom of the list. I had to start
a:

find / -name junuqe -print

to get two up high on the list at the same time. :-)

[ ... ]

It is working at byte level. You write 0x80 to set the
write-enable bit, then after you have entered the stop bit, you re-write
the contents of the time field, with a 0x0 where you had 0x80, so you
don't really care about the lost information in the lower bits.

How does 0x80 correspond to setting the write-enable bit to 1?


The register uses the MSB for the write-enable bit according to
the data which we have. 0x80 is the symbol for hex 80, which in binary
is: 1000 0000 (Broken into upper and lower nybbles corresponding to the
digits in the hex number.) So -- it sets the MSB (the write-enable bit)
to 1, and all others to zero.

I think I see. Does the "0x" indicate that the other two characters
represent a number in hexadecimal?

Yes. It is standard in 'C' -- and scanf(3) when trying to read
in numbers.

Numbers which start with [1-9] are decimal. Numbers which start
with '0' are octal -- *unless* the next character is 'x'. It is also a
standard output format in printf(3).

[ ... NVRAM life extension for retired machines ... ]

You might want to wire the address lines, and other inputs to
ground, so it won't pick up noise and get weird possible settings.

Good idea. This might be a simpler solution. I think I have a 5 V "wall
wart" adaptor somewhere. Or I guess I could just power up the unused
machine now and then, but that might not be so effective at preserving
the battery life.


Nope -- you need to power the chips *full* *time* to preserve
the battery life -- and they will eventually die just from shelf life
anyway. :-)

I just looked at the data sheet again. I thought at first that the
battery was rechargeable, which would seem sensible, but it seems that
it is not. Thanks for pointing this out!

Nope -- it is a coin cell -- and those are typically not
rechargeable.

Incidentally, what exactly does the phrase "wire wrap" mean? I think
I've followed your meaning, but I've not come across that phrase before.


A method of construction which I like for quick-and-dirty
experiments. You don't have to make a PC board for it. Essentially,
each pin on each socket has a long square shaft with sharp edges. The
wire-wrap tool takes the 30 Ga solid wire and wraps it ten times around
the square pin under tension. There is enough pin length to allow three
wires to be terminated on there. There are tools which you can twirl
between thumb and index finger, or tools which operate by squeezing a
handle to get the 10 turns, or electrically or air powered guns for the
task. I have examples of all but the air powered version, and have
built entire CPU boards for a SWTP 6800 (to separate the baud rate
generation from the CPU clock generation so I could go to the full 2MHz
on the later 68B00 CPU chips). And I have built a special purpose
computer at work with multipile dual-port memory boards for a project.

It works quite well, and it is easy to revise the design at
need.

I seem to recall seeing circuits built like this under test in
laboratories before. Actually, I think I've seen one which had solder
over the wrapped wire.

Arrggghhhh! The phone company started wire-wrap -- using larger
pins and heavier gauge wires. They consider a wire-wrapped connection
to be "permanent", and a soldered connection to be "temporary", so
putting solder over a wire-wrapped connection is bad news. :-)

[ ... ]

BTW -- for most things, unless you have set unusual things into
the EEPROM settings, such as a special boot device, you can simply use
the command "set-defaults" at the "ok" prompt. This does nothing to
restore the HOSTID and the MAC address, unfortunately. :-)

Shame it doesn't fix the HOSTID and MAC address. Would be a useful feature!

It *can't*. The other settings are constant from system to
system as default values, so they are just compiled into the
set-defaults program, but HOSTID and the MAC address *must* be unique
for each system -- so they come in the NVRAM -- and are identified by
the barcode label on the NVRAM chip. If you have licensed software, you
buy a new NVRAM clock chip from Sun, after feeding them the barcode, and
they make a replacement with the same codes.

Solbourne (made SPARC clone systems) used a coin cell on the
system board in a clip-in holder, and a NVRAM for all the optional
configuration things -- but HOSTID and the MAC address were in a small
bipolar PROM chip. If you had licensed software, and you had to replace
the system board (as I did once at work) you had to transfer that
bipolar PROM to a socket in the new board. The clock chip and the NVRAM
did not have to be transferred.

[ ... ]

The thing is, with a web browser, you often can't be sure what's causing
the delay.


Agreed.

My won favorite browser is Opera -- for the UltraSPARC machines
and several other flavors made by other companies, but not for the older
Sun machines. (Hmm ... it is compiled as 32-bit code, so maybe it will
work with the older systems -- if the needed shared libs are present.
Of course, I download the static version, so it is less sensitive to
changes in shared libs.

My favourite browser is Netscape 7. Unfortunately I've had to switch to
using Mozilla Firefox for daily use as Netscape is no longer updated. I
still use Netscape 7 for Usenet, though. I tried Opera once, but never
liked the look of it much. I preferred the look of Netscape or Firefox,
and there didn't seem to be an advantage to using Opera.

Opera is typically much faster to start than NetScape, has the
ability to disable JavaScript, Java, and plugins (including FLASH) and
then re-enabling them on a site-by-site basis as needed.

There are multiple "skins" available for Opera, which change the
look and feel of it.

It can also be set to claim that it is NetScape or Internet
Explorer -- or even to "mask" as either for web sites which depend on
IE's broken behavior. :-)

*And* -- there is a setting in there which allows you to set the
behavior with control sequences -- such as ^A to move to the beginning
of the line, or ^U to erase the whole line (unix style) -- or to invoke
other things by default. I prefer the unix style setting.

At least with Sun machines, they don't seem to get slower with time like
Windows machines. One of my friends once said that Windows had a half
life of six months: i.e., the speed of your computer for most practical
purposes halves every six months.


Well ... part of that is that they get bogged down with spyware
and malware which starts chewing up CPU cycles.

Also -- the filesystem needs regular defragmenting.

And Microsoft keeps "improving" them by loading yet more stuff
in there with every service pack. :-)

And -- it all still has to continue working with ancient
programs which make it harder to patch for fixing security holes. :-)

I have never been sure how backward compatible Solaris is supposed to
be. I'm sure that on one occasion in the past I got a program intended
for Solaris 7 or 8 to run under Solaris 9.

I've run programs which I compiled under SunOs 4.1.4 in Solaris
2.6, and I believe that it is still possible in Solaris 10. Solaris 10
can run 32-bit or 64-bit mode as needed, and most programs compiled
under the earlier systems run using compatibility shared libs. Come
things (such as top) which dig deeply into the kernel, *can't* do this,
but most application programs have no problems.

I ran jove (my favorite editor) for years using an old version
compiled under SunOs 4.1.2 or SunOs 4.1.4. I recently re-compiled it to
run in 64-bit mode under Solaris 10 using the "Studio 12" compilers from
Sun. (Jove tended to have troubles compiling under gcc, which is why I
ran the older version for so long. But now Solaris 10 includes the
ability to separately download the development system (Studio 12 and
"NetBeans" -- the java-based integrated development environment.

Enjoy,
DoN.

--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

Hi Don,

I can't find "top" on my Solaris 9 system. In which directory is it
normally located? It isn't a command that was introduced with Solaris
10, is it? I guess it's possible that its directory isn't in my PATH.


It is an open source program, so for Solaris 10 it is in

/opt/sfw/bin/top

I suspect that it is in the same directory for Solaris 9 -- *if* you
have installed the Software_Companion CD. Otherwise, you can download
the source and compile it yourself. This is one program which *has* to
be compiled on the OS version on which you need to use it, because it
has to dig deep into the kernel to get the information which it
displays. I've compiled it on a lot of systems over the years, each
automatically customized to the system under which I was compiling it,
including the ability to display the load on each of multiple processors
at need.

I've only got the GIMP installed from the Software Companion CD. Nothing
else. I'm thinking I'm going to re-install Solaris shortly - certain
pieces of software got corrupted, I think the result of a shared
libraries problem of some sort, and re-installing seems the simplest way
to fix everything - so I can add "top" from the Companion CD then.

I often get the feeling that shared libraries aren't such a great idea.

Here is an example from the system on which I am typing this,
cut off after what I intend to show:

================================================== ====================
load averages: 0.05, 0.04, 0.03 22:41:35
236 processes: 234 sleeping, 2 on cpu
CPU states: 90.8% idle, 0.9% user, 8.3% kernel, 0.0% iowait, 0.0% swap
Memory: 6144M real, 267M free, 663M swap in use, 7894M swap free

PID USERNAME LWP PRI NICE SIZE RES STATE TIME CPU COMMAND
728 dnichols 1 35 0 1576K 1336K cpu/0 0:01 3.02% find
7076 dnichols 1 59 0 175M 72M sleep 113.1H 0.25% Xsun
692 root 1 49 0 4136K 1752K cpu/1 0:01 0.20% top
696 noaccess 25 59 0 202M 98M sleep 101:39 0.04% java
7227 dnichols 1 59 0 4848K 1888K sleep 21:52 0.04% xeyes
556 root 1 59 0 2288K 800K sleep 59:57 0.02% rpc.rstatd
7242 dnichols 1 49 0 10M 5480K sleep 0:36 0.02% dtterm
7296 dnichols 1 49 0 10M 4752K sleep 0:32 0.02% dtterm
16739 dnichols 1 49 0 5696K 2576K sleep 4:59 0.02% perfmeter
16729 dnichols 1 49 0 5624K 2528K sleep 5:18 0.02% perfmeter
================================================== ====================

Note that in the "STATE" column, you will see that most
processes are showing as "sleep", but one is "cpu/1" and one is "cpu/0".
Naturally, one of the two will always show as "top", since it has to be
active to run the software to display the information.

If you have four CPUs , you will see all four on there, if the
system is busy enough. Normally most processes are using little enough
of the system so they fall off the bottom of the list. I had to start
a:

find / -name junuqe -print

to get two up high on the list at the same time. :-)

I'll try this when I get "top" installed.

It is working at byte level. You write 0x80 to set the
write-enable bit, then after you have entered the stop bit, you re-write
the contents of the time field, with a 0x0 where you had 0x80, so you
don't really care about the lost information in the lower bits.

How does 0x80 correspond to setting the write-enable bit to 1?


The register uses the MSB for the write-enable bit according to
the data which we have. 0x80 is the symbol for hex 80, which in binary
is: 1000 0000 (Broken into upper and lower nybbles corresponding to the
digits in the hex number.) So -- it sets the MSB (the write-enable bit)
to 1, and all others to zero.

I think I see. Does the "0x" indicate that the other two characters
represent a number in hexadecimal?


Yes. It is standard in 'C' -- and scanf(3) when trying to read
in numbers.

Numbers which start with [1-9] are decimal. Numbers which start
with '0' are octal -- *unless* the next character is 'x'. It is also a
standard output format in printf(3).

Thanks for explaining that. It makes sense now.

[ ... NVRAM life extension for retired machines ... ]


You might want to wire the address lines, and other inputs to
ground, so it won't pick up noise and get weird possible settings.

Good idea. This might be a simpler solution. I think I have a 5 V "wall
wart" adaptor somewhere. Or I guess I could just power up the unused
machine now and then, but that might not be so effective at preserving
the battery life.


Nope -- you need to power the chips *full* *time* to preserve
the battery life -- and they will eventually die just from shelf life
anyway. :-)

I just looked at the data sheet again. I thought at first that the
battery was rechargeable, which would seem sensible, but it seems that
it is not. Thanks for pointing this out!


Nope -- it is a coin cell -- and those are typically not
rechargeable.

Surely you can get a bunch of different kinds of rechargeable coin cell,
such as lithium-ion, NiCad and NiMH cells? I guess they aren't as common
as alkaline, lithium and silver-oxide cells, but they do exist.

I thought ST would have been smart enough to use one of these
rechargeable types in the NVRAM chip, but it seems not.

Incidentally, what exactly does the phrase "wire wrap" mean? I think
I've followed your meaning, but I've not come across that phrase before.


A method of construction which I like for quick-and-dirty
experiments. You don't have to make a PC board for it. Essentially,
each pin on each socket has a long square shaft with sharp edges. The
wire-wrap tool takes the 30 Ga solid wire and wraps it ten times around
the square pin under tension. There is enough pin length to allow three
wires to be terminated on there. There are tools which you can twirl
between thumb and index finger, or tools which operate by squeezing a
handle to get the 10 turns, or electrically or air powered guns for the
task. I have examples of all but the air powered version, and have
built entire CPU boards for a SWTP 6800 (to separate the baud rate
generation from the CPU clock generation so I could go to the full 2MHz
on the later 68B00 CPU chips). And I have built a special purpose
computer at work with multipile dual-port memory boards for a project.

It works quite well, and it is easy to revise the design at
need.

I seem to recall seeing circuits built like this under test in
laboratories before. Actually, I think I've seen one which had solder
over the wrapped wire.


Arrggghhhh! The phone company started wire-wrap -- using larger
pins and heavier gauge wires. They consider a wire-wrapped connection
to be "permanent", and a soldered connection to be "temporary", so
putting solder over a wire-wrapped connection is bad news. :-)

Strange. Intuitively I would have thought of the wire-wrapped connection
as being more temporary, but I haven't tried to dismantle one.

BTW -- for most things, unless you have set unusual things into
the EEPROM settings, such as a special boot device, you can simply use
the command "set-defaults" at the "ok" prompt. This does nothing to
restore the HOSTID and the MAC address, unfortunately. :-)

Shame it doesn't fix the HOSTID and MAC address. Would be a useful feature!


It *can't*. The other settings are constant from system to
system as default values, so they are just compiled into the
set-defaults program, but HOSTID and the MAC address *must* be unique
for each system -- so they come in the NVRAM -- and are identified by
the barcode label on the NVRAM chip. If you have licensed software, you
buy a new NVRAM clock chip from Sun, after feeding them the barcode, and
they make a replacement with the same codes.

But if you enter a HOSTID and MAC address which are incorrect for the
particular machine, but start with the right characters (I forget how
many) that'll work, won't it?

Solbourne (made SPARC clone systems) used a coin cell on the
system board in a clip-in holder, and a NVRAM for all the optional
configuration things -- but HOSTID and the MAC address were in a small
bipolar PROM chip. If you had licensed software, and you had to replace
the system board (as I did once at work) you had to transfer that
bipolar PROM to a socket in the new board. The clock chip and the NVRAM
did not have to be transferred.

Neat idea. Sun should have put the HOSTID and MAC address on an PROM
too. Are they on a PROM in the "Blade" machines?

The only SPARC clones I remember here in England were sold under the
name "Lion". I have one of their CD-Rom drives, which has a sturdy metal
case, as opposed to the awful Sun plastic case which you had to stick
nails into the side of to release the latches.

The thing is, with a web browser, you often can't be sure what's causing
the delay.


Agreed.

My won favorite browser is Opera -- for the UltraSPARC machines
and several other flavors made by other companies, but not for the older
Sun machines. (Hmm ... it is compiled as 32-bit code, so maybe it will
work with the older systems -- if the needed shared libs are present.
Of course, I download the static version, so it is less sensitive to
changes in shared libs.

My favourite browser is Netscape 7. Unfortunately I've had to switch to
using Mozilla Firefox for daily use as Netscape is no longer updated. I
still use Netscape 7 for Usenet, though. I tried Opera once, but never
liked the look of it much. I preferred the look of Netscape or Firefox,
and there didn't seem to be an advantage to using Opera.


Opera is typically much faster to start than NetScape, has the
ability to disable JavaScript, Java, and plugins (including FLASH) and
then re-enabling them on a site-by-site basis as needed.

There are multiple "skins" available for Opera, which change the
look and feel of it.

I remember there being three or four skins at the time I tried Opera,
and I didn't really like any of them. It was also somewhat unstable.

Firefox seems fine. I just wish they hadn't made the main navigation
buttons smaller when they developed Netscape 7 or Mozilla 1.5 to become
Firefox.

It can also be set to claim that it is NetScape or Internet
Explorer -- or even to "mask" as either for web sites which depend on
IE's broken behavior. :-)

*And* -- there is a setting in there which allows you to set the
behavior with control sequences -- such as ^A to move to the beginning
of the line, or ^U to erase the whole line (unix style) -- or to invoke
other things by default. I prefer the unix style setting.


At least with Sun machines, they don't seem to get slower with time like
Windows machines. One of my friends once said that Windows had a half
life of six months: i.e., the speed of your computer for most practical
purposes halves every six months.


Well ... part of that is that they get bogged down with spyware
and malware which starts chewing up CPU cycles.

Also -- the filesystem needs regular defragmenting.

And Microsoft keeps "improving" them by loading yet more stuff
in there with every service pack. :-)

And -- it all still has to continue working with ancient
programs which make it harder to patch for fixing security holes. :-)

I have never been sure how backward compatible Solaris is supposed to
be. I'm sure that on one occasion in the past I got a program intended
for Solaris 7 or 8 to run under Solaris 9.


I've run programs which I compiled under SunOs 4.1.4 in Solaris
2.6, and I believe that it is still possible in Solaris 10. Solaris 10
can run 32-bit or 64-bit mode as needed, and most programs compiled
under the earlier systems run using compatibility shared libs. Come
things (such as top) which dig deeply into the kernel, *can't* do this,
but most application programs have no problems.

I ran jove (my favorite editor) for years using an old version
compiled under SunOs 4.1.2 or SunOs 4.1.4. I recently re-compiled it to
run in 64-bit mode under Solaris 10 using the "Studio 12" compilers from
Sun. (Jove tended to have troubles compiling under gcc, which is why I
ran the older version for so long. But now Solaris 10 includes the
ability to separately download the development system (Studio 12 and
"NetBeans" -- the java-based integrated development environment.

So it's a case of often, but not always.

Many thanks,

Chris

On 2009-01-23, Christopher Tidy wrote:
Hi Don,

I can't find "top" on my Solaris 9 system. In which directory is it
normally located? It isn't a command that was introduced with Solaris
10, is it? I guess it's possible that its directory isn't in my PATH.


It is an open source program, so for Solaris 10 it is in

/opt/sfw/bin/top

I suspect that it is in the same directory for Solaris 9 -- *if* you
have installed the Software_Companion CD. Otherwise, you can download
the source and compile it yourself. This is one program which *has* to
be compiled on the OS version on which you need to use it, because it
has to dig deep into the kernel to get the information which it
displays. I've compiled it on a lot of systems over the years, each
automatically customized to the system under which I was compiling it,
including the ability to display the load on each of multiple processors
at need.

I've only got the GIMP installed from the Software Companion CD. Nothing
else. I'm thinking I'm going to re-install Solaris shortly - certain
pieces of software got corrupted, I think the result of a shared
libraries problem of some sort, and re-installing seems the simplest way
to fix everything - so I can add "top" from the Companion CD then.

Some of the programs (and I would have thought that "the GIMP" was
one need a lot of shared libs, some of which are in "/opt/sfw/lib".

FWIW -- in Solaris 10, "the GIMP" is in /usr/sfw/bin instead,
which means that it is part of the standard install, not a part of the
Software_Companion CD.

And yes -- it *does* use a gazillion shared libs:


================================================== ====================
libgimpwidgets-2.0.so.0 = /usr/sfw/lib/libgimpwidgets-2.0.so.0
libgimpcolor-2.0.so.0 = /usr/sfw/lib/libgimpcolor-2.0.so.0
libgimpmodule-2.0.so.0 = /usr/sfw/lib/libgimpmodule-2.0.so.0
libgimpbase-2.0.so.0 = /usr/sfw/lib/libgimpbase-2.0.so.0
libgimpthumb-2.0.so.0 = /usr/sfw/lib/libgimpthumb-2.0.so.0
libgimpmath-2.0.so.0 = /usr/sfw/lib/libgimpmath-2.0.so.0
libgtk-x11-2.0.so.0 = /usr/lib/libgtk-x11-2.0.so.0
libgdk-x11-2.0.so.0 = /usr/lib/libgdk-x11-2.0.so.0
libatk-1.0.so.0 = /usr/lib/libatk-1.0.so.0
libgdk_pixbuf-2.0.so.0 = /usr/lib/libgdk_pixbuf-2.0.so.0
libm.so.2 = /usr/lib/libm.so.2
libmlib.so.2 = /usr/lib/libmlib.so.2
libpangoxft-1.0.so.0 = /usr/lib/libpangoxft-1.0.so.0
libpangox-1.0.so.0 = /usr/lib/libpangox-1.0.so.0
libart_lgpl_2.so.2 = /usr/lib/libart_lgpl_2.so.2
libpangoft2-1.0.so.0 = /usr/lib/libpangoft2-1.0.so.0
libpango-1.0.so.0 = /usr/lib/libpango-1.0.so.0
libgobject-2.0.so.0 = /usr/lib/libgobject-2.0.so.0
libgmodule-2.0.so.0 = /usr/lib/libgmodule-2.0.so.0
libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0
libfontconfig.so.1 = /usr/lib/libfontconfig.so.1
libfreetype.so.6 = /usr/local/lib/libfreetype.so.6
libpthread.so.1 = /usr/lib/libpthread.so.1
libc.so.1 = /usr/lib/libc.so.1
libsocket.so.1 = /usr/lib/libsocket.so.1
libnsl.so.1 = /usr/lib/libnsl.so.1
libXft.so.2 = /usr/openwin/lib/libXft.so.2
libXrender.so.1 = /usr/sfw/lib/libXrender.so.1
libX11.so.4 = /usr/openwin/lib/libX11.so.4
libXrandr.so.2 = /usr/lib/libXrandr.so.2
libXi.so.5 = /usr/openwin/lib/libXi.so.5
libXext.so.0 = /usr/openwin/lib/libXext.so.0
libz.so.1 = /usr/lib/libz.so.1
libexpat.so.0 = /usr/sfw/lib/libexpat.so.0
libgcc_s.so.1 = /opt/gcc/lib/libgcc_s.so.1
libmp.so.2 = /usr/lib/libmp.so.2
libmd.so.1 = /usr/lib/libmd.so.1
libscf.so.1 = /usr/lib/libscf.so.1
libdl.so.1 = /usr/lib/libdl.so.1
libdoor.so.1 = /usr/lib/libdoor.so.1
libuutil.so.1 = /usr/lib/libuutil.so.1
libgen.so.1 = /usr/lib/libgen.so.1
/usr/lib/cpu/sparcv9+vis2/libmlib.so.2
/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1
/platform/SUNW,Sun-Blade-1000/lib/libmd_psr.so.1
================================================== ====================

and those which are in /usr/sfw/lib here would have been in /opt/sfw/lib
in Solaris 9, since it idd not have /usr/sfw/lib at all.

I often get the feeling that shared libraries aren't such a great idea.

They are normally a *good* idea -- in that they make programs
more portable between systems.

The one place where I would like to get rid of shared libs and
go for fully static programs are shells and security tools which you
don't want to risk being compromised by a modified shared lib which does
more than the function call is expected to do.

Now -- I would suggest that if you are re-installing, you should
actually install Solaris 10 instead of Solaris 9. If you do, ask me how
to turn off programs which you may not want to run, such as the
"R-commands" and ftpd and the like.

It is quite different from earlier versions.

[ ... ]

If you have four CPUs , you will see all four on there, if the
system is busy enough. Normally most processes are using little enough
of the system so they fall off the bottom of the list. I had to start
a:

find / -name junque -print

to get two up high on the list at the same time. :-)

I'll try this when I get "top" installed.

O.K.

[ ... ]

Nope -- you need to power the chips *full* *time* to preserve
the battery life -- and they will eventually die just from shelf life
anyway. :-)

I just looked at the data sheet again. I thought at first that the
battery was rechargeable, which would seem sensible, but it seems that
it is not. Thanks for pointing this out!


Nope -- it is a coin cell -- and those are typically not
rechargeable.

Surely you can get a bunch of different kinds of rechargeable coin cell,
such as lithium-ion, NiCad and NiMH cells? I guess they aren't as common
as alkaline, lithium and silver-oxide cells, but they do exist.

The rechargeable ones typically have the wrong voltage. The ones
used are 3V cells, which are just right to keep the clock going and the
CMOS RAM loaded -- even after the voltage drop through a diode which
prevents the current from flowing back to the outside from the battery,
trying to power the whole computer while the line is off. :-)

Also -- the rechargeable ones tend to develop memory problems
requiring replacement, while the life of the selected coin cells is
typically around five years running just the clock chip, and keeping the
memory loaded.

I thought ST would have been smart enough to use one of these
rechargeable types in the NVRAM chip, but it seems not.

Physical size, what to do with the hydrogen from charging the
cell while it is potted in epoxy, wrong voltage, and not available when
the chip was first designed and made.

Incidentally, what exactly does the phrase "wire wrap" mean? I think
I've followed your meaning, but I've not come across that phrase before.

It works quite well, and it is easy to revise the design at
need.

I seem to recall seeing circuits built like this under test in
laboratories before. Actually, I think I've seen one which had solder
over the wrapped wire.


Arrggghhhh! The phone company started wire-wrap -- using larger
pins and heavier gauge wires. They consider a wire-wrapped connection
to be "permanent", and a soldered connection to be "temporary", so
putting solder over a wire-wrapped connection is bad news. :-)

Strange. Intuitively I would have thought of the wire-wrapped connection
as being more temporary, but I haven't tried to dismantle one.

The reason it is so reliable is that it has forty gas-tight
connections -- four for each wrap of the ten total. The sharp edges of
the square post bite into the wire, and the tension of the wire during
wrapping keeps them from coming unhooked.

There is a special tool for undoing the connections -- sort of a
backwards hollow auger which catches the end of the wire and loosens it
as you turn backwards.

With soldered connections, there is a point where the wire
exits the solder blob where it is going to flex the most, and where it
is most likely to fail in the presence of vibration.

BTW -- for most things, unless you have set unusual things into
the EEPROM settings, such as a special boot device, you can simply use
the command "set-defaults" at the "ok" prompt. This does nothing to
restore the HOSTID and the MAC address, unfortunately. :-)

Shame it doesn't fix the HOSTID and MAC address. Would be a useful feature!


It *can't*. The other settings are constant from system to
system as default values, so they are just compiled into the
set-defaults program, but HOSTID and the MAC address *must* be unique
for each system -- so they come in the NVRAM -- and are identified by
the barcode label on the NVRAM chip. If you have licensed software, you
buy a new NVRAM clock chip from Sun, after feeding them the barcode, and
they make a replacement with the same codes.

But if you enter a HOSTID and MAC address which are incorrect for the
particular machine, but start with the right characters (I forget how
many) that'll work, won't it?

It will work for the *system* -- as long as there is no conflict
with another system to which it talks. (Put two machines on the same
subnet with the same Mac address -- or allow them to connect through
however many routers with the same Mac address, and things go crazy.
The Mac address is *supposed* to be unique for each system.

And -- if you have any licensed software (such as the older Sun
compiler I have on a Solaris 2.6 system), if the HOSTID or the Mac
address are even slightly different, it will not work. This is why I
needed to move the NVRAM chip from a just died SS-5 to the replacement
one to keep that compiler working.

I lucked into the CD-ROM and license certificate many years ago,
from someone else who got it from a surplus sale with a bunch of other
Sun stuff -- and I was able to call in to their license center with the
HOSTID and Mac address and get a license key which has worked for many
years. Of course, if someone else wanted to use it at the same time, it
would refuse -- it was a key for a single seat on a single system.

Solbourne (made SPARC clone systems) used a coin cell on the
system board in a clip-in holder, and a NVRAM for all the optional
configuration things -- but HOSTID and the MAC address were in a small
bipolar PROM chip. If you had licensed software, and you had to replace
the system board (as I did once at work) you had to transfer that
bipolar PROM to a socket in the new board. The clock chip and the NVRAM
did not have to be transferred.

Neat idea. Sun should have put the HOSTID and MAC address on an PROM
too.

Agreed.

Are they on a PROM in the "Blade" machines?

No -- they are on a SEEPROM (Serial Electrically Eraseable PROM)
which does not need power to keep it updated. The coin cell on the
system board only keeps the clock chip running, not the NVRAM
information retained.

The only SPARC clones I remember here in England were sold under the
name "Lion". I have one of their CD-Rom drives, which has a sturdy metal
case, as opposed to the awful Sun plastic case which you had to stick
nails into the side of to release the latches.

Aside from the Solbourne ones (rather nice ones, and they were
running multi-CPU systems from SunOs 4.1.2 through 4.1.4 (modified anc
called 4.1A through 4.1C"). This was while Sun was claiming that the
move from the BSD based SunOs 4.1.? to Solaris 2.? (SysV-based) was
because it was necessary to run multi-CPU systems), I also have an Opus
(SS-1+ clone). Of the two, I prefer the design and construction of the
Solbournes.

[ ... ]

Opera is typically much faster to start than NetScape, has the
ability to disable JavaScript, Java, and plugins (including FLASH) and
then re-enabling them on a site-by-site basis as needed.

There are multiple "skins" available for Opera, which change the
look and feel of it.

I remember there being three or four skins at the time I tried Opera,
and I didn't really like any of them. It was also somewhat unstable.

It is *very* stable these days. It is also totally free
(instead of a conditional download back then). I don't know how many
skins are available for it, since I stick with the one which it comes
with.

And I see fewer notices of security holes in it (via CERT) than
for Netscape or Firefox -- and *far* fewer for them than for Internet
Explorer. :-)

The only problem with Opera these days is if you get the BZip2
compressed tar files of the static install, (instead of the "package"
install), the install script hits a couple of problems. One is that it
tries to use a "-q" option in grep (which only works in
/usr/xpg4/bin/grep) in one place, and it has one thing (the program's
icon) in the wrong place, so the copy operation in the script fails.

I presume that it works fine for the "pkg" format, and maybe for
the shared lib version as well. I tend to prefer the static, so I don't
need to worry whether I have the right shared libs installed.

Note that in Solaris 10 (and I believe Solaris 9 as well), you
*can't* compile anything with *fully* shared libs, because
/usr/lib/libc.a does not exist -- only the shared lib version thereof.

[ ... ]

I have never been sure how backward compatible Solaris is supposed to
be. I'm sure that on one occasion in the past I got a program intended
for Solaris 7 or 8 to run under Solaris 9.


I've run programs which I compiled under SunOs 4.1.4 in Solaris
2.6, and I believe that it is still possible in Solaris 10. Solaris 10
can run 32-bit or 64-bit mode as needed, and most programs compiled
under the earlier systems run using compatibility shared libs. Come
things (such as top) which dig deeply into the kernel, *can't* do this,
but most application programs have no problems.

I ran jove (my favorite editor) for years using an old version
compiled under SunOs 4.1.2 or SunOs 4.1.4. I recently re-compiled it to
run in 64-bit mode under Solaris 10 using the "Studio 12" compilers from
Sun. (Jove tended to have troubles compiling under gcc, which is why I
ran the older version for so long. But now Solaris 10 includes the
ability to separately download the development system (Studio 12 and
"NetBeans" -- the java-based integrated development environment.

So it's a case of often, but not always.

It is a case of "almost always". The programs which dig into
the kernel (ps, and top as examples) are typically not that common, and
are normally supplied pre-compiled with the system. "Top" is the
semi-exception, as it started as open source and as a result it comes
with Software Companion, not with the OS distribution itself.

To get Solaris 10, you download one really large file, or four
smaller ones which get merged into an ISO image for the Solaris 10 DVD,
and one more for the .iso of the Software_Companion CD-ROM.

Note that if you want to boot from the DVD in your older system
(Ultra-2 or was it Ultra-30), you may need to patch the firmware in the
DVD. If you have "cdrecord" installed, try:

cdrecord -scanbus

and your DVD-ROM should look like:

'TOSHIBA ' 'DVD-ROM SD-M1401' '1009' Removable CD-ROM

If the "1009" is some other figure, you need to patch, and go to the Sun
site for "111649-04.jar", which expands to a directory of tools,
instructions, and the patch called "/111649-04/".

You *may* also need to patch the system firmware to allow
booting from DVD-ROM. The Ultra-2 firmware patch is:

104169-08.tar.Z

and the one for the Ultra-60 is:

106455-11.tar.Z

I don't know the number for the Ultra-30. It may be downloadable as
well, or it may be that the Ultra-60 firmware patch will work on it as
well.

Enjoy,
DoN.

--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

Hi Don,

I can't find "top" on my Solaris 9 system. In which directory is it
normally located? It isn't a command that was introduced with Solaris
10, is it? I guess it's possible that its directory isn't in my PATH.


It is an open source program, so for Solaris 10 it is in

/opt/sfw/bin/top

I suspect that it is in the same directory for Solaris 9 -- *if* you
have installed the Software_Companion CD. Otherwise, you can download
the source and compile it yourself. This is one program which *has* to
be compiled on the OS version on which you need to use it, because it
has to dig deep into the kernel to get the information which it
displays. I've compiled it on a lot of systems over the years, each
automatically customized to the system under which I was compiling it,
including the ability to display the load on each of multiple processors
at need.

I've only got the GIMP installed from the Software Companion CD. Nothing
else. I'm thinking I'm going to re-install Solaris shortly - certain
pieces of software got corrupted, I think the result of a shared
libraries problem of some sort, and re-installing seems the simplest way
to fix everything - so I can add "top" from the Companion CD then.


Some of the programs (and I would have thought that "the GIMP" was
one need a lot of shared libs, some of which are in "/opt/sfw/lib".

Yes, that is the version of GIMP that I have installed. I think it's
version 1.2. I found it more stable and faster than every copy of
version 2 that I could find. But sadly it won't write PNG or GIF files.
Yet I'm sure that there was a version of GIMP 1.2 that could write those
files.

FWIW -- in Solaris 10, "the GIMP" is in /usr/sfw/bin instead,
which means that it is part of the standard install, not a part of the
Software_Companion CD.

And yes -- it *does* use a gazillion shared libs:


================================================== ====================
libgimpwidgets-2.0.so.0 = /usr/sfw/lib/libgimpwidgets-2.0.so.0

snip

/platform/SUNW,Sun-Blade-1000/lib/libmd_psr.so.1
================================================== ====================

and those which are in /usr/sfw/lib here would have been in /opt/sfw/lib
in Solaris 9, since it idd not have /usr/sfw/lib at all.


I often get the feeling that shared libraries aren't such a great idea.


They are normally a *good* idea -- in that they make programs
more portable between systems.

The biggest problem I've had is when you try to install a new piece of
software months after installing everything else. The new piece of
software requiries the latest shared libraries, so you have to update
everything. At least that's the way it works with the
http://www.blastwave.org/ packages.

The one place where I would like to get rid of shared libs and
go for fully static programs are shells and security tools which you
don't want to risk being compromised by a modified shared lib which does
more than the function call is expected to do.

Now -- I would suggest that if you are re-installing, you should
actually install Solaris 10 instead of Solaris 9. If you do, ask me how
to turn off programs which you may not want to run, such as the
"R-commands" and ftpd and the like.

It is quite different from earlier versions.

I would, except that I use the GNOME desktop environment, and the
version of GNOME shipped with Solaris 10 is aesthetically disgusting and
quite unstable :-).

If you have four CPUs , you will see all four on there, if the
system is busy enough. Normally most processes are using little enough
of the system so they fall off the bottom of the list. I had to start
a:

find / -name junque -print

to get two up high on the list at the same time. :-)

I'll try this when I get "top" installed.


O.K.

[ ... ]


Nope -- you need to power the chips *full* *time* to preserve
the battery life -- and they will eventually die just from shelf life
anyway. :-)

I just looked at the data sheet again. I thought at first that the
battery was rechargeable, which would seem sensible, but it seems that
it is not. Thanks for pointing this out!


Nope -- it is a coin cell -- and those are typically not
rechargeable.

Surely you can get a bunch of different kinds of rechargeable coin cell,
such as lithium-ion, NiCad and NiMH cells? I guess they aren't as common
as alkaline, lithium and silver-oxide cells, but they do exist.


The rechargeable ones typically have the wrong voltage. The ones
used are 3V cells, which are just right to keep the clock going and the
CMOS RAM loaded -- even after the voltage drop through a diode which
prevents the current from flowing back to the outside from the battery,
trying to power the whole computer while the line is off. :-)

Also -- the rechargeable ones tend to develop memory problems
requiring replacement, while the life of the selected coin cells is
typically around five years running just the clock chip, and keeping the
memory loaded.


I thought ST would have been smart enough to use one of these
rechargeable types in the NVRAM chip, but it seems not.


Physical size, what to do with the hydrogen from charging the
cell while it is potted in epoxy, wrong voltage, and not available when
the chip was first designed and made.

You get hydrogen from those little button cells? I'm surprised.

Incidentally, what exactly does the phrase "wire wrap" mean? I think
I've followed your meaning, but I've not come across that phrase before.


It works quite well, and it is easy to revise the design at
need.

I seem to recall seeing circuits built like this under test in
laboratories before. Actually, I think I've seen one which had solder
over the wrapped wire.


Arrggghhhh! The phone company started wire-wrap -- using larger
pins and heavier gauge wires. They consider a wire-wrapped connection
to be "permanent", and a soldered connection to be "temporary", so
putting solder over a wire-wrapped connection is bad news. :-)

Strange. Intuitively I would have thought of the wire-wrapped connection
as being more temporary, but I haven't tried to dismantle one.


The reason it is so reliable is that it has forty gas-tight
connections -- four for each wrap of the ten total. The sharp edges of
the square post bite into the wire, and the tension of the wire during
wrapping keeps them from coming unhooked.

There is a special tool for undoing the connections -- sort of a
backwards hollow auger which catches the end of the wire and loosens it
as you turn backwards.

With soldered connections, there is a point where the wire
exits the solder blob where it is going to flex the most, and where it
is most likely to fail in the presence of vibration.

That makes sense, but surely you've got to have some pretty serious
vibration to fatigue the wires, haven't you?

BTW -- for most things, unless you have set unusual things into
the EEPROM settings, such as a special boot device, you can simply use
the command "set-defaults" at the "ok" prompt. This does nothing to
restore the HOSTID and the MAC address, unfortunately. :-)

Shame it doesn't fix the HOSTID and MAC address. Would be a useful feature!


It *can't*. The other settings are constant from system to
system as default values, so they are just compiled into the
set-defaults program, but HOSTID and the MAC address *must* be unique
for each system -- so they come in the NVRAM -- and are identified by
the barcode label on the NVRAM chip. If you have licensed software, you
buy a new NVRAM clock chip from Sun, after feeding them the barcode, and
they make a replacement with the same codes.

But if you enter a HOSTID and MAC address which are incorrect for the
particular machine, but start with the right characters (I forget how
many) that'll work, won't it?


It will work for the *system* -- as long as there is no conflict
with another system to which it talks. (Put two machines on the same
subnet with the same Mac address -- or allow them to connect through
however many routers with the same Mac address, and things go crazy.
The Mac address is *supposed* to be unique for each system.

Got it.

And -- if you have any licensed software (such as the older Sun
compiler I have on a Solaris 2.6 system), if the HOSTID or the Mac
address are even slightly different, it will not work. This is why I
needed to move the NVRAM chip from a just died SS-5 to the replacement
one to keep that compiler working.

I lucked into the CD-ROM and license certificate many years ago,
from someone else who got it from a surplus sale with a bunch of other
Sun stuff -- and I was able to call in to their license center with the
HOSTID and Mac address and get a license key which has worked for many
years. Of course, if someone else wanted to use it at the same time, it
would refuse -- it was a key for a single seat on a single system.


Solbourne (made SPARC clone systems) used a coin cell on the
system board in a clip-in holder, and a NVRAM for all the optional
configuration things -- but HOSTID and the MAC address were in a small
bipolar PROM chip. If you had licensed software, and you had to replace
the system board (as I did once at work) you had to transfer that
bipolar PROM to a socket in the new board. The clock chip and the NVRAM
did not have to be transferred.

Neat idea. Sun should have put the HOSTID and MAC address on an PROM
too.


Agreed.


Are they on a PROM in the "Blade" machines?


No -- they are on a SEEPROM (Serial Electrically Eraseable PROM)
which does not need power to keep it updated. The coin cell on the
system board only keeps the clock chip running, not the NVRAM
information retained.

Is that similar to flash memory?

The only SPARC clones I remember here in England were sold under the
name "Lion". I have one of their CD-Rom drives, which has a sturdy metal
case, as opposed to the awful Sun plastic case which you had to stick
nails into the side of to release the latches.


Aside from the Solbourne ones (rather nice ones, and they were
running multi-CPU systems from SunOs 4.1.2 through 4.1.4 (modified anc
called 4.1A through 4.1C"). This was while Sun was claiming that the
move from the BSD based SunOs 4.1.? to Solaris 2.? (SysV-based) was
because it was necessary to run multi-CPU systems), I also have an Opus
(SS-1+ clone). Of the two, I prefer the design and construction of the
Solbournes.

[ ... ]


Opera is typically much faster to start than NetScape, has the
ability to disable JavaScript, Java, and plugins (including FLASH) and
then re-enabling them on a site-by-site basis as needed.

There are multiple "skins" available for Opera, which change the
look and feel of it.

I remember there being three or four skins at the time I tried Opera,
and I didn't really like any of them. It was also somewhat unstable.


It is *very* stable these days. It is also totally free
(instead of a conditional download back then). I don't know how many
skins are available for it, since I stick with the one which it comes
with.

Well, I last used it in 2005 or '06. I think I got an unofficial package
from a chap called Thomas Glanzmann who used to frequent
comp.unix.solaris and http://www.blastwave.org/.

And I see fewer notices of security holes in it (via CERT) than
for Netscape or Firefox -- and *far* fewer for them than for Internet
Explorer. :-)

The only problem with Opera these days is if you get the BZip2
compressed tar files of the static install, (instead of the "package"
install), the install script hits a couple of problems. One is that it
tries to use a "-q" option in grep (which only works in
/usr/xpg4/bin/grep) in one place, and it has one thing (the program's
icon) in the wrong place, so the copy operation in the script fails.

I presume that it works fine for the "pkg" format, and maybe for
the shared lib version as well. I tend to prefer the static, so I don't
need to worry whether I have the right shared libs installed.

Note that in Solaris 10 (and I believe Solaris 9 as well), you
*can't* compile anything with *fully* shared libs, because
/usr/lib/libc.a does not exist -- only the shared lib version thereof.

You're losing me here a little. You mean that libc.a links to several
other libraries, in order to make itself smaller?

I have never been sure how backward compatible Solaris is supposed to
be. I'm sure that on one occasion in the past I got a program intended
for Solaris 7 or 8 to run under Solaris 9.


I've run programs which I compiled under SunOs 4.1.4 in Solaris
2.6, and I believe that it is still possible in Solaris 10. Solaris 10
can run 32-bit or 64-bit mode as needed, and most programs compiled
under the earlier systems run using compatibility shared libs. Come
things (such as top) which dig deeply into the kernel, *can't* do this,
but most application programs have no problems.

I ran jove (my favorite editor) for years using an old version
compiled under SunOs 4.1.2 or SunOs 4.1.4. I recently re-compiled it to
run in 64-bit mode under Solaris 10 using the "Studio 12" compilers from
Sun. (Jove tended to have troubles compiling under gcc, which is why I
ran the older version for so long. But now Solaris 10 includes the
ability to separately download the development system (Studio 12 and
"NetBeans" -- the java-based integrated development environment.

So it's a case of often, but not always.


It is a case of "almost always". The programs which dig into
the kernel (ps, and top as examples) are typically not that common, and
are normally supplied pre-compiled with the system. "Top" is the
semi-exception, as it started as open source and as a result it comes
with Software Companion, not with the OS distribution itself.

To get Solaris 10, you download one really large file, or four
smaller ones which get merged into an ISO image for the Solaris 10 DVD,
and one more for the .iso of the Software_Companion CD-ROM.

Note that if you want to boot from the DVD in your older system
(Ultra-2 or was it Ultra-30), you may need to patch the firmware in the
DVD. If you have "cdrecord" installed, try:

I've never bothered to get a SCSI DVD drive for the Ultra 2. When I
looked they were rare and fairly expensive.

Many thanks,

Chris

On 2009-01-28, Christopher Tidy wrote:
Hi Don,

[ ... ]

I've only got the GIMP installed from the Software Companion CD. Nothing
else. I'm thinking I'm going to re-install Solaris shortly - certain
pieces of software got corrupted, I think the result of a shared
libraries problem of some sort, and re-installing seems the simplest way
to fix everything - so I can add "top" from the Companion CD then.


Some of the programs (and I would have thought that "the GIMP" was
one need a lot of shared libs, some of which are in "/opt/sfw/lib".

Yes, that is the version of GIMP that I have installed. I think it's
version 1.2. I found it more stable and faster than every copy of
version 2 that I could find.

The version which I am running (from an earlier Solaris 10
distribution) is 2.0.2

But sadly it won't write PNG or GIF files.
Yet I'm sure that there was a version of GIMP 1.2 that could write those
files.

2.0.2 will save both.

I would not expect earlier versions to handle saving as GIF,
because GIF uses a compression algorihtm which was patented, and there
was no provision for licensing for an open source program. The license
needed a fee paid for each copy released, and when people were free to
make their own copies from t he sources, there was no way to handle the
collection. And GNU would *not* use any software which required a
license fee. It was against their policies. However, the patent has
expired, so it now shows up.

PNG was developed as a work-around for the fact that no open
source programs could save GIF files. (Actually, early versions of 'xv'
*did* write GIF files -- until the owners of the patents started
enforcing it.

[ ... ]

I often get the feeling that shared libraries aren't such a great idea.


They are normally a *good* idea -- in that they make programs
more portable between systems.

The biggest problem I've had is when you try to install a new piece of
software months after installing everything else. The new piece of
software requiries the latest shared libraries, so you have to update
everything. At least that's the way it works with the
http://www.blastwave.org/ packages.

That is because you are downloading pre-compiled packages, which
have (of course) been compiled against the most recent packages.
Normally shared libs are backwards compatible, and you will often find
several shortened names of shared libs which are symlinks to the current
name, so the program can call for it by any of a number of version
names. The links are not created where a newer version introduces an
incompatibility with an older one.

If you were to download the source for the packages, and compile
it locally, you would (usually) be able to compile it to use the shared
libs which you already have.

The one place where I would like to get rid of shared libs and
go for fully static programs are shells and security tools which you
don't want to risk being compromised by a modified shared lib which does
more than the function call is expected to do.

Now -- I would suggest that if you are re-installing, you should
actually install Solaris 10 instead of Solaris 9. If you do, ask me how
to turn off programs which you may not want to run, such as the
"R-commands" and ftpd and the like.

It is quite different from earlier versions.

I would, except that I use the GNOME desktop environment, and the
version of GNOME shipped with Solaris 10 is aesthetically disgusting and
quite unstable :-).

So -- get the GNOME source from the earlier version which you
like, and compile it under Solaris 10 after pkg removing the current
version.

I would not know about its stability, since I don't like the
interface and thus won't run it -- in *any* version. There is a
temptation to drop back to tvwm instead -- but as long as they keep CDE
running I'll stick with it.

[ ... ]

Nope -- it is a coin cell -- and those are typically not
rechargeable.

[ ... ]

I thought ST would have been smart enough to use one of these
rechargeable types in the NVRAM chip, but it seems not.


Physical size, what to do with the hydrogen from charging the
cell while it is potted in epoxy, wrong voltage, and not available when
the chip was first designed and made.

You get hydrogen from those little button cells? I'm surprised.

From *any* rechargeable battery while it is being recharged.

[ ... ]

Arrggghhhh! The phone company started wire-wrap -- using larger
pins and heavier gauge wires. They consider a wire-wrapped connection
to be "permanent", and a soldered connection to be "temporary", so
putting solder over a wire-wrapped connection is bad news. :-)

Strange. Intuitively I would have thought of the wire-wrapped connection
as being more temporary, but I haven't tried to dismantle one.


The reason it is so reliable is that it has forty gas-tight
connections -- four for each wrap of the ten total. The sharp edges of
the square post bite into the wire, and the tension of the wire during
wrapping keeps them from coming unhooked.

There is a special tool for undoing the connections -- sort of a
backwards hollow auger which catches the end of the wire and loosens it
as you turn backwards.

With soldered connections, there is a point where the wire
exits the solder blob where it is going to flex the most, and where it
is most likely to fail in the presence of vibration.

That makes sense, but surely you've got to have some pretty serious
vibration to fatigue the wires, haven't you?

And what do you think happens in a telephone exchange, with
relays of all sizes vibrating the frames all the time.

Same for circuits in aircraft or automobiles.

[ ... ]

But if you enter a HOSTID and MAC address which are incorrect for the
particular machine, but start with the right characters (I forget how
many) that'll work, won't it?


It will work for the *system* -- as long as there is no conflict
with another system to which it talks. (Put two machines on the same
subnet with the same Mac address -- or allow them to connect through
however many routers with the same Mac address, and things go crazy.
The Mac address is *supposed* to be unique for each system.

Got it.

Not as much as you would if you *tried* it. ;-)

[ ... ]

Are they on a PROM in the "Blade" machines?


No -- they are on a SEEPROM (Serial Electrically Eraseable PROM)
which does not need power to keep it updated. The coin cell on the
system board only keeps the clock chip running, not the NVRAM
information retained.

Is that similar to flash memory?

Sort of I guess -- except that it is sequential access -- coming
out one bit at a time as it is clocked by the system. Same for writing.

[ ... ]

Opera is typically much faster to start than NetScape, has the
ability to disable JavaScript, Java, and plugins (including FLASH) and
then re-enabling them on a site-by-site basis as needed.

There are multiple "skins" available for Opera, which change the
look and feel of it.

I remember there being three or four skins at the time I tried Opera,
and I didn't really like any of them. It was also somewhat unstable.


It is *very* stable these days. It is also totally free
(instead of a conditional download back then). I don't know how many
skins are available for it, since I stick with the one which it comes
with.

Well, I last used it in 2005 or '06. I think I got an unofficial package
from a chap called Thomas Glanzmann who used to frequent
comp.unix.solaris and http://www.blastwave.org/.

O.K. I don't know him.

And I see fewer notices of security holes in it (via CERT) than
for Netscape or Firefox -- and *far* fewer for them than for Internet
Explorer. :-)

The only problem with Opera these days is if you get the BZip2
compressed tar files of the static install, (instead of the "package"
install), the install script hits a couple of problems. One is that it
tries to use a "-q" option in grep (which only works in
/usr/xpg4/bin/grep) in one place, and it has one thing (the program's
icon) in the wrong place, so the copy operation in the script fails.

I presume that it works fine for the "pkg" format, and maybe for
the shared lib version as well. I tend to prefer the static, so I don't
need to worry whether I have the right shared libs installed.

Note that in Solaris 10 (and I believe Solaris 9 as well), you
*can't* compile anything with *fully* shared libs, because
/usr/lib/libc.a does not exist -- only the shared lib version thereof.

You're losing me here a little. You mean that libc.a links to several
other libraries, in order to make itself smaller?

Actually -- I mis-stated. It is fully *static* linking which is
not possible with Solaris 10 -- because the only version of libc is a
shared lib, not a static one. (The static one would be simply "libc.a".

[ ... backwards compatibility ... ]

So it's a case of often, but not always.


It is a case of "almost always". The programs which dig into
the kernel (ps, and top as examples) are typically not that common, and
are normally supplied pre-compiled with the system. "Top" is the
semi-exception, as it started as open source and as a result it comes
with Software Companion, not with the OS distribution itself.

To get Solaris 10, you download one really large file, or four
smaller ones which get merged into an ISO image for the Solaris 10 DVD,
and one more for the .iso of the Software_Companion CD-ROM.

Note that if you want to boot from the DVD in your older system
(Ultra-2 or was it Ultra-30), you may need to patch the firmware in the
DVD. If you have "cdrecord" installed, try:

I've never bothered to get a SCSI DVD drive for the Ultra 2. When I
looked they were rare and fairly expensive.

Hmm ... "rare and expensive". Try an ebay search for:

Toshiba DVD-ROM SCSI M1401

1) $14.99

2) $49.00 (In a Sun UniPack external chassis)

3) $9.99

4) $25.00

5) $49.99 (five drives not just one)

6) $39.99

I would think that some of those would be cheap enough to use
for the task. It saves a *lot* of CD swapping, and of waiting around
for the right time to swap when loading Solaris 10 (5 CD-ROMs or one
DVD-ROM. :-)

I even put a spare into an ancient SGI Indigo 2, and it works
fine with CDs and DVDs.

Enjoy,
DoN.

--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

Hi Don,

Yes, that is the version of GIMP that I have installed. I think it's
version 1.2. I found it more stable and faster than every copy of
version 2 that I could find.


The version which I am running (from an earlier Solaris 10
distribution) is 2.0.2

I think 1.2 was the last version which Sun distributed with Solaris 9,
unless it has been updated in the last year or so, and I don't think it has.

But sadly it won't write PNG or GIF files.
Yet I'm sure that there was a version of GIMP 1.2 that could write those
files.


2.0.2 will save both.

As would one version of GIMP 1.2, or possibly 1.x, which I had from
http://www.blastwave.org/ in 2004. And it was stable. But I can only use
it now if I use all the software dating from 2004.

I wish I could find a version of GIMP 1.2 which would save GIF and PNG
and was not dependent on shared libraries. Even if I can find a stable
version of GIMP 2, it was seriously slow when I tried it. Any idea where
I might find a later version of GIMP 1.2?

I would not expect earlier versions to handle saving as GIF,
because GIF uses a compression algorihtm which was patented, and there
was no provision for licensing for an open source program. The license
needed a fee paid for each copy released, and when people were free to
make their own copies from t he sources, there was no way to handle the
collection. And GNU would *not* use any software which required a
license fee. It was against their policies. However, the patent has
expired, so it now shows up.

PNG was developed as a work-around for the fact that no open
source programs could save GIF files. (Actually, early versions of 'xv'
*did* write GIF files -- until the owners of the patents started
enforcing it.

Was it Compuserve's patent? I'm trying to remember. I seem to remember
that at one time there was an anti-GIF movement and banners which said
"This is a GIF-free site", etc. But I haven't seen one in a long time.
Both standards seem to be in common use.

I often get the feeling that shared libraries aren't such a great idea.


They are normally a *good* idea -- in that they make programs
more portable between systems.

The biggest problem I've had is when you try to install a new piece of
software months after installing everything else. The new piece of
software requiries the latest shared libraries, so you have to update
everything. At least that's the way it works with the
http://www.blastwave.org/ packages.


That is because you are downloading pre-compiled packages, which
have (of course) been compiled against the most recent packages.
Normally shared libs are backwards compatible, and you will often find
several shortened names of shared libs which are symlinks to the current
name, so the program can call for it by any of a number of version
names. The links are not created where a newer version introduces an
incompatibility with an older one.

If you were to download the source for the packages, and compile
it locally, you would (usually) be able to compile it to use the shared
libs which you already have.


The one place where I would like to get rid of shared libs and
go for fully static programs are shells and security tools which you
don't want to risk being compromised by a modified shared lib which does
more than the function call is expected to do.

Now -- I would suggest that if you are re-installing, you should
actually install Solaris 10 instead of Solaris 9. If you do, ask me how
to turn off programs which you may not want to run, such as the
"R-commands" and ftpd and the like.

It is quite different from earlier versions.

I would, except that I use the GNOME desktop environment, and the
version of GNOME shipped with Solaris 10 is aesthetically disgusting and
quite unstable :-).


So -- get the GNOME source from the earlier version which you
like, and compile it under Solaris 10 after pkg removing the current
version.

I would, but right now I feel there are more urgent things I should do.
I can live with Solaris 9 a bit longer.

I would not know about its stability, since I don't like the
interface and thus won't run it -- in *any* version. There is a
temptation to drop back to tvwm instead -- but as long as they keep CDE
running I'll stick with it.

[ ... ]


Nope -- it is a coin cell -- and those are typically not
rechargeable.


[ ... ]


I thought ST would have been smart enough to use one of these
rechargeable types in the NVRAM chip, but it seems not.


Physical size, what to do with the hydrogen from charging the
cell while it is potted in epoxy, wrong voltage, and not available when
the chip was first designed and made.

You get hydrogen from those little button cells? I'm surprised.


From *any* rechargeable battery while it is being recharged.

Does it come from water in the battery? If so, does it eventually cause
the battery to dry out?

Arrggghhhh! The phone company started wire-wrap -- using larger
pins and heavier gauge wires. They consider a wire-wrapped connection
to be "permanent", and a soldered connection to be "temporary", so
putting solder over a wire-wrapped connection is bad news. :-)

Strange. Intuitively I would have thought of the wire-wrapped connection
as being more temporary, but I haven't tried to dismantle one.


The reason it is so reliable is that it has forty gas-tight
connections -- four for each wrap of the ten total. The sharp edges of
the square post bite into the wire, and the tension of the wire during
wrapping keeps them from coming unhooked.

There is a special tool for undoing the connections -- sort of a
backwards hollow auger which catches the end of the wire and loosens it
as you turn backwards.

With soldered connections, there is a point where the wire
exits the solder blob where it is going to flex the most, and where it
is most likely to fail in the presence of vibration.

That makes sense, but surely you've got to have some pretty serious
vibration to fatigue the wires, haven't you?


And what do you think happens in a telephone exchange, with
relays of all sizes vibrating the frames all the time.

I don't know. I've never been in a telephone exchange. But many of the
relays are solid state now, aren't they?

Same for circuits in aircraft or automobiles.

Presumably it's only a problem in the high vibration regions such as on
the engine itself, isn't it? Cars still have a fair number of soldered
joints, particularly on printed circuit boards.

But if you enter a HOSTID and MAC address which are incorrect for the
particular machine, but start with the right characters (I forget how
many) that'll work, won't it?


It will work for the *system* -- as long as there is no conflict
with another system to which it talks. (Put two machines on the same
subnet with the same Mac address -- or allow them to connect through
however many routers with the same Mac address, and things go crazy.
The Mac address is *supposed* to be unique for each system.

Got it.


Not as much as you would if you *tried* it. ;-)

I hope I won't have to anytime soon. I hope this machine will last me a
while.

snip

You're losing me here a little. You mean that libc.a links to several
other libraries, in order to make itself smaller?


Actually -- I mis-stated. It is fully *static* linking which is
not possible with Solaris 10 -- because the only version of libc is a
shared lib, not a static one. (The static one would be simply "libc.a".

[ ... backwards compatibility ... ]

snip

Hmm ... "rare and expensive". Try an ebay search for:

Toshiba DVD-ROM SCSI M1401

1) $14.99

2) $49.00 (In a Sun UniPack external chassis)

3) $9.99

4) $25.00

5) $49.99 (five drives not just one)

6) $39.99

Sorry, I made a mistake. At the time I was searching for a SCSI DVD
writer, as I wanted to have just a single drive in the machine. At the
time, those were rare and expensive.

I would think that some of those would be cheap enough to use
for the task. It saves a *lot* of CD swapping, and of waiting around
for the right time to swap when loading Solaris 10 (5 CD-ROMs or one
DVD-ROM. :-)

I even put a spare into an ancient SGI Indigo 2, and it works
fine with CDs and DVDs.

What do you think of the Indigo 2? I love the colour. It looks
remarkable, especially the genuine indigo-coloured R10000 machine. I
almost bought one in 2003, but then I got a Sun Ultra 2 for nothing instead.

Best wishes,

Chris

On 2009-01-29, Christopher Tidy wrote:
Hi Don,

Yes, that is the version of GIMP that I have installed. I think it's
version 1.2. I found it more stable and faster than every copy of
version 2 that I could find.

As far as the speed is concerned, I find 2.0.2 is quite fast
enough -- at least on a Sun Blade 2000 with dual 1.2 GHz CPUs. And the
thing which makes the biggest difference in speed for *any* serious
image processor is the amount of RAM present. Running the Ultra-2 with
a full 2 GB of RAM made a significant difference. Running my SB-2K with
6 GB of RAM (instead of the 3 GB which I was running before) makes a big
difference in the speed of gimp 2.0.2.

BTW -- "the GIMP" is now up to version 2.6.?, though I am
running 2.0.2.


The version which I am running (from an earlier Solaris 10
distribution) is 2.0.2

I think 1.2 was the last version which Sun distributed with Solaris 9,
unless it has been updated in the last year or so, and I don't think it has.

I believe that it was included in the Software_Companion in
earlier versions of Solaris 10 as well (installing in /opt/sfw), while
gimp 2.?.? came standard in /usr/sfw.

But sadly it won't write PNG or GIF files.
Yet I'm sure that there was a version of GIMP 1.2 that could write those
files.


2.0.2 will save both.

As would one version of GIMP 1.2, or possibly 1.x, which I had from
http://www.blastwave.org/ in 2004. And it was stable. But I can only use
it now if I use all the software dating from 2004.

Wrong! Install once and run "ldd `which gimp`" on it.

Note where it finds each shared lib. Here is what my gimp on
the SB-2K shows up:


================================================== ====================
Katana:dnichols 21:33:28 ldd `which gimp`
libgimpwidgets-2.0.so.0 = /usr/sfw/lib/libgimpwidgets-2.0.so.0
libgimpcolor-2.0.so.0 = /usr/sfw/lib/libgimpcolor-2.0.so.0
libgimpmodule-2.0.so.0 = /usr/sfw/lib/libgimpmodule-2.0.so.0
libgimpbase-2.0.so.0 = /usr/sfw/lib/libgimpbase-2.0.so.0
libgimpthumb-2.0.so.0 = /usr/sfw/lib/libgimpthumb-2.0.so.0
libgimpmath-2.0.so.0 = /usr/sfw/lib/libgimpmath-2.0.so.0
libgtk-x11-2.0.so.0 = /usr/lib/libgtk-x11-2.0.so.0
libgdk-x11-2.0.so.0 = /usr/lib/libgdk-x11-2.0.so.0
libatk-1.0.so.0 = /usr/lib/libatk-1.0.so.0
libgdk_pixbuf-2.0.so.0 = /usr/lib/libgdk_pixbuf-2.0.so.0
libm.so.2 = /usr/lib/libm.so.2
libmlib.so.2 = /usr/lib/libmlib.so.2
libpangoxft-1.0.so.0 = /usr/lib/libpangoxft-1.0.so.0
libpangox-1.0.so.0 = /usr/lib/libpangox-1.0.so.0
libart_lgpl_2.so.2 = /usr/lib/libart_lgpl_2.so.2
libpangoft2-1.0.so.0 = /usr/lib/libpangoft2-1.0.so.0
libpango-1.0.so.0 = /usr/lib/libpango-1.0.so.0
libgobject-2.0.so.0 = /usr/lib/libgobject-2.0.so.0
libgmodule-2.0.so.0 = /usr/lib/libgmodule-2.0.so.0
libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0
libfontconfig.so.1 = /usr/lib/libfontconfig.so.1
libfreetype.so.6 = /usr/local/lib/libfreetype.so.6
libpthread.so.1 = /usr/lib/libpthread.so.1
libc.so.1 = /usr/lib/libc.so.1
libsocket.so.1 = /usr/lib/libsocket.so.1
libnsl.so.1 = /usr/lib/libnsl.so.1
libXft.so.2 = /usr/openwin/lib/libXft.so.2
libXrender.so.1 = /usr/sfw/lib/libXrender.so.1
libX11.so.4 = /usr/openwin/lib/libX11.so.4
libXrandr.so.2 = /usr/lib/libXrandr.so.2
libXi.so.5 = /usr/openwin/lib/libXi.so.5
libXext.so.0 = /usr/openwin/lib/libXext.so.0
libz.so.1 = /usr/lib/libz.so.1
libexpat.so.0 = /usr/sfw/lib/libexpat.so.0
libgcc_s.so.1 = /opt/gcc/lib/libgcc_s.so.1
libmp.so.2 = /usr/lib/libmp.so.2
libmd.so.1 = /usr/lib/libmd.so.1
libscf.so.1 = /usr/lib/libscf.so.1
libdl.so.1 = /usr/lib/libdl.so.1
libdoor.so.1 = /usr/lib/libdoor.so.1
libuutil.so.1 = /usr/lib/libuutil.so.1
libgen.so.1 = /usr/lib/libgen.so.1
/usr/lib/cpu/sparcv9+vis2/libmlib.so.2
/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1
/platform/SUNW,Sun-Blade-1000/lib/libmd_psr.so.1
================================================== ====================

Next -- copy each of those shared libs into a directory and burn
a CD-ROM of it. Many of the shared libs are in /usr/lib, or perhaps
/usr/openwin/lib. Others in /usr/sfw/lib.

Next, copy the program to your newer system (e.g. my Solaris
10), put all of these libraries in (except probably the
/platform/SUNW.... ones), set up a wrapper script which sets
LD_LIBRARY_PATH to look at the directory of shared libs you just built,
and try running that version of gimp. (Or even just run ldd on that
gimp and look for "not found" reports.)

Try removing (moving into a subdirectory) one shared lib at a
time. starting with the /usr/lib ones, and see if ldd gimp still finds
all the shared libs without complaint. Usually the newer shared libs
which come with the system will work fine. It is just that BlastWave's
installer doesn't know this, and insists on installing up-to-date libs
for everything, whether they are needed or not.

I'll bet that at the end, you will find only a very few shared
libs which need to be added. Keep them in the directory, and keep
invoking gimp via the wrapper. If you discover that *all* of the shared
libs can be removed form that directory, you will have proven that it
will work without needing to add anything to the system.

I wish I could find a version of GIMP 1.2 which would save GIF and PNG
and was not dependent on shared libraries.

Compile your own! It will require a bit of tweaking of the
configure script and the produced Makefile, (and probably re-compiling
of some of the other things to provide a static library to link when you
compile gimp).

Remember that the primary form of "the GIMP" is freely
distributable source code, not pre-compiled binaries. :-)

Even if I can find a stable
version of GIMP 2, it was seriously slow when I tried it. Any idea where
I might find a later version of GIMP 1.2?

Here is the latest version (1.2.5) at this URL (and others):

http://mirror.umoss.org/gimp/gimp/v1.2/v1.2.5/


================================================== ====================
Name Last Modified Size Type
Parent Directory/ - Directory
README 2003-Jun-14 14:17:30 0.4K application/octet-stream
gimp-1.2.5.tar.bz2 2003-Jun-14 14:21:30 10.3M application/x-bzip
gimp-data-extras-1.2.0.tar.bz2 2000-Dec-24 19:16:30 4.2M application/x-bzip
gimp-data-extras-1.2.0.tar.gz 2000-Dec-24 19:14:30 4.5M application/x-gzip
patch-1.2.4-1.2.5.bz2 2003-Jun-14 14:35:30 153.3K application/x-bzip
================================================== ====================

But again, this is in source code form, and you have the great fun of
compiling it (and all the needed libraries which you don't have). And,
you'll probably need a lot of them, if you insist in sticking with
Solaris 9. :-)

[ ... ]

PNG was developed as a work-around for the fact that no open
source programs could save GIF files. (Actually, early versions of 'xv'
*did* write GIF files -- until the owners of the patents started
enforcing it.

Was it Compuserve's patent?

I believe so.

I'm trying to remember. I seem to remember
that at one time there was an anti-GIF movement and banners which said
"This is a GIF-free site", etc. But I haven't seen one in a long time.
Both standards seem to be in common use.

Now that the patent has expired.

[ ... ]

The biggest problem I've had is when you try to install a new piece of
software months after installing everything else. The new piece of
software requiries the latest shared libraries, so you have to update
everything. At least that's the way it works with the
http://www.blastwave.org/ packages.


That is because you are downloading pre-compiled packages, which
have (of course) been compiled against the most recent packages.
Normally shared libs are backwards compatible, and you will often find
several shortened names of shared libs which are symlinks to the current
name, so the program can call for it by any of a number of version
names. The links are not created where a newer version introduces an
incompatibility with an older one.

If you were to download the source for the packages, and compile
it locally, you would (usually) be able to compile it to use the shared
libs which you already have.

Except for ones which you might need to download.

[ ... ]

So -- get the GNOME source from the earlier version which you
like, and compile it under Solaris 10 after pkg removing the current
version.

I would, but right now I feel there are more urgent things I should do.
I can live with Solaris 9 a bit longer.

:-)

[ ... ]

I thought ST would have been smart enough to use one of these
rechargeable types in the NVRAM chip, but it seems not.


Physical size, what to do with the hydrogen from charging the
cell while it is potted in epoxy, wrong voltage, and not available when
the chip was first designed and made.

You get hydrogen from those little button cells? I'm surprised.


From *any* rechargeable battery while it is being recharged.

Does it come from water in the battery? If so, does it eventually cause
the battery to dry out?

It comes from the chemical reactions in the battery. Any acid,
combining with any base, should release hydrogen in the process -- *or*
produce water.

[ ... ]

With soldered connections, there is a point where the wire
exits the solder blob where it is going to flex the most, and where it
is most likely to fail in the presence of vibration.

That makes sense, but surely you've got to have some pretty serious
vibration to fatigue the wires, haven't you?


And what do you think happens in a telephone exchange, with
relays of all sizes vibrating the frames all the time.

I don't know. I've never been in a telephone exchange. But many of the
relays are solid state now, aren't they?

Probably so -- but you would have been amazed at the noise in a
dial telephone exchange in the early 1960s.

Same for circuits in aircraft or automobiles.

Presumably it's only a problem in the high vibration regions such as on
the engine itself, isn't it? Cars still have a fair number of soldered
joints, particularly on printed circuit boards.

Solder joints for mounting components to PC boards are fine --
though there is usually something done to keep the component from
vibrating.

However -- wires from the car's wiring harness to the boards are
almost always connected via crimp-on connectors, or crimp terminated
ring terminals mounted to screws on barrier strips and the like. A
*good* crimp-on terminal will have not only a crimp on the exposed wire,
but a support crimp on the insulation of the wire to control vibration
and keep it from flexing the wire between the insulation and the
terminal.

[ ... ]

[ ... backwards compatibility ... ]

snip

Hmm ... "rare and expensive". Try an ebay search for:

Toshiba DVD-ROM SCSI M1401

1) $14.99

2) $49.00 (In a Sun UniPack external chassis)

3) $9.99

4) $25.00

5) $49.99 (five drives not just one)

6) $39.99

Sorry, I made a mistake. At the time I was searching for a SCSI DVD
writer, as I wanted to have just a single drive in the machine. At the
time, those were rare and expensive.

O.K. For that, you want an ACArd bridge card to convert IDE to
50-pin SCSI. With that, you can mount an IDE DVD burner in the system
in place of the original SCSI drive. I have such a drive in my Sun
Blade 2000, and another one in a FlexiPack (like a UniPack, except that
it holds two drives). That one is connected via an ACard bridge card
which adapts to 68-pin SCSI instead of 50-pin. This particular ACard
can be a pain in the system, but outside with a 68-pin interface, it
works nicely.

The only problem is that while the IDE DVD-burners are quite
inexpensive, the ACard is something like $59.00 or so. :-)

I would think that some of those would be cheap enough to use
for the task. It saves a *lot* of CD swapping, and of waiting around
for the right time to swap when loading Solaris 10 (5 CD-ROMs or one
DVD-ROM. :-)

I even put a spare into an ancient SGI Indigo 2, and it works
fine with CDs and DVDs.

What do you think of the Indigo 2?

Slow once I'm using a Sun Blade 2000 with dual 1.2 GHz CPU
modules. :-) This particular Indigo 2 is the Teal colored one, and
happens to have an unusual CPU -- the R8000 -- only 75 MHz, but it can
do floating-point math as fast as integer math.

I've been disappointed trying to get it to work with a (SCSI) HP
ScanJet 5p, because the driver supplied with the 6.2 version of the OS
stops at the ScanJet III. However, I managed to get sane working in the
SB-2K (a couple of tricky things but I have the latest version running,
and just used it to scan all of the text section of a Bridgeport BOSS-3
and BOSS-4 manual. Unfortunately, the schematics are fold-outs, and
will either have to be scanned in multiple parts and then pasted back
together later, or I'll have to find a scanner which will handle 11x17"
pages. :-)

I love the colour. It looks
remarkable, especially the genuine indigo-coloured R10000 machine.

Pretty much all of their machines are colorful. But then recent
Sun machines have been getting more colorful. Look at the SB-2K for
example. (Of course, you will see two apparent colors in eBay auction
photos -- the duller ones were photographed by incandescent or
fluorescent lights, while the more garish ones were photographed by
electronic flash. :-)

I
almost bought one in 2003, but then I got a Sun Ultra 2 for nothing instead.

This one was free, too.

But I now need to get one of the original DAT drives for what I
wish to use it for -- transferring audio DATs to computer files, which
can then be burned into audio CDs.

Enjoy,
DoN.

--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

Hi Don,

Yes, that is the version of GIMP that I have installed. I think it's
version 1.2. I found it more stable and faster than every copy of
version 2 that I could find.


As far as the speed is concerned, I find 2.0.2 is quite fast
enough -- at least on a Sun Blade 2000 with dual 1.2 GHz CPUs. And the
thing which makes the biggest difference in speed for *any* serious
image processor is the amount of RAM present. Running the Ultra-2 with
a full 2 GB of RAM made a significant difference. Running my SB-2K with
6 GB of RAM (instead of the 3 GB which I was running before) makes a big
difference in the speed of gimp 2.0.2.

It wasn't the speed once it was up and running, it was the start-up
time. On the same machine, GIMP 1.2 was quick, whereas GIMP 2 seemed to
take forever!

BTW -- "the GIMP" is now up to version 2.6.?, though I am
running 2.0.2.


The version which I am running (from an earlier Solaris 10
distribution) is 2.0.2

I think 1.2 was the last version which Sun distributed with Solaris 9,
unless it has been updated in the last year or so, and I don't think it has.


I believe that it was included in the Software_Companion in
earlier versions of Solaris 10 as well (installing in /opt/sfw), while
gimp 2.?.? came standard in /usr/sfw.


But sadly it won't write PNG or GIF files.
Yet I'm sure that there was a version of GIMP 1.2 that could write those
files.


2.0.2 will save both.

As would one version of GIMP 1.2, or possibly 1.x, which I had from
http://www.blastwave.org/ in 2004. And it was stable. But I can only use
it now if I use all the software dating from 2004.


Wrong! Install once and run "ldd `which gimp`" on it.

Note where it finds each shared lib. Here is what my gimp on
the SB-2K shows up:


================================================== ====================
Katana:dnichols 21:33:28 ldd `which gimp`
libgimpwidgets-2.0.so.0 = /usr/sfw/lib/libgimpwidgets-2.0.so.0
libgimpcolor-2.0.so.0 = /usr/sfw/lib/libgimpcolor-2.0.so.0
libgimpmodule-2.0.so.0 = /usr/sfw/lib/libgimpmodule-2.0.so.0
libgimpbase-2.0.so.0 = /usr/sfw/lib/libgimpbase-2.0.so.0
libgimpthumb-2.0.so.0 = /usr/sfw/lib/libgimpthumb-2.0.so.0
libgimpmath-2.0.so.0 = /usr/sfw/lib/libgimpmath-2.0.so.0
libgtk-x11-2.0.so.0 = /usr/lib/libgtk-x11-2.0.so.0
libgdk-x11-2.0.so.0 = /usr/lib/libgdk-x11-2.0.so.0
libatk-1.0.so.0 = /usr/lib/libatk-1.0.so.0
libgdk_pixbuf-2.0.so.0 = /usr/lib/libgdk_pixbuf-2.0.so.0
libm.so.2 = /usr/lib/libm.so.2
libmlib.so.2 = /usr/lib/libmlib.so.2
libpangoxft-1.0.so.0 = /usr/lib/libpangoxft-1.0.so.0
libpangox-1.0.so.0 = /usr/lib/libpangox-1.0.so.0
libart_lgpl_2.so.2 = /usr/lib/libart_lgpl_2.so.2
libpangoft2-1.0.so.0 = /usr/lib/libpangoft2-1.0.so.0
libpango-1.0.so.0 = /usr/lib/libpango-1.0.so.0
libgobject-2.0.so.0 = /usr/lib/libgobject-2.0.so.0
libgmodule-2.0.so.0 = /usr/lib/libgmodule-2.0.so.0
libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0
libfontconfig.so.1 = /usr/lib/libfontconfig.so.1
libfreetype.so.6 = /usr/local/lib/libfreetype.so.6
libpthread.so.1 = /usr/lib/libpthread.so.1
libc.so.1 = /usr/lib/libc.so.1
libsocket.so.1 = /usr/lib/libsocket.so.1
libnsl.so.1 = /usr/lib/libnsl.so.1
libXft.so.2 = /usr/openwin/lib/libXft.so.2
libXrender.so.1 = /usr/sfw/lib/libXrender.so.1
libX11.so.4 = /usr/openwin/lib/libX11.so.4
libXrandr.so.2 = /usr/lib/libXrandr.so.2
libXi.so.5 = /usr/openwin/lib/libXi.so.5
libXext.so.0 = /usr/openwin/lib/libXext.so.0
libz.so.1 = /usr/lib/libz.so.1
libexpat.so.0 = /usr/sfw/lib/libexpat.so.0
libgcc_s.so.1 = /opt/gcc/lib/libgcc_s.so.1
libmp.so.2 = /usr/lib/libmp.so.2
libmd.so.1 = /usr/lib/libmd.so.1
libscf.so.1 = /usr/lib/libscf.so.1
libdl.so.1 = /usr/lib/libdl.so.1
libdoor.so.1 = /usr/lib/libdoor.so.1
libuutil.so.1 = /usr/lib/libuutil.so.1
libgen.so.1 = /usr/lib/libgen.so.1
/usr/lib/cpu/sparcv9+vis2/libmlib.so.2
/platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1
/platform/SUNW,Sun-Blade-1000/lib/libmd_psr.so.1
================================================== ====================

Next -- copy each of those shared libs into a directory and burn
a CD-ROM of it. Many of the shared libs are in /usr/lib, or perhaps
/usr/openwin/lib. Others in /usr/sfw/lib.

Next, copy the program to your newer system (e.g. my Solaris
10), put all of these libraries in (except probably the
/platform/SUNW.... ones), set up a wrapper script which sets
LD_LIBRARY_PATH to look at the directory of shared libs you just built,
and try running that version of gimp. (Or even just run ldd on that
gimp and look for "not found" reports.)

Try removing (moving into a subdirectory) one shared lib at a
time. starting with the /usr/lib ones, and see if ldd gimp still finds
all the shared libs without complaint. Usually the newer shared libs
which come with the system will work fine. It is just that BlastWave's
installer doesn't know this, and insists on installing up-to-date libs
for everything, whether they are needed or not.

I'll bet that at the end, you will find only a very few shared
libs which need to be added. Keep them in the directory, and keep
invoking gimp via the wrapper. If you discover that *all* of the shared
libs can be removed form that directory, you will have proven that it
will work without needing to add anything to the system.

As with many things in Unix which appear at first to be impossible, I
can see that this can be done, with quite a bit of work. One day I'd
like to try it, but right now I need to do some programming which will
make me cash :-).

I wish I could find a version of GIMP 1.2 which would save GIF and PNG
and was not dependent on shared libraries.


Compile your own! It will require a bit of tweaking of the
configure script and the produced Makefile, (and probably re-compiling
of some of the other things to provide a static library to link when you
compile gimp).

Remember that the primary form of "the GIMP" is freely
distributable source code, not pre-compiled binaries. :-)


Even if I can find a stable
version of GIMP 2, it was seriously slow when I tried it. Any idea where
I might find a later version of GIMP 1.2?


Here is the latest version (1.2.5) at this URL (and others):

http://mirror.umoss.org/gimp/gimp/v1.2/v1.2.5/


================================================== ====================
Name Last Modified Size Type
Parent Directory/ - Directory
README 2003-Jun-14 14:17:30 0.4K application/octet-stream
gimp-1.2.5.tar.bz2 2003-Jun-14 14:21:30 10.3M application/x-bzip
gimp-data-extras-1.2.0.tar.bz2 2000-Dec-24 19:16:30 4.2M application/x-bzip
gimp-data-extras-1.2.0.tar.gz 2000-Dec-24 19:14:30 4.5M application/x-gzip
patch-1.2.4-1.2.5.bz2 2003-Jun-14 14:35:30 153.3K application/x-bzip
================================================== ====================

But again, this is in source code form, and you have the great fun of
compiling it (and all the needed libraries which you don't have). And,
you'll probably need a lot of them, if you insist in sticking with
Solaris 9. :-)

Thanks for the link. I began to download that source code, but the
server kept dropping the connection. I'll try again later.

snip

Hmm ... "rare and expensive". Try an ebay search for:

Toshiba DVD-ROM SCSI M1401

1) $14.99

2) $49.00 (In a Sun UniPack external chassis)

3) $9.99

4) $25.00

5) $49.99 (five drives not just one)

6) $39.99

Sorry, I made a mistake. At the time I was searching for a SCSI DVD
writer, as I wanted to have just a single drive in the machine. At the
time, those were rare and expensive.


O.K. For that, you want an ACArd bridge card to convert IDE to
50-pin SCSI. With that, you can mount an IDE DVD burner in the system
in place of the original SCSI drive. I have such a drive in my Sun
Blade 2000, and another one in a FlexiPack (like a UniPack, except that
it holds two drives). That one is connected via an ACard bridge card
which adapts to 68-pin SCSI instead of 50-pin. This particular ACard
can be a pain in the system, but outside with a 68-pin interface, it
works nicely.

The only problem is that while the IDE DVD-burners are quite
inexpensive, the ACard is something like $59.00 or so. :-)

Are those things any good? I remember when they first came out - sold
for hard disks rather than CD-Roms - I heard some complaints that they
were more trouble than they were worth.

And right now, CDs suit my needs. The only reason a DVD burner might be
good is to back up the CDs of photographs I already have (they come on
CDs from the lab; I don't burn them myself). So far I've had no problems
with those CDs, but the oldest are over 5 years old now and I'm not sure
how long they'll last.

I would think that some of those would be cheap enough to use
for the task. It saves a *lot* of CD swapping, and of waiting around
for the right time to swap when loading Solaris 10 (5 CD-ROMs or one
DVD-ROM. :-)

I even put a spare into an ancient SGI Indigo 2, and it works
fine with CDs and DVDs.

What do you think of the Indigo 2?


Slow once I'm using a Sun Blade 2000 with dual 1.2 GHz CPU
modules. :-) This particular Indigo 2 is the Teal colored one, and
happens to have an unusual CPU -- the R8000 -- only 75 MHz, but it can
do floating-point math as fast as integer math.

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.

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

Best wishes,

Chris

On 2009-02-04, Christopher Tidy wrote:
Hi Don,

Yes, that is the version of GIMP that I have installed. I think it's
version 1.2. I found it more stable and faster than every copy of
version 2 that I could find.


As far as the speed is concerned, I find 2.0.2 is quite fast
enough -- at least on a Sun Blade 2000 with dual 1.2 GHz CPUs. And the
thing which makes the biggest difference in speed for *any* serious
image processor is the amount of RAM present. Running the Ultra-2 with
a full 2 GB of RAM made a significant difference. Running my SB-2K with
6 GB of RAM (instead of the 3 GB which I was running before) makes a big
difference in the speed of gimp 2.0.2.

It wasn't the speed once it was up and running, it was the start-up
time. On the same machine, GIMP 1.2 was quick, whereas GIMP 2 seemed to
take forever!

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.

Maybe the later Solaris 10 distributions did that for you before
packaging it.

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.

[ ... ]

2.0.2 will save both.

As would one version of GIMP 1.2, or possibly 1.x, which I had from
http://www.blastwave.org/ in 2004. And it was stable. But I can only use
it now if I use all the software dating from 2004.


Wrong! Install once and run "ldd `which gimp`" on it.

Note where it finds each shared lib. Here is what my gimp on
the SB-2K shows up:

[ ... ]

Next -- copy each of those shared libs into a directory and burn
a CD-ROM of it. Many of the shared libs are in /usr/lib, or perhaps
/usr/openwin/lib. Others in /usr/sfw/lib.

[ ... ]

I'll bet that at the end, you will find only a very few shared
libs which need to be added. Keep them in the directory, and keep
invoking gimp via the wrapper. If you discover that *all* of the shared
libs can be removed form that directory, you will have proven that it
will work without needing to add anything to the system.

As with many things in Unix which appear at first to be impossible, I
can see that this can be done, with quite a bit of work. One day I'd
like to try it, but right now I need to do some programming which will
make me cash :-).

I first read that as "Make me crash". :-)

I wish I could find a version of GIMP 1.2 which would save GIF and PNG
and was not dependent on shared libraries.

[ ... ]

Even if I can find a stable
version of GIMP 2, it was seriously slow when I tried it. Any idea where
I might find a later version of GIMP 1.2?


Here is the latest version (1.2.5) at this URL (and others):

http://mirror.umoss.org/gimp/gimp/v1.2/v1.2.5/

[ ... ]

But again, this is in source code form, and you have the great fun of
compiling it (and all the needed libraries which you don't have). And,
you'll probably need a lot of them, if you insist in sticking with
Solaris 9. :-)

Thanks for the link. I began to download that source code, but the
server kept dropping the connection. I'll try again later.

O.K. Good luck there.

snip

Hmm ... "rare and expensive". Try an ebay search for:

Toshiba DVD-ROM SCSI M1401

[ ... ]

Sorry, I made a mistake. At the time I was searching for a SCSI DVD
writer, as I wanted to have just a single drive in the machine. At the
time, those were rare and expensive.


O.K. For that, you want an ACArd bridge card to convert IDE to
50-pin SCSI. With that, you can mount an IDE DVD burner in the system
in place of the original SCSI drive. I have such a drive in my Sun
Blade 2000, and another one in a FlexiPack (like a UniPack, except that
it holds two drives). That one is connected via an ACard bridge card
which adapts to 68-pin SCSI instead of 50-pin. This particular ACard
can be a pain in the system, but outside with a 68-pin interface, it
works nicely.

The only problem is that while the IDE DVD-burners are quite
inexpensive, the ACard is something like $59.00 or so. :-)

Are those things any good? I remember when they first came out - sold
for hard disks rather than CD-Roms - I heard some complaints that they
were more trouble than they were worth.

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. :-)

And right now, CDs suit my needs. The only reason a DVD burner might be
good is to back up the CDs of photographs I already have (they come on
CDs from the lab; I don't burn them myself). So far I've had no problems
with those CDs, but the oldest are over 5 years old now and I'm not sure
how long they'll last.

Understood.

I would think that some of those would be cheap enough to use
for the task. It saves a *lot* of CD swapping, and of waiting around
for the right time to swap when loading Solaris 10 (5 CD-ROMs or one
DVD-ROM. :-)

I even put a spare into an ancient SGI Indigo 2, and it works
fine with CDs and DVDs.

What do you think of the Indigo 2?


Slow once I'm using a Sun Blade 2000 with dual 1.2 GHz CPU
modules. :-) This particular Indigo 2 is the Teal colored one, and
happens to have an unusual CPU -- the R8000 -- only 75 MHz, but it can
do floating-point math as fast as integer math.

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 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?

Enjoy,
DoN.

--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

DoN. Nichols wrote:

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.

Maybe the later Solaris 10 distributions did that for you before
packaging it.

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.

snip

As with many things in Unix which appear at first to be impossible, I
can see that this can be done, with quite a bit of work. One day I'd
like to try it, but right now I need to do some programming which will
make me cash :-).


I first read that as "Make me crash". :-)

Possibly, but I hope not :-).

snip

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.

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 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?

I was a bit reluctant to part with the Personal Iris actually. It was a
very interesting machine and built like a tank. But it had the Year 2000
problem and wasn't actually very useful, so I had to let it go. Sadly I
can't keep everything, although most people think I try. I'm glad I gave
it to a museum, though.

Best wishes,

Chris

On 2009-02-09, Christopher Tidy wrote:
DoN. Nichols wrote:

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:

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

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).

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.

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.

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.

and wasn't actually very useful, so I had to let it go. Sadly I
can't keep everything, although most people think I try. I'm glad I gave
it to a museum, though.

:-)

Enjoy,
DoN.

--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

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

On 2009-02-15, Christopher Tidy wrote:
Hi Don,

Shouldn't you really be sending these to me via eMail? This is
*far* off topic for rec.crafts.metalworking.

I won't reply again in the newsgroup, and it is a real pain for
me to send an e-mail reply to a usenet posting.

[ ... ]

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?

Yes -- just plain "man gimp".

It may be in the info package. Try typing "info gimp". In
solaris 10, it is part of /usr/sfw/bin, but this suggests that under
Solaris 9 it was more likely to be part of the Software_Companion
installation in /opt/sfw/bin. (Did you install all of the
Software_Companion. or just "the GIMP"?)

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.

O.K.

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.

The swap path could certainly affect the speed of the program.
You don't want to use /tmp, which will be competing with the system for
the system's swap space.

[ ... ]

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?

RAM is important, and the slower your disks, the slower the
system. It would be better to use a totally separate external disk for
the GIMP swap space. I'll bet that you are just letting it use whatever
it defaults to. (IIRC, gimp-2.0.2 asked me to define a swap partition
when it first started up, and encoded that in the ~/.gimp-2.0/.gimprc
file.

You might find it interesting to look in whatever ~/.gimp
directory you have. There are several rc files and several directories,
many of which can also affect startup time, such as the "pluginrc" file.

[ ... ACard and related stuff ... ]

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.

O.K. Ever consider getting a good tape backup unit? The
Exabyte Mammoth-2 drives can hold up to 60 GB with no compression, and
they claim up to 150 GB with the drive's own compression (obviously a
function of whether the files are already compressed. :-)

And the LTO tape drives will hold a lot more than that.

[ ... ]

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.

Yes -- for normal loads. I think that the R8000 might have been
better at floating-point intensive loads.

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

O.K.

[ ... ]

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.

[ ... ]

/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 haven't checked the one I have for that yet. Other things
have priority.

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?

I know that their security was terrible, because the OS kept
running a bunch of things SUID to root -- and had a bunch of
password-free accounts for running demos and the like. When I looked at
mine, I became very glad that I did not hang it on the external net. :-)

Maybe when I get around to compiling ssh for it I can disable
the rsh/rexec/rcp commands and breathe a bit easier.

However -- I only have one reason to run it now -- if I get the
proper DAT drive for it -- that is the ability to read audio DAT tapes,
which is disabled in most backup DAT drives, and not supported in the OS
in most other systems.

Enjoy,
DoN.

--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

DoN. Nichols wrote:
On 2009-02-15, Christopher Tidy wrote:

Hi Don,


Shouldn't you really be sending these to me via eMail? This is
*far* off topic for rec.crafts.metalworking.

I won't reply again in the newsgroup, and it is a real pain for
me to send an e-mail reply to a usenet posting.

You're probably right. I tend not to e-mail people who post to Usenet
unless they invite me to do so. But if I need your advice on a
non-metalworking topic again, that's what I'll do.

Netscape 7 news reader has the option "Reply to Sender Only" but I just
tried it now and it doesn't work. I imagine it needs to be configured to
connect to a mail server.

Thanks for the advice. I've got some useful ideas for improving the
performance of my workstation.

Best wishes,

Chris