WRONG!

William E. Davidsen Jr davidsen at steinmetz.ge.com
Tue Jun 7 05:11:27 AEST 1988


In article <51 at stanton.TCC.COM> donegan at stanton.TCC.COM (Steven P. Donegan) writes:

| Gosh Peter (FLAMES ON), I have been using vi on my XBBS bulletins, control
| files and motd's for ages. You tell me that it's obvious that I can't do
| what I've been doing for about 2 years?

  I suspect he mistyped that one. I'm sure what he meant was that the
message file (note singular) is fixed length records. If you have a way
to edit it with vi PLEASE let me know how you did it.

| I am getting rather sick of the totally unfounded and obviously uninformed
| comments of quite a few different individuals on Sandy's XBBS system. Most
| downside comments I've seen here so far prove that the individuals making
| the comments have never actually installed/operated/managed an XBBS system.

  Good hit 'n'instead of 'f', then.  If I'm one of the individuals you
mean, I've been running XBBS for months now (since before Christmas) and
I agreed with a few of the original remarks, and still do. 

| I also take exception to the 'low-performance application' comment. XBBS is
| a very efficient, fast, responsive system that hides system load well. Users
| of the XBBS system note very little response degradation on a heavily loaded
| system, much less than a shell user on the same system.

  Excuse me? I didn't say anything for or against the performance, but
if you look at the accounting files for XBBS, it does use quite a bit of
memory, CPU, and forks. I'm not sure anyone really said anything bad
about it, but I think calling it efficient and fast is pushing the issue
(as it calling it a pig).

Let's look at some usage figures from the last few days...


procname UID      u-cpu    s-cpu realtime  avg-K  line   iochar ioblk   ends   
bbsc1    xbbs      15.1     80.4   531.84  129.8  tty2A  313984   215 14:22:05
bbsc1    xbbs       3.3     27.0   233.12  144.2  tty2A   77376    85 22:10:34
bbsc1    xbbs       4.1     30.1   216.32  129.6  tty2A   67712    32 23:21:58

procname UID      u-cpu    s-cpu realtime  avg-K  line   iochar ioblk   ends   
bbsc1    xbbs       2.0     15.6   129.42  137.2  tty2A   49456    79  8:19:00
bbsc1    xbbs       3.3     25.8   259.04  127.1  tty2A   51208    91 12:05:47
bbsc1    xbbs       3.9     36.1   294.72  131.4  tty2A  116032    66 12:49:10
bbsc1    xbbs       8.7     73.7  1004.16  131.6  tty2A  181760   111 13:29:11
bbsc1    xbbs       2.3     23.6   352.00  140.8  tty1A   65376    86 13:39:12
bbsc1    xbbs       1.9     13.4   168.96  154.4  tty2A   53928    37 13:59:08


  Note that the CPU is about 10% of the real time, and that the system
time is a lot higher than the user time. This is a moderately large
program. This is one a 386 system with lots of memory and fast disk. If
you extrapolate to a 286 I can see that the performance might be a bit
sluggish. On a loaded machine it might be pretty bad. All of these
figures are from times when the load average was <0.3, so they represent
mostly load from XBBS.

  Let's stop this "is too" "is not" stuff. I think a number of people
will thell you that Sandy has not been responsive even to the point of
responding to fixes for existing bugs. I said before that's his
privilege, but don't expect support. The quality of the code is not
debateable, let anyone who cares pull the latest version and see what
they think. Nobody cares in the least about your opinion (or mine, the
original poster's, or Sandy's for that matter).

  I think both XBBS and UNaXcess represent sharing of a great deal of
work with the public, and both should be taken as "unsupported." Since I
offer both of them, I have some perspective on the comparisons, and I
agree that XBBS is quite hard to maintain, both in the code sense and
the sense of day to day system operation. It's comparable to some DOS
based systems in that respect, requiring renumbering messages, etc.
-- 
	bill davidsen		(wedu at ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me



More information about the Comp.unix.xenix mailing list