v0.0.3

Release v0.0.3

Builds on v0.0.2. New in this release:

• More usable RAM. Earlier releases topped out near a single gigabyte; that
  limit is gone, and the kernel now runs with many gigabytes of memory. Larger
  workloads that couldn't fit before have room now.

• On-screen graphics. Programs can draw to the VM's own window, not just the
  text console — the kernel sets the display mode, hands out a framebuffer, and
  flips it. Rendering is done in software, including continuously animated
  output, not only static frames.

• Faster, lighter process creation. Starting a child process no longer copies
  the parent's memory up front. The two share their pages until one of them
  writes, so a fork is near-instant and uses a fraction of the memory it used
  to — even for large programs. Shells, servers, and build tools that fork
  constantly run leaner and quicker, and forking stays correct under heavy
  multi-core load.

• Real process isolation. Sandboxes and containers can take their own private
  views of the system — separate process tables, a separate network stack, and
  separate mount and inter-process-communication namespaces — with the tools to
  create, join, and inspect them. A program in one namespace cannot see or
  disturb another's processes, and what each program sees through the system's
  introspection interfaces is scoped to its own view.

• Per-program CPU pinning. A program can ask to run only on specific processor
  cores, and the scheduler honors it — useful for latency- or cache-sensitive
  work.

• Much broader networking. Datagram sockets, a working connect, and
  scatter/gather message send and receive run more clients and simple servers.
  Local sockets — streamed, datagram, and abstract — let programs on the same
  machine talk the way stock software expects, including passing open files from
  one process to another. IPv6 works alongside IPv4, programs can query the
  machine's network configuration, and basic reachability testing works.

• Built-in randomness. Programs that need random data — for cryptographic keys,
  secure connections, or program hardening — now get a fast, always-available
  source built into the kernel, rather than depending on the host to supply one.
  It draws from the processor's own randomness and from system timing, never
  stalls waiting for a source, and keeps working even when no hardware random
  device is present. The generator moves forward after every request, so earlier
  output can't be reconstructed from its current state, and it refreshes itself
  over time; a power-on self-check verifies it before any program relies on it.

• More of the system-call surface. Vectored reads and writes, the full set of
  readiness-wait calls, directory-relative file paths, and an in-memory
  filesystem backed by real memory pages for large files. The result: more
  stock programs run unmodified.

• A hardened core. The kernel's internal process and scheduling state is now
  sealed behind enforced interfaces rather than shared freely across the code,
  so a mistake in one part can no longer quietly corrupt another part's
  bookkeeping — the boundary is checked when the kernel is built. This is
  groundwork: it makes the system easier to reason about and harder to break as
  it grows.

• More accurate introspection. The reported boot time, a stable per-boot
  identifier, and a live view of mounted filesystems now reflect reality rather
  than placeholders, so monitoring and diagnostic tools read correct values.

• Steadier multi-core workloads. A rare crash when one processor cleaned up a
  program that another was still tearing down is fixed, and exit bookkeeping was
  reworked so a parent always finds its finished child the moment it is told
  about it. Connection teardown and non-blocking input/output were tightened so
  database and cache servers that hold many connections run to completion instead
  of stalling. Process storms — forking, killing, and waiting on many short-lived
  programs at once — run clean.

See README.md for what runs today, and docs/ for the architecture, the
verification recipe, and the clean-room policy.