1 |
After the previous suggestions on this topic, I have revised the proposed |
2 |
standard somewhat. It is still posted in a variety of formats at: |
3 |
|
4 |
http://www.csis.gvsu.edu/~abreschm/uafhs/ |
5 |
|
6 |
I added the suggestion of using .<distribution>/<architecture>/ for a |
7 |
directory structure, rather than my first change to simply putting it into a |
8 |
hidden umbrella directory of a standard name. However, I still have several |
9 |
questions regarding this which I could not find an immediate answer to: |
10 |
|
11 |
Should there be a standard naming scheme for architectures, or should that |
12 |
be left completely to the devices of the distribution? I'm tending towards |
13 |
leaving it to the distribution, but would like some comments. |
14 |
|
15 |
What about architecture independent systems, like Java? Should each distro |
16 |
include a 'java' architecture, or something of that sort? There is no |
17 |
particular reason for such files to be in every architecture's folder when |
18 |
they work fairly widely. |
19 |
|
20 |
|
21 |
I also liked the idea of having group directories similar to the shared |
22 |
directory. In a larger work environment, such directories could solve many |
23 |
difficult problems. The standard doesn't say much about them, however, |
24 |
besides that they can be named arbitrarily and should have an internal |
25 |
structure identical to /home/shared/ and should be located somewhere in |
26 |
/home/. I don't see what else is needed to be defined on that topic, but |
27 |
would like any suggestions. |
28 |
|
29 |
|
30 |
I see no reason to unhide the program folders. They are still perfectly |
31 |
accessible when they need to be accessed, but they can at least be kept out |
32 |
of sight. This is even more important when using a naming scheme based on |
33 |
the distribution which could result in very many folders. |
34 |
|
35 |
|
36 |
Due to the fact that I merely added to and edited the old document, rather |
37 |
than going through and actually rewriting it, or at least checking it, the |
38 |
wording is clunky on several occasions. I'm not too concerned, as this is |
39 |
still a draft, and will work more on clarity when the ideas to be conveyed |
40 |
are better decided. |
41 |
|
42 |
As always, thank you for your commentary and criticism. |
43 |
|
44 |
Micah Abresch |
45 |
jamethknorth@×××××××.com |
46 |
|
47 |
P.S. In case anyone was wondering why this was sent to the lists it was: |
48 |
those are the groups which have easily accessible public lists and to which |
49 |
this proposed standard seemed relevant. |
50 |
|
51 |
P.P.S. Many people have contributed ideas in discussions but aren't added to |
52 |
the contributors section. Luckily, everything is in a public archive so I |
53 |
can go back and see who suggested what, but it would be easier if anyone who |
54 |
wanted to be credited would just e-mail me about it. |
55 |
|
56 |
_________________________________________________________________ |
57 |
Persistent heartburn? Check out Digestive Health & Wellness for information |
58 |
and advice. http://gerd.msn.com/default.asp |
59 |
|
60 |
|
61 |
-- |
62 |
gentoo-desktop-research@g.o mailing list |