blade/plan.md

Blade is a PID 1

Core

• Custom C++ userspace / init system
• Everything runs in one main PID 1 process
• Keep subsystems code-wise separate internally
• Single-user system
• Custom privilege escalation binary (sudo-like)

Init / Service Manager

• PID 1 handles system initialization
• Start/stop/restart services
• Service dependencies
• Service ordering / stages
• Continuous service supervision
• Ruby-defined service configuration
• Ruby hooks for service events
• Runtime service control through Ruby socket

Package Manager

• Built into the main userspace
• Packages defined as Ruby scripts
• Packages use Git sources
• Build using make commands
• Package dependencies
• Install/update packages
• Cleanup/remove unused packages
• Package hooks
• Hooks can add services/configuration/etc.
• Build required packages during startup

Ruby

• Embedded static mruby
• Ruby is the main configuration language
• Same Ruby system defines packages + services + hooks
• Ruby commands available at runtime over a socket
• Runtime API for controlling the system
• Hooks / shortcuts can react to system events

Built-in Components

• D-Bus broker
• Wayland compositor
  • Notifications (also connects to dbus)
  • Clipboard with history, and api to read/work with history.
• Terminal emulator
• Session manager
• Package manager
• Service manager
• System configuration/runtime API

Boot Sequence

1. Start basic services
   • Networking
   • Audio
   • Other essential infrastructure
2. Run package manager
   • Build/update/install required packages
   • Cleanup
   • Run package hooks
3. Start TTY2
   • Launch shell
4. Start normal non-desktop services
5. Start Wayland on TTY1
6. Wayland starts in locker state
7. Start services that depend on Wayland
8. Resolve service dependencies/order
9. Enter continuous runtime/event loop

Wayland / Desktop

• Wayland compositor is built into PID 1
• TTY1 is graphical
• TTY2 is shell/terminal
• Desktop states:
  • locker
  • terminal
  • application
• application state gives each application its own workspace
• System owns/controls the login/unlock password
• No traditional display manager
• One built-in terminal emulator
• Consider multiplexing later if actually needed

Runtime

• Everything remains active after boot
• Event-driven system
• Ruby command socket
• Runtime configuration changes
• Hooks can react to:
  • service events
  • package events
  • Wayland events
  • shortcuts
  • system events
• Continuously monitor and manage services