web-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: More patches for the FAQ


From: Marcus Brinkmann
Subject: Re: More patches for the FAQ
Date: Tue, 11 Jan 2005 16:21:48 +0100
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

Hi,

some good work, although I have to say as a general note that I don't
believe the FAQ is the right place to document arbitrary
short-comings, bugs or third party projects...

At Sun, 09 Jan 2005 19:51:06 +0100,
Alfred M Szmidt wrote:

>    -{MB} The distinction between `/' and `/usr' has historical reasons.
>    +{MB,FH} The distinction between `/' and `/usr' has historical reasons.
>     Back when Unix systems were booted from two tapes, a small root tape
>     and a big user tape.  Today, we like to use different partitions for
>     these two spaces.  The Hurd throws this historical garbage away.  We
>    -think that we have found a more flexible solution called shadow
>    -filesystems.  Unfortunately, support for shadowed filesystems is not yet
>    -implemented.
>    +think that we have found a more flexible solution called union
>    +filesystems.  Unfortunately, support for union filesystems is still in
>    +early development and styl needs lots of testing and patches.
> 
> styl ==> style, could you rewrite the last sentence to put things into
> more positive light?

Also, it should be something that makes sense.

>    +?? What are union filesystemens and unionfs ?
>    +
>    +{FH} An union filesystem merges two directory trees into a new virtual
>    +tree.  For example, files appearing  under `/bin' could actually be
>    +located in different physical locations.  That's why it isn't
>    +necessary to have a separate  `/usr' directory.  Filesystem unions
>    +will be done by the `unionfs' translator; however, this translator is
>    +still in development.=20
>    +
>    +You are welcome to check it out at:
>    +
>    +  http://duesseldorf.ccc.de/~moritz/hurd.html
>    +
>    +... and to help its development.
> 
> unionfs is now maintained by Gianluca and me, and it is only avaiable
> in the hurdextras CVS.

This should just be dropped.  If it really needs explanation, the
previous entry should be extended: "...called union filesystems, which
allow to create virtual filesystems which are the union of several
other filesystems.  Unfortunately...".

That's just about everything somebody reading the FAQ needs to know.

>     ??        Where is the documentation?
>    =20
>    -{NHW} There are neither man pages nor info nodes for the Hurd translator=
>    s
>    -and commands.  Documentation lives inside of the binaries and can be
>    +{NHW,MM} The most up to date documentation lives inside of the binaries =
>    and can be
> 
> Neal didn't write this section, so giving him credit for this piece is
> incorrect.

I don't see the point of removing the sentence you remove.

>    +You can also find documentation on the Wiki:
>    +
>    +  http://hurd.gnufans.org/

I don't think this is the appropriate place to mention the Wiki.  We
should only list our own documentation here.
 
>    @@ -408,7 +442,14 @@ programs that rely it.  If you are wonde
>     directory, this is a relict from a Debian GNU/Linux package
>     (specifically, `base-files').
>    =20
>    -You can probe for existing hardware devices with the devprobe utility.
>    +{MM} James Morrisson has created a procfs translator which implements
>    +a /proc file system providing informations about running processes on
>    +the system, as Linux /proc does (those are the directories with
>    +numerical names, which are actually PIDs).  It is highly experimental
>    +and needs testing and improvements.  You can check it out at:
>    +
>    +  http://savannah.nongnu.org/projects/hurdextras
>    +
> 
> Is procfs really a frequent question? 

No, and the project in hurdextras is not an appropriate substitute.

Also, the patch removes the devprobe comment, which is more important
than everything the procfs translator does.

Sorry for being so critical, but we should be conservative here.  Only
reliable, stable information should enter the FAQ.  Pointing to
experimental stuff that may or may not be in development and may or
may not work is just not helpful.

Thanks,
Marcus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]