Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: 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 #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