If you’re not into Wayland as a display manager, it seems like your options are slowly dwindling. Xorg isn’t exactly a hotbed of activity, and the one fork everyone knows about is best known as a political lightning rod. Luckily, Rust developers can apparently never see a tool without pulling it into their heavily oxidized bucket of crabs, so we now have another option: the creatively named yserver, released under the MIT license by [joske].
The name, yserver, for the record, is just a placeholder name, but we rather like the simple logic of “Y comes after X” — sure, you could call it X12, but that could imply continuity, and this is a clean break. It’s also not a full reimplementation of the huge, sprawling mess that Xorg has become over the decades. It can’t launch multiple screens and thus lacks full multi-monitor support. So, for now, it may be too bare-bones for some people’s use cases.
As it uses Vulkan, it is limited to relatively modern hardware, but has been tested on Intel, AMD, Nvidia, and Apple chips. The target kernel is good old Linux, but the docs do cover compiling for FreeBSD; just be aware that that’s very much a secondary target. FreeBSD users are probably used to that, though.
On Linux, a standalone DRM/KMS yserver can successfully run not just window managers but full desktops — specifically MATE, Cinnamon, and XFCE, as they’re not on the Wayland bandwagon. It even supports Compiz, in case you missed the cube and wiggly window animations. You can also use yserver via Xwayland or even Xorg. Speaking of Xorg, [joske] has run the X.Org X Test Suite (xts5) against this proposed successor, and it currently scores 66.2%, which seems pretty good considering the project explicitly does not plan to copy all of Xorg’s functionality.
Aside from multiple screens, one thing that would have been neat to see is support for the Asterinas rust-based Linux-compatible kernel — though if that project achieves full Linux compatibility, that may be a non-issue. Even if you aren’t an oxidization enthusiast, you might find reasons to be happy to see more competition in the display-manager market — after all, Wayland Will Never Be Ready For Every X11 User. If Xorg really is destined to the slow death critics predict, perhaps yserver could cover the holdouts.
MIT license makes this a complete non-starter
Why not? It’s one of the most liberal licenses?
Doesn’t mandate propagating/sharing correction and expansion of the code base so it creates proprietary closed branches and incompatibly.
There’s also the fact this is 100% vibecoded. Can’t wait to see claude contend with the horrible concurrency jank that is the circa-2013 X11 protocol.
It’ll be interesting to see where this goes. I’m not convinced that the security and performance issues in X11 protocol are really as fundamental and unfixable as Wayland proponents claim.
But on the other hand Wayland is not going anywhere either, so we will have to live yet more fragmentation and duplicated effort in the coming decades.
It’s not going anywhere, it’s vibecoded.
Why? What that has to do anything with vibecoding?
Every vibecoded project implodes under it’s own weight after a few million tokens or so. AI can’t do anything except add more code, and has no concept of deduplication or global structure. Much less a purpose for why one structure might be preferable over another. Sure, it can GENERATE a justification post-hoc, but in the moment it’s just following the statistical vibes, man.
There’s a good thread starting at https://neuromatch.social/@jonny/116666900898570791 where he discusses the fallout of asking a slop generator to write tests for you. You get something vaguely test-flavored, but every file duplicates large sections of test harness code and it frequently sets up test conditions that are always true, true for a completely different reason, or just plain don’t test anything at all. That’s when you get when the goal is just to “make tests” and then to make edits until the tests pass.
There is vibe coding and AI assisted development. The difference is a human who controls the AI. If the human is senior software engineer they will control and shape the output of AI and enforce structure and testability. The problem is that it takes time which is always limited.
@Ivan It doesn’t matter HOW it’s used when the AI turns into a gibbering idiot above a certain size.
I just asked my AI to fix something. It came up with a solution. The solution worked fine. But it changed code in 8 different places, invented extra classes, hardcoded some objects directly in my class, and added like 50 lines of code in 4 different files.
I looked at its solution for 15 minutes. Then added maybe 10 lines of code to my one single class, and it was done.
AND… I still understand my code too.
I don’t know with who’se code this model (Qwen3.6-27b) is trained, but it was apparently not any of the code that I wrote in the past 20 years.
This is the difference between the vibe coding and AI assisted coding that Ivan was mentioning.
Does this support unified accessibility options like X11. Because of it’s security model Wayland forces each application to implement its own diverse individualistic accessibility option. And the default in Wayland applications is basically no support (Approximately 0.62% of the world’s population is blind).
Good luck getting it to even work with regular apps, nevermind accessibility apps. The whole thing is an LLM’s statistical impression of what an X11 server ought to look like.
If the person who posted this X11 server didn’t write any of it (an LLM did it for them) then what is the actual interest/draw of a project like this? There’s nothing to be learned from it for the average software engineer because there’s no experience to write about other than prompt engineering.
An political lightning rod Xorg fork? Ooo, juicy, I missed that there was such a thing, what fork we talking about? You didn’t link…
The one this article is about.
I was referencing XLibre, which depending who you ask is either a brave libertarian stand against corporate HR culture in open source, or an evil hateful fascist’s personal vendetta machine.
I don’t have a dead guy at that funeral, so haven’t dug into it– but if I had to bet money, I’d say the truth is that it’s a software fork rather than either of those things. Opinions on the quality of code going into XLibre differ as well; no surprise they break down almost exactly along political lines. OTH, it’s not vibe coded, so there is that.
I find it disingenuous that the original post can’t even use the name Xlibre. Look, I don’t want to care about the politics and I switched my LMDE system to Xlibre for stability reasons and could not be happier. I personally don’t think wayland is ready, I surely don’t trust another hastily thrown together rust rewrite.
Wayland is crap IMHO. The in ability to run remote apps on diverse architectures (x86, RISC V, ARM, etc…) is greater today than ever as we shift to thin clients and tablets
Luckily we also have XLibre to keep X Server compatible software working
https://github.com/X11Libre/xserver
i’m really put off by the repeated notion here that a lack of forward momentum in software is a problem. i don’t need Xorg to evolve — i use it the same today as i did 25 years ago. it’s the same as all the grumbling over dropping 486 support or whatever in the kernel…on the actual old hardware that i do occasionally use, the last thing i want to do is run a 6.x series kernel on it! old stuff still works, and for the most part the entire old history of it is still there! i can use ancient xfree86 with a linux 2.x kernel on a knockoff 486 with 8MB of RAM or i can use the latest xorg that still has the minimum support level of whatever bug fixes are needed to compile with the newest gcc/glibc (a surprisingly fast-moving target). our choices are not dwindling. we’ve never had more choices.
and another off-putting element of this project is how the idea of re-implementing in rust has evolved. Rust is an interesting language. i am inclined to believe that for people who like rust, and for projects that grew up with rust, it is quite compelling. But vibe coding some massive steaming heap “in rust” is not gonna realize those advantages! The benefits of rust’s innate memory safety cannot hold a candle to the downsides of hallucinated un-tested un-reviewed un-architected slop.