henry@zoo.toronto.edu (Henry Spencer) (09/10/90)
This cleans up the exceedingly obscure relaying bug in the 1-Sep patch,
and beefs up the relaynews regression test considerably. (It also adds
an item in notebook/problems that just happened to come along last week.)
start of patch 7-Sep-1990
(suggested archive name: `pch7Sep90.Z')
this should be run with patch -p0 <thisfile
The following is a complete list of patches to date.
Prereq: 23-Jun-1989
Prereq: 7-Jul-1989
Prereq: 23-Jul-1989
Prereq: 22-Aug-1989
Prereq: 24-Aug-1989
Prereq: 14-Sep-1989
Prereq: 13-Nov-1989
Prereq: 10-Jan-1990
Prereq: 16-Jan-1990
Prereq: 17-Jan-1990
Prereq: 18-Jan-1990
Prereq: 12-Mar-1990
Prereq: 14-Apr-1990
Prereq: 15-Apr-1990
Prereq: 16-Apr-1990
Prereq: 25-May-1990
Prereq: 1-Sep-1990
*** PATCHDATES.old Fri Sep 7 13:53:29 1990
--- PATCHDATES Fri Sep 7 13:53:29 1990
***************
*** 1,17 ****
--- 1,18 ----
23-Jun-1989
7-Jul-1989
23-Jul-1989
22-Aug-1989
24-Aug-1989
14-Sep-1989
13-Nov-1989
10-Jan-1990
16-Jan-1990
17-Jan-1990
18-Jan-1990
12-Mar-1990
14-Apr-1990
15-Apr-1990
16-Apr-1990
25-May-1990
1-Sep-1990
+ 7-Sep-1990
Changed files, if any:
*** cnpatch/old/libcnews/string.c Wed Sep 5 15:46:32 1990
--- libcnews/string.c Thu Sep 6 19:00:29 1990
***************
*** 272,276 ****
if (nxpathp == NULL)
return NULL; /* path exhausted */
! if (STREQN(pathp, host, hostlen) == 0 &&
(pathp == path || nothostchar(pathp[-1])) &&
nothostchar(pathp[hostlen]))
--- 272,277 ----
if (nxpathp == NULL)
return NULL; /* path exhausted */
! pathp = nxpathp;
! if (STREQN(pathp, host, hostlen) &&
(pathp == path || nothostchar(pathp[-1])) &&
nothostchar(pathp[hostlen]))
*** cnpatch/old/notebook/problems Wed Sep 5 15:46:34 1990
--- notebook/problems Fri Sep 7 13:32:35 1990
***************
*** 520,521 ****
--- 520,537 ----
.DE
This command should output nothing.
+ .SH
+ Values of Logical Operators
+ .PP
+ There seem to
+ be compilers, e.g. the Ultrix one on DEC's new RISC workstations,
+ that go into convulsions when they see something like
+ .DS
+ *p++ = isascii(c) && isalnum(c);
+ .DE
+ because they don't know how to generate a numeric value for `&&'.
+ One or two places in C News use constructs like this.
+ If you run into this, you might
+ want to try replacing the
+ right-hand side
+ with something like ``(...)\ ?\ 1\ :\ 0'' to get the
+ troublesome operator back into a conditional context.
*** cnpatch/old/relay/regress/master/art1 Tue Jun 20 19:00:40 1989
--- relay/regress/master/art1 Thu Sep 6 18:51:13 1990
***************
*** 1,3 ****
! Path: host!user
From: user@host
Message-ID: <#1@host>
--- 1,3 ----
! Path: host!foo!user
From: user@host
Message-ID: <#1@host>
***************
*** 4,6 ****
Newsgroups: test.a
! ## This should appear in test/a/1
--- 4,6 ----
Newsgroups: test.a
! ## This should appear in test/a/1 and not be sent to foo
*** cnpatch/old/relay/regress/master/batch Tue Jun 20 19:00:42 1989
--- relay/regress/master/batch Thu Sep 6 19:03:41 1990
***************
*** 1,4 ****
! #! rnews 108
! Path: host!user
From: user@host
Message-ID: <#1@host>
--- 1,4 ----
! #! rnews 135
! Path: host!foo!user
From: user@host
Message-ID: <#1@host>
***************
*** 5,9 ****
Newsgroups: test.a
! ## This should appear in test/a/1
#! rnews 108
Path: host!user
--- 5,9 ----
Newsgroups: test.a
! ## This should appear in test/a/1 and not be sent to foo
#! rnews 108
Path: host!user
*** cnpatch/old/relay/regress/master/sys Tue Jun 20 19:00:45 1989
--- relay/regress/master/sys Thu Sep 6 18:50:14 1990
***************
*** 1,2 ****
--- 1,4 ----
ME:all
foo:all:f:/dev/null
+ bar:all:f:/dev/null
+ baz:all:f:/dev/null
*** cnpatch/old/relay/regress/out/art1 Tue Jun 20 19:00:29 1989
--- relay/regress/out/art1 Thu Sep 6 19:03:41 1990
***************
*** 1,3 ****
! Path: host!user
From: user@host
Message-ID: <#1@host>
--- 1,3 ----
! Path: host!foo!user
From: user@host
Message-ID: <#1@host>
***************
*** 4,6 ****
Newsgroups: test.a
! ## This should appear in test/a/1
--- 4,6 ----
Newsgroups: test.a
! ## This should appear in test/a/1 and not be sent to foo
*** cnpatch/old/relay/regress/out/batch Tue Jun 20 19:00:31 1989
--- relay/regress/out/batch Thu Sep 6 19:03:42 1990
***************
*** 1,4 ****
! #! rnews 108
! Path: host!user
From: user@host
Message-ID: <#1@host>
--- 1,4 ----
! #! rnews 135
! Path: host!foo!user
From: user@host
Message-ID: <#1@host>
***************
*** 5,9 ****
Newsgroups: test.a
! ## This should appear in test/a/1
#! rnews 108
Path: host!user
--- 5,9 ----
Newsgroups: test.a
! ## This should appear in test/a/1 and not be sent to foo
#! rnews 108
Path: host!user
*** cnpatch/old/relay/regress/out/log Tue Jun 20 19:00:33 1989
--- relay/regress/out/log Fri Sep 7 04:01:13 1990
***************
*** 1,5 ****
! TIME host + <#1@host> foo
! TIME host + <#2@host> foo
! TIME host + <#3@host> foo
! TIME host + <#4@host> foo
! TIME host + <#5@host> foo
--- 1,5 ----
! TIME host + <#1@host> bar baz
! TIME host + <#2@host> foo bar baz
! TIME host + <#3@host> foo bar baz
! TIME host + <#4@host> foo bar baz
! TIME host + <#5@host> foo bar baz
*** cnpatch/old/relay/regress/out/sys Tue Jun 20 19:00:34 1989
--- relay/regress/out/sys Thu Sep 6 18:53:13 1990
***************
*** 1,2 ****
--- 1,4 ----
ME:all
foo:all:f:/dev/null
+ bar:all:f:/dev/null
+ baz:all:f:/dev/null
*** cnpatch/old/relay/regress/out/test/a/1 Tue Jun 20 19:00:36 1989
--- relay/regress/out/test/a/1 Thu Sep 6 19:05:23 1990
***************
*** 1,3 ****
! Path: hostb!host!user
From: user@host
Message-ID: <#1@host>
--- 1,3 ----
! Path: hostb!host!foo!user
From: user@host
Message-ID: <#1@host>
***************
*** 4,6 ****
Newsgroups: test.a
! ## This should appear in test/a/1
--- 4,6 ----
Newsgroups: test.a
! ## This should appear in test/a/1 and not be sent to foo
*** cnpatch/old/relay/transmit.c Wed Sep 5 15:46:36 1990
--- relay/transmit.c Thu Sep 6 19:14:47 1990
***************
*** 92,95 ****
--- 92,99 ----
nnfree(&canpath);
canpath = canonpath(art->h.h_path, art->h.h_approved, art->h.h_sender);
+ #ifdef notdef /* DEBUG */
+ fprintf(stderr, "path=%s canonpath=%s\n", art->h.h_path,
+ canpath);
+ #endif
}
path = canpath;
Files that are new:
new relay/regress/master/mkbatch (patch can't create, so diff against null):
Index: relay/regress/master/mkbatch
*** cnpatch/old/relay/regress/master/mkbatch Fri Sep 7 13:58:02 1990
--- relay/regress/master/mkbatch Thu Sep 6 19:03:30 1990
***************
*** 0 ****
--- 1,7 ----
+ #! /bin/sh
+ for art
+ do
+ bytes=`wc -c <$art`
+ echo "#! rnews `echo $bytes`"
+ cat $art
+ done
new relay/regress/out/mkbatch (patch can't create, so diff against null):
Index: relay/regress/out/mkbatch
*** cnpatch/old/relay/regress/out/mkbatch Fri Sep 7 13:58:03 1990
--- relay/regress/out/mkbatch Fri Sep 7 04:00:57 1990
***************
*** 0 ****
--- 1,7 ----
+ #! /bin/sh
+ for art
+ do
+ bytes=`wc -c <$art`
+ echo "#! rnews `echo $bytes`"
+ cat $art
+ done
end of patch 7-Sep-1990
--
TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
OSI: handling yesterday's loads someday| henry@zoo.toronto.edu utzoo!henrysrc@scuzzy.mbx.sub.org (Heiko Blume) (09/14/90)
since cnews has become really stable, i would suggest posting the whole thing soon. that would also be an opportunity to start using release numbers and patchlevel.h etc. (i like files like cnews-1.0.tar.Z :-) any comments/objections ? -- Heiko Blume c/o Diakite blume@scuzzy.in-berlin.de FAX (+49 30) 882 50 65 Kottbusser Damm 28 blume@scuzzy.mbx.sub.org VOICE (+49 30) 691 88 93 D-1000 Berlin 61 blume@netmbx.de TELEX 184174 intro d scuzzy Any ACU,e 19200 6919520 ogin:--ogin: nuucp ssword: nuucp
lmb@vicom.com (Larry Blair) (09/17/90)
In article <1990Sep13.203645.12937@scuzzy.mbx.sub.org> src@scuzzy.mbx.sub.org (Heiko Blume) writes:
=since cnews has become really stable, i would suggest posting the
=whole thing soon. that would also be an opportunity to start using
=release numbers and patchlevel.h etc. (i like files like cnews-1.0.tar.Z :-)
Patch _numbers_? In C News? What a novel idea!
I notice that, if we were counting, we are up to PL 18. This is about what
I would expect from a piece of software of this complexity.
I'm sure that Henry will gladly try to defend his scheme again. He has never
presented a reasonable explanation. His reasons have been such things as
"It's an experiment" and "We don't subscribe to the patch-of-the-month club."
Interesting that there have been 18 patches in 15 months. I'll bet the reason
this time will be "It's too late to change."
One of the statements that Henry has made repeatedly is that C News not
supposed to be the universal news transport system. The fact is that more
and more sites are switching to C News and the refusal to accept the problems
generated by C News are propogating. My favorites are: exceedingly long
message id's, accepting of old news with no check, and insufficient logging
for statistics generation.
I think that Henry and Geoff need to accept that fact that their software, in
the absence of anything better, is becoming the net standard and act in a
manor that is responsible and consistent with the rest of the net. The time
has come for normal patch levels and reasonable message id's.
--
Larry Blair ames!vsi1!lmb lmb@vicom.comlouie@sayshell.umd.edu (Louis A. Mamakos) (09/17/90)
In article <1990Sep17.010600.11421@vicom.com> lmb@vicom.com (Larry Blair) writes: >I think that Henry and Geoff need to accept that fact that their software, in >the absence of anything better, is becoming the net standard and act in a >manor that is responsible and consistent with the rest of the net. The time >has come for normal patch levels and reasonable message id's. Er, excuse me, but did Henry and Geoff come visit your site and force you to install C news on your system? THEY wrote the software, THEY made it available for YOU to use for FREE, and you demand that they act in a "responsible" manner? If you don't like the softare, don't use it. But don't give these guys a hard time because the choose to give software away for others to use rather than just using it internally. What do you want for free? You can't even give software away for free these days.. louie
karl_kleinpaste@cis.ohio-state.edu (09/17/90)
lmb@vicom.com writes: The time has come for normal patch levels... From the latest osu-cis!~/GNU.how-to-get: | Spencer/Collyer C News is available as well. | Source is somewhere at UToronto as of 23 June 1989. | Root is ~/news/c/cnews.Z-part-a[a-d] [4 pieces]. | There are currently 18 patches required in order to get up to date. | These ared linked in two schemes, one a modified Toronto-peculiar | dating method (the names sort properly), and the other a simple | numeric ordering. Patch names are thus: | | size ~/news/c/Patch/toronto ~/news/c/Patch/numeric | ---- ---------------------- ---------------------- | 26,613 cnews-890623.Z cnews-patch-01.Z | 21,979 cnews-890707.Z cnews-patch-02.Z | 14,503 cnews-890723.Z cnews-patch-03.Z | 28,218 cnews-890822.Z cnews-patch-04.Z | 25,518 cnews-890824.Z cnews-patch-05.Z | 25,485 cnews-890914.Z cnews-patch-06.Z | 23,322 cnews-891113.Z cnews-patch-07.Z | 29,201 cnews-900110.Z cnews-patch-08.Z | 27,776 cnews-900116.Z cnews-patch-09.Z | 23,712 cnews-900117.Z cnews-patch-10.Z | 1,887 cnews-900118.Z cnews-patch-11.Z | 23,005 cnews-900312.Z cnews-patch-12.Z | 23,918 cnews-900414.Z cnews-patch-13.Z | 21,118 cnews-900415.Z cnews-patch-14.Z | 13,018 cnews-900416.Z cnews-patch-15.Z | 29,409 cnews-900525.Z cnews-patch-16.Z | 19,325 cnews-900901.Z cnews-patch-17.Z | 3,889 cnews-900907.Z cnews-patch-18.Z Still running B 2.11.19, --karl
henry@zoo.toronto.edu (Henry Spencer) (09/17/90)
In article <1990Sep13.203645.12937@scuzzy.mbx.sub.org> src@scuzzy.mbx.sub.org (Heiko Blume) writes: >since cnews has become really stable, i would suggest posting the >whole thing soon. that would also be an opportunity to start using >release numbers and patchlevel.h etc... Actually, the relative stability over the summer has been more a matter of lack of time than lack of changes to make. Expect more patches this fall. At some decidedly ill-defined point, we plan what we're currently calling the "cleanup release". This probably *will* appear in its entirety, for a fairly fundamental reason. Patches are very awkward for dealing with certain kinds of changes, like moving files around, and the list of things needing such reorganization is growing. This will also simplify a few relatively drastic changes that might cause very bloated patches, e.g. the new inews. Given the reasons for the cleanup release, it will and must be a break with continuity: there will be no patches to bring an old system up to it. It is likely that we will give a bit of thought to patch designations and the like then. Note, I'm saying we'll probably think about it, not that we promise to make changes. Please do not ask when the cleanup release will be, because we don't have a date for it. It won't be next week and probably won't be next month; I don't recommend delaying conversions and/or updates in hopes that it will soon appear. -- TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology OSI: handling yesterday's loads someday| henry@zoo.toronto.edu utzoo!henry
lmb@vicom.com (Larry Blair) (09/18/90)
In article <1990Sep17.121127.25859@ni.umd.edu> louie@sayshell.umd.edu (Louis A. Mamakos) writes: =In article <1990Sep17.010600.11421@vicom.com> lmb@vicom.com (Larry Blair) writes: = =>I think that Henry and Geoff need to accept that fact that their software, in =>the absence of anything better, is becoming the net standard and act in a =>manor that is responsible and consistent with the rest of the net. The time =>has come for normal patch levels and reasonable message id's. = =Er, excuse me, but did Henry and Geoff come visit your site and force =you to install C news on your system? THEY wrote the software, THEY =made it available for YOU to use for FREE, and you demand that they =act in a "responsible" manner? They distributed the software and have actively promoted it as the `better' alternative. Their software has caused my site and the rest of the net considerable grief due to the (now fixed) inews -C bug and the overly long message id's (which broke rn). This is whether I run C News or 2.11. The problem with their patch scheme is that many admins are unsure if it is safe to apply a patch or if they are up to date and this has led to a continuation of the inews -C problem. As long as they feel that they need to `sell' the net on their software, and as long as it is the defacto standard (which it is becoming), they bear a definite responsibility to the rest of the net. There is one fact that I want to make abundantly clear: I applaud Henry and Geoff's efforts to write and maintain C News. Without their work many sites would have drowned in the ever increasing traffic on the net. There are things about C News over which Henry and I have disagreed ever since I started running it (which was before it was posted to the net), but that doesn't mean that I don't have a great deal of respect for him. -- Larry Blair ames!vsi1!lmb lmb@vicom.com
I.G.Batten@fulcrum.bt.co.uk (Ian G Batten) (09/18/90)
lmb@vicom.com (Larry Blair) writes: > considerable grief due to the (now fixed) inews -C bug and the overly long > message id's (which broke rn). This is whether I run C News or 2.11. The Right. Note my message-id. Joe Zeeff's mkid program takes all of about ten seconds to install, and the fixes to the header building stuff take about ten seconds to make. Compared to the effort involved in installing C News, I guess that it's about comparable in energy budget to shifting your weight on your chair. This is the first I've heard about C news ``breaking'' rn. I assume this is a reference to overflowing the References: line...which was always there. You might as well argue that using FQDNs in message-ids is Evil and Rude. ian
arnold@audiofax.com (Arnold Robbins) (09/18/90)
In article <1990Sep17.164545.1603@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: > Patches are very awkward for dealing with >certain kinds of changes, like moving files around, and the list of things >needing such reorganization is growing. This will also simplify a few >relatively drastic changes that might cause very bloated patches, e.g. >the new inews. I made the following suggestion once in e-mail, but as Henry didn't reply, I suspect the mail got lost and he never got it. I suggest that a "patch" to produce the cleanup release consist of two parts. 1) A shell script that accomplishes the reorganization, such as making new directories deleting things to be deleted moving things that need to be moved 2) A normal context diff to produce new or changed things. Or, new things could go into a shar/here-document in part (1), and just the changes go in the context diffs. This allows one to keep continuity, without overly bloating the patches. Just a suggestion, but one that I hope will at least be considered. -- Arnold Robbins AudioFAX, Inc. | Laundry increases 2000 Powers Ferry Road, #200 / Marietta, GA. 30067 | exponentially in the INTERNET: arnold@audiofax.com Phone: +1 404 933 7600 | number of children. UUCP: emory!audfax!arnold Fax-box: +1 404 618 4581 | -- Miriam Robbins
chip@tct.uucp (Chip Salzenberg) (09/19/90)
According to lmb@vicom.com (Larry Blair): >As long as they feel that they need to `sell' the net on their software, and >as long as it is the defacto standard (which it is becoming), they bear a >definite responsibility to the rest of the net. I disagree. Each Usenet administrator is solely responsible for the installation and use of Usenet software at his site. Admins who don't RTFM are the cause of most trouble with C News. Every version of news software has its bugs. No reasonable person could expect otherwise. Perhaps you've forgotten the bug in B News that caused infinite retransmission of articles with certain kinds of badly formed message IDs? C News isn't alone in having problems. Long message IDs may trigger bugs in rn -- but note that the bug is in the newsreader, not in the transport. Larry Wall should never have used fixed-length buffers for any news article header field. So he makes mistakes too. Surprise, surprise. Geoff Collyer, Henry Spencer and Larry Wall are assets. Let's treat them as such. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip>
woods@eci386.uucp (Greg A. Woods) (09/19/90)
In article <1990Sep17.210150.1586@vicom.com> lmb@vicom.com (Larry Blair) writes: > They distributed the software and have actively promoted it as the `better' > alternative. Their software has caused my site and the rest of the net > considerable grief due to the (now fixed) inews -C bug and the overly long > message id's (which broke rn). This is whether I run C News or 2.11. The > problem with their patch scheme is that many admins are unsure if it is safe > to apply a patch or if they are up to date and this has led to a continuation > of the inews -C problem. I *never* had a problem with the rn vs. C news, and I'm not so blind to believe a totally different system will have the same administrative interface. Perhaps 'inews -C' could have been avoided somehow. It's a common mistake to assume people have more common sense than they actually do, but if we worked with the LCD, we'd never get anywhere. Yes, I agree they have a responsibility, but it is only to deliver what they have been promising, which they have readily outdone themselves with C news. They did not promise to use Configure (which is OK by me), and they did not promise to follow blindly down the beaten path of traditional "net"-style software maintenance (which I'm also quite happy to see). [I would like to see a different manner of software maintenance and configuration than now exists for C news, but I gave up complaining and designed my own custom version.... :-)] > There is one fact that I want to make abundantly clear: I applaud Henry and > Geoff's efforts to write and maintain C News. Without their work many sites > would have drowned in the ever increasing traffic on the net. There are > things about C News over which Henry and I have disagreed ever since I > started running it (which was before it was posted to the net), but that > doesn't mean that I don't have a great deal of respect for him. Same goes for me. (I ran the alpha version on a couple of sites, and have never gone back to 2.11, and never will.) -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP +1-416-443-1734 [h] +1-416-595-5425 [w] VE3-TCP Toronto, Ontario CANADA
henry@zoo.toronto.edu (Henry Spencer) (09/19/90)
In article <1990Sep17.210150.1586@vicom.com> lmb@vicom.com (Larry Blair) writes: >...Their software has caused my site and the rest of the net >considerable grief due to the (now fixed) inews -C bug and the overly long >message id's (which broke rn). This is whether I run C News or 2.11. The >problem with their patch scheme is that many admins are unsure if it is safe >to apply a patch or if they are up to date ... One of the reasons why we're reluctant to change our patch scheme is pure spleen against people who appear to be blindly prejudiced against it, as shown by the silly reasons they advance. - How do you know whether it is safe to apply a C News patch? Well, how do you know if it is safe to apply a B News patch? Numbering/dating has nothing to do with it. - How do you know whether you have the latest C News patch? Well, how do you know whether you have the latest B News patch? Numbering/dating has nothing to do with it. Actually, dating is probably ahead here, since if you have last February's patch, you might suspect you are behind, while having patch 12 tells you nothing of the kind. The inews -C nuisance was the result of treating B2.10 as the standard behavior of news, which it was at the time much of C News was first written. Oh well... I agree that this was a botch, but it wasn't a "bug" in the sense of code that didn't meet the desired specs. Anyone who still has this in their code clearly has not been keeping up with patches *at all*, since we fixed that one long ago. Nothing we can do -- numbering the patches, naming them Joe and Fred, including death threats against people who do not upgrade, *nothing* -- will induce 100% of the net to keep up to date. There are still sites running B2.6, and even I have trouble remembering a time when that was current. As for the overly long message IDs... We do concede that they're a bit wordy, and a fix for this is coming as part of the inews rewrite. However, folks who think everything would have been peachy without C News should look at the lengths of some of the domain names in message IDs nowadays. At most, C News hastened the problem's arrival slightly. Neither of these has anything to do with patch numbering/dating. The date-based naming scheme has one advantage and two disadvantages, aside from purely personal feelings about it. A1. It is easier to tell whether a site is fairly current or badly out of date based on a glance at the name of its latest patch, if they have been reasonably regular. This is occasionally useful. D1. You cannot predict the name of a patch from the name of the previous patch. This can be troublesome when dealing with poorly-run software archives, which let you retrieve files but won't give you a list of available files. D2. You cannot tell which patches precede today's patch without looking at the patch (which contains a complete list), whereas with numbered patches you just look at the names. This strikes me as a minor nuisance. People who moan that they can't tell which old patches they need don't seem to ever have *looked* at one of our patches. In short, to put it bluntly, we think most of the arguments advanced against dated patches are spurious claptrap from people with blind bias against the idea, presumably because of its unfamiliarity. The real advantages and disadvantages -- see list above -- don't seem to point strongly either way. The balance is perhaps slightly against dating, but hardly strong enough to justify the vehement outpourings on the subject and the tendency to blame it for all C News's ills. If there are other solid reasons for going one way or the other -- mind you, I'm talking about numbering vs. dating, not about patch frequency or people who won't apply patches or people who want a magic way to tell whether they are up to date -- I'd be interested to hear them. -- TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology OSI: handling yesterday's loads someday| henry@zoo.toronto.edu utzoo!henry
src@scuzzy.in-berlin.de (Heiko Blume) (09/20/90)
lmb@vicom.com (Larry Blair) writes: >I'll bet the reason >this time will be "It's too late to change." it's never too late! :-) by *posting* a cnews realease 1.0 and starting to call the patch files patch1 instead of ptch!@#(@!)something (:-) {which shouldn't be too hard in the first place} he peobably would also save him from answering lots of mails/articles about what patches have been issued etc pepe. he'd also make the life of source archivers (like me) much easier. >One of the statements that Henry has made repeatedly is that C News not >supposed to be the universal news transport system. The fact is that more >and more sites are switching to C News and the refusal to accept the problems >generated by C News are propogating. My favorites are: exceedingly long >message id's, accepting of old news with no check, and insufficient logging >for statistics generation. there are no problems -- only solutions :-) >I think that Henry and Geoff need to accept that fact that their software, in >the absence of anything better, is becoming the net standard and act in a >manor that is responsible and consistent with the rest of the net. The time >has come for normal patch levels and reasonable message id's. yeah! apart from that i think that cnews is quite sophisticated and when the bug regarding old news is fixed, anybody should be quite happy with it! (i and many other people are already, i bet!) -- Heiko Blume c/o Diakite blume@scuzzy.in-berlin.de FAX (+49 30) 882 50 65 Kottbusser Damm 28 blume@scuzzy.mbx.sub.org VOICE (+49 30) 691 88 93 D-1000 Berlin 61 blume@netmbx.de TELEX 184174 intro d scuzzy Any ACU,e 19200 6919520 ogin:--ogin: nuucp ssword: nuucp
src@scuzzy.in-berlin.de (Heiko Blume) (09/20/90)
louie@sayshell.umd.edu (Louis A. Mamakos) writes: >Er, excuse me, but did Henry and Geoff come visit your site and force >you to install C news on your system? THEY wrote the software, THEY >made it available for YOU to use for FREE, and you demand that they >act in a "responsible" manner? sure, you're right, but if you feed seven or more sites all.all you don't have much options left, given the increasing traffic... besides, i think everybody appreciates their work, and we're just suggesting something. we can't force them. if they say 'we won't do it, eat you heart out' (:-), well, i'll still use cnews and try to keep up with the patches. while i'm at it: thank for the great software Henry and Geoff! -- Heiko Blume c/o Diakite blume@scuzzy.in-berlin.de FAX (+49 30) 882 50 65 Kottbusser Damm 28 blume@scuzzy.mbx.sub.org VOICE (+49 30) 691 88 93 D-1000 Berlin 61 blume@netmbx.de TELEX 184174 intro d scuzzy Any ACU,e 19200 6919520 ogin:--ogin: nuucp ssword: nuucp
tneff@bfmny0.BFM.COM (Tom Neff) (09/20/90)
In article <1990Sep18.222450.25228@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >One of the reasons why we're reluctant to change our patch scheme is pure >spleen against people who appear to be blindly prejudiced against it, as >shown by the silly reasons they advance. Hmm... ad hominem software engineering. Surely its own reward... -- "Do you realize the responsibility I carry? %\%\ Tom Neff I'm the only thing standing between \%\% tneff@bfmny0.BFM.COM Nixon and the White House." -- JFK, 1960 %\%\ uunet!bfmny0!tneff
jeras@oracle.oracle.com (John Eras) (09/20/90)
>>...Their software has caused my site and the rest of the net >>considerable grief due to the (now fixed) inews -C bug and the overly long >>message id's (which broke rn). This is whether I run C News or 2.11. The >>problem with their patch scheme is that many admins are unsure if it is safe >>to apply a patch or if they are up to date ... > >One of the reasons why we're reluctant to change our patch scheme is pure >spleen against people who appear to be blindly prejudiced against it, as >shown by the silly reasons they advance. > >[... blah blah blah, lots of talk about numbered vs. dated patches ...] > >If there are other solid reasons for going one way or the other -- mind >you, I'm talking about numbering vs. dating, not about patch frequency >or people who won't apply patches or people who want a magic way to tell >whether they are up to date -- I'd be interested to hear them. Not that this particularly affects me, but how about patches that are both numbered *and* dated? Wow! The best of both worlds... Or am I just being a bonehead? ----------------------- (: smile! you're on usenet! :) ------------------------ AT: jeras@oracle.com | "It's a terrible waste BANG: ...{pacbell,hplabs,apple,decwrl}!oracle!jeras | to lose one's .sig, or FLAME: /dev/null (nyuk, nyuk) | not to have one at all."
jfh@rpp386.cactus.org (John F. Haugh II) (09/20/90)
In article <1990Sep18.222450.25228@zoo.toronto.edu>, henry@zoo.toronto.edu (Henry Spencer) writes: > If there are other solid reasons for going one way or the other -- mind > you, I'm talking about numbering vs. dating, not about patch frequency > or people who won't apply patches or people who want a magic way to tell > whether they are up to date -- I'd be interested to hear them. i know better than to get involved in this ... i see the problem as being similiar to the source code groups complaints about posting README's at the head of a submission versus at the end or in the middle, etc. the amount of information conveyed by numbered patches is greater than that for dated patches. both dates and numbers are sequential. july always follows june, just as 7 always follows 6. yet there are no numbers intervening 6 and 7, unlike jun-01-90 and jul-31-90. thus, there is more information contained in the statement "this is patch #7" than in "this is patch jul-31-90". you might argue that the date "jul-31-90" conveys the additional information that this patch is recent, therefore you have the most recent patch. by way of counterargument, consider the warren tucker shar which only recently went from version 3.43 to 3.49. the date says nothing - in the case of wt-shar, 6 weeks is an eternity, in the life of something more reasonable, 6 weeks is just yesterday. the same is true for patch numbers - early releases of perl started out with 20+ patches. the current release of sc is like patchlevel 2 or 3 or something small. so the numbers provide no additional information either. that date patches require a complete enumeration of all preceeding patches is a serious detractor. numbered patches have no such requirement - quick - list all the prerequisites for patch #7. now do the same for patch jul-31-90. this alone suffices to convince me that numbered patches are more simple and concise, and IMHO ;-), superior ... -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org "SCCS, the source motel! Programs check in and never check out!" -- Ken Thompson
drew@lethe.uucp (Drew Sullivan) (09/20/90)
In article <1990Sep18.222450.25228@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >- How do you know whether it is safe to apply a C News patch? Well, how do > you know if it is safe to apply a B News patch? Numbering/dating has > nothing to do with it. > >- How do you know whether you have the latest C News patch? Well, how do > you know whether you have the latest B News patch? Numbering/dating has > nothing to do with it. Actually, dating is probably ahead here, since > if you have last February's patch, you might suspect you are behind, > while having patch 12 tells you nothing of the kind. That is why you need both dates and numbers. >The date-based naming scheme has one advantage and two disadvantages, aside >from purely personal feelings about it. When updating a release, I look at both the patch and the patchlevel.h file. What would be best is to have both a number and a date beside the number in the patchlevel file. (PATCHDATES for cnews fans) a new version of PATCHDATES that would be better is -------------------------------------------------------------------- Release Date Notes for Cnews 0 23-Jun-1989 1 7-Jul-1989 2 23-Jul-1989 3 22-Aug-1989 4 24-Aug-1989 5 14-Sep-1989 6 13-Nov-1989 7 10-Jan-1990 8 16-Jan-1990 9 17-Jan-1990 10 18-Jan-1990 11 12-Mar-1990 12 14-Apr-1990 13 15-Apr-1990 14 16-Apr-1990 15 25-May-1990 16 1-Sep-1990 17 7-Sep-1990 (16+17 must be applied together) -------------------------------------------------------------------- In this way you can tell both how old the software, how current it is and if all of the patches have been applied and that no lines have been lost from the patchlevel file. -- -- Drew Sullivan, <drew@lethe.uucp>
dean@coplex.UUCP (Dean Brooks) (09/20/90)
henry@zoo.toronto.edu (Henry Spencer) writes: >One of the reasons why we're reluctant to change our patch scheme is pure >spleen against people who appear to be blindly prejudiced against it, as >shown by the silly reasons they advance. >- How do you know whether you have the latest C News patch? Well, how do > you know whether you have the latest B News patch? Numbering/dating has > nothing to do with it. Actually, dating is probably ahead here, since > if you have last February's patch, you might suspect you are behind, > while having patch 12 tells you nothing of the kind. What? You are kidding right? >D1. You cannot predict the name of a patch from the name of the previous > patch. This can be troublesome when dealing with poorly-run > software archives, which let you retrieve files but won't give > you a list of available files. The truth of the matter is that a large number of archives are not complete. Since C-News hasn't been posted netwide in quite a while, most people are relying on archives when upgrading to C-News from B. In addition, the lXsXXarge number of patches becomes a problem as there is no way of knowing
lishka@uwslh.slh.wisc.edu (a.k.a. Chri) (09/20/90)
henry@zoo.toronto.edu (Henry Spencer) writes: >In short, to put it bluntly, we think most of the arguments advanced >against dated patches are spurious claptrap from people with blind bias >against the idea, presumably because of its unfamiliarity. The real >advantages and disadvantages -- see list above -- don't seem to point >strongly either way. The balance is perhaps slightly against dating, >but hardly strong enough to justify the vehement outpourings on the >subject and the tendency to blame it for all C News's ills. I haven't been following this discussion, so forgive me if this has been mentioned before. A really simple fix that would provide the advantages of both schemes while getting rid of the disadvantages would be to name the patches with a date *and* a number. That way, everyone is at least somewhat satisfied and noone can really complain. For example, the patch name might look something like: #35-Sep-20-1990 Then again, I don't see any real reason to change the patch names. I happen to *like* the date-as-name idea myself. And, as Henry said, the entire patch list for the current version is always included in the patch. Complaining about patch naming schemes seems like more effort than it is really worth. But then again maybe I am missing something here. .oO Chris Oo. -- Christopher Lishka 608-262-4485 "Dad, don't give in to mob mentality!" Wisconsin State Lab. of Hygiene -- Bart Simpson lishka@uwslh.slh.wisc.edu "I'm not, Son. I'm jumping on the bandwagon." uunet!uwvax!uwslh!lishka -- Homer Simpson
henry@zoo.toronto.edu (Henry Spencer) (09/21/90)
I wrote: >If there are other solid reasons for going one way or the other -- mind >you, I'm talking about numbering vs. dating, not about patch frequency >or people who won't apply patches or people who want a magic way to tell >whether they are up to date -- I'd be interested to hear them. Several people have pointed out one issue, which isn't *precisely* an argument one way or the other but is an annoying problem: the suggested naming convention in our patches is badly chosen and consequently the patches are hard to sort into chronological order. I may have overlooked this partly because I almost never type "ls -l" any more -- I have a shell function that does "ls -ltr", which I find a far more useful order than alphabetical. This does depend on some circumstances that don't necessarily apply to users on other machines picking up patches, however. -- TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology OSI: handling yesterday's loads someday| henry@zoo.toronto.edu utzoo!henry
src@scuzzy.in-berlin.de (Heiko Blume) (09/21/90)
henry@zoo.toronto.edu (Henry Spencer) writes: >In <1990Sep13.203645.12937@scuzzy.mbx.sub.org> (Heiko Blume {me}) writes: >>since cnews has become really stable, i would suggest posting the >>whole thing soon. that would also be an opportunity to start using >>release numbers and patchlevel.h etc... >Actually, the relative stability over the summer has been more a matter >of lack of time than lack of changes to make. Expect more patches this >fall. ah, everything's relative :-) however i'd like to mention that at least two major sites here (feeding some dozen systems) run really smooth with cnews, especially because of the *great* space checking / queuing features! >At some decidedly ill-defined point, we plan what we're currently calling >the "cleanup release". This probably *will* appear in its entirety, for >a fairly fundamental reason. Patches are very awkward for dealing with >certain kinds of changes, like moving files around, and the list of things >needing such reorganization is growing. This will also simplify a few >relatively drastic changes that might cause very bloated patches, e.g. >the new inews. Given the reasons for the cleanup release, it will and >must be a break with continuity: there will be no patches to bring an >old system up to it. well, thanks for clearing this up, i think this answers many questions. i look forward to it! >Please do not ask when the cleanup release will be, because we don't >have a date for it. It won't be next week and probably won't be next >month; I don't recommend delaying conversions and/or updates in hopes >that it will soon appear. you'll be ready with it when you're ready with it :-) like with the GNU stuff, i think most people agree, it's much better to wait (and patch :-) until the authors think it's 'perfect' rather than pressing for some beta/pre-release. thanks for this great piece of software ! -- Heiko Blume c/o Diakite blume@scuzzy.in-berlin.de FAX (+49 30) 882 50 65 Kottbusser Damm 28 blume@scuzzy.mbx.sub.org VOICE (+49 30) 691 88 93 D-1000 Berlin 61 blume@netmbx.de TELEX 184174 intro d scuzzy Any ACU,e 19200 6919520 ogin:--ogin: nuucp ssword: nuucp
wayne@dsndata.uucp (Wayne Schlitt) (09/21/90)
In article <18549@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes:
<
< i know better than to get involved in this ...
[ but does anyway ... ]
<
< both dates and numbers are sequential. july always follows june, just
< as 7 always follows 6. yet there are no numbers intervening 6 and 7,
< unlike jun-01-90 and jul-31-90. thus, there is more information
< contained in the statement "this is patch #7" than in "this is patch
< jul-31-90".
well, the obvious solution to this problem is to simply release one
patch per day. :->
-waynejeff@onion.pdx.com (Jeff Beadles) (09/22/90)
henry@zoo.toronto.edu (Henry Spencer) writes: >If there are other solid reasons for going one way or the other -- mind >you, I'm talking about numbering vs. dating, not about patch frequency >or people who won't apply patches or people who want a magic way to tell >whether they are up to date -- I'd be interested to hear them. Howabout a compromise of both sides --- "C news patch 12 of 7-Sep-1990" This will allow both the date of the patch, and the sequence number. I do think that it's easier to tell if I have all of the patches by looking at the sequence numbers, rather than trying to figure out which came where, etc. Just another idea, -Jeff Jeff Beadles jeff@onion.pdx.com
src@scuzzy.in-berlin.de (Heiko Blume) (09/23/90)
sigh, if we all had long filenames we could call the patches something like 'cnews-patch#23.date:12-Nov-1990'. so let's blame at&t :-) -- Heiko Blume c/o Diakite blume@scuzzy.in-berlin.de FAX (+49 30) 882 50 65 Kottbusser Damm 28 blume@scuzzy.mbx.sub.org VOICE (+49 30) 691 88 93 D-1000 Berlin 61 blume@netmbx.de TELEX 184174 intro d scuzzy Any ACU,e 19200 6919520 ogin:--ogin: nuucp ssword: nuucp
anton@bkj386.uucp (Anton Aylward) (09/26/90)
Henry: Who pays you ? What do they pay you to do ? Does anyone pay you for the explicit purpose of maintaining software, writing library modules that are AT&T compatible but outside the copyright ? Have you received any recompense specificly rleated to CNews ? How much time do you devote per week/month to Cnews, and the other things you contribute to the net? Can you ask Geoff the same questions please. Thanks. (remind me I owe you lunch next time we meet) /anton aylward Analysis Synthesis Consulting Inc. anton@analsyn.uucp "Proud to know Henry"
henry@zoo.toronto.edu (Henry Spencer) (09/28/90)
In article <1990Sep26.010953.6109@bkj386.uucp> anton@analsyn.UUCP writes: > Who pays you ? U of Toronto, more specifically its Zoology department. > What do they pay you to do ? Run their computer facilities, and help departmental users of those and other computer facilities. > Does anyone pay you for the explicit purpose of maintaining > software, writing library modules that are AT&T compatible but > outside the copyright ? Only insofar as it aids the above, which means pretty rarely. > Have you received any recompense specificly rleated to CNews ? Let's see, grateful users bought me dinner once. :-) More seriously, some of the early work on C News was "official" because B News was killing our machines and we needed something better. Now that it is running satisfactorily here, it's rare for C News work to be job-related in any way that would justify spending much time on it. > How much time do you devote per week/month to Cnews, > and the other things you contribute to the net? Difficult to say. Probably several hours a week. > Can you ask Geoff the same questions please. Not really necessary, the answers will be pretty similar. -- TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology OSI: handling yesterday's loads someday| henry@zoo.toronto.edu utzoo!henry
heiser@tdw201.ed.ray.com (10/10/90)
In article <1990Sep18.222450.25228@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
This entire thread is, IMHO, really ridiculous. I wish people would stop
arguing about what the patches should be NAMED, and let the CNEWS people
concentrate on doing whatever needs to be done to CNEWS! The way people
are bickering about the patch naming convention makes it seem more appropriate
for alt.flame than for news.*
Now for something a little more constructive:
I recently got CNEWS running on an Esix sytem (with some help from several
people who had previously done the same thing). The package installed smoothly
except for problems with one file -- spacefor. If the cnews people are
interested, I will send you (the file, diffs, or whatever format you like)
showing what has to be done to make it work on Esix. This would be useful
to others (if incorporated in the cnews package).
(or maybe not enough people use Esix to warrant this??)
--
Work: heiser@tdw201.ed.ray.com
{decuac,necntc,uunet}!rayssd!tdw201!heiser
Home: bill%unixland.uucp@world.std.com -or- uunet!world!unixland!bill
Public Access Unix (508)655-3848 [Online but under construction]
Other: heiser@world.std.com (Public Access Unix)mjr@hussar.dco.dec.com (Marcus J. Ranum) (10/10/90)
In article <2704@sud509.ed.ray.com> heiser@tdw201.ed.ray.com writes: >[...] The package installed smoothly >except for problems with one file -- spacefor. Speaking of which, has anyone hacked the code from nntpd that reads free space out of the superblock and made a replacement for spacefor ? If anyone has, I'll be happy to test it under a few versions of Ultrix. :) mjr.
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (10/10/90)
>>[...] The package installed smoothly >>except for problems with one file -- spacefor. > > Speaking of which, has anyone hacked the code from nntpd that reads >free space out of the superblock and made a replacement for spacefor ? If >anyone has, I'll be happy to test it under a few versions of Ultrix. :) Not quite what you wanted, but this might work work. Actually, I find this spacefor more portable (and much faster) than the cnews version. /* Spacefor.c V1.1 Replacement for spacefor (shell script) in cnews. Change the values below as appropriate. Denny Page July 25, 1989 (denny@mcmi.uucp) BSD added by Jon Zeeff (zeeff@b-tech.ann-arbor.mi.us) About how many things of $1 bytes will fit in the available space for stuff of type $2 ("incoming", "articles", "control", "outbound $3", or "archive") without cramping things too badly? */ #define HAVE_STATFS /* If you have statfs() syscall */ #define BSD /* define on bsd sites */ #define BLOCKSIZE 1024 /* try 512 for Sys V and 1024 for bsd */ /* Make these the mount points */ #define DIR_INCOMING "/news" #define DIR_ARTS "/news" #define DIR_NEWSCTL "/u" #define DIR_OUTGOING "/u" #define DIR_ARCHIVE "/news" #define MIN_INCOMING 400 #define MIN_ARTS 400 #define MIN_NEWSCTL 3000 #define MIN_OUTGOING 400 #define MIN_ARCHIVE 400 /***************************************************************************/ #include <sys/types.h> #include <stdio.h> #ifndef BSD #ifdef HAVE_STATFS #include <sys/statfs.h> #define FREEBLOCKS statfsb.f_bfree #define FREENODES statfsb.f_ffree struct statfs statfsb; #else /* HAVE_STATFS */ #include <sys/stat.h> #include <ustat.h> #define FREEBLOCKS ustatb.f_tfree #define FREENODES ustatb.f_tinode struct stat statb; struct ustat ustatb; #endif /* HAVE_STATFS */ #else #define HAVE_STATFS #include <sys/vfs.h> struct statfs statfsb; #define FREEBLOCKS statfsb.f_bavail #define FREENODES statfsb.f_ffree #endif main(argc, argv) int argc; char **argv; { long size, minblocks, available, atol(); char *dirname; if (argc < 3) { fprintf(stderr, "usage: %s size place\n", argv[0]); exit(2); } if ((size = atol(argv[1])) == 0) { printf("10000\n"); exit(0); } if (! strcmp (argv[2], "incoming")) { dirname = DIR_INCOMING; minblocks = MIN_INCOMING; } else if (! strcmp (argv[2], "articles")) { dirname = DIR_ARTS; minblocks = MIN_ARTS; } else if (! strcmp (argv[2], "control")) { dirname = DIR_NEWSCTL; minblocks = MIN_NEWSCTL; } else if (! strcmp (argv[2], "outbound")) { dirname = DIR_OUTGOING; minblocks = MIN_OUTGOING; } else if (! strcmp (argv[2], "archive")) { dirname = DIR_ARCHIVE; minblocks = MIN_ARCHIVE; } else { fprintf(stderr, "%s: bad argument type `%s'\n", argv[0], argv[2]); exit(2); } #ifdef HAVE_STATFS if (statfs(dirname, &statfsb, sizeof(statfsb), 0) != 0) { perror("statfs failed"); exit(1); } #else /* HAVE_STATFS */ if (stat(dirname, &statb) != 0) { perror("stat failed"); exit(1); } if (ustat(statb.st_dev, &ustatb) != 0) { perror("ustat failed"); exit(1); } #endif /* HAVE_STATFS */ available = ((FREEBLOCKS - minblocks) * BLOCKSIZE) / size; if (available <= 0 || FREENODES == 0) available = 0; if (available > 10000) available = 10000; printf("%ld\n", available); exit(0); } -- Jon Zeeff (NIC handle JZ) zeeff@b-tech.ann-arbor.mi.us
henry@zoo.toronto.edu (Henry Spencer) (10/11/90)
In article <2704@sud509.ed.ray.com> heiser@tdw201.ed.ray.com writes: >... problems with one file -- spacefor. If the cnews people are >interested, I will send you (the file, diffs, or whatever format you like) >showing what has to be done to make it work on Esix... Actually, I now count spacefor as a failed approach, and am in the early stages of doing something better. The problem is that there is far too much senseless diversity in df output format, much more than I thought in my young and innocent days. :-) In the works is a version that puts the actual space-finding in C, using the two or three different flavors of how-much-space-is-there system calls, but keeps the choice of threshold out of the C code so it's easy to change. It's tricky to get all this right, especially with a df-based fallback for really old systems, but I think I know how to do it, and it should be significantly less hassle than relying on df. Sigh. -- Imagine life with OS/360 the standard | Henry Spencer at U of Toronto Zoology operating system. Now think about X. | henry@zoo.toronto.edu utzoo!henry