6 ms·

This is starting to feel like the arguments against systemd all over again. A few highly vocal people hate it, but it works just fine for almost everybody else.

kelnos 3y ago
As someone who has been working on porting a desktop environment to Wayland for the past year or so, I don't hate Wayland, but I certainly don't love it. After 10-15 years, it still seems pretty half-baked. Some pretty fundamental-feeling protocols have been languishing as merge requests on git.freedesktop.org, some for 3+ years at this point. I get that you don't want to rush standardization of things that need to remain stable and backward-compatible for (hopefully) decades), but c'mon, this is getting to be a bit much. At this point I cannot actually replicate Xfce feature-for-feature in Wayland, not without inventing private protocols of my own, which I'd prefer not to do. My biggest issue right now is xfce4-panel, and embedding surfaces from one process into a parent process. There's no Wayland way to do this, and the Wayland folks have explicitly rejected some sort of XEMBED-workalike Wayland protocol, instead telling people they should write an embedded Wayland compositor. Well, I've been working on that for the past eight months, and it's hard to get right. I have something that "works", but it has a lot of rough edges, and, critically, eventually either the parent app or embedded apps run into weird spurious protocol errors and quit. While yes, that's technically my fault and my bugs, working with an under-documented protocol and really bare-bones libraries for building apps (wlroots, sadly, is not suitable for writing an embedded compositor, as it does too much) doesn't make any of this easier. I've written more than 10k lines of code (so far), and, meanwhile, you can do an XEMBED implementation in a few hundred. I get that X11 made certain things impossible. But why not build an "X12" rather than throwing everything out and staring completely from scratch? It seems like people just didn't feel like it, and building something new was more exciting and would look better on their resume. I of all people know it's not cool to tell people what open source software to build in their spare time (though, to be fair, many/most of the people involved in Wayland are employed or at least funded by corporations), but jeez, this has been exhausting.
- MBCook 3y ago
  > It seems like people just didn't feel like it, and building something new was more exciting and would look better on their resume Those people were largely the Xorg developers. They knew what they were up against and clearly decided this was a better idea. They may have overcorrected, but they’ve been fixing things compared to the early releases. Wayland is here, it works (for a great many things), and it’s under active development to keep improving. Xorg is not.
- DonHopkins 3y ago
  People have been proposing building "X12" and "Y-Windows" since the day after X11 came out 39 years ago. Not gonna do it. Wouldn't be prudent at this juncture. https://www.youtube.com/watch?v=4QHHGHve_N0 https://www.youtube.com/watch?v=4QHHGHve_N0 X-Windows Disaster: https://donhopkins.medium.com/the-x-windows-disaster-128d398ebd47 https://donhopkins.medium.com/the-x-windows-disaster-128d398... Myth: X Demonstrates the Power of Client/Server Computing At the mere mention of network window systems, certain propeller heads who confuse technology with economics will start foaming at the mouth about their client/server models and how in the future palmtops will just run the X server and let the other half of the program run on some Cray down the street. They’ve become unwitting pawns in the hardware manufacturers’ conspiracy to sell newer systems each year. After all, what better way is there to force users to upgrade their hardware than to give them X, where a single application can bog down the client, the server, and the network between them, simultaneously! The database client/server model (the server machine stores all the data, and the clients beseech it for data) makes sense. The computation client/server model (where the server is a very expensive or experimental supercomputer, and the client is a desktop workstation or portable computer) makes sense. But a graphical client/server model that slices the interface down some arbitrary middle is like Solomon following through with his child-sharing strategy. The legs, heart, and left eye end up on the server, the arms and lungs go to the client, the head is left rolling around on the floor, and blood spurts everywhere. The fundamental problem with X’s notion of client/server is that the proper division of labor between the client and the server can only be decided on an application-by-application basis. Some applications (like a flight simulator) require that all mouse movement be sent to the application. Others need only mouse clicks. Still others need a sophisticated combination of the two, depending on the program’s state or the region of the screen where the mouse happens to be. Some programs need to update meters or widgets on the screen every second. Other programs just want to display clocks; the server could just as well do the updating, provided that there was some way to tell it to do so. The right graphical client/server model is to have an extensible server. Application programs on remote machines can download their own special extension on demand and share libraries in the server. Downloaded code can draw windows, track input events, provide fast interactive feedback, and minimize network traffic by communicating with the application using a dynamic, high-level protocol. As an example, imagine a CAD application built on top of such an extensible server. The application could download a program to draw an IC and associate it with a name. From then on, the client could draw the IC anywhere on the screen simply by sending the name and a pair of coordinates. Better yet, the client can download programs and data structures to draw the whole schematic, which are called automatically to refresh and scroll the window, without bothering the client. The user can drag an IC around smoothly, without any network traffic or context switching, and the server sends a single message to the client when the interaction is complete. This makes it possible to run interactive clients over low-speed (that is, slow-bandwidth) communication lines. Sounds like science fiction? An extensible window server was precisely the strategy taken by the NeWS (Network extensible Window System) window system written by James Gosling at Sun. With such an extensible system, the user interface toolkit becomes an extensible server library of classes that clients download directly into the server (the approach taken by Sun’s TNT Toolkit). Toolkit objects in different applications share common objects in the server, saving both time and memory, and creating a look-and-feel that is both consistent across applications and customizable. With NeWS, the window manager itself was implemented inside the server, eliminating network overhead for window manipulation operations — and along with it the race conditions, context switching overhead, and interaction problems that plague X toolkits and window manager. Ultimately, NeWS was not economically or politically viable because it solved the very problems that X was designed to create.
whatwhaaaaat 3y ago
Welll in this case anyone who wants Nvidia cards to actually work for games. Also anyone using some major applications like discord. So anyone actually gaming on Linux.
- _ea1k 3y ago
  I've never heard of anyone choosing RHEL for those use cases.
- stephen_g 3y ago
  If anything, moves like this only make it more likely that those vendors will fix their drivers and applications with Wayland...
- DonHopkins 3y ago
  So anyone not serious about gaming.
  - whatwhaaaaat 3y ago
    You’re right no one who plays on a steam deck is serious about gaming…
GauntletWizard 3y ago
SystemD still has detractors, and a ton of people who wish there were a better alternative.
DonHopkins 3y ago
And the people who were against systemd were arguing for sticking with the steaming pile of shit and toenail clippings from AT&T that replaced the simple but functional stuff from BSD, because they're too young to have ever known anything other than a steaming pile of shit and toenail clippings, and mistakenly think that's the One True Way of Unix. Nostalgia for X-Windows is just as naive. Since nobody even uses X-Windows networking any more, they'd be better off with SunView. X-Windows is only free if your time is worthless.
- wkat4242 3y ago
  > And the people who were against systemd were arguing for sticking with the steaming pile of shit and toenail clippings from AT&T that replaced the simple but functional stuff from BSD I use the simple but functional BSD stuff :) > Since nobody even uses X-Windows networking any more I still use it every day
- orwin 3y ago
  One if the first company i worked at used X-windows networking for their Paas offering,until at least 5 years ago.
- vidarh 3y ago
  For me, the reason for sticking with X is that my X setup works, and whenever I look at what it'd take me to do the same things with Wayland, I balk. I really don't care about X. But as long as the migration would break any number of script I rely on, it's not worth it exactly because I care about how I spend my time. And that even drives me to write more X code because looking into whether I could realistically do the same upgrades to my environment with Wayland has put me off every time (I could write a tiny wm or be forced to maintain my own compositor - even the "tinywl" wlroots example is several times the size of my current wm, while not doing what I want). For me it is purely pragmatic. If/when it gets harder to keep my X setup running than migrating, I'll migrate, and I do what I can't to keep the X-specific parts of my code well isolated. But it's likely to take many years before migrating becomes easier than staying put at this rate - frankly, odds are what will make me migrate is if/when the browsers drop X support.
- 3y ago
wkat4242 3y ago
It is because it is the same situation. RedHat pushing their IP onto the mainstream and at the same time taking maintenance of over the industry standard so they can let it die off. I'm sure I can make do with systemd but I don't like it, and thus I chose an OS that doesn't use it. I also don't like the way it was orchestrated that I don't have a choice. I want choices. And I don't like my system changing for the sake of it. But with RedHat positioning themselves as the center of the Linux world it is quite difficult to avoid their stuff. They still have a huge finger in the pie and people still respect them as if IBM hadn't taken them over. Even after CentOS where people are even supporting their narrative of "freeloaders" when it comes to Alma and Rocky Linux. I really hope some org from perhaps the BSDs will take over maintainership of Xorg instead of allowing RedHat to shutter it. Choice is good.
- dralley 3y ago
  Who are these souls that would be maintaining Xorg, if only the nefarious Red Hat had not been doing so (laggardly, according to you)? Are they spending their free time working on Xorg, or are they being paid to do so by an employer? Which employer would that be, that has a reason to care about desktop linux AND is motivated to support Xorg specifically over Wayland?
dathinab 3y ago
yes and I'm seeing many of the same kind of arguments as with systemd like arguments you could re-formulate as "but my kinda uncommon setup which is irrelevant for the maintainers and sponsors of which do the decision will not work and it's bad to not support everyone for free" or "but you can't to X in that specific way and because of that you can't do so at all (ignoring alternative ways) and because of that it can't replace it at all" or "hung up on some technical detail which doesn't matter for 99% of users" or "my software which wasn't properly updated since 10 years doesn't work flawless under Wayland" or "hung up on something which wasn't supported initially but is supported since multiple years by now" in the end someone will probably continue to support Xorg and someone will probably maintain it and it probably will get increasingly more painful to run it but it also will take many years until it really hurts and it probably will be banned from most companies caring about security and people starting to use Linux in some years in the future will probably not really know what Xorg is except is that thing related to some ancient programs not behaving nicely and they will wonder what it has to do with X(Twitter) and if thats why it's no longer used.

kelnos 3y ago

As someone who has been working on porting a desktop environment to Wayland for the past year or so, I don't hate Wayland, but I certainly don't love it. After 10-15 years, it still seems pretty half-baked. Some pretty fundamental-feeling protocols have been languishing as merge requests on git.freedesktop.org, some for 3+ years at this point. I get that you don't want to rush standardization of things that need to remain stable and backward-compatible for (hopefully) decades), but c'mon, this is getting to be a bit much. At this point I cannot actually replicate Xfce feature-for-feature in Wayland, not without inventing private protocols of my own, which I'd prefer not to do. My biggest issue right now is xfce4-panel, and embedding surfaces from one process into a parent process. There's no Wayland way to do this, and the Wayland folks have explicitly rejected some sort of XEMBED-workalike Wayland protocol, instead telling people they should write an embedded Wayland compositor. Well, I've been working on that for the past eight months, and it's hard to get right. I have something that "works", but it has a lot of rough edges, and, critically, eventually either the parent app or embedded apps run into weird spurious protocol errors and quit. While yes, that's technically my fault and my bugs, working with an under-documented protocol and really bare-bones libraries for building apps (wlroots, sadly, is not suitable for writing an embedded compositor, as it does too much) doesn't make any of this easier. I've written more than 10k lines of code (so far), and, meanwhile, you can do an XEMBED implementation in a few hundred. I get that X11 made certain things impossible. But why not build an "X12" rather than throwing everything out and staring completely from scratch? It seems like people just didn't feel like it, and building something new was more exciting and would look better on their resume. I of all people know it's not cool to tell people what open source software to build in their spare time (though, to be fair, many/most of the people involved in Wayland are employed or at least funded by corporations), but jeez, this has been exhausting.

MBCook 3y ago
> It seems like people just didn't feel like it, and building something new was more exciting and would look better on their resume Those people were largely the Xorg developers. They knew what they were up against and clearly decided this was a better idea. They may have overcorrected, but they’ve been fixing things compared to the early releases. Wayland is here, it works (for a great many things), and it’s under active development to keep improving. Xorg is not.
DonHopkins 3y ago
People have been proposing building "X12" and "Y-Windows" since the day after X11 came out 39 years ago. Not gonna do it. Wouldn't be prudent at this juncture. https://www.youtube.com/watch?v=4QHHGHve_N0 https://www.youtube.com/watch?v=4QHHGHve_N0 X-Windows Disaster: https://donhopkins.medium.com/the-x-windows-disaster-128d398ebd47 https://donhopkins.medium.com/the-x-windows-disaster-128d398... Myth: X Demonstrates the Power of Client/Server Computing At the mere mention of network window systems, certain propeller heads who confuse technology with economics will start foaming at the mouth about their client/server models and how in the future palmtops will just run the X server and let the other half of the program run on some Cray down the street. They’ve become unwitting pawns in the hardware manufacturers’ conspiracy to sell newer systems each year. After all, what better way is there to force users to upgrade their hardware than to give them X, where a single application can bog down the client, the server, and the network between them, simultaneously! The database client/server model (the server machine stores all the data, and the clients beseech it for data) makes sense. The computation client/server model (where the server is a very expensive or experimental supercomputer, and the client is a desktop workstation or portable computer) makes sense. But a graphical client/server model that slices the interface down some arbitrary middle is like Solomon following through with his child-sharing strategy. The legs, heart, and left eye end up on the server, the arms and lungs go to the client, the head is left rolling around on the floor, and blood spurts everywhere. The fundamental problem with X’s notion of client/server is that the proper division of labor between the client and the server can only be decided on an application-by-application basis. Some applications (like a flight simulator) require that all mouse movement be sent to the application. Others need only mouse clicks. Still others need a sophisticated combination of the two, depending on the program’s state or the region of the screen where the mouse happens to be. Some programs need to update meters or widgets on the screen every second. Other programs just want to display clocks; the server could just as well do the updating, provided that there was some way to tell it to do so. The right graphical client/server model is to have an extensible server. Application programs on remote machines can download their own special extension on demand and share libraries in the server. Downloaded code can draw windows, track input events, provide fast interactive feedback, and minimize network traffic by communicating with the application using a dynamic, high-level protocol. As an example, imagine a CAD application built on top of such an extensible server. The application could download a program to draw an IC and associate it with a name. From then on, the client could draw the IC anywhere on the screen simply by sending the name and a pair of coordinates. Better yet, the client can download programs and data structures to draw the whole schematic, which are called automatically to refresh and scroll the window, without bothering the client. The user can drag an IC around smoothly, without any network traffic or context switching, and the server sends a single message to the client when the interaction is complete. This makes it possible to run interactive clients over low-speed (that is, slow-bandwidth) communication lines. Sounds like science fiction? An extensible window server was precisely the strategy taken by the NeWS (Network extensible Window System) window system written by James Gosling at Sun. With such an extensible system, the user interface toolkit becomes an extensible server library of classes that clients download directly into the server (the approach taken by Sun’s TNT Toolkit). Toolkit objects in different applications share common objects in the server, saving both time and memory, and creating a look-and-feel that is both consistent across applications and customizable. With NeWS, the window manager itself was implemented inside the server, eliminating network overhead for window manipulation operations — and along with it the race conditions, context switching overhead, and interaction problems that plague X toolkits and window manager. Ultimately, NeWS was not economically or politically viable because it solved the very problems that X was designed to create.

whatwhaaaaat 3y ago

Welll in this case anyone who wants Nvidia cards to actually work for games. Also anyone using some major applications like discord. So anyone actually gaming on Linux.

_ea1k 3y ago
I've never heard of anyone choosing RHEL for those use cases.
stephen_g 3y ago
If anything, moves like this only make it more likely that those vendors will fix their drivers and applications with Wayland...
DonHopkins 3y ago
So anyone not serious about gaming.
- whatwhaaaaat 3y ago
  You’re right no one who plays on a steam deck is serious about gaming…

GauntletWizard 3y ago

SystemD still has detractors, and a ton of people who wish there were a better alternative.

DonHopkins 3y ago

And the people who were against systemd were arguing for sticking with the steaming pile of shit and toenail clippings from AT&T that replaced the simple but functional stuff from BSD, because they're too young to have ever known anything other than a steaming pile of shit and toenail clippings, and mistakenly think that's the One True Way of Unix. Nostalgia for X-Windows is just as naive. Since nobody even uses X-Windows networking any more, they'd be better off with SunView. X-Windows is only free if your time is worthless.

wkat4242 3y ago
> And the people who were against systemd were arguing for sticking with the steaming pile of shit and toenail clippings from AT&T that replaced the simple but functional stuff from BSD I use the simple but functional BSD stuff :) > Since nobody even uses X-Windows networking any more I still use it every day
orwin 3y ago
One if the first company i worked at used X-windows networking for their Paas offering,until at least 5 years ago.
vidarh 3y ago
For me, the reason for sticking with X is that my X setup works, and whenever I look at what it'd take me to do the same things with Wayland, I balk. I really don't care about X. But as long as the migration would break any number of script I rely on, it's not worth it exactly because I care about how I spend my time. And that even drives me to write more X code because looking into whether I could realistically do the same upgrades to my environment with Wayland has put me off every time (I could write a tiny wm or be forced to maintain my own compositor - even the "tinywl" wlroots example is several times the size of my current wm, while not doing what I want). For me it is purely pragmatic. If/when it gets harder to keep my X setup running than migrating, I'll migrate, and I do what I can't to keep the X-specific parts of my code well isolated. But it's likely to take many years before migrating becomes easier than staying put at this rate - frankly, odds are what will make me migrate is if/when the browsers drop X support.
3y ago

wkat4242 3y ago

It is because it is the same situation. RedHat pushing their IP onto the mainstream and at the same time taking maintenance of over the industry standard so they can let it die off. I'm sure I can make do with systemd but I don't like it, and thus I chose an OS that doesn't use it. I also don't like the way it was orchestrated that I don't have a choice. I want choices. And I don't like my system changing for the sake of it. But with RedHat positioning themselves as the center of the Linux world it is quite difficult to avoid their stuff. They still have a huge finger in the pie and people still respect them as if IBM hadn't taken them over. Even after CentOS where people are even supporting their narrative of "freeloaders" when it comes to Alma and Rocky Linux. I really hope some org from perhaps the BSDs will take over maintainership of Xorg instead of allowing RedHat to shutter it. Choice is good.

dralley 3y ago
Who are these souls that would be maintaining Xorg, if only the nefarious Red Hat had not been doing so (laggardly, according to you)? Are they spending their free time working on Xorg, or are they being paid to do so by an employer? Which employer would that be, that has a reason to care about desktop linux AND is motivated to support Xorg specifically over Wayland?

dathinab 3y ago

yes and I'm seeing many of the same kind of arguments as with systemd like arguments you could re-formulate as "but my kinda uncommon setup which is irrelevant for the maintainers and sponsors of which do the decision will not work and it's bad to not support everyone for free" or "but you can't to X in that specific way and because of that you can't do so at all (ignoring alternative ways) and because of that it can't replace it at all" or "hung up on some technical detail which doesn't matter for 99% of users" or "my software which wasn't properly updated since 10 years doesn't work flawless under Wayland" or "hung up on something which wasn't supported initially but is supported since multiple years by now" in the end someone will probably continue to support Xorg and someone will probably maintain it and it probably will get increasingly more painful to run it but it also will take many years until it really hurts and it probably will be banned from most companies caring about security and people starting to use Linux in some years in the future will probably not really know what Xorg is except is that thing related to some ancient programs not behaving nicely and they will wonder what it has to do with X(Twitter) and if thats why it's no longer used.