HDTenEightyP/NetNews huggingface dataset:
From: koenig@nova.tat.physik.uni-tuebingen.de (Harald Koenig)
Subject: Wanted: xntp for linux (standalone and/or network) and DCF-77 driver
Organization: TAT (Theoretical Astrophysics Tuebingen), U. of Tuebingen, FRG
Date: Wed, 16 Dec 1992 12:48:45 GMT

Has anyone ported xntp (or ntp) to linux?

What's about the adjtime system call (all UNIX variants exept HPUX
have such a feature)?

Has anyone written a driver for a DCF-77 receiver (second pulses
connected to a serial line reading puls length as 50 baud characters)?

Thanks,
Harald
--
Harald Koenig, Inst.f.Theoret.Astrophysik  (koenig@tat.physik.uni-tuebingen.de)
		"#define no_bdev_def()	dev_disk_init(0)"
 Congratulations!  If AT&T wins its suit against BSDI, you've guaranteed that
  you can never write OS software again, just by reading the previous line!
From: Mills@UDEL.EDU
Newsgroups: comp.protocols.time.ntp
Subject: xntp3 distribution update
Date: 15 Dec 92 17:47:30 GMT
Distribution: inet
Organization: The Internet

Folks,

The file pub/ntp/xntp3.tar.Z on louie.udel.edu contains the latest
batch of patches received from the faithful. The changes are mostly
fixing portability problems.

There remains a known bug with the local-clock option, where no
radio is available and an isolated local net wants to elect one
host its de facto source. It has been reported that the non-electees
in this case refuse to follow the elected host. I do not have the
time or resources at this time to follow this up, but would be glad
to incorporate patches should another soldier bare arms.

Dave
From: Mills@UDEL.EDU
Newsgroups: comp.protocols.time.ntp
Subject: Re:  assistance for selecting a peer..
Date: 14 Dec 92 05:08:52 GMT
Distribution: inet
Organization: The Internet

Sanjay,

First, let me suggest you use xntp3 instead of ntpd on your principal
server, as this version is much more robust in the face of likely
congestion on your access paths to extra-national primary servers.
A couple of years back I was the guest of IIT Bombay on behalf the
UN Development Program, so I have some idea of what you are up 
against. While I don't know the present access path, presumably
via your ERNET headquarters in Bombay, I suggest you run the
traceroute program to find out the particular route and inspect the
file clock.txt in the pub/ntp/doc directory fia anonymous ftp on
host louie.udel.edu for likely candidates. The complete distribution
of ntpd, xntp3 and related programs reside in the pub/ntp directory
and subdirectories on that host.

Please understand the robustness of time distribution depends critically
on redundancy and diversity, which means you need redundant servers
and diverse access paths to multiple servers "closer" to the primary
source of synchronization. The last time I visited India you had only
one access path. Even in that case you should consider multiple
NTP servers for your country. In view of the low network overhead of
xntp3, you might consider each of your four sites as redundant and
have them each peer with outside reference sources and with each
other. See the various information files in the pub/ntp/doc directory
and in the xntp3 distribution.

There is documentation on the tickadj program in the xntp3 distribution.
You need to specify a tick paramter of 9999 for those Sun platforms
known to me. There are example configuration files in the distribution
as well.

In your part of the world, the only precision time signals suitable
for connection to a computer are from the Global Position Service
satellites, which require a most expensive receiver, and the OMEGA
radioonavigation system (receiver made by TrueTime - see clock.txt),
which is only slightly less outrageous. There is a driver for the
OMEGA receiver in the xntp3 distribution (same as the GOES receiver).
I challenge an enterprising grad student to cobble up a receiver
for the BBC on-hour pips, which are I am told derived from precision
sources and readily receivable in your country. With propagation
corrections and selection of only the domestic UK transmitters, you
could realize a quite accurate national time source.

Dave
From: eric@mks.com (Eric Gisin)
Newsgroups: comp.std.unix
Subject: pathconf _PC_PATH_MAX
Date: 18 Dec 1992 02:40:10 -0800
Organization: UUNET Communications
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: eric@mks.com (Eric Gisin)

On a system with a defined, constant value for PATH_MAX,
what would pathconf("/tmp", _PC_PATH_MAX) return?
The books I have, Zlotnick and O'Reilly, say PATH_MAX-4.
The systems I have say PATH_MAX.
Who is right? If it is PATH_MAX-4, how would fpathconf work?

I have not seen a POSIX.1 interpretation on this. Is there one?

	Eric Gisin, Mortice Kern Systems.


Volume-Number: Volume 29, Number 82
From: alvin@eyepoint.com (Alvin Starr)
Newsgroups: comp.std.unix
Subject: Re: POSIX == SVID?
Date: 13 Dec 1992 13:43:23 -0800
Organization: eyepoint
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: alvin@eyepoint.com (Alvin Starr)

psm@nosc.mil (Scot Mcintosh) writes:

>A document I'm reading makes the following statement:
>"POSIXS compliance shall be met via adherence to the
>System V Interface Definition (SVID) for Release 4 of
>Unix." I infer from this that the writer thinks that
>SVIDR4 and POSIX will be the same from the point of 
>view of the application. Will that actually be the 
>case?

SVIDR4 may be a superset of POSIX.1(I am not sure that V.4 will pass
FIPS PCTS as it comes out of the box from USL) but V.4 is not
conformant to POSIX.(2,4...) Various other vendors with propritary OS's
are POSIX compatable without being at all compatable with SVID.

So it is unadvisable to concider SVID and POSIX to be the same.
-- 
Alvin Starr                   ||   voice: (416)513-6717
Eyepoint Inc.                 ||   fax:   (416)513-6718
alvin@eyepoint.com            ||


Volume-Number: Volume 29, Number 79
From: karish@pangea.Stanford.EDU (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re: POSIX == SVID?
Date: 18 Dec 1992 02:39:23 -0800
Organization: Mindcraft, Inc.
NNTP-Posting-Host: ftp.uu.net
Summary: SVR4
X-Submissions: std-unix@uunet.uu.net

Submitted-by: karish@pangea.Stanford.EDU (Chuck Karish)

In article <1ggaprINNkl9@ftp.UU.NET> alvin@eyepoint.com (Alvin Starr) writes:

>SVIDR4 may be a superset of POSIX.1(I am not sure that V.4 will pass
>FIPS PCTS as it comes out of the box from USL) [ ... ]

I'm sure.  It's been certified on a number of platforms,
including the AT&T 6386/25 WGS that sat on my desk for
a while last year.  The certificate is NIST reference
number USL3610.
--

    Chuck Karish          karish@mindcraft.com
    (415) 323-9000 x117   karish@pangea.stanford.edu


[ If people would consider it a valuble service, I would be willing to
  keep a list of systems that have passed various test suites -- mod ]

Volume-Number: Volume 29, Number 81
From: djb@cbosgd.att.com (David J Bryant)
Newsgroups: comp.std.unix
Subject: Re: POSIX == SVID?
Date: 13 Dec 1992 13:41:42 -0800
Organization: AT&T Bell Laboratories, Columbus Ohio
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: djb@cbosgd.att.com (David J Bryant)

Regarding "POSIX == SVID?", sp@osf.org (Simon Patience) wrote:
  
  > What OSF does with the AES is to make it a superset of standards like
  > POSIX, XPG etc, (assuming that conflicting standards don't prevent it).
  > I would guess that USL does the same with SVID. This means that if you
  > are AES (or SVID) compliant you are therefore also POSIX (or XPG, etc) 
  > compliant automatically.

To my knowledge, this is not true for SVID3.  Being SVID3 compliant does not 
necessarily mean you are POSIX & XPG3 compliant.

For example, SVID3 specifies two different mechanisms for internationalized 
message handling, one based on catgets(), and one based on gettext().  I know
that catgets() is from XPG3, while gettext() is neither XPG3 or POSIX.
You must take care to select the "right" routines from SVID3 if you wish your
application to be XPG3 compliant as well.  I assume there are other examples
of this situation throughout SVID3.

I'd be interested in any comparative analysis of XPG3 (now XPG4), POSIX and
ANSI C that pointed out areas of conflict or incompatibility.  Maximal 
portability is important to my applications, and this kind of information would
certainly help out.

David Bryant
AT&T Bell Laboratories       djb@cborion.cb.att.com
Room 1B-256                            djb@cbosgd.att.com
6200 East Broad Street          PHONE: (614) 860-4516
Columbus, Ohio  43213             FAX: (614) 868-4302

Volume-Number: Volume 29, Number 78
From: ppan@nobeltech.se (Per Andersson)
Newsgroups: comp.std.internat,news.admin.misc
Subject: Re: 8-bit representation, plus an X problem
Date: 12 Dec 92 22:23:42 GMT
Organization: NobelTech AB

In article <kkZNVB5w165w@blues.kk.sub.org> kosta@blues.kk.sub.org (Kosta Kostis) writes:
>Yuk! Allthough I'm sitting in front of an IBM PC clone using
>IBM Code Page 850, I would never think of bothering the rest 
>of the world with characters between 128 and 159. That's why
>I convert between CP850 and ISO 8859-1.

At least you know that you are using codepage 850. Lots of people are
not aware that the IBM PC uses several codepages, and fidonet has to my
knowledge no handling of the different codepages, not to mention other
charactersets as Latin x ( I think Latin-1 exists as CP819 or something),
Unicode 1.1 or ISO10646. Also many people in fidonet, at least in sweden 
are not interested in interoperability, and could care less about the 
millions of users reachable on the Internet. Hopefully not all fidonet
users have this attitude.

/Per
-- 
-----------------------------------------------------------------------------
Per Andersson - ppan@nobeltech.se (perand@stacken.kth.se on free time)
Managing networks at, but not speaking for Nobeltech AB, J{rf{lla, Sweden
-----------------------------------------------------------------------------
Xref: sparky comp.std.internat:889 news.admin.misc:815
From: andersa@Riga.DoCS.UU.SE (Anders Andersson)
Newsgroups: comp.std.internat,news.admin.misc
Subject: Re: 8-bit news
Followup-To: comp.std.internat
Date: 17 Dec 1992 13:37:14 GMT
Organization: Uppsala University, Sweden
Distribution: world
NNTP-Posting-Host: riga.docs.uu.se

[note my Followup-To: comp.std.internat]

In article <CKD.92Dec16130204@loiosh.eff.org>, ckd@eff.org (Christopher Davis) writes:
>  VA> You don't send 8 bits to a site which does not understand it. It
>  VA> simply makes no sense -- they don't have appopriate fonts on their
>  VA> terminals anyway.
> 
> How do you know if arbitrary-site understands it or not?  YOU CAN'T.  And
> remember, the terminals may be several years newer than the mailhost.

Also, the terminals needn't be directly connected to the host,
or even owned by the same organization as the host (thus the
capabilities of the fancy terminal may have no relevance for, or
its owner may have no influence on, the gateway host software).
But everybody knows that... :-)

> MTAs are not MUAs.

...which is of course a more concise way to put it.  Thanks!

I'm personally not too bound to 8 bits as the ultimate data unit
size.  Today's efforts of 'stomping out' 7-bit transmission
channels for being obsolete in the presence of superior *8-bit*
channels (even as it's probably a good idea) may seem amusing
sometime in the future, when 8 bits have likewise been stomped
out in favour of 16 bits, or whatever is the fashion.  So, I
prefer not to be too quick labelling every 7-bit application as
'buggy' today, especially when they weren't yesterday.

What?  Are there *still* 8-bit processor architectures out there
in the suburbs? ;-)

What we really need is to separate the application issues from
the transport issues.  The application writer (or the user) need
not, and *should* not, care about how the lower layers of the
communication medium are implemented.  The user may have specific
demands in terms of speed and functionality, but it shouldn't
matter to me whether this article is transported via an 8-bit
channel, a 7-bit channel, a deck of punched cards on a jet plane
or whatever, if it just reaches its destination unmodified and
within reasonable time.  By allowing the lower layers to pick
any communication channel they like, the best performance is
achieved.  Ask DHL...

Haven't people studied the OSI network reference model?
--
Anders Andersson, Dept. of Computer Systems, Uppsala University
Paper Mail: Box 325, S-751 05 UPPSALA, Sweden
Phone: +46 18 183170   EMail: andersa@DoCS.UU.SE
Newsgroups: comp.std.internat,news.admin.misc
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: 8-bit news
Date: Sun, 13 Dec 1992 02:28:37 GMT
Organization: U of Toronto Zoology

In article <4yyNVB4w165w@blues.kk.sub.org> kosta@blues.kk.sub.org (Kosta Kostis) writes:
>There is no way to mandate updates especially if there is no "need"
>for that. As long as we don't use 8-bit, nobody will ever change
>"faulty" software.

There is no way to mandate updates net-wide.  Period.  That is a fact
of life, like it or not.  If you decide to just charge ahead, unless
you have enough administrative control to force updates -- possible for
cooperating subnets, but nobody has such control net-wide -- then you
will spend years answering complaints from people whose software breaks.
Even long after you'd think everybody would have fixed it.  Believe me;
we've seen this with C News.

>> It will not be possible to forget about the bit-handicapped until their
>> numbers are vanishingly small.  That won't happen soon.
>
>I don't agree. It depends on us. Since the intro of VT 2xx terminals
>in 1983 nine years went by and many people are already equiped with
>8-bit terminals and PCs, Macs, NeXTs, Workstations of various brands
>now. All these are capable of displaying 8-bit characters.

"What do you mean 'we', white man?" -- Tonto, as the Apaches charge him
and the Lone Ranger. :-)  I don't have such a terminal.  Are you going to
buy me one?

You're not addressing the issue.  In the first place, the question is
not whether lots of people have 8-bit terminals -- they do -- but whether
many of the potential readers *don't*.  In the second place, the real
issue is transmission paths, not terminals:  the reader software can
look after inadequate terminals, but if the data goes through a 7-bit
keyhole (NNTP!) before it gets to you, no amount of intelligence in your
terminal will fix that.

And in the third place, most important, you're confusing encoding with
content.  MIME provides ways, *today*, to encode 8-bit or 16-bit or
32-bit character codes as 7-bit data that will pass through any of
the current transmission paths unscathed.  There is no need to wait
for 8-bit transmission paths to start using ISO 8859-1 (or, preferably,
10646 -- 8-bit provincialism is no better than 7-bit provincialism).
-- 
"God willing... we shall return."       | Henry Spencer @ U of Toronto Zoology
       -Gene Cernan, the Moon, Dec 1972 |  henry@zoo.toronto.edu  utzoo!henry
Newsgroups: comp.std.internat,news.admin.misc
From: atkinson@itd.nrl.navy.mil (Randall Atkinson)
Subject: Re: 8-bit news
Organization: Naval Research Laboratory, DC
Date: Mon, 14 Dec 1992 16:20:23 GMT

In article <Bz18wz.55q@poel.juice.or.jp> erik@poel.juice.or.jp (Erik M. van der Poel) writes:

>Perhaps the best approach for the American community would be to avoid
>using the ESCAPE that is problematic in netnews and the 8th bit that
>is problematic in both email and netnews, and to use a Viet-like or
>Simonsen-like method, possibly together with an alt.chinese.text-like
>method.  (And this is what you've started doing, right, Steve?)

Erik,

  I hope you are really intending that we collectively move to some
MIME-derivative that can handle these existing interim formats, the
public non-standard formats you've mentioned, and also that will
handle the formats we should all be headed towards (namely ISO-8859-*
and ISO-10646) along with non-text encodings for GIF, TIFF, and audio.

Ran
atkinson@itd.nrl.navy.mil
Xref: sparky comp.std.internat:910 news.admin.misc:848
From: avg@rodan.UU.NET (Vadim Antonov)
Newsgroups: comp.std.internat,news.admin.misc
Subject: Re: 8-bit news
Date: 18 Dec 1992 16:10:59 -0500
Organization: UUNET Technologies Inc, Falls Church, VA
NNTP-Posting-Host: rodan.uu.net

In article <davecb.724685064@yorku.ca> davecb@nexus.yorku.ca (David Collier-Brown) writes:
>  SAML and SOML are underused on the internet, yet the equivalent
>on BITnet is heavily used....

The only problem it that BITNET is dying... (not exactly a problem, i'm very
glad than RJE and all that stuff becomes a matter of folklore).

talk is much better than SMTP's SEND anyway.

>  Don't take them out of the spec: you may want them later,and a standard
>way of doing them is desirable.

Nobody calls to change SMTP commands. All we need is to get rid of the
7-bit restriction.

>  VRFY is utterly necessary to postmasters, and is therefor mandated by the
>Hosts Requirements RFC: finger is shut down on all too many sites, and so
>vrfy/expn are required to verify adressees when mail goes astray.

MAIL/RCPT followed by QUIT works just as fine. VRFY and EXPN practically
never issued by software (though it can save some typing).

>  And HELO is the hook for stronger authentication: even now it and thge
>recieved lines allow me to spot (poorly-)forged mail at a glance.

It you need something even remotely resembling autentication you'd better
use DNS to get the name from peer's IP address. Any forger with IQ higher
than 50 can say HELO with anything he wants. As it is it's nothing more
than wasted bandwidth.

>(small flame)  If you've implemented smtp, you should really know all that...

Somehow my software (uumail/batchmail/newsserver/uucp line disc.) handles mail
and news on all backbones in ex-Soviet countries. And as i already said
the 8-bit problem was solved without adding ugly encodings to already
bloated software. Flame somebody else.

BTW, the central RELCOM backbone handling the number of links comparable with
UUNET's currently runs on a couple of uVAX-es III and few 486s. The "vanilla"
e-mail software is uttelrly sloppy and inefficient and we had to hack
it a lot (or sometimes to throw away and rewrite from scratch).

--vadim
Newsgroups: comp.std.internat,news.software.nn
From: atkinson@itd.nrl.navy.mil (Randall Atkinson)
Subject: Re: 8-bit anything?
Organization: Naval Research Laboratory, DC
Date: Tue, 15 Dec 1992 18:08:48 GMT

In article <BzAxzJ.7np@sci.kun.nl> lwj@cs.kun.nl (Luc Rooijakkers) writes:

>The next nn version will use MIME header tagging to indicate the
>character set used. It will actually refuse to post 8-bit characters
>without such headers (they will be added automatically if you tell
>nn what character set to use).

Great.  

  It would also be useful to mark the 7-bit characters as US-ASCII or
ISO-646-N or whatever they really are.  That way other news readers
would have a good chance at using the right glyph for the variant
characters.  (Not that I'd endorse using ISO-646-* if ISO-8859-* were
available on those systems, but there will be some 646-only terminals
and such for a while yet. :-)

>By the way, isn't it time to create a news.8bit group :-) This subject
>has been cropping up in lots of newsgroups during the last few weeks.

  Discussion seems to have settled down in comp.std.internat and I
don't see any particularly good reason to move it.  If it should move,
lets not use the term "8-bit" in the name since we're also trying to
support ISO-10646 and other wide character sets.  A name like
alt.usenet.mime might not be bad since the consensus appears to be
that some kind of MIME-derivative is the approach to adopt for USENET
news.

  I should mention that some freely distributable software (called
"metamail") that helps implement MIME support for email packages is
available by anonymous ftp from thumper.bellcore.com -- I'm sure the
Metamail package would be just as useful for newsreader software.

Ran
atkinson@itd.nrl.navy.mil
Xref: sparky comp.std.internat:861 news.admin.misc:769
From: henry@zoo.toronto.edu (Henry Spencer)
Newsgroups: comp.std.internat,news.admin.misc
Subject: Re: 8-bit news
Date: 15 Dec 92 23:15:12 GMT
Organization: U of Toronto Zoology

In article <BzBJIA.3AM@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
>>>   The second is to have a standard for marking the contents of
>>> messages in standard headers using standard syntax and standard
>>> tokens.  If I understand Henry correctly, he is putting together a
>>> draft, based on MIME, that addresses this second issue.
>
>>Didn't MIME specify some encodings already? And wasn't ISO 8859-1
>>the default for 8bit encoded text? (hm...)
>
>MIME only talked about Internet email, not news.  Henry's draft will
>apparently talk about news issues and so forth.

There is really precious little that is news-specific in this.  The one
thing that needs careful thought is adapting news to use of RFC-1342 for
encoding non-ASCII stuff in *headers*.  The MIME (RFC-1341) facilities
for use in the *body*, for stating which character set you are using and
encoding >7-bit sets to survive 7-bit transmission channels, appear to be
directly applicable without modification.  I'm debating how much detail
to include about them in the draft, but the bottom line will be "see MIME".
Almost everything in MIME has potential applications to news, and I don't
see any compelling reason to re-invent or re-specify it.
-- 
"God willing... we shall return."       | Henry Spencer @ U of Toronto Zoology
       -Gene Cernan, the Moon, Dec 1972 |  henry@zoo.toronto.edu  utzoo!henry
Xref: sparky comp.std.internat:866 news.admin.misc:777
From: avg@rodan.UU.NET (Vadim Antonov)
Newsgroups: comp.std.internat,news.admin.misc
Subject: Re: 8-bit news
Date: 15 Dec 1992 20:58:32 -0500
Organization: UUNET Technologies Inc, Falls Church, VA
NNTP-Posting-Host: rodan.uu.net

In article <BzBuoy.6MB@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
>  In many cases the vendor doesn't exist and source code isn't
>available and so it _cannot_ be fixed.  Also recall that USENET is
>transported over weird links, not just UUCP and NNTP.

Not really much -- can you recall such a link NOW?
It's plain stupid to make serious decisions affecting millions
of machines and use the buggy software as a rationale!

The following universal remedy will help:

	main(ac, av)
		char **av;
	{
		register c;
		FILE *of;
		char buf[10240]

		sprintf(buf, "rmail.buggy %s", av[1]);
		of = popen(buf, "w");
		while( (c = getchar()) != EOF )
			putc(c & 0177);
		pclose(of);
	}

(translate to YFPL).

>>"Just send 8 bits" *is* backward compatible. Check your logic.
>
>Nope.  With email will crash other folks' machines, which is at least
>highly anti-social and possibly down right malicious.  With news that
>same thing might happen.

Wake up. There ALREADY are 8-bit newsgroups distrtibuted in US.
Subscribe to relcom.* and see (available at most major gateways).

Anybody heard about epidemic host crashing recently?

Didn't you realize that we're talking about changing the standard
POST FACTUM?

>Many of the hosts in question _haven't_ upgraded their software in
>years because they cannot upgrade their software -- which is why there
>is _still_ a hosts.txt at nic.ddn.mil.

And what? Should we all follow that line? Where's my handy card
puncher?! What kind of hosts you're talking about? I understand
why people are reluctant to touch machines which launch missiles;
but, excuse me, it is not the kind of the stuff we're talking about.


--vadim
Newsgroups: comp.std.internat,news.admin.misc