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