Fixing some typos in the documentation

content/docs/cli/filesystem.mdx

@@ -36,7 +36,7 @@ For Unikraft, however, the use of a root filesystem is totally optional and depe
 
 Thanks to Unikraft's highly modular structure, building a unikernel with root filesystem support is both trivial and left up to the application developer and ultimately the application use case.
 Some unikernels may not require a filesystem at all if the application does not read or write any files.
-In this case, neither the underlying filesystem subsystem (`vfscore`) or a root filesystem can are compiled into the unikernel binary.
+In this case, neither the underlying filesystem subsystem (`vfscore`) nor a root filesystem have to be compiled into the unikernel binary.
 For example, this may be use in lambda-type use cases.
 However, many applications do need access to files, configuration data, a temporary file directory scratch pad (e.g. `/tmp`) or other have file-based resource needs.
 In such cases, a root filesystem is essential.

content/docs/cli/packaging.mdx

@@ -64,7 +64,7 @@ Components are one of 5 unique types:
 | `app`  | The final component type is that of a fully functioning unikernel.  The `app` component defines the use of the `core`, a `arch` and `plat` combination, as well as a list of `lib`s. |
 
 
-## Package Manages
+## Package Managers
 
 Internal to `kraft` are programmable package managers that allows you to fetch
 resources that either comprise of library components (distributed through [the

content/docs/concepts/virtualization.mdx

@@ -22,7 +22,7 @@ properly.
 
 A hypervisor incorporates hardware-enabled multiplexing and segmentation of
 compute resources in order to better utilize, better secure and better
-facilitate the instantenous runtime of user-defined programs. Through By the
+facilitate the instantenous runtime of user-defined programs. By the
 means of a virtual machine, an operating system is unaware of the multiplexing
 which happens to facilitate its existence. The hypervisor emulates devices on
 behalf of the guest OS, including providing access to virtual CPUs, virtual

content/docs/internals/architecture.mdx

@@ -103,33 +103,3 @@ micro-library (3️), or optimize throughput by oding against the ukblock API
 (8️).  Schedulers are also pluggable (4️), and each CPU core can run a
 different scheduler.
 
-
-
-
-
-
-
-###
-
-
-The Unikraft Core
-The Unikraft core is the actual kernel code, and is comprised of several components:
-
-the architecture code: This defines behaviours and hardware interactions
-specific to the target architecture (x86_64, ARM, RISC-V). For example, for the
-x86_64 architecture, this component defines the usable registers, data types
-sizes and how Thread-Local Storage should happen.
-
-the platform code: This defines interaction with the underlying hardware,
-depending on whether a hypervisor is present or not, and which hypervisor is
-present. For example, if the KVM hypervisor is present, Unikraft will behave
-almost as if it runs bare-metal, needing to initialize the hardware components
-according to the manufacturer specifications. The difference from bare-metal is
-made only at the entry, where some information, like the memory layout, the
-available console, are supplied by the bootloader (Multiboot) and there’s no
-need to interact with the BIOS or UEFI. In the case of Xen, many of the
-hardware-related operations must be done through hypercalls, thus reducing the
-direct interaction of Unikraft with the hardware.
-
-internal libraries: These define behaviour independent of the hardware, like scheduling, networking, memory allocation, basic file systems. These libraries are the same for every platform or architecture, and rely on the platform code and the architecture code to perform the needed actions. The internal libraries differ from the external ones in the implemented functionalities. The internal ones define parts of the kernel, while the external ones define user-space level functionalities. For example, uknetdev and lwip are 2 libraries that define networking components. Uknetdev is an internal library that interacts with the network card and defines how packages are sent using it. Lwip is an external library that defines networking protocols, like IP, TCP, UDP. This library knows that the packages are somehow sent over the NIC, but it is not concerned how. That is the job of the kernel.
-The core, toghether with the external libraries, applications and platform codes, form the final Unikernel.

content/docs/internals/build-system.mdx

@@ -231,7 +231,7 @@ APPNAME_FILENAME_VARIANT_INCLUDES-y         file and variant of the library
 Unikraft's configuration system is based on [Linux's KConfig system](https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html).
 With `Config.uk` you define possible configurations for your application and define dependencies to other libraries.
 This file is included by Unikraft to render the menu-based configuration, and to load and store configurations (aka `.config`).
-Each setting that is defined in this file will be globally populated as a set variable for all `Makefile.uk` files, as well as a defined macro in your source code when you use `"#include <uk/config.h>"`.
+Each setting that is defined in this file will be globally populated as a set variable for all `Makefile.uk` files, as well as a defined macro in your source code when you use `#include <uk/config.h>`.
 Please ensure that all settings are properly namespaced.
 They should begin with `[APPNAME]_` (e.g. `APPHELLOWORLD_`).
 Please also note that some variable names are predefined for each application or library namespace (see [`Makefile.uk`](/docs/internals/build-system/#makefileuk)).