From b43ea6ca9b24067ee5d4775383a09c46233119df Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Sun, 17 Mar 2013 13:29:39 +0100 Subject: Categorize FAQs more --- faq/old/old_hurd_faq.txt | 145 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 145 insertions(+) create mode 100644 faq/old/old_hurd_faq.txt (limited to 'faq/old/old_hurd_faq.txt') diff --git a/faq/old/old_hurd_faq.txt b/faq/old/old_hurd_faq.txt new file mode 100644 index 00000000..4ebe019b --- /dev/null +++ b/faq/old/old_hurd_faq.txt @@ -0,0 +1,145 @@ +The Unofficial (and no longer maintained) GNU Hurd FAQ, Version 0.13 + +Contributions by: + +Michael I. Bushnell +Len Tower +Trent Fisher +jlr@usoft.spb.su +Remy Card +Louis-Dominique Dubeau + +Original Document by: Derek Upham + + +============================== + +Contents: + +Q0. Where can I get the Unofficial GNU Hurd FAQ? +Q2. Where can I get a copy? +Q3. Why bother writing a new OS when we have Linux and 386/BSD? +Q4. What's all this about Mach 3.0 (and Mach 4.0)? +Q5. Where can I find more information? +Q7. What sort of machines will run Hurd in the future? +Q8. What is the current development status? +Q9. What sort of system would we have if the Hurd was bootable today? + +============================== + +Q0. Where can I get the Unofficial GNU Hurd FAQ? + +The Unofficial Hurd FAQ (what you are reading now) is occasionally +posted to the USENET newsgroup, gnu.misc.discuss. It is also +available from + + http://www.enci.ucalgary.ca/~gord/hurd/hurd-faq.txt (Broken Link ?) + +If you don't have WWW access, you may send mail to me, Gordon +Matzigkeit with a subject line that reads: + + Subject: send hurd-faq + +You should receive a PGP-signed copy of the current version of this +document in a matter of minutes. + + +Q2. Where can I get a copy? + +To put it simply, you can't. It is still under development (by +Michael Bushnell, Roland McGrath and Miles Bader). It is almost, but +not quite, at the point where you can do real work on it. Keep your +fingers crossed. + +Some people have actually bootstrapped it, but the work is not easy, +and the current snapshot won't work until a new multiserver boot +mechanism is made. + +If you *really* want to try it, beware that it is still pre-alpha +code, and that it will likely crash on you. See Trent Fisher's Hurd +pages (under question 5) for the latest information. + + +Q3. Why bother writing a new OS when we have Linux and 386/BSD? + +For one thing, Linux and BSD don't scale well. Hardware designers are +shifting more and more toward multiprocessor machines for performance, +and standard Unix kernels do not provide much multiprocessor support. +The Hurd, on the other hand, runs on top of the Mach 3.0 micro-kernel +[[1]] from CMU. Mach was designed precisely for multiprocessing +machines, so its portability should carry over nicely to the Hurd. + +In addition, the Hurd will be considerably more flexible and robust +than generic Unix. Wherever possible, Unix kernel features have been +moved into unprivileged space. Once there, anyone who desires can +develop custom replacements for them. Users will be able to write and +use their own file systems, their own `exec' servers, or their own +network protocols if they like, all without disturbing other users. + +The Linux kernel has now been modified to allow user-level file +systems, so there is proof that people will actually use features such +as these. It will be much easier to do under the Hurd, however, +because the Hurd is almost entirely run in user space and because the +various servers are designed for this sort of modification. + + +Q4. What's all this about Mach 3.0 (and Mach 4.0)? + +As mentioned above, Mach is a micro-kernel, written at Carnegie Mellon +University. A more descriptive term might be a greatest-common-factor +kernel, since it provides facilities common to all ``real'' operating +systems, such as memory management, inter-process communication, +processes, and a bunch of other stuff. Unfortunately, the system +calls used to access these facilities are only vaguely related to the +familiar and cherished Unix system calls. There are no "fork", +"wait", or "sleep" system-calls, no SIGHUPs, nothing like that. All +this makes it rather difficult to, say, port GNU Emacs to a Mach box. + +The trick is, of course, to write an emulation library. Unix programs +can then use (what they think are) POSIX system calls and facilities +while they are really using Mach system calls and facilities. + +The simplest way of going about this is to take an ordinary Unix +kernel, open it up, and rip out all the machine-specific guts; any +time the Unix kernel talks to the machine, replace the code with calls +to the Mach micro-kernel. Run this fake kernel on a Mach machine and +you end up with something that looks and acts just like Unix (even to +GNU Emacs). Note that the Unix kernel we have implemented is just one +Really Big Mach program (called a single-server). + +The Hurd, on the other hand, breaks the giant Unix kernel down into +various Mach programs running as daemons. Working in concert with +facilities placed in the C library, these daemons provide all of the +POSIX system-calls and features; from the outside they look just like +a standard Unix kernel. This means that, for practical purposes, +anything that you can port to Linux will also port to the Hurd. + +Of course, if a user wishes to run his own daemons, he can do that as +well.... + +Mach 4.0 is an enhanced version of Mach 3.0, put out by the people at +the University of Utah. They are working on another free operating +system, and part of it includes an enhanced, more flexible version of +Mach. The Hurd has moved to Mach 4.0, which is good, because it is a +lot easier to build than 3.0 was. + +You can find more information on Mach by browsing the Hurd pages given +in the next answer, or by looking at the Project Mach and Flux +homepages at: + +Carnegie Mellon University (for Mach versions before 4.0): + + http://www.cs.cmu.edu/afs/cs.cmu.edu/project/mach/public/www/mach.html + +the University of Utah (for Mach 4.0): + + http://www.cs.utah.edu/projects/flux/mach4/html/ + + + +============================== + +Footnotes: + +[[1]] Yes, I know that ``micro-kernel'' is about as apt a description +as ``Reduced Instruction Set Chip'', but we're stuck with it. -- cgit v1.2.3 From 9d656bbe8f5fb2c3b9151da548f32ff12ae3f54a Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Sun, 17 Mar 2013 14:13:01 +0100 Subject: move more old stuff to current --- faq/0-still_useful.mdwn | 16 +++++++-- faq/old/old_faq.txt | 26 -------------- faq/old/old_hurd_faq.txt | 63 ---------------------------------- faq/support/2_gib_partition_limit.mdwn | 2 ++ 4 files changed, 15 insertions(+), 92 deletions(-) (limited to 'faq/old/old_hurd_faq.txt') diff --git a/faq/0-still_useful.mdwn b/faq/0-still_useful.mdwn index d98f98ed..96ea6f32 100644 --- a/faq/0-still_useful.mdwn +++ b/faq/0-still_useful.mdwn @@ -8,10 +8,20 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -[[!meta title="Why is the Hurd useful?"]] +[[!meta title="What are the advantages with the Hurd over Linux/BSD?"]] -What are the advantages with the Hurd over Linux? (In general of course, nothing -in depth) +The Hurd will be considerably more flexible and robust +than generic Unix. Wherever possible, Unix kernel features have been +moved into unprivileged space. Once there, anyone who desires can +develop custom replacements for them. Users will be able to write and +use their own file systems, their own `exec' servers, or their own +network protocols if they like, all without disturbing other users. + +The Linux kernel has now been modified to allow user-level file +systems, so there is proof that people will actually use features such +as these. It will be much easier to do under the Hurd, however, +because the Hurd is almost entirely run in user space and because the +various servers are designed for this sort of modification. > Notably, flexibility for the user: > diff --git a/faq/old/old_faq.txt b/faq/old/old_faq.txt index 24127462..f6a4204b 100644 --- a/faq/old/old_faq.txt +++ b/faq/old/old_faq.txt @@ -85,11 +85,6 @@ partition on the first drive detected by the BIOS (or the second partition with GRUB 1). As Grub now has tab completion, there is not a lot of guess work. -?? Can I use partitions larger than 2GB? - -{ST} Yes. Disk drivers however currently do not support more than 2^32 sectors, i.e. -2TiB. - ?? How much swap do I need? {ST} The usual rule of thumb applies: the same amount as RAM, for instance. @@ -269,16 +264,6 @@ hung, it will not be able respond to its message port and thus, ps will wait forever. The `-M' option instructs ps to not gather information that would require use of the message port. -?? Where are ... - -{MB} `dmesg' is not available. You can read `/var/log/dmesg` instead. - -?? Why does the command `df' not work? - -{NHW} It does, you just have to tell it what filesystem to query. E.g. - - # df / - ?? Why are my translators dying? {NHW} Try passing the `-ap' flag to settrans. By default, settrans only @@ -364,12 +349,6 @@ reboot the system. ? Porting -?? What programs have been ported? - -{NHW} A lot, take a look at the Debian archive. Many programs, however, -do not necessarily need to be ported; they have just never been -compiled. - ?? Is porting easy? {NHW} Porting applications to GNU/Hurd is relatively easy assuming the @@ -382,11 +361,6 @@ thousand, however, on GNU/Hurd, there is no maximum and thus, this is not set. The correct thing to do is to submit a patch to the upstream author that allocates memory dynamically. -?? How can I help? - -{ST} Please see the contributing page: -http://www.gnu.org/software/hurd/contributing.html - ? Compiling ?? Where can I get the source? diff --git a/faq/old/old_hurd_faq.txt b/faq/old/old_hurd_faq.txt index 4ebe019b..20b4c260 100644 --- a/faq/old/old_hurd_faq.txt +++ b/faq/old/old_hurd_faq.txt @@ -16,73 +16,10 @@ Original Document by: Derek Upham Contents: -Q0. Where can I get the Unofficial GNU Hurd FAQ? -Q2. Where can I get a copy? -Q3. Why bother writing a new OS when we have Linux and 386/BSD? Q4. What's all this about Mach 3.0 (and Mach 4.0)? -Q5. Where can I find more information? -Q7. What sort of machines will run Hurd in the future? -Q8. What is the current development status? -Q9. What sort of system would we have if the Hurd was bootable today? ============================== -Q0. Where can I get the Unofficial GNU Hurd FAQ? - -The Unofficial Hurd FAQ (what you are reading now) is occasionally -posted to the USENET newsgroup, gnu.misc.discuss. It is also -available from - - http://www.enci.ucalgary.ca/~gord/hurd/hurd-faq.txt (Broken Link ?) - -If you don't have WWW access, you may send mail to me, Gordon -Matzigkeit with a subject line that reads: - - Subject: send hurd-faq - -You should receive a PGP-signed copy of the current version of this -document in a matter of minutes. - - -Q2. Where can I get a copy? - -To put it simply, you can't. It is still under development (by -Michael Bushnell, Roland McGrath and Miles Bader). It is almost, but -not quite, at the point where you can do real work on it. Keep your -fingers crossed. - -Some people have actually bootstrapped it, but the work is not easy, -and the current snapshot won't work until a new multiserver boot -mechanism is made. - -If you *really* want to try it, beware that it is still pre-alpha -code, and that it will likely crash on you. See Trent Fisher's Hurd -pages (under question 5) for the latest information. - - -Q3. Why bother writing a new OS when we have Linux and 386/BSD? - -For one thing, Linux and BSD don't scale well. Hardware designers are -shifting more and more toward multiprocessor machines for performance, -and standard Unix kernels do not provide much multiprocessor support. -The Hurd, on the other hand, runs on top of the Mach 3.0 micro-kernel -[[1]] from CMU. Mach was designed precisely for multiprocessing -machines, so its portability should carry over nicely to the Hurd. - -In addition, the Hurd will be considerably more flexible and robust -than generic Unix. Wherever possible, Unix kernel features have been -moved into unprivileged space. Once there, anyone who desires can -develop custom replacements for them. Users will be able to write and -use their own file systems, their own `exec' servers, or their own -network protocols if they like, all without disturbing other users. - -The Linux kernel has now been modified to allow user-level file -systems, so there is proof that people will actually use features such -as these. It will be much easier to do under the Hurd, however, -because the Hurd is almost entirely run in user space and because the -various servers are designed for this sort of modification. - - Q4. What's all this about Mach 3.0 (and Mach 4.0)? As mentioned above, Mach is a micro-kernel, written at Carnegie Mellon diff --git a/faq/support/2_gib_partition_limit.mdwn b/faq/support/2_gib_partition_limit.mdwn index 726605f9..3315cc08 100644 --- a/faq/support/2_gib_partition_limit.mdwn +++ b/faq/support/2_gib_partition_limit.mdwn @@ -11,3 +11,5 @@ is included in the section entitled [[!meta title="Is there still a 2 GiB Partition Limit ?"]] The 2 GiB limit has been removed in Debian GNU/Hurd. + +Disk drivers however currently do not support more than 2^32 sectors, i.e. 2TiB. -- cgit v1.2.3 From 37af1117a703d9b8ed3056bf24319988b640aea5 Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Sun, 17 Mar 2013 14:14:54 +0100 Subject: Drop useless index --- faq/old/old_hurd_faq.txt | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-) (limited to 'faq/old/old_hurd_faq.txt') diff --git a/faq/old/old_hurd_faq.txt b/faq/old/old_hurd_faq.txt index 20b4c260..20ce61a9 100644 --- a/faq/old/old_hurd_faq.txt +++ b/faq/old/old_hurd_faq.txt @@ -12,17 +12,7 @@ Louis-Dominique Dubeau Original Document by: Derek Upham -============================== - -Contents: - -Q4. What's all this about Mach 3.0 (and Mach 4.0)? - -============================== - -Q4. What's all this about Mach 3.0 (and Mach 4.0)? - -As mentioned above, Mach is a micro-kernel, written at Carnegie Mellon +Mach is a micro-kernel, written at Carnegie Mellon University. A more descriptive term might be a greatest-common-factor kernel, since it provides facilities common to all ``real'' operating systems, such as memory management, inter-process communication, -- cgit v1.2.3