geoff@utcs.uucp (Geoff Collyer) (11/08/85)
In article <677@decuac.UUCP> avolio@decuac.UUCP (Frederick M. Avolio) writes: > People are running versions of >news that are 3 years old and 3 versions old. (For example, by the >header I see that site bambi runs news 2.10.1 created on 6/24/83. >2.10.2 has been around for over a year now.) Software changes for >enforcement of rules will never work since there is no way to make >people install them. (People don't, even when there are free and >better versions available!) Sorry for the long inclusion, but these complaints are often heard from news gurus. Erik Fair recently said similar things. utcs and utcsstat are still running 2.10.1 and are likely to either keep running it, run Australian 2.10.1 news (by Michael Rourke) or run our own. [ We already run rn and Henry Spencer's expire, which doesn't have all the bells and gongs of the standard expire but runs *much* faster (it keeps the expiry time in the history file so it never has to open, stat or even access a file to determine whether to expire it or not) and regenerates the dbm history data base each time it runs. If Henry or I gets around to rewriting inews (or modifying Australian inews) so that it does its own unbatching without forking nor execing, I'd be glad to chuck B news into the trash. ] Let me tell you why I don't plan to upgrade our machines. I would be much more interested in running new versions of B news if I didn't have to regression test all the new sources against my sources to ensure that fixes that were posted to Usenet and mailed to the maintainers were *actually* incorporated into the latest version. We started out running 2.3 and upgraded pretty religously until 2.10.1. Around 2.8 or 2.9 I found a number of bugs, mailed & posted them and they weren't fixed in 2.10, so I mailed them to Mark Horton again and they weren't fixed in 2.10.1 (the ones that spring to mind are a bunch of unchecked fopens that can fail if your machine doesn't have a /usr/tmp, for example). Given that the news sources are big, I have no interest in regression testing new releases, and there really haven't been major improvements in news since 2.10.1 to act as a carrot. I keep hearing that 2.10.2 and the as-yet-unavailable 2.10.3 are vastly better written than previous versions of B news, but I don't have the energy to diff my current (much debugged) sources with new ones to verify that my fixes really got in. If a sufficiently large carrot (in the form of some vast new improvement) appears in a new news version, I might gather up the energy to diff versions, but if my fixes are *still* not in the new version I look at, I doubt very much that I'll ever do it again. Australian news is attractive because it is much better written that B news 2.10.1, changes infrequently (I know of only two versions: 1.0 and 1.1) and its source code is about 1/7th the size of the B news sources, so there is far less code to diff or fix. Incidentally, utzoo (a backbone site) is still running B news 2.10, except for Henry's completely new expire, even though backbones are supposed to run the latest and greatest B news code. I can fully understand why Henry hasn't upgraded. -- B news is Bad news.
dw@rocksvax.UUCP (Don Wegeng) (11/13/85)
A couple of years ago I was system manager of a PDP11/34 (rocks34). After
a lot of hacking I finally got news 2.9 to fit into the limited memory space
available on the 11/34. I can promise you that if rocks34 were still around it
would still be running news 2.9, for I wasn't about to go through the pain
of hacking another version to fit.
/Don
--
"To err is human - to blame someone else is even more human"
arpa: Wegeng.Henr@Xerox.ARPA
csnet: Wegeng.Henr@Xerox.ARPA
ns: dw:Wbst207V:Xerox
uucp: {amd,decvax!rochester,ihnp4,princeton}!rocksvax!dwgds@mit-eddie.UUCP (Greg Skinner) (11/17/85)
I am glad to see someone supporting the arguments against upgrading to
the latest and greatest versions of B news. Some people like Fred
Avolio and Erik Fair don't seem to understand that different computing
facilities have different needs, and as such the versions of news they
run will be different according to their needs.
If you are only responsible for one or two machines, it is simple enough
to coordinate the establishment of resources for upgrades to news. But
when it becomes upwards of 20 machines, you begin to have problems,
especially when these machines are of different cpu type, OS type, disk
technology (implying online disk storage) and play different roles.
At my previous job, we had a policy that a new piece of software could
not be installed on any of our machines unless it was installed on ALL
of our machines, and was made compatible with all the other machines.
All the quirks needed to be ironed out, so that if a user switched
machines (not uncommon in a rapidly changing environment), it would
appear to the user that he was using the same version of news. This
becomes especially difficult when most of these users are novices, and
need to be protected from quirks which experienced users know how to get
around.
I wanted to install a version of 2.10.2 made compatible for Sys V, but
was constrained by not having enough space on all the machines to
install it. I could not simply blow away other things on disk, because
the people on the machines needed them. This version of news was
specifically designed to provide me with automatic updates of the
executable, so it had to reside in specific directories. However,
because there wasn't enough space on all the machines, none of them could
be upgraded to 2.10.2.
In addition, we used to run the expire in 2.10, but found that it wasn't
getting rid of enough articles. We resorted to the "brute force" method
of expiring news, find /usr/spool/news -type f -mtime +7 -exec rm {}.
Crude, bit it did the job the provided source didn't do.
You see folks, certain sites have darn good reasons for running the versions
of news they do. As long as they are not polluting the net with incorrect-
ly formatted articles, or dropping news accidentally, they have every right to
run the version of news they want to. I agree that versions of notes that
generate "Orphaned Response" and don't do aliasing correctly should be fixed,
but any version of B news that does not muck up the headers or interfere
with transmission of articles has as micuh right being there as the latest
versions.
If you don't agree with me, then maybe you'd like to answer to my former
users, whenever they find a bug in 2.10.3beta, with a timely bug fix?
--
It's like a jungle sometimes, it makes me wonder how I keep from goin' under.
Greg Skinner (gregbo)
{decvax!genrad, allegra, ihnp4}!mit-eddie!gds
gds@mit-eddie.mit.eduavolio@decuac.UUCP (Frederick M. Avolio) (11/19/85)
In article <469@mit-eddie.UUCP>, gds@mit-eddie.UUCP (Greg Skinner) writes: > I am glad to see someone supporting the arguments against upgrading to > the latest and greatest versions of B news. Some people like Fred > Avolio and Erik Fair don't seem to understand that different computing > facilities have different needs, and as such the versions of news they > run will be different according to their needs. Ok. Now I understand. There are reasons why people cannot freely and automatically bring up new news versions at the drop of a hat. But some things can be fixed. An example -- at least one backbone site -- maybe more -- batch and compress news using the compact program rather than the compress program. Since compress makes sources smaller than compact and runs much faster, a change like that will cut down dramatically in cpu cylces used and time spent pushing news around. Which in itself is a reason why we cannot consider software "fixes" for an overloaded net (local distribution defaults, etc.). Why, some news software being run by backbone sites (and others, of course) cannot even properly handle the "Distribution: " field. -- Fred @ DEC Ultrix Applications Center {decvax,seismo,cbosgd}!decuac!avolio