Docs update for new tarball release

We no longer have users install lein, and demo use of `./maelstrom`
throughout the guide.

doc/01-getting-ready/index.md

@@ -20,16 +20,6 @@ OpenJDK Runtime Environment (build 14.0.2+12-Debian-2)
 OpenJDK 64-Bit Server VM (build 14.0.2+12-Debian-2, mixed mode, sharing)
 ```
 
-### Leiningen
-
-Leiningen is a build system for the Clojure language, and is how we'll run
-Maelstrom. To install it, see the [Lein installation docs](https://leiningen.org/#install). Once installed, you should be able to run:
-
-```
-$ lein --version
-Leiningen 2.9.4 on Java 14.0.2 OpenJDK 64-Bit Server VM
-```
-
 ### Graphviz
 
 Maelstrom uses [Graphviz](https://graphviz.org/) to generate plots of
@@ -55,6 +45,16 @@ $ gnuplot --version
 gnuplot 5.4 patchlevel 1
 ```
 
+## Installation
+
+Download the latest tarball from
+[https://github.com/jepsen-io/maelstrom/releases/latest](github), and untar it
+anywhere. In that directory, run `./maelstrom <args>` to launch Maelstrom.
+
+If you'd like to run the latest development builds instead, then install
+Leinigen (the Clojure build tool), clone this repository, and use `./maelstrom
+<args>` instead of `./maelstrom <args>`.
+
 ## Run a Demo
 
 To check that everything's ready to go, you can run Maelstrom against a
@@ -101,7 +101,7 @@ Type `[Control] + [c]` to exit the server.
 Now, let's run Maelstrom, and ask it to test the server:
 
 ```
-lein run test -w echo --bin demo/ruby/echo.rb --time-limit 5
+./maelstrom test -w echo --bin demo/ruby/echo.rb --time-limit 5
 ```
 
 This starts a Maelstrom test with the `echo` [workload](/doc/workloads.md).
@@ -153,7 +153,7 @@ symlink to the most recently completed test. In that directory, you'll find:
 You can browse these files using a file explorer, at the console, or via a web server that comes built-in to Maelstrom. In the main `maelstrom` directory, run:
 
 ```sh
-lein run serve
+./maelstrom serve
 22:41:00.605 [main] INFO  jepsen.web - Web server running.
 22:41:00.608 [main] INFO  jepsen.cli - Listening on http://0.0.0.0:8080/
 ```

doc/02-echo/index.md

@@ -64,7 +64,7 @@ one instance of that server on a node called `n1`, that we'd like to run the
 test for ten seconds, and that we'd like to see stderr log messages in the Maelstrom logs.
 
 ```
-$ lein run test -w echo --bin echo.rb --nodes n1 --time-limit 10 --log-stderr
+$ ./maelstrom test -w echo --bin echo.rb --nodes n1 --time-limit 10 --log-stderr
 ...
 INFO [2021-02-07 16:33:15,155] jepsen node n1 - maelstrom.db Setting up n1
 INFO [2021-02-07 16:33:15,156] jepsen node n1 - maelstrom.process launching demo/echo/echo_demo.rb nil
@@ -110,7 +110,7 @@ In the main loop, we'll parse each line we receive as JSON.
 Let's give that a shot:
 
 ```
-$ lein run test -w echo --bin echo.rb --nodes n1 --time-limit 10 --log-stderr
+$ ./maelstrom test -w echo --bin echo.rb --nodes n1 --time-limit 10 --log-stderr
 ...
 INFO [2021-02-08 10:34:21,262] node n1 - maelstrom.process Received {:dest=>"n1", :body=>{:type=>"init", :node_id=>"n1", :node_ids=>["n1"], :msg_id=>1}, :src=>"c1"}
 ...
@@ -141,7 +141,7 @@ extract the node ID, and use it to initialize our own state.
 ```
 
 ```
-$ lein run test -w echo --bin echo.rb --nodes n1 --time-limit 10 --log-stderr
+$ ./maelstrom test -w echo --bin echo.rb --nodes n1 --time-limit 10 --log-stderr
 ...
 INFO [2021-02-08 10:36:24,323] node n1 - maelstrom.process Received {:dest=>"n1", :body=>{:type=>"init", :node_id=>"n1", :node_ids=>["n1"], :msg_id=>1}, :src=>"c1"}
 INFO [2021-02-08 10:36:24,325] node n1 - maelstrom.process Initialized node n1
@@ -249,7 +249,7 @@ we initialized OK.
 Let's give that a shot!
 
 ```
-$ lein run test -w echo --bin echo.rb --nodes n1 --time-limit 10 --log-stderr
+$ ./maelstrom test -w echo --bin echo.rb --nodes n1 --time-limit 10 --log-stderr
 ...
 INFO [2021-02-08 11:17:57,613] jepsen node n1 - maelstrom.db Setting up n1
 INFO [2021-02-08 11:17:57,615] jepsen node n1 - maelstrom.process launching echo.rb nil
@@ -308,7 +308,7 @@ Let's try replying with the same body we were given:
 Let's try that out:
 
 ```clj
-$ lein run test -w echo --bin echo.rb --nodes n1 --time-limit 10 --log-stderr
+$ ./maelstrom test -w echo --bin echo.rb --nodes n1 --time-limit 10 --log-stderr
 ...
 clojure.lang.ExceptionInfo: Malformed RPC response. Maelstrom sent node n1 the following request:
 
@@ -344,7 +344,7 @@ with the same body we took in! Let's fix that:
 ```
 
 ```clj
-$ lein run test -w echo --bin echo.rb --nodes n1 --time-limit 10
+$ ./maelstrom test -w echo --bin echo.rb --nodes n1 --time-limit 10
 ...
 INFO [2021-02-22 13:54:50,633] jepsen test runner - jepsen.core Relative time begins now
 INFO [2021-02-22 13:54:50,647] jepsen worker 0 - jepsen.util 0	:invoke	:echo	"Please echo 58"
@@ -401,7 +401,7 @@ send to see if Maelstrom notices.
 ```
 
 ```
-$ lein run test -w echo --bin echo.rb --nodes n1 --time-limit 10
+$ ./maelstrom test -w echo --bin echo.rb --nodes n1 --time-limit 10
 ...
  :workload {:valid? false,
             :errors (["Expected a message with :echo"

doc/03-broadcast/01-broadcast.md

@@ -239,7 +239,7 @@ Let's start our node, and see if it responds to an `init` message appropriately:
 
 ```
 $ chmod +x broadcast.rb
-$ lein run test -w broadcast --bin broadcast.rb --time-limit 5 --log-stderr
+$ ./maelstrom test -w broadcast --bin broadcast.rb --time-limit 5 --log-stderr
 ...
 INFO [2021-02-23 09:35:26,128] jepsen node n1 - maelstrom.db Setting up n1
 INFO [2021-02-23 09:35:26,129] jepsen node n1 - maelstrom.process launching broadcast.rb nil
@@ -297,7 +297,7 @@ it when a topology message arrives.
 Let's give that a shot.
 
 ```
-$ lein run test -w broadcast --bin broadcast.rb --time-limit 5 --log-stderr
+$ ./maelstrom test -w broadcast --bin broadcast.rb --time-limit 5 --log-stderr
 ...
 INFO [2021-02-23 10:08:50,936] n3 stderr - maelstrom.process My neighbors are ["n2"]
 INFO [2021-02-23 10:08:50,936] n5 stderr - maelstrom.process My neighbors are ["n2", "n4"]
@@ -368,7 +368,7 @@ And whenever we receive a `broadcast` message, we'll add that message's message
 Let's try that out! We'll dial up the request rate to see how nodes change over time:
 
 ```
-$ lein run test -w broadcast --bin broadcast.rb --time-limit 5 --rate 10
+$ ./maelstrom test -w broadcast --bin broadcast.rb --time-limit 5 --rate 10
 ...
 INFO [2021-02-23 10:30:56,288] jepsen worker 0 - jepsen.util 0	:invoke	:broadcast	0
 INFO [2021-02-23 10:30:56,290] jepsen worker 0 - jepsen.util 0	:ok	:broadcast	0
@@ -477,7 +477,7 @@ messages to tell whether to reply or not.
 Let's see what happens!
 
 ```
-$ lein run test -w broadcast --bin broadcast.rb --time-limit 5 --rate 10
+$ ./maelstrom test -w broadcast --bin broadcast.rb --time-limit 5 --rate 10
 ...
 NFO [2021-02-23 11:21:52,923] jepsen worker 2 - jepsen.util 2	:invoke	:broadcast	0
 INFO [2021-02-23 11:21:53,057] jepsen worker 3 - jepsen.util 3	:invoke	:broadcast	1
@@ -547,7 +547,7 @@ already have it.
 Let's see what happens:
 
 ```
-$ lein run test -w broadcast --bin broadcast.rb --time-limit 5 --rate 10
+$ ./maelstrom test -w broadcast --bin broadcast.rb --time-limit 5 --rate 10
 ...
  :net {:stats {:all {:send-count 450,
                      :recv-count 450,

doc/03-broadcast/02-performance.md

@@ -19,7 +19,7 @@ network behavior. Let's raise the request rate and time limit to get a better
 picture.
 
 ```edn
-$ lein run test -w broadcast --bin broadcast.rb --time-limit 20 --rate 100
+$ ./maelstrom test -w broadcast --bin broadcast.rb --time-limit 20 --rate 100
 ...
  :net {:stats {...
                :servers {:send-count 9980,
@@ -68,7 +68,7 @@ Looking at messages.svg, you might notice something: we often broadcast a messag
 
 
 ```edn
-$ lein run test -w broadcast --bin broadcast.rb --time-limit 20 --rate 100
+$ ./maelstrom test -w broadcast --bin broadcast.rb --time-limit 20 --rate 100
 ...
                :servers {:send-count 5916,
                          :recv-count 5916,
@@ -84,7 +84,7 @@ the number of nodes to, say, a 5x5 grid, we'd expect to see more inter-node
 messages--nodes in the middle might have as many as 4 neighbors.
 
 ```edn
-$ lein run test -w broadcast --bin broadcast.rb --time-limit 20 --rate 100 --node-count 25
+$ ./maelstrom test -w broadcast --bin broadcast.rb --time-limit 20 --rate 100 --node-count 25
 ...
                :servers {:send-count 56280,
                          :recv-count 56280,
@@ -107,7 +107,7 @@ could arrange our nodes in a straight line, such that each has exactly two
 neighbors. It might take fewer messages per broadcast in this kind of topology. We can ask Maelstrom for a linear topology by passing `--topology line`:
 
 ```edn
-$ lein run test -w broadcast --bin broadcast.rb --time-limit 20 --rate 100 --node-count 25 --topology line
+$ ./maelstrom test -w broadcast --bin broadcast.rb --time-limit 20 --rate 100 --node-count 25 --topology line
 ...
                :servers {:send-count 24120,
                          :recv-count 24120,
@@ -137,7 +137,7 @@ little network latency. `--latency 10` tells Maelstrom to wait about ten
 milliseconds before delivering each (inter-server) message.
 
 ```edn
-lein run test -w broadcast --bin broadcast.rb --time-limit 20 --rate 100 --node-count 25 --topology line --latency 10
+./maelstrom test -w broadcast --bin broadcast.rb --time-limit 20 --rate 100 --node-count 25 --topology line --latency 10
 ...
             :attempt-count 959,
             :stable-count 959,
@@ -160,7 +160,7 @@ hops x 10 ms/hop to propagate completely.
 What about the grid topology we started with? Is it more efficient?
 
 ```edn
-$ lein run test -w broadcast --bin broadcast.rb --time-limit 20 --rate 100 --node-count 25 --topology grid --latency 10
+$ ./maelstrom test -w broadcast --bin broadcast.rb --time-limit 20 --rate 100 --node-count 25 --topology grid --latency 10
 ...
             :stable-latencies {0 0, 0.5 11, 0.95 42, 0.99 56, 1 72},
 ```
@@ -182,7 +182,7 @@ between reads on each node, it's easy for small latencies to slip through the
 cracks. Let's raise the latency to get a better picture of the distribution:
 
 ```edn
-$ lein run test -w broadcast --bin broadcast.rb --time-limit 20 --rate 100 --node-count 25 --topology grid --latency 100
+$ ./maelstrom test -w broadcast --bin broadcast.rb --time-limit 20 --rate 100 --node-count 25 --topology grid --latency 100
 ...
             :stable-latencies {0 0,
                                0.5 452,
@@ -202,7 +202,7 @@ with a constant 100 ms of latency. What happens if not every message is delayed
 by the same amount?
 
 ```edn
-$ lein run test -w broadcast --bin broadcast.rb --time-limit 20 --rate 100 --node-count 25 --topology grid --latency 100 --latency-dist exponential
+$ ./maelstrom test -w broadcast --bin broadcast.rb --time-limit 20 --rate 100 --node-count 25 --topology grid --latency 100 --latency-dist exponential
 ...
             :stable-latencies {0 0,
                                0.5 229,
@@ -220,7 +220,7 @@ node immediately? `--topology total` tells Maelstrom to make each node a
 neighbor of every other node.
 
 ```edn
-$ lein run test -w broadcast --bin broadcast.rb --time-limit 20 --rate 100 --node-count 25 --topology total --latency 100
+$ ./maelstrom test -w broadcast --bin broadcast.rb --time-limit 20 --rate 100 --node-count 25 --topology total --latency 100
 ...
             :stable-latencies {0 0, 0.5 77, 0.95 95, 0.99 96, 1 97},
 ```
@@ -246,7 +246,7 @@ prohibitive, and drive up normal network delays.
 Is there an approach that balances latency with message costs? What about forming a *spanning tree* over the nodes?
 
 ```edn
-$ lein run test -w broadcast --bin broadcast.rb --time-limit 20 --rate 100 --node-count 25 --topology tree4 --latency 100
+$ ./maelstrom test -w broadcast --bin broadcast.rb --time-limit 20 --rate 100 --node-count 25 --topology tree4 --latency 100
 ...
                :servers {:send-count 24744,
                          :recv-count 24744,
@@ -278,7 +278,7 @@ all messages are lost from one node to another. Let's try introducing some
 partitions into our broadcast system.
 
 ```clj
-$ lein run test -w broadcast --bin broadcast.rb --time-limit 20 --nemesis partition
+$ ./maelstrom test -w broadcast --bin broadcast.rb --time-limit 20 --nemesis partition
 ...
             :valid? false,
             :lost-count 8,
@@ -451,7 +451,7 @@ replicate asynchronously.
 Let's try that out.
 
 ```
-$ lein run test -w broadcast --bin broadcast.rb --time-limit 20 --topology tree4 --nemesis partition
+$ ./maelstrom test -w broadcast --bin broadcast.rb --time-limit 20 --topology tree4 --nemesis partition
 ...
 INFO [2021-02-24 17:19:12,535] jepsen worker 2 - jepsen.util 2	:invoke	:broadcast	6
 INFO [2021-02-24 17:19:12,537] jepsen worker 2 - jepsen.util 2	:ok	:broadcast	6
@@ -514,7 +514,7 @@ rather than sharing them as the mainloop goes onto the next message.
 Let's see what happens:
 
 ``` edn
-$ lein run test -w broadcast --bin broadcast.rb --time-limit 20 --topology tree4 --nemesis partition
+$ ./maelstrom test -w broadcast --bin broadcast.rb --time-limit 20 --topology tree4 --nemesis partition
 ...
  :net {:stats {:all {:send-count 1277,
                      :recv-count 734,

doc/04-crdts/01-g-set.md

@@ -121,7 +121,7 @@ We haven't done any kind of inter-node replication yet, but let's see what
 happens anyway. We'll have Maelstrom use the `g-set` workload on this binary. In particular, we're looking to make sure that reads and writes can actually execute, and that *some* values get returned:
 
 ```
-$ lein run test -w g-set --bin g_set.rb
+$ ./maelstrom test -w g-set --bin g_set.rb
 ...
 INFO [2021-02-25 10:48:13,039] jepsen worker 3 - jepsen.util 3	:invoke	:add	0
 INFO [2021-02-25 10:48:13,042] jepsen worker 3 - jepsen.util 3	:ok	:add	0
@@ -172,7 +172,7 @@ more efficient, but this is a good place to start.
 Let's see how that goes:
 
 ```clj
-$ lein run test -w g-set --bin g_set.rb --time-limit 10
+$ ./maelstrom test -w g-set --bin g_set.rb --time-limit 10
 ...
             :valid? true,
             :lost-count 0,
@@ -220,7 +220,7 @@ replication rounds, times five nodes, times four messages each.
 What happens if we ramp up the request rate?
 
 ```clj
-$ lein run test -w g-set --bin g_set.rb --time-limit 10 --rate 100
+$ ./maelstrom test -w g-set --bin g_set.rb --time-limit 10 --rate 100
 ...
  :net {:stats {:all {:send-count 2136,
                      :recv-count 2136,
@@ -252,7 +252,7 @@ What about network partitions? Can we still make progress when the network is
 partitioned? Are writes lost?
 
 ```clj
-$ lein run test -w g-set --bin g_set.rb --time-limit 30 --rate 10 --nemesis partition
+$ ./maelstrom test -w g-set --bin g_set.rb --time-limit 30 --rate 10 --nemesis partition
 ...
 Everything looks good! ヽ(‘ー`)ノ
 ```
@@ -376,7 +376,7 @@ of our defensive locking.
 We can double-check that this behaves identically to the hardcoded set:
 
 ```rb
-$ lein run test -w g-set --bin g_set.rb --time-limit 20 --rate 10
+$ ./maelstrom test -w g-set --bin g_set.rb --time-limit 20 --rate 10
 ...
             :stable-latencies {0 0,
                                0.5 2233,

doc/04-crdts/02-counters.md

@@ -130,7 +130,7 @@ CounterServer.new.node.main!
 Let's try this out with a workload of increments, and see what happens:
 
 ```clj
-$ lein run test -w g-counter --bin counter.rb --time-limit 20 --rate 10
+$ ./maelstrom test -w g-counter --bin counter.rb --time-limit 20 --rate 10
 ...
  :workload {:valid? true,
             :errors nil,
@@ -151,7 +151,7 @@ value was within the acceptable range of outcomes: [152, 152].
 What happens if we allow *decrements* of the value? Let's use the [pn-counter](/doc/workloads.md#workload-pn-counter) workload and see.
 
 ```clj
-$ lein run test -w pn-counter --bin counter.rb --time-limit 20 --rate 10
+$ ./maelstrom test -w pn-counter --bin counter.rb --time-limit 20 --rate 10
 ...
             :final-reads (11 11 11 11 11),
             :acceptable ([-38 -38])},
@@ -248,7 +248,7 @@ class CounterServer
 ```
 
 ```clj
-$ lein run test -w pn-counter --bin counter.rb --time-limit 20 --rate 10
+$ ./maelstrom test -w pn-counter --bin counter.rb --time-limit 20 --rate 10
 ...
  :workload {:valid? true,
             :errors nil,
@@ -263,7 +263,7 @@ Everything looks good! ヽ(‘ー`)ノ
 Now we can handle decrements as well! Is it partition-tolerant?
 
 ```clj
-$ lein run test -w pn-counter --bin counter.rb --time-limit 30 --rate 10 --nemesis partition
+$ ./maelstrom test -w pn-counter --bin counter.rb --time-limit 30 --rate 10 --nemesis partition
 ...
  :workload {:valid? true,
             :errors nil,