That is fine. X11 needed fresh start. But they also failed to learn any lessons from X, just assuming "if X11 did it it must've been a bad idea, let's do it differently".
X11 did chalk many lines of abstractions in absolutely the right places, it's just the implementation was crufty in places, and just not designed for modern hardware in some other places, while wayland just tried to kick as much as possible to the WM side, making it so instead one place where those things need a bunch of code (the display system/its plugins), now every WM have to repeat that work and (more importantly) add incompatibilities because of that
> But they also failed to learn any lessons from X
Why do you believe that the developers of X failed to learn lessons from X when developing the replacement of X? Perhaps they learned lessons from X and decided to build it differently as a result?
Which is exactly what they did, as I understand it.
For example Wayland supports far more than just “generic computer screen”. I’ve heard it was designed to be able to handle systems either multiple very different displays. Like maybe a normal screen and an e-paper display.
I remember reading an article that mentioned the mess of screens in current cars would actually fit Wayland well.
Anyway, turns out computers really didn’t do that. We’re all still using one or more monitors that are mostly the same, with a couple of common aspect ratios.
Maybe they’ll be proven right. Maybe it’ll just be some extra stuff in the code forever.
Of course one of the ways you find out that you did something wrong was by doing it. So many comments online seem to just assume that the developers should’ve had the foresight to know everything they did that people don’t like or care about was wrong.
I feel real sympathy for both the developers and people with serious accessibility issues it has been a problem for.
But “beat up on Wayland” is practically a meme. An easy way to score points without looking at the big picture of how we got here.
> For example Wayland supports far more than just “generic computer screen”. I’ve heard it was designed to be able to handle systems either multiple very different displays. Like maybe a normal screen and an e-paper display.
The other common example is that wayland is well-suited to AR/VR 3D compositing, and X... isn't.
> I remember reading an article that mentioned the mess of screens in current cars would actually fit Wayland well.
It had better be well suited to cars, seeing as how it was significantly made for and by car companies. (I hear, at least; I'm told that it was significantly pushed forward precisely by companies developing automotive displays)
wlroots is self-described as "about 60,000 lines of code you were going to write anyway." It's also a moving target and you'll probably have to retool when wlroots updates.
That seems like a huge burden to carry around, considering that a minimal X11 window manager can be a few thousand lines of code and probably still compiles after 15 years.
I think that's actually the biggest real criticism that can reasonably be made about Wayland: they ought to have produced something like wlroots from the start.
Weston was only ever intended to be an example, and its monolithic nature meant that it wasn't particularly useful as a platform on which others could build (and this was even more true early on, before libweston).
As a result, GNOME and KDE both did their own implementations - and from that seed grew a host of complaints about things not working in one or the other, when on xorg they had worked more or less the same. The lack of a common entry point for "plumbing" also hurt, and can probably take much of the blame for the initial pain that many faced when first moving to a wayland-based DE.
But, of course, that's only obvious in retrospect. I don't think it was at all clear at the time those decisions were being made originally - in other words, it was a mistake rather than malice.
That helps, but you still have to - at a bare minimum - wire up all the functionality. My pet example is trying out a new wlroots compositor and discovering that it has no way to change keyboard layout because it doesn't use that code from the library yet.
I believe most of the original committers and maintainers of X are long gone, if still around they could very well be in their late 70s and 80s.
I would agree if you said many of the Wayland Developers people started with Xfee86. But I think the 'complexity' of X has to do with the fact no one of this generation fully understand why X11 did things the way they did, so Wayland was started. That is OK, but here we are.
I think the main issue is proprietary video companies did not to release their specs. I think if the Wayland people told the GPU Companies (like Nvidia) they will not support your hardware unless you release full specs, they would be further along.
OpenBSD is getting along fine without companies like Nvidia, I wish Linux and Wayland would tell these companies their GPUs will never be supported until full documentation is provided.
> I think the main issue is proprietary video companies did not to release their specs. I think if the Wayland people told the GPU Companies (like Nvidia) they will not support your hardware unless you release full specs, they would be further along
OpenBSD is g̶e̶t̶t̶i̶n̶g̶ ̶a̶l̶o̶n̶g̶ ̶f̶i̶n̶e̶ ̶w̶i̶t̶h̶o̶u̶t̶ ̶c̶o̶m̶p̶a̶n̶i̶e̶s̶ ̶l̶i̶k̶e̶ ̶N̶v̶i̶d̶i̶a̶ unuseable for any professional video-related work
> I think if the Wayland people told the GPU Companies (like Nvidia) they will not support your hardware unless you release full specs, they would be further along.
You realize nvidia managed to ship proprietary drivers for linux, right? They really don't need the support
The people behind Plan 9 did a much better job than was done with X11 and that was completely ignored as a path forward from what I can tell.
It’s tiny, secure, graphics subsystem independent (it’ll work on just about anything with or without a GPU, I would expect, given the API is so damn simple) and already designed.
the interface doesn't have to remain a file if that's not suitable.
rendering to a texture (an image) then displaying the image is what window compositors do, and what some games do. plan9 has a file you can write to which just dumps the image to the window/screen. there is no reason this could not work for Plan9. And if you don't want to open a file, write to it, then close it every frame, don't. implement a faster system. writing syscalls for plan9 is not difficult.
The first thing window compositors that care about performace do, is use shared memory, then there are a couple of other tricks that don't fit into everything is a file with a stream of bytes.
Try to imagine how a Vulkan driver could be done on top of a plain file system interface.
Not one that kind of works, one that can match the performance of existing implementations.
> The first thing window compositors that care about performace do, is use shared memory, then there are a couple of other tricks that don't fit into everything is a file with a stream of bytes.
Then don't use "everything is a file" to do it. I already said that. Use shared memory, I don't care. I'm not talking about implementing anything on Plan9, I'm talking about implementing something new on Linux, instead of implementing Wayland.
> one that can match the performance of existing implementations
pretty easy if we're not talking about Linux anymore. FreeBSD can run Linux programs faster than Linux can, and given Plan9's size, if we wanted to do it there, we could perform even better than that.
I was talking about taking what Plan9 and Rio had done, with virtual devices for every window and using that kind of a system in Linux as a starting point.
Wayland is certainly smaller than Plan9 but it is not smaller than Rio, and Rio is already designed and working. It might have been a great starting place and a real opportunity to rethink how Linux UIs work on a fundamental level. Putting syscalls in place of some of the files would not have been challenging. Changing how the mouse works would not have been challenging.
And if none of it worked, maybe we’d have a better idea about how to do the next thing. Software needs to change more. As software people, we get to define our own reality, and make reality benefit us rather than get in our way.
The people who wrote Plan9 knew that. Our industry has forgotten that. We keep working on old systems in old ways because that’s what we know. Because it’s easier than thinking about a new paradigm where the old rules don’t apply. I don’t care if it’s harder to do things in a smarter way. I care that things get better, and the only way to make things better is to do things in new ways. But we won’t do it and I don’t understand why we won’t.
Our industry certainly did not forgot that, people putting UNIX on a pedestal did.
It is no accident that many of the most successful graphical technologies that originated in UNIX world, came from UNIX vendors that went beyond being yet another UNIX clone, like NeXT and SGI.
My problem with it is their proxy for "best" seemed to be "opposite of X11." This was not a solid engineering choice, and I think this post is trying to demonstrate, that had costs.
I'd probably be completely fine with Wayland if it didn't have this obsession with military style desktop security. If it was as open as extensible as X11 by default then we all would have switched. X11 isn't pretty to write code for, but when it works, it works exceptionally well. Wayland seems to have made the wrong sacrifices where it mattered most.
They were in a better position than anyone else to be able to make those calls.
To whatever degree the choices didn’t work out, which I think is likely overstated, they learned something. But if they just threw everything away again, people would be pissed. Again.
This all feels like so much Monday morning quarterbacking.
> They were in a better position than anyone else to be able to make those calls.
I don't trust blind appeals to authority.
> But if they just threw everything away again
No one suggested that.
> This all feels like so much Monday morning quarterbacking.
I don't like the system. I don't know what to tell you. I write a lot of X11 software. I don't really want to switch to writing Wayland software. The developers missed this point of view.
The adoption rate is unusual. I'm offering an explanation. I understand people consider it hostile to Wayland but I can't understand why. If you want to solve the fundamental problem, then I have to admit, I'm part of that problem, for the reasons stated. You can ignore them, but you'll have to live with an exceedingly slow adoption, which as the article points out, may be so long that it is replaced nearly the time it is finished. Which would not be ironic considering that's exactly what is happening to X11.
Again, I have nothing against leaving X11, but it should clearly be a hard sell to anyone who likes X11 to go to a platform that is actively hostile to some of it's well regarded core features.
Open source has become fractious. It feels intentional. I say all these things because I honestly wish it was not. If none of this had happened we'd have a genuine alternative to the commercial offerings, and given some of their choices lately, we could have greatly capitalized on that. Que bono?
Anecdotal evidence: when using X11 years ago I could never avoid screen tearing despite trying various options, except with one option that seemed to replace it with random frame drops. (to be fair that's probably related to my GPU, which is also the reason why I could not use wayland for so long)
Wayland just fixed all that, making it at least usable for multimedia/gaming use with my GPU.
This is true, and it is also true that the maintainers of Wayland have done a terrible job of developing the replacement. It is mostly good enough now to replace X11, but based on what I've seen reported about different features, they frequently let "perfect be the enemy of done" when it comes to implementing critical features. I mean, just look at the drama around remembering the position of a window, its absolutely ridiculous that after years they haven't picked a "good enough" direction and implemented it.
That really isn't his gripe. In fact near the end he describes would have been a good direction for starting fresh.
His pain is that it's been 17 years and some basic core functionality is either still broken or entirely missing. It's not my expertise so I don't know if it could have been planned any better, but 17 years and _basics_ still being broken doesn't sound great.
I think part of the issue is that there's a couple of misconception about Wayland. Wayland focuses, exclusively, on being a window management protocol. Use cases such as screen sharing and accessibility are out of scope for such. Instead, they were supposed to be implemented through their own protocols. But those protocols didn't show up for a long while.
Data point: On my current and previous work laptops (iGPU ThinkPads) I switched from the default Wayland back to X11 because of various bugs (hangs, stutters, resume failures), in X11 they don't happen, seems to work flawlessly.
Sometimes it's worse to live in a mess that is being constantly fixed I guess.
I'm just lurking in the comments with popcorn, but if what you said is true and the maintainers of X decided it was a lost cause and unfixable, well that is the most informed opinion of them all. Nobody knows better then the maintainers. Sure, the replacement might have feature gaps initially but that is a transient issue.
X11 was started in 1984 in MIT. That means, when Wayland was first conceived in 2008, there had been 24 years of X development.
I guess Kristian grossly underestimated the effort required to write a full features Display manager.
FWIW, innmy career the times I've had to perform very impactful changes in software, I always start from the current codebase and remove/simplify stuff.
As an example, once I was in a company that had built a huge Ruby monolith which was not scaling at all. It had APIs for everything, including "high frequency trading" in the same codebase server, under a METAL aws instance (that's how they scaled).
What we did initially was simply copy the repo N times (sign up, compliance, risk, trading, etc), spin up an copies of the same server and use a balancer to route APIs to the different boxes.
Then we started removing unused stuff from each of the repository to specialize them. Fiinally we simplified complexity on each separate codebase.
Were they just supposed to keep working on the massive pile of hacks they felt needed abandoning?
They did what they thought was best. You hate it. Fine.
Do you think things would be better if they kept working on the unfixable mess?
I trust them to know what was going on better than random commenters.