[flagged]
The disconnect is developers want Wayland to replace X ASAP, while users want a smooth experience where nothing breaks due to it being Wayland, which is a high bar.
For me, Wayland remains one of the least favorite technologies I've dealt with. As a developer, I needed to port a custom Linux system to hardware that only has Wayland drivers and it was a giant pain. Wayland offers no advantage at all for that system but it broke a lot of functionality that relied on X in terms of window placement, etc. Took weeks of work to get a more complicated system that does 90% of what the previous one did, while still missing a few convenient features.
As a user, I try Wayland once in a while on one of my computers. It's improving - or more precisely, it's not Wayland itself but rather Wayland support of other software, like KDE. Earlier this year I finally worked under KDE/Wayland for a couple days with no issues, but then I again ran into some weirdness when using Unity so once again back to Xorg. What really makes Wayland hard to daily drive for me is that I have zero issues with Xorg. I don't use the things X can't do at all (fractional scaling is one I think?) so the bar for Wayland as a daily driver is admittedly a very high one, it needs to be completely free of issues because Xorg already does everything for me and Wayland's advantages are for the devs, not for me as a desktop user.
It also feels like it's improving slower than anything else has. Printing on Linux used to be a pain but now it works well. Wifi on Linux was hard to get working at some point but now it just works. Sensationally, gaming on Linux has become as easy as it is on Windows. Wayland protocols hit 1.0 in 2015 and now nine years later, it's approaching usability.
FWIW, I've had decent luck running cage ( https://www.hjdskes.nl/projects/cage/ ), then on that xwayland, and then just ignoring wayland and running X clients. The result does still have some slight quirks, but it mostly works fine.
Still, I can't help but be somewhat unhappy about how the forced use of Wayland resulted in a fair amount of work, the end result of which was running X clients anyway and trying to pretend Wayland isn't there.
Additionally, Wayland is already showing its age. The example that first comes to mind is how events are handled. Device events are received from the kernel and placed in a 4KB buffer that clients are supposed to read from and process. If the buffer fills up without being processed (for example, if high CPU or I/O stress causes a program to get descheduled for a few seconds and the user moves his mouse over the window), the compositor will sever its connection with the program, causing it to crash. This wasn't a problem for Wayland's initial embedded use case, but if you're trying to use it on desktop with devices such as high-polling rate mice it makes it far more unstable than X11 unless you have enough system resources to guarantee that no program will ever have its event handler thread pause for any reason. See here for more information: https://gitlab.freedesktop.org/wayland/wayland/-/issues/159
I wish that the "X11 is showing its age and should be replaced, but Wayland isn't the right option" viewpoint was more mainstream.
Few things are ever truly needed. Those things don't include Wayland. That doesn't mean there are reasons for it but it does mean you can't just discard the downsides.
> Xorg was complicated
And Wayland will be complicated too by the time its mature. Especially when you include all the other compontents needed to provide the same functionality as X.org
> Xorg was [...] insecure
Under what threat model? Personally I have no interest in the zero-trust model needed for proprietary app stores and would rather not pay the cost.
> the maintainers moved on to Wayland
A lot of those maintainers are employed by Red Hat and other corporations. They moved because their employers have reasons to move to Wayland - those reasons don't neccessarily matter to all users.
> Nobody else wanted to take up the mantle of maintaining an X implementation.
Isn't it a bit early to pronounce that. X is mature software. It works just fine for most people. Why would you expect someone to immediately jump at messing with it?
Under the threat model of websites using browser exploits to grab other data on your system?
Or under the threat model of company policy or legislation not allowing you to handle confidential information on a system that can't offer even a basic guarantee of privacy.
Browsers already have multiple layers of sandboxes. You can always add another one to the browser if you are paranoid.
Personally I prefer not running untrusted javascript in the first place (where I can avoid it). An exploit that gains control of the browser is already a doomsday scenario if you are using the browser for internet banking, work or anything that matters. Being able to grab the input and output of other applications is a nothingburger in comparison.
> Or under the threat model of company policy or legislation not allowing you to handle confidential information on a system that can't offer even a basic guarantee of privacy.
Those are usually fine with running countless proprietary drivers and tools with root access. So in other words it's security threater.
I also prefer running trusted code, but that's not an option most of the time (for varying definitions of trust)
99% of the apps I use have no business with the contents of other apps I run so why allow it? Because X11 can't do anything about it is not a valid reason.
Last I'd checked, Windows had the same security issues as X, so it's unlikely to come up.
Next to that Windows has an even stronger permission model regarding DRMed content. But thats only to please movie studios it seems...
Don't get me wrong; I don't like X, but if I had it my way we'd all be using Haiku with a Linux or BSD kernel right now.
> Also, I can take screenshots just fine on Wayland via KWin. I can't pick arbitrary 3p apps just yet but KWin's screenshotter is fine.
Maybe in another nine years Wayland users can choose whatever screenshot tool they want. X is annoying but I'd go crazy if that was my life.
Or you can use a different tool that supports Wayland now.
Or you can can add Wayland support to your favorite tool now (assuming it's open-source).
> Those aren't inherently insecurities, but the way X implemented them was quite insecure.
In what way does X.org add any security holes to the average Linux desktop where you have programs (from a trusted package repository) which can access everything your user account can?
These are very old issues and are some of the major reasons Wayland was started in the first place. May want to read up on what the problems identified by the project were when it started considering all X maintainers migrated their time and energy to Wayland.
I have zero interest in a low trust computing model because that comes with a cost to usability and performance, especially for power users but not also for others.
I also get that most commercial software developers these days should be treated as adversaries because they will break any trust you place in them. The correct response to that should be to not use their software or to create and enforce laws to get them to behave. This is really no different to anti-social behavior outside cyberspace - we have laws and police to enforce them precisely so that we can walk the streets alone without fear and leave our homes unattended. The degree of that safety varies greatly around the world and I much prefer living in places where I don't have to have bars in front of my windows. The same applies to computers.
Eg, this completely excludes Steam. Laws aren't a good way to deal with the issue because they don't prevent damage. Try and sue some guy living in Russia.
That said, I've been using Nvidia+Wayland+KDE on my workstation for over a year now and while there are problems, it's certainly useable.
Plus the attack angle is someone having permission to execute apps on your machine, there's plenty of other nasty things they could do.
No, the attack angle is either a untrusted app running in a sandbox (fatpak, snap or crosvm or qemu with wayland passtrough[1]) with only a connection to the compositor or a trusted app running in a sandbox getting exploited, any apps handling foreign data is suspect here (Web browser, mail client, pdf, office suite, etc.).
[1] https://lore.kernel.org/qemu-devel/20231005024330.836-1-gurc...
That's a huge win. Firefox is a mainstream product with a ton of attention. And I get it from upstream repositories, it's not something I'm compiling myself.
If I can get away with giving 2-3 apps total on my computer screen recording permissions (OBS, Firefox, maybe a screenshot tool or an accessibility client), that is a massive reduction in attack surface, that would be a very large security win.
It would be great if the primary attack vector for recording my screen was an application with decades of sandboxing efforts going into preventing untrusted code from doing things like recording my screen without my knowledge.
I genuinely don't understand the issue, it's a big security win if I can close off permissions on my system and have them open just for the apps that have good sandboxing around their untrusted code. Bonus points if the app in question allows per-domain screen recording permissions, which Firefox does.
I would go so far as to say that (one of) the reasons you run 99+% of your untrusted application code in Firefox is probably because Firefox is one of the very few places on your computer where it's safe to run that code. So it's a big win if we can start pulling some of those same sandboxing ideas into the native world; maybe that makes it easier to use more native apps for some tasks. It's a big win if I can treat apps on my computer the same way that I treat a random website.
Also keep in mind that "untrusted" is not a binary state. I pretty much only run apps on my computer that I "trust", but do they need to be able to record my screen? No, and I love the possibility of not needing to worry quite as much about what happens if they get compromised.
----
There's a somewhat strange notion here that because people do everything in the browser per-app privileges don't matter. But in fact, the reason the browser's security model works and the desktop's doesn't is because the browser has per-domain privileges and permissions, and it's not that per-app permissions don't matter, it's that they do matter and the lack of them is why we centralize untrusted code into one of the few apps on our computers that has per-"app" permissions. Browser permissions work because they are granular, you can grant Zoom access to record your desktop without granting access to Facebook.
So maybe if the desktop copies that, maybe far in the future you won't need to run everything in your web browser just to feel secure. But as it stands with X11 I feel a lot more comfortable using a browser to record my screen specifically because it has privileges and permissions around that are segmented per-domain/"app". The lack of sensible security controls on the desktop is a contributing factor to why people don't use the desktop, and being able to lock that in and restrict the scope of where screen recording can happen does make me feel a lot more secure about my desktop.
Agreed. This debate is particularly frustrating because X11 vulnerabilities get brought up as an excuse for ignoring other sandboxing efforts, and then Wayland gets dismissed because of vulnerabilities when not using other sandboxing methods. You can't win!
----
Even if I'm giving my web browser full access to my computer, there are apps I want to sandbox without running them in a full VM. And there are multiple parts to this puzzle to get better security and sandboxing, but those sandboxing efforts don't work if I can't secure the most basic parts of the visual desktop. If someone is demanding perfect sandboxing before we start looking at X11, they're going to be waiting a long time because there is a limit to how much progress we can make in this area while X11 stays dominant.
And okay, sure, we're setting up clipboard access for web browsers, but I can turn that off. And then I can take advantage of flatpak, snap, qemu, whatever and I can at least get closer to actual sandboxing controls, even for non-malicious apps. And I can do partial sandboxing, which is also a good thing -- the idea that everything needs to be either fully separated from each other or have full permissions is just not a good approach to security, sometimes we partially trust things.
----
Linux security is like we're in a boat with multiple holes that are taking in water, and whenever anybody tries to plug one of the holes, critics jump out and say, "what's the point, if someone can execute apps on your machine, there's plenty of other nasty things they could do." And so you move to the other hole and somebody says, "what's the point, attackers can just record your desktop." There are multiple holes on the ship, let's start patching them.
Getting better sandboxing controls into Linux is something that is going to take time and that means we're going to be patching holes while other holes exist that we haven't gotten around to yet. There is a limit to what tools like Bubblewrap can do for a graphical app if it's hooked up to X11. And yeah, I want clipboard controls for my web browser, but also I run more apps on my computer than just a web browser, and different apps have different problems. It's not even just about exploits or malicious apps entirely, sandboxing is useful even just for setting up temporary builds or dealing with buggy code and the fact that we don't have perfect solutions shouldn't be an excuse to not improve the situation at all.
Oh, yes, it's very likely that Wayland will end up with the exact same vulnerabilities. It's very hard in fact to design a windowing system that allows rich interaction between apps, but still maintains per user access control (never mind actually implementing it).
In practice, that's true (things like flatpack claim to support fake sandboxing, but whatever.)
Hypothetically, in a universe where Wayland was running on top of something other than the Linux desktop ecosystem, you could run untrusted code from bash with su, and have it talk to wayland directly, and it'd be OK. Today, you have to run it in a web browser, or using a VM with display virtualization drivers, or use any of a dozen other sandbox choices.
Those all managed to get the correct security properties under X11 because they're properly modularized. Wayland isn't, so to get this one feature, they're expecting all software to be rewritten.
ALL software was ALREADY rewritten for the web, so just use a web browser running directly on the hardware instead of bothering with X11 or Wayland or some hypothetical replacement like X12. That's just an extra useless layer that nobody needs.
A web browser is totally extensible and scriptable in JavaScript and WASM. Standards based. Excellent networking support. Streaming video. Secure sandboxing. Remote accelerated 2D and 3D graphics and GPU programming and WASM engine. Not rocket science. Off-the-shelf, well tested, open standards based solution. Problem already solved.
Why this is not the most obvious thing in the world since the Effrafax painted a mountain pink, and hasn't already been done, totally baffles me. It's as if the Linux community would much rather bicker and squabble about X11 -vs- Wayland for another 30 years than solve the problem once and for all and permanently and perfectly.
https://en.wikipedia.org/wiki/Somebody_else%27s_problem
>An SEP is something we can't see, or don't see, or our brain doesn't let us see, because we think that it's somebody else's problem. That’s what SEP means. Somebody Else’s Problem. The brain just edits it out, it's like a blind spot.
>The Somebody Else's Problem field... relies on people's natural predisposition not to see anything they don't want to, weren't expecting, or can't explain. If Effrafax had painted the mountain pink and erected a cheap and simple Somebody Else’s Problem field on it, then people would have walked past the mountain, round it, even over it, and simply never have noticed that the thing was there.
https://news.ycombinator.com/item?id=38442601
https://news.ycombinator.com/item?id=38442660
https://news.ycombinator.com/item?id=38445174
https://news.ycombinator.com/item?id=31988890
https://news.ycombinator.com/item?id=29094938
https://news.ycombinator.com/item?id=29097030
https://news.ycombinator.com/item?id=20182294
If I have to live on your world, I'll probably just chuck it all in and work with my hands for a living instead.
I think their comment means you’d be better off targeting an OS level sandbox (maybe based on OCI(?), which means a different container for each OS kernel or breaking kernel change — new docker doesn’t run on old linux as it is).
If you chose the OS level sandbox correctly, that would probably be more cpu-efficient than the web browser.
However, that’s a big “if”, since most of the linux sandbox thingies take multiple seconds to spawn a process, and multiply memory usage by 10-100x.
> However, that’s a big “if”, since most of the linux sandbox thingies take multiple seconds to spawn a process, and multiply memory usage by 10-100x.
And this is the thing I'm not willing to accept. Well, I can tolerate excessive memory consumption depending on what I'm doing, but I refuse to entertain long boot times. It's the main reason I avoid Java apps, Flatpacks, and so on.
X11 sucks. Wayland sucks. Get rid of them both! But the browser's not going away, and it's open standards based and cross platform, and there's a huge amount of collaborative work and money and talent going into making it better and more powerful and more efficient and more secure across the entire industry and all platforms, unlike X11 and Wayland (which nobody gives a shit about outside of a few fanatical Linux desktop users), or even the Windows and Mac desktops and Android and iOS interfaces (which billions of people use every day, but are stagnant terribly designed dead-ends).
The browser is a sandbox, so why run it on top of another leaky inflexible insufficient outdated sandbox full of clumps of dehydrated urine and cat turds like X11 or Wayland, instead of directly on the hardware?
No modern desktop environment is complete without a browser, so since you're stuck with it, why not just use the browser itself as the desktop environment (or whatever user interface paradigm you choose to use), since you're never getting rid of the browser, and modern non-browser desktops aren't as flexible or powerful or extensible as a browser, and most useful applications have been ported to run in the web browser environment anyway, so they can run across many different platforms, and be easily distributed and efficiently used over the network (unlike Wayland or "modern" X11 apps).
I'm just surprised this seems to be so hard for some people to understand, in spite of the fact that I've been making the same argument for more than a decade, and provided many links to those arguments, because it seems extremely obvious and straightforward to me, and the technology is finally mature enough to pull it off.
> No modern desktop environment is complete without a browser, so since you're stuck with it, why not just use the browser itself as the desktop environment..?
Because I want to use my desktop environment as my desktop environment. I've invested time and energy optimising it for my workflow and I'd like to continue to benefit from using it.
> non-browser desktops aren't as flexible or powerful or extensible as a browser
Again, I don't know what this means. My desktop is literally programmable. As in, I can edit and recompile the source code directly. Please tell me what's more powerful than that.
> they can run across many different platforms,...
I only need my apps to run on one platform
> ...and be easily distributed and efficiently used over the network (unlike Wayland or "modern" X11 apps).
`apt install my-x11-app my-wayland-app` `#include <sys/socket.h>`
Did you read any of them? Did you read my other explanation below that I just wrote personally for your benefit? Does it make any sense to you?
Do you understand what I mean now, or do you need me to give you some more citations of other times I've written the same thing, because there are more. What was unclear, and did I leave anything out?
Do you have any more questions I haven't answered time and again and already gave you links to but you just didn't bother reading?
It's exasperating and insulting that you blithely dismiss what I wrote without saying what you disagree with or can't understand, but I promise you, it really is easy to understand and extremely obvious on its face, if you will just take the time to read what I wrote, before complaining you don't know what it means.
If you have time to complain, then you have time to read what I wrote and linked to, before complaining you don't know what it means.
If you're too busy to read, then please don't waste your and my time complaining you don't understand what you didn't bother to read.
My experience with making an app work consistently across browsers is that it's hard work. Making it also work consistently with each OS it runs on is considerably harder. You want to guess how many times I've been asked to even consider either of those two things by a manager, let alone make them a priority? Never.
And going by my experience as a user of browser-based software, I'd say that's pretty normal across the industry.
And that's to say nothing of the fact that these apps are typically slow, cumbersome (by which I mean they throttle my CPU and drain my laptop battery), and crash no less frequently than unsafe apps written in unsafe languages like C (despite the fact that that's supposed to be impossible).
It seems to me that you want to rewrite the world in the browser. That doesn't seem very different to me from rewriting the world in Wayland. Whatever the differences between the two, they are insignificant besides the fallacy of rewriting the world.
As for the rest of your reply, I have no idea why you think I owe you however much time it would take me to read however many links you posted above. If you have something relevant to say, say it in the thread. Don't presume to leave it for me as a homework assignment.
And I haven't actually used it[0] but I thought waypipe was the better option for remoting?
[0] Well, successfully or recently; I'm assuming it's usable now.
In other words: while not originally UNIX-y, X matured in an ecosystem that idiomatically treats every userspace program as a perfect proxy for the user agent themselves. Sandboxing is a foreign (but good!) idiom that’s being bolted onto that paradigm.
You speak as if application sandboxing within the ever existed in the past... Not that people tried to build it and X doesn't play well with it.
I guess then the claim is more that no common implementation is amenable to sandboxing, and the compatibility break of a brand new protocol means they can implement it from day 1 in the way they like. Which is a lot weaker an argument, but practically speaking, it's true that no one is rushing to bolt on security features to X. To be clear I'm not realy a Wayland fan.
$ ps ax -ouser,args | awk 'NR==1;/X.*:/'
USER COMMAND
_x11 /usr/X11R6/bin/X :0 vt05 -auth /etc/X11/xenodm/authdir/authfiles/A:0-PFzcIG (Xorg)
root X: [priv] (Xorg)This is the most surprising part to me.
Despite the volume of end-user complaints I haven't seen any developer stepping up to take over the soon-to-be deprecated X.Org Server or advertising their alternative X implementation.
Even if it remains niche like the various systemd alternatives it seems like a lot of people would be grateful.
So it actually works now? Last time I tried switch to Wayland I also had to switch from i3 to Sway which just flat out refused to run until I gave it some hilariously insane command line argument like --my-next-gpu-wont-be-nvidia, and even then just crashed.
Demanding your users buy different (expensive!) hardware is obviously a non-starter. Especially if you want to do ML. Good luck without an nvidia card.
I can't even begin to think how you would present multiple windows to a user if you didn't composite them into a single image. Even if you are doing a 3D virtual desktop, you still have to composite the layers down to 2 single slightly offset images.
https://en.wikipedia.org/wiki/Compositing_window_manager
vs.
https://en.wikipedia.org/wiki/Stacking_window_manager
There are advantages and disadvantages to both approaches. Note that X.org is traditionally a stacking window manager but has had the compositing model bolted on for a long time now.
Are you thinking of tiling WMs? The major tiling Wayland compositors support floating windows when you want them, too.
> A stacking window manager (also called floating window manager) is a window manager that draws and allows windows to overlap, without using a compositing algorithm. All window managers that allow the overlapping of windows but are not compositing window managers are considered stacking window managers, although it is possible that not all use exactly the same methods.
It's possible that you have another definition but for me (and it seems for Wikipedia) the distinction is that a stacking WM does not keep buffers for individual windows but instead has them draw directly into the desktop buffer (details vary, the programs themselves might not have access to the buffer but send pixmaps that get blitted there). This results in lower resource usage and fewer copies but requires programs to redraw newly exposed regions when you move a window which may result in visible artifacts when programs cannot render fast enough.