Preferences

You'll never find me saying that Wayland development is good in its present state. I think it's a mess and it has a lot of issues.

But let's be honest about Xorg. The overwhelming majority of people who worked on Xorg are now developing Wayland. Why? Because developing Xorg is a massive pain in the butt. It is a 400K LOC behemoth of a project and it has a ridiculous amount of technical debt. I would have to imagine that if the Xorg developers thought they could fix Xorg, they would do that instead of making a new thing.


> Because developing Xorg is a massive pain in the butt.

That's really no reason to build an entirely new system, and then half-ass it the way Wayland did. The Wayland gang should have started with a new, modernized, cleaned up window system API running as a layer on top of X11 and then start replacing the cruft piece by piece while keeping both the original X11 API and the new API working all the time, basically build the whole project from the user perspective (both 'regular' Linux users and programmers who need to build Linux apps).

I guess though the main problem is that feature parity with X11 wasn't even a design goal, they intentionally threw out the baby with the bathwater, and also intentionally fragmented the Linux desktop even more. It almost smells like sabotage (at least self-sabotage).

Also, it's been 17 years since Wayland was released, that's as if X11 would have barely started to become usable by around 2005.

> It almost smells like sabotage (at least self-sabotage).

See also: Ubuntu Unity, Gnome 3, KDE 4... all widely panned by their most loyal users. 2010s were the lost decade of Linux.

there were many of us who really liked gnome 3 though. Not that it was issue free, but the workflow was very appealing.
Sure, I quite enjoy it myself now. But I'd be lying if I said it wasn't borderline unusable for years.
It's not sabotage or self-sabotage, implying some intention behind it. It's just classic second system syndrome: hyper-fixating on real or perceived flaws that were never able to be solved or done right in the previous system, which can be to the detriment of other considerations.
There wasn't a need to have 10s of different wayland compositors. There is not a need to endlessly bikeshed over extentions instead of delivering user value. These are failures of leadership in driving the replacement of X.

Just compare this to Windows and how they made this rearchitecture of making their compositor more modern without splitting into 10s of compositors and breaking a ton of apps.

Here you're just comparing proprietary closed source development to open source development. In the proprietary version the goal is to improve a product. The OSS goals are much harder to pin down and can be different person to person, but it wouldn't be unreasonable to have a goal of "make it so that other devs can make their own compositors easily" and therefore you're describing an obvious success.

Short term this might be a far slower and worse approach. It's not clear that's the case long term though, making things easier to try out different ideas and then finding a winning compositor project could be better than being stuck with one.

It isn't particularly easier to make your own compositor either, as you now also have to bring your own window manager. What made the X architecture much more interesting is that it avoided coupling the window manger to the compositor. Hell: there even are multiple popular compositors for X, as they also managed to avoid coupling the compositor to the display server (which would be the one part of the system that you don't find too many of -- though there were multiple implementations over the years! -- but that's not really much different than Wayland where everyone is using the same library to implement the behaviors as part of their coupled-together balls of mud.)
>What made the X architecture much more interesting is that it avoided coupling the window manger to the compositor

This is the industry standard, putting the compositor and window manager in separate processes.

Android separates SurfaceFlinger and WindowManagerService.

iOS separates quartz compositor and springboard.

Windows separates dwm and explore.

MacOS separates WindowServer and Dock.

Dwm is both the compositor and window manager in Windows. It’s the same with WindowServer in macOS.

If you are talking about the shell or task switcher, then yeah your point stand with Gnome but KDE has kwin and plasmashell processes.

Tell that to the Wayland people? ;P
But why would I ever want to have a separate compositor and window manager? Like the display stack benefits from "vertical integration", being modular is a tradeoff, often of performance and significant complexity.

Why not just make a display server (which handles everything rendering related, compositing included), and then add a window manager as a plugin/extension on top? Window managers are not that complicated.

I dunno: I have never ever wanted to make a compositor -- which, to me, feels like a really boring piece of graphics infrastructure -- and yet I have used multiple window managers over the years and have absolutely wanted to make my own window manager? In X, making your own window manager was so popular of an activity that it honestly felt kind of unreasonable just how many window managers existed, and yet everyone used one of a handful of compositors and I'm honestly not sure why anyone in their right mind would bother making their own display server?
for instance as a X11 user I don't want a compositor at all
> Short term this might be a far slower and worse approach.

We are way past the short term with Wayland!

Wayland is 17 year old.

Existing != used

It does not matter if the devs alone worked on it in isolation but at what point there was public use and how it has evolved. The earliest you could argue it was being used by user on a distro would be 2016 in fedora. Actual mainstream use in ubuntu around 2021 but optional and default literally only just this year.

Perhaps proprietary closed source development is better for making operating systems. Is it a coincidence that Google was able to scale Linux to billions of devices while open source development ones weren't? Open source development should take some lessons if they want to be successful and not aggrevate developers writing apps for your platform like what happened in the article, forcing them to do extra work.

If development for X is ceasing now, there isn't time to experiment on finding the true successor.

I think the hard part about the Linux desktop ecosystem and its development pattern is the cobbled-up-parts nature of the system, where different teams and individuals work on different subsystems with no higher leadership directing how all of these parts should be assembled to create a cohesive whole. We have a situation where GUI applications depended on X.org, yet the X.org developers didn't want to work on X.org any more. If the desktop Linux ecosystem were more like FreeBSD in the sense that FreeBSD has control over both the kernel and its bundled userland, there'd be a clearer transition away from X.org since X.org would have been owned by the overall Linux project. However, that's not how development in the Linux ecosystem works, and what we ended up with is a very messy, dragged-out transition from X to Wayland, complete with competing compositors.

Bazaar-style development seems to work for command-line tools, but I don't think it works well for a coherent desktop experience. We've had so much fragmentation, from KDE/Qt vs GNOME/GTK, to now X11 vs Wayland. Even X11 itself didn't come from the bazaar, but rather from MIT, DEC, and IBM (https://en.wikipedia.org/wiki/X_Window_System).

> Perhaps proprietary closed source development is better

Perhaps...

> Open source development should take some lessons if they want to be successful

A lot of people who write the gui stuff for Linux do it because they want to. Success is not necessarily the same metric as a company making a product.

There are companies working within the space and I doubt the licensing really makes much difference to the outcome (i.e. your Google example)

> If development for X is ceasing now, there isn't time to experiment on finding the true successor.

Why? Again, the people working on it because they want to don't need to do anything, they can experiment. Someone can still fix up issues in X. Some companies will fund the development of things that are important to them. You make it sound like the oss community should be acting like one entity to achieve something, but there is no overarching goal nor a reason for there to be one. People will continue pulling in different directions.

> A lot of people who write the gui stuff for Linux do it because they want to.

Think about how many people might want to write for it if it had a compelling ui stack, tho

Access to virtually infinite cash had more to do with Android's success than the source being proprietary.
Linux (the kernel) is also open source and doesn't suffer from the fragmentation problem. It's pretty much unique to the Linux desktop because there are too many cooks involved.

But even if there's only one cook, it could be worse (if that cook is the gnome team). At least with multiple cooks we can pick kde instead of gnome.

You think Linux isn't widely used at scale?

Phones are a different market from computers, even though they're technically the same thing. A large segment of people own "phones" but not a computer. Linux runs a large chunk of the internet. I think it's used quite well at scale.

Even in the server market the success of having a stable app platform can be attributed to Linux, the kernel, solely for having a policy to never break userspace. The base of the app platform was already figured out a long time ago, and if you look at the bulk of Linux contributions you will see that they are coming from companies using Linux commercially.
> You think Linux isn't widely used at scale?

Certainly not in a high-productivity environment. Google has to swap out most of the runtime components with distributed alternatives to make it compelling in a corporate (distributed) environment.

> it wouldn't be unreasonable to have a goal of "make it so that other devs can make their own compositors easily"

I can't say i've ever wanted a second compositor to choose from. Ideally it would just be part of the window server.

How can you compare the Cathedral with a bazaar? This is not a technical difference at all.

Apple/Microsoft can do whatever they want, just break compatibility at any point and everyone else wanting to have their programs supported on their platform will adapt.

Meanwhile for Linux network effect has a much bigger role to play, you can't tell anyone else what to do, but protocols can only emerge from working together.

Also, I wouldn't bring up Microsoft's display stack as a positive example at all.

> Apple/Microsoft can do whatever they want

Those two are worlds apart when it comes to backward compatibility.

> Also, I wouldn't bring up Microsoft's display stack as a positive example at all.

Why not? It's doing exactly what it's supposed to do, and has been since the late 90s. There's tons of fundamental improvements since then, but they're all under the hood without affecting user-facing features. I'd say the Windows display stack modernization is an excellent example of how it should be done (a real shame though that Microsoft is actively ruining Windows by adding user-hostile features on top of the pretty good technical base).

User experience and developer experience for an OS are real things. It's easy to make a bad experience, people have to actually care about being able to deliver a good experience. Even if you can't tell people what to do, it should be possible to align on something that can deliver a good experience for users and developers.

>This is not a technical difference at all.

Which is why I said it was a problem with leadership than with the technical merrits.

"Failures of leadership" implies that leadership actually exists. Does it?
Right, this is basically peoples' hobby projects. Nobody is incentivized to "lead" the Wayland project.
Actually, that'd probably be a better outcome. But as it is, Red Hat & Ubuntu et al pay people to work on Wayland and those people follow corporate priorities rather than centralized priorities.
I think Red Hat wants a working desktop but I don't think they have strong official opinions on how to get there. I think individual people are responsible for the GNOME/Wayland/Freedesktop messes.
Windows gets to completely rearchitecture their compositor because they only provide one stable ABI to get pixels on the screen: link to USER32.DLL, create the necessary objects to represent a window of your application's class, then create and pump a message queue for it. It's ancient, but it works, and more specifically will never change. Even the higher level toolkits Windows ships ultimately are creating USER windows, and USER has been the only UI ABI since version 1.

macOS is the same way, except Carbon (a light modification to the procedural Toolbox API) and Cocoa (the Mac's first OOP toolkit) were "toll-free bridged" to each other rather than, say, writing Cocoa in terms of Carbon.

In contrast, X11 is a protocol anyone can implement and speak. There is no blessed library that you must use. No, Xlib doesn't count. Servers have to take their clients as they come. And Wayland, while very much deliberately stripped down from X, still retains this property of "the demarc point is a protocol" while every proprietary OS (and Android) went with "the demarc point is a library".

You don't see me working on this stuff, but people keep complaining about this because instead of one thing that works but is a pain, we have two things that work but are a pain. It's pretty obvious that while Xorg works for a lot of people, it's not the way forward; but I think it's apparent that Wayland might not be either... although I think it's likely some will end up running a wayland server with Xwayland as the single wayland client to get continuing driver support.

This is a lot different than say OSS vs ALSA. OSS really could have worked (and still does on FreeBSD afaik), but ALSA fully replaced OSS. I think pipewire seems likely to replace PulseAudio, even if it may not have PulseAudio's key functionality of ruining audio when things used to work just fine.

>This is a lot different than say OSS vs ALSA.

ALSA is an absolute nightmare to work with infinitely worse than Wayland. At best 10% of it is ‘documented’ through Doxygen. For the rest the only reference is the source code. This is one reason applications don’t tend to support ALSA anymore.

It's easier to write documentation than to completely rewrite a subsystem.
You're right, Xorg and X11 should be abandoned and for good reason. That should have happened decades ago. But Wayland doesn't actually fix anything that really needed fixing, other than wiping the slate clean. It's a good thing that Arcan exists, or the future of Unixland would be quite bleak.
How big is the Arcan development team? Is there any prospect of Gtk or Qt adding at least basic native support?
I don't know about GTK (and frankly hope anything will be ported to something else and the whole GNOME project get nixed), about QT they recently implemented a QPA. https://codeberg.org/vimpostor/qtarcan
That begs a question: if they had that much experience why they chose to structure wayland in a way that's such PITA to write for ? This just looks like some massive second system effect.

They just decided X11 did everything wrong and did it differently rather than pick up the pieces (if in spirit of idea, not code) that work and fix parts that don't

I wrote an app using Wayland and XCB/X11 and honestly, I found the Wayland part to be much easier to write than the XCB part, even though it required me to write more code.

This is partly due to the fact that everything you can do with Wayland is defined in protocols that are straightforward to use whereas in X11 you have atoms and messages with arcane name and structures for everything, a lackluster documentation and terrible error handling.

Well, yes. As you say:

Q: if they had that much experience why they chose to structure wayland in a way that's such PITA to write for ?

A: Because they were reacting to Xorg, so they wrote the exact opposite of that.

And for bonus points, because one of the problems they wanted to solve was "Xorg is hard to maintain", they made sure that the replacement was much much easier to maintain and develop... for them. Not for application devs, not for users, but for the folks making wayland, I have no doubt it's very well streamlined and easy to work on.

> they made sure that the replacement was much much easier to maintain and develop... for them

Tbh, if that were the case I would expect much faster progress.

The reason Wayland progress is slow is not technical. We have a coordination problem, people have differing priorities and views on what should be allowed.

There are people opposed to things like a allowing windows to specify their own bounds, and unless all the stakeholders agree to implement such protocols in their respective projects, the ecosystem will remain fragmented. Multiply this against every feature that people want.

It's unfortunately possible for multiple things to be true here. Xorg is an unmaintainable piece of tech debt. And Wayland made several poor design decisions that are now sending it down an eerily similar path, just with different, fresh tech debt.
And that tech debt possibly duplicated across multiple different projects now, too.
Right, I think we can all mostly agree that the old state of things wasn't great/sustainable. The problem, IMHO, is that they went hard on the second-system syndrome and went way too far the other way. This allowed them to replace a massive messy codebase with a nice clean codebase that doesn't do the things people actually need from it.

Xorg put everything - way too many features - into one single display server (Xorg). Wayland put everything in the hands of the compositor, and then spawned an endless array of them (most of them implementing only a fraction of needed features).

X11 de jure and de facto required all those features to be present. In theory you could have an X server missing new features, but there was no way to get rid of really old features, and in practice you really needed all the new ones or apps would break. Wayland made essentially everything optional, to the point of fracturing the ecosystem.

Xorg was a monolithic reference implementation. Wayland ships a reference implementation in the form of weston, and it's so feature poor as to be useless.

X11 has, in practice, really poor security. (There were/are attempts to improve this, but it's not been terribly successful.) Wayland is really big on security. So much so that they refused to implement little things like screen shots and a11y features because they could be abused.

IMHO, with hindsight, they should have done this in 2 stages: First, do the backend refactoring to get the nice driver-facing parts (GBM, AIUI). Essentially, make rootful XWayland the only Xorg, but in a way that is completely invisible to users. (Or, put differently, ship https://gitlab.freedesktop.org/wayback/wayback in 2010 instead of 2025.) Second, after you've done that and vastly simplified a huge chunk of code and made upkeep and refactoring easier, start working on X12. For the sake of argument, this can still be basically the same protocol as the wayland we actually got. However, don't actually ship that at first. Instead, go build/port an actual complete desktop environment to it, including all the features people actually want - clipboard, screen sharing, a11y and automation tools, remote desktop, etc. - and actually implement all the protocols needed for those. By all means make them optional add-ons to the core protocol, but make them up front. Also, I really recommend making one of those a window management protocol, so that 90% of window managers don't have to be a compositor, though some will. Then, after the thing is actually functional, start trying to get people to switch over. Don't start pushing people to adopt something half-baked and mess about for years on basic protocols that should have shipped day one (last I checked, in 2025 there are still 3 different incompatible wayland screenshot protocols). Make it an improvement, not a regression that only benefits you the Xorg developers.

> IMHO, with hindsight, they should have done this...

FWIW, it was also obvious to many people--certainly anyone who had ever been part of one of these big refactors before, whether as the platform or the user--that this is how it should have been done when they started... they just didn't care, and then they spent a decade both directly and indirectly (by condoning the behavior) bullying people who were concerned about the process and insisting that people who even still today have perfectly working systems were/are committing some kind of cardinal sin by not embracing the one true path of Wayland, despite regressions. It is extremely difficult to find any sympathy for the people involved :/.

Because I had to look it up:

a11y = accessibility

There's some irony here, I think. =]

The overwhelming majority of people who worked on x11 are retired and a growing minority are dead.

This is the fourth incarnation of x11 and the people working on it now have nothing to do with the people who developed it.

Xorg is the castodian group who started life as a fork, of a fork, of a fork of an spinout from mit.

Them trying to kill X11 is laughable to anyone who knows anything about its history.

Wayland on the other hand is now 18 years old and we've been told it will be good any day now for 18 years.

I mean, Wayland works fine for me. I'm using niri and an nvidia card.
Yeah. From what you read on here you would think it was totally unusable. Yet I use wayland all day every day. I use an AMD card and it even works. Sway for work KDE plasma for games. Everything I use works completely fine in wayland.
> The overwhelming majority of people who worked on Xorg are now developing Wayland.

I've never seen this documented.

> It is a 400K LOC behemoth of a project and it has a ridiculous amount of technical debt.

So we have people who want to create features but do not want to pay for technical debt. So.. they create more technical debt? Is there some indication that the wisdom of the crowd is particularly valuable here?

> I would have to imagine that if the Xorg developers thought they could fix Xorg, they would do that instead of making a new thing.

It seems like all the paid developers are working on Wayland while many of the volunteers are working hard to continue Xorg despite all the sponsored efforts to artificially shutter the project.

The article authors main complaint seems to be that distributions forced users to choose between one or the other when, at this point in history, there are zero good reasons to have done that.

Open source used to be about choice. Now it's about paid interests bullying you out of that choice. And Hacker News readily defends this in the name of modernity for it's own sake. It's truly a bizarre outcome to me.

> > The overwhelming majority of people who worked on Xorg are now developing Wayland.

> I've never seen this documented.

What do you mean you can look at the history of wayland on Wikipedia (it was started by Kristian Høgsberg) the person who wrote the DRI2 implementation for xorg. Other major xorg contributors like Hutterer have also been major wayland contributors.

I think the misconception is that people thought there are lots of xorg developers. That's just false, around the time when wayland was started there were maybe 10. And now there are even less.

> > It is a 400K LOC behemoth of a project and it has a ridiculous amount of technical debt.

> So we have people who want to create features but do not want to pay for technical debt. So.. they create more technical debt? Is there some indication that the wisdom of the crowd is particularly valuable here?

But that's not what they did?

> > I would have to imagine that if the Xorg developers thought they could fix Xorg, they would do that instead of making a new thing.

> It seems like all the paid developers are working on Wayland while many of the volunteers are working hard to continue Xorg despite all the sponsored efforts to artificially shutter the project.

Who? Looking at xorgs git there is essentially 1 developer making changes that are not related to xwayland?

> The article authors main complaint seems to be that distributions forced users to choose between one or the other when, at this point in history, there are zero good reasons to have done that.

> Open source used to be about choice. Now it's about paid interests bullying you out of that choice. And Hacker News readily defends this in the name of modernity for it's own sake. It's truly a bizarre outcome to me.

You mean the choice not to work on xorg? You're welcome to use X, but you can't bully others into keeping it going for you.

The reoccurring theme in these comments is that the people complaining have little knowledge of X internals, have usually not done any work programming a WM, a compositor or X or wayland libraries. Listening to the people who have done that (e.g. Rasterman, deVault...) are widely positive about wayland over xorg. It's also an indication that most recent interesting desktop experiments/projects (niri, sway, hyprland...) have been happening under wayland. And AFAIK none were corporate sponsored.

> The overwhelming majority of people who worked on Xorg are now developing Wayland. Why?

CADT.

There's so much hot debate about how bad Wayland is, how incorrect it is. But theres something I respect enormously about Wayland which is that: it is so so so much less than Xorg.

It uses the kernel's graphics buffers. It uses the kernel's mode setting. These alone are humongous differeniatiors.

There's so many other amazing glorious ways that Wayland is less. The protocol-centricity is vastly under rated, a massive win for the bazaar that can keep seeking truth versus the (imo utterly pathetic clining) absolutionist monolith style.

It's revolting to see such persistent bitter angry low user disdain, anger. Without any acknowledgement at all. That protocols allowing multiple implementations allows constant honing in, allows for dynamic change and evolution.

Reflecting on the Hindu Trimurti, a cycle of creation/newness, stasis/pattern, and decay & rot, it's amazing how the protest no-change/stasis-only voice has such a loud undying protest going. X is never getting better, has no room to improve, cursed by its own egocentric insanity which it has recursed into far far too far: which the core devs all agree.

It's not pleasant for everyone that Wayland allows a freedom of implementation. But generally most of the protest here has fallen away: support for major features is just here, on most implementations. That competitors can compete, don't have to keep using the same base is hugely advantageous to humanity. But the protest no-change anger-only voice is so loud. Doesn't know doesn't care.

Humanity should respect systems where competition and improvement are possible. X was a single consigned fate, with no growth or improvement. The competition of Wayland is an incredible breath of fresh air, and the growth of protocol competition here is telling, to not necessarily the "everything just works and is great" desire path of the low tech-ig orant beggar class, but which has enable so much Bazaar democratic figuring shit out, that still shares the ideas while allowing innovation within, in a way that few projects have ever enabled before. We are in a magic age of so so much, such cooperative competitive improvement, and it's just so unspoken, so missed, amid the squeaky wheels offering no actual technical critiques, unable to reflect upon the different (much better) age of possibility the bazaar model has opened us into.

This is exactly backwards. Whenever some team that is maintaining a monolith will look at the possibility of splitting it up and going with this protocol idea, they will look at Wayland as a cautionary tail of just how badly that works out in practice.
What an utterly vacuous statement saying nothing. Making no refutable claims. Typical hot air, full of nothing. Boring as fuck, nothing here.

Further, your point is spoken from the perspective of a company, a single entity. Companies are utterly unable to bank on Bazaar practices, to embrace the multitudes way of finding answers. They lack the hackerly blood to try many approaches. They are not creative enough to do anything but build their one Cathedral.

As a company, no, you should not try to build interoperable protocols to foster internal completion on. Duh, no shit. But strong command and control-while it may be good for a company-is not going to be how a much broader ecosystem finds the best paths to take.

It's incredibly impressive how much Wayland compositors compete/cooperate for better. Sway/wlroots for one example has a new Vulkan backend. They could just go try and do new things. There's protocols to implement and they made new implementations, and now there's a half dozen Wayland compositors that have new cutting edge tech they are trying out. Innovation at the edge, but working together, is the shit. Yeah it's not a model that helps the corpo's but that's because open source is searching a much wider field of options, looking much better for wins, and the cathedral model isn't going to get you any of that.

I'm still impressed what vacuous say nothing piece of shit useless Fear Uncertainty and Doubt folks can spread. This era has such a virulent pox of hatred, built around such empty words. None of these bitter words actually say anything, this whole discussion is filled with rabid useless disdain. Piss on ye, say something contestable you villainous cowards. What does you are, saying nothing, but trying to dynamite it all. A pox.

The calculus of what some team does is totally different than what open source does.

This item has no comments currently.

Keyboard Shortcuts

Story Lists

j
Next story
k
Previous story
Shift+j
Last story
Shift+k
First story
o Enter
Go to story URL
c
Go to comments
u
Go to author

Navigation

Shift+t
Go to top stories
Shift+n
Go to new stories
Shift+b
Go to best stories
Shift+a
Go to Ask HN
Shift+s
Go to Show HN

Miscellaneous

?
Show this modal