src/README.md

@@ -7,12 +7,6 @@ It consists of docs for [Developers](/development/index.md), as well as [end-use
 
 If you would like to use the operating system, or help with development, this is where to get your information!
 
-## What is Mercury?
-**Mercury**, or the **Mercury Project**, refers to the collection of `libraries`, `crates`, and other code under this organization.
-"Organization" is a loose term, and really it's anyone who contributes and follows the [Code of Conduct](code-of-conduct.md).
-
-**Mercury OS** refers specifically to the full Operating System built off of the `ferrite` [kernel](/development/design/kernel.md) and all the other binaries.
-
 ## Status
 Right now, **Mercury** is mainly in the planning stage.
 We're still setting things up, learning, and planning out how we're going to do this.

src/SUMMARY.md

@@ -2,18 +2,15 @@
 
 [Introduction](README.md)
 
-# Developer Guide
 - [Development](development/README.md)
     - [Understanding the Design Goals](development/design/README.md)
         - [Actor System]()
-        - [Security Features](development/design/security.md)
-        - [Microkernel](development/design/kernel.md)
+        - [Security Features]()
+        - [Microkernel]()
         - [GUI]()
         - [Filesystem](development/design/filesystem.md)
     - [Configuring a Build Environment](development/environment.md)
     - [Development Workflow](development/workflow.md)
-
-# User Guide
 - [Using the OS](user/README.md)
     - [Running in a Virtual Machine]()
     - [Running on Baremetal]()
@@ -22,7 +19,3 @@
         - [Navigating the GUI]()
         - [Configuring the System]()
         - [Working with Actors]()
-
------------
-
-[Code of Conduct]()

src/code-of-conduct.md

@@ -1 +0,0 @@
-# Code of Conduct

src/development/README.md

@@ -6,7 +6,7 @@ Again, right now we're a heavy work-in-progress. But eventually this will be use
 ## Contributor Agreements
 By submitting resources to this project (code, art, writing, etc.), you must agree to the following terms:
 1. Resources will be licensed under the [CNPLv7+](https://thufie.lain.haus/NPL.html) license
-2. You *must* follow the [Code of Conduct](code-of-conduct.md)
+2. You *must* follow the [Code of Conduct](conduct.md)
 3. You should follow the [Design Goals](/development/design/index.md) and [Best Practices](#best-practices) when possible
 
 Otherwise, feel free to start contributing!
@@ -21,31 +21,14 @@ Feel free to [contact](https://mercury.the-system.eu.org/contribute/) a maintain
 - `unsafe` code should be avoided when possible.
 - Everything should be documented as it is written.
 - Nesting should be avoided as much as possible.
+- `cargo fmt` must be used before each commit.
 - If something can be excluded from the main `kernel`, it should be. It's a `microkernel`!
+- While binary size should be kept down and optimized, it should not be done at the cost of performance.
 - Features should be *opt-in* rather than *opt-out*.
+- Releases should ideally contain no compiler or `clippy` warnings.
 
 ## Source Code
 All of the source code for **Mercury** is on a self-hosted [Gitea](https://git.lavender.software/mercury), courtesy of [Lavender Software](https://lavender.software).
 Sign up there, and contact one of the maintainers to get access to the repositories.
 
 The source for this site, and our [website](https://mercury.the-system.eu.org) is available there as well.
-
-### Design
-All `crates`/`libraries` are in a `no-std` environment. This means we only have access to the [libcore](https://doc.rust-lang.org/core/) functionality.
-However, we will be using the `alloc` crate to access the heap, and`collections` to have access to data structures like `Vec`.
-
-We should, however, have basic support for [async](https://ferrous-systems.com/blog/stable-async-on-embedded/).
-
-## Learning
-Before jumping in, I highly recommend learning some stuff abotu **Rust** and embedded development with it.
-A thorough series of steps might be:
-1. Read through the [Rust Book](https://doc.rust-lang.org/book/)
-2. Work through the [Interactive Rust Book](https://rust-book.cs.brown.edu/)
-3. Complete the [rustlings](https://github.com/rust-lang/rustlings) exercises
-4. Take a quick look through the [Embedded Rust Book](https://docs.rust-embedded.org/book/intro/index.html)
-5. Read the [RISC-V Guide](https://github.com/mikeroyal/RISC-V-Guide)/[RISC-V Bytes](https://danielmangum.com/categories/risc-v-bytes/) to learn more about the **RISC-V** architecture
-6. Read the OSDev Wiki entries on [Microkernels](https://wiki.osdev.org/Microkernel) and [Message Passing](https://wiki.osdev.org/Message_Passing)
-
-Additionally you might want to learn about **Vulkan** if you're going to be hacking on the [GUI](/development/design/gui.md):
-1. Go through the [Vulkan Tutorial (Rust)](https://kylemayes.github.io/vulkanalia/introduction.html) to learn some of the basics
-2. Read through the [Vulkano](https://vulkano.rs/about.html) docs. *(**Vulkano** is a safe wrapper around the **Vulkan API**. It's likely what we will be using)*

src/development/design/README.md

@@ -19,11 +19,6 @@ Additionally, **Mercury** is designed for `ARM`/`RISC-V` architecture machines.
 This is not only because they are simpler, but also because I believe they are the future of computing.
 For the future, I do not see myself wanting or attempting to implement `x86` functionality.
 
-We may also use [Rhai](https://lib.rs/crates/rhai) for scripting, for easy user control & modification of the system.
-
-It will also use a global configuration - similar to **Guix** or **NixOS**. This allows it to be easily setup.
-It will likely use [RON](https://lib.rs/crates/ron) for configuration.
-
 Further design decisions are gone into detail in the next few chapters.
 
 ## Code Organization
@@ -39,6 +34,6 @@ Most of the code will be implemented as libraries, enabling for them to be used
 - [ferrite](https://git.lavender.software/mercury/ferrite-kernel) - The core microkernel code
 - [hermes]() - The package manager
 - [meteor]() - The [actors](/development/design/actor.md) library/implementation
-- [gravitas]() - The library for working with [storage](/development/design/filesystem.md)
+- [gravitas]() - The library for working with [storage](/development/filesystem.md)
 - [pulsar]() - Networking code
 - [photon]() - GUI library

src/development/design/filesystem.md

@@ -12,49 +12,42 @@ I don't want to provide a simple filesystem interface to programs like **UNIX**
 Instead, all data should be just stored in *actors*, then the actors will decide whether or not they should be saved.
 They can save at any time, save immediately, or just save on a *shutdown* signal.
 
-Therefore, the "filesystem" code will just be a library that's simple a low-level interface for the `kernel` to use.
-*Actors* will simply make requests to save.
+Therefore, the "filesystem" code will just be a library that's simple a low-level interface for actors to use.
 
 
 ## Filesystem Layout
 ### Partition
 A virtual section of the disk.
-It's identified simply by numerical order.
+- **BOOT Partition:** Fixed-size partition at the beginning of the disk, containing the kernel code, and info about the other partitions.
+- **DATA Partition:** Fixed-size partition containing misc. *Actor* data
+- **USER Partition:** Contains all data from the `User` [namespace](/development/design/actor.md#namespaces)
 ```rust
-const BOOT_SIZE: u64; // How large the BOOT partition will be
-const LABEL_SIZE: u64; // Number of characters that can be used in the partition label
+enum PartitionLabel {
+    Boot,
+    Data,
+    User,
+}
 
 struct PartitionHeader {
-    boot: bool, // Boot flag
-    label: [char; LABEL_SIZE], // Human-readable label. Not UTF-8 though :/
+    label: PartitionLabel,
     num_chunks: u64, // Chunks in this partition
 }
 ```
 
 ### Chunk
 Small pieces that each partition is split into.
-Contains fixed-length metadata (checksum, extension flag, uuid) at the beginning, and then arbitrary data afterwards.
-If the saved data exceeds past a single chunk, the `extends` flag is set.
-
-Additionally, it has a **UUID** generated via [lolid](https://lib.rs/crates/lolid) to enable identifying a specific chunk.
-
+Contains fixed-length metadata (checksum, dates) at the beginning, and then arbitrary data afterwards.
+If the saved data exceeds past a single chunk, the metadata lists this.
 ```rust
-const CHUNK_SIZE: u16; // Example static chunk size
-
 struct Chunk {
     checksum: u64,
     extends: bool,
-    encrypted: bool,
-    uuid: Uuid,
-    data: [u8; CHUNK_SIZE],
+    data: [u8; 512],
 }
 ```
 This struct is then encoded into bytes and written to the disk. Drivers for the disk are *to be implemented*.
 It *should* be possible to do autodetection, and maybe for *Actors* to specify which disk/partition they want to be saved to.
 
-Compression of the data should also be possible, due to `bincode` supporting [flate2](https://lib.rs/crates/flate2) compression.
-Similarely **AES** encryption can be used, and this allows for only specific chunks to be encrypted.[^encryption]
-
 ### Reading
 On boot, we start executing code from the beginning of the disk (the boot partition, although that's meaningless at this point).
 The `kernel` then reads in bytes from the first partition *(as the **BOOT** partition is fixed-size, we know when this starts)* into memory, serializing it into a `PartitionHeader` struct via [bincode](https://lib.rs/crates/bincode).
@@ -62,7 +55,7 @@ The `kernel` then reads in bytes from the first partition *(as the **BOOT** part
 From here, as we have a fixed `CHUNK_SIZE`, and know how many chunks are in our first partition, we can read from any chunk on any partition now.
 On startup, an *Actor* can request to read data from the disk. If it has the right [capabilities](/development/design/actor.md#ocap), we find the chunk it's looking for[^find_chunk], parse the data (using `bincode` again), and send it back.
 
-Also, we are able to verify data. Before passing off the data, we re-hash it using [HighwayHash](https://lib.rs/crates/highway) to see if it matches.
+Also, we are able to verify data. Before passing off the data, we re-hash it using [ahash](https://lib.rs/crates/ahash) to see if it matches.
 If it does, we simply pass it along like normal. If not, we refuse, and send an error [message](/development/design/actor.md#messages).
 
 ### Writing
@@ -77,12 +70,6 @@ Again, whether actors can:
 
 will be determined via [capabilities](/development/design/actor.md#ocap)
 
-### To-Do
-- Snapshots
-- Isolation
-
-[^encryption]: Specific details to be figured out later
-
 [^find_chunk]: Currently via magic. I have no idea how to do this other than a simple search. Maybe generate an index, or use a **UUID**?
 
 [^free_chunk]: Again, no idea how.

src/development/design/kernel.md

@@ -1,25 +1 @@
 # Microkernel
-The core `kernel` of **Mercury** will be highly limited, implementing only necessary portions.
-This allows other functionality to be simply run in userspace.
-
-Additionally, most code should be put into separate libraries then pulled into the `kernel` code.
-This will likely be done via `git submodules`.
-
-Initially, it will be built for `RISC-V`, then `ARM` *(focused on running in a [VM](/user/virtual-machine.md))*, then on a **Raspberry Pi**.
-Afterwards, we can put focus towards building out various features.
-
-Support for multiple targets will be done via `Cargo.toml` targets, cross-compilation, and [conditional compilation](https://doc.rust-lang.org/reference/conditional-compilation.html).
-
-## Boot Process
-*To be implemented*
-
-## Memory Management
-*To-Do*
-
-## Processes
-*To-Do*
-- [postcard](https://lib.rs/crates/postcard) for message passing
-
-## Error Handling
-All errors must be handled gracefully by the `kernel`. If possible, they should simply log an error.
-If not, they can display it to the user, preferably in a simple format, maybe using something like [const_panic](https://lib.rs/crates/const_panic) or [snafu](https://lib.rs/crates/snafuhttps://lib.rs/crates/snafu).

src/development/design/security.md

@@ -1,14 +1 @@
 # Security Features
-**Mercury** is designed with security in mind from the beginning.
-
-- First, we will be using [Orion](https://lib.rs/crates/orion) - a pure **Rust** crypto library.
-- There is built in support for checksums and **AES** encryption in the [filesystem](/development/design/filesystem.md).
-- **HMAC**[^hmac] will be used for message passing - which additionally allows for encrypted messages.
-- [nanorand](https://lib.rs/crates/nanorand) RNG
-- [HighwayHash](https://lib.rs/crates/highway) is used for checksums
-- [Argon2id](https://lib.rs/crates/argon2) is used for key-derivation
-
-## Isolation
-*To-Do*
-
-[^hmac]: https://cryptobook.nakov.com/mac-and-key-derivation