   shutting down, all applications shut down their top-level supervisor, which
   terminates children in the opposite order they are started.
 
-  We have mentioned the Mix build tool is responsible for compiling applications,
-  but it is also capable of running applications. For example, `mix test`
-  automatically starts your application dependencies and your application itself
-  before your test runs. `mix run --no-halt` also boots your current project and
+  Shutting down a live system cleanly can be done by calling `System.stop/1`.
+  It will shut down all applications in the opposite order they are started.
+  Each application will then shutdown its top-level supervisor, if one is
+  available, [which then shuts down its children](Supervisor.html#module-start-and-shutdown).
+
+  From Erlang/OTP 19.1, a SIGTERM from the operating system will automatically
+  translate to `System.stop/0`. Erlang/OTP 20 gives user more explicit control
+  over OS signals via the `:os.set_signal/2` function.
+
+  ### Application module callback
+
+  An application may start and stop a supervision tree when it boots via
+  the application module callback.
+
+  The first step is to pass the module callback in the application definition
+  in the `mix.exs` file:
+
+      def application do
+        [mod: {MyApp, []}]
+      end
+
+  Our application now requires the `MyApp` module to provide an application
+  callback. This can be done by invoking `use Application` in that module and
+  defining a `start/2` callback, for example:
+
+      defmodule MyApp do
+        use Application
+
+        def start(_type, _args) do
+          children = []
+          Supervisor.start_link(children, strategy: :one_for_one)
+        end
+      end
+
+  `start/2` typically returns `{:ok, pid}` or `{:ok, pid, state}` where
+  `pid` identifies the supervision tree and `state` is the application state.
+  `args` is the second element of the tuple given to the `:mod` option.
+
+  The `type` argument passed to `start/2` is usually `:normal` unless in a
+  distributed setup where application takeovers and failovers are configured.
+  Distributed applications is beyond the scope of this documentation. For those
+  interested on the topic, please access the OTP documentation:
+
+    * [`:application` module](http://www.erlang.org/doc/man/application.html)
+    * [Applications – OTP Design Principles](http://www.erlang.org/doc/design_principles/applications.html)
+
+  A developer may also implement the `stop/1` callback (automatically defined
+  by `use Application`) which does any application cleanup. It receives the
+  application state and can return any value. Note that shutting down the
+  supervisor is automatically handled by the VM.
+
+  An application without a supervision tree doesn't define an application
+  module callback in the application definition in `mix.exs` file. Even though
+  there is no module with application callbacks such as `start/2` and
+  `stop/1`, the application can be started and stopped the same way as an
+  application with a supervision tree.
+
+  ## Tooling
+
+  The Mix build tool can also be used to start your applications. For example,
+  `mix test` automatically starts your application dependencies and your application
+  itself before your test runs. `mix run --no-halt` boots your current project and
   can be used to start a long running system. See `mix help run`.
 
   Developers can also use tools like [Distillery](https://github.com/bitwalker/distillery)

  when tools must be shared between developers and not as deployment options.
  See `mix help archive.build` and `mix help escript.build` for more detail.

  Shutting down a live system cleanly can be done by calling `System.stop/1`.
  It will shut down all applications in the opposite order they are started.
  Each application will then shutdown its top-level supervisor, if one is
  available, which then shuts down its children.

  From Erlang/OTP 19.1, a SIGTERM from the operating system will automatically
  translate to `System.stop/0`. Erlang/OTP 20 gives user more explicit control
  over OS signals via the `:os.set_signal/2` function.

  Applications also provide an "application environment", which is how
  applications are configured. The application environment can either be set
  statically, via a configuration file, or dynamically via `put_env/3` and
  friends.

  Over the next sections, we will cover the "application environment" and
  the "application module callback" in more detail.

  ## Application environment

  Once an application is started, OTP provides an application environment

  system. Instead, you start one or more applications, each with their own
  initialization and termination logic.

  Applications also provide an "application environment", which provides one
  mechanism for configuring long running applications. We will learn more about
  the tooling, start and shutdown and the application environment in the next
  sections.

  ## Start and shutdown

  Starting an application is done via the "application module callback", which
  is a module that defines the `start/2` function. The `start/2` function should
  then start a supervisor, which is often called as the top-level supervisor, since
