This is a common sentiment, but it is kind of funny. Because software engineers working for companies will know the struggle of trying to justify reducing technical debt, improving security practices, etc. but fail to see why these things are useful to them personally when the tables turn.
Wayland indeed “breaks a lot of shit” but it’s not an accident or done due to incompetence. Also, it’s worth noting that since there is not one Wayland server the way there is one Xorg server, that not all of this applies evenly. For example, wlroots-based compositors like Sway do not suffer from the screen recording issues as Sway just supports a permissive screen recording API out of the box. I do think the XDG portal idea is a good idea, though, overall, and that the security improvements will be worth the toil eventually.
But more to the point, that the problem is that moving away from Xorg as a display server really needs to happen eventually. The legacy is holding back desktop Linux quite a lot. Issues like supporting modern high DPI displays or multi-GPU setups are ones that Xorg struggles with that Wayland can be made to handle more elegantly (in case of DPI, already does significantly.) It’s not just that. There’s tons of weird old crufty garbage in Xorg. Clipboard is weird. Drag and drop is weird. Wayland is simpler and makes improvements that are welcome, like a good API for keeping window configuration synchronized to help eliminate “imperfect” frames.
No doubt there are issues. I have some choice words about the decision of GNOME to push for using dbus to communicate cursor size changes on high DPI setups, and I do not like the way client side decorations are favored in Wayland.
Reducing technical debt by rewriting everything from scratch (almost?) never works. It's the baby and the bathwater. It's the sort of thing that seems attractive to junior developers, but more seasoned folks know that the legacy system contains years of embedded knowledge and workarounds for "real world" issues. The new, conceptually beautiful system always fails to capture that embedded knowledge, and ends up breaking many things in many ways for many people.
Perhaps we did need a new display server, perhaps Wayland is conceptually better than Xorg, but it'll be many years before it reaches feature parity, if it ever does.
> It's the sort of thing that seems attractive to junior developers
You make it sound like Wayland has been pushed by some script kiddies, when in fact the lead developers on Wayland are the actual Xorg maintainers.
To me, the migration from X11 to Wayland looks similar to the switch from DOS-based Windows to Windows NT. At the time, lots of programs were broken by the move because they assumed you could meddle in other application's internal memory. But breaking those applications was not malicious intent on the side of the Windows devs. It was a legimitate move towards a more sustainable architecture. I'm not intimately familiar with X11 internals, but my read of the situation is that X11 just exposes too many internals in its interfaces, and therefore it becomes increasingly impossible to adapt it to contemporary needs (in this case, application sandboxing).
> when in fact the lead developers on Wayland are the actual Xorg maintainers.
Daniel Stone[0] incredibly funny and educational talk[1] from 2013 could help many critics who missed the 3 decade long ongoing discussion of why X is bad. We've talked about this already in the mid 90ies (when there were no alternatives) and now 8 years after this popular linux.conf.au talk, people still having troubles understanding why X has always been a terrible tradeoff for both security and performance (well for literally everything).
The talk was interesting but it also shows how the speaker is a little deluded that everything turns around technical quality of code and developers. X is used and preferred by many users and application authors because it is the standard and it works.
> so what is the 1 thing X does, and what is it doing well?
It provides functional and well-established(accepted standard) graphics server technology/libraries for any application that uses graphics.
I don't care if it takes 10 liters of blood to compile one version of X or whatever. I'm a user. All I care is that my desktop works as robustly as did it yesterday or 5 years ago. If that's not happening, I'm not interested in macros, classes, variables, declarations, structs, or any other geeky CS technobabble. That's irrelevant. And a product that advertises itself as being created to be convenient for the people developing it is a paradox. Don't develop it, then. Makes things even easier.
Exactly! I laugh at this petition because nobody is maintaining X.org server right now or even wants to touch it. Last major release was iin 2018. It is a nightmarish cludge. Nobody is forcing anyone to upgrade their software but the rest of us want a future without X11.
It's not just the internals of X11 that are the problem, it's that the entire concept was baked in a different time. The major innovation of the X11 server was that, well, it's a server. It can be completely decoupled from the client, even physically if you use it over tcp. That was kinda nice, but then came GPUs, and direct rendering. The name of the game is now violating every single abstraction that stands between a userland app drawing directly to the display with only a GPU and a single graphics api in between. It was definitely not junior developers who rewrote the entire kernel graphics stack to move from frame buffers to direct rendering.
Computer graphics are pretty tough if you think about how many bits/s are being transferred to your 4k display at 60hz and how little latency we will tolerate. It's not like network data where we can afford to encapsulate it five times over and abstract it and forget about the contents.
Any criticism of Wayland should be with regard to what is next. Hell I'm not even convinced we need a display server, let's talk about that. I'm not going to take anyone seriously who says X11 is better, and because of a few insignificant issues like taking a damn screen cap (really? and that works fine now btw).
And by the way, that whole "never rewerite software from scratch"... that might be what they teach you in your startup accelerator or your CS classes, but in the real world, hardware changes fast, your clients change fast, and you will do well to start from scratch sometimes when fundamental assumptions change and you no longer want to support legacy hardware or legacy features that slow you down and everything can be drastically simplified with your new assumptions in hand.
Take for example, Mac OS 9 -> 10. Complete rewrite. One of the best decisions in computing history. And especially relevant here because the display server was one of the babies they threw out the window or whatever, and the quartz compositor was born.
Application sandboxing is not a need I have or one that I want my display manager to solve.
But incompatibility vs the architecture disallows features like screen sharing, automation or accessibility means I will not ever have it installed anywhere.
I can't tell people want to do, but those features seem very "contemporary" to me.
Perhaps it's because I use linux as my work desktop. I suppose if this is the feature I should just migrate to OSX.
Because I need video conferencing. I don't need a sandbox. I already am selective about what I install and most of those things aren't even desktop applications.
> I already am selective about what I install and most of those things aren't even desktop applications.
in X any application can turn into a keylogger, and you don't need a GUI for it, as long as the program can "speak X" it will be able to read the shared memory of all other programs the X server manages.
Not being able to participate in video conferencing and desktop sharing is an employment risk.
Im a picky person though. I already use i3, but also have NVidia gpu's. I don't mind spending some money on another real GPU (will it work with AMD).
I understand the frustration of the developers too. But screen sharing or my custom screenshot tool.. are things that will make me recompile if needed for days before I give up and abandon linux for the desktop.
I realize I'm spoiled, but I do wonder if this is the direction things are going who is going to be that hypothetical user that cares?
I agree that rewriting things needlessly is bad. However I actually think the folks working on this knew exactly what they were doing and actually made a reasonable choice; they’re not rewriting Xorg, they’re making something completely and utterly foreign to what Xorg is. And I think it is justified regardless of whether Wayland ultimately succeeds or fails.
It feels important to note that in the case of Wayland, it is indeed designed by the very seasoned folks that have worked with Xorg. If someone like keithp who have worked with X since before X11 has opinions on the design, it is likely well informed.
I think very few people involved underestimate the work involved to replace X, and that it is going to be many years before it is somehow done.
> It's the sort of thing that seems attractive to junior developers, but more seasoned folks know that the legacy system contains years of embedded knowledge and workarounds for "real world" issues.
Many seasoned Xorg developers work on Wayland. All the decades of lessons form Xorg _were_ carried over to Wayland.
No. That's exactly what I'm saying doesn't happen with a rewrite, ever. You think you take all of the knowledge with you, because after all, you wrote the thing so you know how it works. But it just doesn't work that way. There is too much complexity to carry around in your head.
I'm sure many lessons from Xorg were carried over to Wayland, but "all" is an insane exaggeration. And I'm sure many new mistakes were introduced. It's inevitable with any new system.
too hardline. progress is possible in this world. software is complex but starting with better sorted fundamentals counts for a bulk ass ton of the marbles.
There are a ton of long standing security issues. Which is why they are working on wayland: X11 isn't possible to secure as bad security is part of how it works.
My desktop is not a smartphone where I download random shady apps from an app store. I don't need any of the "security" wayland offers. If I don't trust some software I simply won't apt install it.
Many of the lessons are being carried over no doubt. Others are embodied in the heads of people not working on Wayland or in the codebase itself as emergent properties from interactions never consciously designed.
There will be some loss of lessons with almost no doubt.
This is not a rewrite. It's a new product that has overlapping functionality with X11.
Rewrites don't work when the following two statements are both true:
- the rewrite should achieve feature parity at a higher generaly quality
- the people who're doing the rewrite don't have most or all the knowledge that people working on the legacy system had (this could be written docs, automated tests, or just actual people hanging around)
There are also cases where the embedded knowledge and workarounds collected over years are a problem and can be solved in better ways by nuking the whole section. It's a 36 years old project after all. But it takes deep understanding of the Xorg system to tell which case it is... which I expect most people on HN do not have.
>It's the sort of thing that seems attractive to junior developers, but more seasoned folks know that the legacy system contains years of embedded knowledge and workarounds for "real world" issues.
The Wayland developers are the same people who have been building all these workarounds for xorg for decades. This isn't a new thing coming out of nowhere. When the old guard is telling you that their own work needs to be replaced, I'd listen.
>Perhaps we did need a new display server, perhaps Wayland is conceptually better than Xorg, but it'll be many years before it reaches feature parity, if it ever does.
Good thing nobody forces you to use it and it's just one click away on the login screen from switching to xorg. In the meantime people who want to hack on the project can do so and ship their changes to users to test them plus those who do suffer from xorg issues( because yes, xorg doesn't do well on a lot of things that aren't even that modern despite all the workarounds for the "real world" issues it has) can use wayland right away.
Everything you said is correct. But, there are surely cases where even though rewriting everything from scratch almost never works, the status quo doesn't work either.
I'm afraid that's where the Linux desktop is today. Linux as a platform actually sucks for running "untrusted" software. And "untrusted" doesn't just mean proprietary games. It also just means "can I please run the alpha version of this cool open source project without being afraid that it'll fuck up my whole home directory?"
Android does a hacky thing where each program is its own "user". But then, having multiple (human) users is confusing (I don't know how Android does this, actually).
I don't know if Wayland will succeed. In fact, I'm rather pessimistic about it. But I'm also pessimistic about desktop Linux "succeeding" (staying reasonably useful even to nerds) if Wayland doesn't.
Android does a thing where it has its own display stack and very strict sandboxing so X11 isn't really a thing :)
And for the sandboxing it uses SELinux which is available on desktop as well. It's just a royal PITA to configure. This is why many people don't bother with it. But in a highly restricted environment like a smartphone it's a lot easier.
I wouldn't call that a 'hacky' thing, it's just using it in a very different environment.
> And for the sandboxing it uses SELinux which is available on desktop as well
I used to think that, and then I started using Fedora. They have put a lot of effort into their SeLinux policies. I do all sorts of things with my workstation and very rarely have to care. In the last 6 months the only thing I have had to do is add ":z" to a bind mount running a podman container so that labelling happened correctly.
The Android thing was a bit of a tangent. I did know that it doesn't use X.
The point was intended to be that Linux is becoming more and more lacking as a personal computing platform, relative to the gains elsewhere in the space. The display server is one part of that- the entire user/group permission model is another part.
The part of Android that is "hacky" is using a separate user for every app. That's obviously not what the Linux/Unix guys had in mind for the user mechanism, thus it's a "hack". It's not necessarily a bad thing and it's totally hidden from the UX of your typical Android user, so it's fine. Just interesting.
The protocol is extensible. Nothing would have stopped an approach of having new clients signal they support new behaviour and aggressively deprecate old functionality to iterate the protocol.
The problem was not the protocol, but that the Wayland devs explicitly wanted to throw out a whole lot of functionality people actually depend on without having put thought into replacements.
> Perhaps we did need a new display server, perhaps Wayland is conceptually better than Xorg, but it'll be many years before it reaches feature parity, if it ever does.
I haven't followed the development at all but, Xorg is 16 years old and Wayland is 12. It seems counterintuitive that feature parity could not be attained in this time unless it's for philosophical reasons.
Edit: Thanks for pointing out that Xorg is actually much older. My argument indeed doesn't hold.
Ahh, 2004 is when Xorg forked off of XFree86, but XFree86 had already been going on since 1991, and already that was an implementation of X which already existed since 1984, and you can trace back even further than that if you want. It’s been a long ride home.
Xorg development largely halted circa 2008 though, since then most of the "Xorg" features have been deleting code in X and moving it to Mesa/libdrm/the kernel.
Wayland's latest release "mostly contains bug fixes and minor protocol updates." [0]. That is ~12 months worth of changes. Pretty similar to 1.18. It isn't like the protocol is a hotbed of massive changes, it looks largely complete according to the release notes.
> I haven't followed the development at all but, Xorg is 16 years old and Wayland is 12. It seems counterintuitive that feature parity could not be attained in this time unless it's for philosophical reasons.
X as a display server is over three decades old, the popular incarnation in the nineties being XFree86, which devs abandoned in 2004 to form Xorg due to licensing issues. Most of the code itself really is ancient.
Xorg is a fork of Xfree86 which started in 1991 but feature parity minus the cruft has been reached years ago. Some people disagree about what is cruft however.
For example, I view 90% of the list in the posted articles to be minor softwares relying on undesirable behaviour and unwilling to adapt (the remaining 10% being misrepresentation of actually solved issues listed in bad faith). The original author would obviously disagree.
Then again, I consider X.org to be and always have been completely unusable. How can people accept to use a display manager with constant screen tearing is beside me.
Screen sharing seems a critical feature to enough people to rise well above mere “minor feature” if the goal is to replace Xorg. That was probably true 12 months ago, but definitely true 8 months ago.
If the goal is to have a different display protocol that a significant fraction of the possible user base can’t reasonably use as their root display because it provides yet another way in which “Linux isn’t ready for this to be the year of the desktop”, that’s a perfectly reasonable aim, but it seems like Wayland is targeting replacing X, in which case supporting screen sharing (and recording) is probably not an ignorable “minor feature degradation”.
Can you write an application which uses screen capture on Wayland, and which works equally well regardless of compositor?
If not, then Wayland doesn't support screen capture. Individual compositors might, but asking developers to implement five separate screen capture protocols is a big ask.
You can. The standard is new, but it exists, and now works on Gnome, KDE and wlroots based compositors https://wiki.archlinux.org/index.php/PipeWire (read past the intro paragraph to where it talks about the various backends available)
> How can people accept to use a display manager with constant screen tearing is beside me.
I never even noticed it, and I never quite understood what people are on about with this. I had to go to YouTube to watch a demo video to see what it really looks like. And if I try it, then yes, I suppose I see some tearing if I move a window and pay close attention to it. But I never even noticed on my own, and am not bothered by it in the slightest.
Would it be better without it? Sure. But the amount of effort to eliminate what I experience as basically a non-issue is a poor trade-off IMO.
Same here on all points, including Youtube. I always envisioned some kind of critical graphics failure from the way people talk about it. Maybe my standards are too low.
Maybe it's overhyped, but tearing does make me feel like I'm using an amateur OS, especially when I'm using X for some weeks and then hop over to wayland or Mac or Windows, and the picture looks stable.
Tearing can be a gigantic issue when you have full screen videos or render games. However as far as I could find these are caused by the KDE/Gnome/etc. compositor not running in sync with the screen refresh rate. Find a way to bypass the compositor(KDE options to disable it, GNOME with full screen windows, or tell the X window to override the compositor) and it goes away. Its easy to lob all problems on X but whats next? Did it also cause 9/11?
I'm not familiar with the internals enough to know if you're right about tearing being the compositor's fault, though I'd be quite surprised if disabling the compositor resulted in less tearing. But I do know that I experienced tearing using compton with i3 (though much less than i3 with no compositor).
If Gnome, KDE and compton all manage to get compositing wrong on X, and yet every wayland compositor manages to get it right, then maybe it is a problem with X, even if there is some arcane way to fix the issue.
> though I'd be quite surprised if disabling the compositor resulted in less tearing
I have been running OpenGL based applications on KDE for some time and the answer to tearing was always disabling the compositor in the desktop settings or just overriding the compositor related redirect state of the window. OpenGL tends to sync against vblank anyway so I don't find it surprising that rendering directly to the final output buffer instead of an off screen buffer that is at the mercy of the compositor helps.
I never noticed it in that either. I played plenty of action games on my Linux machine twenty years, going back all the way to many hours I spent with the Loki port of Unreal Tournament, and I've watched plenty of videos in the last twenty years as well: but it just never registered for me. Maybe I'll notice it now that I know what to look for, but I'm the kind of person who is pretty happy with 1080p (or even 720p) too, so I suppose my brain is just not very good at picking up these kind of visual things, or something.
Yes, tearing is visible in fast-moving videos or games (when run in windowed mode), but video players or games usually run full-screen, where tearing does not happen (as applications can do vsynced doublebuffering), so usually it is not an issue.
I consider tearing a feature. Tearing is an unavoidable consequence of writing to the front buffer, and writing to the front buffer is required if you want the minimum latency possible. If you write to the front buffer, then so long as the part of the screen you're updating is below the raster position you'll see it that same display frame. If you write to the back buffer and then wait for vsync to swap buffers and avoid tearing then you won't see it until the next display frame. I value latency more than aesthetics, so I never use a compositor or Xorg's TearFree feature.
The goal of Wayland is "every frame perfect", which means I consider it broken by design. I want imperfect frames right away, not perfect frames later.
> How can people accept to use a display manager with constant screen tearing is beside me.
I'm not saying this isn't true, but I always find it interesting when I see people complain about screen tearing.
How often does it actually happen to you, and under which circumstances?
Personally I've been using computers since 1995, (Windows and Linux) and I practically never encounter screen tearing. And this is on a wide variety of hardware. Spread evenly over intel, nvidia, and AMD.
The rare times I did encounter it, was only on one PC with an ancient nvidia graphics card (running Arch linux, bspwm). And it would only ever (if even) happen right before a restart after updating the nvidia drivers.
>> I'm not saying this isn't true, but I always find it interesting when I see people complain about screen tearing.
>> How often does it actually happen to you, and under which circumstances?
It happens every time I Watch a video on X, which is really annoying. It also happens when dragging large windows on my 4k. Wayland is fantastic in this regard.
No, that does not solve the issue. Not using a compositor definitely makes tearing worse, on top of a number of other things, but even with a compositor, you'll get tearing on X, at least using intel graphics.
Screen tearing for me has been a thing of the past for years now - just switch on "Force Full Composition Pipeline" on your Nvidia card and hey presto, no more tearing.
> Reducing technical debt by rewriting everything from scratch (almost?) never works.
Agreed but this is one of those "almost" exceptions.
1. Is the code built to 40+ year old requirements, many of which are irrelevant today?
2. Is it hard to make it work for today's requirements without widespread fundamental changes?
3. Is the code a huge pile of foo that's damn near impossible to navigate, much less understand, much less debug?
4. Would a hypothetical program that solved today's requirements (with an architecture where the most important backwards compatibility features could be hooked in as needed) be smaller, simpler, and easier to maintain by newcomers?
If the answer to all of the above is "hell yes!", you might want to think about a wholesale rewrite.
Maybe we've worked on different projects, but sometimes the legacy is just that things were done differently in the past, and the APIs available were crap.
Let me tell you an anecdote: A big, old, crusty online retail company wants to bring their web shop up to par with the competitors. Due to many years of technical debt, feature development speed has come to a halt and it is determined that the web shop must be rewritten to remain competitive. Over a period of months, requirements are gathered from user focus groups and all the employees who maintained the content on the previous shop. Development starts and 3 years later, still not having implemented all the requested features, the project is deemed a failure. Another 3 years later, a new consulting company is brought in to attempt to realize the project. But this time, instead of trying to replace the old shop, a completely new shop is built iteratively and independently. Domain experts in the company complain: there is no way to review products, they can no longer put text wherever they want in the shop and users have to call the hotline to unsubscribe from newsletter because there is no settings menu. Still, the new shop is already outperforming the old one, despite having far less features. It turns out that many of those features weren't needed after all.
The lesson here is that writing a direct replacement system rarely succeeds because the new system will hardly be able to implement all the features in a reasonable time. Instead you should take a step back and develop a completely new system that follows actual user requirements and gets rid of all the dead code.
> Because software engineers working for companies will know the struggle of trying to justify reducing technical debt, improving security practices, etc. but fail to see why these things are useful to them personally when the tables turn.
Problem is, ever so often what should reduce technical debt ends up also reducing "technical assets" even more.
Firefox is a perfect example of this, they reduced technical debt by selling of so many features that it was sometimes hard to see a single unique selling point except not being owned by what I think is the worlds largest data miner (and quitter)!
For someone who used to use and advocate Firefox this hurts.
What is left is certainly better than Chrome on a number of points (except being bug compatible with Chrome) but the differences are now so small on every point except "not being owned by Google" that they are hardly visible to non tech folks.
Edits: a bunch above, mostly to soften and clarify. Also:
IMO the current management at Mozilla inherited a fortune of goodwill, a best in class web browser and significant tech debt.
They supposedly traded goodwill and features for reduction in tech debt but a few years later I suspect they squandered most of it on coolness because if there was less tech debt now, some of the old features should now be trivial to add back.
Firefox has treesyle tabs which has zero good alternatives on chrome. Tridacyl, vim like bindings for your browser + ability to bind javascript or native shell is more powerful than chrome alternatives. Chromium is losing google sync and chrome and chromium are Effectively destroying adblocking sooner or later courtesy of manifest v3.
Ublock origin and treestyle tabs alone make a compelling case and are visually and functionally distinctive.
Tridactyl is extremely quircky due to the limitations imposed to Web extensions though. I remember good old Vimperator to be more reliable.
I get why they did it though, allowing extensions to effectively take over the browser sounds like a recipe for disaster. Too bad there isn't a way to opt into it when it's actually what you want.
It actuall feels snappier than the latest Firefox, but a profile reset on my main Firefox might change that (traditionally with my usage patterns there's little improvement to be seen from that.)
So for now the advantages of Firefox vs Chrome are:
- not Google
- less RAM usage
- slightly better extensions
And for Palemoon vs Firefox:
Pro Palemoon:
- snappier (?)
- extensions work
- looks better (subjective) and can be skinned
Advantages Firefox:
- more secure (maybe, Palemoon unlike Mozilla doesn't have a history of abusing extension bundling for various promos)
I'm fairly aware that my browser is the main vulnerability, thank you, which is why I run different (mainstream) browsers for different sites already and actually want even more lock down for certain use cases than what IT currently privides.
I'll also add that in the last 20 years I've had one infection on a machine that I alone used (a drive by exploit in a banner ad on a developer blog I read) so a combination of carefulness/paranoia certainly helps ;-)
And no, I'm not suggesting anyone should uncritically download a random browser and start exploring the dark corners of the web.
Also: I agree, the robot thing was harmless, but that said: do you remember Superfish? The little thing that Lenovo added to their laptops? Which turned out to be a giant easily exploitable hole?
As for the robot extension:
- when I noticed it in between my own extensions it scared me quite badly until I managed to look it up
- companies that does such things aren't trustworthy. The robot thing was harmless. Superfish wasn't. Do you trust marketing executives to know the difference?
You can get rid of the top tab bar is your user css file other than that it seems kind of identical in functionally to me save for the keybinding gui for it being in a different screen under extension bindings if I recall correctly
For all the talk about UX, why cannot someone be bothered to sit down and talk to the actual people who use the product and ask what the ux problems are?
At this point is there anyone left using Firefox except stubborn power users like me?
The author obviously hasn’t tried plugging a high dpi monitor in to a laptop if they don’t understand what’s wrong with X. Wayland solves so many of my problems and so far the only thing it breaks is screen capture in electron apps. And not even all electron apps. Discord has no problems.
> The author obviously hasn’t tried plugging a high dpi monitor in to a laptop if they don’t understand what’s wrong with X
This is the only actual, honest, problem that I've ever seen about X. Still, it does not seem a really fundamental problem, it must surely be solvable from within X? Do we really need a full-rewrite of X, unstable, with new bugs and less functionalities? (many of us don't use "desktop" applications and it will break screen capture tools, and other things that are dear to us like xwit, xdotool and the like). Just for that silly mixed-resolution screen problem? I have observed this problem, but to me is a minor, mostly irrelevant nuisance. Losing xwit would be a major problem.
The problem has been crippling the Linux desktop for many years now and it still remains unsolved in X which must indicate that either it is not realistically possible or it is so much work that no one is willing to do it and likely never will.
The transition to Wayland is largely finished now. Electron added support last year and eventually the last of the electron apps will update and everything will be done other than nvidia proprietary driver support.
There are so many minor improvements from wayland that are less noticeable like the lack of screen tearing, the possibility of sandboxing apps.
Wayland has existed since more than 10 years and it has still not been able to release a usable system. I'm not willing to lose things that I use everyday just because some idiots want to move their windows between screens and see that they don't change their apparent size. Seriously, this is not a crippling problem. You can easily change the size of one program once it is on the desired screen. What kind of savage keeps moving their windows through different screens?
>Wayland has existed since more than 10 years and it has still not been able to release a usable system.
Fedora has has it on by default for about 4 years now and its perfectly usable. I use it every day.
The problem is much more serious than you are explaining. While using X, on my main monitor, UI and text becomes so small I can not even read it or click the icons. I'm not talking about the window size, but the UI and text size. With wayland the app can switch from 200% scale to 100% scale as it crosses the window border. On X you must pick either 100% or 200% and stick with it on all monitors.
You think that having to close an application in order to move it to a different screen is no big deal, but you think that wayland is lacking critical features? Features more critical than being able to move windows freely?
I really am curious what features you think wayland is lacking. I've been using wayland for years, both using Sway and Gnome, and the thing I've missed the most is xdotool, and perhaps there will be a standardization effort to replicate its functionality securely, but for now it's an understandable omission.
Maybe it's not fair to say that X is broken for mixed-DPI configurations, since I have managed to get it working with X, but it was quite unreliable, whereas on wayland it just works, save for some incompatible electron apps.
> Still, it does not seem a really fundamental problem, it must surely be solvable from within X?
X gives you two options: set DPI per displays. The thing is, you cannot drag windows between displays, the app has destroy it, connect to another one and recreate it here. There's even no mechanism to detect multiple displays other that user setting up the DISPLAY env variable.
Or you can do, as the Xorg does: use multiple screens on a single display. Here, the limitation is, that all screens have to have same DPI.
Neither of those are acceptable for modern display server.
> it will break screen capture tools,
It is a good thing that they are broken, because what they do is snooping on windows that do not belong to them. Just like it is unacceptable to integrate user address book to your app by going through its internal files, it is unacceptable to screen grab by snooping windows of other apps. In both scenarios, your app must go through API, which puts the user in the control, whether the app is allowed to do that. Wayland enforces such protocol for screen grabbing and input handling; those app who do not bother... well, the train will leave the station without them.
> other things that are dear to us like xwit, xdotool and the like
Same as previous, but for input handling.
> Just for that silly mixed-resolution screen problem?
No, there are multiple problems. For another, surely you would like screen lock that doesn't flash your desktop on unlock?
> I have observed this problem, but to me is a minor, mostly irrelevant nuisance. Losing xwit would be a major problem.
See even here on HN, it is important for many. Just few days ago there was a discussion under article about i3 and how to drag it into hidpi world in 2021. On the other hand, the mainstream user doesn't even know why they would use xwit, even if they knew it exists.
> [Xorg] limitation is, that all screens have to have same DPI.
The limitation is not true. Yes, the core protocol gives you a single, global DPI value. However, who cares about the core protocol? You have XRandR, which gives you a per-screen DPI. Alternative, you could have a freedesktop standard/convention where the DPI is stored as a global property of the root window, in a array of values, one for each display, so that you can override them.
Problem solved! I am actually running Gtk+ slightly patched to support that... trouble is, most of the toolkit is hardcoded to assume a fixed display or even process-wide global DPI, or at least it was when I last looked at it. Dunno what they did for wayland.
I really don't understand why we need to throw away an entire 30 years of software development just because the current property for storing the DPI only has space for 1 value instead of 1 array of values, one per monitor. Just use a new property.
Are you going to patch it to decade old binaries? How are you going to handle that Wordperfect from 1998? It certainly won't respect you new protocol.
How the compositors are supposed to handle that?
If you are not going to handle it, and just let it behave as it behaves today, you are still not achieving your goal of scaling all clients properly, and kind of throwing away that 30 years of development by making it unusable anyway.
How are you going to change those decade old binaries to work with Wayland??? At least if you don't throw X11, those decade old binaries still work. If you throw X11, they will not!
You need to put in some type of kludge which is the reason this article exists in the first place (e.g. copy paste will work randomly).
And if the toolkit is linked dynamically, you are very lucky... Not to mention that a more realistic scenario is that you have to update a 20 year old toolkit to support multiple DPIs, in which case it is much easier if you just have to read the property from a different place rather than having to target a different display protocol entirely. You made the program vendors life easier at the cost of making yours harder...
Xwayland is the kludge I was talking about (and this article).
No reason your "classic" X11 compositor cannot scale and make any windows blurry, either. No changes required to the client code at all, but some are required to X11 itself, e.g. https://www.youtube.com/watch?v=BrK4c7iFJLs
X11 is the kludge. Xwayland is the symptom. If anything, Xwayland is too nice and too seamless; it should get Xquartz treatment.
The point of blurry scaled windows is, that X11 compositors cannot tell which clients are DPI aware and which are not. If you run Chrome, it can render itself properly for HiDPI; if you run Gimp (the Gtk2 one), it won't, it needs to be scaled, Meanwhile, the compositor is none the wiser, which is which, which needs to be scaled and which doesn't. So Xwayland lies to them all about real dpi, and upscales everything.
For Wayland native clients, there is a property that the compositor can take into the account. Theoretically you could make X11 windows property for the same effect, and define new events for display/scale changes, but good luck persuading anyone to use it in the next 10 years ("it works in the current Ubuntu LTS, we are fine, no need to add anything").
> The point of blurry scaled windows is, that X11 compositors cannot tell which clients are DPI aware and which are not. I
Just make a new property, and make those DPI-aware clients set it!
You could even make a small utility program that sets it on _other clients_, e.g. "windows created by these binaries get the DPI-aware property set automatically because I know it". This would be trivial to write in X11, but becomes again Mission Impossible in Wayland (you have to edit every display server -- Gnome's, KDE's, etc. -- in existence).
> For Wayland native clients, there is a property that the compositor can take into the account. Theoretically you could make X11 windows property for the same effect, and define new events for display/scale changes, but good luck persuading anyone to use it in the next 10 years
Yes, exactly. But it is going to be much harder to make anyone support Wayland within the next 10 years, since it brings its own share of problems and because of "the devil you know". E.g. can Firefox already screen grab from Wayland these days? From non-Gnome Wayland? Will Zoom ever do it? And work with any Wayland display server other than Gnome's? It is a mess, and has been so for a decade already. And that is why we get this article.
That's the difficult part. You are welcome to try, though!
> You could even make a small utility program that sets it on _other clients_, e.g. "windows created by these binaries get the DPI-aware property set automatically because I know it".
Yes, another hack to keep on piles on other hack. Why would anyone want nice, clean solution, when a hack does?
> E.g. can Firefox already screen grab from Wayland these days?
Firefox can do screen recording/screen sharing under Wayland these days. Hardware encoding for WebRTC is in the works; that's something they would not be able to efficiently do under X11 at all.
> Will Zoom ever do it?
That's the question for Zoom. If we kick them as Apple does, they will. If we lay down and keep piling hacks on top of other hacks, they won't see the point.
> And work with any Wayland display server other than Gnome's?
That's a question you have to ask the authors of any Wayland display server other than Gnome's.
> It is a mess, and has been so for a decade already. And that is why we get this article.
It is a mess, because some people are too hung up on their current ball of mud and cannot see further than their personal desktop. Then they write articles like this and try to drag down others to the level of their ball of mud.
> That's the difficult part. You are welcome to try, though!
I am quite confused by the fact that apparently changing toolkits to set a new property (a one liner) is hard, and creating a program to do this change for these toolkits externally without changing them at all is a "hack" (despite the fact users likely want to do this, as evidenced by Windows offering this setting); but on the other hand throwing everything away and changing everything to support an entirely new display server protocol with its on set of problems is ... a nice, clean solution?
What I see is another manifestation of the "backward compatibility is a hack" mentality. Well, this annoys me to no end, but what can I do.
> I am quite confused by the fact that apparently changing toolkits to set a new property (a one liner) is hard, and creating a program to do this change for these toolkits externally without changing them at all is a "hack"
Most issues could probably solved by a variety of hacks. Several issues that don't concern yourself couldn't. The problem is that X consists of 40 years of hacks piled up on each other. THe X.org devs actively chose to stop further development and continue their work on wayland.
You are on the same side as the people bemoaning IPv6 and asking why we couldn't just use one of the unused flags in IPv4 to solve the address depletion issue. It sometimes makes sense to make incompatible changes.
> I am quite confused by the fact that apparently changing toolkits to set a new property (a one liner) is hard, but changing them to support an entirely new display server protocol with its on set of problems is ... nice, clean solution?
Because if it was just setting a new property in a toolkit, we would not have this discussion now.
Ultimately, it is not just that; if it were, all clients would be Wayland native already as the toolkits have had Wayland backends for years.
It is just setting a new property. The discussion here I thought was what is required to distinguish a client that is DPIaware versus one that it is not, for use by the compositor to decide whether to scale it transparently or not.
It's not just setting a new property. Meanwhile, today, you have clients that are dpi aware and are not setting the property. And they all will be out in the wild for an undetermined amount of time (because stuff works for the application developers, why bother?). If you do not handle them anyway, your users will complain that your desktop is broken.
It is just setting a new property. I am not sure we're on the same page here, but if your existing client is DPI-aware, and you just want to let the compositor know it, then it is a one-line change in your client.
As for the "Meanwhile" part, again, how is that better with a new display stack? Unless the point here is that it will be better to just break all those (DPI-aware) clients unconditionally, rather than actually offering them a way forward that does not involve targeting an entirely new display server API.
Because that "meanwhile" takes years. There are still clients that use libX11 ("it works for them") instead of libxcb. libxcb was introduced in 2003.
So "meanwhile" you would have apps that are not DPI aware without flag, DPI aware without flag and DPI aware with flag. And even crappier desktop as you have now for years to come.
The new API is not just for DPI; it is for many reasons, DPI is only one of the issues.
I specifically qualified it with efficiently. As in, when the surface is in the GPU memory, the software doesn't have to read it over PCIe bus and then put it back into another buffer for the encoder; but that the encoder can do zero-copy encoding in the GPU memory.
Here, Firefox uses dma-buf. Unless X11 exposes a special extension for exposing dma-buf, your client won't be able to do that.
You said it yourself. I even believe that extension already exists since it must be going on inside DRI3 for some EGL/VK extensions to work right now. Don't think it worth to create an entirely new display server API for just this.
dma-buf is linux-specific, not Gnome specific. It is buffer management on GPUs; it is the low-level API that Mesa and libva, and yes, DRI too, build on top.
Just because some specific application works better (for some values of better) on the Xshm does not say anything. In year or two, the situation can be very different, permanently.
> Are you going to patch it to decade old binaries? How are you going to handle that Wordperfect from 1998?
The same way Apple handles a PowerPC-compiled application from 1998.
By incrementing to a new major version number, and stating in
the changelog that users are free to keep running the older
version if their software won't be patched.
Does Wayland provide a better solution than that? No, and in
addition it also breaks a lot of newer applications. We don't
need to do a lot of math to figure out more people would miss
Xorg than Wordperfect.
> The same way Apple handles a PowerPC-compiled application from 1998.
It doesn't handle them at all. There was a transition mechanism, to get users updated, but it wasn't maintained long term. You could not run PowerPC binaries from 1998 in 2005.
Apple expected their users to update the binaries for new architecture in the long term. In many cases, not only ISA and ABI changed, APIs too; good luck if your application used Quickdraw.
(Yes, I still do have coasters in the basement).
So compared to that, Wayland's Xwayland is too nice and too longterm.
> It is a good thing that they are broken, because what they do is snooping on windows that do not belong to them.
Don't want to derail this discussion anymore, but this argument is nuts. If you are so concerned that programs that you run can spy on other programs that you run, how do you deal that the fact that all of these running programs have full read-write access to all files on your $HOME?
EDIT: I agree that being able to run selected programs inside a sandbox would be a good thing (maybe even all programs). But attacking the problem of visible display before that of hidden files seems ridiculous. Moreso if it cripples copy paste, screen capture, and similar basic stuff (which to me are just like unix pipes: ways to make programs work together!)
> t all of these running programs have full read-write access to all files on your $HOME?
They don't necesarilly do; if you are running flatpak, chances are that they don't.
For example, there is a flatpak for MS Teams. For application like this, you want it to be able to share your screen, but it doesn't have any access to your $HOME (in this specific case, only to ~/Downloads).
More importantly, if you want to tight up your desktop, why do you criticize something that starts attacking it from one angle, that it is not 100% solution? It is not; others are working on the other angles, and then together it will be the 100% solution. In this case, Wayland is only one piece of puzzle, not the entire puzzle.
I've never used xwit before, but just looking at the description, I believe at least under sway the same should be achievable using sway's ipc protocol (I wouldn't be surprised if other compositors have similar options).
I think the difference to xwit is that it does not work across windowmanagers/compositors, because much of what X11 used to do is now the job of the compositor, but I assume the users who script xwit likely also have a very tuned windowmanager, so it's unlike they switch window managers all the time and they could therefore just tune their environment for the same functionality as xwit.
I believe if you want linux to be competitive as desktop OS you need to cater for the average user. I would wager that need for multidisplay support is much more common than need for xwit, no?
The laptop part is important. Your laptop likely has a 1080p screen which needs to be at 100% scale while 4K monitors usually need to be at 200% scale. X does not allow this.
X does allow this, but it needs cooperation from clients, which in practice means that Gtk and Qt need to implement it, and they decided to only implement this for Wayland (which also needs clients to implement this!) because for them, X is dead and not worth supporting. It's not a problem of X per se. It's a deliberate decision to not implement a feature for X.
Save the obvious distance, I kind of see a bit of similarity with the Python 2 to 3 transition; it breaks downstream programs and processes that shouldn't break.
Another similarity I see is that Xorg is like the Linux Kernel of GUI applications. Ideally, you just shouldn't break "userspace".
I agree that some stuff is definitely broken in Xorg, like High DPI setups. But I also believe that's no reason to break a myriad other setups that are working well, right now.
This constant "1 step forward, 2 steps back" (from the point of view of the final consumers, who really only care about the result, and not the means) is so common in the ecosystem of GNU/Linux based O.S. It's also why I see the mantra of the Linux kernel so utterly fascinating and inspiring. It takes real work to build something and keep it working for decades with a minimum of breakage; starting from scratch looks then like child's play in comparison.
I guess the problem is the same as always: money. In a parallel universe where Xorg is at the base of Windows, Microsoft would just throw millions at it to improve the architecture and fix issues, while at the same time trying to limit breaking changes as much as possible... but that requires willingness to do it, and deep pockets.
(It is very similar to systemd, and the motto on page https://nosystemd.org/ that is what I think about systemd also: If this is the solution, I want my problem back.)
If one doesn't use multi-GPU setups or high DPI they don't need Wayland, yet (later they will either have no options (like with systemd) or will buy better screens).
For me e.g. I don't know if I have a problem that Wayland may solve - I have not issues with Xorg, I don't like using more than one screen (I forces me to move my head left-right, I prefer single large screen, with full sized window) and I don't have high-dpi screen (I think, at what DPI does it start? My laptop has full-hd with 14", so probably not).
But later when such high-dpi screens will be the norm it would be nice to use them.
I feel the same. Xorg just works. My dev machine has intel onboard gfx with two screens attached and an old gefore 8 (I think) to drive a third screen, using nouveau. Zero config required, X just combines them as if it were one card with three outputs. Wayland? No chance. Screen sharing in Jitsi in Firefox? X doing just fine, Wayland not a chance (using Sway). So X just works fine out of the box no matter what, while Wayland is a broken mess that reminds you of X 15 years ago. Oh but Wayland solves screen tearing, which I guess would boost my productivity while coding by 500% so maybe it's worth the hassle.
This only works for people who don't care about precise font rendering, either because they just don't care, or because their visual acuity is bad and they simply don't see the difference. (People who arguably don't really need HiDPI displays in the first place.)
Notice that you can use hidpi screens with Xorg and it works perfectly. The only problem occurs when you mix screens with very different pixel sizes on the same display and you want to move windows between these screens.
As a complete outsider - ok, I'm a developer, but I haven't had the pleasure (?) of writing something that interfaces directly with Xorg yet - I have been reading for years about Wayland being the way forward and how Xorg is dragged down by a long history of dubious design decisions and features nobody needs anymore, and I was secretly wondering: if this is really the future of desktop Linux, why doesn't it gain more momentum?
This post is a bit too ranty for its own good, but it has a valid point, and one that is unfortunately common in the open source community: because you have no monetary obligation to your "customers" (=users), there's not really a lot that forces you to maintain backwards compatibility. And because a Linux distro is made up of thousands of applications, many of them not in active development anymore, changing such a fundamental component (without providing a "compatibility layer", which I have no idea if it would be even possible) will break a lot of applications that may never be "fixed".
It has plenty of momentum. The two main desktop environments have wayland ports. Several distros ship wayland by default.
without providing a compatibility layer
Wayland does provide a compatibility layer, XWayland, which runs an X server that does all the internal processing that Xorg does, and then send the final frame to wayland to put on the screen. It works very well, just with some quirks around mixed-DPI setups, which X can't handle well to begin with.
When people complain about wayland breaking their set-ups, they're talking about tools like xdotool, which Wayland deliberately does not allow because they're security risks. Old applications, the kind that put a window on the screen, rather than manipulating other applications' windows, work just fine.
Though I would say that standardization of screen capture is far more important than standardization of automation, since screen capture software needs to work for all compositors, but my automation scripts only need to work on the compositor I actually use.
Screen capture is a recently solved problem on wayland. Yes, existing screen capture software that doesn't implement a new backend is broken, because the X model of screen capture was fundamentally broken, and one of main goals of Wayland to fix. But Firefox and OBS can do screen capture on wayland just fine, regardless of compositor.
The gnome global menu thing is a problem with gnome's implementation of wayland. The functionality could surely work if Gnome decided to support the same standard as wlroots does for allowing custom panels like waybar. Perhaps the complaint is that wayland give the gnome despots too much power, but if you don't like gnome, then complain about gnome, not wayland.
I don't know enough about KDE or AppImage to comment on those complaints.
>if this is really the future of desktop Linux, why doesn't it gain more momentum?
Nvidia is the major blocker here and there is very little wayland devs can do to fix this. Fedora has actively discouraged using the proprietary nvidia driver for a while now and they ship wayland by default since the open source driver works fine. I saw that ubuntu is also shipping wayland by default soon for amd and intel users.
> Nvidia is the major blocker here and there is very little wayland devs can do to fix this
I know, but it can be difficult to understand. I mean, how come we currently have Nvidia drivers for Linux, which work pretty well, and they can't be used for Wayland?
Because the entire linux graphics community uses the same API (GBM) and wayland is mostly built around that, but Nvidia insists on not using it for some reason.
Yes, but why is it not a problem for X.org? Can't Wayland be made to work using whatever Nvidia is currently providing? I guess I read it is, and even something (KDE maybe?) made it possible to run Wayland under proprietary Nvidia, so I don't really understand what's the problem.
Its extremely slow and does not support CUDA. I think the problem is nvidia blocks them somehow from changing the clock speed on the gpu so it gets stuck running in its slowest speed.
> This post is a bit too ranty for its own good, but it has a valid point, and one that is unfortunately common in the open source community: because you have no monetary obligation to your "customers" (=users), there's not really a lot that forces you to maintain backwards compatibility.
And yet, distros like Ubuntu are too conservative, because they are too careful not to break something. Their signalling is then considered as it works, we don't have to fix anything, Ubuntu will keep things broken for us. Due to this attitude, they have slowed down Linux desktop by years, by not switching to Wayland by default in the past LTS release.
Compare with Apple: in the same timeframe they've deprecated and removed support for entire architecture (i386) while Ubuntu just thinks about doing one step. Apple breaks compatibility at much faster rate than Linux world, and everyone is fine with it. The difference is in signaling: Apple decides and does. In Linux world, we have articles like these, that try to slow down everyone.
I don't know if everyone is fine with Apple making so many changes. I think it's because they have no choice, being stuck with whatever Apple decides.
eg. for years you couldn't resize a window from the left edge and everybody was "fine" with it. When they actually bothered to implement it, it was astounding to think you couldn't do it before!
As for me, I await each Apple release with trepidation and fear.
Will my audio hardware continue to work? (They break the utilities most releases).
Will I need to buy a new version of Parallels or VMWare because Apple changed the virtualisation API? (This happened a few years ago).
Will my apps no longer work? (Goodbye useful 32 bit apps that I can't find a 64 bit version of).
Will they just break random things? eg. PDF viewing, Quickview of multiple files (both of these happened to me).
Will they change random things for the sake of it? eg. Giant spacing between icons on the menubar on Big Sur. Behaviour of the maximise button into "full screen" button just because they could (a few releases ago).
Will my machine be slower for no apparent reason? HFS+ to APFS makes my machine start up TWICE AS SLOW.
The best bits are due to the Objective-C message passing, old apps will make a "call" to a function that no longer exists and it won't break - it'll just do nothing. You literally have no idea if your app will continue to work between releases, even if it runs and the certificate for the app hasn't expired...
And I say this as a daily user of macos! It just isn't reliable between releases.
My point is exactly as yours; it was addressing comments as the GP one, where the FOSS community is being shown as the one constantly breaking compatibility, while commercial vendors are being shown as example worth to follow. My example intended to show exact opposite -- I'm also Mac user (Windows user and Linux user too), and while I understand the rationale for some steps (i.e. deprecating i386 was in order to not overly complicate Rosetta2), it doesn't mean it won't hurt the users anyway.
I abandoned Mac OSX for Win 10 (manager half of brain) and Linux (dev half of brain) years ago.
It got really tiresome rebuilding my dev environments in particular with every new release. Butterfly keyboard, touch bar, and other hardware choices were additional hindrances. Infuriating design choices like doing away with 'Save As' were the last straw. I don't really care about UI improvements, to be honest. OSX Leopard was usable for everything I do in normal life.
I forgot the "Save As" removal! I type this on a Macbook with an irritating noisy butterfly keyboard where the left shift key works 40% of the time and I get duplicate "i" inputs periodically, with a touchbar that has a fault so the F12 region is constantly flashing in my face...
>And yet, distros like Ubuntu are too conservative, because they are too careful not to break something. Their signalling is then considered as it works, we don't have to fix anything, Ubuntu will keep things broken for us. Due to this attitude, they have slowed down Linux desktop by years, by not switching to Wayland by default in the past LTS release.
How can you complain about Ubuntu LTS keeping Xorg as default in an LTS when RedHat itself had Xorg as default at that time. Isn't this hypocrisy or irony? (same thing of idiots complaining about upstart being shit while RedHat and Goole were still using and supporting it.
IMO let RH use Wayland as default for a few years , then hopefully they can't ignore user bugs and fix them.
> How can you complain about Ubuntu LTS keeping Xorg as default in an LTS when RedHat itself had Xorg as default at that time. Isn't this hypocrisy or irony?
RHEL8 uses Wayland as default. RHEL8 was released in May 2019. Ubuntu LTS was released in April 2020. What hypocrisy you are talking about?
> (same thing of idiots complaining about upstart being shit while RedHat and Goole were still using and supporting it.
Redhat uses systemd since RHEL7; Upstart was used in RHEL6.
Story time: Redhat management didn't see the point of systemd originally; Poettering did it in his spare time, and Redhat management has seen the point only after Fedora and Arch adopted it. Meanwhile, RHEL6 was already deep into its release cycle.
So did you check the show stopper bugs that Ubuntu found? or they should ignore the bugs to please RH and it's fanbase ?
Maybe the next LTS could profit by the fact that RH recently was forced to fix the bugs in Wayland (though not sure how many paying customers started using it yet and submit tickets for the devs to fix)
Show stopper for Ubuntu was screen capture. So screen capture works today, and if they switched, if would be difficult only for the first few weeks, when Ubuntu is buggy anyway.
But they didn't and the long-term consequences of delaying it will be felt across all linux distributions for years to come. So much for appeasing RH and it's fanbase.
I disagree, this happened before with pulseaudio,
it was not ready and for years people would recommend to remove it, so the leason is not replace something that works now with something that is shiny but might work next year.
I also think NVIDIA had a role in this default display issue, Ubuntu has to use something that actually works on all hardware combinations,competent users can install and try a Wayland implementation or all of them.
There are still people who uninstall pulseaudio, because "bloat" and then harass authors of audio applications to support their snowflake system.
The forced PA brought some pain. but it forced swift improvement in audio drivers. Without it, we would still have half-buggy drivers that do not really work.
Regarding Nvidia: all distributions that switched to Wayland default switched that only for supported hardware, so Nvidia users are still getting X11. I don't expect Ubuntu doing it differently.
I still think is terrible for the users but probably great for some developers. So you would force the casual user that has no issue with X to suffer so the Wayland and GNOME/KDE developers would hear better the pain and fix the bugs and add the missing features. This is the job of bleeding edge distros to offer you the latest bugs and features.
I understand that when you work on your free time you want to work on shiny stuff that maybe you created and not on someone else old code, but for good results we see all the time that serious money need to be spend and developers need to be made to work on users feedback and not on what they like. Red Hat is pushing this, they have the money so they need to find more competent developers and do it right.
There is no split "terrible for users, great for some developers". Casual users do have issue with X; see this thread recently on HN: https://news.ycombinator.com/item?id=25970690. Would you consider that normal for users to handle?
Of course not. Casual users having no issue with X is a lie.
The fact is, that some subsytems on Linux are pile of hacks piled upon something built on assumptions that are no longer true. X11 is one of such subsystems. It is a dead end. When you are stuck in the dead end, you can either back up and once you are out, continue in your ride, or keep being stuck in the dead end.
Wayland is backing out of the dead end; yes, it is short-term, high intensity pain, when you are not going forward, and even have to go back for a while. Piling new hacks on top of X11 is trying how to continue going forward without backing out of that dead-end. You will be stuck in that place for a long time, and ultimately you will move nowhere. That is long-term, low-intensity pain. Some people do not take the long term view (or do want to avoid high-intensity pain), being stuck in a place works for them (and chronic low-intensity pain is fine to them).
I agree that Xorg has issues, I disagree that Wayland was the best solution. Creating a protocol that specifies a subset of the features and then taking mroe then 10 years to get decent implementations for the subsets and then still having no unique answer on how to do global keyboard shortcuts and that pathetic delay until we got some kind of screenshot and screen recording solution...
If RH were actually competent would have had a roadmap and Xorg would be replaced with some Wayland implementation only when all X featues are ready. Until then RH can label it as Beta.
I don't like how you propose this unfinished stuff is pushed on users so maybe someone would get frustrated enough and make RH job, like WTF RH has tons of money, they could fins competent people to implement the missing stuff 10 years ago, and while at it they could have fucking fixed GTK or maybe buy Qt and the dev team .
> Apple breaks compatibility at much faster rate than Linux world, and everyone is fine with it.
That's news to me. I have yet to read or hear the sentence
"removal of magsafe was a great idea", or "I love carrying
around this bag of $50 USB-C adapters". Or "this touchbar sure
is a gamechanger, who needs the F-row on a Pro device anyway".
> Apple decides and does.
And Linux decides not to break everything just because they got
a new favorite technology. I am not sure why you complain so
much about Ubuntu when you can just use another distro that does
things differently. Because unlike with Apple, you actually can
choose, and without buying new hardware.
Which is also the reason I'm not that invested in the whole Xorg
vs. Wayland debate; I am certain one distro or another will
still support Xorg for a long time, and who knows, maybe one day
Wayland is actually mature enough for me to use out of the box.
> That's news to me. I have yet to read or hear the sentence "removal of magsafe was a great idea", or "I love carrying around this bag of $50 USB-C adapters". Or "this touchbar sure is a gamechanger, who needs the F-row on a Pro device anyway".
I'm not talking about hardware. I'm talking about software. How they changed the network filtering several times in last 5 years. How they deprecated and removed i386 support during the same timeframe that Ubuntu only considers switching to Wayland. Heck, my ~2015 Samsung MFP in office doesn't scan with MacOS anymore, apparently the latest driver from September 2020 is too old now. And bazillion other examples, see them in sibling thread.
> I am not sure why you complain so much about Ubuntu when you can just use another distro that does things differently.
I do use another distro that does things differently. To problem with Ubuntu is, that application developers do target Ubuntu, not those another distros. So when Ubuntu doesn't need Wayland (or Pipewire, or whatever), they won't allocate manpower for Wayland (or Pipewire, or whatever) support.
Then we get stuff like "Wayland is still broken after 10 years".
> I'am certain one distro or another will still support Xorg for a long time,
That's certainly fine
> and who knows, maybe one day Wayland is actually mature enough for me to use out of the box.
In order to mature, it has to be used by critically-sized amount of users. If you just push it aside, it will stay aside. It is not just Wayland's problem, for another example see ARM support under Windows.
I don’t agree that what we need is better Xorg. Xorg was a client-server based display server design from back when bitmapped displays and their respective UIs were in their infancy. And although it was certainly good for a time, I really think the idea of client-server UI has aged about as well as Polio. Even at the time it was computationally expensive (especially compared to say, Windows basically just jamming the UI into the kernel) but now it’s just crufty, inefficient, and weird. I don’t think there are many design decisions from X11 that you really want to keep anymore. Seriously, dig into the X11 protocol, what would you want to keep? If you want it to be feature compatible, a lot of cruft is going to need to come along for the ride.
There are some aspects of X11 that aren’t so bad, especially more recent bits. Personally, I think XI2 is relatively nicely designed. But on the whole, I just don’t think what we want is better Xorg.
People are flaming and screaming about their beliefs, demonizing systemd, Wayland and what-not with FUD, baseless arguments and non-arguments, because they "believe" these things are bad and must die.
If I want to talk about what runs on my workstation as if it was religion, I install Temple OS.
If I want a modern (and basically following sane/safe architecture decisions) display protocol, I run Wayland.
The linked post is just one thing: superfluous. It helps no-one, a waste of energy and time for everyone involved.
systemd adds a concrete and substantial set of features for me. I eagerly embraced systemd for that reason - there are things I don't like about it, but it gave me lots of new benefits that justified the effort.
Moving to Wayland would force a bunch of changes on me for the sake of no functionality I care about.
That's the big difference. Given it provides no benefits to me that I care about, I won't move until staying on Xorg is more effort than replicating my current setup on Wayland, and as it stands it seems that's likely still years away.
But that's the thing though. For _you_ systemd had a concrete and substantial set of features, while wayland doesn't for many others it was the other way around. (I don't mind either, but there are annoyances in both).
The problem is that many are complaining that _their_ specific set of functionalities is no longer being catered for, or better not being actively developed. The great thing about linux is that you can do what you are doing and continue running Xorg as long as you want, it might be more work however.
Regarding your wayland would force a bunch of changes on you for no functionality, what are those specifically?
I would encourage you to try out wayland, for me moving from i3 to sway has largely been a seamless experience and I (tell myself that) see notable performance improvements for example.
The point is not that nobody sees benefits in Wayland, but that the case for switching is a lot more ambiguous. There's a substantial proportion of people for whom it is a loss of functionality or effort for no benefits. With systemd there was no loss of functionality - it is compatible enough that if you don't make use of the new functionality you don't lose anything. With Wayland, if you depend on any number of different functionality aspects, you either lose functionality or have to pick specific compositors that implement additional protocols.
With respect to my time investment, it's down to having to switch window manager. I'm using bspwm, and rely extensively on the API it provides. I could probably transition that to sway if I had to. But I have no incentive to. It gives me no new functionality and solves no problems I'm having.
So I'll stay on Xorg until an incentive appears to justify the fairly significant time cost of reworking my workflows and/or a bspwm compatible compositor arrives (there's been an issue open for 5 years, and at least one - abandoned - attempt).
The time investment required to switch also means I'd be prepared to invest quite a lot in getting Xorg running if the situation is the same down the line at a point where I can't get an "off the shelf" dpkg of Xorg.
At the pace Wayland efforts are moving, I suspect I'll still be on Xorg in 5 years, and wouldn't be surprised if I still was on it in 10.
But really, the main point of my earlier comment was that there are real, concrete reasons for people not to move to Wayland that has nothing to do with belief. It would take time I don't have to make the move, and it doesn't provide me any benefits to justify putting aside other things to invest that time. Maybe one day it will, but it won't be any time soon.
I haven't seen many desktop apps emerging in the last decade, so whom is that "legacy is holding back the Linux desktop" argument addressed at? X may not be the most modern architecture, but it's still the API almost all F/OSS desktop apps are ultimately written and tested against. For many apps, wayland doesn't bring a new perspective, but end of life with no new apps taking their place. For other apps, wayland means additional testing and porting effort. And wayland, like gnome and almost every other "innovation" by RedHat, brings fragmentation into the free desktop world also for BSD and Mac OS ports. Desktop app development, being starved off developers anyway, doesn't need a "Python 2" moment, that is, a decade+ long phase of transition in the name of dubious progress, or other impediments getting thrown in its way. The end result is simply that less usable software will exist.
It would be funny that at the point where it seems that Linux desktop hardware support is at its peak, the actual use of Linux desktop would be at its lowest. I don't think that's the case, though.
GNU/Linux gets used alright, on IoT, servers and VMs, where the desktop is irrelevant.
While Linux community can pat themselves on the back for having Linux kernel as part of ChromeOS and Android, they tend to forget it is hardly exposed to userspace frameworks used by app developers.
Crostini only works in some models, and follows the same approach as WSL, running GNU/Linux in a virtualized Linux kernel, completely unrelated to ChromeOS Linux kernel.
ChromeOS vNext could be based on Fuchsia and still offer Crostini.
This would be more believable if there was a surplus of new Windows/Chrome OS desktop apps. Even macOS which is doing a little healthier basically gets a couple of indie commercial apps that people care about them.
The rest of the new desktop apps are electron which doesn't care about X vs Wayland
You are overestimating the difficulties of porting old stuff to wayland. XWayland doesn't have a prespecified EOL, it's just going to sit there indefinitely to support all the legacy apps. This means that there is no need to hurry with migration.
And the issues in X that wayland aims to fix are much bigger than the issues that python2 had when it got replaced.
“You are overestimating the difficulties of porting old stuff to wayland”
The same is true for moving away from win32 GUI API. How many times has Microsoft tried?
I have experimented with wayland and considered submitting patches for various 30-bit color issues, but the community is so catty. Everything is met with snark. It reminds me so much of trying to help a damaged person who doesn’t trust me, which is so weird and off-putting, in this context.
> The same is true for moving away from win32 GUI API. How many times has Microsoft tried?
I'm not very familiar with this example, but experience from proprietary systems rarely applies to FOSS because the way free software is developed is so different. Furthermore, Qt and GTK apps work out of the box with both wayland and X. The same applies to many other toolkits and libraries.
> I have experimented with wayland and considered submitting patches for various 30-bit color issues, but the community is so catty. Everything is met with snark.
What part of the ecosystem did you attempt to contribute to? I got a couple of patches merged into Sway and some of its utilities and the community always felt rather welcoming.
I have to agree about client side decorations. But my biggest issue (I use gnome) is that it is now the compositors job to remember window sizes and positions, and they are not doing that. I understand and agree with the reasoning that an app can't influence its environment and position itself. But someone has to do it. And automatic placement is not a substitute for remembering the users placement.
Indeed, it's funny they would think it was meant to solve issues they had. The justification for it was never X11 doesn't work. It was always "it's becoming impossible to work on".
As it happens, Wayland does solve a problem I have. The HDMI port doesn't work under X11 on my Lenovo X1 2nd gen laptop. It does under Wayland. Granted, that's because no one wants to work on X11 any more, so new or unusual stuff doesn't get added. (The X1 gen2 is indeed unusual: the HDMI port comes off the Nvidia card rather than the intergrated graphics. The X1 gen3 fixes that nit.)
Which brings us the full circle: Wayland may fix no issues he has now, but the X11 code base being so much of a pig will mean he has issues with it in the future.
I've now moved to Wayland, and it was under sufferance. It's forced me to use Gnome3. The Gnome3 taskbar and I are not compatible ("what a complete waste of space" springs to mind), so I'm not that happy about it. Debian's alternatives system for selecting a Window Manager (now the compositor under Wayland) seems to be completely broken.
But Wayland itself: a few paper cuts, touchpads not working after suspend and things like that - nothing serious. But my god it's fast, and amazingly remote X11 connections (ie, "ssh -X") still just work. And the code base is much smaller.
People are comparing Wayland to systemd, to me it's not at all like systemd. Systemd was more complex, in lines of code literally 100's of times larger than then things it replaced, and never delivered on it's speed promises, and seeks to replace everything with Systemd. On all those metrics, Wayland is the reverse - it even encourages mutiple implementations.
I agree with probonopd on many things, but I will concede that the benefits of this rewrite for hidpi and likely other features is needed. The dependencies for things may shift more however to the DE layer and that is ok - but it will make things more complicated for many developers as they will have to test against DE's more methodically than what they had been is what I suspect.
I am picking up on this from writing app that cares about the currently focused app and with x11 that is easy to deal with. Wayland explicitly denies it from happening, only the DE can give me that information and I have to work out how to work with all of them individually if I want to retain parity. There are definite cons to that as it limits the DEs that I can support vs having the capability retained in Wayland.
Though as developer you should already be aware that programing against 1- different incompatible targets is extremly painful, so why the hell they did not implement a Wayland server too, is seems a cheap excuse "wayland is just a protocol, all the issues are in the implementation you use".
I am expecting someone would comment that browsers are a good example, and my answer is go check the contenteditable and for example how text selection works and all the issues people had creating a rich text editor that works on all browsers using it.
> The legacy is holding back desktop Linux quite a lot.
But I'd rather have it be replaced by something that's like X but supports higher resolution then (4K works for me with X though, no issues), rather than with something that doesn't allow screenshots, xdotool automation, clipboard, ... in the name of "security".
Wayland seems like a move to take away control from the user to me.
I'm guessing you prefer the selection "clipboard" and the primary clipboard. There are a couple more clipboards that nobody uses.
I agree the selection is sometimes handy, but I've accidentally hit the middle button where I didn't mean to just enough times that I'm ready to give it up. I rarely use them to hold two different things.
> Screen recording works with Gnome's built in recorder.
okay, but what if I don't like gnome ? e.g. I had to record a screencap of a bug of a software (that, uh, occurs only under wayland) so I went under weston and, well apparently there is also a screen capture tool but it is incompatible. On X11 I use simplescreenrecorder no matter the desktop (I mostly use i3wm or KDE Plasma depending on the circumstances).
Also what's the way to set a different keymap, that would work for any wayland compositor ? `setxkbmap` used to work but doesn't anymore and this is fairly frustrating and I really really don't want to have to learn one command per compositor.
Moving windows (or even the mouse cursor) also feels absolutely sluggish on wayland, like the frame rate is halved.
Under X11, the screen capture and recording doesn't work when one of my screen is scaled and rotated. The capture will turn entirely black, even when capturing on my other screens. If I want to capture something, I need to unplug that monitor (or change my xrandr settings to put it back to horizontal).
Works just fine under Wayland with Sway.
Improvements in X11 break software all the time too. It's not a wayland thing.
Screen recording was something that couldn't just be copied over from X when building wayland, because the way X does it lets any application just read any visible data from any other application with a window open. Avoiding that kind of security hole was one of the main goals of Wayland.
So it took a while for screen capture to work on Wayland. I agree that it was questionable for distros like Fedora to move to Wayland before such a critical feature was working, but now it works.
Because Wayland is a protocol with no canonical implementation, it is going to take a bit of time for all compositors to implement the new standard for screen capture. But gnome has implemented it, so has wlroots, and I assume KDE has or soon will. Weston is a toy compositor, not intended for serious use, so it's not surprising if it lags behind.
The only env var you have to set is MOZ_ENABLE_WAYLAND=1.
You will probably also want to force enable webrender (gfx.webrender.all = true in about:config), which still isn't on by default apparently.
I've used this for more than a year on Sway. Recently I had some issues with addon dialogues , but mostly it's been running just fine and with best in class performance, very noticeably faster than Chrome.
Is it? I moved to Sway (a Wayland WM) a few months ago, and run FF exclusively. Hell, I even run Firefox ESR (as provided by Debian), and I've noticed precisely one bug, and it's tiny: the main FF hamburger menu has a vertical scrollbar even if it's got plenty of vertical space left on the screen. Whatever, I use that menu once in a blue moon. Everything else is perfect!
What are you experiencing?
> you need to set up some environment flags before launching it
A single flag! Come on, this is hardly a problem.
> and there's a trove of bugs still open for it.
There's a trove of bugs open for FF in general ;-)
> Like cut and paste between different kind of applications, which is an horrible user experience tbh.
What do you mean? It works fine for me. From FF to other Wayland windows, from other Wayland windows to FF, and to and from Xwayland windows. The only copy/paste behavioral difference I've noticed on Wayland is that I lose the copied data if I close the source program. So when copying from FF, I can't close FF (as a whole, not talking about the window in question) before I've pasted. I can't see that this is an actual problem.
> The only copy/paste behavioral difference I've noticed on Wayland is that I lose the copied data if I close the source program.
This is because sway by default does not provide a "clipboard manager" component. It has been the case for a long time that the clipboard is only actually populated when you paste, copying merely stores a reference. This is so you can copy/paste multi gigabyte files without running out of memory. A clipboard manager component solves this issue by intelligently saving your clipboard as applications come and go.
The clipboard issue was the bug that forced me to switch back to X11. I need to have a Windows VM running constantly due to some proprietary software at work, and copying/pasting text under wayland between the VM and linux almost never works as expected.
I'm using Ubuntu 20.04 on an XPS13 and can finally have different scaling factors between the internal HiDPI screen and external normal DPI screen without awful issues.
For me I have a 60fps 4k monitor and a 1080p monitor. I want a higher refresh rate monitor for gaming but I do not want to drop down to 1440p on my main monitor so I am waiting for 4k high refresh rate monitors to become affordable. Wayland makes it possible to wait that out and doesn't break anything I do.
That would have way less PPI. I have 24" 4K display that already has less than 200 ppi. Thats why I am interested which 4k display would reach close to 300, if that wasn't just a typo.
Indeed. Now the question is: where do you get a 16" 4k display for $300? As I like displays with high resolution, I find it very disappointing that 4k displays with 150 ppi and less are plentiful, but it is difficult to find anything with 200 ppi or more. Even at 24" you just barely get 200 ppi and you are lucky if you get such a display.
The only downside is anything running in xwayland (Essentially just apps on old versions of electron and wine) will pick the scale of one of your monitors and not switch when dragged across the border.
Same here, I am using Sway WM on top of Wayland as my daily driver both at home and at work since early 2020. So far I am not really missing anything from xorg after all the horror stories that kept me from giving it an honest try earlier. This is of course a personal experience and I don't doubt there are things that might break, but I haven't encountered them and I'm very happy with Wayland.
I've had the opposite experience too. I have an Nvidia linux card and Wayland on Fedora has always worked very well for me. In comparison Xorg on Ubuntu was a nightmare on the same machine
I've found it very difficult to make screensharing work at all in Wayland.
On the other hand, the reason I switched to Wayland was that I wasn't able to get multiple monitors with different pixel densities working in Xorg. That works fine in Wayland, and since one of my monitors was unusable without being able to choose different pixel densities for each monitor, Wayland it is.
If it matters, I'm using Pop OS on a System76 Thelio.
The biggest issue with slack and wayland is due to Slack running via Xwayland (so not wayland native).
When electron 12 is released and slack will be build using it, it will be possible to use slack as a native wayland application and then screensharing should work.
One of the things I noticed with fractional scaling on my 4K monitor that video playback occasionally looks choppy, which is slightly annoying because I don't want integer scaling because my other monitor is a factor of about 1.4 off.
That never worked under X11 either so not a problem with wayland, just it would be nice to find a solution.
You could try it in chrome which has wayland support. Wayland support was added to chrome and electron recently but it looks like most electron apps are on old versions.
I don't get why everyone gets so defensive for Wayland. It's a fact that a lot of things still do break for users if they switch, without existing alternatives or workarounds.
Yes, Xorg is now legacy, outdated, insecure, and does too much. But what wayland did was to replaced one functionality of Xorg, without offering alternatives to other functionalities. Which is good, I guess, it has a clear and focused responsibility.
But now compositors are responsible for other functionalities and they seem to be doing things in their own way. Which is also good, I guess, they explore the design space and then they can gravitate to a standardized way of doing things later.
But it's more than a decade now, many things seem to be stuck in the "exploring design space" phase, so it's understandable if some users are impatient. Yes, it's free software without warranties, it doesn't mean immunity from criticism though.
I also get performance regressions in wine games on xwayland, didn't try wine-wayland yet though. But many games I play will never move from X.
People get defensive for Wayland due to the tone of the article. Sentences like "Let Wayland not destroy everything and then have other people fix the damage it caused" sound extremely hostile, making people who disagree immediately defensive.
People get defensive for Wayland whenever it comes up. While I don't agree with the tone of the article, the author brings up valid points (mostly in the comments though).
Also I believe the problem is not Wayland. It's the lack of other standard protocols on top of it that are required for application developers to not chase ad-hoc, desktop environment dependent protocols for basic needs like screen sharing. The issues are probably political rather than technical, and the solution is coordination between the desktop environment implementers to use the same standards and provide common interfaces for application developers.
The biggest roadblock and catch22 is nvidia support. Developers using nvidia can't use wayland and hence can't contribute to better compositors as there is no incentive for themselves.
Statistics say nvidia has around 20% global marketshare and for gamers it's up to 80%. My guesstimate is developers are somewhere in the middle there so you are looking at 50% of all developers that can't use wayland themselves. How is that ever going to make the compositor ecosystem catch up.
I have nvidia and use wayland. It works just fine. I think you are referring to a nested caveat of this which is that the subset of applications still coded soleley against the X protocol will run without gpu acceleration under nvidia and Xwayland. The number of these apps has dwindled thanks to gtk and qt moving over to wayland, now chrome and firefox have early wayland support, and like you said nvidia will soon support Xwayland.
That was just example. Because of Wayland's security model of sandboxing applications, none such tool will work. Currently afaik only way to do something similar is using /dev/uinput as does for instance ydotool, but its capabilities are vastly inferior.
For the same reason that it can make sense to say that python is more powerful than C, even though you can obviously do more things with C than with python. Xdotool lets you send keystrokes to a particular window, even if it's not in focus. You can do that with ydotool if you also do some sway IPC, but it's not as convenient, and no one has made a higher-level tool, possibly because it would be a nightmare to make it work with multiple different compositors.
Do you know if there's any standardization effort to support xdotool-like functionality over wayland with some kind of actual security model (using ydotool kind of subverts the security improvements wayland offers unless one does more due diligence than is pleasant to do for quick scripts)
I see your point. No, I'm not familiar with such an effort, though it could probably be incorporated into our existing protocols, perhaps with only minor changes.
Actually, xdotool is the wrong place for this kind of automation. IMO, the optimal place to implement this is in the toolkits, to make it possible to read text and properly click buttons and menus.
I think you have a point, and I agree about this kind of complaint for screencapture where there are APIs on Wayland so you can't point at X-based software that didn't port and say "it's broken"!
However as far as I am aware there is no proper key-capture or key-inserting API in Wayland. There are hacks (IMHO) like bypassing the compositor and reading the events directly but we are still missing a well-defined API that is supported cross-compositor.
I am fine with GNOMEs very limited keyboard shortcut support but I definitely agree that this is a step down from what we had on X.
That's not true. It bypasses the default security model but it is entirely possible (and to be honest I'm surprised there hasn't been progress) for the user (or the compositor automatically) to provide an API that provides the required access to whitelisted applications.
It is just like the web. By default websites don't get to access your camera, but that doesn't mean that camera access is impossible. They just added a way to request camera access with user permission.
Yes, officially and well contained mechanisms exist (used for virtual keyboards).
Heck, you can even go a layer lower and simulate a keyboard event device, which would work with any window system, past, present and future. Even kmscon.
There might be some good stuff here for Wayland devs, but otherwise seems to be mostly the usual dumpster fire (good for for roasting popcorn, though).
Stopped reading at this gem from the OP a long way down:
> For all the Wayland proponents here, why argue in places like this, wouldn't it be a better use of your time to send PRs to fix things like MaartenBaert/ssr#431 and vkohaupt/vokoscreenNG#51.
Time perhaps to invoke Teddy Roosevelt:
"It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat."
Hats off to the Wayland devs. We're cheering you from the sidelines.
>Hats off to the Wayland devs. We're cheering you from the sidelines.
Its pretty horrible how much toxic crap gets directed at the people who actually do all of the work. Just look at the amount of abuse has been flung at the SystemD developers from people who largely do not even know what it does.
Then again, mocking and taunting people for using X11, which works great for most people, repeating all over every social media outlet that “X11 is dead use Wayland LOL,” giggling about how once IBM pulls its developers from X11 that “nyaaa nyaaaaahhhhh you’ll have no choice” and other poor marketing decisions, apparently conceived by obnoxious children, have convinced many people to NEVER touch Wayland with a ten foot pole.
It’s like the System D shills - they are HYPER obnoxious. I don’t need software made inside IBM, and I don’t need software which apparently can only gain adoption by obnoxious bullying.
It’s too late for Wayland, much like it’s too late for System D. The hyper childish bullshit chased me, and many others, away.
Wayland represents an interesting and possibly classic software situation - a beautiful standard has been developed. It blocks the user from using a screenshot application in the name of security.
Now when the standard gets rolled out kludge will be developed to allow users to still take screenshots. The beauty of the standard will be compromised or everyone will spend a bunch of time pretending the kludge isn't de-facto part of the standard.
Wayland's model of user security was a mistake if the goal was getting typical users to use it. It isn't secure, it just means screenshots will be done with a kludge. I think literally everyone I know who owns a computing device (I'm counting phones and tablets) wants to be able to take screen captures to show people things.
Taking your example of screenshots... I don't think there's an 'official'/defacto Wayland protocol for that. Under GNOME Shell you can use the org.gnome.Shell.Screenshot dbus API, but under KDE you presumably have to use something else. It is pretty grim.
These are dbus APIs though, not wayland protocol specifications that you can call with libwayland's RPC mechanism.
On the one hand this means you can support both X11 and Wayland with a single API from a client perspective, on the other you have to use DBus, which is horrendous to use (especially from statically typed languages).
It also doesn't seem to work on my XFCE/X11 desktop, which shows what fragmentation we have now.
> DBus, which is horrendous [from] statically typed languages
Could you explain this? In my experience DBus provides you with a schema, the exposed DBus interface describes the callable methods, their arguments and types, readable properties, and signals.
Just like with SQL it's useful to create a layer that takes advantage of the statically typed powers of the language.
Usually there are tools that use introspection (or the XML introspection data) to generate "types" (ie. this layer).
Not all statically typed languages. Using it in QT is great, and using it in GTK in C is not more difficult than showing a window. I also recently came across zbus in rust (https://docs.rs/zbus/1.8.0/zbus/) and it looks like it’s similar dynamically typed languages. I’ve also heard good things about the Systemd implementation. In all of these situations, it’s far easier to use DBus than another Wayland protocol.
I use grim with sway / wayland and it works great, much better than scrot on X (which always leaves strange visual artifacts on the image when using rectangular selection).
Not a big fan of the hostility in the text and the comments under it. Wayland does indeed break compatibility at points with X, but I still believe it's a good way forward. I'm personally holding off on switching over until the desktop environment I use(KDE) says they fully support it, and that it's stable, but I don't really see the need to be this aggressive about it.
I picked one a few of those issues at random, and they're entirely out of context and deliberately misrepresented.
For example, some Jitsi bugs are closed as "we can't fix this", and it's because the issue was a Firefox bug (hence, Jitsi devs could do nothing). Also Firefox did actually fix that. So, not only is the context wrong, the issue is actually solved.
Also, I used Jitsi and screen sharing on sway several times a week - works like a charm.
I've looked at a few examples, and they seem to most be misrepresented the same way.
It is trivial to write a desktop-agnostic screengrabber program in X11, but impossible to do that in any Wayland-like display server since by definition you need to integrate it with your display server (e.g. Gnome's, KDE's, etc.). Also for example Gnome's Wayland display server integrates a shitton of garbage into the display server process itself (e.g. a Javascript interpreter), and a crash in any of that code brings down the entire display server with all your windows.
I have tried using wlroots, it's very hard. If you had to build your own compositor Mutter is far easier (it provides a GUI toolkit and all you need graphic wise). QTWayland is very nice too but won't get you far outside embedded uses (no xdg portals, no screen capture, etc.)
WayFire makes wlroots a bit easier but I find it quite messy/not clear (but it's very powerful & flexible).
There's definitively the need for an easy high level API for wlroots (the main wlroots dev started working on a high level scene tree API some times ago but it now seems kinda abandoned)
Enlightenment has support for Wayland. It is up to the hundreds of X11 window manegers if they want wayland or not. There a lot of distros supporting x11 WM:s very few supporting Wayland, Enlightenment, Sway, Wayfire, Taiwins, Liri shell,Hikari, a few supports Plasma and Gnome. Only Arch supports them all.
Having a singular library is more limiting than X even for a developer of a wm and much more so to user who can no longer merely assemble an environment by setting a list of components to be started by a script.
That's exactly how I'm assembling my Sway session. My Sway config ends with `exec systemctl --user start sway-session.target`, and that target links to all the services I want running in my session (redshift, notification daemon, etc.). If you don't like systemd, you can `exec my-session-startup-script.sh` in the exactly same way.
> User services only really make sense for user stuff that requires more complex set up and tear down than start foo and kill it when I log out.
>
> Creating a user service per single line exec foo is extra ceremony.
Then go with the parent post's other suggestion: a simple startup script that ends with launching Sway.
> I have nvidia hardware so sway makes no sense for me to use.
I mean the fact that Nvidia refuses to play by the rules, making their hardware unusable with Wayland, is a well-established thing by now.
> Also it's developer is extremely abrasive.
Is he? He has strong opinions and doesn't beat around the bush, but does that really matter unless you yourself actually want to develop Sway?
> Is there anyway that sway does better than i3?
I actually haven't tried i3, but on the face of it I would say that it's an advantage of Sway that it can run without the gigantic and increasingly unmaintainable legacy system that is X. You can certainly run X without problems today, but isn't it widely agreed that X doesn't exactly have a bright future? Sway is not tied to X's future.
I asked you to name even one thing sway did better and you tell me about the nature of the legacy code base.
No user on earth cares any more than they care about the sharpness of the blades used to grind the sausage they ate for breakfast.
I'm not sure why you imagine that nvidia is obligated to support Linux in the fashion you would prefer. I bought the hardware based on the existing drivers working well under Linux and windows not love for them or idealogy. This is why most people buy things.
X11s future departure seems like a thin justification seeing as it's future seems pretty secure for the next decade. Maybe by 2030 there will be a compelling case for switching plus hopefully the kinks will have been worked out courtesy of folks like yourself.
> I asked you to name even one thing sway did better and you tell me about the nature of the legacy code base.
OK, let me rephrase it: a feature it has over i3 is a higher probability of running on the platform provided by most distros in 5 years' time.
> No user on earth cares any more than they care about the sharpness of the blades used to grind the sausage they ate for breakfast.
Indeed. But if you're choosing a sausage you wanna have for breakfast for the next few years, you might choose better than the one made from the animal that people fear might go extinct.
> I'm not sure why you imagine that nvidia is obligated to support Linux in the fashion you would prefer.
Oh not the fashion I prefer. The fashion the Linux developers prefer. Most other providers of hardware seem to. What makes Nvidia special?
> X11s future departure seems like a thin justification seeing as it's future seems pretty secure for the next decade.
Perhaps. You may well be proven right, but I wouldn't bet that X11 is able to attract sufficient manpower to keep up going forward. Time will tell.
I'm not trying to convert you. I'm trying to give one argument why Sway might offer something that i3 doesn't.
Give it some time. With the way sway and wlroots are developed, someone will create a proper high level framework-to-write-a-WM one day and we'll get all those experiments on wayland too.
One day. While today it's easy to write one in X and you don't have all the compatibility issues talked about in the article and up and down this thread.
One of my main gripes unfortunately Wayland does not function very well with accessibility software. Areas include but not limited to :
-simulated keyboard/mouse input (some progress recently with some composers)
ability to inspect window attributes (e.g. window title, executable and handle)
ability to manipulate windows (e.g. maximise, close, etc)
So just as with automation software this has significant impact on accessibility. The current composers available provide very limited functionality. Not to mention there are many different composers that would have to be supported to make many different system configurations accessible.
I don't really understand why such a title has been chosen for HN. Granted, the original one is inflammatory, but this one is just wrong: there is no “Yet”, Wayland will never be a 1:1 compatible Xorg replacement, and is not intended to be.
Wayland has a different approach when it comes to security, which makes it much less flexible in order to increase user security. It has evolved a in way to allow as much legit things as possible, but it will never be 100% compatible with what Xorg offered, by design!
I can no longer use Linux on desktop due to Xorg's lousy DPI scaling support and tearing. Let's face the fact that most laptops are currently HiDPI, modern external displays are too, and neither 1x nor 2x scaling is tolerable with most of them. Unfortunately my video card does not really work with Wayland.
I have never had this serious hardware issues with Linux since 2002. Xorg got outdated but the replacements are not here yet.
I mean display scaling settings that are especially useful for laptops with high-DPI screens.
The desktop environments do have settings for scaling all the elements (not only fonts) but when running on Xorg, the alternatives in the DE are 1x, 2x and 4x, while many present-day configurations would require fractional scaling (like 1.5x) to be usable.
I have a 27-inch 3840x2160 display which I cannot use without scaling, since the UI elements get too small for my eyesight, and scaling everything 2x (effectively 1920x1080) kind of voids the purpose of buying a 27-inch display since the usable screen estate is downgraded to something typical for 23-inch screens. Our laptop has 13-inch screen with 1920x1080 resolution - again not usable without scaling and a disaster with 2x scaling (960x540). Windows is offering very convenient 150% and 125% scaling options on these pieces of hardware, so I had to migrate my professional work to WSL unitl updating to Radeon and Wayland.
They seem to point to https://pipewire.org/ for screen recording. I don't know how well that works out in practice and if there are other solutions for automation
I really miss the network transparency in Wayland. Just being able to start a program on another machine through an SSH session is so useful. You can use something like vnc but a "whole desktop in a window" is slower and not as handy.
I'm on freebsd mostly anyway which isn't big on the Wayland train so I'm fine for now. But it would be great if X11 development would be continued.
Yeah I hope so. It's not in a good place with RedHat right now because they want to get rid of it anyway. This way it becomes obsolete even quicker, it's a self-fulfilling prophecy.
I really hope some group will take it on board that really wants it. I think there's still a good usecase for it.
FreeBSD does support Wayland in a way but it's pretty primitive.
Agreed, my workflow is a workspace with firefox with jira gitlab etc. open. Then a few with terminals and vscode open, several of those are often vscode running on remote machines via x forwarding. Then I develop on one box that is a couple vpn hops away and its too slow for forwarding. I hate it though because I have to switch to that workspace, fullscreen the window, and then when I'm done, esc the vnc and switch to another workspace. If there is a wayland way to have just firefox or just vscode running remotely that would solve my concern.
Yeah even on my cloud boxes it works great. They are physically close though.
Ideally if X was still maintained they could incorporate some of the old freeNX / X2go logic that makes it more robust against latency.
But I think this usecase is becoming more important again. In the early days of X it was great because we were all using terminals on single powerful machines. Then we moved to desktop and transparency was less of a thing. But now we're moving more and more towards cloud computing again which is not all that different from the old client/server model. At least not in the sense of having a separation between compute and I/O.
Windows subsystem for linux literally uses RDP and wayland for single windows as its graphics subsystem. Single windows aren't a problem and "network transparency" through remote procedure calls is just anachronistic, and will never support things like animations, 3d, or video.
A few months ago I came back to Arch with Gnome and Wayland after several years with Mac. Sadly, default Gnome installation is way less functional now than it used to be back then. Screen sharing doesn't work in Skype and Slack because of Wayland. Apparently Zoom circumvents this by making a series of screenshots. Systray is missing and most of extensions that promise to restore it don't work. Some parts of UI(e.g. weather widget) relies on emojis that are not installed by default. I understand that sometimes you need to break stuff in order to move forward but I think this has gone too far already. (I ended up with X11/Cinnamon)
Nobody has said it, but it seems we are reaching a fork in the desktop?
For users, not 'right' and 'wrong' here, just two groups whose goals differ.
Those supporting X.org are using X very much in the spirit of it; custom window managers, network transparency, and possibly bitmapped fonts, BSDs.
And those in support of Wayland have arrived there via Linux with eg. GNOME and dominated by GTK and QT desktop apps; looking for an open-source offering with the same functionality as Mac and Windows desktop.
Really, this has been brewing for a while. It's been a fluke that the underlying X has allowed these two groups to co-exist.
One more nice thing about X that people sometimes miss is that you can turn off compositing (this is the default really.) Lots of people say Wayland feels "sluggish" and this is likely a major contributor to that. Especially if you don't have hardware acceleration (and there are a huge number of reasons why that might not be working.)
Wayland solves a lot of problems by deciding to just not handle things but we have to recognize that taking that position sacrifices things.
Yes, I am also not using compositing, which I always assumed means apps render direct to the framebuffer.
Does this mean that moving to Wayland (or its implemenation) is going to add 1 or more frames of delay to my output? This could be a part of why I have always found other modern systems to be less snappy than my own X desktop.
Not so long ago, I had to use screensharing from Chromium, which I tried from Fedora (I think 31 or 32, it was less than a year ago). It didn't work; all I got was a blank screen. Logging out and back in to Xorg fixed it. That convinced me that, at least at that moment, Wayland was simply not ready.
Apart from that, I depend quite a lot on things like xdotool, for which I'm not aware of a (generic) Wayland alternative.
If these issues are solved, I may try it again, but overall I'm pretty sceptical; around mid-2019 I tried GNOME on Wayland and there were some pretty wild rendering bugs that I didn't have on Xorg. The compositor being responsible for all rendering also meant that when doing something like opening the app menu, the cursor started lagging, but that's probably more of a GNOME problem, but it still concerns me.
I wasn't even sure which of them I'm running even though I've been remote teaching for almost a year, i.e. frequently sharing my screen:
> [user@laptop:~]$ echo $XDG_SESSION_TYPE
> wayland
Apparently it's not as bad as it seems! However, now that I think of it, I haven't been able to share the entire screen and must add one application at a time to OBS. Maybe I've gotten used to this. At least I won't accidentally show something that I'm not supposed to.
If you're using a wlroots compositor, then a workaround for sharing the whole screen is to use wf-recorder [1], which supports capturing the whole screen, and feeding its output to a virtual V4L2 device using v4l2loopback [2]. Software that is able to capture from a V4L2-compatible webcam (i.e. most) can them capture from the virtual device without knowing anything about Wayland. It's not exactly the most CPU-efficient way of doing things, but if you can afford the cycles it works very well!
I have a high tolerance of stuff breaking... even now my mid-2020 release laptop requires a custom built kernel because the latest kernel (5.10.12) doesn't support the WiFi 6 chip properly.
Ultimately the reason why I won't adopt Wayland is that I use XFCE, and XFCE doesn't support it.
Totally leaving aside the entire topic of that post, the comments could be used as a textbook case of a toxic "discussion" ...
That in itself I think tells more about the state of things around wayland than everything else.
I too use wmctrl daily to organise my windows as I switch between using a larger monitor docked to my laptop, back to my laptop screen. wmctrl allows me to move and resize all my windows as I require, all at once. I would find it very inconvenient not being able to "fix" my window environment easily, which I can with wmctrl.
Wouldn't it be possible to write Wayland in such a way that it is similar and familiar to Xorg, so porting Linux GUI applications is easy? Or is the API already familiar enough that this is already possible?
Surely it's possible to write a modern display stack while preserving the rich legacy of applications, toolkits, window managers. I would certainly like proper isolation of input, and better support for HiDPI and even locking. But I would certainly miss Xscreensaver and Fluxbox, and even random applications like Asunder or Suckless Terminal.
Though I admit that I'm speaking from a position of ignorance, having only ever written in C/SDL for anything graphical on *nix.
PS: Now the possibility of porting Fluxbox to Wayland is beckoning me. Could such a mad thing be attempted?
This is so incredibly bad faith based. I have used wayland on my main computer for the last 3 years and the amount of GNOME-centricness is entirely choice based, there are lots of other options. There are items on those lists that have been long fixed, it's just that X tools don't work on wayland. One has to employ wayland tools. This is like saying "I can't use x86 assembler for arm processors therefore arm is useless". A new technology requires new tools (a different assembler in this example). Some tools are already present in wayland world (like redshift replacement) and some still have to be developed. Instead of whining the author could perhaps contribute to that effort and make wayland a better place.
I'm of the opposite opinion. Think twice before doing anything with X as the experience and knowledge you gain will soon be useless.
Instead invest in wayland, it works great and will only get better and X will only get worse at this point.
The pain points are few but yes, if you must have screen sharing with a particular app that doesn't work with wayland that might be a dealbreaker. If not, no reason to stay with X, pick a time when you are configuring a new computer or whenever it is a good time to make the switch and try it out.
As I said, there are pain points. If you need application X to do Y and it doesn't work in wayland that might be a dealbreaker for you.
I'm having no issues with screen recording and screenshots. Haven't attempted nor need remote desktop but know people that do it. Obviously don't have the same breadth of alternatives such as X.
Something that isn't particularly good 12 years in will likely never be so. At 12 years in some really basic stuff is just now rolling in. In general the idea of natural progress is completely imaginary. The general nature of things is to get worse not better entropy always wins.
It night not be great but it does many things Effectively and doesn't require each graphical environment to individually handle low level hardware details.
The people who would greatly benefit from not needing to maintain it shout from the rooftops that it is dead because they wish it was already so. In fact its probably be mainstream for another 10-15 years and existing for another 25. Look how long it took to sort of but not really kill python 2.
Thus the choice today is actually X vs Wayland because those are the 2 choices that can provide a functional desktop at this point in time.
As for possible Ys I see SurfaceFlinger from android which doesn't look like its suitable for a desktop
Arcan a one man band that doesn't look apt to replace X soon
Whatever Redox uses. I don't quite understand from a casual inspection how graphics works there.
I would bet money that the choice over the next 10 years will STILL be X vs Wayland with more stuff wedged in until wayland is more functional but as kludgy as X wherein someone will have the brilliant idea to replace it with something more "modern"
When using gnome wayland is already the default in most major distributions already or have been announced for the next major version (such as ubuntu 21.04).
I don't know about KDE more than that they are making progress. If they within a few years make the same transition then pretty much every single default installation will be on wayland. A few moments after that XWayland will become the leading X-server. X will surely live on for decades to come inside wayland, and that is fine. And X will surely be an option for an eternity in some distros. But it will quickly become quite niche, similar to the way systemd has become the mainstream init system.
Maybe so but being the most popular option made Microsoft some money it never actually made it very good. In all honesty Gnome + Fedora + Wayland is a mediocre work compared to windows. At that point the only reason to use linux is cost and given the cost of a license it really isn't a very good one.
I wont feel bad about running a niche distro or even a different OS any more than I feel bad about picking Linux over windows in 2003. There is no accounting for taste and there are probably more people listening to Britney Spears than Beethoven. Its OK if you want to be involved with pop music there is money in it and it still requires the same skills to produce good sound regardless of the artist.
In order to support recording on different Wayland compositors (without having to develop tons of other middle layers by yourself), one would need to simply activate their built-in screencasting tool according the specified user settings. This took me a bit of time to figure out for GNOME, and I had to fill a bug-report to speak to one of the compositor developers to understand how to do that, as no documentation was available at all. Even so, some hidden bugs appeared (Quality wasn't too good, audio had to be recorded separately over ffmpeg, and then both audio and video had to be merged together in one file, V9 had a bug that consumes 100% of CPU on some hardware, so we had to use V8 by default... etc).
In order to go further, I had to do the same thing for KWin on Wayland, Sway and other compositors out there in the market and then integrate them into my program. I had to find some workarounds for any bugs that may occur.
Later on, some changes for ffmpeg API broke the Xorg recording (Green Recorder used ffmpeg to record on all desktop environments on Xorg), so I had to do more testing now for multiple versions of ffmpeg and on which distro do they work and don't work.
So I just gave up, as I simply didn't find any particular reason to continue doing that since the only amount of support I received on my then-opened Patreon was $20 per month at its max.
But it shouldn't be said that Wayland can not support screencasting or that it breaks screencasting. It is possible, and the previously mentioned issues are actually on the compositors' developers side, not the protocol.
So funny to read "Wayland breaks everything", yet I run it everyday (on Ubuntu), it solved my screen tearing and other than that I only switch to X for my sons Minecraft.
For me it didn't "break everything" in fact, it fixed something for me. Moreover, it seems to be more secure (which is of course something you only notice by things not happening). So such a title does not really make me want to read what is probably an emotional rant.
Edit: I see the title just changed, anyway, I think most people realize it's not 1:1 with X, which is why Canonical makes X defaults and allows me to choose easily. At some point though it will be nice, I for one like the promises of PipeWire. Why is there so much emotion involved with such projects anyway?
"screen tearing" is this thing which is always rolled out to defend Wayland, and I use X all the time and have never worried about this as a problem (even assuming I understand what the problem is). Maybe my eyes are too slow to see this or something. To throw away everything to get this imaginary benefit seems pretty strange to me.
I think it is a matter of proper GPU driver support + correct configuration and people mistakenly attribute all bad to Xorg. My polaris AMD cards have perfect tear-free video, but with intel I had problems/difficulties to configure tear-free behaviour.
I love wayland in old laptops, specially the ones with an week iGPU, as it's a lot faster than Xorg, only being a problem with a few specific programs like OBS Studio.
But.. in desktop I use a Nvidia card, and for business shenanigans the drivers are not compatible with wayland, and Xorg it's ok but there are some features I miss, like fractional scaling in Gnome 3.
Right now I can see wayland as great alternative for casual users, that mostly use a web browser and require a fast solution that it's good enough, but I don't see it as a full replacement yet, and god knows if will ever be.
The problem it's that despite being old Xorg it's great too, and the benefits for wayland are there, but maybe not enough for a full migration from all developers.
The author seems to have way to little knowledge about wayland. It's okay to say I use Xorg bc it's not ready for my usecase yet but spreading this whole GNOME FUD makes this more spam than anything else. I can't take this serious at all.
I think I'll wait until every screen sharing, video calling application I use will work with Wayland. Pasting selected text with middle button is also very important to me (huge time saver) and it seems not to work with Wayland yet.
Basic things like embedding windows (and thus classic, non-remote-puppet-over-dbus) systrays are impossible, which funnily enough break things like signing my tax forms with digital signature...
I should say that if you are touchscreen user, wayland solves a lot of problems. I literally can't get touchegg or other crummy solutions to work in xorg for gestures, but in wayland with gnome it just works.
I've been using sway for more than an year but recently got an issue where all QT applications randomly close and can no longer start until I restart sway.
The screen sharing works fine with xdg-desktop-portal-wlr and with Fedora moving fully into pipewire I'd expect things to get even more stable under wayland.
One thing I'm missing is a decent screen recorder (gif/mp4). For screenshots one can use swappy, it works perfectly.
> Err. What? I don't want Wayland. I want Xorg. But thanks for your comment.
The glove is on the ground, Xorg is getting abandoned, anyone who needs Xorg in their life can take up the mantel and continue developing and maintaining it. I for one prefer Wayland since it has an architecture that allows for security (not that the protocol enforces security by default).
The problem with wayland is simply underinvestment. https://gitlab.freedesktop.org/pq This person is probably responsible for most of the commits and PR reviews. Everything happens at a snail's pace.
It's very on-topic. In my experience no, they don't work as well as on Xorg. There was even a bug in Gnome's compositor too for batching input events at screen refresh intervals, which also makes fast-paced games less playable, even if they are native Wayland (not many of those, I believe).
All the things that were mentioned are annoying, but multi-touch works properly, animations are smoother and I get no screen tearing, even on a multi-GPU setup.
It's almost like different people have different priorities, who could've though?
Xorg is bad and deprecated but works, same with Firefox extensions.
Firefox devs decided to drop old extensions in favor of webextensions, now
firefox is at 3.66% marketshare and dropping every month.
(I am using Palemoon fork)
Another reason is the extremely toxic response of proponents to legitimate criticism. I'd link what is effectively a response from the primary dev of sway but I think I might get banned for the language.
The only thing that holds me back from running my Gnome DE in Wayand is that as of version 88 Google Chrome now supports hardware acceleration. But only for X11.
Honestly this sort of stuff is why using Linux as a desktop is actually super painful. 99% of the issues I suffer on my desktop I wouldn't suffer if I was using Windows or Mac. And all the reasons why I use linux are development reasons, container support is built in where on other os' it's virtualised, performance is faster on Linux than Macs, the CLI terminal application is better than on Windows, etc.
If the CLI terminals improved on Windows that they could compete with any of the Linux ones, I would probably switch to Windows since it's now got a ubuntu compatibility layer.
I'm using an OBS branch (there's an open pull request). I'm not a fan of how it expects me to guess the resolution of the canvas (and in GNOME you can't find out the size of a window), but that's not really the fault of Wayland.
I think Wayland is a nice way forward from X, right now it's still not a replacement because of how central X is and how much stuff interfaces with it specifically or make assumptions about X features. (and so indeed, Wayland kind of breaks "everything")
But I also think that they (Wayland) took a way too heavy napalm approach to the solution, almost like they totally ignored how painful such a transition would have been. I still don't get it...
You can quite easily be using wayland right now and not even notice it. It’s even the default on some distros now. Basically the only things holding it back are proprietary screen capture tools and nvidia.
I'm not saying you cannot use it, in fact I use it (with minor hassles here and there)
But this last step is taking ages, what I don't understand is why it had to be such a painful process without a migration path (hence we are still talking about it and the transition still didn't happen)
DPS was available as extension on X11, but it wasn't the same implementation as on NeXTSTEP, where AFAIK even the old 0.8 code already used Mach IPC for communication with window server.
Cascade of Attention-Deficit Teenagers. Instead of solving a bug, rewrite everything from scratch and close all the bug reports of the previous, now obsolete, system.
Wayland is a clear-cut example of that. Oh, mixed-resolution does not work well in X? Alright, let's rewrite everything from scratch. Of course, new bugs will appear, but then you can iterate the process to close them!
Wayland doesn't even work for me, so I guess I don't have such problems. I'm not really into the actual arguments between NVidia and Wayland folks, but I suspect it's something like "they don't want to bow to us, therefore we don't want to work with them" from both sides. Like a kindergarten ;)
That's part of what I'm talking about. Giving a 'f you' sign on a public conference is not professional at all. I mean I know that it's Linus who did it, and we all like Linus, so we give him a free pass with his sh-ttalk, at the same time when we would condemn anyone else who uses such rhetoric who isn't Linus, but in closed-source software development world such clashes happen all the time, each month. Whether a software project in such environment is a success or failure depends on whether people will get along with each other, or not. In case of Nvidia/Wayland I think that simply people just don't want to get along each other.
Having talked with some multimedia developers, EGLStreams is actually the better API, but it's nVidia's and thus disliked, whereas the other side wants you to use DRM-specific buffer sharing mechanisms... which won't work for non-DRM driver like nVidia (and then there's IIRC some licensing issues that mean nVidia can't use DRM, and so on).
I thought that software development was about finding solutions to problems, not escalating existing problems and demanding changes so we don't have to adapt.
TL;DR Just played Cyberpunk 2077 with no glich on Sway and Wayland on Arch Linux last night for almost two hours.
I am embracing Wayland and wlroot-based desktops. It is simpler, faster, and fits easier in my head.
Forgot to mention that I also just got my screensharing working under Wayland with Sway and Chromium for MS Teams (Have not tried with Firefox yet). Works like charm, albat with Pipewire. I have no gdm/GNOME installed.
I have no need for it. I also don’t care for IBM / Red Hat’s “viral” marketing, it’s really just terrible shilling. Nobody wants Wayland. Nobody needs it. We are tired of hearing about how IBM will pull its X.org developer - just shit or get off the pot already so a proper fork can be made to continue the work on X.
It's not meat in the fridge it doesn't go bad at a certain date.
Rhel 8 supports x11 and will be supported until 2029-2031. If they don't excise support by the next major release which is super likely it will end up supporting x11 until 2034-2036
Wayland fixes tons of security and inefficiency issues. You can also run xwayland, which is a compatibility layer that would fix 99% of the author’s complaints.
I’m not sure there’s a legitimate case to be made against Wayland at all. The author seems to have installed it without understanding what it is.
Just in case someone RTFA and gets worried: this is breathless FUD and could be handled much more usefully in some other fashion that invites discussion of pros/cons (such as is happening on HN but I doubt the gist will be updated...). Wayland is an 0.99:1.00 replacement for x11. I would appreciate a succinct "Wayland changed X, Y and Z and that will affect applications A, B, C" but TFA isn't that.
Much like systemd, Wayland sounded as though it might have some serious wrinkles but those, as with systemd, never really materialized for me (a power user on a powerful machine). Most issues I experienced were transient as applications caught up with the switch (mostly screen sharing). Even though it's not too important to me, games (wine and native) are working better than ever on Linux (and Wayland).
I think the two persistent "issues" I've seen are: graphical ssh (X-over-ssh); and, maybe, others screen drawing on my screen in Slack calls.
I trust the arguments from the x11/Wayland developers and, AFAICT, Wayland has been a Good Thing but some eggs were broken to make the omelette...
This is a common sentiment, but it is kind of funny. Because software engineers working for companies will know the struggle of trying to justify reducing technical debt, improving security practices, etc. but fail to see why these things are useful to them personally when the tables turn.
Wayland indeed “breaks a lot of shit” but it’s not an accident or done due to incompetence. Also, it’s worth noting that since there is not one Wayland server the way there is one Xorg server, that not all of this applies evenly. For example, wlroots-based compositors like Sway do not suffer from the screen recording issues as Sway just supports a permissive screen recording API out of the box. I do think the XDG portal idea is a good idea, though, overall, and that the security improvements will be worth the toil eventually.
But more to the point, that the problem is that moving away from Xorg as a display server really needs to happen eventually. The legacy is holding back desktop Linux quite a lot. Issues like supporting modern high DPI displays or multi-GPU setups are ones that Xorg struggles with that Wayland can be made to handle more elegantly (in case of DPI, already does significantly.) It’s not just that. There’s tons of weird old crufty garbage in Xorg. Clipboard is weird. Drag and drop is weird. Wayland is simpler and makes improvements that are welcome, like a good API for keeping window configuration synchronized to help eliminate “imperfect” frames.
No doubt there are issues. I have some choice words about the decision of GNOME to push for using dbus to communicate cursor size changes on high DPI setups, and I do not like the way client side decorations are favored in Wayland.