On 18 Oct 2000, Chris G. Demetriou wrote:

# let's see.
# 
# http://www.framed.usps.com/ncsc/lookups/lookup_ctystzip.html
# 	went to usps site, and followed links.

Let's see:

le0:  Link down or transceiver cable problem?

# btw, even suffering a rather lousy net connection and slow browser, i
# managed to collect and document those in less than 4 minutes.

Can't collect squat without a link.

# > i, for one, have always been *delighted* that those things are there.
# 
# That's great.  But fundamentally, when an OS project is trying to
# track area code assignments and birth tokens, something isn't quite
# right.

NetBSD is, to me, as 4.x BSD was.  It's more than just "an OS".  It
was/is an environment all its own.  Look at Sun - they went into
making it just "an OS", and the next thing I know, /usr/games/fortune
went by the wayside, the man pages had all the esoteric references
removed and Sun became a drag to work with.  Well, that, and they
slept with AT&T, who left Sun to bear a bastard child.

# These types of things -- if somebody finds them desirable -- should be
# in an add-in, third-party-maintained package, in pkgsrc.

I'd like them to be a first-and-a-half-party package, in that they
can be added in from the base distribution if desired.  Oh, wait,
that's what the "misc" package is for (except it contains termcap/
terminfo files and stuff).

Separate it into nonessential, or some such?  I don't know.

# > some of the other stuff is a little more esoteric, but i'd hate to
# > have to search around on the "web" for it if it wasn't installed here.
# > why throw away good data?
# 
# because, especially for the ones which change (airport codes, phone
# stuff, zipcode stuff), it's outside of the scope of an operating
# system project to maintain them.

"See above regarding an OS versus an environment."

# They need to be kept up to date, and I see no reason The NetBSD
# Project -- an operating system development project -- should spend the
# effort on maintaining them.
# 
# 
# If somebody, you or other, wants to make a package out of them, and
# distribute it and maintain it, that'd be _great_.  Then it'd not only
# be usable to NetBSD users, but also to users of other systems.
# 
# But an OS development project doesn't really have any business wasting
# any resources on maintaining them.

And tell me, where do the pkgtools fall as far as being OS development?

Should we waste our time keeping sh, make, dump, ls, ftp, or anything else
in /{,usr/}{s,}bin up to date?  After all, they're not the OS.  They're
"just binaries". 8'D

Apologies in advance if this seems a bit vitriolic -- it's meant to
be much less so than it may seem, really.  I see what Chris is saying,
but by the same token, if we're "an OS development project" and that's
all, we've already overextended ourselves into other regions; tacking
/usr/share/misc onto that is SUCH a small splash in the water that I
don't see where the problem lies.

If anyone decides to make a package, call it miscupd or something
like that that will update /usr/share/misc directly and thus keep it
out of the developers' hair.  Otherwise, we can just honor send-pr,
have someone toss in a diff, update it for the next sup and we're
good to go.


# chris

				--*greywolf;
--
*BSD: No Sh;t!