Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!teknowledge-vaxc!mwolf
From: mw...@teknowledge-vaxc.ARPA (Michael Wolf)
Newsgroups: news.software.b
Subject: Where does cnews live?
Message-ID: <28272@teknowledge-vaxc.ARPA>
Date: 6 Aug 89 09:29:48 GMT
Reply-To: mw...@Teknowledge.COM (Michael Wolf)
Distribution: usa
Organization: CIMFLEX Teknowledge, Inc., Palo Alto CA
Lines: 7
I notice that there seem to be a fair number of patches for
cnews. Is there an anonymous ftp site that is the designated
archive site for cnews? I'd like to be able to keep up to
date on any additions/bug fixes.
Michael Wolf
mw...@Teknowledge.COM
Newsgroups: news.software.b
Path: utzoo!henry
From: he...@utzoo.uucp (Henry Spencer)
Subject: Re: Where does cnews live?
Message-ID: <1989Aug7.195904.13429@utzoo.uucp>
Organization: U of Toronto Zoology
References: <28272@teknowledge-vaxc.ARPA>
Date: Mon, 7 Aug 89 19:59:04 GMT
In article <28...@teknowledge-vaxc.ARPA> mw...@Teknowledge.COM (Michael Wolf) writes:
>I notice that there seem to be a fair number of patches for
>cnews. Is there an anonymous ftp site that is the designated
>archive site for cnews?...
Well, I'm not sure 3 qualifies as "a fair number" -- unless you're counting
unofficial patches from others -- but admittedly there is a need for making
the patches available from archives. The full set of official patches to
date has been sent to the comp.sources.unix archive sites, and should be
available from them shortly. Future official patches will be sent there
at the same time as they are posted.
--
1961-1969: 8 years of Apollo. | Henry Spencer at U of Toronto Zoology
1969-1989: 20 years of nothing.| uunet!attcan!utzoo!henry he...@zoo.toronto.edu
Path: utzoo!utgpu!watmath!iuvax!purdue!ames!vsi1!lmb
From: l...@vicom.com (Larry Blair)
Newsgroups: news.software.b
Subject: Re: Where does cnews live?
Message-ID: <1989Aug8.170802.20975@vicom.com>
Date: 8 Aug 89 17:08:02 GMT
References: <28272@teknowledge-vaxc.ARPA> <1989Aug7.195904.13429@utzoo.uucp>
Reply-To: l...@vicom.COM (Larry Blair)
Organization: VICOM Systems Inc., San Jose, CA
Lines: 22
In article <1989Aug7.195904.13...@utzoo.uucp> he...@utzoo.uucp (Henry Spencer) writes:
=In article <28...@teknowledge-vaxc.ARPA> mw...@Teknowledge.COM (Michael Wolf) writes:
=>I notice that there seem to be a fair number of patches for
=>cnews. Is there an anonymous ftp site that is the designated
=>archive site for cnews?...
=
=Well, I'm not sure 3 qualifies as "a fair number" -- unless you're counting
=unofficial patches from others -- but admittedly there is a need for making
=the patches available from archives. The full set of official patches to
=date has been sent to the comp.sources.unix archive sites, and should be
=available from them shortly. Future official patches will be sent there
=at the same time as they are posted.
Which brings us back to the issue of patch numbering. If the patches for
C News were numbered like every other piece of net.software, we would
know that there were only 3 and we would know if we had missed any.
I still don't understand what the problem with the conventional numbering
is. It is not to late to change. Is this just a case of NIH?
--
Larry Blair ames!vsi1!lmb l...@vicom.com
Newsgroups: news.software.b
Path: utzoo!henry
From: he...@utzoo.uucp (Henry Spencer)
Subject: Re: Where does cnews live?
Message-ID: <1989Aug9.164003.20669@utzoo.uucp>
Organization: U of Toronto Zoology
References: <28272@teknowledge-vaxc.ARPA> <1989Aug7.195904.13429@utzoo.uucp> <1989Aug8.170802.20975@vicom.com>
Date: Wed, 9 Aug 89 16:40:03 GMT
In article <1989Aug8.170802.20...@vicom.com> l...@vicom.COM (Larry Blair) writes:
>Which brings us back to the issue of patch numbering. If the patches for
>C News were numbered like every other piece of net.software, we would
>know that there were only 3 and we would know if we had missed any.
Oh, nonsense. If they were numbered, you'd be asking what the latest
number was. This way, if the patch is dated yesterday, you have pretty
considerable confidence that you are current.
And to find out whether you've missed any, you simply look at the list
of prerequisite patches that is in *every* patch. (I agree this would
get unwieldy if there were 57 of them, but there won't be.)
>I still don't understand what the problem with the conventional numbering
>is. It is not to late to change. Is this just a case of NIH?
No, it's a case of NLH (Not Liked Here), plus an interest in finding out
whether an alternative would work. I must say, if we'd anticipated that
there would be this much mindless whining about it, we might have thought
twice about the experiment... I would welcome *carefully thought out*
comments on it, but please stop nattering about how it's not what you're
used to and therefore it must be bad. I thought about this scheme at
some length, and so far *nobody* has come up with an argument that I
didn't think of in advance. I still feel that (a) the problems are
nowhere near as serious as claimed, and (b) it works about as well when
you think about it. Patch numbers make it easier to list all the patches
that preceded a given one; that is their sole advantage. Patch dates
tell you how current the latest patch is; that is their major advantage.
In either case, the missing information can be had by referring to the
text of the patch itself, if it's built properly (and ours are).
We may change if it becomes clear that the date-based scheme is causing
more problems than it solves. So far I see little evidence for this.
Convincing us is going to require good arguments, not endless repetition
of poor ones.
--
1961-1969: 8 years of Apollo. | Henry Spencer at U of Toronto Zoology
1969-1989: 20 years of nothing.| uunet!attcan!utzoo!henry he...@zoo.toronto.edu
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!ukma!rutgers!dayton!jad
From: j...@dayton.UUCP (J. Deters)
Newsgroups: news.software.b
Subject: Re: Patch dates or Patch Numbers
Summary: Patch Numbers. Definitely.
Message-ID: <6717@dayton.UUCP>
Date: 16 Aug 89 22:42:47 GMT
References: <1989Aug9.164003.20669@utzoo.uucp>
Reply-To: j...@dayton.UUCP (J. Deters)
Organization: Terrapin Transit Authority
Lines: 57
In article <1989Aug9.164003.20...@utzoo.uucp> he...@utzoo.uucp (Henry Spencer) writes:
>more problems than it solves. So far I see little evidence for this.
>Convincing us is going to require good arguments, not endless repetition
>of poor ones.
A correctly used patch system will need numbers. Not want. Need.
If you want to know where your program is in relation to the patch you have,
a system of Release.Revision.PatchLevel is almost mandatory. Dates hide
the history of the code without substantial digging into documentation.
I'd hate to have to go through the posting to find the README file that
has a list of release dates and changes to find that I missed a release
somewhere, when it is intuitively obvious that 5.4.1 is 4 releases higher
than my current 1.3.6. :-) This also tells me that many things such as
file layouts, etc. have probably changed since I put my code in, while
5.5 probably will drop right on top of 5.4.6 without my worrying about it.
You may think that the general public knows enough about your code to know
that you put in a widget-seeking algorithm that restructures your save file
when you went from 5/21/86-3 to 7/01/86, but it's not obvious by looking
at those dates. 3.7.6 to 4.0 kind of stands out as a warning.
Set it up so that if a Release comes out, you know to dump any source code
you have and re-install the new source. If a Revision comes out, you know
that you can apply it to ANY previously applied Revisions to this release.
Cumulative patches in the Revisions make life easier for the installers.
You don't have to waste hundreds, if not thousands of net.dollars posting
messages like "Can somebody send me foobar 12/15/88? I have foobar
12/01/88 but I just received foobar patch 12/15/88 patch 1"
Instead, you *know* that foobar 3.2 can be applied to foobar 3.0.
If a PatchLevel comes out, you must apply it to the appropriate Release
and Revision, but you may or may not need previous PatchLevels depending
on your philosophy of distribution. I personally prefer cumulative patches,
such that 3.2.1 is not a pre-requisite to installing 3.2.2, but for net
distribution I will concede that diff's to previous PatchLevels are smaller,
and therefore more acceptable. You then automatically know that you
will need to find 3.2.1 and 3.2.2 before you can apply 3.2.3 to your copy
of 3.2. You also know that if you can't get 3.2, you may as well hit the
'n' key.
Dates are worthless unless you like to issue full releases every time
somebody thinks adding a couple of widget keys would be neat-o. If you
miss just one non-cumulative patch, you're hosed. (You're hosed in the
PatchLevel situation described above, too, but at least you know it. :-)
Having cumulative Revisions keeps the full-source releases down. Date-based
patch identification prevents using an intelligent system. And adding a
revision into the middle of the ID such as mm/dd/yy-rev-patch is just
another way of restating the above while still hiding the history of the code.
I realize that this may require the distributor and/or author of changes
to code to actually keep track of what's been done. At least everyone
who receives the code won't have to have perfect memories.
-j
--
J. Deters - j...@dayton.DHDSC.MN.ORG j...@jaded.DHDSC.MN.ORG
Newsgroups: news.software.b
Path: utzoo!henry
From: he...@utzoo.uucp (Henry Spencer)
Subject: Re: Patch dates or Patch Numbers
Message-ID: <1989Aug17.171000.23302@utzoo.uucp>
Organization: U of Toronto Zoology
References: <1989Aug9.164003.20669@utzoo.uucp> <6717@dayton.UUCP>
Date: Thu, 17 Aug 89 17:10:00 GMT
In article <6...@dayton.UUCP> j...@dayton.UUCP (J. Deters) writes:
>A correctly used patch system will need numbers. Not want. Need.
>If you want to know where your program is in relation to the patch you have,
>a system of Release.Revision.PatchLevel is almost mandatory...
Assuming that you are talking about one of those pieces of, uh, software
that is constantly changing, with bales of new features and swarms of
new bugs regularly showing up. My opinion of such mushware is very low
indeed; Geoff's opinion is unprintable.
Particularly for the news transport subsystem, where specs are quite solidly
fixed by backward-compatibility constraints, we see no fundamental reason
why a well-written piece of software cannot stabilize fairly quickly and
then remain essentially unaltered unless and until it is replaced by a
complete rewrite on radically different principles. This is the model
we are working towards: software, not mushware. We may not achieve it,
but we are determined to try. (Indeed, we are not interested in trying
the alternative.)
--
V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology
1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry he...@zoo.toronto.edu
Path: utzoo!attcan!uunet!rick
From: r...@uunet.UU.NET (Rick Adams)
Newsgroups: news.software.b
Subject: Re: Patch dates or Patch Numbers
Message-ID: <64033@uunet.UU.NET>
Date: 17 Aug 89 21:28:59 GMT
References: <1989Aug9.164003.20669@utzoo.uucp> <6717@dayton.UUCP> <1989Aug17.171000.23302@utzoo.uucp>
Organization: UUNET Communications Services, Falls Church, VA
Lines: 9
In article <1989Aug17.171000.23...@utzoo.uucp>, he...@utzoo.uucp (Henry Spencer) writes:
> Particularly for the news transport subsystem, where specs are quite solidly
> fixed by backward-compatibility constraints, we see no fundamental reason
No matter what one thinks of Cnews, it is is not backward-compatible.
Cnews is another transport system (just like notes is). it may be
better or worse, but it clearly paid no attention to backwards
compatibility.
Newsgroups: news.software.b
Path: utzoo!utstat!geoff
From: ge...@utstat.uucp (Geoff Collyer)
Subject: C news compatibility (was Re: Patch dates or Patch Numbers)
Message-ID: <1989Aug18.102335.17269@utstat.uucp>
Organization: Statistics, U. of Toronto
References: <1989Aug9.164003.20669@utzoo.uucp> <6717@dayton.UUCP> <1989Aug17.171000.23302@utzoo.uucp> <64033@uunet.UU.NET>
Date: Fri, 18 Aug 89 10:23:35 GMT
Rick Adams:
>Cnews [sic] is another transport system (just like notes is). it may be
>better or worse, but it clearly paid no attention to backwards
>compatibility.
Nonsense. C news meets the specification for message format in RFC
1036 and provides a compatible interface to the newsreaders (e.g. the
active file, stored articles and silly options to inews); our sys file
is compatible with the B 2.11 one except for a few obsolete options for
multicasting (see our batcher) and unbatched ihave/sendme. News
administration differs somewhat from B news, but the C news rules are
documented and easy to learn. We exchange news with B news sites and
have run vanilla news readers like readnews, rn and nn locally.
--
Geoff Collyer utzoo!utstat!geoff, ge...@utstat.toronto.edu
Path: utzoo!attcan!utgpu!watmath!iuvax!mailrus!sharkey!itivax!scs
From: s...@itivax.iti.org (Steve Simmons)
Newsgroups: news.software.b
Subject: Re: Patch dates or Patch Numbers
Message-ID: <2876@itivax.iti.org>
Date: 18 Aug 89 12:51:00 GMT
References: <1989Aug9.164003.20669@utzoo.uucp> <6717@dayton.UUCP> <1989Aug17.171000.23302@utzoo.uucp>
Organization: Industrial Technology Institute, Ann Arbor, MI.
Lines: 46
he...@utzoo.uucp (Henry Spencer) writes:
>In article <6...@dayton.UUCP> j...@dayton.UUCP (J. Deters) writes:
>>A correctly used patch system will need numbers. Not want. Need.
>>If you want to know where your program is in relation to the patch you have,
>>a system of Release.Revision.PatchLevel is almost mandatory...
>Assuming that you are talking about one of those pieces of, uh, software
>that is constantly changing, with bales of new features and swarms of
>new bugs regularly showing up. My opinion of such mushware is very low
>indeed; Geoff's opinion is unprintable.
>. . . we see no fundamental reason
>why a well-written piece of software cannot stabilize fairly quickly and
>then remain essentially unaltered unless and until it is replaced by a
>complete rewrite on radically different principles. This is the model
>we are working towards: software, not mushware. We may not achieve it,
>but we are determined to try. (Indeed, we are not interested in trying
>the alternative.)
Sorry for the long requote, but given the response I'm about to make it
seemed only fair.
Henry, your response in no way addresses the request. Deters (and I,
in seperate mail) have both stated that a patch numbering system in
less ambiguous than your date-oriented system. While I salute your
efforts towards quality software (and would even say you're succeeding)
your responses to this issue have (a) not addressed it and (b) verged
on . . . ah . . . emotional. I realize you are not trying to be insulting,
but a response laden with terms like "mushware" and "unprintable" would
lead the casual reader to assume you are applying those terms to the
feature (patch numbering) being requested.
The main virtues of patch numbering are twofold: First, they give an
absolutely unambiguous way of telling you how many patches must be
obtained. By contract, patch dating can lead one into a cycle of
not being quite sure one has the previous patches (one gets the june 17
patch only to discover you now need the june 2 patch. get that, only to
find you now need the april 1 patch. i realize you don't put out a lot
of patches. your posting/patching frequency is irrelevant to the quality
of number vs. date as a methodology). Second, patch numbers are easier
to remember. One simple number, rather than a date.
--
Steve Simmons s...@vax3.iti.org
Industrial Technology Institute Ann Arbor, MI.
"Velveeta -- the Spam of Cheeses!" -- Uncle Bonsai
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!rick
From: r...@uunet.UU.NET (Rick Adams)
Newsgroups: news.software.b
Subject: Re: C news compatibility (was Re: Patch dates or Patch Numbers)
Summary: nonsense
Message-ID: <64125@uunet.UU.NET>
Date: 18 Aug 89 20:18:32 GMT
References: <1989Aug9.164003.20669@utzoo.uucp> <6717@dayton.UUCP> <1989Aug18.102335.17269@utstat.uucp>
Organization: UUNET Communications Services, Falls Church, VA
Lines: 21
nonsense. The RFC was an attempt to document the behavior of Bnews.
(The rfc is 4 years old and out of date.) Where the RFC and Bnews differ the
behavior of Bnews should generall be considered correct.
To me (and just about everyone else) backwards compatible means behaves
the same as Bnews. As I said before, your wrote something compatilble
with the the RFC, so your have developed a new transport. It is
not backwards compatible with Bnews.
You are doing everyone a great disservice claiming that it is
backwards compatible. Anyone who has tried to use Cnews will tell
you that it is not.
Note the argument is not better or worse, but compatible vs. incompatible.
Cnews chose to have serveral incompatible (and wrong in my opinion)
differences with Bnews. Fine. Just dont claim to be backwards compatible.
Dont rationalize your decisions by referring to the RFC. If you
were concerned about backwards compatibility, then you would have
paid attention to current behavior of the commonly used program
that defines the behavior that everyone expects.
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!fletcher
From: fletc...@cs.utexas.edu (Fletcher Mattox)
Newsgroups: news.software.b
Subject: Re: C news compatibility (was Re: Patch dates or Patch Numbers)
Message-ID: <6722@cs.utexas.edu>
Date: 18 Aug 89 20:57:02 GMT
References: <1989Aug9.164003.20669@utzoo.uucp> <6717@dayton.UUCP> <1989Aug17.171000.23302@utzoo.uucp> <64033@uunet.UU.NET> <1989Aug18.102335.17269@utstat.uucp>
Organization: U. Texas CS Dept., Austin, Texas
Lines: 4
If C news is backward compatible with B news, then why do I have to
have to modify NNTP to work with with C news?
Fletcher
Newsgroups: news.software.b
Path: utzoo!utstat!geoff
From: ge...@utstat.uucp (Geoff Collyer)
Subject: Re: C news compatibility (was Re: Patch dates or Patch Numbers)
Message-ID: <1989Aug19.004434.29961@utstat.uucp>
Organization: Statistics, U. of Toronto
References: <1989Aug9.164003.20669@utzoo.uucp> <6717@dayton.UUCP> <1989Aug18.102335.17269@utstat.uucp> <64125@uunet.UU.NET>
Date: Sat, 19 Aug 89 00:44:34 GMT
Rick Adams:
> (The rfc is 4 years old and out of date.)
My copy of RFC 1036 is dated December 1987, so I make it 1.67 years old.
> Where the RFC and Bnews differ the behavior of Bnews should generall be
> considered correct.
Henry and I do not buy this argument. The behaviour of B news does not
make a de facto standard.
> To me (and just about everyone else) backwards compatible means behaves
> the same as Bnews.
Perhaps we are not speaking the same language. My OED says
``compatible a. Consistent, able to coexist, (with); mutually
tolerant; (of equipment etc.) able to be used in combination''. I
don't see any meaning which implies cloning. C news is not a clone of
B news. People who want a clone should get B news; it's a clone of B
news.
> your wrote something compatilble with the the RFC, so your have developed
> a new transport. It is not backwards compatible with Bnews.
And where is C news incompatible with the message format of B news?
Our users seem to be exchanging news with B news sites just fine.
> You are doing everyone a great disservice claiming that it is
> backwards compatible. Anyone who has tried to use Cnews will tell
> you that it is not.
We have had letters from many satisfied users of C news; no one (other
than you) who has actually used C news claims that it is incompatible
with B news.
> Cnews chose to have serveral incompatible (and wrong in my opinion)
> differences with Bnews.
Again, what are they? We haven't seen them.
> If you were concerned about backwards compatibility, then you would have
> paid attention to current behavior of the commonly used program
> that defines the behavior that everyone expects.
We have no interoperability problems.
Fletcher Mattox:
> If C news is backward compatible with B news, then why do I have to
> have to modify NNTP to work with C news?
In general, you don't have to; you can continue to suffer horrible
performance. The two things you do need to compensate for are that B
news changed its mind about case sensitivity of Message-IDs and C news
uses the B 2.10.1 interpretation (case insensitive), and that NNTP
relies on an implementation detail, the format of the second field of
the history file (which B news changed its mind about; NNTP wants the B
2.11 format), so we provide a minor change to nntp/server/newnews.c to
understand the C news format.
--
Geoff Collyer utzoo!utstat!geoff, ge...@utstat.toronto.edu
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!cs.utexas.edu!uunet!rick
From: r...@uunet.UU.NET (Rick Adams)
Newsgroups: news.software.b
Subject: Re: C news compatibility (was Re: Patch dates or Patch Numbers)
Message-ID: <64167@uunet.UU.NET>
Date: 19 Aug 89 04:12:12 GMT
References: <1989Aug9.164003.20669@utzoo.uucp> <6717@dayton.UUCP> <1989Aug19.004434.29961@utstat.uucp>
Organization: UUNET Communications Services, Falls Church, VA
Lines: 124
Summary: reaching
In article <1989Aug19.004434.29...@utstat.uucp>, ge...@utstat.uucp (Geoff Collyer) writes:
> Rick Adams:
> > (The rfc is 4 years old and out of date.)
>
> My copy of RFC 1036 is dated December 1987, so I make it 1.67 years old.
However, the text of the rfc was frozen and sent to Postel the summer
of 1986. It took him well over a year to "release" is as an RFC. This
is also why no on has bothered to do an update. The text of the
RFC is basically 1985 with minor changes in early 1986.
(SCCS logs support this.)
If I buy a copy of Robinson Crusoe that has a 1985 printing date on it,
I dont claim the book is only 4 years old. The date on the
RFC is the printing date, not the date of the information.
>
> > Where the RFC and Bnews differ the behavior of Bnews should generall be
> > considered correct.
>
> Henry and I do not buy this argument. The behaviour of B news does not
> make a de facto standard.
WRONG. Pull your dictionary out again. Something is a de facto standard
when the vast majority of sites comply with it. Since the
vast majority of sites run Bnews, they can be said to comply with it.
You are thinking of de jure standard, which is is not.
>
> > To me (and just about everyone else) backwards compatible means behaves
> > the same as Bnews.
>
> Perhaps we are not speaking the same language. My OED says
> ``compatible a. Consistent, able to coexist, (with); mutually
> tolerant; (of equipment etc.) able to be used in combination''. I
> don't see any meaning which implies cloning. C news is not a clone of
> B news. People who want a clone should get B news; it's a clone of B
> news.
Who cares about the definition of compatible. What does the OED say
about backwards compatible.
Something is backwards compatible when you can replace an older system
with it and things keep running.
If you could remove all of the Bnews executables and replace them
with Cnews and the system kept running, then it would be backwards
compatible. Clearly you can not do that. Therefore, clearly it is not backwards
compatible.
>
> > your wrote something compatilble with the the RFC, so your have developed
> > a new transport. It is not backwards compatible with Bnews.
>
> And where is C news incompatible with the message format of B news?
> Our users seem to be exchanging news with B news sites just fine.
No one is arguing about the message format. Notes files exchange
articles with Bnews sites too. Would you claim they are backwards
compatible. The notes people wouldn't. They also wouldn't care.
>
> > You are doing everyone a great disservice claiming that it is
> > backwards compatible. Anyone who has tried to use Cnews will tell
> > you that it is not.
>
> We have had letters from many satisfied users of C news; no one (other
> than you) who has actually used C news claims that it is incompatible
> with B news.
Ask them. EVERYONE I have talked to has said it is not backwards compatible.
God, look at all the patches for nntp compatibility, etc.
Interoperable hsa nothing to do with backwards compatibility.
> > Cnews chose to have serveral incompatible (and wrong in my opinion)
> > differences with Bnews.
Messageids are case independant. Period. You intentionally ignore it
with some sleazy rationalization about its not being in the RFC.
The RFC is wrong. My name is on the RFC. I think that lets me
say with some authority whether the RFC is wrong or not.
> Again, what are they? We haven't seen them.
>
> > If you were concerned about backwards compatibility, then you would have
> > paid attention to current behavior of the commonly used program
> > that defines the behavior that everyone expects.
>
> We have no interoperability problems.
Damn it, try having the same conversation as I do. No one has
said it does not interoperate. It does. So does Notes. However
Cnews is not backwards compatible with Bnews. Interoperability has
nothing to do with backwards compatibility.
>
>
> Fletcher Mattox:
> > If C news is backward compatible with B news, then why do I have to
> > have to modify NNTP to work with C news?
>
> In general, you don't have to; you can continue to suffer horrible
> performance. The two things you do need to compensate for are that B
> news changed its mind about case sensitivity of Message-IDs and C news
> uses the B 2.10.1 interpretation (case insensitive), and that NNTP
> relies on an implementation detail, the format of the second field of
> the history file (which B news changed its mind about; NNTP wants the B
> 2.11 format), so we provide a minor change to nntp/server/newnews.c to
> understand the C news format.
Jesus. Would you drop your damned "bnews sucks" campaign. Bnews
fixed a bug in the early code that didnt ignore case. it didn't
"change its mind" B 2.10.1 is BROKEN. Basing Cnews on 5 or 6
year old code was just plain stupid. Would you write a unix and
base it on Version 7 and claim it was backwards compatible with
System 5? Of course not, people would laugh at you. This situation
is similar.
Your last sentence says it all. Backwards compatible programs
DO pay attention to implementation details. Thats what backwards
compatible means.
Why dont you just admit that you did a better, but non-backwards compatible
implementation? There is nothing wrong with that.
--rick
Path: utzoo!attcan!uunet!rick
From: r...@uunet.UU.NET (Rick Adams)
Newsgroups: news.software.b
Subject: Re: C news compatibility (was Re: Patch dates or Patch Numbers)
Summary: conflicts
Message-ID: <64229@uunet.UU.NET>
Date: 19 Aug 89 16:17:06 GMT
References: <1989Aug9.164003.20669@utzoo.uucp> <6717@dayton.UUCP> <3536@epimass.EPI.COM>
Organization: UUNET Communications Services, Falls Church, VA
Lines: 9
Yes Bnews has bugs. no doubt about it.
My point is that blindly relying on the rfc is not good. blindly
relying on a particular piece of code is not good.
If you discover a case that the RFC doesnt fully handle or that
differs from the bnews code, ASK someone what the intent was. Dont
go your own way.
Newsgroups: news.software.b
Path: utzoo!henry
From: he...@utzoo.uucp (Henry Spencer)
Subject: Re: Patch dates or Patch Numbers
Message-ID: <1989Aug19.215016.23031@utzoo.uucp>
Organization: U of Toronto Zoology
References: <1989Aug9.164003.20669@utzoo.uucp> <6717@dayton.UUCP> <1989Aug17.171000.23302@utzoo.uucp> <2876@itivax.iti.org>
Date: Sat, 19 Aug 89 21:50:16 GMT
In article <2...@itivax.iti.org> s...@itivax.iti.org (Steve Simmons) writes:
>... i realize you don't put out a lot
>of patches. your posting/patching frequency is irrelevant to the quality
>of number vs. date as a methodology)...
Ah, but this is exactly my point: it's not. The difference between the
various bookkeeping systems becomes significant only for large numbers
of patches. We hope to solve the how-to-track-lots-of-patches problem
by avoiding it entirely. If there are only a handful of patches, it just
doesn't matter that much.
--
V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology
1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry he...@zoo.toronto.edu
Newsgroups: news.software.b
Path: utzoo!henry
From: he...@utzoo.uucp (Henry Spencer)
Subject: Re: C news compatibility (was Re: Patch dates or Patch Numbers)
Message-ID: <1989Aug19.223016.23702@utzoo.uucp>
Organization: U of Toronto Zoology
References: <1989Aug9.164003.20669@utzoo.uucp> <6717@dayton.UUCP> <1989Aug18.102335.17269@utstat.uucp> <64125@uunet.UU.NET>
Date: Sat, 19 Aug 89 22:30:16 GMT
In article <64...@uunet.UU.NET> r...@uunet.UU.NET (Rick Adams) writes:
>... The RFC was an attempt to document the behavior of Bnews.
That is its origin. However, it does not say "this is the standard for the
behavior of B News", it says "this is the standard for news transmission".
And it does say "standard". Definitions of the C language started out more
or less as documentation of the behavior of Dennis Ritchie's C compiler, but
these days the compilers are written to match the standards, not vice versa.
Same thing for RFC1036: its flaws and origin notwithstanding, it is written
as an implementation-independent standard for news transmission, and we treat
it as such.
>... Where the RFC and Bnews differ the
>behavior of Bnews should generall be considered correct.
Um, considered by who? This is like AT&T saying "where POSIX and System V
differ, the behavior of System V should be considered correct". The older
documents that POSIX is derived from did originate as an attempt to document
the behavior of System V, but these days the standard is the primary document.
RFC1036 says it is the standard; we believe it.
On a more pragmatic note, there are a couple of very serious problems with
taking B News's behavior as the standard. One is that it's a moving target:
B2.11 differs from B2.10.1 in important ways. (Some of the B2.11 <-> C News
differences arise because some of C News predates 2.11.) Another is that
finding out what that behavior *is* can be very difficult. Geoff had to
resort to the B News code to figure out ihave/sendme, since RFC1036's
description is simply inadequate. It took him a long time. The groaning,
swearing, and complaining were something to hear. The B News code is not
practical as a standards document.
>To me (and just about everyone else) backwards compatible means behaves
>the same as Bnews...
As I've said in another article, there is more than one aspect of
compatibility involved here, and we are backward compatible in most of
the ones that matter to most people.
>You are doing everyone a great disservice claiming that it is
>backwards compatible. Anyone who has tried to use Cnews will tell
>you that it is not.
Many people who have tried, and succeeded, and continued using it, tell
us that it is.
Rick, you have some special problems, given the enormous size of your
sys file and your complex administrative situation. We recognize this,
and in the past have offered to help (specifically, to take a look at
your sys file and shell programs for compatibility problems). But most
sites do not have the problems you have with even the slightest change
to the sysadmin interface, and find C News's major-although-imperfect
backward compatibility adequate for their purposes.
--
V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology
1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry he...@zoo.toronto.edu
Newsgroups: news.software.b
Path: utzoo!henry
From: he...@utzoo.uucp (Henry Spencer)
Subject: Re: C news compatibility (was Re: Patch dates or Patch Numbers)
Message-ID: <1989Aug19.225027.24194@utzoo.uucp>
Organization: U of Toronto Zoology
References: <1989Aug9.164003.20669@utzoo.uucp> <6717@dayton.UUCP> <1989Aug19.004434.29961@utstat.uucp> <64167@uunet.UU.NET>
Date: Sat, 19 Aug 89 22:50:27 GMT
In article <64...@uunet.UU.NET> r...@uunet.UU.NET (Rick Adams) writes:
>Something is backwards compatible when you can replace an older system
>with it and things keep running.
Quite a few older systems have been replaced by C News, and Usenet is
still running fine. When people replace B2.nn with C News, their news
readers keep running. (In fact, utzoo ran B New's readnews until about
a year ago.) Sounds backwards compatible to me.
>If you could remove all of the Bnews executables and replace them
>with Cnews and the system kept running, then it would be backwards
>compatible. Clearly you can not do that. Therefore, clearly it is not backwards
>compatible.
Of course, when one replaced the B2.10.1 executables with B2.11 ones,
duplicate-article rejection broke until all the old entries got expired
out of the history file, because of the change to message-id case policy.
That being a rather serious matter for many sites, clearly B2.11 was not
backwards compatible with B2.10.1, by your reasoning. (*Why* it was
done is irrelevant, by your own definition.)
>Messageids are case independant. Period. You intentionally ignore it
>with some sleazy rationalization about its not being in the RFC.
We ignore it because the specifications say it's not true. The matter
very definitely is in RFC822. RFC1036 says 822 dominates in the event
of dispute, and on this issue there isn't even a dispute, since 1036 is
silent on the matter.
(Actually, we agree that the wording about 822 dominating needs to be
revised, since taken literally it invalidates most of 1036, but here
there can be little doubt about what the current specs say.)
>The RFC is wrong. My name is on the RFC. I think that lets me
>say with some authority whether the RFC is wrong or not.
No argument. However, it begs the question: what's right? Dennis
Ritchie considers C bitfields "a botch and a blemish" (his exact words),
but I trust you would not buy a C compiler that therefore left them out.
Dennis no longer sets the standard for C; B2.11 and its maintainer no
longer set the standard for news. In both cases, the standard is set
by a consensus document, not by a man ("government of laws, not men").
When the documents are wrong, eventually they get revised, but until
then, they are the best standard we've got and the proper basis for
a new implementation.
--
V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology
1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry he...@zoo.toronto.edu
Path: gmdzi!unido!mcvax!uunet!ginosko!usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!gryphon!desint!geoff
From: ge...@desint.UUCP (Geoff Kuenning)
Newsgroups: news.software.b
Subject: Re: Patch dates or Patch Numbers
Message-ID: <173@desint.UUCP>
Date: 20 Aug 89 08:51:17 GMT
References: <1989Aug17.171000.23302@utzoo.uucp> <2876@itivax.iti.org> <1989Aug19.215016.23031@utzoo.uucp>
Reply-To: ge...@desint.UUCP (Geoff Kuenning)
Organization: Interrupt Technology Corp., Manhattan Beach, CA
Lines: 48
Posted: Sun Aug 20 09:51:17 1989
In article <1989Aug19.215016.23...@utzoo.uucp> he...@utzoo.uucp (Henry Spencer) writes:
> Ah, but this is exactly my point: it's not. The difference between the
> various bookkeeping systems becomes significant only for large numbers
> of patches. We hope to solve the how-to-track-lots-of-patches problem
> by avoiding it entirely. If there are only a handful of patches, it just
> doesn't matter that much.
Henry, you don't exactly strike me as wet behind the ears. I'm pretty sure
that you were on the net before I was, and I'm also pretty sure I've seen
you write about your memories of computing in the 60's. Even if my memory
is wrong, it's rather clear from years of watching your postings that you're
no fool. While I am less familiar with Geoff's work, I think I can safely
assume that he, too, reaches far beyond mere competence in his chosen field.
Why, then, is it that you take such a wet-behind-the-ears attitude towards
the bugs in and the longevity of your own software? Surely you've heard
the saying, "there is no such thing as a bug-free program?" Surely you've
dealt with other people's software for long enough to realize that even
widely-respected software by widely-respected programmers has lots of bugs
that require corrections?
Computers have existed for almost 45 years now, and certain things have
been learned during that time. One of the lessons is that maintenance
is an unfortunate reality, and smart people plan for many years of
maintenance.
C news is certain to exist for many years. Neither Henry nor Geoff is
even vaguely stupid (hell, Geoff even spells his name correctly :-). So
why not study the maintenance lessons that others have struggled so
painfully to learn? Five years from now, whether the total number of
C news patches is 3 or 45, people will have a much easier time keeping
track of the patches if they are numbered and handled professionally.
Climb down off your arrogant pedestals, Henry and Geoff. The reality
is that you are not the only superb programmers in the world. If you
learn from the lessons of other superb programmers, you will look less
foolish in a few years. Check out Knuth's article in the July '89 SP&E
on bugs in TeX (I'm presuming you accept my premise that Knuth is no idiot,
either).
And face the truth: well-designed maintenance is superior to
poorly-designed maintenance, regardless of how much is required. Why,
when you have put so much effort into good design of your software, do
you think it is an advantage to be deliberately sloppy about maintenance?
Shoddiness is shoddiness, regardless of where it is found.
--
Geoff Kuenning ge...@ITcorp.com uunet!desint!geoff
Newsgroups: news.software.b
Path: utzoo!henry
From: he...@utzoo.uucp (Henry Spencer)
Subject: Re: Patch dates or Patch Numbers
Message-ID: <1989Aug21.173144.7327@utzoo.uucp>
Organization: U of Toronto Zoology
References: <1989Aug17.171000.23302@utzoo.uucp> <2876@itivax.iti.org> <1989Aug19.215016.23031@utzoo.uucp> <173@desint.UUCP>
Date: Mon, 21 Aug 89 17:31:44 GMT
In article <1...@desint.UUCP> ge...@desint.UUCP (Geoff Kuenning) writes:
>And face the truth: well-designed maintenance is superior to
>poorly-designed maintenance, regardless of how much is required. Why,
>when you have put so much effort into good design of your software, do
>you think it is an advantage to be deliberately sloppy about maintenance?
The key disagreement here is that we do not consider our scheme poorly-
designed or sloppy. Different, yes. And we admit that we consider it
experimental. For various reasons, however, we like it and want to give
it a serious trial.
To reiterate: We are interested in hearing about any serious non-obvious
problems with our scheme. We are not interested in hearing repeatedly about
the obvious ones; we feel, at this time, that it has enough advantages to
counterbalance them. We are not interested in hearing how silly we are not
to have thought of the obvious problems; we *have* thought of them. We are
not interested in reading long explanations of how we're being silly, or of
how it's sinful and unprofessional to do things in unusual ways; we disagree.
At the very least, if people *must* repeat all the arguments we've already
seen 57 times, after having thought of them ourselves beforehand anyway,
we urge that it be done by private mail and *not* by further postings to
this newsgroup. It's really getting boring and tedious, guys. If you must
inflict it on us, at least have the decency not to inflict it on others.
--
V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology
1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry he...@zoo.toronto.edu
|