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.
Aurornis 1 hours ago [-]
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.
kees99 2 hours ago [-]
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.
amszmidt 17 minutes ago [-]
Only because the X Window System is very heavily documented, e.g., in the excellent "The Definitive Guides to the X Window System Series".
glitchc 1 hours ago [-]
No libc? It used inline assembly routines?
kees99 1 hours ago [-]
Yes, something like this:
static inline long read(int fd, void *buf, long count) {
register long rax asm("rax") = __NR_read;
register long rdi asm("rdi") = (long)fd;
register long rsi asm("rsi") = (long)buf;
register long rdx asm("rdx") = count;
asm volatile(
"syscall"
: "+r"(rax)
: "r"(rdi), "r"(rsi), "r"(rdx)
: "rcx", "r11", "memory"
);
return rax;
}
Chu4eeno 1 hours ago [-]
It's quite easy to get it to do syscalls directly, I even got Fable to do a simple standalone TLS implementation (in C). Not really useful since it hardcoded a set of supported algorithms etc., but it's fun to see how "simple" you can force it to go.
casey2 26 minutes ago [-]
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)
tty456 2 hours ago [-]
Sounds like another prompt is in order to re-write the code
bogwog 54 minutes ago [-]
> 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 wrote my own.... symphony, novel, programming language, etc
14 minutes ago [-]
QwenGlazer9000 51 minutes ago [-]
You're absolutely right!
yjftsjthsd-h 3 hours ago [-]
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.
vidarh 2 hours ago [-]
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.
Kelteseth 2 hours ago [-]
> 'there are multiple wildly different X servers being built from scratch'
by claude code. So this was only possible since no human had to bear looking at X original source code.
bogdan 2 hours ago [-]
Try running `tile` as a wm. I imagine it's not fully compliant to support dwm.
yjftsjthsd-h 1 hours ago [-]
Huh. So it's not the window manager. It's individual applications that are working or not.
Working: tile, dwm, pcmanfm-qt, feh, dmenu, glass
Not: alacritty, st
So... Thus far, anything but a terminal other than glass. I'd think the problem was alacritty doing fancy things with APIs that frame doesn't have, but st??
Quitschquat 21 minutes ago [-]
I'm a prolific vibe coder too, but I'm not going say I WROTE MY OWN Emacs for Commodore 64.
ToyKeeper 3 hours ago [-]
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.
pjmlp 2 hours ago [-]
Eventually that will be the way, revenge of COBOL and 4GLs.
duskwuff 9 minutes ago [-]
"Congratulations! You've reimplemented compilers, except slower, less reliable, hopelessly proprietary, and you have to pay to use it."
(Oh, and the "compiler" will also refuse to operate on certain types of programs.)
idiotsecant 1 hours ago [-]
There is evidence that LLMs are capable of making assembly that runs a great deal more efficiently than the compiler can manage on its own.
wild_egg 1 hours ago [-]
There are a ton of optimization opportunities that hinge on the intent of a piece of code which static compilers can never detect at scale. LLMs can actually navigate that and write surprisingly optimal assembly.
I've had all my side projects being written in x64 for the last 6 months and it is shockingly effective.
kibwen 49 minutes ago [-]
The purpose of an optimizing compiler is not merely to produce efficient assembly. The goal of an optimizing compiler is to produce efficient assembly while confidently preserving a program's observable logical semantics. Asking an LLM to spit out raw unstructured assembly based on inferred context from a specification given in English is a contender for one of the worst ideas I have ever heard; I award you no points, and may God have mercy on your soul.
Agingcoder 56 minutes ago [-]
Do you have references ?
throwaway613746 35 minutes ago [-]
[dead]
dlojudice 1 hours ago [-]
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.
jcs 48 minutes ago [-]
Most of the gain seems to come from choosing a much smaller program. Frame implements enough X11 for this one desktop and leaves out decades of compatibility work that a compiler would still have to preserve.
asveikau 12 minutes ago [-]
I can have a machine generated X server in assembly too. It's called cc -s.
Or:
$ objdump --disassemble /usr/lib/xorg/Xorg
NetOpWibby 2 hours ago [-]
Beautiful. Using LLMs to create perfect tools for yourself is my favorite thing about them.
No dependencies and better performance? Fantastic.
fhn 2 hours ago [-]
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?
spikk 2 hours ago [-]
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
pjmlp 2 hours ago [-]
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.
shevy-java 1 hours ago [-]
> 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.
mintflow 4 hours ago [-]
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
kosolam 22 minutes ago [-]
״I am not sure this laptop has a fan anymore. Except me״ huh nice one
gen2brain 2 hours ago [-]
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.
edumucelli 2 hours ago [-]
OMG, yes, please, get rid of all those composers, all that mess that people are doing. X11 is 40 years of battle testing. Wayland in 22 years (it already has 18) will be 100x worse than X11.
A Dockbar I am working on https://github.com/edumucelli/docking/ is a pain to build on Wayland. It already supports a lot of composers and even mutter/gnome with that Gnome shell extension, but at what cost ...
Chu4eeno 1 hours ago [-]
One of the issues with Wayland is that it forces every compositor to reimplement the X server, badly.
So you can't really "fix it", short of patching e. g. Gnome's compositor, with patches that will never be accepted upstream.
1 hours ago [-]
elendilm 2 hours ago [-]
<I am not sure this laptop has a fan anymore. Except me.>
I wish mine had no fan too except me.
casey2 50 minutes ago [-]
>I wrote
AI wrote*
system7rocks 3 hours ago [-]
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?
cogman10 3 hours ago [-]
The really unfortunate thing about linux is the defaults tend to be not battery friendly.
For example, I recently got another 1 hour out of my old laptop's battery because I didn't realize for the intel video card driver I needed to add some modprobe flags to get it to load up a firmware binary blob. Doing that enabled hardware video decoding, faster performance, and lower power usage.
There's a bunch of setting like this that you need to make sure are turned on to get the best battery performance. Some OSes are better about toggling them than others and mine (gentoo) let's you discover later that you forgot to turn them on :).
tcmart14 1 hours ago [-]
This is where looking at the gaming centric distros and doing what they do makes sense. I haven't seen all kernel settings for all distros, but my understanding is many choose the defaults and most of the defaults are more optimized for server usage. Which makes sense. Debian's biggest deployment environment is a fleet of servers. For the standard Debian Install, of course. However, my laptop is not a server, so the defaults don't make sense. This is where we maybe need distros that their whole niche is to be laptop friendly. Or, get the bigger distros, to offer a flavor with a different set of defaults for laptop environments.
inigyou 2 hours ago [-]
I have a laptop where you need to load a certain driver to turn off the discrete GPU, which triples the idle battery life.
cogman10 2 hours ago [-]
Yeah, I have this problem. IIRC the last time I looked into it, it requires a specific version of the nVidia driver which isn't the latest version (very unfortunately). I just bit the bullet and went with the 5W of constant consumption rather than figure out how to get that old driver working with my setup.
fhn 2 hours ago [-]
That's really sad to hear. I think it's just so much to configure for any human to take on. I'm going to run my system config through an LLM and have it optimize it for me see if that works.
exe34 2 hours ago [-]
Hey could you tell me about this flag please? I have an intel gpu and might need it too!
Thanks! Aha this is for gen 9ish onwards, my GPU is gen 3.
lproven 59 minutes ago [-]
Exactly -- not sure I have many machines new enough for this to apply to.
The machine I'm typing on is the 2nd newest in the fleet -- it's a work box -- and it's an i7-8550U, an 8th gen "Kaby Lake" chip.
dapperdrake 1 hours ago [-]
Kernel option nohz_full in grub config.
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.
c0balt 3 hours ago [-]
You might want to take a look at TLP[0]. It, among other things, backs the power mode/profile panels in Gnome/KDE.
Many distros already try to push good defaults, but you can do a whole lot when optimizing for a mobile experience. You can also do some fun stuff with it, like running a script[1] when going from ac->bat power to, e.g., turn of a service, lower refresh rate or reduce brightness.
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.
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.
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.
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)
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?
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.
by claude code. So this was only possible since no human had to bear looking at X original source code.
Working: tile, dwm, pcmanfm-qt, feh, dmenu, glass
Not: alacritty, st
So... Thus far, anything but a terminal other than glass. I'd think the problem was alacritty doing fancy things with APIs that frame doesn't have, but st??
(Oh, and the "compiler" will also refuse to operate on certain types of programs.)
I've had all my side projects being written in x64 for the last 6 months and it is shockingly effective.
Or:
No dependencies and better performance? Fantastic.
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.
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
A Dockbar I am working on https://github.com/edumucelli/docking/ is a pain to build on Wayland. It already supports a lot of composers and even mutter/gnome with that Gnome shell extension, but at what cost ...
So you can't really "fix it", short of patching e. g. Gnome's compositor, with patches that will never be accepted upstream.
I wish mine had no fan too except me.
AI wrote*
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?
For example, I recently got another 1 hour out of my old laptop's battery because I didn't realize for the intel video card driver I needed to add some modprobe flags to get it to load up a firmware binary blob. Doing that enabled hardware video decoding, faster performance, and lower power usage.
There's a bunch of setting like this that you need to make sure are turned on to get the best battery performance. Some OSes are better about toggling them than others and mine (gentoo) let's you discover later that you forgot to turn them on :).
https://wiki.gentoo.org/wiki/Intel#GuC.2FHuC_firmware
The machine I'm typing on is the 2nd newest in the fleet -- it's a work box -- and it's an i7-8550U, an 8th gen "Kaby Lake" chip.
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.
Many distros already try to push good defaults, but you can do a whole lot when optimizing for a mobile experience. You can also do some fun stuff with it, like running a script[1] when going from ac->bat power to, e.g., turn of a service, lower refresh rate or reduce brightness.
[0]: https://linrunner.de/tlp/index.html [1]: https://linrunner.de/tlp/usage/run-on.html#run-on-ac-run-on-...
https://github.com/vidarh/ruby-x11