C News patch of 7-Sep-1990
Henry Spencer
henry at zoo.toronto.edu
Wed Sep 19 08:24:50 AEST 1990
In article <1990Sep17.210150.1586 at vicom.com> lmb at 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 at zoo.toronto.edu utzoo!henry
More information about the Comp.sources.bugs
mailing list