Improvements to notebooks that rely on distribution

lib/livebook/notebook/explore/distributed_portals_with_elixir.livemd

@@ -13,6 +13,8 @@ For a more structured introduction to the language, see [Elixir's
 Getting Started guide](https://elixir-lang.org/getting-started/introduction.html)
 and [the many learning resources available](https://elixir-lang.org/learning.html).
 
+<!-- livebook:{"break_markdown":true} -->
+
 ### The plan ahead
 
 The Portal game consists of a series of puzzles that must be
@@ -647,6 +649,8 @@ However, before we start, there is one big disclaimer:
 > resources available for Elixir, which will provide a more solid ground to
 > leverage the Erlang VM and its distributed features.
 
+<!-- livebook:{"break_markdown":true} -->
+
 ### Distribution 101
 
 When Livebook executes the code in a notebook, it starts a separate Elixir
@@ -694,6 +698,8 @@ Node.get_cookie()
 
 Now we have everything we need to connect across notebooks.
 
+<!-- livebook:{"break_markdown":true} -->
+
 ### Notebook connections
 
 In order to connect across notebooks, open up [a new empty notebook](/explore/notebooks/new)
@@ -757,9 +763,9 @@ Portal code has been defined in this notebook but it is not available
 in the other notebook. If we were working on an actual Elixir project,
 this issue wouldn't exist, because we would start multiple nodes on top
 of the same codebase with the same modules, but we can't do so here.
-To work around this, you should simply copy the cell that define the
-`Portal.Door` module from this notebook into the other notebook and
-execute it. Now we should be able to shoot a door in the other node:
+To work around this, copy the cell that defines the `Portal.Door` module
+from this notebook into the other notebook and execute it. Now in the other
+node you should be able to start a door:
 
 <!-- livebook:{"force_markdown":true} -->
 
@@ -767,12 +773,14 @@ execute it. Now we should be able to shoot a door in the other node:
 Portal.Door.start_link(:blue)
 ```
 
+<!-- livebook:{"break_markdown":true} -->
+
 ### Cross-node references
 
 Now that we have spawned a door on the other notebook, we can directly read
-its content from this notebook. So far, we have been using an atom, such
-as `:blue`, to represent the doors, but we can also use the `{name, node}`
-notation to refer to a process in another node. Let's give it a try:
+its content from this notebook. So far, we have been using atoms to represent
+doors, such as `:blue`, but we can also use the `{name, node}` notation to refer
+to a process in another node. Let's give it a try:
 
 ```elixir
 blue = {:blue, other_node}

lib/livebook/notebook/explore/vm_introspection.livemd

@@ -24,25 +24,20 @@ alias VegaLite, as: Vl
 
 ## Connecting to a remote node
 
-While Livebook can run a notebook directly inside a remote node,
-this time we will connect to a running node manually to minimize
-the impact in the remote system. This will also give you a better
-idea of how you can inspect a remote node in general.
-
-The first thing we need is a separate Elixir node. For this example,
-you can do so by opening up [a new notebook](/explore/notebooks/new),
-since Livebook automatically starts each notebook as a remote node.
-
-In practice, you may want to start an existing Elixir system,
-such as by running the following in your production app:
+The first thing we need is a separate Elixir node. In practice,
+you would start an external Elixir system, such as by running the
+following in your production app:
 
 ```
-elixir --name my_app@IP -S mix TASK
+iex --name my_app@IP -S mix TASK
 ```
 
-Or by connecting to a production assembled via
+Or by connecting to a production node assembled via
 [`mix release`](https://hexdocs.pm/mix/Mix.Tasks.Release.html).
 
+For convenience, however, you can simply start [a new notebook](/explore/notebooks/new),
+since Livebook automatically starts each notebook as a remote node.
+
 Once you start a new notebook, you can find its node name and
 cookie by running the following inside an Elixir cell: