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?
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 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.
Luckily we also have XLibre to keep X Server compatible software working
https://github.com/X11Libre/xserver