Stop deploying packages updated wording.

1 files changed, 8 insertions, 4 deletions

diff --git a/content/technical/stop-deploying-packages.md b/content/technical/stop-deploying-packages.md
index 3732a45..61228e1 100644
--- a/content/technical/stop-deploying-packages.md
+++ b/content/technical/stop-deploying-packages.md
@@ -3,15 +3,15 @@ Date: 2016-04-18 13:35
 Tags: linux, technical, kubernetes
 Slug: stop-deploying-packages
 Category: Linux
-Summary: Stop assembling packages while deploying a system. Stop using tools that assemble packages while dploying a production system.
+Summary: Packages shouldn't be assembled as you deploy a system. You shuold treat tools that assemble packages while deploying a production system are legacy tools.
 
-Stop assembling packages while deploying a system. Stop using tools that assemble packages while deploying a production system.
+Packages shouldn't be assembled as you deploy a system to production. You should treat tools that assemble packages while deploying a production system as legacy tools. Here's why.
 
 <div style="text-align: center">
 <img alt="Be prepared to stop" src="../images/be-prepared-to-stop.jpg">
 </div>
 
-Packages are for development. Whether that's developers of systems or developers of services. Don't use ```apt-get install``` or ```yum install``` or ```npm install``` or any of another hundred other package installers on your production systems. Use those tools as part of your build process.
+Packages are for when you're building a system or developing an application. Whether your building it to tinker, contribute, or building a system that will later be deployed into production. Tools like ```apt-get install``` or ```yum install``` or ```npm install``` or any of another hundred other package installers shouldn't be run on your in-production systems. Use those tools as part of your build process.
 
 <h3 style="text-align: center">Packages are build components</h3>
 
@@ -19,9 +19,11 @@ This applies to Linux distribution packages, RPMs, NPM packages, Ruby Gems, JAR
 
 When it comes time to deploy those systems, services or applications, don't assemble these parts all over again. Use what you assembled previously during development, the parts you integrated and tested. Deploy exactly those bits.
 
+An example: Any production system that was broken by the [NPM fiasco with left-pad in March 2016](http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/) got this wrong. Build systems should have broken, not deployments.
+
 <h3 style="text-align: center">It wasn't always this way</h3>
 
-Do you remember a time when you built your Linux or BSD systems from source every time on every machine? In fact, you can still do that today. There is even fancy tooling that lets you assemble stuff on your system from source with just a couple commands. But we moved on. Binary packages were born. We wanted a reproducible, verifiable, composable abstraction.
+Do you remember a time when you built your Linux or BSD systems from source every time on every machine? In fact, you can still do that today. There is even fancy tooling that lets you assemble stuff on your system from source with just a couple commands. But we moved beyond that. Binary packages were born. We wanted a reproducible, verifiable, composable abstraction.
 
 To this day, source code is still really important and a vital part of development, troubleshooting, not to mention a corner stone of [free software](http://www.gnu.org/philosophy/free-sw.en.html#content).
 
@@ -44,3 +46,5 @@ This move beyond packages is not done. Stands to reason, or I wouldn't be writin
 But the mindshift has already happened. The movement is underway and has significant momentum. By thinking about things in terms of the new reality we finish building out the remaining gray areas.
 
 Packages are development tools.
+
+<sup>Note: I changed a bit of the wording, after getting feedback from initial reviewers. Hopefully it helps the idea carry through better.</sup>