Article View: net.notes
Article #157Re: Flames from an ex-notesfile site - (nf)
From: kolstad
Date: Tue, 27 Sep 1983 04:57
Date: Tue, 27 Sep 1983 04:57
138 lines
7544 bytes
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!kolstadShow 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