From 1f8211c357eb784bdbe566d0776b77fa1f3d0bae Mon Sep 17 00:00:00 2001 From: Sjoerd Simons <sjoerd.simons@collabora.co.uk> Date: Tue, 13 Apr 2021 07:18:01 +0000 Subject: [PATCH] Apply 14 suggestion(s) to 1 file(s) --- content/concepts/overview.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/content/concepts/overview.md b/content/concepts/overview.md index 1fc3c78a6..35f02addd 100644 --- a/content/concepts/overview.md +++ b/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. -- GitLab