Frame – Linux X server in Assembly

When first looking at the source code, I wondered why one would waste so much time to write 25k lines in raw assembly language, but then I saw that it was generated with Claude, for whom it does not matter much how expanded is the written text.

If someone had written this program manually, the strategy would have been very different. With a good macro-assembler (and nasm is good enough) one should define a great number of macros, to encapsulate all the tedious boilerplate, especially for things like function prologues, epilogues and invocations.

With a well written macro library, an assembly program can be almost as compact as a C program, instead of containing many text lines for each equivalent high-level language statement.

Such an assembly source with good macros can be read and understood much more easily than raw assembly language, like in this "frame.asm".

Otherwise, this is interesting work.

> I wrote my own

I see the growing trend of words losing all meaning is still going strong in 2026. I wonder what human communication will look like in the near future?

I am loving the shift from 'X11 is too big and messy to ever reimplement' to 'there are multiple wildly different X servers being built from scratch'.

Also, has anyone run it successfully? I got as far as building and running with --display and then running `DISPLAY=:7 dwm` and `DISPLAY=:7 alacritty`, but I can't seem to focus the window to actually type. Given that the author posted a picture of the thing actually running a live environment and claims to actually be using it, I'm pretty sure this is a me problem but I haven't been able to figure out where it is. Mouse works, too.

I'm a prolific vibe coder too, but I'm not going say I WROTE MY OWN Emacs for Commodore 64.

It's funny to see someone using a LLM as a compiler, making it convert higher-level operations into assembly, instead of just using a compiler.

I can have a machine generated X server in assembly too. It's called cc -s.

Or:

   $ objdump --disassemble /usr/lib/xorg/Xorg

How many times have people posted here about how software is no longer optimized because CPUs keep evolving, making programmers lazy? It seems things have changed. The question is: will LLMs manage to squeeze the most out of this hardware, better than compilers do? In the few tests I’ve run, yes, a lot.

Beautiful. Using LLMs to create perfect tools for yourself is my favorite thing about them.

No dependencies and better performance? Fantastic.

Was browsing some of the other rust projects(https://isene.org/fe2o3/#tools) and https://github.com/isene/torii says "Mozilla removed Firefox's "Open network login page" banner". I'm on windows and still see the banner so don't know if this is true. Is the really true on Linux?

I wonder if very cheap code generation will make software monocultures less relevant here. Because lots of incompatible devices is awful to work with, security stuff may also hurt

Up voting as it kind of makes the point I believe in, regarding how this AI powered tooling eventually will land on.

COBOL and 4 GL dreams coming into reality.

>I wrote

AI wrote*

> The underlying graphics engine, the thing that puts pixels on the screen. X11 is 4 million lines of code, a beast very few can claim they understand.

Working on it:

https://github.com/X11Libre/xserver

And they also deleted old code too. A lot of the old code could probably be removed, but is it really that relevant whether you have 4 millions line of code or 2 million lines of code? C is in my opinion too overbose. Rust is even worse. Which language would yield fewer lines of code without speed penalty? C is king largely because of the speed gains. We don't see people use python for an xserver.

״I am not sure this laptop has a fan anymore. Except me״ huh nice one

this is impressive, even with claude i think the guy have enough deep understanding of the OS and the varioius topic make it works

recently i also rewrite most of the app's underlying core function to rust, just like the guy do for the phone

perhaps i should also do more stuffs given codex reset too quickly

I would like to see a similar project that fixes Wayland. Like, can someone vibe-code window positioning, add SSD to GNOME (damage was already done, but still), and add the ability to send events so you can automate and drive the app offscreen for testing.

<I am not sure this laptop has a fan anymore. Except me.>

I wish mine had no fan too except me.

Interesting.

I've never quite found that Linux is more optimized on battery-powered machines for energy savings, even though supposedly there is a lot of room to tweak and optimize settings -- from selecting a low resource window manager/DE to turning off various services to switching up power management utilities. But this does seem like an approach that might produce that kind of fruit?

can it run Doom?

Was there a reason to add an AI-generated image to the top of the article? :(

[dead]

[dead]

Vidar wrote one in pure Ruby.

https://github.com/vidarh/ruby-x11