By the time GTK5 arrives Wayland will probably be old enough to drive or maybe even drink in the US. And, as much as I hate to say it, I believe it will still not be omnipresent in the Linux desktop.
I really want to see Wayland move forward and succeed, but there are so few companies injecting money on it, they get to dictate how things move. Red Hat is one of the main contributors, and they only seem to care about Gnome working on Wayland (as much as I don't like their direction, I can't really blame them for following it, it just sucks that I don't like the product they're developing). The landscape is extremely fragmented and everybody who is not on the Gnome garden will suffer a lot.
I really wish some other non-Gnome-favoring company would find a reason to dump a lot more money into Wayland and help move it forward in the not-only-gnome-favorable path. This is not a thing that will move forward without full-time workers. X has always had a lot of paid people contributing to it.
That is, if IBM doesn't decide to throw a bigger wrench at the problem.
What about all the portals built by Redhat that allow kde and wlroots to tap into screen recording, audio, and soon even key captures? I get that Redhat doesn't actively submit patches to wlroots, but they also seem to be making stuff as open as seems reasonable.
As a Sway user, I haven't noticed anything that works on Gnome but not Sway, except for stuff like Zoom, which hasn't, until recently, used the portals.
wlroots & kde both have their own xdg-desktop-portal-*[1][2]'s, which don't seem to be built by Red Hat.
xdg-desktop-portal itself originates from Flatpak[3], which makes me think it's more like to related to Canonical/Ubuntu rather than being something RH drove.
> I really wish some other non-Gnome-favoring company would find a reason to dump a lot more money into Wayland and help move it forward in the not-only-gnome-favorable path. This is not a thing that will move forward without full-time workers. X has always had a lot of paid people contributing to it.
My understanding is most of the work is, deliberately, not in Wayland itself. In fact if you read feature and bug discussion between users and Wayland devs, it kinda seems like Wayland doesn't do much at all and has no interest in doing more.
I haven't looked into it, but wouldn't be a bit surprised if RH had a hand in that architectural decision. Definitely makes it harder to compete with Gnome.
The Wayland developers do this because they absolutely do not want to be involved in the perpetual fights between desktops. Getting into that is a lose-lose proposition. So they focus only on the small subset of things that every desktop agrees on. Users that aren't actively working on an implementation in a desktop unfortunately don't have any place in this discussion, practically they just have nothing meaningful to contribute. It's not feasible without some implementation "sponsoring" the relevant code. Piling more features into upstream Wayland to please these users is not going to help anything, the implementations will not be able to use it and it will just complicate things for no gain and create more fragmentation. This is not specifically a Wayland thing, it was also the case in the X server if you were developing a new extension, you needed to gather feedback from the WM implementations before doing anything.
If you want to make it easier to develop alternatives to GNOME, it would be best to start putting more reusable features into libraries, and getting all desktops (including GNOME) to use them. That way you have a common baseline that everyone can depend on. That may seem counter-intuitive but it is the only way, libraries provide implementations and it is actually the implementations themselves that are the important part to users, not anything that upstream is doing. The simplest example is something like Mesa. All the Wayland servers want to support hardware acceleration, so they all implement the relevant extensions, and then they're able to support applications that talk using the Mesa libraries.
You've nailed the point and failed to get to the right conclusion.
> So they focus only on the small subset of things that every desktop agrees on
It's the old "but I can't do screenshots or screen sharing" again. The desktop may agree on this, but 90% of the users are like "I don't care, just make it work" - and by catering to what desktops agree on and completely ignoring things that at least some good percentage of every desktop will use, they kinda made a mess. It might be an architecturally superior mess but not even the people who have been tinkering with their Linux boxes for 20 years seem enthusiastic about wayland. Not everyone wants to first implement features in their window manager of choice.
>It's the old "but I can't do screenshots or screen sharing" again.
I don't know what this refers to. The screenshots and screensharing are done through the xdg portal and pipewire. That's as "standard" as something across desktops can be, but like I said it just is done in a separate library/daemon rather than being in wayland upstream. You don't need to really implement anything in your window manager of choice if you already have support for those, you just use pipewire. They all agree on it. The implementations haven't ignored this, you're telling me I didn't get to the right conclusion but your conclusion is to just keep barking up the wrong tree and hope they change their mind, when they have even less incentive to do that now because the feature is already implemented elsewhere in a much better way.
>but not even the people who have been tinkering with their Linux boxes for 20 years seem enthusiastic about wayland
I don't consider this to be a problem. The tinkerers get most excited when you hand them something with a giant config file (e.g. xorg.conf) with every option under the sun that they can tweak and watch it fall apart. Most upstream maintainers I've talked to would very much like to get rid of these giant config files because they are completely untestable and unmaintainable. The tinkerers cannot have their cake and eat it too.
Not really, I'm just saying I know enough people who are usually enthusiastic and knowledgeable and they still try out wayland once a month or so and it's always "oh, found 3 thing that don't work" and go back. They're not excited if they have to fix dualscreen working or something so basic.
That fork of GNOME with a Win9x-style UI exists: it's called Cinnamon.
It's OK and it's quite popular. It's a lot more customisable and versatile than GNOME's own GNOME-Classic or GNOME-Flashback sessions, but it's still really quite clunky compared to, say, MATE or Xfce.
If GNOME-Classic or GNOME-Flashback worked a little better, so that one could rearrange panels and add/move/remove controls and so on, I suspect that there would be no need for MATE to exist.
I personally find Xfce to support more of the customisations I personally want (such as a vertical taskbar with horizontal rows of components and controls) than MATE, or KDE come to that.
Wayland, for me, delivers nothing I really want. I read about variable refresh rates, HiDPI support, smooth flicker-free animations and so on, but I don't actually want or need any of those things. I don't get flicker or tearing as it is, and X.11 does all I need: seamless multihead support with 3D acceleration, and so on. I frankly prefer a minimum of animations and fades and so on.
Because, despite the fact that Wayland originally underestimated the size of the problem, it is in theory a better technical solution to our modern graphics problems than X11. It is designed in a more secure way (there is more isolation between the apps, which is both a blessing and a curse), every frame is indeed perfect, and it provides a sane solution to the 'compositing' problem.
It's just a shame it was made into something that is even more fragmented than X11 due to it being even less than what X11 tries to be. So much got undefined by the protocol and left as something to be solved by the Compositor, and we don't have an universal compositor.
And it's not like companies are throwing money at X11 either: progress is not happening there.
X11 is a fairly mature piece of software, though. It's been around for decades, and as usual, when things stick around for that long, it's because they work fairly well. I'm not sure what progress you'd expect to see there.
I guess I don't see why software that's been around for a few years longer than I've been alive, and has never really caused me much headache needs to be replaced with software that is an immature and in many ways, a worse offering.
I see people talking about screen tearing, but X11 supports vsync on most video cards, so I really don't quite get where that's coming from.
I guess if screen tearing is the worst thing you know, you wake up in cold sweat every night screaming its name, I guess you should really use Wayland. But for other people?
Right, I never got this. Every time the X11 vs. Wayland thing comes up, I see so many people talking about tear-free rendering as if it were on the same footing as curing cancer.
(Regardless, I haven't seen screen tearing on X11 in... close to a decade? More? I don't care if that's the case only because it's "possible", and not because it's "inevitable". Who cares? It works fine.)
Have you ever seen a film or a TV show that had screen tearing in it? I haven't, it would look awful. For anything that needs to animate smoothly at a stable frame rate, tearing is a bug. It makes it look really choppy. You can do various things to eliminate a lot of tearing in X (like using an X compositor, and only using clients that implement double buffer vsync), but the default in X is that clients can send drawing commands at any time. Wayland changes this and makes it so you're practically guaranteed to never see tearing by default.
I've used X11 for like 20 years and done all sorts of things, including watching video and even doing video editing, and this has never been an issue I've so much as thought about.
I don't know how that could be possible, I find tearing to be incredibly noticeable when doing video editing. If you're getting it when trying to do transfers between frame rates it will potentially screw things up, because you're not able to see the actual frame rate. Occasionally I still see a youtube video where someone recorded a screencast and was getting tearing, and I find it really jarring.
Dunno, maybe it's just not something I'm noticing at all. Some people seem incredibly bothered by it, but I just barely notice it if I'm not actively looking for it.
I'm far more annoyed by the added input delay and sluggishness from vsync. I want frames on the screen as fast as possible.
I don't know how you can't notice it when doing video editing, you have to actively notice the frame rate to do it right. Any choppiness will be evident. Also I really don't understand your second paragraph. You can't get rid of input delay or make frames appear faster by disabling vsync. When you mux the video you target a specific frame rate, the common formats are almost always 24, 25, 30, 60, or multiples of those. The frames are appearing the same, it's whatever is in the video file.
Any form of sane security. X11 can’t be made secure unless you go full nested X servers, where you are back to square 1 (cut holes for screen sharing and the like).
Why do you think it underestimated the problem? I am fairly sure it was a deliberately small core with an extensible (and queryable!) protocol model, exactly to be able to later develop more and more features.
There is no way to ship a full X11 replacement in one go, especially not in a bazaar-style platform.
I don't understand all of the hate around Wayland. X is fine for what it is, but Wayland enables the flicker-free, nicely-animated experience most users want from their desktops, and also better reflects how modern hardware works. GTK4 on Wayland is actually a pretty nice API to program with, which remedies a lot of warts in GTK/X11. Even Emacs runs X11-free these days: https://www.reddit.com/r/emacs/comments/rj8k32/the_pgtk_pure.... What's so wrong with declaring that X11 support will be dropped years from now?
My practical engineering analysis says that people will be forced to choose between abandoning working X software and foregoing new Wayland packages.
For example when one workflow critical app adopts GTK 5 (assuming it does not support X) and another workflow critical app remains X based.
And apps will remain X based because all the effort of porting to Wayland is chores not features.
Wayland doesn’t add import functionality to applications.
Indeed breaking the client-server idiom is a functional regression.
As is breaking Linux and Wayland is a breaking change because backward compatibility and/or reliable automated tooling to port complex applications is too much work for Wayland’s developers.
Who like most of those affected, are not getting paid Faang wages to work on deep pocketed well resourced teams.
Breaking applications makes it Python3 on steroids in terms of generating tidal waves of compatibility efforts.
Wayland has in-built backwards compatibility in the form of XWayland, so you can continue to run every X program you want.
But frankly, we can’t just put our heads in the sand and use 30 years old technology when it doesn’t map well to the underlying hardware. How else could such a transition ever happen otherwise?
The security model on Linux is "don't fling binaries from strangers around." That's why you can get away with the lazes fair security model X uses and still have less malware than Windows. Heck half the garbage Microsoft themselves ship with the OS could be called malware.
Ubuntu connected the web browser to Amazon by default.
And sent my desktop searches to Google.
Or maybe it was Duck Duck Go.
Which is Bing.
Same as Microsoft does.
My decision was practical.
Linux was a local minimum for me.
For my creative pursuits, Windows simply has less friction.
For example, my photography workflow used a Linux program called rapidphotodownloader.
One day toward the end, it stopped working.
I spent a non-trivial but not extreme amount of time figuring out why.
Turns out, the developer had hard coded window managers into the configuration file with the latest update (and the software nags every time there is an update and because it is Python with access with substantial file system privileges security is a concern).
Anyway, my Linux workflow used Xmonad which wasn't in the list of popular window managers the developer considered.
And because the software wasn't generous in what it accepted, it just broke.
I value stable tooling.
And after nearly a decade with Linux, I debugged the problem, changed the configuration file and felt a sense of accomplishment.
But what I really wanted to do was get my pictures off an SD card so I could do photography...editing, printing, and maybe sharing on social media.
If I was into filing bug reports, I would have let the developer know.
But I'm not.
Not that I am a selfish prick - at least I don't think I am - who doesn't "give back to the community."
It's that there is no community there that I am a part of...at least there's no more community there for me than there is a hammer community to which I ought to give feedback about hammers.
For many many things, digital tools are a mostly solved problem. Downloading files from and SD card and renaming them is a long solved problem...Windows Xcopy has been around since the NT days.
> I don't understand all of the hate around Wayland.
The Wayland thread a few days ago[1] made me want to try Wayland again. I've tried once a year or so for ages, but it had been a while. So I logged out, switched to Wayland and logged back in.
To my surprise, things looked like they worked. No rendering artifacts like last time, YouTube even played fairly smooth. Sure it wasn't as snappy as Xorg, but hey.
A day later I tried to play some video files from my Samba share on my NAS. I use SMPlayer since it can handle smb:// links. However this time it didn't start playing. I checked the logs, and I could see it complained about not having the correct credentials to the share, NT_SOMETHING_SOMETHING.
So I messed around trying to re-authenticate the share, different users etc. Nothing worked. I could view images just fine, but the videos just wouldn't play.
Looking at the SMPlayer logs I noticed something that struck me as odd. After the NT_SOMETHIG_SOMETHING error, there was mention of a Wayland authentication error...
So I logged back out, selected Xorg, logged back in and boom, video played like nothing had happened.
I'm just a user. I don't wanna dig into why the hell Wayland has anything to do with Samba share authentication. I just want my computer to work.
This October it's the 10 year anniversary of Wayland 1.0... maybe in another 10 it'll actually work for a mere mortal like me.
There is no reason why Wayland would cause Samba authentication errors, now come on.
Blame SMPlayer being buggy, I play videos from smb shares in Wayland and nothing breaks because it's a bloody desktop compositor, not your network stack.
The misinformation surrounding Wayland is just astounding.
I agree that it seems very weird, but as a user all I know is that the exact same steps that works using Xorg does not work using Wayland.
And as a user, that's all I care about.
edit: This time might be SMPlayer, last time was perhaps Firefox, and so on. I've tried Wayland at least once a year for ages, and every single time I have to go back because something is broken.
That issue really could be anything, it could be something you did like putting some credentials in X-specific config files, or it could be SMPlayer looking for some X configuration that isn't there...
As I mentioned, I did reconnect to the share while in Wayland, and I did it as I have in Xorg, using the file explorer. So if that's the issue, it's the file explorer and not SMPlayer. Though SMPlayer logs did mention Wayland and authentication error on the same line... so clearly SMPlayer is doing something different in Wayland.
But sure, it could be anything. All I know is if I select Xorg on the login screen things just work, and when I select Wayland things don't.
>So I messed around trying to re-authenticate the share, different users etc. Nothing worked. I could view images just fine, but the videos just wouldn't play.
>Looking at the SMPlayer logs I noticed something that struck me as odd. After the NT_SOMETHIG_SOMETHING error, there was mention of a Wayland authentication error...
>So I logged back out, selected Xorg, logged back in and boom, video played like nothing had happened.
>I'm just a user. I don't wanna dig into why the hell Wayland has anything to do with Samba share authentication. I just want my computer to work.
A recent upstream Linux kernel update broke certain SMB shares, if you are using Arch (or something else that closely follows upstream), its probably that.
What flicker? Maybe I'm just ignorant of it, but I haven't seen flicker on X11 in years and years and years and years. I've been on Intel graphics for the past 7+ years, so maybe that has something to do with it? And if it does, then that means it's not X11's fault that there's flicker, it's the people who write bad video drivers.
also anecdotal but I had screen tearing issues on virtually every machine until I used Wayland. I don't know whose to blame because I don't understand the specifics of the stacks well enough, but Wayland just straight up solved it. And you can really find pages of complaints about flickering or tearing issue on every linux forum.
I like Wayland, but I avoid using it because (last I checked) a crashing or killed compositor takes the whole desktop down with it. Meanwhile, under X I can restart Gnome Shell (or equivalent) if it's having trouble due to a memory leak or the like. Crashes and memory leaks have been common enough that I don't want to risk losing work to them just for some minor benefits.
This isn't an intrinsic problem with Wayland—I'm just not aware of anyone making a compositor that can recover or restart yet. I'll be excited to try out any that people write.
The design of gtk is to separate the rendering in the GDK layer. Prior versions ran on Win32 without application changes.
That's how you can get it on X11 or Wayland without changing applications. Wayland didn't exist when this design choice was made, but has benefited from that choice. Imo rather than a liability, this is what good design looks like for such a library.
No doubt. But isn't that unrelated to what I said? I was just explaining my grandparent's comment.
To provide the same API for such a broad set of underlying technology, you necessarily have to shoehorn a few things to make them fit. That doesn't make the API bad. It's awesome that applications don't have to do this on their own!
Yes. I've seen it too often be the case that an appropriate layering or abstraction is derided as too much complexity, and that you should replace it with straight calls into the dependency. The former is often a strength, not a weakness!
I'm not even sure how to do anything with Wayland. I have kubuntu and at no point has it suggested Wayland to me.
The stuff from comments about screen capture not working reliably does not inspire much confidence. I remember X11 taking decades to fix rough edges and surely don't want to go over it again.
Much like IPv6, it seems to be real old now, still not adopted and not really working, definitely not hip anymore.
As a daily Wayland user, the only thing that Wayland can't do is networked sessions, and I have never needed that.
> suggested Wayland
Ubuntu slated it for default in 22.04, but reverted due to a bug. I expect them to try again during the next release. If you want to try it then it's typically selected in the login manager.
> don't want to go over it again
Or don't try it, the grandparent comment was talking about "hate" not "disinterest".
I know I get flicker and tearing with X11 sometimes, I notice it. Not every month though. I don't care much about it. I just want that the programs I use work and that I can make my desktop look more or less like I want. (That was a reason for I never used Unity, the fixed and bar at the top of the screen.) If Wayland gives that to me it's OK, if it doesn't I can keep using X11 forever and I don't have incentives to make a test. Maybe when a future upgrade of Ubuntu will give me a simple way to do it. I still have to install 22.04 and I think it's got both Wayland and X11.
>Wayland enables the flicker-free, nicely-animated experience
Of all the things I care about this might be at the very bottom of the list. If that's the best reason people can come up with to give up my DE and decent performance for all the X11 apps I use than I'm sorry but I won't ever be using Wayland.
>Wayland enables the flicker-free, nicely-animated
Did you start using Linux last month? Because I have flicker-free, nicely-animated experience on X for years. Granted it's not experience that everyone has, but it's not fault of X, it's bad drivers or low power hardware. Wayland only brought forced vsync.
GTK4 is actually trash that ruined font rendering because GNOME developers felt so.
I don’t know why you think it is not the fault of X. X doesn’t care about when will a given program render to the screen. Sure, there are hardware solutions to the problem, as well as compositors, but in the latter case X will have no use other than being a bad IPC.
X isn't to blame for screen flicker. That's all Nvidia's fault. Every other video driver on Xorg works correctly. Every other X server works correctly. X is just a collection of protocols and data structures. It can run on top of anything. It isn't to blame for low level hardware issues from poorly implemented drivers.
Most linux software still uses gtk3 and the docs for gtk4 aren't even finished. Hopefully slating this for 5 will give GNOME the decade it needs to realize X11 isn't going away until wayland is actually at feature parity. And I'm fairly confident it still won't be in any one implementation because there'll be dozens of different waylands now and 10 years from now. Just like 10 years in the past.
GNOME doesn't care if wayland is at feature parity. They can require it for GNOME by fiat. They also don't need to care about supporting multiple compositors; they can require all GNOME users to use theirs.
It's not really a "fiat". There just aren't any GNOME developers left that are interested in maintaining the X11 parts of the stack. The Mutter developers are actively working on making the remaining X11 parts optional. Xorg itself is not getting any new extensions, all feature work on display protocols relevant to Mutter is currently happening in Wayland extensions and in Mesa. The major problems left there that involve X are related to XWayland. The GTK developers already redesigned the whole client back end to match Wayland. The other pieces of GNOME have long since moved into protocol-agnostic dbus interfaces. What incentive do they have left to maintain X11 support? There just isn't much there besides legacy compatibility.
Perhaps "fiat" was too loaded of a term. What I mean to say is that, since GNOME is an integrated system, there is no particular need for it to depend on Wayland implementing some random feature that X11 has. On top of that, since so much of Wayland is implemented in the compositor, it's likely that Mutter can make up for any missing features in Wayland.
Therefore, as you say, there's no incentive for the GNOME developers to support X11, and the devs are free to say "Use GNOME on wayland, implement an X11 backend for GNOME/GTK yourself, or don't use GNOME" which, in practice, boils down to "Use GNOME on Wayland, or don't use GNOME" and is, effectively, a fiat to use Wayland if you want to continue using newer versions of GNOME.
I also didn't intend this to be judgemental; GNOME is almost certainly the most complete desktop environment for linux. I personally use KDE as my desktop, but most applications I use are not part of KDE (or even built using Qt). Conversely, a typical desktop user could probably get by using just GNOME applications (plus maybe libre-office for opening MS documents that can't be handled within GNOME). IMO a large part of what makes this possible is by being judicious in what is supported.
>and is, effectively, a fiat to use Wayland if you want to continue using newer versions of GNOME.
Ok, I get what you're saying, but this is not different from looking at GNOME 2 (which only ran on X11) and saying they declared a fiat that you have to use X11. Any project gets to pick its dependencies.
Both of you are concentrating on GNOME DE. GNOME DE doesn't matter. Gtk3/4/5 matters and it, and Gtk using devs writting applications, don't have all the vertical integration and control that the GNOME desktop environment has.
You're not wrong about control of Gtk. But my point was that if GNOME does drop such X11 functionality while the GNOME DE may not suffer, the far more important and larger set of applications that use Gtk will. GNOME DE won't have problems but the Linux ecosystem will.
No, the parent comment is wrong. There is no "vertical integration" or control. It's just an open source project. If anyone was interested in maintaining the X11 support, it would happen, or at minimum it would happen in a fork, but there is currently nobody.
If someone is worrying about other parts suffering, they should start contributing now. I doubt this will happen though, nobody has turned up over the past several years, which is exactly why they consider dropping it. Honestly I think most developers who even bother with GTK4 are probably fully on board with wayland, the ones who aren't are still trying to use GTK2 and GTK3.
After looking at gtk4 recently, I also learned it's pretty crippled in some areas as compared to gtk3. I understand their rationale for this (removing things like GtkPlug/GtkSocket, and making it impossible to implement yourself), but I can't say I agree with it. I've started a couple new gtk3-based projects recently, and I don't think I'd ever migrate them to gtk4.
GtkPlug was a pretty busted API that only ever worked on X11, and even then it didn't totally work right. To make it work on other platforms (or allow users to implement it themselves) would require exposing so many hooks in the toolkit that it's not worth it.
Gnome will continue supporting X apps via xWayland. GTK3 and GTK4 apps will always work on both. Anyone building a new app should not be writing for X at this point (its deprecated) so there is no need for X support in a future toolkit.
If X11 is well and truly on the way out by then, I'll be all for GTK5 dropping X11 support. It doesn't seem like much of the world beyond Gnome is on Wayland but GTK is everywhere. If that remains the case, a Wayland only GTK (that didn't accept X11 patches) would probably result in a massive fork.
I generally use Gnome on my Linux laptop. I often find myself switching it to be Gnome on X rather than Gnome on Wayland. This isn't based on any explicit preference (I genuinely don't care), but I usually encounter some glitchiness that goes away when I take Wayland out of the picture.
It's funny how they made an article about 4 short comments between 2 devs.
People sure like to hate on change. Rather odd for a forum about disruptive startups.
Might be worth thinking about where Wayland was 5 years ago, and where it is now, and where it will be in 5-10 years. That's basically what the conversation was about.
Pretty much agreed. And we should also be projecting Wayland's future on a non-linear basis. Lets of groundwork has gone into it, similar to pipewire, and that will create a tipping point for the project in terms of stability and feature delivery rate.
That's a weird comparison. The first time I heard about pipewire it replaced both pa and Jack for me without sacrificing anything and actually improved everything. And that was before it was picked up by distros. Wayland on the other hand is widely deployed and I still can't always use it for basic use cases like screen sharing.
I'd argue pipewire is a much smaller scope and has had better collaboration from everyone involved. You got in when the distros quite reasonably made the switch on your behalf and it was not an especially difficult call for them. Wayland has a bit more baggage, bad actors in the video hardware/driver territory, etc.
Distros are facing a way harder decision on Wayland to make on your behalf, especially as Wayland starts to support some use cases fully while still not hitting others.
but such comparisons will always have shortcomings.
For what it's worth, screensharing works fine for me. I use it with Zoom and Mattermost (webrtc). Are you on an old version? I'm on 1.18 I think (Debian 11)
Screen-recording is still a bit cringe. The builtin Gnome tool is OK, but a bit clunky. I miss Kazam.
Yeah, el reg sort of prove the maxim "believe nothing you hear and only half of what you see".
Like once I was reading that a product I was an engineer on got a huge contract that I absolutely would have known about and would have been on call for. Remember that a lot of reg stories are banking on the idea that anyone who actually knows better won't break their NDA to inform the public.
This is precisely why I tend to festoon my articles with links, as citations.
In the specialist world of desktop Linux, a lot of the stuff about rival toolkits and display servers is well-known and understood.
For the vast majority of people who work with computers, using Windows or macOS on the desktop and Linux only on servers if that, then this stuff is largely unknown. I try to bridge the gap by providing some context and explanation of what's going on, what it means, what it might lead to and so on.
Actually, from my own personal career history, even people working with Linux on the desktop often don't know much of this stuff. If they know enough to have a preferred distro and desktop, many people look no further.
I won't give Wayland another try until I absolutely have to. And I might even consider going back to Windows before doing so.
Every attempt to do the switch (sometimes forced by bad decisions of distributions) broke essential functionality without any workarounds, so I had to switch back to X11 eventually. I expect this to happen again if I give it another try - be it 1 or 10 years from now.
I've started Wayland up just for fun, to see what it was about, but I've never actually used it. Xfce will probably never port to it (since it'd involve a ground-up rewrite of most components), and I have no desire to switch to a different desktop environment. So as long as X11/Xorg exists and people still continue writing and supporting software for it, I don't think I'd ever switch to Wayland.
But that will be the problem, someday: if Wayland ever becomes the primary windowing system to target on Linux, I would expect some things might disappear. Like maybe Steam for X11 stops being a thing. Maybe Mozilla stops releasing an X11 version of Firefox. That would suck. But I do expect I still have at least another decade before that becomes a concern.
It's been a while. The last thing that was an absolute mess was screen sharing via Google Hangouts/Meet. You could share individual windows just fine, but I had two external displays attached to my notebook and wanted to share a single screen. It wouldn't work. You could only share both screens at once, so it was impossible for others to read anything.
I think external displays in general had problems, but I don't remember many details. I had problems with my docking station under Wayland, scaling options that didn't work. And there was an issue when trying to re-order attached screens with the corresponding Gnome tool.
I think this was on Ubuntu in 2018 or 2019, when they started giving you Wayland by default. But they soon learned that it just wasn't ready yet.
Granted, some of those problems might have been caused by Gnome tools or Ubuntu or maybe even hardware drivers. But all of them were gone immediately once I switched back to X.
X11 Keyboard extension system (which i need for my custom layout) is basically garbage on Wayland; some other extensions that are needed to enable small functions in other aspects (not just screen composition) also don't work or behave poorly outside X11. I really dislike X and i would ditch it in a heartbeat if a good alternative existed.
I tried hard to love Wayland but it's just not there yet. I hope it will be sooner, debugging why my keyboard stopped working because a C header file changed slightly in a semi-unrelated package upgrade is very not fun, and yet that's the best there is.
Strange, that sucks. I guess either you're unlucky with your hardware compatibility or I'm lucky with mine. Hopefully the open nvidia driver programme will bring better compatibility to both our systems!
I don't understand this comment - I have to assume you haven't used it at all (or at least several years).
Multiple external displays works MILES better on wayland - I can set proper scaling ratios set on each screen, which is basically a requirement for a modern laptop with external monitors. No more "This window opened on my laptop screen and will be HUGE on the external monitors because the laptop was scaled for hidpi and the externals aren't". Now the issue is just limited to apps running in x-wayland, and I have close to zero apps that I care about running in x-wayland these days.
Further - I get much more consistent external display output with Wayland. I plug the monitor in and it "just fucking works"tm.
Screen sharing is a pain on basically every modern system - you're letting one application monitor and consume the output on another. Allowing this by default and with no user prompt is a fucking nightmare (and as much as people bitch about "but mah screen sharing!" - there's an equally vocal push from the "but mah system security!" crowd). Wayland struggled here for a bit, but it seems like covid finally pushed the right buttons to get this knocked out in most of the DEs I've used. All the major sharing platforms now seem to work - Slack/Discord/Zoom/Chrome/etc... Including sharing multiple displays now.
So basically - fucking no one thinks this: "But if Wayland folks think that having two external displays and screen sharing is an esoteric workflow"
What gives you the impression they think that? There is quite a lot going on before your google meets displays a popup of what you want to share and the display manager initiating screen sharing.
For what it worth, Wayland has really good externel screen support (mixed-DPI even), so it is likely just a not-yet-supported feature, nothing inherently problematic.
Seems pretty consistent with GNOME dropping valuable features everyone uses... I say this as someone who just switched back to GNOME on Wayland (since 42), but it always seems like they're trying to lose users. At least it seems like a non-goal to grow their base, so it always loses out to any other concerns.
What do you mean? Ctrl-L works and thumbnails kind of work now (I don't know why but only on some images, even of the same type, even form the same roll.)
I don't think so. I think the title is perfectly accurate. I read the issue and it's comments. As I said, this seems very typical for GNOME. We've seen the same kind of thing a lot.
Gtk 2/3/4 programs. Also I think some people are conflating GTK and gnome. Systems can run multiple versions of GTK at the same time, and gnome will still use xwayland for older x-apps.
> Also I think some people are conflating GTK and gnome
Yes and no. The GTK developers have stated that GTK now exists for GNOME. Other non-GNOME uses of GTK work through coincidence, and won't be supported or considered as they evolve the GNOME platform. We can already see this with the removal of several features from GTK4 (that were present in GTK3). GTK5 will just be more of the same, and will leave more non-GNOME people behind.
Sure, apps won't have to move from GTK3 or GTK4 to GTK5, but some will. And will someone step up to fork and maintain GTK3 and/or GTK4 when the GTK developers are focused on GTK5 and don't care about the older versions anymore?
Alternatively, maybe we'll see a new toolkit start to gain prominence. After all, GTK5 is many years away, and GTK5-only apps are even further out. There's plenty of time for something new to take the stage. Maybe a Rust-based toolkit will become popular enough to be considered on similarly-equal footing to GTK and Qt. (Certainly the non-Rust binding story would have to be really good for this to be viable, as I can't imagine all those C, C++, Python, etc. devs who use GTK to all become Rust developers.) That would be my hope, but we'll see. There's a lot of time for this to unfold.
>The GTK developers have stated that GTK now exists for GNOME.
I don't know where you heard this, but it's not at all true. This is actually the complete opposite of what they did in GTK4. A lot of the features that were removed were actually GNOME specific features that were simply moved into libadwaita, the thinking was that anyone building a platform on GTK4 can create their own library and put the themes/widgets they want there. Elementary OS also did exactly this with libgranite. The rest of your comment stems from this false assumption, so I think you can retract it.
I believe I read it in an article quite a few years ago. I'm near 100% certain that's what the article said, though it's possible the author of the article was wrong or was misquoting someone. I don't see a need to retract most of my comment; the second and third paragraphs still hold. I still see little need to migrate to GTK4 (and one of my recent projects simply cannot be built with GTK4 due to features that were removed), and if GTK5 does eventually drop X11 support, I certainly wouldn't bother with it... unless of course somehow X11 actually disappears.
The libadwaita stuff is also super weird and IMO implemented poorly, and in a way that basically says "if you aren't using GNOME we don't care about you". Want to run an app that uses libadwaita outside of GNOME? Sure, but expect it to look completely out of place since it won't use your desktop theme.
>and one of my recent projects simply cannot be built with GTK4 due to features that were removed
Yes, they also deprecated/removed some features that were just broken or not so useful. That's not a GNOME issue.
>the second and third paragraphs still hold
This is just my prediction from looking at some of the existing Rust libraries: There will not be any viable toolkit for general use written in pure Rust. To do so would require a giant investment. If it ever happened, any interested party would want it to be cross-platform because Rust is primarily used as a cross-platform language. And because of that, at best it would become a poor approximation of Qt without any of the benefits. The closest I could ever see conceivably happening would be some WASM-based thing that you can then deploy inside Electron. And I say this as someone who rather dislikes C++ and (in theory) prefers Rust.
>and if GTK5 does eventually drop X11 support, I certainly wouldn't bother with it... unless of course somehow X11 actually disappears.
I don't know why you wouldn't bother with it. The code will probably not ever completely disappear, but X11 itself has already been obsolete for a number of years.
>Want to run an app that uses libadwaita outside of GNOME? Sure, but expect it to look completely out of place since it won't use your desktop theme.
I don't see how this is even a problem. The point of the GNOME app is to follow the GNOME HIG and design patterns. The point of libadwaita is to provide prefab implementations of the GNOME HIG. You can't make an app that follows two design styles at the same time. Like, think about this. Motif or KDE apps also don't look anything like GNOME apps and they look out of place. Windows apps also look completely out of place on GNOME if you run them in Wine, etc. On an open platform nobody can enforce a certain look for any applications. Eventually they will all look weird and out of place somewhere.
Every year I read a comment saying Wayland is standard, I try to switch to it and always regret. Literally most day to day functionality doesn't work, electron only recently added screen capture ability, and that's only for current window, not full screenshare or another window, so pair programming is pain, running Java or C# desktop programs is pain or impossible due to scaling issues. Vulkan/OpenGL programs can crash after restoring from minimised state... Switching from multiscreen(docked) to single screen(laptop) doesn't restore windows in their position, oh even dragging windows between monitors doesn't work well as the window on a new screen is different size, eg. just the top bar with the window content gone until minimized and maximized again
Screen sharing is still a awful yeah. It either just works or you’re into a world of pain with user level systemd units that log nothing useful or nothing at all, dependencies that you have to somehow know to install with no instructions, arcane program arguments and env vars that mean hacking desktop files or shell scripts for things that are otherwise straightforward and then random breakages with upgrades.
I still class it as "bleeding edge". In another five years I doubt it'll be in a state that'd make me recommend it as the most sensible default. Maybe, maybe by the end of the decade.
>Is there any combination of these various X11, Wayland, Gnome etc. things that "just work"
that's pretty much what the latest Ubuntu LTS or Fedora release is. And I think most people are using it, but they're just silent about it. I think the linux community just has some uniquely vocal folks on the other end.
I think a large portion if not the majority of the Linux community is just one that prefers choice and customizability over being given whatever that "just works", but not exactly to one's preference. Loss of choice is a loss. For example, there may be users that use WMs like Blackbox, StumpWM, or Xmonad that they've heavily customized throughout many years, and now they're essentially being told that their setups will eventually be incompatible with the changing ecosystem. i3 users got lucky for getting a port (sway), but there are lots of other WMs, and lots of other related tools useful for customization like xdotool, perhaps not all portable to Wayland.
> For example, there may be users that use WMs like Blackbox, StumpWM, or Xmonad that they've heavily customized throughout many years, and now they're essentially being told that their setups will eventually be incompatible with the changing ecosystem.
Yes. You got a wonderful set of tools as a result of all the work and time folks put into X.
The problem is that the folks doing most of the lifting in this space right now, the ones still giving their free time and effort, have decided that they'd rather be developing Wayland (it's not all of them, X is still kicking, but it's a lot of them).
You, as a user of the free software produced by real people putting in time and effort, absolutely don't get to bitch about "Loss of choice is a loss" when what you're really saying is "I'd like to force the people working on wayland to continue working on X, because it's beneficial to me".
The opposite of XWayland (a Wayland server that outputs to X11 windows) will be much easier to implement than XWayland itself and won't require integration in window manager, so that won't even be as disruptive as it sounds.
And this is why Desktop Linux is a running joke with devs fighting with each other's solutions to a re-implementation of an old problem and they still can't do it right to the level of desktops like Windows, and macOS.
The fragmentation and alternatives of alternatives mess of the Linux Desktop has turned it into a giant contraption full of inconsistency and tons of unnecessary in-fighting between a bunch of devs due to UNIX philosophy or a desktop that simply just works.
It is not early days anymore and it has been over 20 years and the Linux Desktop still has the same problems already present today and is a solution in search of an (already solved) problem at this point.
No wonder that explains why Google was so fed up with desktop Linux they decided to replace it with their own OS (Fuchsia).
The Unix philosophy has very little to do with desktop fragmentation and everything to do with the fact that unlike macos and windows: it's not that commercial an endeavor. A common employer is a main reason many work on someone else's ideas when they can just work on their own ideas.
Even when there are commercialization efforts: investment and adoption circular. The challenges are much much bigger than just the desktop fragmentation.
See: ChromeOS. Investment can solve these problems.
Similarly, Fuchsia is a much bigger effort about the future of operating systems and not about just desktop environment quirkiness. Again, they have ChromeOS for that.
Don't get me wrong, I agree this all hurts Linux adoption, and as a user I wish it were different.
Everything I said is the brutal, hard, evergreen truth.
> The Unix philosophy has very little to do with desktop fragmentation and everything to do with the fact that unlike macos and windows: it's not that commercial an endeavor. A common employer is a main reason many work on someone else's ideas when they can just work on their own ideas.
It is part of the in-fighting, which contributes to the whole desktop fragmentation issues, distro forks and chaos around it and its frankly an unsolvable disaster.
The whole debating between system components such as systemd vs init.d, X11 vs Wayland, Pulseaudio vs Portaudio vs Pipewire have further contributed to the alternatives of alternatives desktop fragmentation and it is a tug of war between UNIX philosophy greybeards and other devs attempting to solve the fragmentation for years. Due to this failure of consensus: No app developer can 'define Linux support' and cater to all desktop Linux users 100% of the time, unlike Windows, and macOS.
> See: ChromeOS. Investment can solve these problems.
Only for Google. They already have learned from the mistakes of these distros and are going to replace it with Fuchsia. ChromeOS is still a mostly closed-source system despite using a Linux kernel, just exactly like Android still is, which isn't the same thing as the chaos you see in many open-source full Linux distros.
> Similarly, Fuchsia is a much bigger effort about the future of operating systems and not about just desktop environment quirkiness. Again, they have ChromeOS for that.
Hence why Google is replacing ChromeOS with Fuchsia, which includes and avoids all of the above.
> Everything I said is the brutal, hard, evergreen truth.
Hey, I'm not here defending any of the desktop chaos or waving the whole: "but atleast choice is good!" flag. I just disagree with your attribution of everything to "the unix philosophy" and then snowballing that into Fuchsia.
I just think convergence is the exception not the norm for FOSS and this was more true before then now. That's less about "the unix philosophy" and more that only companies come with referees who pay you to converge and polish.
I don't think the problem is the Unix philosophy, which has to do with building focused components ("do one thing only and do it well") that are interoperable with each other (e.g., Unix pipes). While it's hard to apply Unix pipes to GUIs, component-based GUIs have been explored (e.g., Smalltalk environments where everything is an object and thus composability is built-in, Plan 9 [the acme editor is a great example of how an IDE can be composed from smaller programs], OpenDoc, Microsoft's OLE, COM, and ActiveX technologies, and even KParts and Bonobo in KDE and GNOME, respectively).
I think the problems with the Linux desktop are as follows:
1. Think of the sheer size of modern desktops. Think of the large amounts of code that are in the Xorg, GNOME, and KDE code bases. Building a large desktop system that is as feature complete as Windows or macOS will take millions of lines of code when developed using conventional programming languages and tools. This is not a single programmer's weekend project. Even a small team of programmers will need a considerable amount of time building something usable.
A counterargument to this, though, is the STEPS project by Alan Kay's Viewpoints Research Institute (http://worrydream.com/refs/Kay%20-%20STEPS%202012%20Progress...). The researchers were able to implement an entire desktop operating system in just 20,000 lines of code. Perhaps by using the lessons drawn from STEPS it may be possible for one programmer or a small team of programmers to build a high-quality Linux desktop in a short amount of time. In fact, reducing the size and complexity of Linux desktops may lead to a better situation for Linux desktop users.
2. It is difficult to impose a singular vision on something as large and complex as a desktop using bazaar-style development patterns. It's one thing to build a clone of Unix this way; Unix's userland is a collection of disparate tools anyway, and Unix was already a well-studied design by the time the GNU project started. It's another thing, however, to build a brand new environment in this manner. It's no wonder that the best desktop ever to be built on top of Unix, NeXTSTEP and its descendants, was a commercial project led by Steve Jobs.
3. Big software projects require large amounts of resources. Windows and macOS has these resources. The server-side open source ecosystem has many well-funded projects, including the Linux kernel itself. But GNOME and KDE never had this level of investment. This is true of application software as well. Consider the resources devoted to the development of Microsoft Office and the Adobe Creative Suite, and compare that to LibreOffice, the GIMP, and Inkscape. On the flipside, consider how GNU/Linux (the Linux kernel + GNU utilities) successfully competed against proprietary Unices, to the point that some users of proprietary Unix systems downloaded GNU tools because they liked them better than the tools that came with the system. I believe this is one of the key benefits of small, composable tools.
4. Fragmentation may hurt adoption. On one hand more choice theoretically means that it's easier for users to choose a desktop that best fits their needs. On the other hand, fragmentation in an environment where resources are already scarce means sifting through an ecosystem of half-baked, incomplete desktops instead of having fewer but complete desktops. In addition, developers have to decide which technologies to target. If I'm using an existing toolkit, do I pick Qt, GTK, or something else like Electron? Do I target Wayland or X11?
5. In my opinion, churn has also hurt adoption. Sometimes churn is necessary, but this doesn't minimize the disruption for both users and programmers. I still remember the KDE 3 -> KDE 4 and the GNOME 2 -> GNOME 3 transitions and how disruptive they were. I also felt they harmed adoption at a critical time for the Linux desktop. By comparison, Microsoft has bent over backwards to preserve backwards compatibility. Apple is more willing to make disruptive changes, but these disruptive changes usually have a clear benefit (for example, the transition from Mac OS 9 to Mac OS X with all of the modern features the latter had), and Apple tries hard to minimize the impact of these disruptions for both users and programmers.
I think the solution to this problem is for the community to adapt to the realities of open source software development with its constrained resources compared to commercial development, and build small, composable software tools that don't require large armies of developers to maintain, preferably in high-level programming languages or even (taking a page from STEPS) domain-specific languages. No one desktop is going to satisfy all users, but smaller, more modular tools are easier to deal with than large monoliths. "If you don't like it, change the code; it's open source" isn't much of a solution when you're staring down hundreds of thousands of lines of C++, but if the desktop were something more akin to Squeak Smalltalk, it would be easier to change it to fit one's liking, even without express support for customization.
I really want to see Wayland move forward and succeed, but there are so few companies injecting money on it, they get to dictate how things move. Red Hat is one of the main contributors, and they only seem to care about Gnome working on Wayland (as much as I don't like their direction, I can't really blame them for following it, it just sucks that I don't like the product they're developing). The landscape is extremely fragmented and everybody who is not on the Gnome garden will suffer a lot.
I really wish some other non-Gnome-favoring company would find a reason to dump a lot more money into Wayland and help move it forward in the not-only-gnome-favorable path. This is not a thing that will move forward without full-time workers. X has always had a lot of paid people contributing to it.
That is, if IBM doesn't decide to throw a bigger wrench at the problem.