[9fans] Creating new documents on KFS, Fossil, and Venti implementation and etc...

[9fans] Creating new documents on KFS, Fossil, and Venti implementation and etc...

[Vester Thacker]

1.  Does Fossil replace kfs on all Plan 9 computers? Or should Fossil
be used only on file servers, while terminals and cpu servers use kfs?
I find myself asking this question after reading the wiki docs and
reading 9fans.

2.  I know many of the Plan 9 papers are clearly outdated. For
instance,  the Plan 9 from Bell Labs paper
(http://plan9.bell-labs.com/sys/doc/9.html) doesn't mention Fossil and
Venti, nor how the items are incorporated into the scheme of things. I
can imply their usage, but I don't like to assume.  Also, I've noticed
that a few of the ideas have apparently been deprecated (e.g., the IL
protocol) since the Plan 9 from Bell Labs paper was originally
written.

I'm curious to see if anyone is working on updating any of the Plan 9
papers or are in the process of creating a new work. If not, I'd like
to heavily revise the papers to reflect the current situation vice a
document about Plan 9 one or two editions ago. Since the original
authors of the papers are greatly respected and admired, I imagine
revising their work might not sit well with some folks.

Would anyone be interested in creating a Plan 9 documentation group? I
know several folks have been doing little by little on the side and I
applaud their efforts. But is anyone interested in starting a
documentation project? This might lead to greater colaboration and
lead to economy of effort. Let the programmers write code and the rest
of us write or update the docs.   Comments?

Sincerely,
Vester "Vic" Thacker

Re: [9fans] Creating new documents on KFS, Fossil, and Venti implementation and etc...

[Boris Maryshev]

On Sun, 26 Sep 2004, Vester Thacker wrote:

> 1.  Does Fossil replace kfs on all Plan 9 computers? Or should Fossil
> be used only on file servers, while terminals and cpu servers use kfs?
Wiki says that you should use fossil on cpu servers: "If you have 
installed your system with a fossil file system (as you should have)", 
probably it doesn't matter much for terminals...

> Would anyone be interested in creating a Plan 9 documentation group? I
> know several folks have been doing little by little on the side and I
> applaud their efforts. But is anyone interested in starting a
> documentation project? This might lead to greater colaboration and
> lead to economy of effort. Let the programmers write code and the rest
> of us write or update the docs.   Comments?
I think Wiki is the best place for it.

>
> Sincerely,
> Vester "Vic" Thacker
>
Boris Maryshev

Re: [9fans] Creating new documents on KFS, Fossil, and Venti implementation and etc...

[Vester Thacker]

> Wiki says that you should use fossil on cpu servers: "If you have
> installed your system with a fossil file system (as you should have)",
> probably it doesn't matter much for terminals...

Hmm. KFS still works as a cpu server. When we made the leap to fossil,
maybe we should have had a revision change. There appears to be three
4th editions. One where I can do everything with KFS, one where I can
use both, and one where I can do everything with Fossil.


> I think Wiki is the best place for it.
I concur. I suppose that I am interested in a concerted effort vice hodge podge.

Re: [9fans] Creating new documents on KFS, Fossil,

[andrey mirtchovski]

> 2.  I know many of the Plan 9 papers are clearly outdated 

the problem you're going to run into is, strictly academically
speaking, that you won't be able to modify any of the documentation
without publishing the modifications.  if you want to have an
up-to-date venti description you should publish an up-to-date venti
paper.

publishing is much more difficult than writing man pages, so it's not
a surprise that you see a fossil paper still lingering in the
documentation corners without having an official release with a
conference-backed citation, just look at
http://plan9.bell-labs.com/sys/doc/fossil.ps

two paths lead to a solution to this problem.  either write
documentation accessible to anyone everywhere (i.e.  man pages) or
leave others to ponder on implementation solutions through the papers.
the second one has an obvious drawback -- on a frequently used system
it won't matter how much you change the papers, the implementation is
always going to be one step ahead.

andrey

Re: [9fans] Creating new documents on KFS, Fossil,

[geoff]

There is a third possibility: the person who updates the code updates
the corresponding paper, if any.  This seems to be part of 1127's
tradition that the person who writes the code writes the
documentation.  It makes sense, the programmer knows better than
anyone the details of the program.  Having someone else do it can
lead, in the extreme, to such hilarious fiction as the HISTORY
sections of the BSD manual pages.

To take a timely example, I've just made /sys/src/fs use 64-bit
integers internally and on disk to hold metadata (e.g., file offsets,
block numbers, sizes, made file name components longer, made it
possible to compile the same source to get a kernel that is precisely
compatible with current on-disk file systems, upgraded the IDE code
(it now uses DMA and RWM), and fixed it and the boot code to cope with
faster than 2⁳ⁱHz Pentium IVs (and some other lesser fixes).  It was
annoying and embarrassing that one couldn't create a tar archive, even
in an `other' file system, larger than 2GB.  These changes are almost
entirely internal, so I think that fs(8) and fsconfig(8) are still
correct, but I have updated /sys/doc/fs to reflect the changes in
implementation (and fix a few obvious formatting errors).  Some
sections are unchanged, other needed changes to an astonishing number
of details.  (I will be feeding the changes back to jmk.)

Note that I'm not opposed to fossil (nor venti) but I do like
automatic backup to optical jukeboxes, and there are tricky
bootstrapping issues of how to recover a combined venti/fossil server
if fossil damages its write buffer.  I should probably beat on fossil
and see how robust it is these days.

Re: [9fans] Creating new documents on KFS, Fossil,

[Kenji Okamoto]

> There is a third possibility: the person who updates the code updates
> the corresponding paper, if any.  This seems to be part of 1127's
> tradition that the person who writes the code writes the
> documentation.  

I suppose this tradition can not be live long anymore bvecause of
dispersion of people, and they have their own job other than Plan 9 
now.

The paper is paper, which makes us the things clearer than reading
so-called users manual.   However, it'd be better if we have users
anual with papers for beginners.   I'm not a person who can do it,
so, I'd be very happy if someone could use their time for that purpose.
If we have such, it's more easy to tell someone "Why you don't try
Plan 9?"

By the way, your updates to /sys/src/fs is very interesting to me.
All the sources are in sources?

> I should probably beat on fossil
> and see how robust it is these days.

Quite robust these days!

Kenji

Re: [9fans] Creating new documents on KFS, Fossil,

[geoff]

My changes aren't yet on sources but I'll be giving them
back to jmk for distribution.