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?
This guy vibecodes his whole stack, from X server, WM, terminal emulator, to shell and text editor. It would've been weird not to have an AI-generated image in an article =)
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.
Yeah, I have a mostly-functioning X11 server in Ruby, myself (not anywhere public yet).
Isene and I have relatively similar philosophies on this, except I have Claude burning tokens on optimizing and fixing my Ruby compiler now because I still want things in a high-level language, and my entire stack is Ruby instead of asm. But I love what he's doing - I just don't love x86 asm...
Turns out a functioning X server is a relatively simple piece of software. It's mostly just tedious. And most of the bulk is protocol handling that Claude can handle really trivially.
This "hopelessly proprietary, and you have to pay to use it." is what scary me most.
How often there are stories "Google/Apple/Microsoft [but mostly Google] deactivate my account for some stupid reason and I lost everything: my business, my tax data, my client data, my developer account and access to my apps, everything".
Given how few programmers very seriously write lots of assembly, it's kind of astonishing how good LLMs are at working with assembly. They can compile and decompile all on their own with apparently very little effort.
I suspect (with zero proof or understanding) that this has something to do with how well C maps to assembly. It's not a stretch to say the model's vector space maps this chunk of assembly with that line of C. And we all know how much C code exists online.
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".
Claude has surprisingly good knowledge of X11 protocol.
The other day, colleague showed me a (pretty basic) terminal emulator written in one-shot by Opus. Kicker is - that was compiled to a 30 KB static binary. That's right. No libX11, no libXfont, not even libc.
It’s an interesting strategy, but I question how much it pays off, if at all. Very few parts of a program benefit from manually tuned assembly compared to the naive C implementation. Writing everything in assembly adds an extra layer of thought, which even for an LLM is additional effort that could have been used for targeted optimizations instead. It makes it harder to notice patterns that have been trained into the data set, from security problems to performance opportunities.
On a long enough time frame with enough tokens invested there’s probably not a difference, but being written in assembly by an LLM doesn’t imply optimal to me. I’d almost prefer having an LLM rely on higher level abstractions offered by a programming language rather than rolling everything itself. After reviewing a lot of LLM code, even at Fable and Sol levels, I just don’t trust that LLMs are writing optimal code. Assembly makes it harder to even review.
I do it find it very fun and entertaining. This is a component and I’m grateful that it was shared.
Once you create an abstraction (like a macro, routine, language) you forfeit the benefits using machine code gives you wherever you use that abstraction, since there could be some bespoke implementation that solves the problem.
That entire point is moot here because the abstraction in this case is a massive ball of crap and it's used everywhere. So you never get the benefit you think you would for using a lower level language. That's why generally LLMs are best with python and even better with a "harness" (domain specific framework and language)
You can just open it up and take out the fan. Might experience thermal throttling or shutdown though. For extra credit, go into the BIOS and underclock it until that doesn't happen.
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
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.
> 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.
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.
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.
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?
With the crazy lack of supply for hardware and ridiculous prices, seems we are going to have to start squeezing more juice out of our existing hardware. What I would love to see is how well this runs on an ancient system. Will this for instance run on an old PI and make it snappy?
38 comments
[ 0.24 ms ] story [ 18.4 ms ] threadrecently 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'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?
Also disable hardware SMT as a kernel option in grub config. Then the cores can clock down way more often and L1 data cache size doubles.
XFCE and X11 tripled my laptop battery life vs. whatever Wayland+GNOME Ubuntu (2024?) brought by itself.
Powertop and tlp also help.
Happy camping.
EDIT: the lower heat dissipation also halved boot time. That one surpised me the most.
EDIT2: Disable "atime" with ext4 option "noatime". Saves a lot of power, heat, trimming, and re-writes on your SSD/NVMe.
For "faster shutdowns" manually run systemctl start fstrim.service. Not exactly sure why fstrim.timer seems unreliable.
https://github.com/vidarh/ruby-x11
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.
Isene and I have relatively similar philosophies on this, except I have Claude burning tokens on optimizing and fixing my Ruby compiler now because I still want things in a high-level language, and my entire stack is Ruby instead of asm. But I love what he's doing - I just don't love x86 asm...
Turns out a functioning X server is a relatively simple piece of software. It's mostly just tedious. And most of the bulk is protocol handling that Claude can handle really trivially.
(Oh, and the "compiler" will also refuse to generate certain types of programs.)
How often there are stories "Google/Apple/Microsoft [but mostly Google] deactivate my account for some stupid reason and I lost everything: my business, my tax data, my client data, my developer account and access to my apps, everything".
With LLM/Coding agent providers it will be worse!
I suspect (with zero proof or understanding) that this has something to do with how well C maps to assembly. It's not a stretch to say the model's vector space maps this chunk of assembly with that line of C. And we all know how much C code exists online.
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.
The other day, colleague showed me a (pretty basic) terminal emulator written in one-shot by Opus. Kicker is - that was compiled to a 30 KB static binary. That's right. No libX11, no libXfont, not even libc.
On a long enough time frame with enough tokens invested there’s probably not a difference, but being written in assembly by an LLM doesn’t imply optimal to me. I’d almost prefer having an LLM rely on higher level abstractions offered by a programming language rather than rolling everything itself. After reviewing a lot of LLM code, even at Fable and Sol levels, I just don’t trust that LLMs are writing optimal code. Assembly makes it harder to even review.
I do it find it very fun and entertaining. This is a component and I’m grateful that it was shared.
That entire point is moot here because the abstraction in this case is a massive ball of crap and it's used everywhere. So you never get the benefit you think you would for using a lower level language. That's why generally LLMs are best with python and even better with a "harness" (domain specific framework and language)
Modern macro assemblera are fun
No dependencies and better performance? Fantastic.
I wish mine had no fan too except me.
COBOL and 4 GL dreams coming into reality.
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 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?
AI wrote*
Or:
Maybe I'm getting too old for this, but I really don't see the point in having AI generate assembly code for this.Very inspiring and I applaud your efforts.
I haven't written assembler in years but this inspires me to do a small project for the fun of it.