docs: fix typos, edited for clarity

A few typos here and there. Excised some excess.

Signed-off-by: Steve Francis <steve.francis@talos-systems.com>

website/content/v1.0/learn-more/architecture.md

@@ -6,14 +6,13 @@ description: "Learn the system architecture of Talos Linux itself."
 
 Talos is designed to be **atomic** in _deployment_ and **modular** in _composition_.
 
-It is atomic in the sense that the entirety of Talos is distributed as a
+It is atomic in that the entirety of Talos is distributed as a
 single, self-contained image, which is versioned, signed, and immutable.
 
-It is modular in the sense that it is composed of many separate components
+It is modular in that it is composed of many separate components
 which have clearly defined gRPC interfaces which facilitate internal flexibility
 and external operational guarantees.
 
-There are a number of components which comprise Talos.
 All of the main Talos components communicate with each other by gRPC, through a socket on the local machine.
 This imposes a clear separation of concerns and ensures that changes over time which affect the interoperation of components are a part of the public git record.
 The benefit is that each component may be iterated and changed as its needs dictate, so long as the external API is controlled.
@@ -32,19 +31,19 @@ Talos uses these partitions with the following labels:
 
 ## The File System
 
-One of the more unique design decisions in Talos is the layout of the root file system.
+One of the unique design decisions in Talos is the layout of the root file system.
 There are three "layers" to the Talos root file system.
-At its' core the rootfs is a read-only squashfs.
+At its core the rootfs is a read-only squashfs.
 The squashfs is then mounted as a loop device into memory.
 This provides Talos with an immutable base.
 
 The next layer is a set of `tmpfs` file systems for runtime specific needs.
 Aside from the standard pseudo file systems such as `/dev`, `/proc`, `/run`, `/sys` and `/tmp`, a special `/system` is created for internal needs.
 One reason for this is that we need special files such as `/etc/hosts`, and `/etc/resolv.conf` to be writable (remember that the rootfs is read-only).
-For example, at boot Talos will write `/system/etc/hosts` and the bind mount it over `/etc/hosts`.
+For example, at boot Talos will write `/system/etc/hosts` and then bind mount it over `/etc/hosts`.
 This means that instead of making all of `/etc` writable, Talos only makes very specific files writable under `/etc`.
 
-All files under `/system` are completely reproducible.
+All files under `/system` are completely recreated on each boot.
 For files and directories that need to persist across boots, Talos creates `overlayfs` file systems.
 The `/etc/kubernetes` is a good example of this.
 Directories like this are `overlayfs` backed by an XFS file system mounted at `/var`.

website/content/v1.0/learn-more/concepts.md

@@ -6,22 +6,19 @@ description: "Summary of Talos Linux."
 
 When people come across Talos, they frequently want a nice, bite-sized summary
 of it.
-Even better would be if we could give them a reference by which to extrapolate
-what Talos is from something they already know.
 This is surprisingly difficult when Talos represents such a
 fundamentally-rethought operating system.
 
 ## Not based on X distro
 
-A really easy (and useful!) way to summarize an operating system is to say that it is based on X, but focused on Y.
+A useful way to summarize an operating system is to say that it is based on X, but focused on Y.
 For instance, Mint was originally based on Ubuntu, but focused on Gnome 2 (instead of, at the time, Unity).
 Or maybe something like Raspbian is based on Debian, but it is focused on the Raspberry Pi.
 CentOS is RHEL, but made license-free.
 
-Talos Linux _isn't_ based on any other distribution, so there's no help here.
+Talos Linux _isn't_ based on any other distribution.
 We often think of ourselves as being the second-generation of
 container-optimised operating systems, where things like CoreOS, Flatcar, and Rancher represent the first generation, but that implies heredity where there is none.
-It does, though, allow a conceptual handle to the concept.
 
 Talos Linux is actually a ground-up rewrite of the userspace, from PID 1.
 We run the Linux kernel, but everything downstream of that is our own custom
@@ -36,12 +33,12 @@ We don't even have a build toolchain in the normal sense of the word.
 ## Not for individual use
 
 Technically, Talos Linux installs to a computer much as other operating systems.
-_Unlike_ other operating systems, however, Talos is not meant to run alone, on a
+_Unlike_ other operating systems, Talos is not meant to run alone, on a
 single machine.
 Talos Linux comes with tooling from the very foundation to form clusters, even
 before Kubernetes comes into play.
-A design goal of Talos Linux is to come as close to eliminating the management
-of individual nodes as possible.
+A design goal of Talos Linux is eliminating the management
+of individual nodes as much as possible.
 In order to do that, Talos Linux operates as a cluster of machines, with lots of
 checking and coordination between them, at all levels.
 
@@ -62,13 +59,13 @@ Never get hung up on an individual machine.
 
 ## Control Planes are not linear replicas
 
-People familiar with traditional relational database replication tactics often
+People familiar with traditional relational database replication often
 overlook a critical design concept of the Kubernetes (and Talos) database:
 `etcd`.
 Unlike linear replicas, which have dedicated masters and slaves/replicas, `etcd`
 is highly dynamic.
 The `master` in an `etcd` cluster is entirely temporal.
-This means fail-overs are handled easily, often, and usually without any notice
+This means fail-overs are handled easily, and usually without any notice
 of operators.
 This _also_ means that the operational architecture is fundamentally different.
 
@@ -86,7 +83,7 @@ If any two disagree or even fail to answer, the `etcd` database will lock itself
 until quorum is again achieved in order to protect itself and the integrity of
 the data.
 This is fantastically important for handling distributed systems and the various
-types of contention which may arise therein.
+types of contention which may arise.
 
 This design means, however, that having an incorrect number of members can be
 devastating.
@@ -144,6 +141,3 @@ Bootstrapping only tells `etcd` to form a cluster, so don't judge the success of
 a bootstrap by the failure of Kubernetes to start.
 Kubernetes relies on `etcd`, so bootstrapping is _required_, but it is not
 _sufficient_ for Kubernetes to start.
-
-[comment]: <>(!-- TODO: how to check if a cluster has already been bootstrapped
-successfully.)

website/content/v1.1/learn-more/architecture.md

@@ -6,14 +6,13 @@ description: "Learn the system architecture of Talos Linux itself."
 
 Talos is designed to be **atomic** in _deployment_ and **modular** in _composition_.
 
-It is atomic in the sense that the entirety of Talos is distributed as a
+It is atomic in that the entirety of Talos is distributed as a
 single, self-contained image, which is versioned, signed, and immutable.
 
-It is modular in the sense that it is composed of many separate components
+It is modular in that it is composed of many separate components
 which have clearly defined gRPC interfaces which facilitate internal flexibility
 and external operational guarantees.
 
-There are a number of components which comprise Talos.
 All of the main Talos components communicate with each other by gRPC, through a socket on the local machine.
 This imposes a clear separation of concerns and ensures that changes over time which affect the interoperation of components are a part of the public git record.
 The benefit is that each component may be iterated and changed as its needs dictate, so long as the external API is controlled.
@@ -32,19 +31,19 @@ Talos uses these partitions with the following labels:
 
 ## The File System
 
-One of the more unique design decisions in Talos is the layout of the root file system.
+One of the unique design decisions in Talos is the layout of the root file system.
 There are three "layers" to the Talos root file system.
-At its' core the rootfs is a read-only squashfs.
+At its core the rootfs is a read-only squashfs.
 The squashfs is then mounted as a loop device into memory.
 This provides Talos with an immutable base.
 
 The next layer is a set of `tmpfs` file systems for runtime specific needs.
 Aside from the standard pseudo file systems such as `/dev`, `/proc`, `/run`, `/sys` and `/tmp`, a special `/system` is created for internal needs.
 One reason for this is that we need special files such as `/etc/hosts`, and `/etc/resolv.conf` to be writable (remember that the rootfs is read-only).
-For example, at boot Talos will write `/system/etc/hosts` and the bind mount it over `/etc/hosts`.
+For example, at boot Talos will write `/system/etc/hosts` and then bind mount it over `/etc/hosts`.
 This means that instead of making all of `/etc` writable, Talos only makes very specific files writable under `/etc`.
 
-All files under `/system` are completely reproducible.
+All files under `/system` are completely recreated on each boot.
 For files and directories that need to persist across boots, Talos creates `overlayfs` file systems.
 The `/etc/kubernetes` is a good example of this.
 Directories like this are `overlayfs` backed by an XFS file system mounted at `/var`.

website/content/v1.1/learn-more/concepts.md

@@ -6,22 +6,19 @@ description: "Summary of Talos Linux."
 
 When people come across Talos, they frequently want a nice, bite-sized summary
 of it.
-Even better would be if we could give them a reference by which to extrapolate
-what Talos is from something they already know.
 This is surprisingly difficult when Talos represents such a
 fundamentally-rethought operating system.
 
 ## Not based on X distro
 
-A really easy (and useful!) way to summarize an operating system is to say that it is based on X, but focused on Y.
+A useful way to summarize an operating system is to say that it is based on X, but focused on Y.
 For instance, Mint was originally based on Ubuntu, but focused on Gnome 2 (instead of, at the time, Unity).
 Or maybe something like Raspbian is based on Debian, but it is focused on the Raspberry Pi.
 CentOS is RHEL, but made license-free.
 
-Talos Linux _isn't_ based on any other distribution, so there's no help here.
+Talos Linux _isn't_ based on any other distribution.
 We often think of ourselves as being the second-generation of
 container-optimised operating systems, where things like CoreOS, Flatcar, and Rancher represent the first generation, but that implies heredity where there is none.
-It does, though, allow a conceptual handle to the concept.
 
 Talos Linux is actually a ground-up rewrite of the userspace, from PID 1.
 We run the Linux kernel, but everything downstream of that is our own custom
@@ -36,12 +33,12 @@ We don't even have a build toolchain in the normal sense of the word.
 ## Not for individual use
 
 Technically, Talos Linux installs to a computer much as other operating systems.
-_Unlike_ other operating systems, however, Talos is not meant to run alone, on a
+_Unlike_ other operating systems, Talos is not meant to run alone, on a
 single machine.
 Talos Linux comes with tooling from the very foundation to form clusters, even
 before Kubernetes comes into play.
-A design goal of Talos Linux is to come as close to eliminating the management
-of individual nodes as possible.
+A design goal of Talos Linux is eliminating the management
+of individual nodes as much as possible.
 In order to do that, Talos Linux operates as a cluster of machines, with lots of
 checking and coordination between them, at all levels.
 
@@ -62,13 +59,13 @@ Never get hung up on an individual machine.
 
 ## Control Planes are not linear replicas
 
-People familiar with traditional relational database replication tactics often
+People familiar with traditional relational database replication often
 overlook a critical design concept of the Kubernetes (and Talos) database:
 `etcd`.
 Unlike linear replicas, which have dedicated masters and slaves/replicas, `etcd`
 is highly dynamic.
 The `master` in an `etcd` cluster is entirely temporal.
-This means fail-overs are handled easily, often, and usually without any notice
+This means fail-overs are handled easily, and usually without any notice
 of operators.
 This _also_ means that the operational architecture is fundamentally different.
 
@@ -86,7 +83,7 @@ If any two disagree or even fail to answer, the `etcd` database will lock itself
 until quorum is again achieved in order to protect itself and the integrity of
 the data.
 This is fantastically important for handling distributed systems and the various
-types of contention which may arise therein.
+types of contention which may arise.
 
 This design means, however, that having an incorrect number of members can be
 devastating.
@@ -144,6 +141,3 @@ Bootstrapping only tells `etcd` to form a cluster, so don't judge the success of
 a bootstrap by the failure of Kubernetes to start.
 Kubernetes relies on `etcd`, so bootstrapping is _required_, but it is not
 _sufficient_ for Kubernetes to start.
-
-[comment]: <>(!-- TODO: how to check if a cluster has already been bootstrapped
-successfully.)