diff --git a/docs/installation.adoc b/docs/installation.adoc
index a695bcd..bfaac6e 100644
--- a/docs/installation.adoc
+++ b/docs/installation.adoc
@@ -241,7 +241,8 @@
 $ cd kudu
 ----
 
-. Build any missing third-party requirements using the `build-if-necessary.sh` script.
+. Build any missing third-party requirements using the `build-if-necessary.sh` script. Not using
+the devtoolset will result in `Host compiler appears to require libatomic, but cannot find it.`
 +
 [source,bash]
 ----
@@ -250,7 +251,8 @@
 
 . Build Kudu, using the utilities installed in the previous step. Choose a build
 directory for the intermediate output, which can be anywhere in your filesystem
-except for the `kudu` directory itself.
+except for the `kudu` directory itself. Notice that the devtoolset must still be specified,
+else you'll get `cc1plus: error: unrecognized command line option "-std=c++11"`.
 +
 [source,bash]
 ----
diff --git a/java/README.md b/java/README.md
index 326c29b..157aafd 100644
--- a/java/README.md
+++ b/java/README.md
@@ -29,33 +29,10 @@
 The client jar will can then be found at kudu-client/target.
 
 
-Building the Kudu CSD
-------------------------------------------------------------
-
-By default, the Kudu CSD will not be built with the client.
-It requires access to the Kudu binaries which may not be
-available. For example, when building on OSX.
-
-Here's how to build the kudu-csd module:
-
-$ mvn package -DskipTests -PbuildCSD
-
-Also by default, building the CSD does not validate it,
-because (for the moment) this requires access to an internal
-Cloudera repository containing the validator maven plugin.
-
-Here's how to build the kudu-csd module with validation:
-
-$ mvn package -DskipTests -PbuildCSD -PvalidateCSD
-
-
 Running the Tests
 ------------------------------------------------------------
 
-Most of the unit tests will start their own cluster but it
-is also possible to provide your own.
-
-By default, the unit tests will start a master and a tablet
+The unit tests will start a master and a tablet
 server using the flags file located in the src/test/resources/
 directory. The tests will locate the master and tablet server
 binaries by looking in 'build/latest/bin' from the root of
@@ -66,20 +43,8 @@
 
 $ mvn test
 
-In order to point the unit tests to an existing cluster,
-you need to use a command line like this one:
-
-$ mvn test -DstartCluster=false
-
-If you choose to not start a cluster, the tests will look for
-a master running on localhost:7051. If you would like to run
-against a remote cluster, you can override this using
--DmasterAddress:
-
-$ mvn test -DstartCluster=false -DmasterAddress=foo.example.com:7051
-
-If for some reason you would like to start a cluster, but use
-binaries other than the ones in build/latest/, you can pass
+If for some reason the binaries aren't in the expected location
+as shown above, you can pass
 -DbinDir=/path/to/directory.
 
 Integration tests, including tests which cover Hadoop integration,
@@ -158,3 +123,25 @@
 
 There's a simple workaround: delete the errant folder within
 Eclipse and refresh the kudu-client project.
+
+
+Building the Kudu Custom Service Descriptor (CSD)
+------------------------------------------------------------
+
+By default, the Kudu CSD will not be built with the client
+and isn't needed by any API.
+
+It requires access to the Kudu binaries which have to be built
+prior to building this module.
+
+Here's how to build the kudu-csd module:
+
+$ mvn package -DskipTests -PbuildCSD
+
+Also by default, building the CSD does not validate it,
+because (for the moment) this requires access to an internal
+Cloudera repository containing the validator maven plugin.
+
+Here's how to build the kudu-csd module with validation:
+
+$ mvn package -DskipTests -PbuildCSD -PvalidateCSD
\ No newline at end of file