Re: directory structure - 2.
No offense meant, but I find this sort of ordering very inefficient for the
users. If I need information about my SB AWE soundcard, where do I look?
* HOWTO/mini? (here you would find my howto, after probably 8 trials)
* news? (maybe my sound card is a new one, and I'm confused by all the
The ftp organization has absolutely no connection about finding
information. It has something to do with finding packages/software, and even
here I often guess wrong when I look for a specific package via ftp.
This is the wrong approach. You should know that libraries don't sort books
by publishers, size or color. They arrange them not in alphabetical order,
too (alphabetical ordering is the *last* criterium). There are several
systems, but one very common has a three level deep letter-coded
organization structure. For example, "A" is for general information, "T" for
mathematic and so on. And if the first letter is "T", the second letter says
something about the sort of mathematic the book is telling about. "A" means
general (bibliographies, lexica etc), "B" could mean Algebra and so on. The
third letter gives even more information. For most books, you can say what
information is in the book just by knowing the three letters. And it works
also the other way round: If you have an idea of the book you need, you can
limit the area to search up to three presorted levels. You can easily guess
the first two letters, the third is sometimes a bit hard to know before.
The people that invent such structures take a lot care about this, and they
know why. Searching in a big library for information can be a pain. We
should also be very careful, because our library is theoretical not limited
in size. We have more powerful tools than simple letters. We should make use
of them. The structure you suggest below is useful for ftp ordering, but it
does not take into count *one* of the important things you need to make
information easy accesible.
We should not be too picky about a structure now: It will evolve when
documents are added. However, we should have a *solid* base for a starter.
I think we have the following main levels:
Using (weak word, has someone a better word?).
Note that I also think that many related documents could share a tree by
themselves, but they should also register in the four categories above. For
example, all X related documents could be stored in a single tree X, but the
individual documents should also be find below Administration, Development
I see no problem in using several main branches: There could even be a
branch that has all Apllications (similar to the menu system), that collects
the documents related to a single program. Maybe this is what Marco has in
However, we should have one or two such main branches (maybe the one above
and the "Application" branch that are mandatory for every document. This
would mean that every document has to register at least once in each of this
default branch(es). This would avoid confusion, as every document can be
found in one of the default branches.
I would volunteer to maintain the
list/structure/whatever-you-like-to-call-it. This means, I would collect
suggestions, new entries etc and would post updated versions (if appropriate
with alternatives) on this list. Probably this could avoid some confusing
discussion on this list.
Note that this question is very related to the structure of the Debian
FAQ-o-Matic, and I think they could probably be build after the same model
(maybe this would give the faq-o-matic a push). Please also note that this
does not mean that we should take the structure from the faq-o-matic (I
wouldprefer the other way round ;)
On Mon, Apr 13, 1998 at 08:23:00PM +0100, Marco Budde wrote:
> Includes some of Christians directories:
> devel/c or gcc?
> cu, Marco
"Rhubarb is no Egyptian god." Debian GNU/Linux finger brinkmd@
Marcus Brinkmann http://www.debian.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com