1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
|
From: mib@duality.gnu.ai.mit.edu (Michael I. Bushnell, p/BSG)
Newsgroups: gnu.misc.discuss
Subject: Re: GNU vs. Linux FSSTND conflict?
Date: 13 Aug 1995 22:31:18 GMT
Organization: Free Software Foundation, Cambridge, MA
In-reply-to: Rick Niles's message of 13 Aug 1995 16:20:29 GMT
In article <40l8od$ia9@news4.digex.net> Rick Niles <niles@axp745.gsfc.nasa.gov>
writes:
Is there a conflict between the GNU Filesystem Structure and
the Linux Filesystem Structure (FSSTND)?
What you point out is the trivial difference; there are significant
lossages in FSSTND, such as the absence of libexec...
I've heard on this newsgroup that the GNU std. is to elminate
the use of /usr. So:
I guess the first question is: Is this true?
Yes.
If it is how do you answer those who say the root part. should
be small and only enough to boot the system? And
the rest of the system should be on a separate part. (/usr)
In GNU the directory /bin will be an amalgam of several directories;
this well be done by the use of a translator in the Hurd. (It will be
similar to BSD shadow filesystems.)
So we have no need to confuse users by putting binaries in two
different places. We can put different binaries in different physical
locations without either forcing them to appear in different places or
creating a forest of symlinks.
But the FSSTND's arguments are bogus even for Unixoid systems which do
force differently located files to have different directory names:
o It is often mounted from very small media. For example, many Linux
users install and recover systems by mounting root off a RAM disk,
which is copied from a single 1.44M or 1.2M floppy disk.
This is a non-issue. Obviously a floppy can only have a small number
of files, but that's totally irrelevant in deciding what should be on
root on a fully loaded system.
o The root filesystem has many system-specific configuration files in
it. Possible examples include a kernel that is specific to the
system, a different hostname, etc. This means that the root
filesystem isn't always shareable between networked systems.
Keeping it small on networked systems minimizes the amount of space
lost on servers to unshareable files. It also allows workstations
with smaller local hard drives.
It should be possible to require only the etc directory to be
per-system; there is no reason that bin and such should be non-shared
at all.
o While you may have the root filesystem on a large partition, and
may be able to fill it to your heart's content, there will be
people with smaller partitions. If you have more files installed,
you may find incompatibilities with other systems using root
filesystems on smaller partitions. If you are a developer then you
may be turning your assumption into a problem for a large number of
users.
This is totally incoherent, as far as I can tell. If someone can tell
me what it means, then maybe I could help. What sort of
incompatibilities are expected?
Michael
From: gord@enci.ucalgary.ca (Gord Matzigkeit)
Newsgroups: gnu.misc.discuss
Subject: Re: GNU vs. Linux FSSTND conflict?
Date: 14 Aug 1995 18:55:20 -0600
In-reply-to: mib@duality.gnu.ai.mit.edu's message of 13 Aug 1995 22:31:18 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hi!
>>>>> "mib" == Michael I Bushnell, p/BSG <mib@duality.gnu.ai.mit.edu> writes:
mib> In article <40l8od$ia9@news4.digex.net> Rick Niles
mib> <niles@axp745.gsfc.nasa.gov> writes:
[hack & slice]
>> If it is how do you answer those who say the root
>> part. should be small and only enough to boot the system? And
>> the rest of the system should be on a separate part. (/usr)
mib> In GNU the directory /bin will be an amalgam of several
mib> directories; this well be done by the use of a translator in the
mib> Hurd. (It will be similar to BSD shadow filesystems.)
This is what I figured... my reply didn't get posted to USENET,
though, because our NNTP server has been down for the last day or two.
mib> So we have no need to confuse users by putting binaries in two
mib> different places. We can put different binaries in different
mib> physical locations without either forcing them to appear in
mib> different places or creating a forest of symlinks.
This is grand! One of my ideas that I mentioned to Rick was that I'm
currently using depot, and I see that the GNU union/shadowfs could
replace that.
What depot does is manages symlinks for a "software environment" (a
more restricted version of what you have described).
The way I think I'll be setting up my Hurd machine is to have all the
physical disks mounted under "/disk", each containing a fragment of
the filesystem.
Now, my only concerns are:
1) control files, as far as determining precedence, and what can and
cannot be shadowed (for collision resolution), and what is just
auxilliary info (like CVS directories in the site package, which
should not be mapped onto the software environment)
2) packages. Is there some slick way to divide the filesystem into
"package pieces", like depot does?
One suggestion to get (2), is that I could create an intermediate
directory, say "/package", that would be the union of various mounted
physical disks (under /disk), and would contain things like:
emacs-19.30/bin
emacs-19.30/lib...
gcc-2.7.3/bin...
fileutils-5.8/man...
site/sbin/useful_perl_script
et al. Then I would unionfs all the directories in the /package dir
onto the root filesystem.
This would have most of the advantages I'm getting from depot, namely,
the ability to specify different precedences on different machines,
so that I can try out emacs-19.31 on one workstation without
disrupting the others.
Is there a better way to do this? I do like the idea of three
different hierarchies for files (under /disk, where I can see what is
on each server; under /package, where I can see what is in each
package; the GNU standard dirs, where I actually use the files), but I
am hoping that there is something more elegant. Hmm. Maybe not.
mib> It should be possible to require only the etc directory to be
mib> per-system; there is no reason that bin and such should be
mib> non-shared at all.
This is one point (for security), that would mandate the use of config
files, so that the unionfs doesn't map /etc/some_important_file from
another server.
This is yet another thing that I'm looking forward to. Thanks. ;)
- --Gordon
- --
Gordon Matzigkeit | Heck, it was only a TOASTER... lighten up!
gord@enci.ucalgary.ca | PGP mail preferred... finger me for my key.
Keyprint: D5 66 08 E0 4D F4 D7 7B 8A C8 8A 9C 7F 39 25 A7 - ID 339ABEB9
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface
iQCVAwUBMC/wcyFsfCEzmr65AQHubwP7BGVHqs9ACB8hFUqDdF2oWu/lLq1hW/Oa
qra2ZfcKfIZq9hIM4tLRJ0qCaiOVm5MGLgH7Yax+ZyOPb4K0fCObzk1XY5b0enhV
9SR70UZ7Qm7MXj+PFCp5lxvrNiaFXMbil0EN5FQEvH9kUp0ed1NWcaXGqTK6gezm
YBUumt2Zadk=
=6f2c
-----END PGP SIGNATURE-----
From: mib@duality.gnu.ai.mit.edu (Michael I. Bushnell, p/BSG)
Newsgroups: gnu.misc.discuss
Subject: Re: GNU vs. Linux FSSTND conflict?
Date: 16 Aug 1995 14:43:47 GMT
In-reply-to: gord@enci.ucalgary.ca's message of 14 Aug 1995 18:55:20 -0600
In article <npka8gj893.fsf@enci.ucalgary.ca> gord@enci.ucalgary.ca (Gord Matzig
keit) writes:
The way I think I'll be setting up my Hurd machine is to have all the
physical disks mounted under "/disk", each containing a fragment of
the filesystem.
Our idea is to do something roughly like this.
1) control files, as far as determining precedence, and what can and
cannot be shadowed (for collision resolution), and what is just
auxilliary info (like CVS directories in the site package, which
should not be mapped onto the software environment)
Yes, the relevant translator will support a *rich* set of semantics
for this kind of things specified by a control file.
2) packages. Is there some slick way to divide the filesystem into
"package pieces", like depot does?
We're going to do this; rms and I have worked out a usable scheme that
meets all the necessary goals.
The physical location of files has to be reflected by sharing rules
(see the GNU makefile standards); users have to be able to see all the
files relevant to a particular program easily; programs have to be
easily de-installed. We have a scheme that meets these three.
Michael
|
