README: remove original shipping containers 'manifesto'. It's a little long to stay here.

README.md

@@ -188,142 +188,6 @@ They are probably not perfect, please let us know if anything feels
 wrong or incomplete.
 
 
-Note
-----
-
-We also keep the documentation in this repository. The website
-documentation is generated using Sphinx using these sources.  Please
-find it under docs/sources/ and read more about it
-https://github.com/dotcloud/docker/tree/master/docs/README.md
-
-Please feel free to fix / update the documentation and send us pull
-requests. More tutorials are also welcome.
-
-
-Setting up a dev environment
-----------------------------
-
-Instructions that have been verified to work on Ubuntu 12.10,
-
-```bash
-sudo apt-get -y install lxc curl xz-utils golang git mercurial
-
-export GOPATH=~/go/
-export PATH=$GOPATH/bin:$PATH
-
-mkdir -p $GOPATH/src/github.com/dotcloud
-cd $GOPATH/src/github.com/dotcloud
-git clone https://github.com/dotcloud/docker.git
-cd docker
-
-go get -v github.com/dotcloud/docker/...
-go install -v github.com/dotcloud/docker/...
-```
-
-Then run the docker daemon,
-
-```bash
-sudo $GOPATH/bin/docker -d
-```
-
-Run the `go install` command (above) to recompile docker.
-
-
-What is a Standard Container?
-=============================
-
-Docker defines a unit of software delivery called a Standard
-Container. The goal of a Standard Container is to encapsulate a
-software component and all its dependencies in a format that is
-self-describing and portable, so that any compliant runtime can run it
-without extra dependencies, regardless of the underlying machine and
-the contents of the container.
-
-The spec for Standard Containers is currently a work in progress, but
-it is very straightforward. It mostly defines 1) an image format, 2) a
-set of standard operations, and 3) an execution environment.
-
-A great analogy for this is the shipping container. Just like how
-Standard Containers are a fundamental unit of software delivery,
-shipping containers are a fundamental unit of physical delivery.
-
-### 1. STANDARD OPERATIONS
-
-Just like shipping containers, Standard Containers define a set of
-STANDARD OPERATIONS. Shipping containers can be lifted, stacked,
-locked, loaded, unloaded and labelled. Similarly, Standard Containers
-can be started, stopped, copied, snapshotted, downloaded, uploaded and
-tagged.
-
-
-### 2. CONTENT-AGNOSTIC
-
-Just like shipping containers, Standard Containers are
-CONTENT-AGNOSTIC: all standard operations have the same effect
-regardless of the contents. A shipping container will be stacked in
-exactly the same way whether it contains Vietnamese powder coffee or
-spare Maserati parts. Similarly, Standard Containers are started or
-uploaded in the same way whether they contain a postgres database, a
-php application with its dependencies and application server, or Java
-build artifacts.
-
-
-### 3. INFRASTRUCTURE-AGNOSTIC
-
-Both types of containers are INFRASTRUCTURE-AGNOSTIC: they can be
-transported to thousands of facilities around the world, and
-manipulated by a wide variety of equipment. A shipping container can
-be packed in a factory in Ukraine, transported by truck to the nearest
-routing center, stacked onto a train, loaded into a German boat by an
-Australian-built crane, stored in a warehouse at a US facility,
-etc. Similarly, a standard container can be bundled on my laptop,
-uploaded to S3, downloaded, run and snapshotted by a build server at
-Equinix in Virginia, uploaded to 10 staging servers in a home-made
-Openstack cluster, then sent to 30 production instances across 3 EC2
-regions.
-
-
-### 4. DESIGNED FOR AUTOMATION
-
-Because they offer the same standard operations regardless of content
-and infrastructure, Standard Containers, just like their physical
-counterparts, are extremely well-suited for automation. In fact, you
-could say automation is their secret weapon.
-
-Many things that once required time-consuming and error-prone human
-effort can now be programmed. Before shipping containers, a bag of
-powder coffee was hauled, dragged, dropped, rolled and stacked by 10
-different people in 10 different locations by the time it reached its
-destination. 1 out of 50 disappeared. 1 out of 20 was damaged. The
-process was slow, inefficient and cost a fortune - and was entirely
-different depending on the facility and the type of goods.
-
-Similarly, before Standard Containers, by the time a software
-component ran in production, it had been individually built,
-configured, bundled, documented, patched, vendored, templated, tweaked
-and instrumented by 10 different people on 10 different
-computers. Builds failed, libraries conflicted, mirrors crashed,
-post-it notes were lost, logs were misplaced, cluster updates were
-half-broken. The process was slow, inefficient and cost a fortune -
-and was entirely different depending on the language and
-infrastructure provider.
-
-
-### 5. INDUSTRIAL-GRADE DELIVERY
-
-There are 17 million shipping containers in existence, packed with
-every physical good imaginable. Every single one of them can be loaded
-onto the same boats, by the same cranes, in the same facilities, and
-sent anywhere in the World with incredible efficiency. It is
-embarrassing to think that a 30 ton shipment of coffee can safely
-travel half-way across the World in *less time* than it takes a
-software team to deliver its code from one datacenter to another
-sitting 10 miles away.
-
-With Standard Containers we can put an end to that embarrassment, by
-making INDUSTRIAL-GRADE DELIVERY of software a reality.
-
-
 ### Legal
 
 Transfers of Docker shall be in accordance with applicable export