🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: net.notes
Article #157

Re: Flames from an ex-notesfile site - (nf)

#157
From: kolstad
Date: Tue, 27 Sep 1983 04:57
138 lines
7544 bytes
#R:pur-phy:-93400:parsec:40000001:000:6883
parsec!kolstad    Sep 19 23:25:00 1983

I guess I ought to respond to the notes flame as I really think it is
terrific stuff.

	1.  The index page gives no indication of what notes haven't been
	    read.  Thus, its advantage is limited.  Of course, I can see
	    the titles of new notes, but I can't tell if there is a reply
	    I want to see.  So I usually end up 'j'ing to them all anyway.

cosmetics here -- I can't imagine going through the 1700+ notes of
net.unix-wizards looking for which notes have/have not been read.
Keeping up the database of read/unread responses (currently just by
the "last perused date") seems enough.  Clearly the capability exists
(as the j key shows).  I find it easy at 9600 baud.  I imagine that
300 baud must be torture.

	2.  The grouping doesn't always work.  True, it makes a good
	    attempt, but not perfect.  It should really begin to generate 
	    a 2.10.1 compatible "References:" header and use it.  See below
	    for more about compatibility.

Some sites still run A news.  We discussed this stuff at length a couple
years ago and were told that everything must always remain compatible.
It's a miracle that it works at all.

	3.  Incompatibility with USENET software.  With 2.10.1, the
	    information kept in the header is completely lost after
	    travelling through a notes-only site.  Soon, as news begins to
	    rely more on this info, a notes-only site can only be regarded
	    as being a detriment to the network.  The 'A' news interface
	    has GOT to go, and soon.  The headers MUST be kept.  Subject
	    lines MUST be make longer.  The size limitation MUST be
	    removed.

The size lengths were, in hindsight, a mistake.  The file size length
was poor planning (who could imagine sending 65K chars at 300 baud?);
the argument about the title was the people don't need to read more
than x characters in the title.  Oops.
[The size limitation is leaving in the next notes version, I hear]

	4.  Reliability.  Administering it was a real pain in the A**!!
	    Rarely did a week or two go by that I didn't notice some
	    screw-up in the log like "some sort of failure resulted in a
	    jump to toobad".  This is an error message?!  Give me a break.
	    How am I supposed to find and fix bugs that aren't clearly
	    described?  Few, if any, messages even mentioned the notesfile
	    it referred to.  About once a week I had to manually remove
	    lock files (and not as the result of a crash).  A few times, I
	    even had to adb the text file to clear the NFINVALID bit.

I was surprised to read this.  We have had two lock problems since January.
They are now reported as they happen -- haven't seen any reports on this
the latest version of news.  Otherwise, I've been delighted with maintaining
notes.  No work.  It always goes.  We use a 4.1c...

	5.  Permission lists:  great idea, but never used for USENET news.
	    It would have been great if I could have by default set myself
	    up as the the director of every notesfile, but there was no
	    way to do this except by running as the notes user and doing
	    it manually.  And no, I don't believe the notes user should be
	    a real person, since real people often move, and I don't want
	    my uid "wired" into any system software.

No flame here...conflict of design philosophies.  I've noticed that some
users are now discussing the idea of permission lists for news.

	6.  Display driver: stupid.  When you use it at 300 baud, you see
	    how much it wastes time.  Also, since there is no way to tweak
	    the screen, often important blocks of text get split between
	    windows.  This is extremely frustrating.

I certainly agree that reading text at 300 baud is a loser.  I'm not so
sure this is a problem inherent to notes but it sure was designed with
9600 baud terminals in mind.  There should be an alternate low speed
interface.  I don't get that concerned about splitting blocks of text.

	7.  Mailing replies: almost impossible.  The router supplied won't
	    build a real data base on an 11.  Furthermore, databases
	    change, and the table probably doesn't.  With 4.2's sendmail,
	    it won't be so bad, I guess.

This problem certainly occurs since the 11 hasn't enough address space to
build the data base.  I maintain (and distribute) one version of the database
and NEVER have problems with responses.  This is one of the points that our
users always mention as handy.  It certainly has little to do with the
notesfile implementation per se.

	8.  The method of keeping the text of the notes saves space, but I
	    dislike it.  Why?  Because I like to be able to grep through
	    the news directory for some reference I seem to remember.  The
	    title is often deficient in helping me to find it, so 'grep'
	    is great for this.  Furthermore, due to some screwup, it's
	    easy to really trash a notesfile this way.  Our net.sources
	    notefiles was being clobbered every week by, it appears, a bad
	    free pointer.  I was forced to stop gating it in from news. Of
	    course, the problem is now moot, at least for us.

I spec'd a keyword search for original notes -- it never made it in (incredible
amount of CPU/disk accesses).  We've never had a trashed notefile at
parsec.

	9.  This last one concerns personal preference.  I dislike moded
	    command structure.  I would rather not have to swap command
	    sets every other minute.  Vnews has one set of commands that
	    work everywhere, none of this index page commands, reading
	    note commands, reading reply commands, etc.

I kinda liked the way the commands worked out that most keys do the same
thing everywhere.  There are exceptions, but not too many.


     Well, that about does it.  The news people have finally given us an
     interface that I can enjoy.  Notesfiles came very close--it was well ahead
     for about a year.  However, one thing I cannot personally stand is
     software that "just about" works.  If features are missing, ok, they can
     be added.  If features behave poorly, then I begin to fume.  I realize
     that this software was probably written in spare time, i.e., not a funded
     project.  I did not intend to insult any of its authors.  However, I
     implore whoever is supporting it now to consider these remarks, especially
     the ones relating to USENET compatibility.  Excuses like "notesfiles can't
     do this or that" when talking about things like net.general/followup, etc.
     just don't cut it.

As with much software, the notesfile implementation evolves.  None of these
comments showed up in net.notes *sigh*.  People having these kinds of
problems should send them to net.notes or uiucdcs!essick for acknowledgment
and repair.  The package is a viable one.


   I suppose I'll get flames about this back.  Oh well, if I can dish it 
   out . . . .

Hope this didn't hurt too bad.....

					Rob Kolstad
					PARSEC
Technical Details
Message-ID: <2908@uiucdcs.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!linus!philabs!cmcl2!floyd!clyde!ihnp4!ixn5c!inuxc!pur-ee!uiucdcs!parsec!kolstad

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!linus!philabs!cmcl2!floyd!clyde!ihnp4!ixn5c!inuxc!pur-ee!uiucdcs!parsec!kolstad
From: kolstad@parsec.UUCP
Newsgroups: net.notes
Subject: Re: Flames from an ex-notesfile site - (nf)
Message-ID: <2908@uiucdcs.UUCP>
Date: Tue, 27-Sep-83 00:57:45 EDT
Article-I.D.: uiucdcs.2908
Posted: Tue Sep 27 00:57:45 1983
Date-Received: Thu, 22-Sep-83 06:48:29 EDT
Lines: 138