STABLE 13.2.0 · GNU/LINUX X86-64REAL_BIOSTAR PASSREAL_STORAGE DISARMEDEVIDENCE

ABOUT THE WORK

DEADBYTE / DBYTE

I build DBYTE because I like systems I can still fit in my head. Compiler, runtime, VM, native backend and object writers live close together so I can chase a bad result from source text down to the bytes instead of blaming a black box.

What is alive right now?

13.2.0 is the current public stable release. It ships native GNU/Linux x86-64 host tools and has real BIOSTAR physical-host qualification. The DByte REAL_STORAGE path is still DISARMED, and this release does not claim a finished full OS.

Stable manual · release proof · release history.

Rules from the machine room

  • One semantic authority. Backends do not invent language behavior.
  • Raw source, package bytes and release identities outrank polished prose.
  • Target-specific ABI and hardware facts stay target-specific.
  • Virtual proof and physical proof are never merged by wording.
  • Restore to known-good is a feature.
  • Cut the problem boundary before adding another framework.

Why not hide behind a giant stack?

Libraries are fine when I can see the boundary. DBYTE owns the parts where owning them makes bugs easier to see or the output easier to reproduce. Rewriting the universe for fun would be stupid; the code budget is real.

If the prose and the machine disagree, the prose does not win because it looks nicer.

Domain rant

I want dbytelang.org eventually. .org fits a non-profit hobby systems project better than .site. DBYTE is not a company and I am not trying to turn this into a subscription machine.

Why am I still on .site? I am broke. A second domain still costs money, and right now I would rather keep that money and keep shipping compiler bytes. When the budget stops being a joke, .org can happen. Until then, .site works.

In memory

Terry A. Davis (1969 - 2018). Rest in peace.

Thank you for what you gave us. Your work still reminds us that one person can build and understand a whole system.