From 11f714d28c11f819331d036b8d6dde659ef48480 Mon Sep 17 00:00:00 2001 From: tg Date: Wed, 5 Feb 1997 07:36:51 +0000 Subject: Typos. --- usr.sbin/rpc.ypxfrd/rpc.ypxfrd.8 | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'usr.sbin/rpc.ypxfrd') diff --git a/usr.sbin/rpc.ypxfrd/rpc.ypxfrd.8 b/usr.sbin/rpc.ypxfrd/rpc.ypxfrd.8 index 3c69bce..6dc284d 100644 --- a/usr.sbin/rpc.ypxfrd/rpc.ypxfrd.8 +++ b/usr.sbin/rpc.ypxfrd/rpc.ypxfrd.8 @@ -88,7 +88,7 @@ server speeds up the transfer process by allowing NIS slave servers to simply copy the master server's map files rather than building their own from scratch. Simply put, .Nm rpc.ypxfrd -impliments an RPC-based file transfer protocol. Transfering even +implements an RPC-based file transfer protocol. Transfering even a multi-megabyte file in this fashion takes only a few seconds compared to the several minutes it would take even a reasonably fast slave server to build a new map from scratch. @@ -129,9 +129,9 @@ The FreeBSD .Nm ypxfrd protocol is not compatible with that used by SunOS. This is unfortunate but unavoidable: Sun's protocol is not freely available, and even if it -were it would probably not be useful since the SunOS NIS v2 implimentation +were it would probably not be useful since the SunOS NIS v2 implementation uses the original ndbm package for its map databases whereas the FreeBSD -implimentation uses Berkeley DB. These two packages use vastly different +implementation uses Berkeley DB. These two packages use vastly different file formats. Furthermore, ndbm is byte-order sensitive and not very smart about it, meaning that am ndbm database created on a big endian system can't be read on a little endian system. -- cgit v1.1