5 ms·

> Xwayland should be able to handle most X11 clients that won’t immediately be ported to Wayland, and if needed, our customers will be able to stay on RHEL 9..

> Xwayland should be able to handle most X11 clients that won’t immediately be ported to Wayland, and if needed, our customers will be able to stay on RHEL 9... For such a drastic change a "should" it's not enough.

justahuman74 3y ago
In theory you could keep using rhel9 till 2032, so theres plenty of road to kick the can down
dathinab 3y ago
since when is a change which had been incoming for 10+ years drastic? plus the huge majority of software doesn't directly communicate with either X or Wayland, but instead with some GUI library which does that for them. Which means that instead of porting thousands of applications you need to port a handful of relevant GUI libraries and any software which is keept up to date will "just work". Sure when it comes to some "desktop environment utilities" and similar that won't work, but for most of them there are Wayland compatible ports or alternatives. Also each (major) version for RHEL is supported for many years which means that going in 2 versions through deprecation and removal isn't drastic at all either (RHEL 9 is planned to be "supported" for roughly another 8 years, through mostly security fixes and similar at some point in a few years).
- brnt 3y ago
  Shifting to Wayland hasn't been incoming since the project never meant to support everything X did. It follows directly that it never could, if you care about supporting all your users and all their uses.
  - dathinab 3y ago
    I'm not sure how to properly response to your comment without it sounding mean because it's pretty much nonsense. Wayland from the beginning was meant to replace X and this was pushed from a lot of sides, including some of the core developers of X at that point in time. So it had been very clear, from the get to go, that X will go and be gone sooner or later. That was clear like 10 years or so ago! Anything wayland didn't support pretty much falls into one of three categories: - its a security issue, so it was meant to be removed and would have been removed from X if that would have been viable - it's somewhat broken and not really properly supported by X either with there being alternative better working approaches (e.g. the whole network transparency thing) - it's not yet supported by wayland, but wayland is designed with extensibility in mind and there is since years a standard group which is standardizing additional wayland protocols and basically stating what any implementation should support. By now the large majority of gaps are filled and it has become often more a question of weather or not the wayland implementation you use has implemented it yet then weather it's supported per-se. Most times that's not too much of an issues but if you are on a distribution which mainly ships outdated software versions or on some niche mostly hobby project wayland implementations that can be an issue. There are some minor exceptions to that 3 categories (e.g. wrt. certain front rendering things) but they in the larger picture don't matter and normal have alternatives in the 3rd category. > if you care about supporting all your users and all their uses. No one does support all users. Or at least no one who doesn't hypocritically claims things they can't long term commit too does. You always should support the majority of users. If you have contributing users with a bias for them. But going from that to all isn't possible without stopping any changes and outside of some (but not even all) bug fixes stopping development. But that would kill your software sooner or later. Times change and resources are limited. What was acceptable security wise 20 years ago today can land you in prison for negligence (well legal troubles then prison, it's a metaphor). Similar requirements change, In the past supporting keyboard is enough, then mouse today controllers and drawing pans and in at most 20 years proper touch support is essential. This means your codebase needs to be changeable, maintainable and secure enough for the resources the maintainers have available. For X non of this was the case and some of the problems where of fundamental architectural nature. So that X needs to die was known even before wayland was a think. I mean if I buy a new car I make it fit my current and coming requirements and if just because it means I can't help some friend of mine with moving something as much as I could before doesn't mean it's not a replacement, because in the end what matter the most is what the person who pays for the car and maintains it needs, not what a friend who doesn't contribute anything to it would prefer it to be.
    - brnt 3y ago
      > I'm not sure how to properly response to your comment without it sounding mean because it's pretty much nonsense You could try examining why you might be wrong before you post walls of silly excuses.
      - dathinab 3y ago
        > silly excuses. Your argument is misleading using the pretense of using logical deduction to argue that something that isn't 100% backward compatible can't be expected to replace something else. Seems more like a silly excuse to me as this argument is not based at all in reality but pure ideological delusion. Something I assume you know very well as people commenting on HN normally have a bit of experience with software development/administration.
        brnt 3y ago
        I assume that what you write is pure projection.
    - arp242 3y ago
      The previous poster didn't say "Wayland wasn't meant to replace X", they said "Wayland was never meant to support everything X did". These are very different things. You're responding to something that was never claimed. "It's nonsense that Wayland doesn't support everything X11 did" and "Wayland doesn't support this for these reasons" is pretty contradictory.
    - hulitu 3y ago
      > So it had been very clear, from the get to go, that X will go and be gone sooner or later. It was more like a rant that X sucks and some people are building the best thing since sliced bread. The only thing that i noticed is that, since around one year ago, they are pronoting it as as finished product, while some people complain that basic things are still not implemented.
    - hulitu 3y ago
      > You always should support the majority of users. The majority of users is using X windows.
- hulitu 3y ago
  > since when is a change which had been incoming for 10+ years drastic? Incoming where ? I only heard about wayland since about 2-3 years ? Earlier was mir the "new display server".
  - dralley 3y ago
    Here's a decade-old talk on Wayland https://www.youtube.com/watch?v=cQoQE_HDG8g https://www.youtube.com/watch?v=cQoQE_HDG8g Wayland has been the default on Fedora and Arch w/ GNOME since around 2018, 5 years ago. It became the default on Debian w/ GNOME in 2019, 4 years ago. So yes, long time coming. KDE took longer but it's now finally ready.
  - m4rtink 3y ago
    I had been using Wayland on my phones (Sailfish OS) since 2013. :P
vidarh 3y ago
How many RHEL paying customers rely on anything which won't run under XWayland, though? I detest Wayland. I'll stay on X for years to come (heck, I've just started writing an X window manager). But I'm not sure this will matter to the typical target customer of RHEL.
- DonHopkins 3y ago
  Recreational Bugs talk [1989] by "Sgt." David Rosenthal (author of the ICCCM, developer of the Andrew Window Manager, X10, X11, and NeWS, employee #4 and chief scientist at Nvidia, and an old friend of mine): https://blog.dshr.org/2018/05/recreational-bugs.html https://blog.dshr.org/2018/05/recreational-bugs.html >"You will get a better Gorilla effect if you use as big a piece of paper as possible." -Kunihiko Kasahara, Creative Origami. https://en.wikipedia.org/wiki/David_S._H._Rosenthal https://en.wikipedia.org/wiki/David_S._H._Rosenthal The X-Windows Disaster: https://donhopkins.medium.com/the-x-windows-disaster-128d398ebd47 https://donhopkins.medium.com/the-x-windows-disaster-128d398... Ice Cube: The Lethal Weapon One of the fundamental design goals of X was to separate the window manager from the window server. “Mechanism, not policy” was the mantra. That is, the X server provided a mechanism for drawing on the screen and managing windows, but did not implement a particular policy for human-computer interaction. While this might have seemed like a good idea at the time (especially if you are in a research community, experimenting with different approaches for solving the human-computer interaction problem), it can create a veritable user interface Tower of Babel. If you sit down at a friend’s Macintosh, with its single mouse button, you can use it with no problems. If you sit down at a friend’s Windows box, with two buttons, you can use it, again with no problems. But just try making sense of a friend’s X terminal: three buttons, each one programmed a different way to perform a different function on each different day of the week — and that’s before you consider combinations like control-left-button, shift-right-button, control-shift-meta-middle-button, and so on. Things are not much better from the programmer’s point of view. As a result, one of the most amazing pieces of literature to come out of the X Consortium is the “Inter Client Communication Conventions Manual,” more fondly known as the “ICCCM”, “Ice Cubed,” or “I39L” (short for “I, 39 letters, L”). It describes protocols that X clients must use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late — by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past. The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn’t work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It’s so difficult, that many of the benefits just aren’t worth the hassle of compliance. And when one program doesn’t comply, it screws up other programs. This is the reason cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application. If you want to write an interoperable ICCCM compliant application, you have to crossbar test it with every other application, and with all possible window managers, and then plead with the vendors to fix their problems in the next release. In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry’s standard naked emperor. Using these toolkits is like trying to make a bookshelf out of mashed potatoes. - Jamie Zawinski
hollerith 3y ago
RHEL 9 defaults to Wayland: the X server is available, but the admin must explicitly choose it, and most admins never do. So describing this as a drastic change is a bit hyperbolic.

justahuman74 3y ago

In theory you could keep using rhel9 till 2032, so theres plenty of road to kick the can down

dathinab 3y ago

since when is a change which had been incoming for 10+ years drastic? plus the huge majority of software doesn't directly communicate with either X or Wayland, but instead with some GUI library which does that for them. Which means that instead of porting thousands of applications you need to port a handful of relevant GUI libraries and any software which is keept up to date will "just work". Sure when it comes to some "desktop environment utilities" and similar that won't work, but for most of them there are Wayland compatible ports or alternatives. Also each (major) version for RHEL is supported for many years which means that going in 2 versions through deprecation and removal isn't drastic at all either (RHEL 9 is planned to be "supported" for roughly another 8 years, through mostly security fixes and similar at some point in a few years).

brnt 3y ago
Shifting to Wayland hasn't been incoming since the project never meant to support everything X did. It follows directly that it never could, if you care about supporting all your users and all their uses.
- dathinab 3y ago
  I'm not sure how to properly response to your comment without it sounding mean because it's pretty much nonsense. Wayland from the beginning was meant to replace X and this was pushed from a lot of sides, including some of the core developers of X at that point in time. So it had been very clear, from the get to go, that X will go and be gone sooner or later. That was clear like 10 years or so ago! Anything wayland didn't support pretty much falls into one of three categories: - its a security issue, so it was meant to be removed and would have been removed from X if that would have been viable - it's somewhat broken and not really properly supported by X either with there being alternative better working approaches (e.g. the whole network transparency thing) - it's not yet supported by wayland, but wayland is designed with extensibility in mind and there is since years a standard group which is standardizing additional wayland protocols and basically stating what any implementation should support. By now the large majority of gaps are filled and it has become often more a question of weather or not the wayland implementation you use has implemented it yet then weather it's supported per-se. Most times that's not too much of an issues but if you are on a distribution which mainly ships outdated software versions or on some niche mostly hobby project wayland implementations that can be an issue. There are some minor exceptions to that 3 categories (e.g. wrt. certain front rendering things) but they in the larger picture don't matter and normal have alternatives in the 3rd category. > if you care about supporting all your users and all their uses. No one does support all users. Or at least no one who doesn't hypocritically claims things they can't long term commit too does. You always should support the majority of users. If you have contributing users with a bias for them. But going from that to all isn't possible without stopping any changes and outside of some (but not even all) bug fixes stopping development. But that would kill your software sooner or later. Times change and resources are limited. What was acceptable security wise 20 years ago today can land you in prison for negligence (well legal troubles then prison, it's a metaphor). Similar requirements change, In the past supporting keyboard is enough, then mouse today controllers and drawing pans and in at most 20 years proper touch support is essential. This means your codebase needs to be changeable, maintainable and secure enough for the resources the maintainers have available. For X non of this was the case and some of the problems where of fundamental architectural nature. So that X needs to die was known even before wayland was a think. I mean if I buy a new car I make it fit my current and coming requirements and if just because it means I can't help some friend of mine with moving something as much as I could before doesn't mean it's not a replacement, because in the end what matter the most is what the person who pays for the car and maintains it needs, not what a friend who doesn't contribute anything to it would prefer it to be.
  - brnt 3y ago
    > I'm not sure how to properly response to your comment without it sounding mean because it's pretty much nonsense You could try examining why you might be wrong before you post walls of silly excuses.
    - dathinab 3y ago
      > silly excuses. Your argument is misleading using the pretense of using logical deduction to argue that something that isn't 100% backward compatible can't be expected to replace something else. Seems more like a silly excuse to me as this argument is not based at all in reality but pure ideological delusion. Something I assume you know very well as people commenting on HN normally have a bit of experience with software development/administration.
      - brnt 3y ago
        I assume that what you write is pure projection.
  - arp242 3y ago
    The previous poster didn't say "Wayland wasn't meant to replace X", they said "Wayland was never meant to support everything X did". These are very different things. You're responding to something that was never claimed. "It's nonsense that Wayland doesn't support everything X11 did" and "Wayland doesn't support this for these reasons" is pretty contradictory.
  - hulitu 3y ago
    > So it had been very clear, from the get to go, that X will go and be gone sooner or later. It was more like a rant that X sucks and some people are building the best thing since sliced bread. The only thing that i noticed is that, since around one year ago, they are pronoting it as as finished product, while some people complain that basic things are still not implemented.
  - hulitu 3y ago
    > You always should support the majority of users. The majority of users is using X windows.
hulitu 3y ago
> since when is a change which had been incoming for 10+ years drastic? Incoming where ? I only heard about wayland since about 2-3 years ? Earlier was mir the "new display server".
- dralley 3y ago
  Here's a decade-old talk on Wayland https://www.youtube.com/watch?v=cQoQE_HDG8g https://www.youtube.com/watch?v=cQoQE_HDG8g Wayland has been the default on Fedora and Arch w/ GNOME since around 2018, 5 years ago. It became the default on Debian w/ GNOME in 2019, 4 years ago. So yes, long time coming. KDE took longer but it's now finally ready.
- m4rtink 3y ago
  I had been using Wayland on my phones (Sailfish OS) since 2013. :P

vidarh 3y ago

How many RHEL paying customers rely on anything which won't run under XWayland, though? I detest Wayland. I'll stay on X for years to come (heck, I've just started writing an X window manager). But I'm not sure this will matter to the typical target customer of RHEL.

DonHopkins 3y ago
Recreational Bugs talk [1989] by "Sgt." David Rosenthal (author of the ICCCM, developer of the Andrew Window Manager, X10, X11, and NeWS, employee #4 and chief scientist at Nvidia, and an old friend of mine): https://blog.dshr.org/2018/05/recreational-bugs.html https://blog.dshr.org/2018/05/recreational-bugs.html >"You will get a better Gorilla effect if you use as big a piece of paper as possible." -Kunihiko Kasahara, Creative Origami. https://en.wikipedia.org/wiki/David_S._H._Rosenthal https://en.wikipedia.org/wiki/David_S._H._Rosenthal The X-Windows Disaster: https://donhopkins.medium.com/the-x-windows-disaster-128d398ebd47 https://donhopkins.medium.com/the-x-windows-disaster-128d398... Ice Cube: The Lethal Weapon One of the fundamental design goals of X was to separate the window manager from the window server. “Mechanism, not policy” was the mantra. That is, the X server provided a mechanism for drawing on the screen and managing windows, but did not implement a particular policy for human-computer interaction. While this might have seemed like a good idea at the time (especially if you are in a research community, experimenting with different approaches for solving the human-computer interaction problem), it can create a veritable user interface Tower of Babel. If you sit down at a friend’s Macintosh, with its single mouse button, you can use it with no problems. If you sit down at a friend’s Windows box, with two buttons, you can use it, again with no problems. But just try making sense of a friend’s X terminal: three buttons, each one programmed a different way to perform a different function on each different day of the week — and that’s before you consider combinations like control-left-button, shift-right-button, control-shift-meta-middle-button, and so on. Things are not much better from the programmer’s point of view. As a result, one of the most amazing pieces of literature to come out of the X Consortium is the “Inter Client Communication Conventions Manual,” more fondly known as the “ICCCM”, “Ice Cubed,” or “I39L” (short for “I, 39 letters, L”). It describes protocols that X clients must use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late — by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past. The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn’t work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It’s so difficult, that many of the benefits just aren’t worth the hassle of compliance. And when one program doesn’t comply, it screws up other programs. This is the reason cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application. If you want to write an interoperable ICCCM compliant application, you have to crossbar test it with every other application, and with all possible window managers, and then plead with the vendors to fix their problems in the next release. In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry’s standard naked emperor. Using these toolkits is like trying to make a bookshelf out of mashed potatoes. - Jamie Zawinski

hollerith 3y ago

RHEL 9 defaults to Wayland: the X server is available, but the admin must explicitly choose it, and most admins never do. So describing this as a drastic change is a bit hyperbolic.