Of course, it's entirely possible I'm misreading the history here: Wayland could've been widely despised back then, or maybe this thread is an outlier. Either way, I'd be happy to see if anybody's got a good pulse check.
Of course, it's entirely possible I'm misreading the history here: Wayland could've been widely despised back then, or maybe this thread is an outlier. Either way, I'd be happy to see if anybody's got a good pulse check.
Virtually all of the complaints listed in this rant are the result of enforcing a sane security model.
> I absolutely detest it when software tries to prevent me from doing what some developer thinks is "a bad idea" but did not consider my use case, e.g., running truss for debugging on FreeBSD needs to run the application as root.
These are not compelling arguments for running the GUI as root or allowing different applications to spy on each other.
I suspect the rationale behind this rant is motivated by the author's position as a BSD distro manager. BSD people really dislike it when Linux replaces legacy Unix infrastructure with Linux specific technologies. But if Wayland is doomed as an Xorg replacement, then why has development activity dropped off [0][1]?
[0]: https://www.phoronix.com/scan.php?page=news_item&px=X.Org-Se... [1]: https://www.openhub.net/p/x
For example, screenshots. It is still possible to make screenshots. It is not possible to make screenshots without the user knowing. What use case do you have to make screenshots without user knowledge, that benefits the user?
Why? If you knew all your programs, and that they are well-behaved, there is no need for that.
But we do use protected memory. And IOMMU (you know all the peripherals that you connect to your computer as well, right?). And other facilities intended to separate programs and hardware from each other.
So the same way as programs do not snoop on shared global heap, do not big-bang i/o ports, etc, programs are not supposed to snoop on shared display surfaces (really just a subset of 'global shared heap'). If you need something specific from them, you ask them via defined way (e.g. screenshot API), that might or might not have facilities to enforce access control.
Because we are not relying on them to be well behaved. Instead, we will notice if they aren't.
SCNR :)
I'm sure LOTS of people stopped using certain Unix programs that relied on a single address space whenever that was implemented. But to quote myself a few relies up,
>> These are not compelling arguments for running the GUI as root or allowing different applications to spy on each other.
> or give up on Linux entirely and get a Mac.
You mean the Unix that originally decided against using X11 because it would have required a re-write to do what they wanted anyway [1]? You understand that Wayland was designed by core Xorg contributors to replace X11 because attempts to match OS X resulted in a glitchy nightmare ... right?
[1]: https://news.slashdot.org/comments.pl?sid=75257&cid=6734612
The benefit of being wide open is that no coordination is needed between desktop environment and developer leading to a wide open field of tools that work on every environment without exception, difference in feature set, no need to check if version foo works on version bar of $DESKTOP.
You could of course get virtually the same benefits plus improved security at the cost of some complexity by standardizing the feature in common usage for nearly 30 years towards the beginning of the development cycle of Wayland instead of 13 years in.
You point out the need for security and completely ignore the fact that such security could trivially have been obtained without reducing users to obtaining a pile of tools only from their desktop environment or waiting 20 years for things to standardize so they can again pick and choose the best tools for the particular task.
It's not like they haven't figured out how to do that with Windows or OS X.
> The benefit of being wide open is that no coordination is needed between desktop environment and developer
The same is true of virtual memory.
> You point out the need for security and completely ignore the fact that such security could trivially have been obtained
The Xorg developers who tried really hard for decades would disagree with you. That's why programmers that Red Hat used to pay to hack on Xorg now get paid to develop Wayland [0].
[0]: https://www.theregister.com/2020/10/30/x_server_lead_maintai...
You misunderstand. Wayland development started in 2008. Screenshots/recording should have been on the board from day one and they could have gotten to standardizing on how to handle them in oh 2013-2015?
The sin is not the extra complexity to secure the system. It's having first zero then more than one way to go about it and 13 years later ending up in the situation where some utilities support only X and some only some Wayland implementations. It's the sin of forcing your users to rip out the walls and stare at the plumbing.
What other OS makes you think about display servers?
Red Hat doesn't believe in the Linux ecosystem and it shows they believe in their ecosystem with a singular official GUI and unfortunately an ecosystem in which one is required to use only their tools is a mostly mediocre one because they are best in class in nothing and worst in class in many.
I agree that Wayland's development has taken far too long and the transition has been rocky. But what development team couldn't use more funding? Ubuntu throwing a tantrum after the ecosystem rejected Mir and not contributing to Wayland certainly didn't help.
> What other OS makes you think about display servers?
I am sympathetic to arguments that Wayland/Weston could provide more functionality out-of-the-box. The bazaar's fragmented mess of "desktop environments" is certainly not a strength compared to what the Cathedrals have produced. But Linux's uniquely modular GUI stack necessitates coordination across lots of projects to develop and adopt standards.
But not doing anything and sticking with X11 would have condemned us to being stuck with an insecure, buggy, and visually glitchy mess forever.
> Red Hat doesn't believe in the Linux ecosystem
I have my qualms with Red Hat too, but my point was that Wayland was created by Xorg developers because they tried and failed to make X11 competitive. Seriously, just go watch this XFree86/Xorg/Wayland developer's talk [1].
I will have to disagree. I like having options. Before Wayland having options meant that your app starting GUI and your file manager was different. If Wayland had meant there were now two options one deprecated and the other coming this wouldn't have really been a huge problem.
It's a problem now because insisting on standardizing on so little means we now have fragmentation the likes of which we never had with X and will likely have for many years to come.
Even more so because it isn't yet ready about 6 years after its fanboys started insisting it was and shitting on other options and dismissing actual problems as the mutterings of crackpots and luddites.
What does "competative" even mean in this context? Linux has had a nicer GUI since 2003 and if you don't hop on the pointless change parade a fairly consistent one. I literally switched to linux for a better interface 19 years ago and its still better.
I agree that the transition has been long and messy. But the Linux desktop experience has always been a fragmented mess of half-baked apps that quickly fall into disrepair. Wayland breaks a lot of stuff that has been in maintenance mode for a long time. That sucks, but it's not a good argument for sticking with X11. The situation with X11 had been unacceptable ever since the adoption of virtual memory and Wayland is the only real alternative.
> It's a problem now because insisting on standardizing on so little means we now have fragmentation the likes of which we never had with X and will likely have for many years to come.
I'm not going to criticize the boundaries of a standard that I haven't been deeply involved with. I understand their impulse to keep it minimal, as Wayland is something of a forever standard. But I am sympathetic to arguments that Wayland doesn't do enough.
> Even more so because it isn't yet ready about 6 years after its fanboys started insisting it was and shitting on other options and dismissing actual problems as the mutterings of crackpots and luddites.
If by "other options" you mean Mir, my memory is that the primary criticism of Mir's original architecture replicated Wayland in an incompatible way without any good reason for doing so. Eventually Mir was re-architected to layer it on top of Wayland and does provide more of the batteries you seem to want to have by default.
If by "other options" you mean X11 ... only crackpots and luddites think applications should be able to spy on each other [0].
What other options were there?
> What does "competitive" even mean in this context?
* Not having every app double as a key-logger.
* A working screen-locker.
* Not tearing on window resize or scrolling while a video plays.
* Multi-DPI monitors.
* Non-blocking API calls.
* etc [1].
I remember context menus being especially glitchy.
> Linux has had a nicer GUI since 2003 and if you don't hop on the pointless change parade a fairly consistent one. I literally switched to linux for a better interface 19 years ago and its still better.
Let me guess, you use some "minimalist" desktop environment? I'm not here to hate on people that don't need what most consider a modern user experience. If that's what you want, that's great! I was into lightweight desktop environments for a while and liked exploring that design space.
But I'm also a usability engineer who remembers Linux back then: it was not competitive with OS X and it still isn't.
[0]: https://en.wikipedia.org/wiki/TempleOS
[1]: https://www.phoronix.com/scan.php?page=article&item=x_waylan...
* HALF BAKED
=================================================
> But the Linux desktop experience has always been a fragmented mess of half-baked apps that quickly fall into disrepair.
> Let me guess, you use some "minimalist" desktop environment?
You mean the environments which aren't half backed and instead of falling into disrepair just sit there quietly working the same way so you can use your computer to do useful things?
=================================================
* WAYLAND SECURITY
=================================================
Millions of people have apparently solved the keep applications from secretly hacking you for man eons and decades of real time by not installing uncle bobs malware from www.notarealsite.com or responding to prompts to install software by fake support scam agents.
This is admittedly inferior to better isolation but better isolation is quite hard and few people are actually tackling it in any meaningfully complete way. If I solely switched today from X to Wayland I wouldn't meaningfully improve my security because apps aren't strongly firewalled from one another and so many vectors exist its more like installing a screen door than a bank vault. Proposed improvements like flatpak actually greatly reduce security in practice by
- Allowing users to be targeted by targeting already fixed vulnerabilities in flatpaks with outdated libraries
- Making it MUCH easier to get random bobs software in front of the user
- Trivializing the gap between compromised developer and user by shortening the gap between compromise and distribution from days->weeks to minutes->hours.
All told security is on net a pretty pointless reason to switch to wayland at this point. See qubes, distro processes, FDE, user education about common scams for actual improvement in security.
Lets be real you knew I didn't mean MIR.
=================================================
* COMPETITIVE POINTS
=================================================
- Tearing: I didn't have this problem in 2003 and I don't have it now.
- Multi-DPI monitors: I am typing this on a machine with a 4K monitor flanked by 2 1080p monitors. I scale them down from a higher resolution. Apps think all 3 are the same DPI and its transparently scaled down so that UI elements are identically sized on all displays. Nothing is blurry.
- Non-blocking API calls. I'm using an environment not writing one. None of your users on earth care.
=================================================
* SECURING LOCKED COMPUTERS
=================================================
On desktop machines screen locking provides by default similar levels of security as locking a bathroom door it protects against casual intrusion. You can keep someone from sitting down and looking at your email it cannot prevent an attacker with physical access to your computer from gaining access to your data.
You could get greater security by blocking switching TTY and by blocking usb devices from being attached while the screen is locked for example with USBGuard regardless of choice of display server.
For machines that are at risk of actual attack you would want to to rely on FDE and either full shutdown or locking critical data when user isn't in physical control of the device.
None of this has much to do with choice of display servers and choosing Wayland by default doesn't appear to do much beyond what could be accomplished by blocking changing ttys.
=================================================
* END LINKS
=================================================
I'm not sure why you linked either TempleOS or a 9 year old write up on the design flaws of X.
For what its worth its not only dated but bad as well. Just to pick on a particularly bad patch.
>Wayland breaks everyone's desktop.” Also wrong. Once XWayland is finalized and merged we should have more-or-less perfect backwards compatibility because every X app just gets its own mini X-server to deal with.
This was back in 2013 and the entire ecosystem has spent 9 years going through growing pains with applications going through a plethora of Wayland specific issues with entire categories of applications disappearing or requiring different implementations on different compositors years later. In 2013 this was basically the definition of over-promise under-deliver. It's aged like milk and it makes the authors analysis challenging to take seriously.
Headless browser testing. Network admin at a corporate site. For starters.
For corporate uses, you can use something like vPro and it's remote access. It works independently of the OS (and by default expects user consent too).
Put another way: do we truly believe that in 12+ years, some motivated hackers couldn't evolve X11 into something better? I get that many of the people involved were burnt out on it, and sure, no one (myself included) stepped up to the plate, but it doesn't seem plausible to me that X11 and Xorg are lost causes.
IDK. I understand the direction they decided to take.
But when most (every?) computer includes some kind of GPU, local rendering makes the most sense -- especially when that's how your primary competitors work.
I don't know enough about Wayland vs X11 to make an informed statement, but I do appreciate that Wayland explicitly didn't try to include remote rendering. Let's just leave that up to other protocols (VNC/RDP/etc...). Now if we can just get one of those protocols to work on an individual application/window basis as opposed to the whole desktop.
Now I donate monthly to Xorg release engineering.
(for when you very rarely need to use X)
Could you spare a link, so I can follow your example?
EDIT: I should also mention that my experience is overall positive, I use swaywm so config and setup is easier than with X (no xorg.conf to tinker with every driver update) with a small stability tradeoff. Sometimes sessions will crash out when doing things with the GPU dmabuffers, which for a lot of people isn't really acceptable, but also who's usually using dmabuffers?
Oh and mouse interactions can be really wrong when going between xwayland windows and native ones.
Yes. It is not just a random program that needs some fixing here and there, it is a program which has to evolve with all its accompanying user space, as almost anything can be a breaking change. Sometimes reinvention is the correct decision, and I am quite sure that the whole X11 team uniformly deciding on that gives it enough weight.
(and I think the nvidia issue is solved or close to being solved)
wayland has been the only way I've managed to get tear free smooth 60fps on Linux (trying intel, nvidia and amd drivers on Xorg)
I don't have nvidia.
Where can I learn more?
FWIW I was also an i3 user for a long time (and xmonad before that), and I’m a very happy convert to Sway.
Though, fwiw, I had no issues with screen tearing once I started using picom. I used to have mild tearing before that, but after setting up picom (don't remember how I configured it exactly) I got buttery smooth output!
vsync = true
Love picomThey didn't switch to Wayland by default, because the apps weren't ready. The apps weren't ready, because they ran on current Ubuntu just fine, so why would they change. Chicken, egg.
Compare that to Apple macOS. Apple breaks macOS compatibility at the rate that GNOME can gush with envy. But the third parties are quick to update, without dragging their feet for years.
So if the signalling was, that Wayland is inevitable by release XX.YY, apps would be ready.
I went looking for a video demoing the first statement and came across https://youtu.be/sdSFzZCgWp0. I'd find a better video but sometimes the worse video is too funny to pass up :).
This post projects an idea that there is a new resurgence of push-back & dislike, a failure to come into fruition, but personally I feel there's been a long continual & ongoing history of refusenik/can't-do attitude, like nearly all new technologies & especially sizable open source developments face. And success is widespread.
What I see as somewhat new is that the pace in Wayland protocol development has indeed really tapered off, with a large part of that slowness being chalk-up-able to (alas) internal obstructionism. A lot of innovations have been really hotly contested. Rather than independent innovation (which Wayland protocols make imminently possible), there's way more bickering in the various protocol proposals & less getting shit off the ground. There's absolutely a place for getting it right, but the clashes have gotten louder & bigger & it's sapping the energy in the room. Virtual input devices for example have been a shit show and a half, all kinds of hard work & valid proposals getting snubbed & shot down left & right, rudely. Some stuff has just been slow: global hotkeys for example.
Even still, I think far more of the problems in this gist relate more to apps that just aren't well maintained (alike your NV gpu that has been a bad actor on the scene), aren't well cared for. Others of these grievances are kind of small & non issues, or just paranoia (eg: conspiracy-theory freak-outs about client side decorations), some are indeed deeply technical sticking points Wayland hasn't specified it's way through yet (hotkeys again), some just seem... wrong (most Intel users don't experience terrible godforsaken tearing all the time?) but a lot of them are just slow apps not doing basic good. Yeah. It takes a long time to improve a vast vast vast vast ecosystem.
That said, it's really been about a year that Wayland has been shipping truly genuinely en-masse, so the visibility & noticeability of issues is much much much higher than it had been.
The fact there was no default widget kit is the big one for me. If you're developing a new GUI in the early 2000s, "all the software looks native" is pretty near table stakes. Yeah, not doing so probably avoided a huge holy war, but surely the right thing to do would have been to do Xaw, GTK and Qt flavoured bindings atop some native widget set so you're at least 70% of the way there.
The movement from "window manager" to "compositor" is a huge scope creep. I'm going to admit that one of the things that drew me into Unix/Linux in the late '90s was the appeal of highly customized X11 desktops (i. e. Enlightenment v0.15).
Now, an X11 "window manager" is probably a within scope of one, or a small team, of moderately competent developers. I think one of the big old O'Reilly X11 reference books actually had a clumsy but functional example with line-by-line commentary. I like that I can run something fairly lightweight (FVWM, for example), instead of having to pull in most of the GNOME or KDE desktop incidentally because I want frames around my windows.
A Wayland-style compositor, on the other hand, seems to be a much higher barrier to entry. The whole "nVidia works, but only with the GNOME compositor" sort of stuff reads as a sign that there's way too much involved in there. I don't recall ever seeing "You have to use TWM because AfterStep won't work with your Trident 9440 video card" back in 1998. I wonder if it would have made more sense to go with a paired approach-- a single master compositor implementation, with the complicated and more hardware-sensitive stuff involved, and a pluggable window manager that spoke to it.
This wouldn't have worked. Different DEs will never ever ever agree on a common toolkit. If Wayland had a single official toolkit that means that today one DE (probably GNOME) would be using Wayland and every other DE would still be on Xorg (which is unmaintained).
The movement from "window manager" to "compositor" is a huge scope creep.
It's not. It's actually simpler and more reliable to implement window management inside the display server than using a separate process.
I wonder if it would have made more sense to go with a paired approach-- a single master compositor implementation, with the complicated and more hardware-sensitive stuff involved, and a pluggable window manager that spoke to it.
Agreed. Wayland probably could have done a better job of putting 99% of the code in libweston so that different compositors would only have to reimplement 1%.
But at the same time that was meant as reference implementation, prone to quick changes and no promise of backwards compatibility. It could hinder their initial progress instead.
Wlroots is exactly that and has been available for quite some years now (with many niche wms building on it)
All in all, the basics of Wayland are a pretty tight package. https://wayland-book.com/ goes through the pieces, and it's not a super thick read. The system of passing around surfaces is comprehensible, tight, makes sense, and there is very little fluff or barriers here, imo.
Wayland has a common core, but absolutely I'd grant that the various protocols do indeed make it a much less tightly coupled thing, with different compositors having different sets of protocols they support. So yes, some apps that require advanced capabilities run much better in some compositors than others; the compositor choice matters. Sometimes there are multiple competing protocols for the same feature-sets, but usually/historically, wayland-protocols hammers stuff out reasonably quickly & most of this is a matter of time.
Still, this is often easier than the past, where apps would have to each test for extensions & have various fast/regular/fallback codepaths depending on available extensions; not necessarily a hindrance to the window-manager, but a bundle of complexity for everyone else trying to use X11 adequately. The Wayland common primitives, on the other hand, are fairly universally performant & well chosen.
Returning to complexity for window-manager/compositor, the situation is not unlike X11 itself, where yes, a simple window manager (or compositor) is possible to spin up relatively quickly, but where there is a sea of different standards to implement to do a good job. Window manager hints, extended window manager hints, and a plethora of other standards existed around X11 that were up to the window-manager to tackle, and implementing each of those took a lot of time too, if you wanted good support for all apps. Different Wayland compositors also have different support for different protocols, and those are a bit deeper rooted capabilities, less superficial than many of the X11 hints (which, if ignored, were less likely to impede use), but the idea is the same: real support to really be decent took work in X11, and it takes work in Wayland to implement a good suite of protocols here too.
Where I disagree highly is calling out the hardware here. Wayland is closely tied to kernel fundamentals; any reasonably supported video card will perform adequately under any competent/non-specialist compositor today. (Certainly some compositors could demand higher standards, such as some of the experimental compositors requiring Vulkan, but generally compositors have very similar, very common requirements.)
> I wonder if it would have made more sense to go with a paired approach-- a single master compositor implementation, with the complicated and more hardware-sensitive stuff involved, and a pluggable window manager that spoke to it.
I like where we are, where there are various toolkits/libraries for accelerated implementing. Wlroots, which underpins chiefly Sway (the i3 replacement), has given rise to a variety of other compositors, spanning the gamut from quick/fast/experimental to rich/deep/powerful. libwayland still defines some core ideas, if not compositing implementations, to speed development somewhat. Weston is still available as a reference compositor, although yes it's designed (more or less) to be forked & enhanced, not built to be preserved & built (extensibly) on top of. Wlroots & other alternative toolkits fill this need, & provide a diversity of ideas for how we might get going. Projects like Greenfield, the HTML5 compositor (https://github.com/udevbe/greenfield) demonstrate the diversity we get from not having a single common core technology, are possible because of this belief in protocol & standards over implementations, eased though implementations might be from promoting something like Weston to the one-and-only implementation.
> The whole "nVidia works, but only with the GNOME compositor" sort of stuff reads as a sign that there's way too much involved in there.
We can't look at a anti-plays-well-with-others entity like Nvidia to assess what is/isn't a good idea. Nvidia spent nearly a decade stomping their feet & demanding only their way was ok. The fact that Embedded OpenGL itself, what the rock their obstinacy was built around (EGLStreams), is quite heavily on the way out further should stress how foolish & self-centered this vendor has been. This discompatibility indicates nothing, is no sign, except an indicator of what kind of a company Nvidia is/was (one that obstructed any implementations of well known & common kernel constructs).
And I very much don’t agree with the window manager compositor “feature creep”. If anything, the only reason it was easy to write for X11 is because X was a huge monolith doing things it really was not meant to, making you in essence write a window layout plugin. That’s why it was easy. But that just pushed (and worse, solidified) the complexity a layer beneath.
Wayland instead solves the complexity of its problem domain, not more, not less. You can still write a window manager plugin over wlroots for example with not much work, but writing a wayland implementation is not the same thing.
Honestly it really wasn't until SGI and NeXT did we see powerful mini computers on the desk running GUI applications in the 90s.
X11 is due for a replacement, but users just dont want to let go. Linux GUI based applications are still a small user base compared to the headless nature Linux normally gets used for.
For every 1 GNU GUI using Linux user, there are 100+ Linux installs that run completely headless. So the demand to move to Wayland is small.