Date: Thu, 7 Nov 1996 14:50:05 -0800 (PST) From: Martin Cracauer <cracauer@cons.org> To: freebsd-bugs Subject: Re: bin/1968: rdate(8) implementation (from NetBSD) Message-ID: <199611072250.OAA24781@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/1968; it has been noted by GNATS.
From: Martin Cracauer <cracauer@cons.org>
To: FreeBSD-gnats-submit@freebsd.org
Cc: Subject: Re: bin/1968: rdate(8) implementation (from NetBSD)
Date: Thu, 7 Nov 1996 17:21:01 +0100 (MET)
Mark O'Lear writes:
> cracauer@cons.org wrote:
[...]
> > I can imagine the following situations where rdate(8) may be better
> > than NTP:
> > - You want to synchronize to a host whose clock is just wrong, but you
> > don't care for the correct time, just it has to be the same on
> > a second machine you are root on.
> > - In an environment where I know one host has a perfect clock, I just
> > add an rdate run to the crontab and don't set up NTP at all.
[...]
> When you say NTP do you mean xntpd or just the protocol?
> ntpdate(8) does one time clock synchronization using NTP.
> Does rdate use something other than NTP?
To make my point cleaner, let me add a few points:
1) You can use ntp or ntpdate only when the host to synchronize to
support ntp. Maschine not beeing capable of that include:
- SunOS-4.1.x (this is a BSD mailing list, you don't want want me to
switch to Solaris, eh?)
- NetBSD, at least 1.1
- whatever OS gatekeeper.dec.com runs
- you can get normal timeserver software for Windows NT, I don't know
about a NTP implementation
This is a killer argument, I think, but let me add another one:
2) The fact that ntp uses a different protocol and different port can
make live hard. Consider a firewall where only certain ports are
open. Suppose you don't have control over the firewall, it is a) more
likely that the adminstrator opens the port for a service he knows
about and the simple inetd-based rdate-mechanism is likely to be
better known than ntp and b) the port rdate uses may already be open
for a better-known port.
3) Consider
shell$ man ntpdate | wc
132 723 5463
shell$ man rdate | wc
23 83 725
My point: rdate is just a little easy-to-use utility that can be used
without further investigation and without thinking about the
environment.
In a word: I think an operating system that provides rdate(8) is more
convinient for users used to other OSes. We want to be that.
You might argue that a new tool adds bloat to the system. Obviously,
the disk space for the rdate implementation I submitted is
neglectable (spelling?). What else is followed by bloat?
- the lookup time of files in /usr/sbin will be a bit higher
- the lookup time of man pages in section 8 will be a bit higher
- any additional manpage causes `man -k` etc. to be slower. But we're
talking about a tiny manpage (see above)
I could stand all these points.
Once again, I request to add rdate(8) with it's man page to the base
FreeBSD system.
> --
> Mark O'Lear \ e-mail: Mark.Olear@Colorado.EDU
> University of Colorado \ phone: (303) 492-3798
> Telecomm. Svcs. (CB 313) \ fax: (303) 492-5105
> Boulder, CO 80309 \
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611072250.OAA24781>