Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 Dec 2001 21:02:48 +0100
From:      "Anthony Atkielski" <anthony@freebie.atkielski.com>
To:        "Joe & Fhe Barbish" <barbish@a1poweruser.com>
Cc:        "FBSD Questions" <questions@FreeBSD.ORG>
Subject:   Re: /etc/hosts file ?  FBSD doc suck
Message-ID:  <004201c18347$f9b219c0$0a00000a@atkielski.com>
References:  <LPBBIGIAAKKEOEJOLEGOKEEMCJAA.barbish@a1poweruser.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Joe writes:

> I want to thank you for your professional response
> to my question on this list.

You're welcome.  I've spent a portion of my career in technical support, so
I'm used to answering questions.

> The type of information you provided is what is missing
> in the FBSD handbook.

The handbook and the man pages are both extremely lightweight, IMO.
However, I understand that most people find writing documentation to be a
serious chore, and even when they don't, it usually has a lower priority
than development.  Of course, this is all the more true when the software is
free and both code and documentation are written by volunteers.  You can't
really complain if you got it for free; a lot of documentation for
commercial software packages costing a bundle is only marginally better.

> In the technical documentation writers world it's
> called descriptive supporting background information.

Yes.  The kind that explains a concept to someone who hasn't already
encountered that concept.

> The handbook and man pages are written in a reference
> style which is targeted at an audience who all ready
> has an in-depth understanding of how things work.

I've noticed that.  They are like reference cards, I think.  Even then, they
are often missing important details that even a seasoned administrator may
not have committed to memory.

> Some of the man pages you all most have to have
> the authors level of knowledge to understand what
> it means.

There is significant inconsistency in the tone of man pages, probably due to
a varied authorship and limited editorial control.

I used to work on mainframes, too.  I often thought the documentation was
pretty bad.  But then I started working on PCs, and suddenly the
documentation for mainframes looked exhaustive!

> FBSD will never penetrate the main line pc operating
> system market or ever make a dent in Microsoft's
> market share until the handbook, man pages and
> install procedure become user friendly, up to date
> and current with the version of the software in
> current distribution.

Very true.  However, there are so many other obstacles to displacing
Microsoft on the desktop that documentation is probably the least of the
problems to be addressed.

In the server realm, it's a different story.  If you can find geeks to run
your servers (and you pretty much have no choice if you want to run UNIX, as
UNIX is not for the IT-illiterate), minimal documentation will often do.
Unsophisticated IT staffs may be tempted to choose Windows, however.

> I hope Wind River the new FBSD supporter will also
> see this and invest in a technical writer to redo
> the documentation.

Documentation can be pretty expensive.  I don't know if they'll be making
enough to redo the documentation.

Heck, I'd volunteer myself (I've written documentation before, and I'm
better at it than most software engineers), but unfortunately I have to
concentrate on finding ways to pay the rent first.

> Now a comment about what I have comprehended from
> your answer. It looks to me as the host name function
> in the hosts file is an undocumented standard naming
> convention.

Well, it's sorta documented, in that misty, gestalt-based way that all
open-source geek software documentation seems to take.  It's the kind of
documentation that you understand best just before you have it all
memorized, if you know what I mean.

> The domain name represents the handle name you want
> to know your whole environment by. The prefix.domain
> is the name you use to identify each unique machine on
>  the LAN. The alias name is just a short cut name.

It's more straightforward than that.  The resolver just scans the hosts file
looking for a hostname that you reference, and if it finds a match, it uses
the corresponding IP address.  Pretty simple, in the traditional UNIX way.
No need to open a ten-megabyte proprietary relational database and query it
with three DLLs and a five-megabyte background service to obtain a
proprietary dynamic ActiveMess object that points to a reference to the
final IP address of the referenced name and reports the weight of your
wallet to MSN.

One nice thing about FreeBSD is that you have the source, so you can
actually dig up the routine that does this and see it.  I located
gethostbyht.c in the source, which apparently services gethostbyname() (the
call used to pick up an IP address for a hostname), and it does indeed open
the file, scan it, and close it.  It couldn't be much simpler.

> Entries of this type are not necessary but are
> generally used as a convenance.

Yes.  Additionally, if you have a DNS server available, you can configure
your system to just query the DNS server to look up names.  Or you can set
it up to use both the hosts file and DNS; by default, it searches them both
in that order, but you can change it.

> So if I have these statements
> 10.0.0.10 gateway.companyname.com gateway
> 10.0.0.11 winbox1.companyname.com winbox1
>
> I could ping 10.0.0.10 or ping gateway.companyname.com
> or ping gateway and all the pings would be basically
> the same.

Not just basically the same, but identical.




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?004201c18347$f9b219c0$0a00000a>