os-selection.md - fix typos

docs/src/design/os-selection.md

@@ -48,7 +48,7 @@ Complex embedded systems require robust debugging and monitoring capabilities th
 | **System Composition** | **Static**: All tasks defined at compile-time in app.toml configuration, cannot be created/destroyed at runtime. Build system validates all configurations with static assertions. Supports in-place task reinitialization for fault recovery - supervisor task can restart crashed tasks without system reboot. Design philosophy prioritizes eliminating functionality not essential for server management and platform security, resulting in a smaller, more focused codebase to audit and validate. | **Dynamic**: Tasks can be dynamically loaded and assigned. Offers flexibility for diverse application scenarios and runtime adaptation. | Static model with compile-time validation prevents entire classes of runtime failures. In-place restart capability enables component-level recovery, avoiding system-wide reboots for isolated faults. Dynamic models provide flexibility for applications requiring runtime component loading or updates. |
 | **Communication** | **Strictly Synchronous**: IPC blocks sender until reply received. Uses rendezvous mechanism inspired by L4 microkernel - kernel performs direct memory copy between tasks, extending Rust's ownership model across task boundaries through leasing. | **Asynchronous**: Callback-based notifications for applications. | Synchronous communication eliminates race conditions, enables precise fault isolation (REPLY_FAULT at error point), and simplifies kernel design by avoiding complex message queue management. |
 | **Fault Isolation** | **Disjoint Protection Domains**: Drivers and kernel in separate, MPU-enforced memory spaces. Failing driver cannot corrupt kernel. | **Shared Protection Domain**: Drivers run in same domain as kernel but are partitioned by Rust's type system and capsule architecture. Capsules are kernel modules that rely on Rust's memory safety (borrowing rules, lifetime management) and trait-based interfaces for isolation rather than hardware memory protection. | Hardware-enforced isolation provides robust defense against faults. Memory-safe languages alone don't prevent all failures in critical systems. |
-| **Embedded CPU Architecture Support** | **ARM Cortex-M:** Official native support included.<br> **RISC-V** Designed with RISC-V in mind, but currently only has unnofficial support from outside developers including OpenPRoT partners. | **ARM Cortex-M:** Official native support included.<br> **RISC-V** Official native support included.<br> **x86 (32bit):**  Official native support included. | While native support is desireable, Hubris is relatively trivial to port to additional architectures for these reasons:<br><br> 1. **🎯 Narrow target scope**: Only 32-bit microcontrollers<br> 2. **📦 Rust ecosystem**: RISC-V already well-supported<br> 3. **🔒 Memory safety**: Rust prevents most porting bugs<br> 4. **⚡ Simple execution model**: Privileged kernel, unprivileged tasks<br> 5. **🛡️ Minimal assembly**: Most code is portable Rust<br> 6. **📚 Clear documentation**: Architecture requirements already specified<br><br> [More details](./hubris-riscv.md) |
+| **Embedded CPU Architecture Support** | **ARM Cortex-M:** Official native support included.<br> **RISC-V:** Designed with RISC-V in mind, but currently only has unofficial support from outside developers including OpenPRoT partners. | **ARM Cortex-M:** Official native support included.<br> **RISC-V:** Official native support included.<br> **x86 (32bit):**  Official native support included. | While native support is desirable, Hubris is relatively trivial to port to additional architectures for these reasons:<br><br> 1. **🎯 Narrow target scope**: Only 32-bit microcontrollers<br> 2. **📦 Rust ecosystem**: RISC-V already well-supported<br> 3. **🔒 Memory safety**: Rust prevents most porting bugs<br> 4. **⚡ Simple execution model**: Privileged kernel, unprivileged tasks<br> 5. **🛡️ Minimal assembly**: Most code is portable Rust<br> 6. **📚 Clear documentation**: Architecture requirements already specified<br><br> [More details](./hubris-riscv.md) |
 | **Licensing** | **Mozilla Public License Version 2.0**: Commercial use allowed, May be combined with proprietary code, Modified MPL files must be shared and remain MPL, Explicit patent grant included, Must retain copyright notices | **Apache License 2.0**: Commercial use allowed without restrictions, May be combined with proprietary code, Must state significant changes but not required to share, Explicit patent grant included, Must retain copyright notices | Both licenses allow for commercial use and mixing files with other licenses (including proprietary code). The primary difference is that any MPL licensed files must remain under the MPL license, and any changes to those files must be shared publicly. |
 
 ### Resource & Memory Management