Browse Source

Run update.sh

Docker Library Bot 10 years ago
parent
commit
2a33dad7b2
9 changed files with 11 additions and 11 deletions
  1. 1 1
      erlang/README.md
  2. 1 1
      golang/README.md
  3. 2 2
      hello-world/README.md
  4. 2 2
      hello-world/content.md
  5. 1 1
      iojs/README.md
  6. 1 1
      node/README.md
  7. 1 1
      pypy/README.md
  8. 1 1
      python/README.md
  9. 1 1
      ruby/README.md

+ 1 - 1
erlang/README.md

@@ -63,7 +63,7 @@ The `erlang` images come in many flavors, each designed for a specific use case.
 
 ## `erlang:<version>`
 
-This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of. This tag is based off of [`buildpack-deps`](https://registry.hub.docker.com/_/buildpack-deps/). `buildpack-deps` is designed for the average user of docker who has many images on their system. It, by design, has a large number of extremely common Debian packages. This reduces the number of packages that images that derive from it need to install, thus reducing the overall size of all images on your system.
+This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of.
 
 ## `erlang:onbuild`
 

+ 1 - 1
golang/README.md

@@ -82,7 +82,7 @@ The `golang` images come in many flavors, each designed for a specific use case.
 
 ## `golang:<version>`
 
-This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of. This tag is based off of [`buildpack-deps`](https://registry.hub.docker.com/_/buildpack-deps/). `buildpack-deps` is designed for the average user of docker who has many images on their system. It, by design, has a large number of extremely common Debian packages. This reduces the number of packages that images that derive from it need to install, thus reducing the overall size of all images on your system.
+This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of.
 
 ## `golang:alpine`
 

+ 2 - 2
hello-world/README.md

@@ -33,8 +33,8 @@ For more examples and ideas, visit:
 
 
 $ docker images hello-world
-REPOSITORY   TAG     IMAGE ID      SIZE
-hello-world  latest  690ed74de00f  960 B
+REPOSITORY   TAG     IMAGE ID      VIRTUAL SIZE
+hello-world  latest  0a6ba66e537a  960 B
 ```
 
 ![logo](https://raw.githubusercontent.com/docker-library/docs/master/hello-world/logo.png)

+ 2 - 2
hello-world/content.md

@@ -25,8 +25,8 @@ For more examples and ideas, visit:
 
 
 $ docker images hello-world
-REPOSITORY   TAG     IMAGE ID      SIZE
-hello-world  latest  690ed74de00f  960 B
+REPOSITORY   TAG     IMAGE ID      VIRTUAL SIZE
+hello-world  latest  0a6ba66e537a  960 B
 ```
 
 %%LOGO%%

+ 1 - 1
iojs/README.md

@@ -57,7 +57,7 @@ The `iojs` images come in many flavors, each designed for a specific use case.
 
 ## `iojs:<version>`
 
-This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of. This tag is based off of [`buildpack-deps`](https://registry.hub.docker.com/_/buildpack-deps/). `buildpack-deps` is designed for the average user of docker who has many images on their system. It, by design, has a large number of extremely common Debian packages. This reduces the number of packages that images that derive from it need to install, thus reducing the overall size of all images on your system.
+This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of.
 
 ## `iojs:onbuild`
 

+ 1 - 1
node/README.md

@@ -68,7 +68,7 @@ The `node` images come in many flavors, each designed for a specific use case.
 
 ## `node:<version>`
 
-This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of. This tag is based off of [`buildpack-deps`](https://registry.hub.docker.com/_/buildpack-deps/). `buildpack-deps` is designed for the average user of docker who has many images on their system. It, by design, has a large number of extremely common Debian packages. This reduces the number of packages that images that derive from it need to install, thus reducing the overall size of all images on your system.
+This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of.
 
 ## `node:onbuild`
 

+ 1 - 1
pypy/README.md

@@ -66,7 +66,7 @@ The `pypy` images come in many flavors, each designed for a specific use case.
 
 ## `pypy:<version>`
 
-This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of. This tag is based off of [`buildpack-deps`](https://registry.hub.docker.com/_/buildpack-deps/). `buildpack-deps` is designed for the average user of docker who has many images on their system. It, by design, has a large number of extremely common Debian packages. This reduces the number of packages that images that derive from it need to install, thus reducing the overall size of all images on your system.
+This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of.
 
 ## `pypy:onbuild`
 

+ 1 - 1
python/README.md

@@ -77,7 +77,7 @@ The `python` images come in many flavors, each designed for a specific use case.
 
 ## `python:<version>`
 
-This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of. This tag is based off of [`buildpack-deps`](https://registry.hub.docker.com/_/buildpack-deps/). `buildpack-deps` is designed for the average user of docker who has many images on their system. It, by design, has a large number of extremely common Debian packages. This reduces the number of packages that images that derive from it need to install, thus reducing the overall size of all images on your system.
+This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of.
 
 ## `python:onbuild`
 

+ 1 - 1
ruby/README.md

@@ -65,7 +65,7 @@ The `ruby` images come in many flavors, each designed for a specific use case.
 
 ## `ruby:<version>`
 
-This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of. This tag is based off of [`buildpack-deps`](https://registry.hub.docker.com/_/buildpack-deps/). `buildpack-deps` is designed for the average user of docker who has many images on their system. It, by design, has a large number of extremely common Debian packages. This reduces the number of packages that images that derive from it need to install, thus reducing the overall size of all images on your system.
+This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of.
 
 ## `ruby:onbuild`