Request for Help

[david.burton at checksol.com (Burton, David)]

Gentlemen--
I could use some help in disposing of 3,000 Xwindows diskless workstations
and 19" or 17" monitors.  These are by NCD, model HMX, have either 8 or 16
megs of RAM, and are in near new condition.  All I want for them are $450
apiece-the 19" monitors are worth that (proprietary cable but can be adapted
to standard PC with special video card @$100.00).  I'll split shipping
costs, UPS ground, for individuals.  If someone out there can find a
corporate buyer for the entire 3000 or some part thereof, a finders fee of
$20.00 per machine will be paid.  Corporate rate is $450.00 FOB Olive
Branch, Mississippi, and we will work with our shipper or one they
designate.  Includes all cables, keyboards, and mice.  Quite an opportunity
here.

Thanks all of you

Dave Burton





-----Original Message-----
From: John Chambers,,,781-647-1813 [mailto:jc at TRILLIAN.MIT.EDU]
Sent: Tuesday, August 03, 1999 8:23 AM
To: discuss at Blu.Org; linuxguy at ici.net
Subject: Re: Strange Tree




christoph remarked:
| > On Mon, 2 Aug 1999 Chris DiTrani <cditrani at ne.mediaone.net> wrote:
| > 
| > /usr/bin/mh is a symlink to ".", which makes /usr/bin/mh a reference to
| > /usr/bin. The behavior you're seeing is a natural side effect of this.
| > 
| > /usr/bin/mh is the original installation directory for the Rand MH, and
| > some third-party tools depended on it; hence the symlink to maintain
| > backwards compatibility.

| In my opinion, this is a silly hack.  If RedHat builds the packages from
| source, they should be able to control things better than this.

| A few years back, this type of recusive linking provided endless headaches
| when used with tar, find & cpio, and even worse was the unix-unaware
vender
| that ported crummy code.

Also, putting all the components of a package like mh  into  /usr/bin
isn't all that wise an idea.  This is an invitation to having package
X stomp on package Y by "accidentally" installing an executable  with
the same name as one of Y's executables.  For a package with only one
executable, this isn't much of a problem, but for a package  like  mh
with  a  whole  flock of executables, it is a recipe for disaster and
finger pointing and user bafflement.

A much better approach would be to install such complex packages into
their  own  directories,  as is conventionally done with X11 (and was
done with the original mh). Users who need to directly exec pieces of
the  package  will  need  to  be  told what to add to their $PATH, of
course, or a startup script could do it for them. But this isn't much
of  a  constraint,  and  is  much  easier to deal with than trying to
diagnose problems with one package overwriting another's executables.

I'm reminded of the many months it took me to get ghostview  to  work
properly. For the longest time, it just gave me bizarre error windows
with incomprehensible error messages.  I finally discovered that  the
problem  was  another  package  I'd  installed that had an executable
called "gs", which had wiped out  ghostview's  program  by  the  same
name.  I re-installed both of them into different directories (from a
non-su account so that they couldn't install their pieces  into  /bin
or  /usr/bin),  and  wrapped  their main commands in scripts that put
their own directories at the head of $PATH, and they both work now.


--
Modern GUIs are very well designed, for people with three hands. The
real problem has been how slow customers have been to make necessary
hardware upgrades to meet the requirements of the software.
-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).
-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).