X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=doc%2Fintro.texi;h=27ee2cbd11c409d051fd1fbd27f380582825221a;hb=82281a670902d91868eb968db65a8c0dc9b4e502;hp=0a5f85bf44f4ecbbf5a51f91eac2d2c9a3538216;hpb=392931f3f604f0c8ceb7d97dba21c7fefa2a2187;p=pintos-anon

diff --git a/doc/intro.texi b/doc/intro.texi
index 0a5f85b..27ee2cb 100644
--- a/doc/intro.texi
+++ b/doc/intro.texi
@@ -16,9 +16,8 @@ CPU and its peripheral devices accurately enough that unmodified operating
 systems and software can run under it.  In class we will use the
 @uref{http://bochs.sourceforge.net, , Bochs} and 
 @uref{http://fabrice.bellard.free.fr/qemu/, ,
-qemu} simulators.  Pintos has also been tested with
-@uref{http://www.vmware.com/products/server/gsx_features.html, ,
-VMware GSX Server}.
+QEMU} simulators.  Pintos has also been tested with
+@uref{http://www.vmware.com/, , VMware Player}.
 
 These projects are hard.  CS 140 has a reputation of taking a lot of
 time, and deservedly so.  We will do what we can to reduce the workload, such
@@ -50,8 +49,9 @@ Stanford ITSS, as described on the
 @uref{http://www.stanford.edu/services/cluster/environs/sweet/, , ITSS
 webpage}.  You may use the Solaris or Linux machines.  We will test your
 code on these machines, and the instructions given here assume this
-environment.  However, Pintos and its supporting tools are portable
-enough that it should build ``out of the box'' in other environments.
+environment.  We cannot provide support for installing and working on
+Pintos on your own machine, but we provide instructions for doing so
+nonetheless (@pxref{Installing Pintos}).
 
 Once you've logged into one of these machines, either locally or
 remotely, start out by adding our binaries directory to your @env{PATH}
@@ -82,7 +82,7 @@ you log in.
 Now you can extract the source for Pintos into a directory named
 @file{pintos/src}, by executing
 @example
-tar xzf /usr/class/cs140/pintos/pintos.tar.gz
+zcat /usr/class/cs140/pintos/pintos.tar.gz | tar x
 @end example
 Alternatively, fetch
 @uref{http://@/www.stanford.edu/@/class/@/cs140/@/pintos/@/pintos.@/tar.gz}
@@ -250,7 +250,7 @@ from them by @option{--}, so that the whole command looks like
 @code{pintos @var{option}@dots{} -- @var{argument}@dots{}}.  Invoke
 @code{pintos} without any arguments to see a list of available options.
 Options can select a simulator to use: the default is Bochs, but
-@option{--qemu} selects qemu.  You can run the simulator
+@option{--qemu} selects QEMU.  You can run the simulator
 with a debugger (@pxref{GDB}).  You can set the amount of memory to give
 the VM.  Finally, you can select how you want VM output to be displayed:
 use @option{-v} to turn off the VGA display, @option{-t} to use your
@@ -308,9 +308,9 @@ timings, in which a one-second delay should take approximately one
 second of real time.  Simulation in real-time mode is not reproducible,
 and options @option{-j} and @option{-r} are mutually exclusive.
 
-The qemu simulator is available as an
+The QEMU simulator is available as an
 alternative to Bochs (use @option{--qemu} when invoking
-@command{pintos}).  The qemu simulator is much faster than Bochs, but it
+@command{pintos}).  The QEMU simulator is much faster than Bochs, but it
 only supports real-time simulation and does not have a reproducible
 mode.
 
@@ -338,7 +338,7 @@ After running all the tests, @command{make check} also prints a summary
 of the test results.
 
 For project 1, the tests will probably run faster in Bochs.  For the
-rest of the projects, they will run much faster in qemu.
+rest of the projects, they will run much faster in QEMU.
 @command{make check} will select the faster simulator by default, but
 you can override its choice by specifying @option{SIMULATOR=--bochs} or
 @option{SIMULATOR=--qemu} on the @command{make} command line.