Rendered at 17:41:28 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
adrian_b 23 hours ago [-]
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 22 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.
cogman10 21 hours ago [-]
It will make the code slower.
Writing maintainable assembly is at odds with writing fast assembly in most circumstances.
A key optimization that's hard to pull off is inlining.
An optimizing compiler can see that a method is small enough that it can be pulled into the caller, it can then further eliminate from that smaller method branches that can't be executed due to the nature of the caller (Imagine calling a function with a `bool` parameter and you send in `true` at the call site).
To make the code faster in hand written assembly, you have to do the inlining, but that makes writing more structured code a lot harder. You are duplicating logic paths in the name of performance.
Not to mention the fact that the compiler gets updated and knows about more instructions and architectures then you do or then you could have. Hard to write the FMA instruction if it didn't exist when you were writing the assembly in the first place.
stelonix 2 hours ago [-]
Simply no. This is a catchphrase, a buzzword from compiler companies. We have seen here on HN time and time again many articles showing the truth to be the opposite of what you've said. It's time to put to rest the nonsense that compilers optimize better than humans. Here a few examples I've talked about:
It's true that in specific functions a human can do better than a compiler at optimizing for a target platform (sometimes, not always). That's a place where someone could reasonably drop down to assembly and get better performance.
But the case I'm specifically pointing out, one of inlining, is something that compilers do better than humans. This isn't "propaganda from compiler companies" (btw, not a thing. The most common and popular compilers are opensource and not owned by any single company). There are other cases like this where compilers are just more likely to get things right than humans are. They have a lot of heuristics about common assembly patterns that few humans can be expected to have memorized.
Each of the cases you pointed out are cases where the compiler does a bad job at optimizing a single function for whatever reason. They are not examples of a whole application written in assembly outperforming compiled high level languages. And each of the cases almost certainly took the human a considerable amount of time to figure out and prove their solution was better than the compilers.
What you've done is cherry pick when compilers fail and you are using that as evidence that they always fail.
Compilers sometimes fail, something I'm happy to admit. But on the whole for a whole application the compilers will get a lot more right than a human possibly could because they can output unmaintainable assembly.
kees99 23 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 22 hours 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".
vidarh 20 hours ago [-]
Yeah, I've had it work on an X11 server using a Ruby X11 protocol implementation instead of libX11, and it just rushed ahead and added support for a bunch of missing requests and responses. None of that is hard - it's all very well documented - but it's tedious.
My terminal emulator using the same binding also started out hand-written but Claude overhauled that too recently and it knows vtxx escape codes far better than me too.
glitchc 23 hours ago [-]
No libc? It used inline assembly routines?
kees99 23 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;
}
asveikau 21 hours ago [-]
The linux kernel also has its own headers (IIRC it was something like <asm/unistd.h> and/or <sys/syscall.h>, but might depend on architecture and version) where it will provide the stub asm statements.
In my memory the syscall ABI has changed a few times (i386 had int $0x80, then sysenter, then abstracting it in the vdso, then amd64 has 'syscall'), so it may be easier to let the kernel header provide the mechanism.
yjftsjthsd-h 20 hours ago [-]
The Linux syscall ABI is (famously) stable; on x86* you can still call into 0x80 just fine. There might be new interfaces made available, but existing programs shouldn't break. Although, in C there could be value in abstracting over the per-platform differences like int/syscall. I've only ever done raw syscalls from assembly where portability was rather moot:)
Chu4eeno 22 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.
tty456 23 hours ago [-]
Sounds like another prompt is in order to re-write the code
iberator 20 hours ago [-]
assembler is fun and kinda easy. easier than learning any JS framework in my opinion serious here.
Modern macro assemblera are fun
casey2 22 hours 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)
bogwog 22 hours 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 comment on hackernews. This is the prompt I used...
QwenGlazer9000 22 hours ago [-]
You're absolutely right!
cassianoleal 18 hours ago [-]
I already see a lot of people say they've "read" a certain book when they mean they listened to the audiobook instead.
yndoendo 15 hours ago [-]
Words matter to me. This why I say "consumed" vs read. Audiobooks are great for walks and long car drives.
cassianoleal 6 hours ago [-]
Yep, it's very weird. Consumed, listened to... There's ways to say the thing like it is. I guess "read" carries a certain superior connotation so people lean on it.
Note that I do think reading is superior. This is not to diminish anyone who chooses to listen to books. Some people do it because of accessibility, some because of time (can listen while commuting, or in the gym), or they just choose to listen to some books they don't care as much whilst still read the ones they do.
This is all great and people should be encouraged to do what works for them - but please don't pretend it's the same. Sometimes I even think we need a different word for reading e-books.
ape4 21 hours ago [-]
I wrote my own.... symphony, novel, programming language, etc
21 hours ago [-]
gspr 20 hours ago [-]
Thank you. I dread where we're heading.
21 hours ago [-]
yjftsjthsd-h 1 days 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 23 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.
ptx 18 hours ago [-]
Wasn't a lot of the protocol encoded in XML as part of libxcb? Could that be used to generate the tedious code for the X server?
vidarh 18 hours ago [-]
Yes, you're right.
There are other tedious bits too, like all of the details around exactly how to propagate which events, but the protocol encoding is certainly one of the most tedious bits.
Kelteseth 23 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.
vidarh 20 hours ago [-]
I think not looking at the original X source code is probably a good thing. The protocol is reasonably well specified, and you can further use the XML specification used for XCB. Most of the requests are pretty simple.
For some of the trickier ones it might be worth diving into an X11 implementation, but you can also defer most of the trickier ones other than getting the event handling right (most of the old school drawing API mostly matters if you want to run 30+ year old software that hasn't been updated much since; that said it might be nice to be able to run twm and xeyes - I have a whole separate file in my own X11 server for legacy stuff required to run twm and xeyes and similar ancient software, but not useful for anything else I actually care to run...)
bogdan 23 hours ago [-]
Try running `tile` as a wm. I imagine it's not fully compliant to support dwm.
yjftsjthsd-h 23 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??
vidarh 21 hours ago [-]
There are 3-4 typical different approaches to rendering text on X. If it's not yet (or not correctly) implementing one or two of them, that'd explain it.
EDIT: Testing with xtruss shows st uses RenderCompositeGlyphs8(), part of the RENDER extension. I don't have Alacritty installed, but I think Alacritty uses the GPU, at least by default? Looking at the source for Glass it seems to use PolyText16 - the "old school" old server-side font rendering API. A lot of older X11 apps would work fine with PolyText16, and a lot of newer X11 apps does all the text rendering client side into a shared memory buffer without requiring GPU support, so it's not hard to end up with a set of applications where none of them would run into either gap.
EDIT2: I've looked at the Frame source, and it does seem to have support for the RenderCompositeGlyph calls and other supporting request, so not sure what the issue with st is. It's not doing anything unconventional.
I'd try rxvt (PolyText8/16) or xterm (ImageText8/16). If either/both works it's likely an issue with the RenderCompositeGlyphs support.
ToyKeeper 24 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 23 hours ago [-]
Eventually that will be the way, revenge of COBOL and 4GLs.
vitally3643 21 hours ago [-]
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.
vidarh 20 hours ago [-]
It's relatively recent, I feel. Claude used to really struggle with writing asm not that long ago. But the last 6 months or so it's done great.
It's also far better than me (as someone who has done assembler since the Commodore 64) at using gdb to debug it, despite being effectively stuck using it in batch mode (which I didn't even knew existed). Watching it write elaborate scripts to dig into a code generation bug in my compiler is something.
I feel like the problem used to be that it'd struggle with the ambiguity of flow that is much more apparent in a high level language. But clearly that's not a problem any more.
gspr 20 hours ago [-]
I've had the opposite experience. Inspired by a recent HN post where someone made the world's dumbest browser by having an LLM read HTML and draw the rendered page, I thought I'd do a fun art project and take it a notch dumber: have the LLM "be" the computer and execute code as a VM. I chose a simple instruction set that I thought would be very present in the training material (RV32IM), and defined a very simple machine model with flat memory and two trapped calls (to terminate and to request to print).
I couldn't once get any of the SoTA models from a month or two ago to correctly execute more than the first 5% of the instructions for a fizzbuzz (compiled from C with GCC). As I recall, one of the Qwens did the best and would only mess up "a little bit", but that's of course enough to derail everything (can someone remind me again why we think natural language is good for interacting with precise machines?). I didn't think it'd go very well, but failing at decoding something as well-documented as RISCV is not very impressive!
Most models would also start gaslighting me when I pointed out their mistakes. To their credit, they'd very often cheat by deducing that the code was for fizzbuzz, and try to fake the execution. Always badly though. (This despite explicit instructions to execute the code faithfully instruction by instruction and not be informed by their overview of the code).
I honestly don't understand how people can work like that. I had fun because the whole thing was a joke, an art project. Doing serious work in that way must be so ridiculous.
But then again, I don't use LLMs very much and might be holding them wrong.
duskwuff 21 hours ago [-]
"Congratulations! You've reinvented compilers, except slower, unpredictable, hopelessly proprietary, and you have to pay to use it."
(Oh, and the "compiler" will also refuse to generate certain types of programs.)
idiotsecant 22 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.
orphereus 20 hours ago [-]
This has got to be the craziest AI-shill sentence I have heard in a long time.
How can a generic LLM generate better assembly than a dedicated compiler, whose sole purpose is to generate assembly code. With people pedantically adding every optimization imaginable and unimaginable to produce the most efficient code possible. And you have the audacity to say LLMs, which write garbage non-trivial amount of time, are capable of producing better assembly.
This has got to be either a masterful ragebait, or a person with very low knowledge of modern compilers, because even an LLM would not write something so stupid as this.
im3w1l 20 hours ago [-]
One simple thing that LLM's doesn't have to do is use a calling convention. Compilers need to use them, at least to some extent because it's not known at compile time who will link against this function in the future. Humans kinda need them because it's a lot of mental load when everything is custom. But for a sufficiently smart llm, noticing a register doesn't need to be preserved because there is only two callers and neither of them care about it might be doable.
bigyabai 20 hours ago [-]
Agreed. "Evidence" in this case is a weasel word that could be anything. Misconfigured LLVM? Old/unsupported GCC target? Doesn't matter, look at the evidence of great success! This 10kb assembly loop has a 44,000% speedup versus compiling with automatic vectorization disabled!
LLMs generating "assembly that runs a great deal more efficiently" is a ludicrous claim that cannot be substantiated outside PEBCAK situations.
wild_egg 22 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.
VortexLain 5 hours ago [-]
They can navigate that, if specifically targeted towards that, with proper adversarial reviews (including human reviews).
The question is, if one takes their time and has enough competence to do that.
Agingcoder 22 hours ago [-]
Do you have references ?
kibwen 22 hours 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.
wojciii 8 hours ago [-]
Now imagine doing this for some system which actually matters and can cost lives if implemented incorrectly. That would be scary.
vitally3643 21 hours ago [-]
Code is code my dude. If an LLM can turn English into Python, there's really no reason it can't do assembly. Assembly is not magic, it's just code that humans find difficult to grok. LLMs, it would seem, don't have the same kind of trouble understanding assembly that humans do.
Have you ever compiled something by hand? You should try sometime, it's an illuminating experience. Humans find it hard because you have to remember a lot of details while simultaneously paying attention to a different large set of information while also generating instructions. It's tough, but not impossible, it takes humans a lot of time and effort. How might a computer fare if it could remember everything and pay attention to multiple inputs and outputs at once? That's what an LLM does.
throwaway613746 22 hours ago [-]
[dead]
orphereus 21 hours ago [-]
At first I was so interested into this guy, writing his own everything, thinking this has got to be something to aspire to, to be as good a programmer as this guy. Then I realised LLMs wrote this, and I was so very disappointed. It was naive and stupid of me to think otherwise, but here I am.
VortexLain 5 hours ago [-]
This person's idea is that if LLMs can create personalized and efficient software on the fly, it's good enough to use such software instead of more bloated, existing software which has to accommodate for usecases outside of his.
Sortof like suckless.org, but vibecoded on the fly.
I've found his Rust android development framework quite interesting, and will probably try using that to vibecode some software I've always wanted to have for my own personal use, but I've never had the time to code properly, especially considering it won't be useful for anyone else. Of course, I'll probably release it under a FOSS license, in case somebody finds it useful anyways.
dlojudice 23 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 22 hours 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.
Yokohiii 18 hours ago [-]
For that to happen people have to prompt for it. Usually they already struggle to get basic stuff done.
asveikau 21 hours ago [-]
I can have a machine generated X server in assembly too. It's called cc -s.
Or:
$ objdump --disassemble /usr/lib/xorg/Xorg
Maybe I'm getting too old for this, but I really don't see the point in having AI generate assembly code for this.
wojciii 8 hours ago [-]
It's just you.
Everything that can be done with LLMs is better than without. Why use tooling at all when you just can use a LLM? Maybe just make the LLM generate machine code for your tager directly.
Just like making digital systems that are "better" than analog ones from the past because of digital.
asveikau 1 hours ago [-]
That hasn't been my experience at all. The quality of these things is absolutely terrible. Maybe if you have no taste and no actual skill, you can't tell the difference.
The fact that you have chosen to say this about generated amd64 assembly is telling. This is a terribly pointless exercise. Further, the llms are bad at more niche languages especially. Even experimenting with having them write C, which is quite a bit more common than writing straight assembly, I have seen them fall over quite severely.
NetOpWibby 23 hours ago [-]
Beautiful. Using LLMs to create perfect tools for yourself is my favorite thing about them.
No dependencies and better performance? Fantastic.
gen2brain 23 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.
Chu4eeno 22 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.
fc417fc802 21 hours ago [-]
It's also an 80% solution, the same thing so many rust "rewrites" are notorious for. Sure it finally mostly works at this point. Mostly. But it took a decade of kicking and screaming to get here and there are still edge cases that don't work, many clearly viewed as wontfix simply because there isn't enough popular support to force the hand of the purists. Hopefully llms make a community bootleg wayland protocol effort viable.
izacus 21 hours ago [-]
That's a bit dishonest since you're forgetting about all those features that now work, aren't you?
fc417fc802 20 hours ago [-]
Not at all. "Sure it finally mostly works at this point. Mostly." I explicitly acknowledged that after 10+ years of needless drama something like 95% (handwave) of the extended feature list is working.
And so much of it really was needless drama. Go read through many of the wayland protocol extension issue tracker threads. The amount of intentional heel dragging, willful ignorance, and purity spiraling is off the charts (IMO obviously).
To be clear I like and use wayland in its current state. There are plenty of valid criticisms of X11. IMO a redo was not a bad idea per se and it eventually turned out well enough (provided your app doesn't depend on the 5% that suffers an arbitrary rejection).
edumucelli 23 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 ...
Wayland is designed not to support all that stuff. If you're going to reimplement X in Wayland you might as well just use X.
23 hours ago [-]
Quitschquat 22 hours ago [-]
I'm a prolific vibe coder too, but I'm not going say I WROTE MY OWN Emacs for Commodore 64.
pjmlp 23 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.
segmondy 21 hours ago [-]
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?
vidarh 6 hours ago [-]
An X11 server is rarely on the hot path for rendering. Most X11 apps does most of the rendering to shared memory buffers themselves.
fhn 23 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 23 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
casey2 22 hours ago [-]
>I wrote
AI wrote*
mintflow 1 days 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
ozhero 21 hours ago [-]
This is the very definition of "scratching your own itch" lol.
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.
elendilm 23 hours ago [-]
<I am not sure this laptop has a fan anymore. Except me.>
I wish mine had no fan too except me.
inigyou 18 hours ago [-]
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.
kosolam 22 hours ago [-]
״I am not sure this laptop has a fan anymore. Except me״ huh nice one
At a glance, that looks like an X client library, not an X server?
vinceguidry 1 days ago [-]
Ah! You're right, I had read somewhere that he'd implemented his own X windows but I suppose I was mistaken.
vidarh 6 hours ago [-]
I had Claude prototype one, but it's not complete or public yet...
system7rocks 1 days 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?
dapperdrake 23 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.
cogman10 24 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 23 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 18 hours ago [-]
The beauty of open source is that you can be the change you want to see in the world.
inigyou 23 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 23 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 23 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 23 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 22 hours 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.
c0balt 1 days 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.
Was there a reason to add an AI-generated image to the top of the article? :(
VortexLain 4 hours ago [-]
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 =)
stonogo 1 days ago [-]
The article about an AI-generated X11 server? Why not?
mikepavone 24 hours ago [-]
Article reads like it was AI-generated too
shevy-java 23 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.
elcritch 18 hours ago [-]
Nim gives me similar performance to C++ in generally half the LOC.
The biggest problem with Xorg refactoring is that the entire surface area, every non-static function, is module API and there are closed-source modules everyone relies on (mostly Nvidia).
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.
Writing maintainable assembly is at odds with writing fast assembly in most circumstances.
A key optimization that's hard to pull off is inlining.
An optimizing compiler can see that a method is small enough that it can be pulled into the caller, it can then further eliminate from that smaller method branches that can't be executed due to the nature of the caller (Imagine calling a function with a `bool` parameter and you send in `true` at the call site).
To make the code faster in hand written assembly, you have to do the inlining, but that makes writing more structured code a lot harder. You are duplicating logic paths in the name of performance.
Not to mention the fact that the compiler gets updated and knows about more instructions and architectures then you do or then you could have. Hard to write the FMA instruction if it didn't exist when you were writing the assembly in the first place.
https://news.ycombinator.com/item?id=8508923 https://news.ycombinator.com/item?id=36618344 https://news.ycombinator.com/item?id=41922295 https://news.ycombinator.com/item?id=44186843 https://news.ycombinator.com/item?id=44177446 https://news.ycombinator.com/item?id=36949314
It's true that in specific functions a human can do better than a compiler at optimizing for a target platform (sometimes, not always). That's a place where someone could reasonably drop down to assembly and get better performance.
But the case I'm specifically pointing out, one of inlining, is something that compilers do better than humans. This isn't "propaganda from compiler companies" (btw, not a thing. The most common and popular compilers are opensource and not owned by any single company). There are other cases like this where compilers are just more likely to get things right than humans are. They have a lot of heuristics about common assembly patterns that few humans can be expected to have memorized.
Each of the cases you pointed out are cases where the compiler does a bad job at optimizing a single function for whatever reason. They are not examples of a whole application written in assembly outperforming compiled high level languages. And each of the cases almost certainly took the human a considerable amount of time to figure out and prove their solution was better than the compilers.
What you've done is cherry pick when compilers fail and you are using that as evidence that they always fail.
Compilers sometimes fail, something I'm happy to admit. But on the whole for a whole application the compilers will get a lot more right than a human possibly could because they can output unmaintainable assembly.
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.
My terminal emulator using the same binding also started out hand-written but Claude overhauled that too recently and it knows vtxx escape codes far better than me too.
In my memory the syscall ABI has changed a few times (i386 had int $0x80, then sysenter, then abstracting it in the vdso, then amd64 has 'syscall'), so it may be easier to let the kernel header provide the mechanism.
Modern macro assemblera are fun
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?
Note that I do think reading is superior. This is not to diminish anyone who chooses to listen to books. Some people do it because of accessibility, some because of time (can listen while commuting, or in the gym), or they just choose to listen to some books they don't care as much whilst still read the ones they do.
This is all great and people should be encouraged to do what works for them - but please don't pretend it's the same. Sometimes I even think we need a different word for reading e-books.
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.
There are other tedious bits too, like all of the details around exactly how to propagate which events, but the protocol encoding is certainly one of the most tedious bits.
by claude code. So this was only possible since no human had to bear looking at X original source code.
For some of the trickier ones it might be worth diving into an X11 implementation, but you can also defer most of the trickier ones other than getting the event handling right (most of the old school drawing API mostly matters if you want to run 30+ year old software that hasn't been updated much since; that said it might be nice to be able to run twm and xeyes - I have a whole separate file in my own X11 server for legacy stuff required to run twm and xeyes and similar ancient software, but not useful for anything else I actually care to run...)
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??
EDIT: Testing with xtruss shows st uses RenderCompositeGlyphs8(), part of the RENDER extension. I don't have Alacritty installed, but I think Alacritty uses the GPU, at least by default? Looking at the source for Glass it seems to use PolyText16 - the "old school" old server-side font rendering API. A lot of older X11 apps would work fine with PolyText16, and a lot of newer X11 apps does all the text rendering client side into a shared memory buffer without requiring GPU support, so it's not hard to end up with a set of applications where none of them would run into either gap.
EDIT2: I've looked at the Frame source, and it does seem to have support for the RenderCompositeGlyph calls and other supporting request, so not sure what the issue with st is. It's not doing anything unconventional.
I'd try rxvt (PolyText8/16) or xterm (ImageText8/16). If either/both works it's likely an issue with the RenderCompositeGlyphs support.
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.
It's also far better than me (as someone who has done assembler since the Commodore 64) at using gdb to debug it, despite being effectively stuck using it in batch mode (which I didn't even knew existed). Watching it write elaborate scripts to dig into a code generation bug in my compiler is something.
I feel like the problem used to be that it'd struggle with the ambiguity of flow that is much more apparent in a high level language. But clearly that's not a problem any more.
I couldn't once get any of the SoTA models from a month or two ago to correctly execute more than the first 5% of the instructions for a fizzbuzz (compiled from C with GCC). As I recall, one of the Qwens did the best and would only mess up "a little bit", but that's of course enough to derail everything (can someone remind me again why we think natural language is good for interacting with precise machines?). I didn't think it'd go very well, but failing at decoding something as well-documented as RISCV is not very impressive!
Most models would also start gaslighting me when I pointed out their mistakes. To their credit, they'd very often cheat by deducing that the code was for fizzbuzz, and try to fake the execution. Always badly though. (This despite explicit instructions to execute the code faithfully instruction by instruction and not be informed by their overview of the code).
I honestly don't understand how people can work like that. I had fun because the whole thing was a joke, an art project. Doing serious work in that way must be so ridiculous.
But then again, I don't use LLMs very much and might be holding them wrong.
(Oh, and the "compiler" will also refuse to generate certain types of programs.)
How can a generic LLM generate better assembly than a dedicated compiler, whose sole purpose is to generate assembly code. With people pedantically adding every optimization imaginable and unimaginable to produce the most efficient code possible. And you have the audacity to say LLMs, which write garbage non-trivial amount of time, are capable of producing better assembly.
This has got to be either a masterful ragebait, or a person with very low knowledge of modern compilers, because even an LLM would not write something so stupid as this.
LLMs generating "assembly that runs a great deal more efficiently" is a ludicrous claim that cannot be substantiated outside PEBCAK situations.
I've had all my side projects being written in x64 for the last 6 months and it is shockingly effective.
The question is, if one takes their time and has enough competence to do that.
Have you ever compiled something by hand? You should try sometime, it's an illuminating experience. Humans find it hard because you have to remember a lot of details while simultaneously paying attention to a different large set of information while also generating instructions. It's tough, but not impossible, it takes humans a lot of time and effort. How might a computer fare if it could remember everything and pay attention to multiple inputs and outputs at once? That's what an LLM does.
Sortof like suckless.org, but vibecoded on the fly.
I've found his Rust android development framework quite interesting, and will probably try using that to vibecode some software I've always wanted to have for my own personal use, but I've never had the time to code properly, especially considering it won't be useful for anyone else. Of course, I'll probably release it under a FOSS license, in case somebody finds it useful anyways.
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.Everything that can be done with LLMs is better than without. Why use tooling at all when you just can use a LLM? Maybe just make the LLM generate machine code for your tager directly.
Just like making digital systems that are "better" than analog ones from the past because of digital.
The fact that you have chosen to say this about generated amd64 assembly is telling. This is a terribly pointless exercise. Further, the llms are bad at more niche languages especially. Even experimenting with having them write C, which is quite a bit more common than writing straight assembly, I have seen them fall over quite severely.
No dependencies and better performance? Fantastic.
So you can't really "fix it", short of patching e. g. Gnome's compositor, with patches that will never be accepted upstream.
And so much of it really was needless drama. Go read through many of the wayland protocol extension issue tracker threads. The amount of intentional heel dragging, willful ignorance, and purity spiraling is off the charts (IMO obviously).
To be clear I like and use wayland in its current state. There are plenty of valid criticisms of X11. IMO a redo was not a bad idea per se and it eventually turned out well enough (provided your app doesn't depend on the 5% that suffers an arbitrary rejection).
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 ...
You can always use XWayland if you feel that way.
COBOL and 4 GL dreams coming into reality.
AI wrote*
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
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.
I wish mine had no fan too except me.
https://github.com/vidarh/ruby-x11
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.
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.
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-...
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.
For example I had Codex port Kiwi Cassowary C++ to Nim: https://github.com/elcritch/kiwiberry