[4237] in SIPB bug reports
Discuss 1.6 without kerberos
daemon@ATHENA.MIT.EDU (ejb@ERA.COM)
Wed Nov 10 20:06:33 1993
Date: Wed, 10 Nov 93 15:01:41 -0500
From: ejb@ERA.COM
To: bug-discuss@MIT.EDU
Cc: bug-sipb@MIT.EDU
Cc: ejb@ERA.COM
Hello. Gee. I wonder whether I still know anyone on this list.
I have recently acquired discuss 1.6 (from ftp.uu.net, which is
all I have ready access to from here) and attempted to compile
it here at ERA. We do have zephyr installed, but not kerberos.
It seems to me that discuss has not really been tested in a
non-kerberos environment. I had to make several modifications
to Imakefiles to even get the thing to compile. (-DKERBEROS,
-lkrb, etc. were hardcoded in many places in spite of the fact
that $(KRBDEF), $(KRBLIB), etc. are defined in site.def.) The
result was a discuss that works fine including the zephyr
announcements as long as you only try to read meetings on your
local host. Any remote access to meetings fails with a
completely useless error message (Unknown code H 0 <hostname>).
If I ever get this working, I will send you my patches. If you
want what I have so far, I can send those along...
Before I either decide to give up and use local news groups or
to install kerberos, I am wondering whether there is a more
recent somewhat stable version of discuss than the discuss 1.6
on ftp.uu.net is dated 6/17/92 and is most likely mirrored from
athena-dist.
Although I have been on the verge of installing kerberos here
for some time, there is really little need since we are on an
internal-only network with just a uucp link to the outside.
Also, since we don't really have a good way to tightly integrate
it with the rest of our environment, it would be hard to get
people to run kinit just so they could read discuss meetings.
BTW, we were hoping to use discuss primarily as a means of
having (marginally) controlled access forums for tracking
development efforts instead of doing what people do now which is
to just send out mail to different individuals or mailing
lists...
On another note, after leaving Athena/SIPB/MIT, I have been
exposed to a wider range of systems including some SVR4 and even
SVR3 systems. I am constantly struck whenever I go back to
sources from SIPB or Athena at how BSD they are. Of course, I
can understand this having "grown up" at Athena myself, but in
this day and age, it looks kind of bad to have code that is not
portable to system V environments. It is no longer a hard
problem, so to speak. I for one have become a proponent of gnu
autoconf. It's not hard to write good portable code with gnu
autoconf, the information in its info pages, and some sense of
what kinds of things are different between BSD and system V. I
have recently had the experience of starting to work on an SGI
Indigo running 4.0.5H (a system V release 3 operating system)
and having several thousand lines of code I wrote with autoconf
compile without any errors or warnings. I had never programmed
in an svr3 environment before when this happened. It is also
possible to combine the autoconf style of portability with imake
if people still insist upon using it. You can have a config.def
file or something similar to that be generated by autoconf. I
typically do large software builds with gnu make these days and
use autoconf to generate a file that is included by other
makefiles.
Anyway, that's just my $0.02. In some ways, I wish I could be
back there to push some of these things more actively...
Jay Berkenbilt (ejb@ERA.COM)
Engineering Research Associates
Formerly qjb@MIT.EDU
P.S. If there is a reasonable version of discuss around
accessible from athena, I can still dial in long distance to my
athena account and mail stuff here....
