anchor.diff:  There is never `blobstore_secret` line for blobstores of types other than
   `local`.
   
  -Also, be aware that the `local` type blobstore is essentially a convenience for
  +The `local` type blobstore is essentially a convenience for
   development.
  -Final releases should use a publically-accessible type of blobstore.
  +Final releases should use a non-local blobstore that is publicly accessible.
   
   ### <a id="inform"></a> Inform BOSH where blobs are ###
   
  -Each package has a `spec` file, which has a `files` block.
  -For packages whose content you downloaded from the internet,
  -the `files` block lists the binaries you downloaded, along with
  -the URLs from which you downloaded them.
  +In the package `spec` file, the `files` block lists any binaries you downloaded,
  +along with the URLs from which you downloaded them.
   (This assumes that you followed the directions in the [Update package specs](#update-pkging-specs) section.)
   
   Those files are blobs, and now you need the paths to the downloaded blobs on
  
positive.code: 
  `bosh add blob <path_to_blob_on_local_system> <package_name>`
  
  BOSH adds each blob to the `blobs` directory, in a subdirectory whose name is the
  second argument to the `bosh add blob` command.
  The package name is a good choice for that argument because it produces a
  cleanly-organized `blobs` directory.
  
  ### <a id="no-upload"></a> Do not upload blobs for a dev release ###
  
  
negative.code: ## <a id="blobs"></a> Add Blobs ##
  
  When creating a release, you likely use a source code repository.
  But releases often use tar files or other binaries, also known as blobs.
  Checking blobs into a repository may be problematic if the repository you use
  is not well-suited to dealing with large binaries.
  (Git, for example, is not.)
  