On Abandoning the X Server(ajaxnwnk.blogspot.com)
ajaxnwnk.blogspot.com
On Abandoning the X Server
https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server.html
419 comments
I can find Wayland equivalents for my compositor for all of these tools:
https://github.com/swaywm/sway/wiki/i3-Migration-Guide#commo...
https://github.com/swaywm/sway/wiki/i3-Migration-Guide#commo...
Ok so I've mainly used Windows, but I got a secondary machine with Linux, which for the last few years has been running KDE Neon which I rather enjoy.
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.
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 most likely runs as a native Wayland application. Though for any legacy apps/games that use X, yeah they'll run in XWayland and should be seamless.
Right... seamless...
https://gitlab.gnome.org/GNOME/mutter/-/issues/1065
https://gitlab.gnome.org/GNOME/mutter/-/issues/1065
>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?
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.
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.
> Kile
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.
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.
> 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.
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.
Just to take a couple of examples from that list:
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.
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.
I find this comment deeply ironic.
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.
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.
> 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.
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...
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...
My opinion - today - is that X doesn't work on laptops where the user expects to use a touchpad. Nor does it work on a laptop with a resolution that requires scaling (at least not the second you plug in another display).
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.
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.
> My opinion - today - is that X doesn't work on laptops where the user expects to use a touchpad. Nor does it work on a laptop with a resolution that requires scaling (at least not the second you plug in another display).
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.
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.
Funny, I'm writing this on a Arch/Gnome/Wayland XPS machine, that I use as my daily driver. So clearly it's not "literally unusable".
> 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.
> 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.
> 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!
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!
Honestly - It sounds like it's been a minute since you've tried it.
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
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
> Now, all that said, if you've tried recently and it's still not there, I absolutely get it.
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).
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).
> Global hotkeys work pretty much everywhere
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.
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.
The GNOME Settings app allows you to assign global hotkeys under Wayland using the normal GUI [1]. Not sure about configuring those hotkeys in a config file like i3/sway, I assume it’s some dconf thing.
[1] https://help.gnome.org/users/gnome-help/stable/keyboard-shor...
[1] https://help.gnome.org/users/gnome-help/stable/keyboard-shor...
> My opinion - today - is that X doesn't work on laptops where the user expects to use a touchpad.
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.
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.
"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."
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...
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...
Nobody is forcing you to use Wayland. Nobody is arguing that X.org's server will disappear from the face of the earth.
> Nobody is arguing that X.org's server will disappear from the face of the earth.
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.
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.
I'm sorry, this sounds like some strange mix of entitlement and unwillingness to explore new solutions.
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?
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?
> ... entitlement and unwillingness ... You don't want ...
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?
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?
X disappearing from the face of the earth would be a great thing for wayland, because people would be forced to fix the remaining issues.
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.
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.
> people would be forced to fix the remaining issues.
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 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 issues can’t be ‘fixed’ in the Wayland protocol, but have been addressed by individual compositors and libraries like wlroots. The difficulty is not in building a decent Wayland desktop from scratch (GNOME, Sway and ChromeOS have all done this), but in rewriting X11 window managers, screen sharing apps and automation tools that perform functions that are the compositor’s responsibility under Wayland.
Why would they be forced to fix the remaining issues instead of telling users they don't really need the features that they have deprecated?
>as the platform under it (the hardware, the kernel, etc.) changes to the point that it becomes non-functional.
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.
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.
That's precisely what people are arguing. That's precisely what Kristian Høgsberg wanted from the get-go: for X to simply go away, except as a compatibility layer for "legacy applications". (And I bet Xwayland will eventually be deprecated and unsupported, except for Red Hat's government clients or something.) X has been quasi-officially deprecated for years now, with Wayland offered as its replacement.
> (And I bet Xwayland will eventually be deprecated and unsupported, except for Red Hat's government clients or something.)
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.
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.
s/That particular X developer/All X developers, except maybe for Keith Packard/g
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.
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.
Or, we could just use X if it still works for us. I don't need any "more powerful and knowledgeable forces" to tell me what works for me and what doesn't.
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.
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.
Yeah, except what happens when the apps and toolkits you use drop X support because they consider X a dead end? What will you do then?
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.
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.
At that point the Wayland ecosystem is hopefully mature enough to make the switch less painful than it is now. I don't see anyone saying they'd rather toss their computer in the garbage than ever use Wayland, just that it doesn't currently meet their needs.
I do not think it is wise to spread fear. Fear is the reason people attack Wayland.
Lets keep them separate. I have no PulseAudio, solved Skype with apulse, though I don't use much media except browser, player and tuner.
Lets keep them separate. I have no PulseAudio, solved Skype with apulse, though I don't use much media except browser, player and tuner.
Same as with ALSA - I either stop using those apps, patch ALSA/X11 support back in or use wrappers to do the translation for me.
This is an interesting dichotomy. Alternatively just keep using X until 2030. If X does everything you presently care for well and major apps like gimp and firefox are apt to support X for the next decade an alternative contribution might be bug fixes for X or packaging for distros that opt to continue to support it.
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.
This is an interesting dichotomy. Alternatively just keep using X until 2030-2040. If X does everything you presently care for well and major apps like gimp and firefox are apt to support X for the next decade+ an alternative contribution might be bug fixes for X or packaging for distros that opt to continue to support it.
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".
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".
> When about do you think firefox will no longer build for X?
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.
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.
You can still build Firefox with Alsa support and probably still will be able to in 2025.
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.
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.
The other option is to maintain X. I'm not interested in that, and since thise who have done that in the past agree Wayland is the future I'm cautiously going to trust them and so I'll transition my systems to Wayland (if they are still x).
I said this last time, but ydotool probably won't ever have the same features as xdotool because the scope isn't the same. A lot of the X commands in xdotool don't even make sense in the context of wayland, so it would be unreasonable for them to have the same scope.
As an end-user, the fact that Wayland can't do what I need while X can is a black mark against Wayland.
I don't understand where you're getting this idea that Wayland is or was supposed to do all the same things as X in exactly the same way. It's not, that's the entire point. As an end-user you can continue to use what works for you. Yes X is much more flexible at some things (and Wayland is more flexible at others) but it comes at a cost which is expounded on by the article.
> I don't understand where you're getting this idea that Wayland is or was supposed to do all the same things as X in exactly the same way. It's not, that's the entire point.
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?
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?
Please tone down the rhetoric, I'm not blaming anybody. X is still included on those distros as a fallback option in case you have something that doesn't work.
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)
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)
> Please tone down the rhetoric, I'm not blaming anybody.
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.
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.
cycloptic(3)
> 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.
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.
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.
And regarding global hotkeys? Something which before would involve going into an application's settings and seeing "Choose hotkey for X", a la Windows, now involves going into the compositor's settings, adding a hotkey, knowing what the command line is and how to achieve X via the command line, understanding how launching commands can affect already-running instances of applications, adding a hotkey there...
That seems distinctly anti-grandma.
That seems distinctly anti-grandma.
I think we should acknowledge many people have grandmas who build desktop operating systems, so this is perhaps a source of misunderstanding :b
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.
[1] https://en.wikipedia.org/wiki/Keystroke_logging
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.
[1] https://en.wikipedia.org/wiki/Keystroke_logging
About global keybindings.
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.
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.
> Global hotkey bindings? Sure, that works on Windows, macOS, and X, but it doesn't on Wayland and its your fault for expecting it.
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!
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!
Wayland is not currently the default on Ubuntu.
Doh, my bad, you're right. I... think? they were planning to make it the default in 20.04 and then they backed off.
> I don't understand where you're getting this idea that Wayland is or was supposed to do all the same things as X
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.
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.
The article also includes a call for developers that want to help support X.
Yes it does, but that's not going to stop people from expressing themselves online or discuss the disadvantages of what's coming.
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.
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.
It does nothing good. It is not Wayland fault that distribution decided to switch. It is not Wayland fault that no one wants to maintain X.Org.
The right call would be kickstarter, patreon, any kind of sponsorship.
The right call would be kickstarter, patreon, any kind of sponsorship.
"it comes at a cost which is expounded on by the article."
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.
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.
Those are all quotes that are referring to it, as well as this one:
>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?
>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?
Daniel Stone, The real story behind Wayland and X (Or, 'Why Everything You've Read in LWN and Phoronix Comments is Untrue')
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.
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.
Yes, the missing scope is the problem!
>on my compositor
Yikes! So just more fragmentation and half-baked alternatives.
Yikes! So just more fragmentation and half-baked alternatives.
This is actually an extremely important point.
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.
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.
Indeed. I wonder if these alternative tools are guaranteed to work no matter what compositor the user chooses for their computer. In X, the user has complete freedom over their WM and the tools will always work. You can build confidently on top of them. I'm concerned the same can't be said of Wayland.
Why don't these compositor developers just get together and standardize?
That's what wayland-protocols [1] is for.
[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols
[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols
And dbus for things that aren't in-scope for Wayland itself.
That's kinda the full issue in standardizing. Gnome wants dbus for everything while sway wants wayland extension most things as they avoid using dbus code. So stuff like xsettings/xrdb or screensharing replacement has basically has wayland extension and a dbus API.
It looks like thanks to Wayland being more modular, there is even more room for fragmentation. X had its fair share of extensions, but somehow most WMs and DMs managed to agree on things.
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....
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....
"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."
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).
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).
How did any of that JavaScript have access to anything that would let it affect X?
> I guess X needs to keep chugging along a couple more years....
Likely at least a decade (Lindy effect).
Likely at least a decade (Lindy effect).
I’m sure there’s good reasons for this design decision but this overall situation is why Linux display will never hold a candle to Windows or MacOS or iOS. This kind of thing should just be monolithic, if not architecture then in politics. The people writing all the different components should answer to the same unit tests, the same specifications, and the same boss. A truly great solution needs unity of vision and unity of design.
This is why the org.freedesktop.* namespace exists. Very few people complain about org.freedesktop.Notifications not being portable. The next ones on track are org.freedesktop.Screenshot and org.freedesktop.Screencast.
We already see this with global hotkeys/shortcuts - some compositors support it and others not, and how to configure it is not unified. :)
Correction: on my compositor and all compositors implementing the protocols wlroots pushes forward. This includes Sway, but also all wlroots-based compositors, and for some protocols also KDE and Mir.
And I can develop on an ancient Thinkpad if I want. But I'm not going to claim that's the best UX.
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.
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.
Hell, I'd be happy if there was just fewer bugs.
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...
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...
I think pipewire broke my audio when I upgraded to Kubuntu 20.10. Removing it fixed it and seems to have had no ill effects.
Pulseaudio used to break everything, and I used to delete it to fix them. Gstreamer used to crash a lot.
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.
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.
Pulseaudio doesn't crash any more, true. But it still uses gobs of cpu to play audio and has other idiosyncracies that I have no idea how to work around. For example, I have no volume control in the GUI for the headphone port on the front of my computer, but I can control it just fine using alsamixer. After hours of trying various suggestions I've just decided to control my volume from the terminal and move on with my life.
The trouble with your guake bug is it might be Gnome + Wayland specific. With the separation between the server and composer, bugs might need to be fixed in multiple places. Some window managers use wlroots, so maybe some bugs can be fixed there, but others have their own forks and implementations.
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.
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.
It's not that they're user-hateful it's just that they're (I think rightfully) being aggressive about scoping Wayland to things related to drawing surfaces and handling input events. If people started treating as one domain specific protocol that display servers use for drawing stuff on the screen and not "everything a desktop app might want to do" protocol there would be less conflict.
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.
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.
So what does a Wayland-only future look like? Your clipboard, keyboard hotkey daemon, app runner, etc. all communicating happily over D-bus?
Clipboard is handled by Wayland. Global hotkeys also needs to be handled by the Wayland compositor in some way since only the compositor has access to the full stream of input events. The compositor might choose to offload input events for known global hotkeys to some helper application, like kglobalacceld on Plasma.
Exactly. What we’re really seeing here is technical debt from the fact that we have so many different desktop environments. Much of the cost of having Gnome and KDE was hidden by the fact that a lot of the job of putting pixels on the screen and handling keyboard and mouse events was done (very badly) by X in one way or another.
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.
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.
I mean, from my perspective, they're literally prioritizing the things that I want my display manager to do well
- 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.
- 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.
> the same crowd
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.
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.
Entirely fair.
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.
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.
Namely that the "angry" that happens to be getting selected for has nothing to do with the merits of either piece of software,
What, you don't think people have legitimate criticisms of Systemd, or Wayland?
What, you don't think people have legitimate criticisms of Systemd, or Wayland?
[deleted]
No, I think there are plenty of fair criticisms of both. Just like there are plenty of fair criticisms of init and X.
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.
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.
It's not fear, it's resentment: the old ways worked, and often worked quite well, and everyone has mostly settled on reasonable ways to work around where the old ways were broken; the new ways quite simply don't work in ways that the old ones continue to work just fine, and we resent being forced to lose functionality we appreciate having.
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.
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.
> 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.
[1] https://devuan.org/
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.
[1] https://devuan.org/
> Imagine world where there is no Wayland, how is it better? I fail to understand who forces you.
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 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.
No, without Wayland there would be stagnation. Less users, less corporate sponsorship, less developers.
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.
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.
You bring up a good point, it's something to think about.
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 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.
What is interesting, is that you can tag people friends or foes. When you friend someone, suddenly you can see icons appear on other accounts: friends-of-friend (green/red pill), and foes-of-friend (green/green pill).
I never got the impression that the tagging system is widely used, however.
I never got the impression that the tagging system is widely used, however.
I can work with a system running on systemd, upstart or old good init but I cannot work without screen sharing especially now that everybody is working remotely. I can probably survive with all the other missing features but not this one. I'll consider Wayland only when all the different softwares my customers and friends use will work on it as they do on X.
But remote desktop just barely works on Linux. X forwarding is slow, VNC is buggy especially when certain applications packages expect hardware acceleration, and don't even get me started with all the issues with the keyboard mapping that can arise application to application. Meanwhile in Windows the remote application is close to flawless.
Maybe Wayland is solving that, I really don't know. However I don't need them. What I need is screen sharing in Slack, Meet and TeamViewer and that works with X. I also occasionally need Skype, Webex, Zoom, Jitsi and Teams. They also work with X. I'm confident that any random system my customers throw at me will work with X if it's advertised to work on Linux. Not so much if I were running Wayland.
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.
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.
Screen Sharing works fine for browser based videoconferencing like Jitsi.
Some apps like AnyDesk just haven't invested in support for Wayland, while shovelware like Zoom tries to force you to install their client.
Some apps like AnyDesk just haven't invested in support for Wayland, while shovelware like Zoom tries to force you to install their client.
> Some apps like AnyDesk just haven't invested in support for Wayland
That they have to invest work for simple functionality to work is the problem. Until Xwayland can support this, Wayland is broken by design.
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've been using NoMachine on my local network for a while, it's fast enough and works on Windows, OS and Linux (you can just about play video over it even).
I haven't looked into iOS and Android.
I haven't looked into iOS and Android.
I'm really going to have to explore this option. Does it have encryption capabilities?
> This reminds me of the systemd arguments all over again
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.
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.
A few years ago I had a bug like this under X + Noveau + GNOME, where Windows were reporting the wrong coordinates.
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.
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.
> Hell, I'd be happy if there was just fewer bugs.
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.
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.
Yeah, I'm not sure why the entire X protocol had to be thrown away. I suspect for a while the shiny new desktop stack will just be X on Wayland until someone writes a Wayland compositor that is also an X server just without the bits that can't work. One
of the reasons for Wayland was fast compositor updates, but I still don't see why the compositor and window manager have to be one and the same, you could delegate management to a wm and present the full window. Heck, you could also replace Xlib and xcb with versions that know when they're running locally and skip the network protocol for most operations.
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.
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.
I switched to Sway recently. I couldn't believe how snappy it is.
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
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
> Wayland is only supported by compositors that implement the wlr-layer-shell protocol. Typically wlroots-based compositors.
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.
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.
I don't know why people are so afraid of fragmentation in this respect. There are lots of "de specific" protocols that are well supported everywhere like org.freedesktop.Notifications.
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.
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.
I'm personally concerned because I like to use "niche" tiling WMs (I used Ratpoison then StumpWM for over a decade, then I switched to a rather heavily customized DWM a couple of years ago).
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.
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.
There are tiling window managers for Wayland. Sway is one that is meant to maintain configuration file comparability with i3. But yes, obscure tiling managers will need to be rewritten for Wayland.
I'm looking at sway and it looks promising (although I wonder how it deals with the many weird corner cases that X11 tiling WMs have had decades to fix and work around) but Sway's home page linked to the wlroots project which is:
>[...] 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.
>[...] 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.
The more I learn about this, the more I start to think that there needs to be some kind of middleware library implementing all these missing features from Wayland that all Wayland compositors are going to to need anyway.
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.
In fact, this library could even be protocol-agnostic, and be able to talk to both Wayland and X.
>The more I learn about this, the more I start to think that there needs to be some kind of middleware library implementing all these missing features from Wayland that all Wayland compositors are going to to need anyway.
>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".
>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".
Wlroots is the middleware library. Other wayland tilling wm use it as well.
> dwl - dwm for Wayland
> dwl.c, 2000 LOC
https://github.com/djpohly/dwl
wlroots should be compared with X.Org Server, 370000 LOC
https://github.com/freedesktop/xorg-xserver
> dwl.c, 2000 LOC
https://github.com/djpohly/dwl
wlroots should be compared with X.Org Server, 370000 LOC
https://github.com/freedesktop/xorg-xserver
> My DWM is 3k lines and it's fully featured as far as I'm concerned.
For fairness, you should count the hundreds of thousands of LOC in Xorg as well. From that PoV, 50k might actually be pretty lean.
For fairness, you should count the hundreds of thousands of LOC in Xorg as well. From that PoV, 50k might actually be pretty lean.
Rewritten and add compositor functionality.
What you fear is sadly true. See my top-level comment in this thread for some elaboration.
I tried a bunch of tiling window managers over the last two years, and found that the choice of X11 or Wayland does not make much of a difference with regard to the “second class citizen” effect you described. What finally solved it for me was switching to GNOME (ie. mutter on Wayland) with the PaperWM extension. Fundamentally, I’m running a conventional desktop with no tearing and standard, widely used solutions for keyboard shortcuts, the clipboard, screenshots, and floating windows, so graphical applications look and feel correct even if they are a bad fit for the tiling model. Tiling is then implemented by PaperWM at a higher level, in JavaScript, leaving the complexities of hardware accelerated, animated compositing to GNOME. It’s a good combination – I’d like to see more tiling window managers designed to take advantage of hardware-accelerated compositing.
> 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
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.
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.
>Wayland is a shiny new thing
It's 12 years old
It's 12 years old
It usable since 2 years for my definition of usable.
It breaks multiple things for me and does nothing of note I care about. The things I want to work will either never be fixed or will be fixed in the distant future.
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.
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.
With any luck, civilization will collapse first and provide a reprieve.
> There are lots of "de specific" protocols that are well supported everywhere like org.freedesktop.Notifications.
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
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
I had this as well with Mumble. The problem was that I didn't have a notification daemon running, so the application was timing out trying to connect to the respective bus. Autostarting a barebones notification daemon like Mako fixed the issue for me.
KDE and Mir already implement some wlroots protocols. We (wlroots) try to get as many compositors as possible on board.
Is wlroots still incompatible with Nvidia hardware?
Nvidia still doesn't implement the de-facto standard API used by everybody else (GBM).
So yes, wlroots is still incompatible with Nvidia hardware.
I guess I see that as Nvidia being incompatible with wlroots. Nobody but Nvidia can do it, and Nvidia, for all its $billions, can't.
Is there a standard for global hotkey configuration, so that apps can configure some of their own?
> I switched to Sway recently. I couldn't believe how snappy it is.
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!"
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!"
On what benchmarck can we measure this? Phoronix regularly show that Wayland is slightly slower than X.
It could be mostly subjective - lack of "jank" can go a long way in terms of making UIs feel faster and nicer to use.
I'm not surprised: one of Wayland's goal is to produce 'perfect frame' at the very least this has a latency cost..
I have yet to see evidence that Wayland has less artifacts/tearing than X.
Wayland does not has such a thing: https://www.phoronix.com/scan.php?page=news_item&px=Radeon-T...
Also Wayland probably has less support for adaptative sync (which is the biggest feature regarding what you call a perfect frame)
> less support for adaptive sync
What does "less support" mean? At least on my system, Sway is running with adaptive sync enabled.
What does "less support" mean? At least on my system, Sway is running with adaptive sync enabled.
Sway is the only Wayland compositor to supports freesync
> Until Wayland has all these (and more) and they are as stable and feature-rich as the existing apps on X, I will not willingly switch to Wayland.
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.
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.
xcape and the compose key are really killer tools. Not having them would really screw with productivity
FYI There are lots of alternatives to xcape (and even better ones because, in my experience, xcape is not compatible with VirtualBox or hot-plugging one's keyboard), e.g.:
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:
https://github.com/myfreeweb/evscript
https://github.com/wbolster/evcape
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:
https://github.com/myfreeweb/evscript
https://github.com/wbolster/evcape
Thanks for the links!
Man reading this thread confirmed that I probably shouldn't even attempt to use Wayland in the near future, I basically use every single of the features you've listed.
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 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.
I always get downvoted for saying this but anyway. Wayland needs the Nvidia problem to be solved. I don't see how it's sustainable to have to build everything for GBM and EGLStreams.
Yep. People can complain about Nvidia’s refusal to comply to standards as much as they want, but at the end of the day, there is never going to be widespread adoption of Wayland until Nvidia hardware is fully supported.
Probably because it is solved?
> EGLStreams (NVIDIA): GNOME, KDE, Weston
https://wiki.archlinux.org/index.php/wayland#Requirements
> EGLStreams (NVIDIA): GNOME, KDE, Weston
https://wiki.archlinux.org/index.php/wayland#Requirements
> I don't see how it's sustainable to have to build everything for GBM and EGLStreams.
That's life.
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...
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...
[deleted]
I would not consider this examples "Applications", but more configuration tools. I would also not expect to be able to port the OSX Clipboard manager to Windows or the "Displays" utility. From a new window server I would expect to have some ways to configure output, switch applications, manage clip-board but I would not expect to have my existing tools continuing to work.
If you are re-architecting a system from the ground-up there is always some fallout expected.
If you are re-architecting a system from the ground-up there is always some fallout expected.
> I would also not expect to be able to port the OSX Clipboard manager to Windows or the "Displays" utility.
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 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.
Wow.
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...
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...
I recently switched to Sway on Wayland. Sway has good dynamic output configuration. `wl-clipboard` and `wl-paste` are there for CLI clipboard access. There's a rofi fork that works on Wayland, and can also emulate `dmenu`. `clipman` is Wayland compatible. I use `grimshot` with `rofi` integration for screenshots. I have a HTML Color Picker script for sway that's launched from `rofi` that I should share. `ydotool` and `wtype` emulate the parts of `xdotool` that I care about.
Also, there's no longer tearing when I resize windows!
Also, there's no longer tearing when I resize windows!
You kinda just need to use new stuff when it's all so heavily dependent on an X server.
* 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)
clipman, for a clipboard manager.
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)}'
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)}'
May I recommend CopyQ as well? I moved to it when Plasma changed Klipper some time ago and I am quite glad I did. Can even install it on Windows in a portable fashion.
I can't shake the feeling that I can do so much with it yet I'm barely scratching the surface as user, it's quite powerful.
+1 for CopyQ from me, it is awesome.
Yeah no, requiring users to switch applications makes your display server DOA.
The problem with Wayland is really that people understand it to be a drop-in replacement of X11, or something close to it. But it's not a replacement of X11. You don't "switch to Wayland", despite what that GDM button seems to indicate. Wayland is just a protocol, whereas X11 is a protocol and entire system around it.
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.
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.
Deprecating Xorg and providing no replacement standard/protocol for almost everything it does and enables is kind of the whole problem, isn't it?
No matter how horrible X may be, it has a lot of value for end users. Almost all of this value is in the ecosystem around X.
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.
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.
To be fair to """Wayland""" (again, whatever that means), Gnome on Wayland seems to be a lot better when it comes to the core smoothness of the desktop experience. I have never seen tearing on Gnome on Wayland, and with X11 I saw it every day. I haven't used KDE on Wayland extensively, but in my short time with it it was a lot less glitchy graphically speaking than X11. For all the shortcomings of the """Wayland ecosystem""", there seems to be true technical merit Wayland has over X11. If only because it fundamentally solves X11's buffer sharing problem.
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.
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.
I think tearing may be one of those personal preferences where the population is divided down somewhere near the middle, but people on either side can not fathom the existence of the other as anything other than some sort of bad-faith exercise in contrarianism. At least, I for my part could never imagine ever willingly giving up a "real feature" (my perception!) like xdotool for the cosmetic benefits of no tearing (which to me feels like a problem on the importance level of "getting the blinky blue LEDs on your GPU fan to work"), but at the same time there is clearly a large number of people on tech support forums, stackexchange etc. to whom it is of show-stopping significance, as evidenced by the effort and time put into achieving non-tearing and how often it is presented as a self-evident killer feature of systems like Wayland.
That tearing issue even comes from a tradeoff space: a couple days ago on another thread about X people were noting that to avoid the tearing Wayland seems to have higher latency, and some people (and I would be one of them, were I to experience this) care way more about lower latency than "never ever ever see tearing".
I can't find the story you're talking about here, but one thing that would be good to understand here is whether this is some flaw in the Wayland protocol, or whether this is an implementation issue in a specific Wayland compositor like Gnome's Mutter. People tend to blame a lot of issues resulting from immature implementations on some unspecified "Wayland" (whatever that means).
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].
[1]: https://github.com/swaywm/sway/releases/tag/1.4
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].
[1]: https://github.com/swaywm/sway/releases/tag/1.4
...which was a peculiar discussion because I don't think anyone mentioned that just about everyone runs X today with some combination of DRI2 or DRI3, which involves plenty of latency, boundary-crossing, and buffer-copying.
> The compositor is evil
> 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.
https://news.ycombinator.com/item?id=24466929
> 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.
https://news.ycombinator.com/item?id=24466929
> but people on either side can not fathom the existence of the other as anything other than some sort of bad-faith exercise in contrarianism.
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.
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.
> 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.
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.
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.
In other words you believe distro maintainers does bad job. They push product that is not ready.
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.
https://news.ycombinator.com/item?id=24925189
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.
https://news.ycombinator.com/item?id=24925189
I equate obsession with tearing with not being serious about the topic. I can't think of any single thing that tearing ever interferes with getting done.
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?
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?
I would agree with you about not seeing tearing... except that it only applies to the "desktop experience". Any time I'd watch a video with, say, VLC media player, I'd get absolutely horrendous tearing that was nearly unwatchable. And upon switching to Wayland it would all disappear.
I'm really surprise at the tearing argument here. I've had Nvidia, AMD, Intel and Matrox graphic cards, sometimes on Intel other on AMD, so I've known tearing ... But that have been fixed for me with the introduction of double buffering and GL compositor. Waaaayyy before Wayland even existed. So that argument does not really fly with. Granted, internally those combo are ugly and clunky. And Wayland might have a cleaner design.
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.
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.
"Wayland is just a protocol, whereas X11 is a protocol and entire system around it."
This statement doesn't make sense to me.
This statement doesn't make sense to me.
Wayland is a display protocol.
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.
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.
Yes, and I don't want to switch to a pure stack from _any_ desktop environment. I want all these things to easily mix and match. And for all these things outside the pure wayland protocol (and some supposedly inside it), they don't.
I'm not sure why that's your takeaway here. Wayland exists precisely because things should easily mix and match - it should be easy to get your apps displaying/moving on any standard compositor. The same would go for other Freedesktop standards to do things like input, clipboard interaction, and screen recording.
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
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
Except wlroots cannot be the standard library due to the NVidia problem. Even after that is fixed, the different implementations are far enough along they will never be merged. We will have at least four duplicate not entire compatible implementations for the near future.
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'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.
It looks like a ton of common functionality is not ready yet. It is dispersed among DEs, and this is not convenient.
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.
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.
Maybe the problem is precisely that Wayland is not an X replacement, because that has led to a situation where there is a certain mismatch between the different pieces of the stack. Few people really understand what Wayland actually is, and how it works, and how it all fits together, which means only few people are actively working on the ecosystem.
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.
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.
> Maybe the problem is precisely that Wayland is not an X replacement
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.
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.
That is all true, but the question then becomes whether Wayland will ever be widely adopted. For most users X is good enough, and replacing it with a quasi beta-quality implementation is not appealing to them. As long as there is only a very small group interested in developing the Wayland ecosystem, it is unlikely ever to get to the point where users (or distros) can be convinced to adopt it.
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.
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.
Yes, this process of moving away from X11 has been terribly mismanaged - by not being managed at all really. But it's not quite as dire as you're saying.
> 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.
> 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.
Wayland has been enabled by default on Fedora for nearly 4 years, on Debian for 1.5 years, and on RHEL/CentOS for about the same (the GNOME editions in each case).
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.
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.
There are more than 3 Desktop/Window Manager in the Linux/Unix world, right ? What happen to the others ?
> Wayland has been around since 2008, and it still seems more like a tech demo
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.
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.
What did Wayland accomplish? What did X not?
This was so predictable, though, considering how slow and painful it was to get to even the current level of standardization and interoperability in the Xorg+Freedesktop world. I have to assume that part of the reason is that solving the problems Wayland solves is exciting and fun (and addresses the most obvious pain points with Xorg/X11), but building the rest of the ecosystem is less exciting and doesn't draw as much focus and engineering effort.
[deleted]
There are few replacements:
* 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.
* 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.
For me the only reason is that my window manager would need to change (bspwm) and I have no compelling reason to switch unless it's 100% painless.
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.
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.
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.
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.
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.
The good news is that by the time that happens, hopefully the desktop environments will have picked up the slack and the feature-gap will be narrower.
If you need to make the alternatives worse in order for people to switch then Wayland has failed.
No, it means it has succeeded in attracting the X developers over, so the old stack starts bitrotting.
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.
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.
Nobody is intentionally going to make X worse but everyone will make the kernel, graphics drivers, desktop environments, and other components better but potentially different in ways that no one will be updating X to match. X and it’s associated tech like DRI will bitrot. And of course existing bugs will go unaddressed.
Thankfully I have few compelling reasons to upgrade for the sake of upgrading, so that will take a long time. Maybe by then Wayland will be a viable choice. At this stage I'm not convinced it won't be superseded by something else before then.
Put another way: I've seen similar new things come and disappear several times.
Put another way: I've seen similar new things come and disappear several times.
>> Until Wayland has all these (and more) and they are as stable and feature-rich as the existing apps on X, I will not willingly switch to Wayland.
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.
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.
The comment you're responding to lists very concrete issues. Try accepting constructive criticism instead of accusing people of entitlement just because they dare to disagree with you.
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.
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.
They also seem to "dare" to disagree with major Linux distribution direction so perhaps it's not the responders opinion that's in the minority?
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.
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.
So non laggy screensharing is niche use case? Such statement does not make any sense to someone that live in the reality, especially since covid.
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
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
I've never seen non-laggy screensharing with X either (especially since most modern apps draw directly and don't use X commands) so that's a really facetious argument to make. Even with NX and Xpra.
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.
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.
> 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.
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.
I see major difference in there: both systemd and pulseaudio do things differently but in fact do not break any existing usecases. For both these "modern" solutions all the super niche things that get broken are still possible. While Wayland outright does not provide solutions for things that are decidedly non-niche.
PulseAudio certanly broke a lot of existing use-cases. But it also brought some very clear advantages.
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.
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.
>> Try accepting constructive criticism instead of accusing people of entitlement just because they dare to disagree with you.
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.
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.
I think this is a very emotional issue because people are being told that an important tool will be taken away from them, but I also think that it's important to think about being reasonable.
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?
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?
Features drive adoption. I might be more inclined to believe in Wayland if other secured platforms adopted similar constraints. Unfortunately for Wayland, other comparable platforms have consistently found security-conscious solutions that don't compromise on added value.
>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.
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.
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.
> Examples (in order of importance to me):
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
[1] https://aznote.jakou.com/prog/wayland/index.html
[2] http://azsky2.html.xdomain.jp/memo/index.html
* 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
[1] https://aznote.jakou.com/prog/wayland/index.html
[2] http://azsky2.html.xdomain.jp/memo/index.html
I agree those features are essential for an Xorg replacement, but you're missing the fact that the Wayland designers excluded them intentionally, so Wayland is intrinsically hostile to the features and the power-users that use them. See my comment at the top level of this thread.
This is a good time to ask a question I wondered for a long time: why is does the clipboard depend on the window manager at all?
Wouldn't it be easier to make it a separate service instead of having X or Wayland deal with it?
Wouldn't it be easier to make it a separate service instead of having X or Wayland deal with it?
There is no technical reason why it needs to be in the window system (well in X the clipboard goes away if you if the client that set it exits, but that is unwanted anyway) but from a user perspective it is very close to keyboard input so it makes sense to have it be handled by the same system.
For me it's XMonad - there was an attempt to write Wayland alternative Waymonad[1][2] but it is now dead.
[1] https://github.com/waymonad/waymonad
[2] https://github.com/xmonad/xmonad/issues/193
[1] https://github.com/waymonad/waymonad
[2] https://github.com/xmonad/xmonad/issues/193
When the last discussion of X being abandon-ware came up one of the things I wanted to say, being the creator of a highly used open source project myself, is that people are ultimately responsible for software. I was going to speculate that the maintainer of X might be burnt out and that none of us have any right to his free labour, and that the people whining should probably step up or shut up.
Open source software is also free (as in beer) software.
There's a word for people who complain about free things.
Open source software is also free (as in beer) software.
There's a word for people who complain about free things.
> 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.
The post and comments are free, yet here you are complaining. Consider why you think that's okay, and you'll understand.
A post and comment today is by necessity an active effort; judging the quality of an ongoing effort on a project and judging why there isn’t an ongoing effort on the project are two very different things.
What if you write a comment about it?
Most (almost all) of the X.org and Wayland developers are paid for their work.
Not really. There are hundreds of contributors not paid by anyone. Until 1 year ago I wasn't paid for my Wayland-related work. I'm now very lucky to have a company sponsor my contributions, but that's far from being the case of everybody.
Even if all developers were paid, they wouldn't be paid _by users_. It means the developers don't owe the users anything.
Even if all developers were paid, they wouldn't be paid _by users_. It means the developers don't owe the users anything.
“You’re not owed anything,” from the developers of a flailing project to its users, is a red flag.
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.
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.
> Those users are the target market that those companies are interested in pleasing.
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…
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…
From a fellow maintainer of open source software (currently not being paid for the work at all) - I agree 100%.
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.
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.
> expecting answers for questions that were asked and answered thousands of times before
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...
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...
But then the only users who get the features they want are programmers, who are a fairly atypical type of user. I understand that you don't owe users anything, but if you don't want to create software that's useful and pleasing to them, why bother creating open source software at all. You could get the same enjoyment from coding for profit or doing logic puzzles.
Hire, we have money for that specific reason.
> why bother creating open source software at all.
I create features for myself, I share it for free, that's gift, not pleasing.
> why bother creating open source software at all.
I create features for myself, I share it for free, that's gift, not pleasing.
> > it’s possible that […] your work makes the world a worse place
>
> Always great to hear that…
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.)
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.)
I am surprised. The system I use is someone else work. I've brought nothing, got it for free.
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.
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.
There are hundreds of low-volume contributors not paid by anyone. The project would continue without them. Most regular developers, including you, are paid.
You miss the point.
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".
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".
[deleted]
I'm fairly sure you missed his point. Entirely.
No, GGP is saying that we (users) have no right to complain about a FOSS developer abandoning their project since we don't compensate them for it.
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).
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).
It is not Waylands fault that it serves same niche as X.Org.
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.
[1] https://wiki.archlinux.org/index.php/Init
[2] https://devuan.org/
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.
[1] https://wiki.archlinux.org/index.php/Init
[2] https://devuan.org/
I think we're all rooting for Wayland, but we also like to get work done and like the stability of xorg. I hope someone can pick it up and keep it going until Wayland is 100%
Trying to shaming critics into silence might suppress their criticism, but it won't make them like you.
I'm not trying to shame anyone into silence. I'm not trying to shame anyone. However, I would like to see people complain less and act more. Being on the other side of open source software is eye-opening. It can be very disheartening to get mostly negative feedback for something done out of passion (even if you might make a bit of money for it).
> There's a word for people who complain about free things.
You don't complain about the weather?
You don't complain about the weather?
I don't think I do (I'm generally not easily put out by weather), but I would argue that the weather isn't free. I have to survive and deal with weather (clothes, shelter, etc) no matter where I live or what I do.
Well, it's free as in free beer. I'm not paying for the weather, but I still complain about it.
Do you complain about people building new shelter (for free)? The one (also free) we are using is impossible to fix though some people still maintain it.
I don't see anyone complaining that X isn't being maintained.
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).
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).
What new features have even been added to X lately?
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.
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.
> I don't have any real desire to get there while still pretending that the xfree86 hardware-backed server code is a real thing
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.
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.
The xserver code base is huge and supports a lot of stuff. It supports drawing through hardware-backed drivers (e.g., xf86-video-radeon on Xorg), through generic drivers (e.g., xf86-video-modesetting on Xorg) and even through weirder drivers (e.g., xf86-video-nested). It also supports servers other than Xorg (e.g., Xephyr, Xvfb) and many other things.
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.
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.
What do game devs have to say about all this? Or do games bypass X11/Wayland and do some kind of lower-level rendering?
Quite the opposite: games often just run on GL or Vulkan (actually usually Unity or Unreal which will then use GL or Vulkan), and will abstract input with something like libsdl, so they don't have to care about Wayland or X11. But still, some problems that affect games to have to be solved in the X11/Wayland level. Some are solved by the graphics companies (Intel, AMD, etc), some others are either left or picked by companies with a different kind of interest in the graphics world, like Valve.
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.
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.
So. Couple of things.
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.
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.
> 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. … What would you have us do?
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.
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.
Thanks for replying to me.
> 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.
> 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.
Terminology is something X has always gotten a little wrong.
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.
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.
So, I need nvidia proprietary drivers, use a window manager that doesn't support wayland (cwm), do I have any options besides using Xorg? I think the answer is no, but I'm not super well versed in these things. Xorg seems to work just great for me, not sure what all the fuss is about. But then again, I'm not an expert, so I'm happy to adopt any other solution, assuming I can get fast graphics/cuda at 144hz and use my favorite window manager, cwm.
Compositors are starting to implement Wayland EGLStreams support, but it’s very shaky at the moment. As always, X works fine in some setups but is hopelessly broken in others (e.g. multiple NVidia GPUs connected to multiple monitors).
AFAIK Gnome and KDE already have EGLStreams support in place, but it does not work for XWayland because incompatibilities in NVIDIA-maintained libraries.
Kwin supposedly got it over a year ago, but trying to boot into a Plasma Wayland session on Nvidia still kicks me back to a TTY.
I'm not convinced it will ever actually happen.
I'm not convinced it will ever actually happen.
I wonder what this “only what is current may exist” culture is, whether it’s manifestation of survival of the fittest, a baby step towards the machine uprising of 2037; whether it acknowledges a notion, that an environment, where what without a change may sustain, cannot host a life.
It's a solution to the trust problem. Without consensus on what good, stable software looks like -- there are zero trustworthy review sites anymore (cf Amazon reviews) -- the only metrics we really have left are (a) backed by large corporation, and (b) is newer than the alternatives.
The other problems like environment drift and maintainer interest are secondary to the trust problem.
The other problems like environment drift and maintainer interest are secondary to the trust problem.
For someone not familiar with this world, what is X Server and xfree86? What problem does it solve?
It provides an implementation for the X Window System (aka X11) https://en.wikipedia.org/wiki/X_Window_System
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.
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.
Thanks!
The fact that there is an implementation of X on Mac speaks to the power of this system, IMO.
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.
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.
Depends on the era of apps. If you're doing mostly bitmaps (that is, Qt4+, GTK2+, anything that draws its own UI, anything with HTML incl all electron, anything using GL, anything using composition) then VNC will work better, as it transfers better bitmaps. Working with Xlib, GTK1, or Qt3-era or earlier apps, X will perform astoundingly better. Test with xemacs next time, and you should see your results inverted.
There was a lot of work done to make X11 work better over low bandwidth/high latency links. [0] But in the end you could get most of the benefits just by forwarding your X session over SSH with compression enabled. Although X11 is old enough that compression would have used too much CPU back when it was developed.
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.
[0] https://en.wikipedia.org/wiki/Low_Bandwidth_X
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.
[0] https://en.wikipedia.org/wiki/Low_Bandwidth_X
A better comparison with X is the RDP protocol, which too is an API level protocol (its basically forwarding large parts of the windows GDI interface).
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.
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.
It started a long time ago, back in the days of mainframes and thin clients. Mainframe boxes would run the sever side part of "X Server" while clients (ambiguous term in this context, I'll admit) would send commands (e.g. keyboard strokes) and receive graphics back.
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.
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.
We do use them, it is called browser nowadays.
I don’t know, web browsers today are almost too powerful to be called “virtual programmable HTTP terminals”...
I like this analogy... It's very true, and has a lot of local rendering which at the time of X terminals was a bit of a pipe dream. They could just locally render some things like fonts.
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.
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.
Thanks!
Not quite. The X server ran on the client only. The "mainframe" (usually a Unix server) had client programs that would connect to your X server, send it display commands, and receive pointer and keyboard events. The client-server relationship was reversed from the usual way, because the server was sitting in front of the user. The end-user computer was providing a service -- access to the user -- to the big machine in the server room.
In the linux world I work on, a very large percentage of the developers are frequently unknowingly running X via ssh tunnels. Its just to convenient to be able to run the graphical version of tools on the remote dev/test machine than to live all day long restricted only to the GUI tools on your local machine and a terminal session.
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.
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.
> 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.)
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.)
Almost there, you login to the server and run application, that application connects to the X Server on your client:
+----------------+ +----------------+
| Client +---->+ Server |
| | | |
| +-----------+ | | +-----------+ |
| |X Server +<---------+Application| |
| +-----------+ | | +-----------+ |
| | | |
+----------------+ +----------------+
X11 is a window system. An X client is an application that uses the X protocol (e.g., Firefox, GIMP, LibreOffice) while an X server is an implementation of the X protocol that handles the rendering. Note that an X server and an X client don't have to run on the same machine; if I log into a remote server and execute LibreOffice, LibreOffice is still the X client and my machine's X implementation is still the X server, despite the fact that LibreOffice is running remotely.
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.
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.
> 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,
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.
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.
Based on my understanding, the license change was "the straw that broke the camel's back." There were already murmurs of a fork due to disagreements among XFree86 developers, but the license change was the final push that led to distributions choosing not to adopt XFree86 4.4, the first version with the new license.
> 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.
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.
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.
You may find it odd, but that is what the other, now long forgotten side said at the time, and I'm describing that without taking their side. I noted neutrally as I could that they were "unhappy" and consensus was not built "to their satisfaction", but then that their project soon died because interesting work was going on in the fork.
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.
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.
I mean I think the “sole” contributor your are referring to is Keith Packard? Don’t see any reason to not name names here. In any case I guess what I find odd is that while he did a shit ton of work in spearheading a fork, it’s not like it was just him. There were a lot of people, greatly outnumbering the XFree86 steering committee that were unhappy with the direction of the project. It’s not like it was just Keith. That’s what I find odd about your assessment. Obviously there was enough consensus to fork.
Yes, I am talking about Keith Packard, but as I do not personally know anyone involved I didn't feel like dropping names.
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.
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.
Suffice it to say that Packard was involved in X before XFree86. But the point was that although he was an actual productive contributor he was far from working outside of a consensus. There’s really no sides here. The market could have continued with XFree86, it did not.
[deleted]
Thanks!
While it's true that originally X was network transparent, this hasn't truly been the case for a long time now. All modern applications (including the ones you've listed) render the whole window locally for performance reasons. This does not work over the network. Instead, xorg will transmit a picture of the window, giving you an in many ways worse version of VNC. The only difference is the level of integration with other programs like SSH.
This is what happens when the losing player is humble enough to say GG because this was just a game. Nice RE at the end there.
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.
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.
Shortcut keys are configured in the compositor, and screenshots/screencasts work in a cross-compositor fashion via xdg-desktop-portal.
As a user of desktop linux (PopOS), I wonder what is going on here and how this effects me.
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 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 use Wayland on Pop_OS. It works flawlessly. Much better than X for rotated displays and fractional scaling.
I guess it would be nice to have Wobbly Windows - but there's nothing about it that is missing for me.
I guess it would be nice to have Wobbly Windows - but there's nothing about it that is missing for me.
> I guess it would be nice to have Wobbly Windows
Wayfire got you covered: https://wayfire.org/
Wayfire got you covered: https://wayfire.org/
As a user of sway who recently found out about wayfire, it feels a bit strange that I need to switch out sway for something similar but not the same (totally separate codebase?) to get a few additional features (animations).
As much as I like sway, this smells like bad architectural decisions when so much code needs to be rewritten many times.
As much as I like sway, this smells like bad architectural decisions when so much code needs to be rewritten many times.
Indeed, and how the answer to this problem always seems to be "use wlroots".
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.
[0] https://github.com/swaywm/wlroots
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.
[0] https://github.com/swaywm/wlroots
> 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.
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.
X11 (X version 11) is the protocol that controls most the graphics stuff in traditional Linux systems. It employs a client-server architecture.
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.
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.
Thanks!
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..)
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..)
All of that's correct, as far as I know.
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).
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).
Apparently the creator of Wayland was driving through Wayland, MA when he had the idea for the project: http://www.h-online.com/open/features/Wayland-Beyond-X-14320...
Yes, that is basically correct, except that ssh -X working is one of the bugs in X11 that Wayland fixes.
It's worth noting this is not the first time that X has become abandonware.
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.
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.
I am curious, what are the others?
When XFree86 was forked to X.org, is that what you call the first?
When XFree86 was forked to X.org, is that what you call the first?
XFree86 was itself a fork.
What's the difference between X11 and xfree86 (and I guess Xorg)?
If you're talking about forks, they're pretty much the complete opposite of abandonment. Forks exist because people want to work on the code.
In these cases, forks were deeply interconnected with project abandonment
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.
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.
That's a different concept of abandonment to what's happening with the Xorg server code today.
Have any of the BSD (FreeBSD/OpenBSD/NetBSD) started the transition to Wayland yet? X is more than just Linux? There are a lot of other operating systems out there and many have their own X11 forks they maintain.
FreeBSD certainly has: https://www.freebsd.org/news/status/report-2020-07-2020-09.h...
OpenBSD uses and actively supports a customized (not forked) X called Xenocara, which takes the opposite philosophical route from Wayland by putting a wider part of the ecosystem of X features into one coherent project so it can be maintained, improved, and culled (simultaneously, and without committees). You can learn about it on the Xenocara project pages and in its robust manual pages.
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.
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.
I so glad to see there are still people practicing sound engineering in this world.
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.
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.
[deleted]
> 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.
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?
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?
> Windows & Mac are already on exclusively Wayland-style compositors
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.
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.
All of the features that are considered "out of scope" for Wayland are also out of scope for other OS's compositors, too. So not in a narrow sense at all.
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.
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.
Fair. The point I’m trying to convey - without burdening the reader with too many specifics - is that there isn’t really any problem with Wayland on non-Linux systems per se, but rather fundamental philosophical and design differences that spiral way out into other parts of the operating system and beyond (into hardware).
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.
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.
I got your point, but I'm flat out disagreeing with it. Wayland aligns Linux with the philosophical & design differences of other OS's, it doesn't diverge at all.
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"
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"
I agree that X is the odd duck out in its attempt to follow the Unix philosophy. Wayland further pursues the “GNU is Not Unix” principle by introducing a modern desktop paradigm to pair with its modern application busses and other modern features.
Where can I find a list of protocols and standards, and what compositors have implemented them? I don't want to dig between issues and thousands of repos or docs. I imagine commercial software have even less patience, maybe that's why Zoom used the proprietary GNOME thing instead of the open standard.
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 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.
The X11 protocol is highly documented. There are many decent books about it. The Xlib and XCB are small wrappers around the protocol. Once you learn one, jumping to the protocol bits is easy.
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.
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.
[deleted]
Here's a link with a (partial) [1] answer.
[1] https://news.ycombinator.com/item?id=24889703
[1] https://news.ycombinator.com/item?id=24889703
This ship has sailed for better or worse. The people who take these decisions don't hang out in forums to listen to every complaint and gripe. They work for the main corporations and foundations steering Linux development and they have decided that Wayland is the future, even if the transition is going to be ugly. Linux is no longer the "community" OS that it once was. In a way it has gone more mainstream than even MacOS or Windows, and that means it will cater to the larger market forces than the "community's" wants.
Wayland is not corporate policy. It was developed as a side project by some guy from Red Hat, people liked it. Corporations would have likely pressured to keep using X11 to avoid breaking compatibility with applications.
The people who take decisions can take decisions because they contributed a lot to the project. If you want to take decisions too, there's no need to be part of a big company, all you need is getting involved.
The ecosystem is still powered by the community. I see a lot of patches coming from hobbyists in many related projects.
The ecosystem is still powered by the community. I see a lot of patches coming from hobbyists in many related projects.
This makes no sense. The community of people working on Xorg aren't gone, they're just working on wayland now. Wayland was designed by long time Xorg maintainers. This "hostile takeover" narrative is complete FUD.
I'd love to hear more about Xwayland, a project the OP talks about. It sounds like a way to run X on wayland, or maybe the other way around. It sounds like a really nice way to bridge the gap while wayland is still working out some of its kinks and providing backwards compatibility for X apps.
Yes, Xwayland lets users run X11 applications inside Wayland compositors.
Xwayland is more of a hack if anything. Half of the programs don't work because the security model of Wayland is fundamentally different than that of X11. E.g. Xeyes won't follow the mouse cursor because Wayland developers decided it is a security risk to read out mouse coordinates when the mouse is not positioned above the window. More severe in the age of home office work is the lack of support for XGetImage() that makes using X11 videoconferencing software almost impossible to run on XWayland.
This has been working by default in all compositors for a while now, it is not a new feature or project.
Good! Xorg needs to become a community project again. The current maintainers are almost without exception full time paid employees and act solely in the interest of their employers and NOT in the interest of the FOSS community. Their employers have decided to sabotage the ecosystem by breaking established community standards. Maintaining backwards compatibility is the most important thing to keep any ecosystem alive. This means the community should abandon their software (e.g. Wayland) and put people in charge of X11 that start acting in their interest.
Just because Red Hat is moving resources away it doesn't really mean it is sabotaging the project, just that it's realigning the priorities. Instead of blaming them for not caring anymore, we should blame ourselves for empowering them so much?
Ajax seems pretty open in his invitation for people to come and help maintain the things RH doesn't care about anymore...
Ajax seems pretty open in his invitation for people to come and help maintain the things RH doesn't care about anymore...
I'm blaming nobody. I'm just saying that there is a chance for X11 to become a real community project again. Never waste a good crisis.
> Their employers have decided to sabotage the ecosystem by breaking established community standards.
> Just because Red Hat is moving resources away it doesn't really mean it is sabotaging the project
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...
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...
My problem with switching from X to Wayland is not that Wayland doesn't do enough of the things that X does. It's that at it's not different enough. I've been waiting for a really good Linux desktop experience and windowing system since I first started using Linux in 1991. I've always found X hacky and awkward in the entire almost-30 years I've been using it -- it's definitely improved from the era of manual modeline and input device configuration, but it's still ... yuck. Especially things like clipboard. But I don't feel like Wayland is the thing that's going to move us towards any world of consistency and usability. It's just another way for very heterogeneous and mismatched applications to draw arbitrary stuff on the screen.
How well do fcitx & ibus work in Wayland yet? I need good l10n support.
Who is using Wayland without X in Asia right now and isn't using English?
Who is using Wayland without X in Asia right now and isn't using English?
fcitx works fine for me under sway. I couldn't get ibus to work, but I used to use fcitx under X as well so I didn't try too hard to get ibus to work.
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.)
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.)
I like the sentiment....but I don't know a single person who actually uses Wayland. This concerns me.
Why the downvotes? I generally try to run the latest stuff I can get away with on my laptop in solidarity of the devs who rather not be backporting fixes or putting up with technical debt.
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.
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.
If Canonical hadn't wasted a few years developing and trying to push Mir I feel like Wayland could be a lot further along now than it is.
Reading this post, it strikes me that there could have been standalone monitors with an Ethernet port that had just enough compute power to run an X server.
There were. They were called X terminals ( https://en.wikipedia.org/wiki/X_terminal ) and there were quite a few of them on the market around the early 90s, supplanting the traditional terminal protocols. Then there were quite a number of Thin Client ( https://en.wikipedia.org/wiki/Thin_client ) devices that were a hair more independent than dumb X terminals, from players like Sun (Sun Ray) and Wyse (Now part of Dell).
There was an inversion from "Users per to Computer" to "Computers per User" and that model mostly fell out of favor.
There was an inversion from "Users per to Computer" to "Computers per User" and that model mostly fell out of favor.
There are third-party X servers for Windows, but almost nobody has heard of them, while everyone has a browser. So we’re abusing Javascript and HTML to replace X as a remote UI protocol for desktops/laptops that barely have any installed software.
X application draws on X Server, imagine server drawing on <canvas> over websocket. Each character I type would be handled by server. I can't imagine hardware requirements for HN in this model.
NeWS is a better comparison to web browser.
NeWS is a better comparison to web browser.
Yes and those X-Terminals were exactly what X was invented for. This is why the net transparency is not great over high-latency connections, it was never designed for that. In those days companies only had a handful of "computers" and people worked on terminals. Usually shared over a 10 megabit shared ethernet bus, which was surprisingly responsive!
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.
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.
A Raspberry Pi 1 makes for a good X terminal.
There were, and they worked very well. I used them for a while.
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.
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.
You're right, this is how I studied computer science. A laptop was simply unaffordable for a student in those days (mid-90s). I remember one of my friends bought an IBM "Butterfly" laptop really cheaply at an auction. We were all amazed at it. Imagine, your own computer in your backpack! :D
Typical X terminals ran xclock and xterm back in the day and not much else. Pretty cool for the time though. I remember lan gaming with friends in the 90s sometimes turned into hacking sessions. I would sometimes have a few Mosaic browsers run remotely off my system over 10Base2. Given how slow the dialup modem was downloading html X wasn't the bottle neck.
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.
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.
As a part outsider/part insider (long time Linux user, not much of a programmer) let me see if I can try to summarize my frustration with this transition process -- it simply seems to be a much different methodology than the one that got Linux to where it is.
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.
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.
For whatever reason, people who follow the classic Unix/Linux philosophy no longer write much code. The people who are coding the desktop are all using a more Mac-like philosophy.
Right, though I don't think that's quite it -- I think that the "Mac-like" projects/philosophies are more visible because of spaces like Hacker News and Reddit et al, plus perhaps the greater level of PR that bigger projects like Gnome and KDE (and Ubuntu, Mint, PopOs, etc) get.
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.
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.
It never was true, UNIX is bloated, hence Plan 9, `cat -v`.
On the contrary, Wayland is very much in the spirit of Unix & Linux philosophy, while X11 isn't. Wayland is an attempt to do one thing and do it well, hence why it doesn't have solutions for things like clipboard management. Because that's not part of display management & composition. Wayland only does that one thing.
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.
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.
> On the contrary, Wayland is very much in the spirit of Unix & Linux philosophy, while X11 isn't.
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.
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.
> I have an opposite view.
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.
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.
You see, we have a lot of interchangeable parts. We have bash/zsh/sh, glibc/musl, apt/pacman/yum, systemd/runit/OpenRC, GNOME/KDE/XFCE, i3/wmii/xmonad, chromium/firefox etc etc. Even kernel is interchangeable - HURD [1], kFreeBSD [2].
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.
[1] https://www.debian.org/ports/hurd/
[1] https://www.debian.org/ports/kfreebsd-gnu/
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.
[1] https://www.debian.org/ports/hurd/
[1] https://www.debian.org/ports/kfreebsd-gnu/
Funny how Wayland is trying to replace one of the few crucial parts of the *nix ecosystem that _isn't_ fragmented. Everyone's got their own take on everything from basic stuff like kernels, shells, userland, and directory structures to bigger stuff like desktop environments.
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.
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.
Imagine if Microsoft abandoned the WIN32 API. It feels like only yesterday that GNOME2 was scrapped in favor of Unity despite everyone's wishes. Or the day GNOME unilaterally required all distros switch to Systemd. The GNOME project has a long history of stirring the pot and helping Linux to continually destroy itself. The project itself was actually born from petty drama and unwillingness to cooperate with the Qt developers, who unlike GNOME actually had a decent API and went out of their way to address community concerns, but were ignored.
The GNOME project was started because KDE required the non-free (at the time) Qt library. Probably you forgot this little detail because Qt has been free software for such a long time now.
> we can finally abandon xfree86
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...
[1] https://news.ycombinator.com/item?id=24886074
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...
[1] https://news.ycombinator.com/item?id=24886074
I have to disable wayland in gdm3 (on ubuntu), otherwise I end up in a login loop ...
On two occasions I’ve heavily modified WM source (originally ratpoison, now write). Without caring about graphical extensions will I be able to hack similarly under Wayland?
Seemly people want badly to abandon X Server (not the protocol, I mean the server).
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?
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?
The trend for now is to use remote desktops instead. VNC, RDP, that sort of thing. Use Xvnc or Xrdp on the remote machine, so the apps on that machine have something to connect to.
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.
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.
That's not a great trend though. Having actual programs rather than entire desktops run remotely is amazingly handy. A desktop inside a window has never been a great experience.
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!
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!
Replace, no. But there are many implementations of it. It won't go away.
Windows has Xming and Cygwin. Mac has XQuartz. Linux, well, has Xorh and Xwayland. Even on iOS and Android there's X servers.
Windows has Xming and Cygwin. Mac has XQuartz. Linux, well, has Xorh and Xwayland. Even on iOS and Android there's X servers.
The X Window System (X11 for short) looks and feels the same on my Intel Ubuntu Linux laptop and on my HP 9000 UNIX workstation running HP-UX 11 on PA-RISC.
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.
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.
Indeed, this network transparency, I use it every day... It is the #1 feature I couldn't do without on Wayland.
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.
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.
What is your usecase for network transparency? Remote desktop? Is that not supported in a Wayland world?
No, running apps remotely. I specifically don't want to run desktops within Windows. Having remotely running programs on my desktop within my native window manager (or even on Mac and Windows) is much better.
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 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.
Well the people behind Wayland maintained X for a long time, so they know something about it and the real problems. There were several other X replacements that never went anywhere over the years because the people who maintain X looked at it and said it didn't fix any of the real problems.
X Server made my Dell XPS 13 suffer from horizontal tearing. Each Ubuntu release came with its own set of tricks to circumvent the issue until the release of Ubuntu 20.04, when nothing seemed to work. Switched to Wayland and the issue went away without doing anything at all. Never looked back.
I've never used Wayland. Are there inherent advantages that make it preferable, even if the community could successfully revive X? (And assuming Wayland's deficiencies were addressed-- speed as an example, from other comments I've seen)
[deleted]
The whole window system situation on Unix is and has always been like a Rubik's Cube that somebody switched the stickers on so it's impossible to solve.
X consumes 900 MB and Wayland consumer 1 GB RAM in my laptop
GNOME on Wayland allows me to set my FullHD laptop screen at 100% and my 4K display at 200%. I'm sold. :D
"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):
Until Wayland has all these (and more) and they are as stable and feature-rich as the existing apps on X, I will not willingly switch to Wayland.
[1] - https://old.reddit.com/r/wayland/comments/85q78y/why_im_not_...