23 ms·

> replacemeant for Xorg WHY. What's the compelling reason for Wayland? How will it make my life better? As someone who's used Linux as their only computing

by loxias 5y ago

> replacemeant for Xorg WHY. What's the compelling reason for Wayland? How will it make my life better? As someone who's used Linux as their only computing environment for 20 years, I'm terrified of my Xorg being taken away. It works! I understand it! And, I'm still bitter over my init system becoming unnecessarily complicated and stupid with systemd. There's what feels like a rising attitude in the F/OSS community of people wanting to replace things simply because they are old.

perth 5y ago
Well it doesn't rely on using a giant buffer for multiple monitors so it supports hidpi scaling. Have you ever tried hidpi on xorg? It's a mess, even on Ubuntu where they tried their best to clean it up. The xorg apps from the compatibility layer still suffer from it, probably until they update to Wayland. Sidenote: Google tried to use xorg for ChromeOS and ended up writing their own UI system for hidpi scaling among other things when it didn't work Some relevant links for those curious about other people hitting into this: https://www.foell.org/justin/simple-hidpi-monitor-scaling-with-wayland-in-ubuntu-18-04/ https://www.foell.org/justin/simple-hidpi-monitor-scaling-wi... Gnome team: https://wiki.gnome.org/Initiatives/Wayland/XWayland https://wiki.gnome.org/Initiatives/Wayland/XWayland
- jcelerier 5y ago
  Setting DPI in .Xresources had worked fine for me since 2014 except for Firefox and Chrome which took a year or so to adapt
  - perth 5y ago
    Try to set two different DPIs in that.
    - AshamedCaptain 5y ago
      You certainly can, but the problem is that there is no agreed standard from the toolkits to do it. E.g. Qt has its own way.
      - hulitu 5y ago
        Why does QT needs to be smarter ? Just asking.
        jcelerier 5y ago
        Qt runs on platforms where there is literally only a kernel + the Qt app running, through for instance EGL for rendering. So it has to have its own way.
    - Izkata 5y ago
      I don't have a second monitor right now to double check, but I have this in a script for our office monitors to get a different dpi for one display (named eDP-1): xrandr --dpi 100/eDP-1
  - DonHopkins 5y ago
    https://donhopkins.medium.com/the-x-windows-disaster-128d398ebd47 https://donhopkins.medium.com/the-x-windows-disaster-128d398... >My super 3D graphics, then, runs only on /dev/crt1, and X windows runs only on /dev/crt0. Of course, this means I cannot move my mouse over to the 3d graphics display, but as the HP technical support person said “Why would you ever need to point to something that you’ve drawn in 3D?” >Of course, HP claims X has a mode which allows you to run X in the overlay planes and “see through” to the graphics planes underneath. But of course, after 3 months of calls to HP technical support, we agreed that that doesn’t actually work with my particular hardware configuration. You see, I have the top-of-the-line Turbo SRX model (not one, but two on a single workstation!), and they’ve only tested it on the simpler, less advanced configurations. When you’ve got a hip, forward-thinking software innovator like Hewlett-Packard, they think running X windows release 2 is pretty advanced.
  - kaba0 5y ago
    That’s for a single monitor. Now try two monitors with different DPIs
- sprash 5y ago
  The final "composing" step in Wayland does require Wayland to use a "giant" buffer as well. Also My GPU has 16 GB of GDDR how can any frame buffer be "giant" in that context? The support of hidpi scaling is something Toolkits have to manage (on both Wayland and X11). On X11 all the necessary pitch information to do so is available via the xrandr extension.
  - md8z 5y ago
    You really don't want to use Xrandr information to do scaling, it's not accurate. A better way would be to set a property on the window and have the compositor read that, AFAIK this is the solution that the Kwin developers were working on.
- loxias 5y ago
  What's hidpi? I mean, pragmatically. I can guess that that acronym means "high dots per inch", but I don't follow. One of my desktops uses 2x 4k monitors, is that hidpi? X works fine... X also worked fine on an older setup with 4 monitors. Also, I don't know Wayland internals, but I'm gonna assert without proof that any low level graphics interface is gonna involve a framebuffer at some point...
  - perth 5y ago
    Basically: You have a Microsoft Surfacebook, Chromebook Pixel, or Macbook with retina display, let's say at 300 DPI, and you try to plug it into a monitor that is 70 DPI. The buffer will not be possible to adjust to properly handle both monitors because 1 is 300 DPI and 1 is 70 DPI. This is because xorg is internally designed around the philosophy that every monitor will have the same DPI. There are tricks and hacks that teams, specifically I've seen the canonical team pull this off, where they can "trick" xorg into displaying properly with some minor visual artifacting. The last time I tested this was with Ubuntu a few years ago, back when Wayland support was "experimental" and I had this exact sort of setup, and Wayland was easily able to pull this off 100% better in every way because it is not designed around this limitation.
    - loxias 5y ago
      Ah, I think I get it. You want to use a "point" abstraction, not a "pixel" abstraction, right? In your example, I imagine everything would work just fine, but images will be physically bigger on the 70 DPI monitor because, well, the pixels are bigger. I'm guessing that Wayland adds a layer of indirection, resampling the framebuffer based on the DPI to preserve the same point size across displays with different pixel sizes. I ascribe to "the end user is always right" philosophy, so, if you want that functionality, you should be able to have it. But I wonder how popular that desire is. It's far from universal. Personally, I find resampled images to be so distracting and distasteful that it makes a computer hard to use for more than a few minutes. I hate fuzzy text, fuzzy windows, and fuzzy pixels. Any time I've been forced to use a device at something other than its native resolution, I've gotten preoccupied with "how can i fix this ugly crap" until I get native resolution working, and I'm sure I'm not alone. It's cool that Wayland does that for you, because you want it, but consider that to others, it might be a bug, and not a feature. :)
Seirdy 5y ago
The biggest reason is security. X offers no GUI isolation. This is a basic mitigation that should have been the norm a decade or two ago. Advanced mixed DPI also comes to mind. Another is performance: Sway easily outperforms DWM/i3/AwesomeWM on most ARM devices when configured for minimal latency.
- yyyk 5y ago
  Security would be the worst reason. Zero cases in the wild, and it's not that difficult to add access checks to X - there used to be an X extension to do this. The real reason would be that X contains lots and lots of cruft which isn't used anymore and it made development&testing impossible.
  - Seirdy 5y ago
    > Zero cases in the wild Follow along this post and you'll end up with one case in the wild all by yourself on your own machine: https://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html https://theinvisiblethings.blogspot.com/2011/04/linux-securi... Xace was designed to address the mess that is Xsecurity and using the SELinux sandbox for GUI apps, except Xace barely works for mitigating exploits well on the desktop; it's so finicky that Dan Walsh himself concluded that XACE does not work and instead opted to use nested X servers (!!): http://people.fedoraproject.org/~dwalsh/SELinux/Presentations/sandbox.pdf http://people.fedoraproject.org/~dwalsh/SELinux/Presentation...
    - yyyk 5y ago
      >>Zero cases in the wild >Follow along this post and you'll end up with one case in the wild all by yourself on your own machine I know it's possible. The 'case in the wild' terminology is asking whether this was ever weaponized in an exploit. I don't recall X ever being an attack vector in the last decade or two. I guess there are more than enough ways to gain local root this class of exploits doesn't matter. Now, I'm all for closing this hole. But there's something bad about a development strategy that finds things like this and DPI with multiple monitors very important - the vast vast majority of users only have a single monitor - and mostly ignored scenarios like remote desktop until 2020 or so - remote desktop always used by several orders of magnitude more users than HiDPI, and a little tiny bit more important with this mass pandemic going on. Maybe that's why transitioning from X to Wayland takes more time than transitioning from python2 to python3, a well known example of successful migration.
blacklion 5y ago
Wayland is pushed by people, who do embedded Linux. Think: infotaiment system in your car. All UI is pre-installed and fixed to one (maybe, custom) toolkit, custom "window manager" (and it is not full-featured WM, as X11 ones are, as you can not move and resize windows arbitrarily), one theme, no remote access, very low response time. It is better than both X11 and plain framebuffer in this role, for sure.
- loxias 5y ago
  I've done a spot of embedded linux programming before and it is a royal PITA to do anything but the simplest graphics. I can easily see a role for Wayland for that. This is a great answer, thanks. Also, the comment about GUI isolation for security makes sense (though I suspect x11docker would solve the security issues as well). Seems like Wayland is on track to be a good solution for a niche use case.
- microtonal 5y ago
  Wayland is pushed by people, who do embedded Linux. Maybe when Wayland was started. But X.org is now effectively unmaintained and most of the core X.org developers are now working on Wayland. From the release maintainer of X.org: So here's the thing: X works extremely well for what it is, but what it is is deeply flawed. There's no shame in that, it's 33 years old and still relevant, I wish more software worked so well on that kind of timeframe. But using it to drive your display hardware and multiplex your input devices is choosing to make your life worse. https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server.html https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server... See also: https://www.phoronix.com/scan.php?page=news_item&px=XServer-Abandonware https://www.phoronix.com/scan.php?page=news_item&px=XServer-...
  - Macha 5y ago
    > So here's the thing: X works extremely well for what it is, but what it is is deeply flawed. There's no shame in that, it's 33 years old and still relevant, I wish more software worked so well on that kind of timeframe. But using it to drive your display hardware and multiplex your input devices is choosing to make your life worse This implies it's a choice made in isolation, rather than with the matrix of WM features and hardware support driving. People aren't "choosing" Wayland or X in large numbers. They're making decisions like "I'm using distro A which ships Wayland by default" or "I want a tiling WM and have nvidia hardware, so I have to use X".
II2II 5y ago
I have been using Linux for over 25 years. I am not going to shed any tears over the loss of X, though I am concerned that some edge cases will be missed in the transition to Wayland or XWayland. The latter is why I am holding off on switching. Let others figure out and fix those edge cases for me. As for systemd, it appears to be an entirely different type of transition. I won't go as far as saying it is unnecessarily complicated since many Linux distributions had a complicated startup to begin with. However, it is complicated compared to Net/OpenBSD. In contrast, I have always seen X as complex. It is easier to deal with these days since they have smoothed over the sharp edges, but I don't know if it is a case of those edges being sanded down or covered up. It also doesn't cover up the complexities of the many different toolkits one encounters, which you will encounter under X if you use older software.
- sprash 5y ago
  > I have always seen X as complex. True, but don't assume Wayland to be less complex [1]. It has a lot less features, sure. 1.: https://wayland.app/protocols/ https://wayland.app/protocols/
Hendrikto 5y ago
> I'm still bitter over my init system becoming unnecessarily complicated and stupid with systemd. Systemd is neither unnecessary nor stupid. And I am sure, if you really think about it, you know this yourself. It would not have been adopted so widely and quickly if it were. Systemd offers countless advantages over previous init systems: https://www.reddit.com/r/archlinux/comments/4lzxs3/comment/d3rhxlc/ https://www.reddit.com/r/archlinux/comments/4lzxs3/comment/d...
- yjftsjthsd-h 5y ago
  > And I am sure, if you really think about it, you know this yourself. I already disliked systemd on its own merit, but the condescending "if you disagree you're a troll or an idiot" attitude of its proponents really helped cement the feeling.
  - md8z 5y ago
    Please avoid making bad faith interpretations. I'm reading that comment as this: surely you can acknowledge that sysvinit is not a good solution for many people? And just for the purpose of adding some structure around sysvinit, systemd does an adequate job? And if you have an advanced use case that requires a very specialized init system, I hope you can understand how that is uncommon?
    - yjftsjthsd-h 5y ago
      I don't think that is a bad faith reading; when the original statement was (basically) "systemd is bad and overcomplicated", saying "it's not and you know it" is a bad-faith statement. And no, sysvinit was perfectly fine for most people; if anything, I could fairly describe systemd as a very specialized init system for uncommon requirements. Now, I'm happy to agree that systemd is also basically fine for the most common uses (because, honestly, the most common cases are covered by anything), but it also introduced pain points for even non-esoteric cases (I've personally witnessed systemd getting stuck in fascinating nondeterministic ways more than sysv).
RedShift1 5y ago
> There's what feels like a rising attitude in the F/OSS community of people wanting to replace things simply because they are old. This has been going on for at least 15 years now. I've been through multiple cycles like this with different desktop environments and GUI toolkits. The churn is even much greater in the Javascript world where if you come back to a project you haven't look at in about 3 months, the first few hours you're just busy catching up with the rest of the world.
- kaba0 5y ago
  Or just try to go at things with an open-mind and hell, you might learn something? X comes from a time when GPUs were not even a thing, it’s current role on a typical desktop is basically just to be a middleman in the communication of applications and the compositor. Wayland cuts out this middleman, fixes unfixable problems in X (you can’t have displays with different DPIs), and is backwards compatible through XWayland.
  - RedShift1 5y ago
    Why can't the new display server just re-implement the X protocol? The implementation could leave out the unused parts.
    - kaba0 5y ago
      It does, it’s called XWayland. So almost all functionality of “legacy” programs will continue to function under Wayland.
      - mcguire 5y ago
        That word "almost" has me worried.
  - loxias 5y ago
    > a middleman in the communication of applications and the compositor There's an implicit assumption here, that one is even using a compositing window manager. I'm guessing that you do, and that's cool -- you do you! But there are lots of people, who, when sitting down at a fresh install of any operating system, start by turning off all the 3d/transparency/drop shadow/animation/eye candy they can find. I'm one of them, and about half of my peers do as well. The first thing I do on Android is disable all the useless (imho) animations and effects, the same on Windows (back when I used Windows), and on Debian, where I have real control, the last time I saw a compositing window manager was I think 2006. I remarked "Ok. I guess this is for people who want their Linux to look like a Mac" and then promptly removed it. I have nothing against people wanting eye candy! Eye candy sells! But... don't pretend that it's a necessary, or even important feature. > you can’t have displays with different DPIs This is factually not true. Right now I'm sitting in front of a thinkpad connected to two monitors, all 3 displays have different DPIs. I can drag my windows around between them just fine. Everything works. I'm happy. What I think you mean is "Wayland supports point based instead of pixel based rendering", or "Wayland does image resampling for you, making it easier for people who don't want to use native resolution" (I don't know Wayland internals). Anyway, I think this whole comment thread is both educational and disturbing. :/ There appears to be two camps, both of which are incorrectly assuming that everyone else thinks like them. I'm guilty of this as well. Other than the comment about security, and use on embedded environments, all of the "features" that Wayland offers (according to these comments) are, from my perspective, things I would turn off because they'd get in the way. And I will follow your suggestion, and sometime soon set up a VM, and try to install Wayland and whatever the current whiz bang desktop environment is.
ch_123 5y ago
Here is one list of problems with X11 which Wayland solves. One of the author is someone who has done a lot of work on Xorg, so they know what they are talking about: https://www.phoronix.com/scan.php?page=article&item=x_wayland_situation&num=1 https://www.phoronix.com/scan.php?page=article&item=x_waylan...
- loxias 5y ago
  Thank you! No idea why your comment is so low. Most educational one here. I enjoyed reading that link -- a fact oriented list, directly answering my question, rather than an assumption that I want eye candy or resampled resolutions. Fixing the input subsystem alone feels like a compelling reason to use Wayland. It's also interesting to me that the list doesn't mention DPI, which seems to be of great concern here. :> Having read that, I'm much less terrified, though it does mean I probably will have to take the time to write a window manager for Wayland. Thanks!
- hulitu 5y ago
  This link shows what is the problem with SW development, not with X . The same thing is done also in QT or GTK. Why a program written for QT4 cannot compile in QT5 ? Why every library release must be incompatible with the predecessor ? I was able to compile and run X10 programs in X11. Why do i need to have on my linux system more than one version of a library ? Will Wayland fix that, because from this article I see that it is more or less in the same mess of incompatible libraries ?

by loxias 5y ago

perth 5y ago

Well it doesn't rely on using a giant buffer for multiple monitors so it supports hidpi scaling. Have you ever tried hidpi on xorg? It's a mess, even on Ubuntu where they tried their best to clean it up. The xorg apps from the compatibility layer still suffer from it, probably until they update to Wayland. Sidenote: Google tried to use xorg for ChromeOS and ended up writing their own UI system for hidpi scaling among other things when it didn't work Some relevant links for those curious about other people hitting into this: https://www.foell.org/justin/simple-hidpi-monitor-scaling-with-wayland-in-ubuntu-18-04/ https://www.foell.org/justin/simple-hidpi-monitor-scaling-wi... Gnome team: https://wiki.gnome.org/Initiatives/Wayland/XWayland https://wiki.gnome.org/Initiatives/Wayland/XWayland

jcelerier 5y ago
Setting DPI in .Xresources had worked fine for me since 2014 except for Firefox and Chrome which took a year or so to adapt
- perth 5y ago
  Try to set two different DPIs in that.
  - AshamedCaptain 5y ago
    You certainly can, but the problem is that there is no agreed standard from the toolkits to do it. E.g. Qt has its own way.
    - hulitu 5y ago
      Why does QT needs to be smarter ? Just asking.
      - jcelerier 5y ago
        Qt runs on platforms where there is literally only a kernel + the Qt app running, through for instance EGL for rendering. So it has to have its own way.
  - Izkata 5y ago
    I don't have a second monitor right now to double check, but I have this in a script for our office monitors to get a different dpi for one display (named eDP-1): xrandr --dpi 100/eDP-1
- DonHopkins 5y ago
  https://donhopkins.medium.com/the-x-windows-disaster-128d398ebd47 https://donhopkins.medium.com/the-x-windows-disaster-128d398... >My super 3D graphics, then, runs only on /dev/crt1, and X windows runs only on /dev/crt0. Of course, this means I cannot move my mouse over to the 3d graphics display, but as the HP technical support person said “Why would you ever need to point to something that you’ve drawn in 3D?” >Of course, HP claims X has a mode which allows you to run X in the overlay planes and “see through” to the graphics planes underneath. But of course, after 3 months of calls to HP technical support, we agreed that that doesn’t actually work with my particular hardware configuration. You see, I have the top-of-the-line Turbo SRX model (not one, but two on a single workstation!), and they’ve only tested it on the simpler, less advanced configurations. When you’ve got a hip, forward-thinking software innovator like Hewlett-Packard, they think running X windows release 2 is pretty advanced.
- kaba0 5y ago
  That’s for a single monitor. Now try two monitors with different DPIs
sprash 5y ago
The final "composing" step in Wayland does require Wayland to use a "giant" buffer as well. Also My GPU has 16 GB of GDDR how can any frame buffer be "giant" in that context? The support of hidpi scaling is something Toolkits have to manage (on both Wayland and X11). On X11 all the necessary pitch information to do so is available via the xrandr extension.
- md8z 5y ago
  You really don't want to use Xrandr information to do scaling, it's not accurate. A better way would be to set a property on the window and have the compositor read that, AFAIK this is the solution that the Kwin developers were working on.
loxias 5y ago
What's hidpi? I mean, pragmatically. I can guess that that acronym means "high dots per inch", but I don't follow. One of my desktops uses 2x 4k monitors, is that hidpi? X works fine... X also worked fine on an older setup with 4 monitors. Also, I don't know Wayland internals, but I'm gonna assert without proof that any low level graphics interface is gonna involve a framebuffer at some point...
- perth 5y ago
  Basically: You have a Microsoft Surfacebook, Chromebook Pixel, or Macbook with retina display, let's say at 300 DPI, and you try to plug it into a monitor that is 70 DPI. The buffer will not be possible to adjust to properly handle both monitors because 1 is 300 DPI and 1 is 70 DPI. This is because xorg is internally designed around the philosophy that every monitor will have the same DPI. There are tricks and hacks that teams, specifically I've seen the canonical team pull this off, where they can "trick" xorg into displaying properly with some minor visual artifacting. The last time I tested this was with Ubuntu a few years ago, back when Wayland support was "experimental" and I had this exact sort of setup, and Wayland was easily able to pull this off 100% better in every way because it is not designed around this limitation.
  - loxias 5y ago
    Ah, I think I get it. You want to use a "point" abstraction, not a "pixel" abstraction, right? In your example, I imagine everything would work just fine, but images will be physically bigger on the 70 DPI monitor because, well, the pixels are bigger. I'm guessing that Wayland adds a layer of indirection, resampling the framebuffer based on the DPI to preserve the same point size across displays with different pixel sizes. I ascribe to "the end user is always right" philosophy, so, if you want that functionality, you should be able to have it. But I wonder how popular that desire is. It's far from universal. Personally, I find resampled images to be so distracting and distasteful that it makes a computer hard to use for more than a few minutes. I hate fuzzy text, fuzzy windows, and fuzzy pixels. Any time I've been forced to use a device at something other than its native resolution, I've gotten preoccupied with "how can i fix this ugly crap" until I get native resolution working, and I'm sure I'm not alone. It's cool that Wayland does that for you, because you want it, but consider that to others, it might be a bug, and not a feature. :)

Seirdy 5y ago

The biggest reason is security. X offers no GUI isolation. This is a basic mitigation that should have been the norm a decade or two ago. Advanced mixed DPI also comes to mind. Another is performance: Sway easily outperforms DWM/i3/AwesomeWM on most ARM devices when configured for minimal latency.

yyyk 5y ago
Security would be the worst reason. Zero cases in the wild, and it's not that difficult to add access checks to X - there used to be an X extension to do this. The real reason would be that X contains lots and lots of cruft which isn't used anymore and it made development&testing impossible.
- Seirdy 5y ago
  > Zero cases in the wild Follow along this post and you'll end up with one case in the wild all by yourself on your own machine: https://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html https://theinvisiblethings.blogspot.com/2011/04/linux-securi... Xace was designed to address the mess that is Xsecurity and using the SELinux sandbox for GUI apps, except Xace barely works for mitigating exploits well on the desktop; it's so finicky that Dan Walsh himself concluded that XACE does not work and instead opted to use nested X servers (!!): http://people.fedoraproject.org/~dwalsh/SELinux/Presentations/sandbox.pdf http://people.fedoraproject.org/~dwalsh/SELinux/Presentation...
  - yyyk 5y ago
    >>Zero cases in the wild >Follow along this post and you'll end up with one case in the wild all by yourself on your own machine I know it's possible. The 'case in the wild' terminology is asking whether this was ever weaponized in an exploit. I don't recall X ever being an attack vector in the last decade or two. I guess there are more than enough ways to gain local root this class of exploits doesn't matter. Now, I'm all for closing this hole. But there's something bad about a development strategy that finds things like this and DPI with multiple monitors very important - the vast vast majority of users only have a single monitor - and mostly ignored scenarios like remote desktop until 2020 or so - remote desktop always used by several orders of magnitude more users than HiDPI, and a little tiny bit more important with this mass pandemic going on. Maybe that's why transitioning from X to Wayland takes more time than transitioning from python2 to python3, a well known example of successful migration.

blacklion 5y ago

Wayland is pushed by people, who do embedded Linux. Think: infotaiment system in your car. All UI is pre-installed and fixed to one (maybe, custom) toolkit, custom "window manager" (and it is not full-featured WM, as X11 ones are, as you can not move and resize windows arbitrarily), one theme, no remote access, very low response time. It is better than both X11 and plain framebuffer in this role, for sure.

loxias 5y ago
I've done a spot of embedded linux programming before and it is a royal PITA to do anything but the simplest graphics. I can easily see a role for Wayland for that. This is a great answer, thanks. Also, the comment about GUI isolation for security makes sense (though I suspect x11docker would solve the security issues as well). Seems like Wayland is on track to be a good solution for a niche use case.
microtonal 5y ago
Wayland is pushed by people, who do embedded Linux. Maybe when Wayland was started. But X.org is now effectively unmaintained and most of the core X.org developers are now working on Wayland. From the release maintainer of X.org: So here's the thing: X works extremely well for what it is, but what it is is deeply flawed. There's no shame in that, it's 33 years old and still relevant, I wish more software worked so well on that kind of timeframe. But using it to drive your display hardware and multiplex your input devices is choosing to make your life worse. https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server.html https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server... See also: https://www.phoronix.com/scan.php?page=news_item&px=XServer-Abandonware https://www.phoronix.com/scan.php?page=news_item&px=XServer-...
- Macha 5y ago
  > So here's the thing: X works extremely well for what it is, but what it is is deeply flawed. There's no shame in that, it's 33 years old and still relevant, I wish more software worked so well on that kind of timeframe. But using it to drive your display hardware and multiplex your input devices is choosing to make your life worse This implies it's a choice made in isolation, rather than with the matrix of WM features and hardware support driving. People aren't "choosing" Wayland or X in large numbers. They're making decisions like "I'm using distro A which ships Wayland by default" or "I want a tiling WM and have nvidia hardware, so I have to use X".

II2II 5y ago

I have been using Linux for over 25 years. I am not going to shed any tears over the loss of X, though I am concerned that some edge cases will be missed in the transition to Wayland or XWayland. The latter is why I am holding off on switching. Let others figure out and fix those edge cases for me. As for systemd, it appears to be an entirely different type of transition. I won't go as far as saying it is unnecessarily complicated since many Linux distributions had a complicated startup to begin with. However, it is complicated compared to Net/OpenBSD. In contrast, I have always seen X as complex. It is easier to deal with these days since they have smoothed over the sharp edges, but I don't know if it is a case of those edges being sanded down or covered up. It also doesn't cover up the complexities of the many different toolkits one encounters, which you will encounter under X if you use older software.

sprash 5y ago
> I have always seen X as complex. True, but don't assume Wayland to be less complex [1]. It has a lot less features, sure. 1.: https://wayland.app/protocols/ https://wayland.app/protocols/

Hendrikto 5y ago

> I'm still bitter over my init system becoming unnecessarily complicated and stupid with systemd. Systemd is neither unnecessary nor stupid. And I am sure, if you really think about it, you know this yourself. It would not have been adopted so widely and quickly if it were. Systemd offers countless advantages over previous init systems: https://www.reddit.com/r/archlinux/comments/4lzxs3/comment/d3rhxlc/ https://www.reddit.com/r/archlinux/comments/4lzxs3/comment/d...

yjftsjthsd-h 5y ago
> And I am sure, if you really think about it, you know this yourself. I already disliked systemd on its own merit, but the condescending "if you disagree you're a troll or an idiot" attitude of its proponents really helped cement the feeling.
- md8z 5y ago
  Please avoid making bad faith interpretations. I'm reading that comment as this: surely you can acknowledge that sysvinit is not a good solution for many people? And just for the purpose of adding some structure around sysvinit, systemd does an adequate job? And if you have an advanced use case that requires a very specialized init system, I hope you can understand how that is uncommon?
  - yjftsjthsd-h 5y ago
    I don't think that is a bad faith reading; when the original statement was (basically) "systemd is bad and overcomplicated", saying "it's not and you know it" is a bad-faith statement. And no, sysvinit was perfectly fine for most people; if anything, I could fairly describe systemd as a very specialized init system for uncommon requirements. Now, I'm happy to agree that systemd is also basically fine for the most common uses (because, honestly, the most common cases are covered by anything), but it also introduced pain points for even non-esoteric cases (I've personally witnessed systemd getting stuck in fascinating nondeterministic ways more than sysv).

RedShift1 5y ago

> There's what feels like a rising attitude in the F/OSS community of people wanting to replace things simply because they are old. This has been going on for at least 15 years now. I've been through multiple cycles like this with different desktop environments and GUI toolkits. The churn is even much greater in the Javascript world where if you come back to a project you haven't look at in about 3 months, the first few hours you're just busy catching up with the rest of the world.

kaba0 5y ago
Or just try to go at things with an open-mind and hell, you might learn something? X comes from a time when GPUs were not even a thing, it’s current role on a typical desktop is basically just to be a middleman in the communication of applications and the compositor. Wayland cuts out this middleman, fixes unfixable problems in X (you can’t have displays with different DPIs), and is backwards compatible through XWayland.
- RedShift1 5y ago
  Why can't the new display server just re-implement the X protocol? The implementation could leave out the unused parts.
  - kaba0 5y ago
    It does, it’s called XWayland. So almost all functionality of “legacy” programs will continue to function under Wayland.
    - mcguire 5y ago
      That word "almost" has me worried.
- loxias 5y ago
  > a middleman in the communication of applications and the compositor There's an implicit assumption here, that one is even using a compositing window manager. I'm guessing that you do, and that's cool -- you do you! But there are lots of people, who, when sitting down at a fresh install of any operating system, start by turning off all the 3d/transparency/drop shadow/animation/eye candy they can find. I'm one of them, and about half of my peers do as well. The first thing I do on Android is disable all the useless (imho) animations and effects, the same on Windows (back when I used Windows), and on Debian, where I have real control, the last time I saw a compositing window manager was I think 2006. I remarked "Ok. I guess this is for people who want their Linux to look like a Mac" and then promptly removed it. I have nothing against people wanting eye candy! Eye candy sells! But... don't pretend that it's a necessary, or even important feature. > you can’t have displays with different DPIs This is factually not true. Right now I'm sitting in front of a thinkpad connected to two monitors, all 3 displays have different DPIs. I can drag my windows around between them just fine. Everything works. I'm happy. What I think you mean is "Wayland supports point based instead of pixel based rendering", or "Wayland does image resampling for you, making it easier for people who don't want to use native resolution" (I don't know Wayland internals). Anyway, I think this whole comment thread is both educational and disturbing. :/ There appears to be two camps, both of which are incorrectly assuming that everyone else thinks like them. I'm guilty of this as well. Other than the comment about security, and use on embedded environments, all of the "features" that Wayland offers (according to these comments) are, from my perspective, things I would turn off because they'd get in the way. And I will follow your suggestion, and sometime soon set up a VM, and try to install Wayland and whatever the current whiz bang desktop environment is.

ch_123 5y ago

Here is one list of problems with X11 which Wayland solves. One of the author is someone who has done a lot of work on Xorg, so they know what they are talking about: https://www.phoronix.com/scan.php?page=article&item=x_wayland_situation&num=1 https://www.phoronix.com/scan.php?page=article&item=x_waylan...

loxias 5y ago
Thank you! No idea why your comment is so low. Most educational one here. I enjoyed reading that link -- a fact oriented list, directly answering my question, rather than an assumption that I want eye candy or resampled resolutions. Fixing the input subsystem alone feels like a compelling reason to use Wayland. It's also interesting to me that the list doesn't mention DPI, which seems to be of great concern here. :> Having read that, I'm much less terrified, though it does mean I probably will have to take the time to write a window manager for Wayland. Thanks!
hulitu 5y ago
This link shows what is the problem with SW development, not with X . The same thing is done also in QT or GTK. Why a program written for QT4 cannot compile in QT5 ? Why every library release must be incompatible with the predecessor ? I was able to compile and run X10 programs in X11. Why do i need to have on my linux system more than one version of a library ? Will Wayland fix that, because from this article I see that it is more or less in the same mess of incompatible libraries ?