David Goodenough <[EMAIL PROTECTED]> writes:
>                        At least with a single vendor changes
> are managed,
> and so documentation updates are controllable.  This does
> make it a bad
> thing to want to do, just a very difficult one.

My experience is exactly opposite to this.  The worst-documented,
most-cryptic open source packages I've ever seen all came from
the fingers of a single author.  The best are usually a group
effort, requiring coordination between the players.  And I've
never seen a group programming effort that didn't have an
acknowleged leader to take on that role.  That's *especially*
true in modern open source projects, where despite the "anyone
can fork and run" rule, in practice people avoid forking code
bases like the plague, and there's always a small core that are
allowed to check in changes.  If you reject patches based on
availability of documentation, you'll eventually get good doc.

>                                                  Add to that
> the well known
> fact that programmers do not like witing documentation and
> you have the
> current Linux situation.

Are we talking about the same system?  I've got 285MB in 19501
files under /usr/doc, /usr/man, and /usr/info.  Sure, there's
some duplicated information, and of course some of it is a little
raw.  And that's not to mention the contents of the Linux
Documentation Project (www.linuxdoc.org).  OK, it's not the
massive OS/390 or VMS library, but it's not as bad as MS-Windows
either.

Want some examples?  The GNU C library is better documented than
many I've seen, and the doc is all on your system ("info libc").
The GNU Compiler Collection ("info gcc") doesn't document the
languages, but they do document the variations from the standards
and most things that are specific to their compilers.

>                           Of course not only does Linux
> itself come from
> many places, but Linux is only the kernel, and all the other
> bits need to
> be considered too.  Then it all needs to be NLS enabled,

There's a GNU NLS-enablement package, and much if not all of
the C library is enabled.  There are over 100 subdirectories
in /usr/share/locale/ containing translated message repositories.

Ross Patterson
Computer Associates

Reply via email to