Frame – Linux X server in Assembly

Original Article ↗ Hacker News Discussion ↗

A hobbyist X11 server for Linux, largely generated by an LLM in x86 assembly, prompts debate over whether such “vibecoded” low-level stacks can meaningfully improve performance, battery life and simplicity compared with traditional C-based systems. Commenters trade power‑tuning tips for laptops and note that minimal, purpose‑built components can run fast and lean, but question the maintainability, safety and real-world advantages of AI-written assembly versus mature optimizing compilers. The thread also broadens into long-running tensions around X11 versus Wayland, the value of hand-crafted versus autogenerated software, and what it really means to say one has “written” their own tools in the age of AI.

Project & approach

  • Topic is an X11 server (“Frame”) in x86 assembly, largely generated with an LLM and tuned for one person’s desktop stack (server, WM, terminal, shell, editor).
  • Many find it impressive and inspiring as an example of “vibe-coding” personalized, dependency-free, efficient tools.
  • Others question the point of AI‑generated assembly when compilers already emit assembly and existing X servers exist.

Linux power usage and laptops

  • Several comments pivot to laptop battery life: many find Linux defaults not battery‑friendly, especially for GPUs and codecs.
  • Suggestions include TLP, powertop, kernel options like nohz_full, disabling SMT, using lightweight DEs/WM (XFCE + X11), noatime on ext4, and trimming SSDs manually.
  • Some report big gains from enabling GPU firmware (e.g., GuC/HuC), powering down discrete GPUs, or tuning gaming‑oriented distros.
  • Others note complexity is too high for typical users, suggesting LLMs or specialized “laptop‑friendly” distros to auto‑optimize configs.

X11 reimplementation and compatibility

  • Multiple people note that writing an X server is “simple but tedious” thanks to well‑specified protocols and XCB XML descriptions.
  • There’s growing interest in small, from‑scratch X servers; Frame is seen as part of a trend away from “X11 is too big to reimplement.”
  • Some users report partial success running common WMs and apps, with terminals like st and alacritty failing; possible gaps around text rendering paths (e.g., RENDER glyph composites) are discussed but remain unclear.

LLMs, assembly, and compilers

  • One camp claims LLMs can generate assembly that is sometimes more efficient than compiler output, especially when they can reason about intent and avoid general calling conventions.
  • The opposing camp calls this “ludicrous,” stressing that optimizing compilers exist to preserve semantics reliably, while LLM‑generated assembly is opaque, unverified, and often wrong.
  • Some share positive experiences of LLMs writing/debugging asm and syscalls; others report them failing even simple VM‑style instruction execution tasks and gaslighting about errors.

Assembly style and maintainability

  • Critics argue that a human‑written assembly project would lean heavily on macros for readability; the generated code is verbose and harder to review.
  • There’s skepticism that full‑stack assembly via LLM yields global optimality; using higher‑level languages with targeted hot‑spot tuning might be better.

Wayland vs X11 and ecosystem concerns

  • Some wish for a similar LLM‑driven effort to “fix” Wayland: window positioning, server‑side decorations, automation, and event injection for testing.
  • Wayland is criticized as forcing each compositor to reimplement X‑like functionality, leading to an “80% solution” with lingering edge‑case gaps and perceived protocol purism.
  • Others counter that many features now work, and XWayland remains available for legacy behavior, though tensions about priorities and drama persist.

Authorship, AI, and language

  • Several comments object to phrases like “I wrote my own X server” when an LLM did much of the codegen, seeing it as part of a broader erosion of meaning (similar to saying “read” for audiobooks).
  • Others see the human as directing, curating, and integrating LLM output, and view such projects as legitimate “scratching your own itch” with new tools.