# Projects

# Sterling OS

### Minimal Capability-Based Operating System

## Design Principles

- No global filesystem, no path resolution
- No drivers in kernel, only sandboxed userspace driver processes
- No GPU acceleration, all rendering is deterministic software-based
- All resources accessed via capability tokens
- Processes are strictly sandboxed
- Programs operate on memory buffers, not raw file handles
- Desktop environment is a sandboxed coordinator, not a privileged process

## Authorization Token Model

Programs delegate access via opaque, kernel-managed tokens.

    		grant_token(target_pid, resource_id, flags) -> token_id
    		accept_token(token_id) -> resource_handle
    		revoke_token(token_id)

## File Editing Flow

1. DE requests file via storage service
2. Storage service provides a memory buffer
3. Editor process receives buffer handle, edits
4. Changes submitted back to storage via DE

## Driver Model

- All drivers run as fully unprivileged user processes
- No driver registration or kernel mediation required
- Drivers communicate with hardware via explicit kernel-exposed capability channels
- No dynamic linking or privileged probing allowed
- Users can run or replace any driver without OS permission

## Graphics System

- No GPU support, no shaders
- Software renderer processes draw via shared memory
- DE composites framebuffers deterministically

## Programming Language Requirements

- Manual memory management
- Low-level data layout control
- Inline assembly support
- Pattern matching and compile-time macros
- No runtime, no global init, no dynamic linking

## Execution Model

- Programs are spawned with exact buffer and token permissions
- No shared global state
- All IO is mediated via explicit capability-based services
- Everything is inspectable and reproducible

## Sandboxing Model

All processes are isolated via strict memory boundaries and capability-scoped access. No process can access global state, shared memory, or system calls without explicit capability grants.

### Memory Layout

    		+-----------------------+
    		| Code (RX)             |
    		+-----------------------+
    		| Data (RW)             |
    		+-----------------------+
    		| Shared Buffers (RWX?) | ← only if explicitly mapped by kernel
    		+-----------------------+
    		| Stack (RW)            |
    		+-----------------------+

### Process Launch

- Preallocated memory map (no heap growth)
- Passed a syscall pointer table, token list, and init buffer
- Cannot request global system resources directly

### Capability Enforcement

All access is mediated via capability tokens, handed off securely:

    		token_id = request_token(pid, SERVICE_IO, READ_WRITE);
    		handle = accept_token(token_id);

- Token scope, rights, and duration enforced by kernel
- No access without explicit grant
- All capability use is auditable and revocable

### Filesystem Abstraction

- No global file system
- Programs receive only memory buffers with scoped access
- Read/write must go through kernel-mapped tokens

### Driver Isolation

- Drivers are userland processes only
- No direct port I/O or DMA access
- Hardware is accessed via kernel-exposed capability channels

### IPC

- All inter-process communication is routed via the kernel
- Uses named ports and token-authenticated message queues
- No shared memory by default

### Future Additions

- Deterministic scheduler
- Audit trail of all token activity
- Formal capability typing system

## Philosophy

Not a POSIX clone. It is a deterministic, capability-secure, user-controlled computing environment built to reject legacy complexity and embrace verifiable simplicity.