🚀 go-pugleaf

Probably be a useful idea to start off by defining
some "do and don't do" rules (or "motherhood and
apple pie" baselines) for the vaporware plug and
play Usenet system under consideration.

1) Not MS-DOS. Why? I spent a mercifully brief nine
months working on a ten month MS-DOS project to
upgrade an existing commercial software package with
much more functionality to "beat the competition";
it's delivery was just announced, three YEARS late.

Every problem _I_ saw was due to overstressing an
architecture and an operating system already pushed
far past its limits.  Cheap as the hardware and OS
are, building on an MS-DOS base is a recipie for
failure or immediate obsolescence.

Something like SCO Unix on a fairly cheap 80386 box
would probably be fairly effective.  AmigaUX is a
SYSVr4 Unix, but a bit pricy compared to the Intel
boxes, but it might be worth considering too, since
the software would all be PD after the initial
purchase.

2) Preemptive multitasking -- so the operator can be
using the system, while the filing software is
working at sorting out news/mail, while at least
one user is logged in.

3) Diligient, highly directive error reporting; not
just "error ### occurred", but "The last transfer
was halted due to lack of spool partition space;
your current expire is 3 days, run expire with a two
day parameter (do a 'man expire' to see how) to get
more room, or look for suspiciously overlarge or
over-age files using 'find' (see 'man find')."

4) A complete online glossary and help/manual set:
"what's a spool partition" should be an easy
question to answer.

5) Brilliant error recovery from all the current
problems; dropped user lines, dropped feed lines,
overlarge file transfer, file system corruption,
power loss, etc.

6) A prioritizing system to transfer files in aged
"smallest files first" fashion to encourage brevity.

7) Backing store for files await transmission; this
may (probably will) require operator intervention,
but we shouldn't be afraid to make the system labor
intensive to save costs; we have the example of
amateur radio operators to show us how hard
hobbiests are willing to work, we just need to make
the system not be knowledge intensive, so that those
diligent but unskilled can just follow directions to
make it work.

8) Robust and commonly available components; we
should _expect_ phone line quality problems, power
brownouts, lightning storms, etc. Since repairs
will be a problem, select stuff that doesn't break
often, and where local spares are an affordable
option.

9) Redundancy; use two lesser grade $300 systems
instead of one $600 system, so that graceful failure
modes exist; do this even at the sacrifice of
greater overall throughput from the monolithic
system.

10) A _very_ simple editor, character and line
oriented, that automatically avoids transmitting
overlong lines, etc.

11) Lots of optional ways to do things; hooks to use
radio instead of phone instead of satellite; swap
editors at the user level, locally present news as
mail and vice versa, etc.

12) Respect for local character sets; probably best
to just start with a 16 bit or variable length
character size; this implies that each document
transmitted should have a header that identifies
language and character set, so that we monolinguals
can pick our favorite language out of a wider
discussion. While I love English as a standard
language for world discussion, and it is probably
the most common second language in the world, it is
still not reasonable to ask local conversations to
occur in English.

13) Probably tons more; someone else take a turn.

Kent, the man from xanth.
<xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>