Apply 14 suggestion(s) to 1 file(s)

content/concepts/overview.md

@@ -33,7 +33,7 @@ Apertis as they see fit!
 The following sections look at various scenarios in which Apertis can be used
 on devices and the technical building blocks that Apertis intends to make
 available for them. As such they all describe a reasonably full-featured setup
-for each scenario, however and actual deployment can still choice to only use a
+for each scenario, however an actual deployment can still choose to only use a
 subset of available features.
 
 As this document provides a forward-looking vision of the Apertis
@@ -41,27 +41,27 @@ platform not all features mentioned are yet implemented or even fully defined.
 
 # Fixed function device scenario
 
-This setup represent an "appliance" or fixed function devices. That is to say
+This setup represents an "appliance" or fixed function devices. That is to say
 the device is intended to be used for a specific functionality which cannot be
 extended by installing extra software on top of the base system. This scenario also
 assumes it's operating in a headless fashion without a comprehensive graphical
 user interface. It is still possible to have some amount of user interactions 
 for example via simple buttons or knobs for user inputs and lights and/or segmented
 displays for outputs, however typical inputs and outputs for these devices will
-be attached periphals and sensors.
+be attached peripherals and sensors.
 
 Typically these devices are expected to be connected to an IP network and have
 the ability to either directly or indirectly connected to internet services (e.g. 
 via ethernet, wifi, 5G).
 
-As security and integrity is paramount the devices supports a fully verified
+As security and integrity is paramount the device supports a fully verified
 boot sequence (secure boot, verified boot or similar) to ensure untampered
 firmware, kernel, etc are used. The system (root) filesystem is integrity
 measured for all executables to get a fully trusted system.
 
 To further improve integrity and privacy of the system a Trusted Execution
 environment is available for trusted applications (e.g. optee).  The TEE
-environment or a dedicated chip (e.g. TPM) are available to support for remote
+environment or a dedicated chip (e.g. TPM) are available to support remote
 attestation as well support for encrypted areas (filesystems etc) which can
 only be accessed by a specific device and only when it has been booted into a
 known state.
@@ -85,7 +85,7 @@ Building upon the fleet management integration, while updates provide one piece
 of the puzzle telemetric support provides another aspect to enable remote
 management and monitoring of devices.
 
-As lot of this functionality needs network access, so of course Apertis
+As a lot of this functionality needs network access, so of course Apertis
 supports various ways of accessing networks whether this is via wired
 connection, wifi or mobile networks.
 
@@ -127,7 +127,7 @@ The additions of applications to the system can be done via the installation of
 flatpak-based application bundles, which allows applications to be
 installed with minimal dependencies on the base system. This also makes it
 possible to have separate update lifecycles for applications  and the base operating
-system as typically application are update at a far shorter cycle then the operating'
+system as typically applications are updated at a far shorter cycle then the operating
 system itself. The usage of flatpak-based applications also enables the
 implementation of dynamic policies for what resources are available for 
 an application. For example camera access might only be allowed for some
@@ -159,13 +159,13 @@ runtime including SDK variants and debug extensions (needed for development)
 will be provided. These runtime will include a basic set of libraries for
 libraries to rely on.
 
-However as certain applications or devices can have special needs for the libraries
+However certain applications or devices can have special needs for the libraries
 available in their standard runtime. Custom runtimes can also be created as needed.
 
-For some devices specific extra or different libraries can are required. For
+For some devices specific extra or different libraries can be required. For
 example to support a device specific GL or Vulkan stack or device specific
 codec libraries. These can be shipped as a flatpak runtime extension, allowing
-multiple devices to use the same base runtimes but adjust as need to take full
+multiple devices to use the same base runtimes but adjust as needed to take full
 advantage of the underlying hardware.
 
 Apart from this base infrastructure application may also have a need to access
@@ -194,7 +194,7 @@ dynamically manage which devices run specific workloads.
 Typically these devices collect data on the edge either directly by containing
 various sensors (e.g. cameras, power measurement, temperature etc) or
 indirectly via other devices on a local network (which could be fixed function
-apertis devices). The role of this devices typically is to process all these
+apertis devices). The role of these devices typically is to process all these
 inputs in some fashion and either act on them or relay it to a cloud
 infrastructure.
 
@@ -203,10 +203,10 @@ workloads; These containers are distributed and run using the open container
 initiative (OCI) standards. Apertis will include an open-source workload
 orchestrater to interact with a management system to orchestrate deployments.
 
-Another role an edge device can take is as an orchestrater for deploying software
+Another role an edge device can take is as an orchestrator for deploying software
 updates or workloads to secondary devices. For example an accompanying
 microcontroller running a real time operating system or a separate
-network-attached system which is not (or cannot be) directly connect to the
+network-attached system which is not (or cannot be) directly connected to the
 internet. The orchestrater is able to manage and push updates to these
 devices.
 
@@ -222,7 +222,7 @@ devices.
 Like Flatpaks OCI images to be run on a device are separate from the main
 system to decouple the two. OCI images are the standard way of distributing
 cloud workload for network services which is a good and natural fit for the
-workloads on edge devices. This allows allows the apertis device to take
+workloads on edge devices. This allows the Apertis device to take
 advantage of common workflows developers are used to for building images
 targeting cloud deployments.