On Abandoning the X Server
ajaxnwnk.blogspot.com
ajaxnwnk.blogspot.com
"at the moment there are several types of applications that not only don't work in wayland, but would be very difficult, or impossible to work natively in all major wayland compositors.
Examples (in order of importance to me):
* Programmatic output configuration (xrandr, arandr, etc.)
* CLI clipboard access (xsel, xclip)
* Third party app launcher/window switcher (rofi, dmenu, albert, docky).
* Clipboard managers (parcellite, klipper, Gpaste, clipman, etc.)
* Third party screen shot/capture/share (shutter, OBS, ffmpeg, import, peek, scrot, VNC, etc.)
* Color picker (gpick, gcolor3, kcolorchooser)
* xdotool
[1] - https://old.reddit.com/r/wayland/comments/85q78y/why_im_not_...
https://github.com/swaywm/sway/wiki/i3-Migration-Guide#commo...
This whole "desktop stack" on Linux always makes my head hurt, so these might be really dumb questions:
If I install some distro, Arch say, and I wanted to use Sway, and I then want to run Kile, will Kile then run through XWayland? Will it work just as well as Kile on KDE Neon?
I understand KWin has some Wayland support but it also seems not quite ready for prime time the times I've tried it. So was curious about alternatives, just for curiosities sake.
Kile seems to use Qt5, so should work without Xwayland.
> Will it work just as well as Kile on KDE Neon?
It should, yes. I don't use Kile though, so I haven't checked.
Since Kile is a KDE application it should run using Qts wayland backend.
> Will it work just as well as Kile on KDE Neon?
Depends, do you need anything more fancy than mouse and keyboard? No? Then great.
Power user functionality like copy paste on the other hand? https://github.com/swaywm/sway/issues/4007 might want to pray before using that.
Come on.
Congratulations, you've found the only opened bug report about clipboard on Sway/wlroots. It's triggered by edge cases (X11 client hanging + fcitx apparently), and most of it has been fixed already.
Are you really trying to convince people that the clipboard is broken on Wayland with this? Maybe you could start by actually trying Wayland.
ydotool is listed there as an equivalent of xdotool, but ydotool has only a tiny fraction of the features of xdotool.
And it's unlikely that it'll get much better any time soon, as its README says:
"Since Jun, 2019, I have little time to maintain this project"
wtype is listed as another equivalent to xdotool, but it has even less features than ydotool.
If the rest of the X equivalents on that list are as feature poor as these, I don't hold out much hope for Wayland in the near future.
You're here complaining that a maintainer isn't around to add features in a thread that's literally a major maintainer of X server telling you he's not going to work to maintain the project anymore.
---
Here's my take on your position - I absolutely agree that if you have processes and tooling in place that you currently depend on, and can't replace, you should stick with X.
That said - As a way to manage input and output on my system (MY system, with my preferences and my requirements) I've found Wayland to be a delightfully better experience than X.
So to come back at your list of requirements, mine looks like
- Multimonitor support, including mixed scaling ratios
- Touchpad input with gestures, approximately in line with the experience on OSX
- A sane "default" that does not constantly require that I manually edit settings or xconf files on EVERY system I touch
- No screen tearing or flickering. Seriously - NO!
---
The difference between the two lists, is that I believe Wayland can eventually replace the tools you need. I no longer have any faith that X will be able to solve my requirements. Wayland does.
I... think you already understand why this is a disingenuous argument, but I'll explain anyway:
The difference is, for most folks, X works, right now, today, while its maintainership is in question. For example, of the four items you listed, none of them particularly matter to me.
ydotool, as an example, doesn't work and it's not maintained.
Does that make sense?
> I believe Wayland can eventually replace the tools you need
Alright, well, ten years from now we should revisit this conversation!
Unfortunately, at this point, the Wayland ecosystem is looking a bit like Zeno's Paradox...
It also takes a hell of a lot more configuration to reach that state.
It's also not maintained.
So no disrespect, but it really sounds like your argument has boiled down to "I won't acknowledge issues unless they personally impact me and my daily workflow".
Now - I'm fine with that when you're making an argument for the machine you should use personally (hell, I agree with you, if X works and you like, rock on). But that's a pretty disingenuous take to make while discussing the merits of the platform with other folks.
None of those issues actually make X unusable. And I say that while writing this on an X1 Carbon running Debian testing using X in a multi-monitor setup (and yes, this is a totally plug-and-play setup with zero monkeying around in config files... a fact that, frankly, amazes me, having grown up hacking X modelines).
Wayland, by contrast, is literally unusable (as in, it lacks fundamental features that make it something people can't use) in many circumstances due to either compositor bugs, features that don't work by design, or features that don't work due to a lack of solutions or a lack of adoption of those solutions.
And I know this because I've tried to use it. I really like the possibilities it opens up.
But it's so far from mature, at this point, that it simply cannot act as an X replacement for most people.
Frankly, I'm a little shocked distros are making Wayland their default display server ecosystem, as it's an objective step backward for desktop Linux and I expect will scare a lot of neophytes away who wonder why the hell basic features like screensharing still don't yet work in their favourite application.
> Frankly, I'm a little shocked distros are making Wayland their default display server ecosystem
They're making it the default because it work better for most people.
You may not be most people, but I can at least concede that X is probably still the right choice for you.
You seem to be unable to have a good faith conversation about the merits of Wayland.
Actually, we haven't talked about the merits, yet!
Unfortunately, when I was playing around with Wayland, I struggled a bit to find the benefits that would make it so irresistible that I'd put up with the downsides.
Tear-free? Eh, I have that with X thanks to Intel's drivers. Though I absolutely understand that's not a universal experience.
Different display DPIs? Anything that falls back to Xwayland (which unfortunately is still a lot of applications) look like blurry garbage for obvious reasons, which means it's actually unusable in a lot of circumstances. And that's assuming solid application-level support (I seem to recall Firefox had mixed DPI regressions that were recently resolved, but that's only a vague recollection).
TBH, I was really really rooting for this feature as it could be really nice, and I was deeply disappointed when it didn't work out.
Touchpad gestures? Okay, legit these are really nice! Three-finger workspace switching in Gnome is pretty slick. OTOH, the lack of that feature isn't a dealbreaker, either.
General touchpad improvements? Funny thing is, libinput is being backported into Xorg, which means that you can get a lot of those benefits without switching. For example, I'm using Firefox with libinput2 and it's a fantastic improvement!
Honestly, I'd love a killer feature that'd push me to Wayland and cause me to put up with all the functional regressions. But I simply haven't found one... :(
So, at this point, I'm waiting for the regressions to be resolved. Hopefully we'll get global hotkeys, broadly supported screencasting, better application-level support for things like mixed DPI, and lots of bug fixes so I can finally make the switch!
I can say that 4 years ago I was firmly in the "it isn't ready" camp.
2 years ago, touchpad support was my "killer feature" (I'm left handed and have issues with RSI in my right wrist).
Global hotkeys work pretty much everywhere I've tried in the last year or so (including being able to configure global hotkeys in an electron app I have to maintain for work, which was a nice plus). I also actually tend to like that they're centralized and apps aren't able to just stomp all over the configured hotkeys.
Screencasting is still a pain point, but I actually appreciate the security model that makes it painful, and pipewire is functional enough that I can pretty easily share a screen on anything that can run in a browser (Zoom, Discord, Hangouts - Slack is still a pain).
I don't have issues with XWayland being blurry - although I do have issues with Xwayland windows having the same scaling restrictions as X (If you move a window from a scaled screen to a non-scaled screen, it won't re-adjust). Fortunately, most of my daily apps are now Wayland native, including my editor, my terminal, and my browser (Chromium build with ozone enabled).
---
Now, all that said, if you've tried recently and it's still not there, I absolutely get it. But I think it'll move faster than you expect. 4 years ago I certainly wouldn't have believed you if you'd told me I'd like Wayland enough to bother writing out this whole comment chain :D
Unfortunately I tried it... I'd estimate two months ago (I switched back to Debian testing from Ubuntu a couple of months back and decided to give Wayland a shot now that it's the default).
To be clear you mean that can in your config file or settings menu bind a hotkey to run a particular action if and only if that action can be specified by a particular command line operation.
This is indeed my preferred way to specify such things I like that it is centrally managed and if the application developer lets you interact with the program that way it is quite powerful.
Is this possible on gnome wayland or just under sway?
There is another form of global hotkey configuration wherein the app lets you specify a global command for an operation that may be internally specified and may not be provided via a cli interface and this functionality will never work by design.
[1] https://help.gnome.org/users/gnome-help/stable/keyboard-shor...
My touchpads work very well with X, out of the box (any Ubuntu I used.) HP ZBook 15 from 2014 and a HP nc8430 from 2006.
> Nor does it work on a laptop with a resolution that requires scaling (at least not the second you plug in another display).
I can't comment on this. The few times I added another display it wasn't larger than the usual 1920x1080 px.
The difference is that a huge number of essential features both exist and actually work in X, but not in Wayland.
That particular X developer might have abandoned X, but X itself is still here, still works, and still does what I need. Can't say the same about Wayland, yet...
Actually, that's exactly one of the major reasons put forth for switching to Wayland. The very comment you replied to quotes it:
>>> a major maintainer of X server telling you he's not going to work to maintain the project anymore
If the project ends up truly unmaintained, it really would end up disappearing from the face of the earth as the platform under it (the hardware, the kernel, etc.) changes to the point that it becomes non-functional.
You don't want people to use a new thing because it might siphon off resource you're benefitting from now?
If you love X, go work on it, or pay people to. Otherwise... what possible point are you trying to make?
Did I express any want in my comment? I didn't even say anything about my preferences. I wonder if perhaps you replied to the wrong comment?
> what possible point are you trying to make?
To correct emersion about Wayland being an option. Do you think what I said was incorrect?
I’ve seen this happen multiple times with replacement systems: as long as people can escape back to the old system the new one remains rough around the edges, but once the old one is turned off the new system rapidly improves to production level quality.
The problem is that they can't be fixed, as I understand. People are asking for things that some see as features and others see as bugs.
The only way to keep everyone happy is for both to continue co-existing, but unless something changes, it doesn't seem like that's going to happen.
The kernel has a pretty strong backwards-compatibility stance, so you'd need to wait a long time.
Nobody stops you from running an outdated and insecure distribution to use X11 (in this hypothetical future). Nobody stops you from patching X11 to support newer interfaces.
If you want to stick with X11, you can. Nobody urges you to upgrade.
No, sorry. X11 clients are eternal, there's just way too many of them out there that are line-of-business and will never be ported to anything else. So I'm always going to need some solution to make those apps work, and since for the foreseeable future that probably means "run a nested X server that translates things to the native display server's API", that means Xwayland isn't going away any time soon, and if/when it does it'll be replaced by some other translation layer I'll need to support.
The X development community has decided, almost unanimously, that Wayland is the way forward. More powerful and knowledgeable forces than you have cast this die for you. It is now upon you to either adjust, or step up and contribute where Wayland is lacking.
I'd like to use Wayland. But there's no replacement to my bspwm+picom setup that works with a little configuration. Tough luck, guess I won't be using Wayland for now.
This is NOT a hypothetical. Projects have dropped ALSA support and adopted a policy of PulseAudio or GTFO -- and ALSA has more commitment to its long-term maintenance than Xorg now does. And I suspect the next phase will be Wayland maintainers putting pressure on toolkits to drop X support, much like Lennart pressured the GNOME community to hard-depend on systemd.
Lets keep them separate. I have no PulseAudio, solved Skype with apulse, though I don't use much media except browser, player and tuner.
When about do you think firefox will no longer build for X?
Python 3 was ready in 2008 but 2 will be supported by RHEL until at least 2024 16 years later. I will be surprised if in 2030 I can't simply pick distro with X and fire up firefox.
When about do you think firefox will no longer build for X?
Python 3 was ready in 2008 but 2 will be supported by RHEL until at least 2024 16 years later. I will be surprised if in 2030 I can't simply pick distro with X and fire up firefox. Its kind of silly to expect users who are disinterested in using foo to pitch in to make foo acceptable when said users really want bar because you tell them that bar is now the standard "get over it".
Firefox? 2025 at the latest. Firefox was the project that deprecated ALSA a few years back. Now that all major distros ship with Wayland as the default, it's time to assume Wayland and not assume X. Eventually X support will become burdensome, and be removed.
The majority of users are still using x11 which is why for example Firefox just added hardware decoding under X last month. Optimistically for wayland this might change between 2024-26 at which point application developers can stop supporting it at which point people who are so inclined can provide an x11 build of Firefox in 2026-2028 which are liable to work through 2030.
In a less optimal world we are still in step one in 2030.
Anyone who thinks X is going anywhere this decade is dreaming.
Ahh, classic: blame the user.
You are wrong for expecting things to work in a way that's familiar!
Global hotkey bindings? Sure, that works on Windows, macOS, and X, but it doesn't on Wayland and its your fault for expecting it.
The beatings will continue until morale improves!
> As an end-user you can continue to use what works for you.
LOL, Wayland is literally being marketed as the replacement for X. It's even the default display server in Debian, Ubuntu, and (I think?) Fedora.
Why are you surprised that people therefore expect stuff that works in X to work in Wayland?
Re global hotkey bindings: Can you please describe your setup to me? I honestly have no idea what you're talking about, global hotkeys were supported in all the Wayland implementations I tried recently. (KDE, GNOME, Sway, Wayfire)
I understand that's not your intention, but that's effectively what you're doing.
I'm a former developer who moved into product management a long time ago, and I've seen the syndrome.
"I understand what you want, but we didn't build it that way, so you need to change your expectations" places the onus on the user to change their behaviour, instead of on the developer to build the thing the user actually wants.
> X is still included on those distros as a fallback option in case you have something that doesn't work.
The trouble is, a neophyte will a) have no idea what the difference is between Wayland and Xorg, and b) not realize that switching might fix whatever issue they're encountering.
And BTW, this all presumes that a distro installs Xorg at all. If not, you've gotta dive into the package manager, which adds an additional barrier since you need to know what to look for and install.
> Re global hotkey bindings: Can you please describe your setup to me? I honestly have no idea what you're talking about, global hotkeys were supported in all the Wayland implementations I tried recently. (KDE, GNOME, Sway, Wayfire)
It certainly doesn't.
Two examples that immediately spring to mind:
Guake, a handy pop-up terminal. In X I can press F12 anywhere and it opens. Super handy for quick terminal interactions, always-on commandline tools, etc.
Gnome Do or equivalent. Basically Quicksilver for Linux. Fast search, command execution, etc, from the keyboard. Hit a hotkey and it pops up.
Right now the way this works is that the compositor binds the key and then... does stuff. But that requires these applications to be redesigned to support that. For example, guake added a whole separate binary, 'guake-toggle', and it's only job is to toggle visibility.
Unfortunately, that requires the user to know that they need to go into their compositor settings, bind the key, and set it to run that application.
Meanwhile, on literally any other OS, this would be handled with a config setting right in the application.
Maybe eventually be addressed with yet-another-dbus-protocol, but right now it's just a gaping functional regression.
But they're definitely clever enough to be using xdotool. Lol.
Wayland may not fit with everyone, which is fine, no one is taking X away from you. But allow the vast majority of users to have their scaling displays and multiple monitor setups, which is far more common than your requirements. I'm sorry Wayland hasn't come far enough yet to cover you as well, but it's far enough for the vast majority of users. You bring up xdotool in everything thread as if it's something that Grandma uses Linux for. It's not.
> And BTW, this all presumes that a distro installs Xorg at all. If not, you've gotta dive into the package manager, which adds an additional barrier since you need to know what to look for and install.
So be honest what you're arguing for. You, as an accomplished unix user, want distro defaults to be tailored to your use case. That's not what distro defaults are there for.
That seems distinctly anti-grandma.
What kind of global hotkeys are we talking about that casual everyday users need, as opposed to people who build their own desktop OS from parts?
We all tried the universal frictionless global hotkeys thing. It was a really bad idea for a general audience [1]. That's why we have MPRIS for global media player controls (Firefox supports it now, which is awesome!), and stuff like the keyboard shortcut inhibit protocol for VMs and the like. It's unfortunate for the building an OS from parts thing, but unlike cars and smartphones, at least it is still all open source.
Interesting, I just noticed MacOS allows normally global keybindings to be overridden by applications that really want to override them.
So for example, doing Command-Tab in the VNC viewer will tab through applications on the VNC server you're connected to, which makes sense because you feel like you're using that other desktop. But everywhere else, Command-Tab is intercepted by the window manager and tabs through the local applications.
Same for other hotkeys that are usually universal, like the one that takes screenshots and screen recordings (which are both done really nicely in MacOS by the way), or the one that lets you search for anything.
It's not that. It's that global hotkey bindings are out of scope for a Wayland compositor. But don't worry. An API for such things for the crufty d-bus broker should be dropping aaaaaaany minute now... then all you have to do is wait for your compositor to support it!
This entire post is about Xorg becoming abandonware. People are expressing why they're not willing to switch to Wayland, citing lack of features they use.
> As an end-user you can continue to use what works for you.
Until Xorg becomes unmaintained and eventually breaks. Wayland is not being put forth as an option. The idea is that X will eventually be unsupported.
Besides, realistically speaking, not everyone is capable enough to do that. Their only way to contribute is to let the web know that not everyone prefers Wayland and why. Discussions like these are like feature requests and bug reports, only broader, encompassing multiple projects. Some people might interpret that as entitled b____ing, but then apparently so are feature requests and bug reports sometimes.
The right call would be kickstarter, patreon, any kind of sponsorship.
I would appreciate it if you could quote the article where it expounds on the cost.
I've read through it a few times, and could only find two very brief, vague, handwavy complaints against X:
1 - "the code happens to implement an unfortunate specification"
2 - "You can only apply so much thrust to the pig before you question why you're trying to make it fly at all."
As an end-user, I don't find these to be particularly convincing.
Moreover, X works for me now and does everything I need.
>But using it to drive your display hardware and multiplex your input devices is choosing to make your life worse.
If X continues to work for you and you don't find it makes your life worse, then... keep using it?
https://www.youtube.com/watch?v=GWQh_DmDLKQ
And directly from ajaxnwnk
https://news.ycombinator.com/item?id=24925189
> Moreover, X works for me now and does everything I need.
Someone makes pig fly all these years.
Yikes! So just more fragmentation and half-baked alternatives.
Because Wayland pushes so much logic into the compositor, there's now the very real likelihood that things will work on Gnome but not KDE, or work in i3 but not Gnome.
[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols
And in my opinion the whole isolation and security concept is hot garbage. It hinders so many useful things. My Linux desktop is not a smartphone where I download random, badly screened closed source apps from a play store. I'm downloading open source tools via my distro's package manager. If one of these got backdoored, Wayland preventing it from taking a screenshot of another Wayland app won't exactly save the day anyways.
Instead we're now getting clumsy, overly complicated solutions for all these simple use cases. Ultimately I don't care. If people enjoy creating these needlessly complicated monstrosities, fine. It's just that we need to wait ten times as long until we get something usable that way. I guess X needs to keep chugging along a couple more years....
You're forgetting all of the untrusted Javascript (and soon Webassembly) most people are running through their web browser.
That seems to be one of the biggest security holes Wayland is designed to plug (to some extent).
Likely at least a decade (Lindy effect).
From the article, about X:
> But using it to drive your display hardware and multiplex your input devices is choosing to make your life worse.
This is a weird conflation of this developer's experience after being burned out on development, and the user's experience running a modern distro.
If as I user I confuse those two things, then I'm going to click the button to choose Wayland when I log in. And I guarantee you my experience as a user will be worse on Ubuntu, Debian, and probably any other modern distro by making that choice.
I can work around that worse user experience by choosing alternative to what doesn't work, but that's a separate issue from the default UX under Wayland making my life easier.
Case in point: Gnome + Wayland + guake. If you configure guake to use anything less than 100% of the width of the screen, then it suddenly appears in the wrong position.
But wait, maybe that's a guake bug, right?
Wrong. I tried a couple of other options for similar functionality and they demonstrated the same issue. So odds are it's actually a bug in the compositor.
And that's ignoring that basic things like global keybinding don't work (edit: ya ya, the Wayland proponents will tell you that's by design, but it's a) user hateful b) totally different than literally any other desktop OS out there today, and c) breaks apps, right now, in ways that will require major code changes to fix) so I have to put a hack in place to allow F12 to open guake up in the first place.
Meanwhile, we only just got the "official" solution for screensharing (what Zoom does is an incredible hack: they just take lots of screenshots! No, I'm not kidding, that's actually how it works, which is why the framerate is so bad) and it involves yet more new stuff (pipewire, et al) that I'm sure will be a source of its own raft of bugs.
I'd say "maybe in a year or two", but we've been saying that for a long time, now...
The hotkey thing is big and it's annoying because it's another thing that might need to be implemented/fixed in each and every composer and environment (and it could be different in every environment).
I've seen the X11/Wayland talks and I agree Xorg has tons of old crufty garbage in it, and screen locking in Xorg is not very secure. But the Wayland team seems to have made little effort in addressing even the most basic things like hotkeys, screenshots, etc.
I'm not sure if "user hateful" is the right term, but they don't seem to be prioritizing the most basic things people are asking for.
I'm glad they're leaving all the "desktop" stuff out and letting desktops agree on dbus interfaces. I doubt people writing little CLI utilities want to have to create dummy Wayland surfaces to do interact with the display server which is how wl-clipboard works.
Now the compositor/screen manager isn’t doing that anymore because it never should have and it was a terrible division or responsibility in the first place. But we have devs pushing forward on multiple different fronts with different DEs and development is painfully slow.
- Handle rendering things to screen
- Handle user input
My issue is that while X has a LOT of other things it also happens to do, it just doesn't do those two primary things very well on modern hardware.
As an aside -
This reminds me of the systemd arguments all over again, but the same crowd that was ready to crucify systemd for all the things it does are now bemoaning all the things Wayland doesn't do.
But really, I think there are just a lot of folks who aren't willing to try something new, or to re-evaluate some of the toolchains they've made for themselves.
Now - I'm not going to blame them for that, having a working system change under you isn't fun, and it eats up time and resources some people don't have. But it also doesn't stop the new thing from replacing the old thing.
Particularly if the new things happens to be genuinely better in many respects.
And while I can certainly understand the pain point of missing features in Wayland, The way it gets user input and display output right are just delightful.
So delightful that I actually prefer it to my work macbook, which is not something I could ever say about X.
It might not be the same crowd. There are many crowds on Hacker News, and the voting mechanism tends to select for whichever crowd is angry at any given time.
Which is, like, super frustrating. I want to feel like I have a relationship with the people I'm talking to, but I don't really. It's always different people, and they're not consistent with each other.
I almost wrote out an aside in the above comment, because the person I was replying to certainly didn't mention systemd.
I do think there are some interesting echoes between the two conversations, though. Namely that the "angry" that happens to be getting selected for has nothing to do with the merits of either piece of software, and a lot more to do with the fear of having to learn something new to replace something familiar.
What, you don't think people have legitimate criticisms of Systemd, or Wayland?
But fair criticisms aren't really the comments I tend to see in these threads. Instead I see fear/resentment/anger expressed in the form of "How dare you choose to use X, when it doesn't solve my problem Z? Good ol' Y never lets me down on Z, you should just keep using that. And no, I don't care that you have problems A, B, and C with Y".
Which... looking back at that sentence... I sure used a lot of letters, but I think it captures the point.
Systemd does offer some nice functionality, but in return it makes certain unreasonable demands (.ini files everywhere, binary logs, systemd-{resolved,homedir,consoled,all-the-things}. Wayland does offer some nice functionality, but it is not ready for prime time yet. It is nowhere near ready for prime time yet. It cannot replace X11, because it utterly fails to replace key X11 functionality today.
Next year, or the year after, it might be different. It probably will be. I genuinely look forward to adopting Wayland when it upgrades X11. But I would utterly resent being forced to use it today, and I am very worried that I may soon be.
Imagine world where there is no Wayland, how is it better? I fail to understand who forces you. Maybe default choice of distribution? Or that people don't want to maintain X.Org?
People maintained other init systems in Arch Linux, they are gone now. Too much work probably? People created Duvian [1]. If systemd is such an awful choice it should be amazingly popular.
You answered your own question. It starts with distros defaulting to Wayland, despite it completely missing features I currently rely on in X11. No big deal, I can always manually switch to X. It's only a small pain! Then more and more software starts being Wayland-only, because most people are using it by default. Not a huge deal, I can stick to older versions of software. Then drivers are only released for Wayland, because at this point the only people left running X are me and a few other folks like me. Meanwhile, the features I consider absolutely necessary are still missing, because the primary source of funding is no longer hobbyists but corporate vendors.
I have seen it happen before, with GNOME. A decade or more after the cascade of attention-deficit teenagers started stripping out features it is still missing plenty.
> People created Duvian. If systemd is such an awful choice it should be amazingly popular.
You miss the corrupting influence of money. Money means resources, and resources mean being able to extend tentacles into every project. Resources mean being able to present an offer to other projects that they can't refuse: patches that implement needed functionality and, oh yeah, also mandate systemWaylanD.
You and me (I use XOrg too, no xmonad on Wayland) enjoy status quo for free. We consume work that maintainers do not enjoy.
> and I am completely burnt out on that on its own merits [1]
[1] https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server...
---
> attention-deficit teenagers
JWZ cliches are worn out, marking group you don't agree with disorder regresses discussion. Someone would call you old whiner and he would be right. I would recommend you join BSD camp.
> You miss the corrupting influence of money.
I missed nothing. Same money brought what we have today. A lot of people work on Open Source for free.
> mandate systemWaylanD.
Straight from ajaxnwnk:
> X11 clients are eternal, there's just way too many of them out there that are line-of-business and will never be ported to anything else [2].
[2] https://news.ycombinator.com/item?id=24925459
---
I feel sick seeing such attitude. I would reply anymore.
I try to address this with completely transparent and public voting, and also non-numerical voting, meaning every vote has to also be a "tag", like on Slashdot: insightful, interesting, troll, flamebait, offtopic, etc.
But not only that, you also get to see who tagged you, and this tells you whether it's someone you know or just some random.
I never got the impression that the tagging system is widely used, however.
If X would stop working this morning I'm afraid I'll have to go back to Windows, after 11 years, and use WSL2. Not a future I'm looking forward to and not something I'd thank the Wayland community for.
Some apps like AnyDesk just haven't invested in support for Wayland, while shovelware like Zoom tries to force you to install their client.
That they have to invest work for simple functionality to work is the problem. Until Xwayland can support this, Wayland is broken by design.
I haven't looked into iOS and Android.
I picked up on a completely different common theme: people are upset because major distros replaced a thing that worked with something else, and the new thing has a lot of problems that the old thing didn't.
It was fairly easy to find an example on stackoverflow that created a Window using Gtk, and reported it's position.
Once something like that is on the bug report things tend to get fixed pretty quickly.
Report the bug on the outer-most thing first, e.g. GNOME shell in this case.
Now they work all the time. Pipewire appears to be a better architecture than Pulseaudio. We have to hope it un-bugs faster than PA did.
There are strategic and tactical issues here.
Tactical issues are obvious. Wayland's problem with screenshots and all the bugs from not having a decades long lineage.
Strategic issues are less obvious. As this blog pos alludes to the standard X server is reaching a maintainability crisis where long term devs don't think the project is a good idea.
I think Wayland is a tactical mis-step myself for reasons you and GP mention, but I think now that the bad has been covered someone needs to mention the good:
The reference X server cannot practically be replaced. The reference Wayland compositor quite possibly isn't ever going to get established before being replaced. This is an excellent thing - it beings evolutionary pressure to the display system.
Wayland has problems, but unlike the current X ecosystem the problems can be fixed by replacing bits of software. The Wayland protocol seems light enough that Wayland+1 can implement it as a compatibility layer. When the dust settles, leaving X will have been a good idea.
Sadly I don't have time to work on that, which really sounds like a full time job for a team of at least 3 developers, and from the looks of it, the people in charge don't share my vision for integrated coexistence of old and new.
Some of your issues are solved:
CLI clipboard access: wl-clipboard: https://github.com/bugaevc/wl-clipboard
App launcher: bemenu: https://github.com/Cloudef/bemenu
I'm really concerned about Wayland fragmentation. Will some tools work on only wlroot implementations and not others? X11 apps generally work across window managers, although the weird ones (tiling window managers like i3) may have some interesting things you have to work around.
If wlroots became the standard for all window managers on Wayland and everyone used it, I guess it would be fine. But if not, we're going to see a lot of apps that have to be adapted for each and every composer.
If the world can agree on Wayland then desktops can agree on some dbus interfaces for doing stuff like screenshots, screencasts, and automation.
Wayland is a shiny new thing and lots of people are writing compositors since it's suddenly possible for people to write them in a way that you simply couldn't with X11. The ecosystem will eventually mature but I think it would be a mistake to recreate the Xorg monoculture with wlroots. People seem to see the value of multiple browser implementations agreeing on standard but not display servers.
Even with a relatively monolithic and "opinionated" protocol such as X11 it's not uncommon to encounter applications that don't play very nicely with alternative paradigms (because they expect a tray to be available, or to be able to place floating windows anywhere they want for instance). Still, overall with a few hacks here and there it works mostly very well. Basically I know that we're 2nd class citizens within the unix desktop world but at least the X11 model gives us enough of preemption to get things working mostly correctly.
From what I see of Wayland I'm very concerned in the long run. Not being able to just beat a window into submission X-style seems like it would create a world of troubles.
And because tiling environment are fairly niche I don't expect the ecosystem to organically evolve solutions to all of these problems.
And if you think "well just stop using tiling WMs and use whatever else is using you weirdo" please do note that these issues are also often the same that are encountered by people with disabilities who need to rig their UIs in certain ways to make them usable. Also you'll have to pry my tiling WM from my cold dead hands, you heathen.
>[...] a modular basis for Sway and other Wayland compositors to build upon
I was curious to see what that looked like so I went on the github and the first sentence on the README is:
>Pluggable, composable, unopinionated modules for building a Wayland compositor; or about 50,000 lines of code you were going to write anyway.
My jaw literally dropped when I read this. It seemed so wild that I actually cloned the repository and ran sloccount myself to check if there was a catch (there isn't, master is at 53k lines). My DWM is 3k lines and it's fully featured as far as I'm concerned.
I realize that it just pushes a lot of that functionality (and code) into X but at least it separates the concerns, my WM doesn't ship with half of the X11 source code as a hard dependency. Also X11 has been battle tested for literally decades by now, it's not a fast moving project (well, arguably it's quite the opposite, hence the very existence of this discussion).
I haven't looked very deeply at Wayland so I won't say that they're doing it wrong, maybe I'm just missing an important aspect, but the more I learn about it the more it feels like they've thrown the baby out with the bath water.
X11 can be hugely hacky at times and some of it is seriously outdated at the conceptual level, but it also does many things amazingly well, arguably better than any other mainstream desktop environment out there. It's an incredibly flexible, if a bit idiosyncratic system. Wayland seems to fix some of its flaws by introducing a brand new system that comes with its own set of drawbacks.
Then the compositors could just use this library instead of every one of them duplicating effort and coming up with their own mutually incompatible ways of doing things.
In fact, this library could even be protocol-agnostic, and be able to talk to both Wayland and X.
>Then the compositors could just use this library instead of every one of them duplicating effort and coming up with their own mutually incompatible ways of doing things.
That's what wlroots is, except for...
>In fact, this library could even be protocol-agnostic, and be able to talk to both Wayland and X.
... because that's outside its scope. The point of the middleware is to interface with the wayland protocol. It's not "protocol-agnostic".
> dwl.c, 2000 LOC
https://github.com/djpohly/dwl
wlroots should be compared with X.Org Server, 370000 LOC
For fairness, you should count the hundreds of thousands of LOC in Xorg as well. From that PoV, 50k might actually be pretty lean.
I think in the long run you’ll actually be quite happy with Wayland for your use-case since Wayland removes a lot of the weird things that Windows can do without the help of the (tiling) compositor. A tiling compositor actually has far far more power to beat windows into submission than an Xorg based WM ever could. Surfaces can’t move, steal focus, put popups anywhere without the compositor having a say and, potentially, just saying no.
And GNOME has removed support for xembed tray icons in favor AppIndicator which is just a generic dbus interface which a tiling WM can actually sanely implement.
It's 12 years old
Since I have no desire to lose functionality or work around issues I will revisit the situation either when every major issue is resolved or within 1 year of major apps like Firefox not working on X even with a a user contributed build.
I would be shocked if this was before 2030.
except when they aren't - I had a firefox bug for a couple years where the browser showing a notification would completely hang it for at least 15-20 seconds
This is the common refrain I tend to see. I know I was certainly in the "Can't believe it" category, since I'd tried wayland about 4 years ago and ended up moving back to X.
That said, I had exactly the same reaction 2 years ago when I gave it a shot on my new machine.
It was fast, didn't show any tearing or flickering, handled automatic configuration of most monitors correctly, and made my touchpad genuinely nice to use.
Just the touchpad support alone won me over pretty much immediately.
I went from "Eh, Wayland isn't ready" to "Holy shit, I'm never going back!"
The former is nearly unwatchable if the scene has lots of darkness punctuated by light, such as a fire.
What does "less support" mean? At least on my system, Sway is running with adaptive sync enabled.
For me it’s some of those, dwm, sxhkd, keynav, xcape, the Compose key, and simple highlight + middle click/Shift+Insert copypasta. I’m a bit confused about the extent to which the Wayland devs have changed their minds about the last one.
https://gitlab.com/interception/linux/plugins/dual-function-... (currently using this – very powerful)
https://gitlab.com/at-home-modifier/at-home-modifier-evdev (used this for years – works extremely well)
Two more projects I've found that should work on Wayland:
So far I basically kept using X11 because it mostly just works for me, but I didn't expect that Wayland was still so far behind.
So it respects ~/.XCompose?
> EGLStreams (NVIDIA): GNOME, KDE, Weston
I've checked OpenBSD once, no audio support. I've bought Intel Poulsbo based netbook [1], no video acceleration beyond XOrg 1.9 and kernel 2.6. I've patched source for 3.* compatibility [2] and finally bought new hardware. I would dance if GNOME or KDE had Poulsbo support.
Soon (if not already [3]) NVIDIA would be second class citizen on Linux.
[1] https://en.wikipedia.org/wiki/System_Controller_Hub
[2] http://sergeykish.com/linux-poulsbo-emgd
[3] https://www.gamingonlinux.com/index.php?module=statistics&vi...
If you are re-architecting a system from the ground-up there is always some fallout expected.
I would also not expect people to suggest deprecation OS X in favor of Windows and then shit on people what want to keep using their OS X Clipboard manager.
This is the real problem with all this forcing to move people to Wayland / Pulse / SystemD crap: They are new platforms instead of compatible improvements to the existing platform, but somehow you still expect everyone to just jump ship.
I was suprised to read that OBS doesn't work with Wayland. I found some articles [0] on how it runs well using XWayland [1] - which I guess let's you run X-Clients under Wayland - but it seems that the amount of work to get this to work is not trivial, considering the official PR for the work, is on part 3 and that has been open since March![2]. Oh, how did it get so bad?
---------------
[0]:https://feaneron.com/2019/11/21/screencasting-with-obs-studi... [1]:https://wayland.freedesktop.org/xserver.html#heading_toc_j_3 [2]:https://github.com/obsproject/obs-studio/pull/2484#issuecomm...
Also, there's no longer tearing when I resize windows!
* swaymsg (no idea what Gnome or KDE do here)
* wl-clipboad
* wofi, or a Wayland fork of rofi (https://github.com/lbonn/rofi)
* I don't use a clipboard manager, so I'm gonna skip this one. :D
* slurp, grim, wf-recorder, mpv (OBS and ffmpeg work fine, not sure about the others)
Also here's a oneliner for color picking:
grim -g "$(slurp -p)" - -t png -o | convert png:- -format '%[pixel:s]\n' info:- | awk -F '[(,)]' '{printf("#%02x%02x%02x\n",$2,$3,$4)}'
So Wayland is not a replacement of X11. Gnome on Wayland should be a replacement for Gnome on X11. KDE on Wayland should be replacement for KDE on X11. Sway on Wayland should be a replacement for i3 and X11. But as you can imagine in this equation, KDE, Gnome and Sway are permitted and required to take on more responsibilities.
You might take issue with the fact that a lot more of the display stack gets tied up in specific desktop environments. It's KDE and Gnome and Sway that are not providing you these command line tools/screen recording/clipboard access. I don't mean to say this as nitpicking or that """Wayland""" (whatever that means) is dropping the ball, but this is really the responsibility of the desktop environment (or WM) in Wayland's design. Wayland is just a protocol.
What you're observing as shortcomings in Wayland is really a lock of pace and direction of development for (e.g. Freedesktop) standards that standardize clipboard access/screen recording use cases, and the adoption of those standards. The Linux community seems to have been hit by 1) not realizing Wayland does not replace X11 and 2) realizing that, not being to coordinate standardization well of the pieces of the X11 stack that should be replaced as well. If you need to replace X11, you need a lot more than just Wayland. But that seems to keep on catching people by surprise.
I think it'd be helpful for the future of the Linux desktop if more people recognized that.
You can't capture an ecosystem unless you provide that value, plus the activation energy needed to persuade people to change.
systemd (as an example of a large, recent, change to the "whole system") touched end-users far less than X so the pain was felt mainly by distributors and sysadmins.
Time and again, software that's "better" fails in the market because it doesn't provide the things that users need, want or use.
Backwards compatibility is usually key when trying to capture a large, long established user base. ...and that means backwards compatibility even (or especially!) with all the "bad" or "wrong" stuff. This is one of the things that makes software "products" much harder than software "engineering" (which in turn is "harder" than computer science).
Science is how it works. Engineering is getting it to work and productisation is getting people to adopt it.
Wayland has to solve problems that end-users actually care about rather than just being better in technical ways.
But the writing's on the wall. This change is not coming about through market forces as you're suggesting, but where the developer's interests are. And that's pretty clear X.org's development has slowed down significantly compared to whatever is happening around a Wayland ecosystem. Although sadly not as much effort is put into the stuff that is needed outside of Wayland.
All I can find is that in the past Mutter had lower latency for its Wayland implementation when compared to it using X.org, but it seems that Mutter's latency story has always been iffy in the past. FWIW it seems that Sway for example has finely grained input latency tweaks built in while being Wayland compliant [1].
> First, I want to make it clear that I’m not accusing the compositor of true evil, which I define roughly as deliberately causing suffering. There’s unfortunately too much of that in the world. I mean it in the more metaphorical sense that it causes serious problems and forces other parts of the system to be more complex to work around its limitations.
I do not understand this position. Why attack Wayland? X.Org works, it would probably work for another 10 years, XWayland maybe 20 years. If X.Org is such a marvel surely someone would maintain it.
There are a lot of options to support X.Org — programming, hiring, donations, asking company to buy license from the vendor that maintains it. Companies buy all sort of licenses, office suits, editors, I have not seen buying Linux licenses.
Because most people are dependent on distributions to provide them with a standardised setup, packages and security updates, and few distros have proven willing to support more than one option for a component as central and dominant as the display server. Sysvinit also works, und unlike Xorg doesn't even have the problem that graphics hardware will eventually leave it behind; and yet, it is now basically impossible to avoid systemd and its many tentacles if you want a mainstream-compatible Linux experience with timely security patches, because its proponents have successfully persuaded every major distro to adopt it and drop everything it replaced. Wayland, unfortunately, is not willing to exist as just another option until it has reached feature parity with X11; rather, it is competing with it for a limited resource (distro support) now, and poised to go in for the killing choke.
I've seen enough arrogant quotes from systemd developers. But it solves user problems. Arch Linux was first among systemd adopters, boot become much quicker. And I think it solves maintainers problems, that's why it was adopted so quickly.
Oh, I've heard GNOME also helped adoption, but is it systemd fault or GNOME fault? I believe GNOMEs. As I know OpenBSD does not run systemd so it is possible if people care enough.
I do not use PulseAudio, but I have not tried since 2008 (pushed by Ubuntu, wrong choice). Maybe it works, ALSA works so I do not care. If I cared enough about ALSA, I'd support its development like maintaining Firefox ALSA backend.
> Wayland, unfortunately, is not willing to exist as just another option
I do not believe this is developers attitude, more like your opinion. You would gain nothing by attacking Wayland. Some developers would burn out sooner, same developers that could have implemented features you need. And lets face it no one wants to work on XFree86, not you, not me, hardly anyone. Because it is a mess:
> The size isn't so much the issue, it's the design. The xfree86 ddx seriously believes that you have one video card driving one monitor with one keyboard and one mouse, and anything beyond that only works well because we sank a ton of effort into it. (It used to have code to disable interrupts! From userspace! What could go right.)
> X is a tremendously successful project whose core design and reference implementation do not reflect how computers work anymore, in ways that make it painful to develop and maintain as the system display server.
That said, it's been years since I saw tearing on X. I can't really even remember what it looked like, or when it went away. Intel graphics used to crash all the damn time, but I don't recall ever seeing tearing on it. Is it an NVidia driver artifact?
But in the vast majority of cases, X11 implementations have worked for the end user. It certainly did for me. Wayland does not. I've never managed to have it working smoothly for me !
As a user (like in a user story you could say), I don't care that the Wayland protocol does not cover X11 protocol, I want my screengrabber and my video to just work. And if it is "cross-platform/desktop" the better. As a user I do not want a different set of bugs because I use a Gtk screengrabber and a Qt video editor and the Wayland team decided it was not in their scope to handle it. IMHO, sadly, it ends up in nobody's scope and/or in code duplication.
This statement doesn't make sense to me.
X.org is a display protocol, its own server implementation of that protocol, and many utilities to interface with that server. And even more stuff.
To illustrate this: if you run Gnome on X.org, you will see you have an 'xorg' binary running in addition to all the Gnome stuff. That's the X11 server from X.org. If you run Gnome on Wayland, there's no 'wayland' stuff running. There's just Gnome implementing the Wayland display protocol.
That's why this "switching to Wayland" talk is just missing the point. You're not really switching to Wayland, you're just switching to a "pure Gnome" stack, or a "pure KDE" stack, or a "pure Sway" stack. These stacks all just happen to implement the Wayland protocol in their own compositors (i.e. Mutter, KWin, Sway) because they're committed to standardization and all want to run GTK3+Qt5+Ozone+XWayland+etc apps built for Wayland.
The only difference is that all these things currently used to exist within the X.org project, and now they're in various other places (some parts in fact don't exist at all...). There's nothing stopping people from abstracting a lot of this functionality out in a library for others to more easily build their own stuff with it [1]!
If anything the efforts replacing X11 will make it easier to mix and match components, because it gets rid of the focus on the singular X.org implementation. Not saying multiple implementations of the same thing is necessarily a good thing mind you, but you can't accuse these efforts of making it more difficult to mix and match.
[1]: e.g. https://github.com/swaywm/wlroots does some of this to make it more easy to build a window manager that supports Wayland
I'm sure dealing with different extensions and subtle bugs makes everyone who needs to deal with it very happy, and will help Linux desktop adoption (not). Perhaps eventually the cost of keeping up will reduce desktop fragmentation and everyone will be stuck with only a single option for an OSS desktop environment.
Wayland replaced a bad technical situation with X11 with a bad social situation with Wayland. Technical problems can be solved with enough work (e.g. Wayland itself to replace X), social problems however can persist for a long time and aren't so easy to fix. It didn't have to be that way. Perhaps it still doesn't if the community could actually standardize while prioritizing the main use cases.
I hope we'll eventually have some "wayland-goodies" package which will implement the common stuff like easy screenshooting, easy hotkey assignment, easy window inspection and control, etc. I suppose this can be implemented based just on the protocol, and not specifics of a compositor.
Love it or hate it, but systemd has been around since 2010, and is almost ubiquitous by now. Wayland has been around since 2008, and it still seems more like a tech demo for most use cases rather than something that is production ready. There is clearly an issue with this project.
For the understanding of all of this by the community, certainly. But Wayland could have never been a direct replacement for X. The problem with X is not that it's old or poor quality. Even if that were so, that is fixable. The problem with X is that its fundamental design principles are not suited to a desktop made after the early 1990s.
The reason X is much more entrenched than being a display protocol very much has to do with every X running system having a standardized X server any system process can talk to. That client server principle was fundamentally flawed and Wayland fixes that, but that very same client server principle allowed this X ecosystem to thrive. Any "X replacement" that did away with X11's core design problems would therefore run into not being able to replace the ecosystem in the same way.
If there would have been a coordinated effort to replace X, we would have needed a much broader initiative pop in 2010. An initiative where Wayland is one component, something like PipeWire another, and some Freedesktop IPC standards for e.g. accessing the clipboard and other features provided out of the box by X11, and reference utilities implementing those standards.
But coordinated efforts like that are not really how the free software community works! So Wayland just evolved out on its own. It started as a small effort by developers frustrated with X11 the display server protocol. The community then proceeded to take the line "Wayland is a replacement for X.org" and then ran with it, creating confusion everywhere, and stifling progress to replace X11 in the process.
Systemd is quite unique in the free software world because it's a tremendously coordinated effort and has taken on a broad scope. And just look at the sheer amount of vitriol that ended up getting just for those aspects of the project. It's just not how the community likes to operate, or at least a vocal minority does not like this.
The way things are currently going, Wayland may turn out to be another HURD: it's always a year away from being ready, and there are some enthusiasts working on it, but in the end, it is supplanted by a more pragmatic solution. And the only way that is happening is once X is falling apart enough that some company like Redhat coordinates an effort to replace it.
> For most users X is good enough
It's good to understand the converse is also true. For a lot of users, Gnome with Wayland is also good enough [1]. Fedora's default install has been Gnome with Wayland since Fedora 25, which was released almost four years ago. Since then I've primarily used this non-X11 desktop on my Linux desktop, although I did fall back to X11 for specific scenarios. Debian 10 and CentOS 8 (both released over a year ago) also default to Gnome with Wayland for a desktop install. Red Hat's and the Debian Project's decisions there may have been questionable, but this is still software many, many users use daily despite its limitations. It's certainly well beyond a GNU Hurd situation even if it doesn't reach your or my desktop standards all the time.
Despite the utter mess this transition has been for years, I do think Wayland will persevere in the end and become dominant. Features users expect from a modern desktop, like fractional UI scaling, rich trackpad gestures and browser hardware video decoding are implemented more quickly for the non-X11 desktop stack. People seem to implicitly agree it's the future, although to this day some essential parts of it are still left behind. That's just the free software community for you - no centralized planning or vison, and nobody works on the boring parts.
[1]: It's only been Gnome so far that has reached this level of "mainstream acceptance". KDE with Wayland is almost there, and Sway has a lot of enthusiasm around it too.
Sway has been working great for quite some time as well.
KDE has been lagging behind, but is finally at a place where it will be usable by the next release.
It's therefore somewhat difficult to identify with your phrasing. Wayland is already here, "ready" or not, it's taking over.
Look from another side. Wayland has been around since 2008 yet it accomplished something X.Org could not. It's been 30 years in development, it has tremendous market share and yet it failed. There is clearly an issue with this project.
* https://github.com/bugaevc/wl-clipboard
* https://github.com/ReimuNotMoe/ydotool
OBS / ffmpeg and etc. should get integrated with Pipewire I think for screen capture and the like? But I'm not sure how far that progressed.
This is the biggest problem. I accept Wayland brings benefits for some people, but I couldn't care less. Since I don't care about the benefits it brings, it needs to be entirely painless.
Until the switch is more painless than holding on to Xorg, there will be a good chunk of users with no incentive to make the move.
EDIT: I'd also say that the fact that so many of the tools need to change, rather than e.g. get support added to them to support Wayland compositors is a huge indictment of the whole thing. It seems like no thought was put into planning for transition.
That depends a lot on how difficult it is to keep Xorg working with modern distros. You might get forced into Wayland when your favourite distro and all acceptable alternatives don’t want to put the work into integrating and patching an aging Xorg.
Whether it’s with a carrot or a stick, you’re going to Wayland sooner or later.
Remember, this was not some guys just randomly showing up and pushing their shiny new thing on people. Wayland was started by one of the developers who had already worked on the Xorg stack for several years.
Put another way: I've seen similar new things come and disappear several times.
Every time this topic comes up, a bunch of people bring up the things X has that Wayland doesnt yet have, or have in the form they think it should.
I'm not sure if it's just me but these comments come across as some combination of defiant, demanding, or I dont know what. It's like they don't understand that the world is moving on and doesnt really give a $h!t about them and their love of X. I mean here is a post from "the guy" whose been keeping X going for a long time saying "this shit is done" and people keep complaining about that as if they have some say in it without actually contributing to the code. It reads like entitlement - some kind of expectation that other people exist just to make things the way they want them to be.
Entitled developers who think their work is above criticism just because it's open source are just as annoying as entitled users who think they are owed something.
I mean, this really sounds very similar to systemd and pulse audio type gnashing of teeth where the new solutions added plenty of widely required features while compromising on niche use cases which had other workarounds.
Wayland bring the risk of having critical bugs on compositor Y and critical missfeatures/missoptimizations. Staying on X does not have any major user facing issue. Therefore choosing to use Wayland right now is an irrational action which pros does not offset the cons.
Maybe that it'll make sense in the next 5 years, then I'd reconsider
State of the art has moved to image compression based screen sharing even on Linux and demanding that we stay on an obsolete stack which falls apart as soon as you connect a modern monitor to modern laptop due to some 1990s usecase is the crux of all these neckbeard complaints. Just like with Pulse, SystemD and bunch of others.
Linux distros want to stay competitive in the now, not in 1990s. Which is why they're gaining market share.
This is where distro diversity is critical. Users have the choice to use a distro that is serious about maintaining backward compatibility or they can choose the ones chasing the new shiny. Everyone wins.
Personally, I’m not swayed by the “but it’s modern!” arguments. I just want my existing software to continue working. I don’t care if my stack is obsolete, whatever that means. I just don’t want to worry about software breaking when I update to the never version.
Other people are not like me and they can go use a distro with Wayland, and we are all happy.
Same with Wayland - it's a way to drag Linux desktop into a world where mixed DPI displays exist and where HW acceleration of desktop is a norm. That seems to be signifiantly more useful in 2020 where most displays need some kind of scaling.
That's valid, and I did say I'm not sure if it's just me - meaning my (possibly wrong) interpretation. A list of specific things missing is fine, but the I'm-not-switching-until sounds different than a simple valid criticism or an inquiry as to weather those are being addressed.
I probably should not have responded to a particular comment with my comment though. It wasn't too bad as those things go. Some of them really do come across the way I described.
X, architecturally, is a dumpster fire. None of the ideas that were reified in it's design, types, or behaviour - not forcing rasters down unix pipes nor building widgets with X objects nor rendering networked fonts nor the general concept of immediate-mode widget rendering - are actually used today in modern X apps and have been mitigated-away with hacks and jury-rigs. But the design and the types and the protocol persists and no one wants to work on this nonsense in their free time. Unpaid programmers have voted with their commmits and Xorg has been orphaned. It's a dirty job and for the longest time only paid programmers have maintained X. And the last company to pay programmers to work on this stuff canvassed their customers and decided that the work didn't need to be done anymore.
Everyone using X today has been free-riding on RHEL customers for years and Redhat has decided not to burden them with this anymore. And nobody else is volunteering to pay for this.
I don't think entitled developers is the right term here. As an Xorg user, how much did you pay to use Xorg?
Every time this topic comes up, a bunch of people remind that Wayland doesn't yet have an accepted standard for basic features. Wayland is very good at some niche features like HiDPI or fractional scaling* , but more people (at least two orders of magnitude more) need screensharing these days when companies move to WFH.
* Yes, these are relatively niche features right now. e.g. Look at the Steam hardware survey: more people run resolutions below 1080p than above it - and that's in a biased sample, since gamers are more likely to have high resolution monitors! Now, it's nice to be future proof, but these features should not be prioritized over basic features.
* Image editor, with own modern looking GUI-toolkit built on top of X11 (AzPainter)[0]
Same thing actually decided by AzPainter developer: they already tried to add Wayland support to its GUI-toolkit (additionally to already supported X11), but postponed it due to Wayland still is not fully usable.[1,2]
[0] https://github.com/Symbian9/azpainter
Wouldn't it be easier to make it a separate service instead of having X or Wayland deal with it?
It's not even the second time.
This is the third time X development has been abandoned. And yet, millions of us use X11 every day.
Don't hold your breath for Wayland to replace X11.
When XFree86 was forked to X.org, is that what you call the first?
X11 gave us XFree86, because changes to the X386 server weren't being merged. There wasn't much of an alternative to forking.
Xorg was forked from XFree86 over a license change, but after the fork, XFree86 died -- its maintainers were unable or unwilling to merge changes or do releases.
Open source software is also free (as in beer) software.
There's a word for people who complain about free things.
The post and comments are free, yet here you are complaining. Consider why you think that's okay, and you'll understand.
Even if all developers were paid, they wouldn't be paid _by users_. It means the developers don't owe the users anything.
Those users are the target market that those companies are interested in pleasing. It’s not about “owing” or not. It’s about delivering something that people want to use or not. If you fail, the users will go elsewhere. You don’t have to care; you might develop the software for your own personal gratification. But people are going to share their dissatisfaction and might very well vote with their feet. And it’s possible that, even if they don’t, your work makes the world a worse place. No, no one can sue you or call you a cheat for doing a bad job, but they don’t have to like it either.
Not really, no. My company (SourceHut) has nothing to do with Wayland and is just sponsoring me for working on open-source software (_any_ open-source software). A few other developers are working for Collabora, which mainly focuses on Wayland for embedded use-cases. So, none of these companies have a real interest in pleasing desktop users.
Regardless, it doesn't mean that I personally don't care about my users, or that I want to fight against them. It's just that if you don't like something, you need to step up and do something about it to improve the situation, instead of just complaining.
Maintainers are scarce.
> it’s possible that […] your work makes the world a worse place
Always great to hear that…
Users are always demanding things: new features (which sometimes are very bad ideas), merging patches (which sometimes were never tested), expecting answers for questions that were asked and answered thousands of times before…
> It's just that if you don't like something, you need to step up and do something about it to improve the situation, instead of just complaining.
Exactly. Users who want to say on X (for whatever reason) should start contributing instead of spending time blaming the devs. If they want to switch to Wayland, but are missing something - they should work towards fixing it instead of dragging everyone else back.
I don't mean to seem ungrateful for the work that open source maintainers do every day, but I think this sort of complaint is usually a symptom of a problem with either the documentation or the interface being unclear. These pain points are usually an opportunity for improvement in the product. On the other hand, there are probably more such opportunities than there are available maintainers...
> why bother creating open source software at all.
I create features for myself, I share it for free, that's gift, not pleasing.
Painful, but it is true.
Free Software development is awkward in this respect. Both developers and users feel as if they are doing something virtuous, but it's unclear to what extent the contributions of either party help the other (or anyone else).
Meanwhile the presence of this self-conscious feeling of virtue makes transactions difficult, as every party feels they begin by deserving something out of it. So Free Software users are more demanding and aggressive than users of proprietary software, and Free Software developers are more prickly.
Loss of ego is absolutely essential here.
(More on-topic, this series of HN posts about X and Wayland has prompted me, a long-time holdout X user, to experiment again with switching one laptop to Wayland. It's massively better than the last time I tried it, and I'll probably leave this laptop like this unless something goes awfully wrong. Thank you, unappreciated Wayland developers.)
Demanding users I see looks like spoiled web users. They expect free services, they pay with privacy or are clever enough not to pay (adblock). But Free Software does not sell their data.
Or they compare to Microsoft Windows and Apple macOS, quite profitable companies. But Free Software does not acquire telemetry, does not sell hardware or bundled services. There are some private companies (Red Hat, Canonical, Mozilla), their difference from my industry (web development) is they ship source.
The problem is not wayland. I root for wayland and I hope it'll progress steadily to maturity.
The problem is getting pushed to drop my well-working Xorg-based setup for some wayland-based setup that can't run the application I use daily and that I've been running for years.
I'm okay with wayland, but I have a problem with people telling me "oh just drop that".
GP is saying yeah, that's great and all, but other people try to push everyone to switch to Wayland because <reasons>. The Wayland ecosystem simply isn't there yet though; they're hawking a broken solution.
It's perfectly fine for a FOSS developer to walk away from any given project. When third parties come along and frame things as though the only option is to switch to a broken "solution" it derails the discussion. We (ie the community at large) should be having much broader discussions about both how to keep maintenance going as well as what's needed to actually make the replacement viable (so we can maybe switch to it later).
People who had objections against systemd maintained init systems [1], created new distributions [2]. I do not pretend there are no problems with systemd but it serves my (quite common) needs. And the way distributions shows some people were burnt out.
If you need X.Org (and I do), speak how to help X.Org.
Some people needs covered by Wayland. It is not their fault.
Distributions default may be questionable, it is distributions problem not Waylands. I use Arch Linux, no default, no problems.
You don't complain about the weather?
Only that they'd rather use (unmaintained) X over Wayland due to numerous shortcomings in wayland that are practically unfixable (because they're intentional design choices, or because they're a result of the fragmentation resulting from wayland's design choices).
It is fine. It is done. Maybe something better will come along at some point, but we could just keep using it like this indefinitely.
As I understand it, Linus' number one deal is "don't break backward compatibility." The Unix Way is "Write programs that talk to one another..." etc. This is the foundation that I believe put Linux where it is today, this is why I love it and use it so much.
Which is why I'm dismayed to see so much comfort with what feels in line with a proprietary top-down control attitude, the thing that Microsoft and Apple et al do, i.e. "This thing is going to change, so get over it."
I appreciate that there is work being done. I'm willing to trust that there is a point to Wayland (I literally don't get it at this stage; trying to use it presently creates FAR more problems than it solves) -- but it seems like it should be axiomatic that the project works harder to preserve the space than it appears to now.
I have to remind myself to try to dig a bit deeper around to find out about the things I'm more into; what matters more to me than "the desktop" is "applications/programs" -- and that seems to be harder to seek out these days.
By contrast the common complaint about Wayland is that it doesn't have the vast variety of unrelated features rammed into it like X does.
Part of the problem here then is that there's A) no big pushes for 'does one thing & does it well' for all the other X features (like clipboard or global keyboard shortcuts), and B) fragmented implementations of the wayland protocol. There really should have been a much better, and more singular, reference implementation that Gnome, KDE, etc... all just embedded instead. Which means the "does it well" part is taking a really long time, as developer communities are split up.
I have an opposite view. X11 has two key aspects separated to two independent entities: mechanism (in Xserver) and policy (in window manager). This has and advantage as neutral mechanism can be shared by everybody (Xorg), while everyone has different opinion about policies (many WMs).
Wayland assumes integration of compositor (mechanism) and WM (policy) to one entity.
All I can say is that nearly every single one of the former core Xorg developers has said precisely the opposite (sometimes in literal terms [0] [1]), and has switched to developing Wayland.
[0] https://www.youtube.com/watch?v=GWQh_DmDLKQ&t=27m44s
[1] https://community.kde.org/KWin/Wayland
> In Plasma we need Wayland support as we are hitting the limitations of X all the time. Wayland will simplify our architecture and allow us to composite the screen in the way we consider as most useful.
Distribution is a collection of such parts, you may think of it as "proprietary top-down control attitude" but it is just a collection that suits someone needs. It may not suit you, you may replace parts, you may create another distribution. For example as Arch Linux user my install does not include graphical system, no one forces me.
The point I see is that Wayland got something useful. So useful that distributions started to switch their default. If anything it conforms that X11 has some problems, that it was harder to achieve same result there. Maybe it does not cover your needs but it covers someone needs better.
Except X. X is X and everybody agrees that X is X. It's not perfect, but it's there, and it mostly just works, and all the programs are written for it. Instead of trying to fix the one thing we've all managed to agree upon, we're going to replace it with something completely different.
I'm not sure this is a good idea.
X11 is ancient (1987), but it's brilliant. Its designers even anticipated having 16 mouse buttons, and (more importantly) opening a window on a remote system.
The system is flexible, programmable, customizable; I've got all development manual volumes here on my shelf.
While I'm open and sympathetic to any new ideas and improved software systems, including novel windowing concepts, personally, I don't have any unmet window manager needs at present. Any new system shouldn't just replicate a subset of X11, they should go beyond the state of the art to justify the time investment.
But X11 has been stale so long it would really benefit from a back-to-the-drawing-board approach. From many points of view. Network latency, security etc.
But Wayland isn't it for me... It's too desktop centric IMO.
I mainly use it when logging into headless servers by the way. Saves me setting up a complete desktop environment there. All they need is the GUI apps I need and some X libs.
I'm not convinced it will ever actually happen.
The other problems like environment drift and maintainer interest are secondary to the trust problem.
What does he mean by that? That there isn't really a hardware-accelerated Xorg server?
If that's true, is the post indicating that Adam sees the Xorg code as an interface layer to some other rendering system that had hardware acceleration?
Is that XWayland? I'm guessing at all this.
Xwayland can lick my sack.
In an ideal world where everything uses KMS or everybody uses something like Xwayland we would be able to kill million of lines of code from the Xserver. While this doesn't happen, those millions of lines not exercised by these paths remain unmaintand.
Remember, Ajax works for Red Hat, which is trying to push really hard for Wayland on Gnome. They don't seem to care about anything graphics-related that's not Wayland+Gnome. Red Hat has much more decision power on the Linux community than people imagine it has.
A huge problem here is that a lot of efforts that were previously redirected at X11 are now being done on the Gnome compositor, due to Red Hat. We just won't get to see a solution to the fragmentation power unless someone with a lot of money decides to play Linux Graphics.
If only we had more real world money-making products actually relying on the desktop graphics stack to make money, then we'd have a better graphics situation.
sloccount says xserver is around 370kloc. This isn't counting the drivers outside of the generic KMS support (which, practically speaking, is what you're probably running on anything remotely modern), but ati+amdgpu+nouveau are another 102k, and intel is another 186k (partly because it embeds a copy of the software renderer for dumb reasons), so you're still not quite at two-thirds of an MLOC. The size isn't so much the issue, it's the design. The xfree86 ddx seriously believes that you have one video card driving one monitor with one keyboard and one mouse, and anything beyond that only works well because we sank a ton of effort into it. (It used to have code to disable interrupts! From userspace! What could go right.)
It sounds a little like you think I'm being given these priorities as marching orders from above. That's maybe a bit insulting? I suspect I'd have the same opinion at this point regardless of my employment history, namely, that X is a tremendously successful project whose core design and reference implementation do not reflect how computers work anymore, in ways that make it painful to develop and maintain as the system display server. Frankly that was probably true in 2005 when I started on it, but at that point it was also the only thing that had credible video drivers at all.
It's not that Red Hat is trying to lock anybody into a particular desktop out of some nefarious political agenda, it's that we don't have the resources to do things twice. If we want to deliver the best desktop experience we can then choose your own adventure among Gnome and KDE and XFCE and twm and i3 and whatever else simply is not going to be an efficient use of our headcount. And we're reaching that point with display services too, trying to support both X and Wayland increasingly means writing the same feature twice, sometimes with radically different approaches, and trying to implement them _at_ _all_ under X11 is more and more intractable. What would you have us do? What we're trying to build now is an Xwayland that keeps your X apps working as well as they ever did, under a hardware display server model that makes things like high-dpi and HDR and AirPlay and RDP and GPU offload straightforward, or at least feasible, instead of excruciating. You can like that or not, I guess.
In all seriousness, if someone wants to take the reigns of stewardship over the xfree86 code then please, by all means, come forward and claim your prize. But I can't justify spending my time on that anymore, and given the interval since the last major release, apparently nobody else can either.
I appreciate the work that is going into the Wayland desktop ecosystem, really, but I would wonder why you would put all this general-purpose desktop environment implementation effort into Gnome specifically and not a common library like wlroots, with the Gnome compositor as a layer on top, so that all compositors would benefit. (I would ask the KDE team the same question.) It feels like what we are losing most with the transition from X11 to Wayland is commonality of implementation for the various system services other than input or presentation which were formerly handled by the X server, and which are now handled either by the compositor itself (Gnome and KDE) or by a shared library (Sway and any other wlroots-based compositors).
It is good that we at least have standardization at the protocol level, but just the same in my opinion it is … unfortunate … that the two largest desktop environments chose to forge their own paths in terms of the implementations of those protocols, with various desktop-specific extensions.
> 1st big paragraph
Yes, I recognize I exaggerated regarding LOC. I should have not said that. I do understand that the core protocol assumes one of each thing. Sometimes I dream about declaring X12 being the same thing as X11 but with the core protocol being converted to just an additional extension marked for deprecation :). Then we also deprecate everything related to drawing and find a way to make compositing great again.
> 2nd paragraph
I did not mean to insult you at all. But let's be honest: if you wanted to spend your time doing something that your employer does not want, you'd either have to do it outside your normal working hours or you'd start getting bad performance reviews due to not being aligned with the business priorities. Red Hat's business alignment has much much much more influence over the Linux ecosystem as whole than people on Hacker News realize or are willing to believe.
> 3rd paragraph
I understand it, and that's why I say things won't change unless someone else with lot of money decides to play Linux Graphics. We can't blame RH for choosing a path and following (to quote a certain someone, "Linux is not about choice", right?). But we do have the unfortunate consequence that RH's decisions are contributing to significant fragmentation. You don't want to have to reimplement the stuff for X+Wayland, but everybody else who does not want to use the Gnome compositor will have to reimplement the stuff you put on Gnome. There's probably a lot the community (not only RH) could try to push to alleviate the fragmentation problems.
> 4th paragraph
I completely understand that.
The organization is called X.Org. The project is called xserver. It contains several display backends. The one based on the model inherited from XFree86 is called xfree86 in the code, but the executable is named Xorg (to avoid stepping on the XFree86 trademark, if memory serves). Its other backends you might encounter include Xvfb for an in-memory virtual framebuffer; Xwin and Xquartz, for running nested under some commercial OS' display servers; Xephyr and Xnest, for two different approaches to running nested under another X server; and Xwayland, for running nested under a wayland display server.
So when I say Xorg is abandoned I'm very specifically referring to the xfree86 code, to running xserver as _the_ display server.
I know enough about X, but. What the heck is wayland?
wikipedia says (display server using the Wayland protocol is called a Wayland compositor, because it additionally performs the task of a compositing window manager.) Whats the compositor doing? Does this effect local linux or only trying to run windows remotely? Xwayland?
I've used X (Xwindows) to run windowing apps remotely (ssh -X) occasionally. It works, excepting that now that I WFH it doesn't.
Linux moves very slowly, but shouldn't replacing X be a great thing?
I guess it would be nice to have Wobbly Windows - but there's nothing about it that is missing for me.
Wayfire got you covered: https://wayfire.org/
As much as I like sway, this smells like bad architectural decisions when so much code needs to be rewritten many times.
The wlroots github page[0] even says so: "about 50,000 lines of code you were going to write anyway".
Seems to me that if there's a necessary 50k LoC that every compositor needs, it should actually be a part of Wayland.
Wayland is an IPC mechanism and a set of core protocols for input (passing keyboard, mouse, etc. events to applications) and presentation (communicating rendered surfaces back to the compositor), not a compositor or a desktop environment in its own right. There is a Wayland library but its only concern is implementing the IPC system. Those 50k lines of code would be out of scope.
The wlroots library implements low-level input processing and rendering functions and various other protocols and standards which are common to all desktop environments; you can think of those 50k lines as a replacement for the parts of the X server which are not directly concerned with input and presentation, such as clipboard support, screen recording, the system tray, negotiation of window roles, and much more. On top of wlroots (or its equivalent) you have the actual compositors, like Sway, which perform the function of an X11 window manager and determine the high-level look & feel of the desktop as a whole.
As part of the transition some of the roles have shifted between the various components, usually for good reason. For example, security is much more of a concern now than it was when the X11 protocol was designed, which is where most of the issues relating to screen recording, mouse/keyboard grabbing, and primary selection (middle-click paste) originate. These things could be implemented just as they are in X11, but the inherent security issues of e.g. any application being able to observe what is displayed or selected in another application are difficult to mitigate without impacting the user experience. The Wayland-adjacent project developers involved are attempting to come up with solutions that actually improve the status quo, not just copy forward all the issues that were present in X11. At the same time I believe it is well understood that simply eliminating screen casting or global key bindings is not on the table; we need to be able to accomplish the same goals even if we have to do it a slightly different way.
The windows (clients) send their local framebuffers to the X server, X sends them to a compositor, the compositor joins them together into a big framebuffer that has the different windows in their respective positions and sends them to the X server. The X server then displays them on your screen.
There's a relatively new (~10 years old) protocol, called Wayland, which will replace X. The architecture is better and it has some other constraints (vsync is always on, so there's no screen tearing). Some distributions are using it by default (Fedora), but most are still sticking to X, since Wayland is not completely ready yet (in practice) and other projects are still transitioning into Wayland.
Maybe I got some technical details wrong, but that's the basic idea.
So basically Wayland replaces the X protocol. (I had to run some things with ssh -X, and windowing on remote machines came back to me..)
And Xserver is replaced by another Compositor which is not specified, but poking around Weston seems like the reference one (towns in metro west Boston?)
No tearing would be nice (I watch someone weekly on a Manjaro install, tearing linux screen share, it can be unpleasant).
I'm assuming a lot this gets abstracted away by QT/KDE , Gnome/GTK so developers can just Develop. (probably at the expense of alternative desktops..)
Just note that a Wayland compositor must implement some core Wayland protocols and it can also implement its own protocol extensions (for example, it can implement a screen-sharing extension, and efforts are being made to 'standardize' these extensions).
It has a long a storied history. The concept of running an app remotely and use a local display server is probably the thing that sets X11 apart from the rest of the pack. This is still really useful in my humble opinion -- I can run X11 apps (e.g. xv) on a headless EC2 server running Linux in the cloud and have the UI/display on my Mac (using Xquartz).
This story runs in parallel with the history of Unix itself.
However, regarding remote setups, is X forwarding significantly superior to using something like VNC? I've never done a side-by-side myself, but most of what I've read indicates that VNC is usually faster.
As a semi-experiment, a few months ago I decided to try running Firefox in a Linux VM, and render it in XQuartz on my Mac host. The experience was not pleasant, to say the least. And that's what I'd think to be the best-case-scenario for latency. Hard for me to imagine using it over WAN.
The more interesting comparison between X forwarding and VNC is that X is really only displaying a remote application locally, not an entire screen or desktop. (Unless you use xnest to run X inside X which is pretty cool.) I used to have a FreeBSD workstation with a browser window running on a Linux server and a bunch of terminal windows spun up on different Sun servers, and you couldn't tell the difference between your local and remote windows. Remote windows are first class citizens in X11.
OTOH, the big strength of RDP is the async stream requests. This gives it a much lower apparent latency than X, but it can also do the VNC thing and render/compress parts of the UI on the remote machine.
XFree86 is a free software implementation of the X Window System.
The whole server/client thing is a bit outdated now, since almost nobody uses actual thin clients anymore. X forwarding is useful, but it's not a mainstream way to do your computing.
Sun also tried to get into this game early with the JavaStations. But they were ridiculously slow, so painful to use. In fact they kind of ruined Java for me. I was learning it at the time, and we got a JavaStation on loan from somewhere. Working on it just established this "Java = slow" feeling in my head and really put me off so much I went to do other things.
Of course this wasn't really deserved, and Java has gone on to become powerful (though I still consider its poor intra-version compatibility an issue). But I've never been able to quite shake that feeling.
The one place that X could use some updating is all the sync method calls, that unlike RDP become quite slow if the network connection has any real latency.
I wouldn't say the one place, but it is a pain point.
(And actually, many of the supposedly synchronous things are not synchronous at the protocol level, but at the C library binding level -- xlib. Nowadays there's a much closer to the protocol binding: libxcb.)
+----------------+ +----------------+
| Client +---->+ Server |
| | | |
| +-----------+ | | +-----------+ |
| |X Server +<---------+Application| |
| +-----------+ | | +-----------+ |
| | | |
+----------------+ +----------------+
XFree86 is a specific X server implementation, though it has been superseded by X.org sometime around 2004 due to a license change from the MIT license to the 4-clause BSD license, which is incompatible with the GPL. X.org is by far the most dominant X server implementation in the free open source software community, but it is not the only implementation; off the top of my head there were proprietary X server implementations for SunOS and NeXT.
My understanding is that the scene for the fork had already been set by the time of the relatively late license change. I seem to recall reading at the time that the XFree86 core team was unhappy that a sole contributor was attempting to modernize the system by introducing extensions, without building consensus around them to their satisfaction.
So the license change was meant to prevent forks from merging in further work on XFree86.
Of course the fork was adding functionality everybody wanted. So the fork survived and upstream languished.
This is a kind of odd retelling/interpretation of events, considering the “rogue” contributor version is the only one that lived and XFree86 is history.
They envisioned a world in which they needed license changes to block the fork from stealing all their work... And worthwhile contributions from their side did not materialize.
Spurred by this discussion I read this old email thread linked by Wikipedia: https://web.archive.org/web/20030821073445/http://xfree86.or...
This is a year before the license change I think?
You will note that Keith is directly blamed for the fork and undermining XFree86. It sounds like there is also resentment for how XRENDER was done, also driven by Keith, but it would seem with more cooperation within the project. We know that the fork was the victor in history and XFree86 looks unreasonable to most observers but I was merely trying to accurately convey the other side in the dispute, without taking their side.
It does seem like there were a bit of tensions between "Linux on the desktop" types (driven by end user visible features and represented by the fork) and more conservative "old hand at X" types present in the thread, resisting such changes, maybe sometimes for good reasons and sometimes for bad. Though when I google around, it seems Keith and others were active in X before the rise of Linux.
Who is using Wayland without X in Asia right now and isn't using English?
That said, the way fcitx works is to use toolkit integration directly, rather than work with the compositor via the input-methods protocol. So it only works for programs using those toolkits. Thus gtk2, gtk3, qt programs will work, but not something like alacritty. (This is good enough for my use case.)
Wayland works really well, I think people who can't use it yet because of features they miss should just use x.org and stop complaining and harassing open source developers. I'm using sway and wayfire but I have no clue how they work behind the scenes or wayland itself.
Wayland is also a protocol and also documented, somewhere. I heard it has support for extensions and they are also in some repo. Search: https://cgit.freedesktop.org/
A big difference between the Wayland and X11 protocols is that X11 covers a lot more things, like drawing. Also, X11 has the concept of a client that is also a compositor and tons of interfaces for clients and compositors and the Xserver to interact. Wayland has none of those things, because the entity that implements the protocol is the compositor, unlike X.
Everything that's not covered by the Wayland protocol or extensions has to be defined/implemented by the Compositor, and that's where Fragmentation is killing us. Each compositor is allowed to implement whatever it wants to deal with those things. I am not aware of any standards here, although I would recommend trying to look if any XDG standards exist for those.
There was an inversion from "Users per to Computer" to "Computers per User" and that model mostly fell out of favor.
NeWS is a better comparison to web browser.
However they were more than a simple terminal. Most of them were basically small Unix computers (like the SPARC X-terminal which was just a diskless low-powered SPARCstation, it could actually run full Solaris). HP's EnvizeX stuff was similarly complex though I don't think they could run HP-UX. But they weren't nearly as 'dumb' as the text terminals of the days.
I still have a few Sun Rays here but they used a very different protocol that only worked with their proprietary software.
However I do expect a return of this model. Now with the cloud, a lot of computing is once again shifting to a central model rather than on the endpoint.
You could sit down at any of the terminals on campus, select the server you wanted to log into, and log into your own account.
It would bring up a fresh instance of your desktop, much like when you boot up your own computer. Except all the files and configuration were on a shared server.
The experience was almost as good as running applications locally, with the added benefit that the applications ran on a big, shared, beefy computer somewhere else, much more powerful than could be placed at each desk.
And you could sit down wherever was convenient to do your work, and have all your files and familiar configuration available.
Back then, most people didn't have their own laptop to work with so that wasn't an option. Those that did, their laptop would be much slower and have a poorer quality screen.
Todays modern desktops with compositing and rendering libraries that can target hardware acceleration and run games and visualisation software on opengl or vulkan aren't well served by network transparency and the X extension model.
The sad truth about X network transparency is that it generally worked better to write to a local screen and then send the screen updates over some other protocol like vnc or nx.
Assuming they do.
Is there any software that can replace the server part of it?
For example in my current work I SSH -X to another machine, and use X apps installed on that machine, any other software can do that?
Although X was remote-capable from early on, it was never especially well designed for remote uses. For example you can't easily detach from a display and move an app to a different display. And it's not very good at latency on a high-latency network. Partly that's because of how it assigned XIDs in the protocol; they should have been client-assigned. It would still be possible to make that change (as an extension) but it hasn't been done.
It would be great if there was a modern remote desktop application protocol, that works well over all kinds of networks and allows application windows be moved between different display clients easily (e.g. from your laptop to your desktop at work). Or even better, let the application move as well, for ideal responsiveness everywhere.
I think we will get that eventually, because it's such a natural evolution of all the distributed things we're building. But I think it will be a long time coming.
Indeed it's not great at high-latency, it was invented for rooms full of local X-terminals (that were on constantly so connection loss wasn't an issue either, unless someone messed with the cable terminators :P )
I would love for this to continue being developed though, as there is still a great usecase for it IMO. But the protocol could really be cleaned up removing a lot of round-trips with locally cached variants (basically what NoMachine NX and X2GO are doing).
I do agree it makes sense in this increasingly cloud-centric world.. I hope it will eventually come too!
Windows has Xming and Cygwin. Mac has XQuartz. Linux, well, has Xorh and Xwayland. Even on iOS and Android there's X servers.
The ecosystem is still powered by the community. I see a lot of patches coming from hobbyists in many related projects.
If you read other comments in separate parts of the threads here, you’ll see people describing re-scoping certain elements “out” of Wayland and “into” other layers to fix “broken” parts of X. Those “widely agreed upon” solutions for other layers exclude considerations for the way OpenBSD works in fairly fundamental ways that make it seem (to me, at least) there is no practical purpose in exploring Wayland on OpenBSD beyond the point it has already been explored.
I’m speaking about the coherent and supported OpenBSD operating system, not what can be found in packages.
If there ever become features fundamental to the current user-developers of OpenBSD that are enabled by Wayland, I would expect them to further modify Xenocara to support those use cases, but it is hard to even imagine what those could be. Most of Wayland’s promised future features are anti-features to the OpenBSD approach.
I expect that in 5-10 years, many user applications will be Linux-only, and there will be many conversations about how stubborn BSD (and Windows/Mac) designers are for not aligning to earlier decisions made on their behalf.
These are just my personal opinions with no inside knowledge from any part of this intellectual territory, and I do not accuse or blame ANY developer on ANY project for working on what they are interested in, but I expect this unified Linux (and Linux-only) outcome is the unstated but express purpose behind promoting Wayland for some of the commercial interests that support it.
I want to doubly emphasize that I am talking about the motivations of executives determining the allocation of capital and human resources, not about the motivations of the developers, which are clearly to facilitate cool or useful new things.
The driving force behind Wayland appears to be commercial interests that have no interest in the desktop use-case per-se.
The linux-only outcome is purely an unintended side-effect.
Windows & Mac are already on exclusively Wayland-style compositors, they made that transition years & years ago (Vista was Microsoft's transition, for example, which was 13 years ago now). Why would they have any issues here?
Only in a narrow sense; nearly all of the features one might reasonably consider fundamental parts of Windows/Mac are “out of scope” for Wayland. Wayland relies on layers upon layers of other solutions for things like central registries, interprocess communication, and negotiating hardware access.
From the Wayland perspective, this is all perfectly reasonable. It’s just how software gets made.
From the perspective of someone who isn’t already running a Linux kernel with evdev + KMS + DRM, we aren’t able to even find common language to discuss what being “a compositor” means to Wayland.
Wayland is one thing, not an X replacement. There is, unfortunately, not a great story/push to standardize all the other parts of X outside of Wayland's scope.
But it's important to recognize those other parts are also very much not handled by the Wayland-equivalent on other OS's, either. Window's DWM doesn't do clipboard management. Android's SurfaceFlinger doesn't do input. MacOS's QuartZ Composer doesn't do global keyboard shortcuts. And from an app perspective, none of those other OS's conflate those random unrelated things in the way X did, either. They aren't part of the same library or technology group. As in, you'll never find clipboard references in CoreGraphics. You use NSPasteboard which talks to the pastboard server, instead. Entirely unrelated & orthogonal to the compositor, as it should be.
Only on Linux is a full desktop environment stack shoehorned into what's supposedly a display manager.
A question like whether or not IPC and application buses are managed by a supposed display manager is a more complicated decision than it appears on the surface, with lots of questions that need to be asked that feel like you’re challenging the literal meaning of words depending on which contextual paradigm you’re approaching the discussion from.
The net result is Wayland being a reasonable solution to a real problem that still further isolates Linux into a GUI desktop silo. The result is only “cross compatibility” if you consider the “cross” to mean across Linux distributions, which - in fairness - is actually what most people DO seem to mean.
In the same way that X's unique snowflake design hasn't significantly impacted cross-OS compatibility, why would Wayland make this any harder? If anything Wayland reduces cross-OS complexity as you can finally have a compositor API on Linux like you have on literally every other OS, which greatly reduces the friction for things like embedding video within an app.
But otherwise right now on any cross-OS application the design is going to assume that composition, clipboard, and keyboard shortcuts are all independent systems. Only on X is that not true. X is the unique, unorthodox design in the broader world of "all OSes"
The trouble here for those who use Unix-likes as graphical programming environments is that Wayland is the intended replacement for Xorg, and the quoted statement comes from the perspective of making products for non-technical end-users instead of something power-users (like many of us here) can use efficiently. I will not claim here that it is theoretically impossible for efficient graphical programming environments to be based on a Wayland compositor, but the facts are firstly that currently Wayland based systems are a downgrade compared to Xorg (I think the Wlroots/Sway is currently the only compositor that tries to cater to power users, and the issue with Wayland is also that support from the compositor is necessary and difficult for almost any feature), and secondly that the Wayland design is hostile to features that power users are already accustomed to from X Windows. More broadly, Wayland is actually hostile to features like screenshots that all users of other operating systems are accustomed to, meaning that Wayland is actually causing an unnecessarily ugly image of Linux systems among users of other systems. Causally related to the above is the fact that the Wayland design necessitates great duplication of effort for both compositor implementations and applications that want to be able to use more than one incompatible compositor.
Three days ago there was a discussion here on basically the same topic, and because my comment there[1] is completely relevant, I'm going to mostly just copy it here:
A too common complaint about Wayland (or Wayland compositors, more specifically) is that it is taking a long time to catch up to X11. The elephant in the room is that this situation stems from a deeper issue: Wayland has a horrible design, for an X11 replacement, a design that leads to massive fragmentation issues across the graphical part of the Linux ecosystem. Implementing a Wayland compositor requires much more effort than implementing an X11 window manager and each new compositor implementation reinvents the wheel many times, leaving users with less options for a desktop environment than on X11. Even worse, Wayland does not standardize on or is hostile to some essential features, meaning that users need to rely on compositor specific behavior for those features, if they are even available. E.g., an application that needs to grab the entire screen will need separate code for each compositor it supports screenshots on, or it must use a protocol outside Wayland to get the screenshot. Quoting Red Hat: > Furthermore, there isn’t a standard API for getting screen shots from Wayland. It’s dependent on what compositor (window manager/shell) the user is running, and if they implemented a proprietary API to do so.
An xdotool (an input event automation tool, imagine wanting to inject or intercept input events) replacement is not possible on Wayland (without having separate support for each compositor, of course). These seem to be intentional design decisions (marketed as being necessary for security, but really being power-user hostile), this[0] Reddit comment puts it nicely:
> It has been almost a decade, why does Wayland not have a protocol definition for screenshots?" - answer - "Because security, dude! Wayland is designed with the thought that users download random applications from the interwebz which are not trustworthy and run them. Wayland actually makes a lot of sense if you don't think of Linux desktop distributions and desktop systems, but of smartphones. But for some reason we absolutely need this technology on the desktop, like we had not enough pain and lose ends over here without it.
But the lack of these features AFAIK also causes big trouble for users with special accessibility needs. Wayland is also, with its forced composition, hostile to interactive applications requiring low latency, e.g. video games.
[0] https://www.reddit.com/r/linux/comments/7lb5l7/new_screensho...
That said- Wayland might be the only future but I'm not convinced it is the present. It still misses a specified way to handle shortcut keys and screenshots.
But I'm not even sure what to do about Wayland, other than switch to Fedora and meet that people that use it. I'm in a complete we-all-wish-we-were-using-wayland-but-aren't bubble. It's unfortunate.
Ajax seems pretty open in his invitation for people to come and help maintain the things RH doesn't care about anymore...
I think you may have misunderstood the commenter you replied to: they were probably referring to the careless breaking of backwards compatibility that was being done while Xorg was still nominally being maintained. I think a good example is refactoring the Server while silently breaking extensions they don't care about.
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/3...