summaryrefslogtreecommitdiff
path: root/unsorted/hurd-fs-org
diff options
context:
space:
mode:
authorThomas Schwinge <tschwinge@gnu.org>2008-11-06 12:37:49 +0100
committerThomas Schwinge <tschwinge@gnu.org>2008-11-06 12:37:49 +0100
commitef7f0326b971806ce9061a71cd1874b7e0c279d0 (patch)
tree00c8d2db319a5c68c0f23e34b07a442db98fe1a2 /unsorted/hurd-fs-org
parent7c632cb5e64dd91c917ce9043cd7c2a6e85f9085 (diff)
Three more documents I don't know what to do with.
Diffstat (limited to 'unsorted/hurd-fs-org')
-rw-r--r--unsorted/hurd-fs-org219
1 files changed, 219 insertions, 0 deletions
diff --git a/unsorted/hurd-fs-org b/unsorted/hurd-fs-org
new file mode 100644
index 00000000..ba515623
--- /dev/null
+++ b/unsorted/hurd-fs-org
@@ -0,0 +1,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