Skip to content

rfi-irfos/rusty-penguin

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

314 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Rusty Penguin

Language: Rust License: MIT Version: 2.5.0 Platform: x86_64 Kernel: Pure Rust Status: Active Development

"Binary hardware. Ternary mind."

"I'm sure some clueless young person will decide 'how hard can it be?' and start his own operating system in Rust..." — Linus Torvalds, Open Source Summit Europe 2024 (keynote, 16:59). We were stupid enough — see docs/ORIGIN.md.

The keynote playing on the Rusty Penguin kernel

…and then we played that keynote back on the kernel it triggered. The actual Torvalds/Hohndel talk, decoded by our own from-scratch .rpv codec and blitted to our own framebuffer — no browser, no Linux, no external codec. See docs/META_VIDEO.md.

Rusty Penguin is a complete operating system written from scratch in pure Rust — its own bootloader, kernel, drivers, window manager and apps, with no Linux kernel and no libc underneath. The goal: a daily-driver desktop OS you can install in place of Ubuntu. Ternary logic (-1 / 0 / +1) is a first-class primitive at every layer, from the scheduler to the AI runtime.

Built by RFI-IRFOS as part of the Ternary Intelligence Stack. Preinstalled: albert · ternlang · albert-cli · ternlang-mcp

Rusty Penguin desktop v2.3

Rusty Penguin Googles itself — on its own bare-metal kernel. The OS fetches google.com/search?q=rusty+penguin+os over our own TLS 1.3 stack and finds "rusty-penguin - crates.io: Rust Package Registry" in the results. No X11, no Wayland, no libc, no Linux kernel underneath.


Why a third state

Binary computers have two states: on and off. Every value, every decision, every process is either 1 or 0.

Rusty Penguin treats a third state as real: dormant. Not running, not stopped — resting. A process that hasn't been asked for anything yet is not the same as a process that failed. A memory page that hasn't been touched is not dead. A neural-network weight of zero should cost nothing to compute.

Every primitive in this system expresses three states:

Trit Value Meaning
Pos +1 Active, running, promoted
Zero 0 Dormant, idle, neutral
Neg -1 Suppressed, terminated, rejected

Dormancy is sacred. Zero is not nothing — and the renderer, the scheduler and the AI runtime all skip dormant work instead of grinding through it.


What it is, concretely

A from-scratch x86_64 OS, hand-written in Rust top to bottom:

  • Bootloader handoff → pure-Rust kernel — Multiboot2, 32-bit → 64-bit long mode, physical/virtual memory management, interrupts, a custom syscall ABI, ring-3 userspace, PS/2 keyboard + mouse, a 1920×1080 framebuffer, and Intel HDA audio.
  • A native desktop — frosted-glass window manager (drag / resize / minimize / maximize), a floating dock, a start menu, an arrow cursor, and a warm stone-green visual language. No external UI toolkit; every pixel is drawn by our own framebuffer + ternary-CSS engine.
  • Real apps — terminal (psh), file manager, text editor, calculator, system monitor, settings, the TIS console, plus Snake, Minesweeper and a pure-Rust DOOM-style raycaster.
  • A ternary runtime — balanced-ternary arithmetic and a sparse-skip inference engine that physically skips zero-weight multiplications.

No libc. No C dependencies. No UI framework. Systems programming from first principles.


Running the existing software world: the Linux ABI bridge

A from-scratch OS has a chicken-and-egg problem — none of the world's existing software was compiled for it. We solve this without giving up the pure-Rust ternary core: the kernel is growing a Linux ABI compatibility layer — a one-way translation shim that lets unmodified, already-compiled Linux/glibc binaries run on top of our Rust kernel.

This is not "boot Linux instead." There is no Linux kernel here. The native syscall surface is our own, ternary-flavored ABI; the Linux ABI sits beside it purely so the binary ecosystem (eventually a real browser) can run while the native, ternary-native app ecosystem grows to replace it.

It is honest, brick-by-brick work:

  • Done: the kernel runs real unmodified glibc programs natively — both statically and dynamically linked. printf, TLS (__thread), malloc, SSE floating point, full atexit/exit, file I/O, and ld.so loading + relocating + running a dynamically-linked binary against libc.so.6.
  • Next: threads (clone/futex), per-process virtual memory + demand paging, /proc, more of the syscall surface, then a framebuffer GUI app — and on that road, a real web browser.

A browser is the long pole. Be clear-eyed: full web parity is a multi-year horizon. The path is real and the early bricks are laid, but we don't pretend velocity equals completion.


Honest status

The OS (bare-metal pure-Rust kernel — the product)

Component Status
Boot → long mode, memory mgmt, interrupts, syscalls, ring-3
Framebuffer 1920×1080, PS/2 keyboard + mouse
USB xHCI HID — keyboard + mouse on modern laptops ✅ QEMU verified
Intel HDA audio + Sound mixer app
Window manager, floating dock, start menu, arrow cursor
Quick Settings panel (Wi-Fi/BT/dark/volume tiles, tray-anchored) ✅ GNOME-style
Apps: terminal, files, editor, calculator, monitor, settings, TIS console
NIC drivers: RTL8139, Intel e1000/i219, Realtek r8169 ✅ ~95% laptop coverage
TCP/IP stack: ARP/ICMP/UDP/DHCP/DNS/TCP/HTTP ✅ fetches real internet
TLS 1.3 client (X25519 · ChaCha20-Poly1305 · from scratch) ✅ real HTTPS, QEMU-verified vs live web
Live web browser — type host → real page ✅ http + https, follows redirects
fetch, wget terminal commands
Linux ABI layer (static + dynamic glibc binaries) ✅ Bricks 1–5 done
id Software's real DOOM (fbDOOM) on the pure-Rust kernel via the Linux ABI ✅ boots + renders, QEMU-verified
Preemptive multitasking + per-process address spaces (CR3) + ring-3 isolation ✅ scheduler foundation, QEMU-verified
Multi-user login (SHA-256 passwords, /home/)
In-memory VFS within a session
Persistent bare-metal disk storage (RPFS + AHCI) ✅ settings/files survive reboot

The installed system (Linux track — the daily-driver path)

Component Status
Install to disk (rp-install /dev/nvme0n1) ✅ UEFI/GPT
Standalone boot from disk (no ISO)
Persistent /home (ext4) ✅ survives reboots
Package manager (rpm install <url>) ✅ with SHA-256 + ed25519 signing
WiFi: wpa_supplicant + iw bundled ✅ auto-assoc on boot
wifi-setup command (console: wifi-setup <SSID> <pass>)
Chrome / Firefox on X11
Recovery console

Remaining gaps for "replace Ubuntu" daily driving

  • TLS certificate-chain validation (the TLS 1.3 client does the handshake + verifies the server Finished, but has no CA trust store or wall clock yet — confidentiality vs a passive attacker, not active-MITM protection)
  • GPU acceleration (framebuffer only; software rendering)
  • WiFi on bare-metal kernel (needs per-chip driver + firmware)
  • The real work-week path today: install to disk + rp.web mode

Boot it

Zero-to-QEMU in one line

Paste this into a fresh Linux or macOS terminal. It installs the Rust toolchain and all required tools, builds the ISO, and launches it in QEMU automatically:

curl -sSf https://raw.githubusercontent.com/rfi-irfos/rusty-penguin/main/install-dev.sh | bash

What it does: installs rustup (nightly + required targets), grub-mkrescue/ xorriso, and qemu-system-x86_64 via your system package manager, clones the repo, runs bash iso/build.sh, then launches bash launch.sh. Total time on a fast connection: ~3 minutes.

Manual setup (if you prefer)

# 1. Rust nightly + bare-metal targets
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y --default-toolchain nightly
source ~/.cargo/env
rustup component add rust-src --toolchain nightly

# 2. QEMU + ISO tools (Ubuntu/Debian)
sudo apt-get install -y qemu-system-x86 grub-pc-bin grub-efi-amd64-bin xorriso

# 3. Build + launch
git clone https://github.com/rfi-irfos/rusty-penguin && cd rusty-penguin
bash iso/build.sh && bash launch.sh

On a real laptop (recommended path for daily driving)

# Flash to USB (replace /dev/sdX with your USB drive)
sudo dd if=rusty-penguin.iso of=/dev/sdX bs=4M status=progress && sync

# Boot from USB → GRUB menu:
#   "Rusty Penguin (bare metal)"  — pure-Rust kernel + desktop
#   "Rusty Penguin -- Web (X11)"  — Linux kernel + Chrome/Firefox
#
# First time: pick "Console / Install to disk", then:
#   rp-install /dev/nvme0n1       (or your disk)
#   wifi-setup MyNetwork MyPass   (if WiFi only)

In QEMU

bash launch.sh
# Or with Intel e1000 NIC (real laptop test):
qemu-system-x86_64 -machine q35 -cdrom rusty-penguin.iso -m 512M \
  -netdev user,id=n0 -device e1000,netdev=n0 \
  -device qemu-xhci,id=xhci -device usb-kbd,bus=xhci.0 \
  -display sdl

The preselected GRUB entry, Rusty Penguin (bare metal), boots the pure-Rust kernel. For a full work week (browser, persistence, Git), use the Web (X11) entry after installing to disk.

It runs the real DOOM — on our own kernel

id Software's actual 1993 DOOM (fbDOOM, an unmodified, dynamically-linked glibc binary) boots and renders on the pure-Rust kernel through the Linux ABI layer — no Linux kernel underneath. The dynamic linker (ld.so) loads it against libc.so.6 (relocation, RELRO, TLS), then D_DoomMain → W_Init (loads the WAD) → R_Init → I_InitGraphics renders into our framebuffer. Verified end-to-end via serial trace. Build it with bash iso/build-real-doom.sh.

DOOM running on Rusty Penguin

A separate GRUB entry, Rusty Penguin -- DOOM (demoable), boots straight into DOOM without the desktop at all (for maximum performance demo).

In progress: running DOOM windowed, next to the browser. The kernel now has preemptive multitasking, per-process address spaces (CR3) and ring-3 process isolation (the scheduler foundation, all QEMU-verified — see docs/SCHEDULER.md). Remaining: a higher-half-kernel VMM migration (docs/VMM_HIGHER_HALF.md), a virtual /dev/fb0, and window compositing. Honest status: real DOOM runs fullscreen as a standalone process today; the side-by-side windowed form is the next multi-step build.


The computational case for ternary

Balanced ternary represents the same range in fewer digits:

  • 9 trits → ±9841 (vs 9 bits → ±255 unsigned)
  • Multiplication maps to shift-and-add on a ternary number line
  • Neural networks quantized to {-1, 0, +1} skip every zero-weight multiplication — the entire basis of the sparse ai-runtime
rp$ tri 6 * 7
  6 * 7 = 42
  ternary: 000000+-0 * 000000+-+ = 0000+---0

rp$ ai 8 4
sparse ternary inference -- 4 layers x dim 8
  L0 [00000+-0] -> [+-++-+++]  dormancy 79%
  ...
4 layers  avg dormancy 46%  skipped 120/256 ops

This is the same insight behind BitNet and ternary LLM quantization — implemented here from first principles in Rust, running bare-metal in a bootable OS. Each win is logged, with its honest basis, in docs/TERNARY_FINDINGS.md.


Part of the Ternary Intelligence Stack

Module Source
compiler/ ternlang-core lexer/parser/BET bytecode/VM
filesystem/ ternlang-fs VFS patterns
ipc/ ternlang-runtime TernNode actor model
hardware-abstraction/ ternlang-driver HAL traits
ai-runtime/ ternlang-ml TritTensor + sparse inference

License

MIT — see workspace Cargo.toml.