| View previous topic :: View next topic |
| Author |
Message |
flexibeast
Guru
Joined: 04 Apr 2022
Posts: 448
Location: Naarm/Melbourne, Australia
|
 Posted: Mon Nov 11, 2024 11:57 pm Post subject: |
 |
|
| metapsyborg wrote: | | I hope Xorg continues to be supported. I see no point in wayland. Xorg is not broken so I see no reason to "fix" it. |
Xorg devs frustrated by the effort involved in maintaining Xorg / keeping it "not broken"[a] are amongst the people pushing Wayland - cf. this comment of mine upthread re. a presentation by Xorg dev Matthieu Herrb, and this presentation by former Xorg dev Daniel Stone. So unless a number of people step up and volunteer to take on this work, Xorg is, as Herrb said, probably going away.
[a] As a side note, my experience is that people who don't have to maintain software themselves often underappreciate how much effort can be required to keep something working in the face of continual changes in the surrounding ecosystem, whether the software or hardware or both. Like: "Oh, this library we use has changed how it does things, so now we need to change how our software uses that library". Cf. bitrot / software rot.
_________________
https://wiki.gentoo.org/wiki/User:Flexibeast |
|
| Back to top |
|
 |
pingtoo
Veteran
Joined: 10 Sep 2021
Posts: 1243
Location: Richmond Hill, Canada
|
| Posted: Tue Nov 12, 2024 12:40 am Post subject: |
|
|
| flexibeast wrote: | | metapsyborg wrote: | | I hope Xorg continues to be supported. I see no point in wayland. Xorg is not broken so I see no reason to "fix" it. |
Xorg devs frustrated by the effort involved in maintaining Xorg / keeping it "not broken"[a] are amongst the people pushing Wayland - cf. this comment of mine upthread re. a presentation by Xorg dev Matthieu Herrb, and this presentation by former Xorg dev Daniel Stone. So unless a number of people step up and volunteer to take on this work, Xorg is, as Herrb said, probably going away.
[a] As a side note, my experience is that people who don't have to maintain software themselves often underappreciate how much effort can be required to keep something working in the face of continual changes in the surrounding ecosystem, whether the software or hardware or both. Like: "Oh, this library we use has changed how it does things, so now we need to change how our software uses that library". Cf. bitrot / software rot. |
Thank you, This also my understanding on how Wayland come about.
However I wonder, Does Wayland developer currently also suffer what they criticise on Xorg? Those surroundings for X also same for Wayland. The major difference are Wayland code being newly written therefor it is more familiar therefor easier to follow/change. Whereas Xorg have 10s of year of code that become hard to follow and change.
Will Wayland 30 years from now with new generation developer need to have Wayland+? 
Personally I prefer X design. The client/server architecture is much better then the Wayland with monolithic(relative to X) architecture. However I like the most is NeXT displayserver (postscript)
Currently use Gnome(wayland) and Xfce(Xorg). |
|
| Back to top |
|
|
flexibeast
Guru
Joined: 04 Apr 2022
Posts: 448
Location: Naarm/Melbourne, Australia
|
| Posted: Tue Nov 12, 2024 1:50 am Post subject: |
|
|
| pingtoo wrote: | | Does Wayland developer currently also suffer what they criticise on Xorg? Those surroundings for X also same for Wayland. |
The difference is that the underlying design of Xorg is actually very complex, such that the Xorg devs have had to work around a lot of issues to get X to provide the functionality it currently does - refer to slide 37 onwards of Stone's presentation. Slide 46, talking of what happened with X, talks of "At least 25 more extensions / Thousands more pages of spec"; slide 70 says "Three people on this earth understand X input"; slide 71 says "really wish I wasn't one of them". Talking of working on Xorg, slides 77-82 say: "We shifted all the paradigms", "Themes got harder / We drew them client-side", "Fonts got harder / We drew them client-side", "Subwindows got in the way / We moved them client-side", "Window management got harder / We got the WM to draw everything". Then slide 96 asks "And what's the X server [nowadays]?", to which slide 97 says "Really bad IPC", with further slides going into detail about why it's so bad.
The idea with Wayland, as i understand, is to have a much less complex underlying design, which both reflects current usage requirements and patterns (e.g. those of gamers, of which i am not one!) and makes it much easier to adapt to future requirements and patterns than X has proved itself to be (cf. the details in the slides).
| pingtoo wrote: | | The major difference are Wayland code being newly written therefor it is more familiar therefor easier to follow/change. Whereas Xorg have 10s of year of code that become hard to follow and change. |
No, that's not the only difference; it's not just that the X code is old. There are fundamental architectural/design issues with X, as noted in the slides (and not only the ones i quoted). i strongly encourage people to actually read through those slides, to get an understanding of what the Xorg devs have been trying to wrestle with.
| pingtoo wrote: | | Will Wayland 30 years from now with new generation developer need to have Wayland+? |
Potentially yes, because we can't entirely foresee the future. Wayland has been developed by - amongst others - Xorg devs with concrete experience of how certain design decisions can significantly influence the ability to make changes, but they're surely not infallible, and it's certainly possible that technology will take a path that Wayland will be difficult to adapt to.
Xorg has fundamentally been working for me, and i don't 'need' Wayland in the way that others do. At the same time, i feel its important to acknowledge that this is primarily due to heroic efforts on the part of Xorg devs, and it's them saying "Xorg is a real hassle to maintain; the underlying design of Wayland will allow a number of these sort of hassles to be avoided" that's led me to actually get the bit between the teeth and move to Wayland (adding stuff i learn to the wiki along the way).
_________________
https://wiki.gentoo.org/wiki/User:Flexibeast |
|
| Back to top |
|
|
dmpogo
Advocate
Joined: 02 Sep 2004
Posts: 3425
Location: Canada
|
| Posted: Tue Nov 12, 2024 6:48 am Post subject: |
|
|
| pingtoo wrote: |
Will Wayland 30 years from now with new generation developer need to have Wayland+?
Personally I prefer X design. The client/server architecture is much better then the Wayland with monolithic(relative to X) architecture. However I like the most is NeXT displayserver (postscript)
Currently use Gnome(wayland) and Xfce(Xorg). |
X-windows have a imaginative forward looking (and having survived 35 years) vision of interconnected computers displaying information on displays elsewhere (which blew me away when I first started using it in 1992). Wayland's vision is a boring phone. where wayland basically does little, offloading real work to third parties. |
|
| Back to top |
|
|
lars_the_bear
Guru
Joined: 05 Jun 2024
Posts: 520
|
| Posted: Tue Nov 12, 2024 9:06 am Post subject: |
|
|
| dmpogo wrote: |
X-windows have a imaginative forward looking (and having survived 35 years) vision of interconnected computers displaying information on displays elsewhere (which blew me away when I first started using it in 1992). Wayland's vision is a boring phone. where wayland basically does little, offloading real work to third parties. |
For better or worse, Wayland's vision probably suits > 95% of the ways that people use desktop computers. After all, desktop computer and phone functionality now overlap considerably. All the interconnectedness you mention, while undoubtedly clever, is rarely used these days.
As ever, though, it's the niche applications, the < 5%, that get screwed over. There are applications and installations that use the few things that X offers, that Wayland does not. There's a hard road ahead, I think, for the people that maintain those systems.
My main concern is that Linux development, in general, is being driven by desktop thinking. That something is good for desktop Linux doesn't necessarily make it good for servers, embedded systems, etc. Wayland seems to be me to be entirely desktop-focussed. Of course, you're probably not running X or Wayland on your embedded gadget; but I worry that all the effort of Linux developers is going into desktop applications, while desktop Linux is only a small part of the overall Linux install base.
In addition, my experience is that, when we replace something that is old and hard to maintain, with a new, shiny thing that should be simple and easy to maintain, it's never very long before the new thing is hard to maintain as well. I've seen this time and again in my professional life.
BR, Lars. |
|
| Back to top |
|
|
metapsyborg
n00b
Joined: 28 Sep 2011
Posts: 25
|
| Posted: Wed Nov 13, 2024 4:37 pm Post subject: |
|
|
| lars_the_bear wrote: | | it's never very long before the new thing is hard to maintain as well. |
This 100%. The new thing only ever retains its simplicity by taking a hard-line stance against user requirement bloat. Sure there's a new team of devs who know the new codebase better than the old codebase, but as they add more and more new features to reach parity with the old product then the new codebase becomes just as bloated and spaghettified as the old codebase. Any simplicity that they are able to maintain is due to over reliance on third party libraries and by simply refusing to implement or support a variety of user requirements that the old product did support.
"Next gen" products are instigated by the hubris of young developers and product managers who think they can do it better than the old devs who have been working on and maintaining a 30 year old codebase.
It's possible that wayland can remain firm in its resistance to adding features that compromise its clear and simple design vision, but I doubt it. More likely they will make more and more concessions to "modern" designs like systemd or whatever "unity" or "snap" type bs that cannonical pushes. |
|
| Back to top |
|
|
metapsyborg
n00b
Joined: 28 Sep 2011
Posts: 25
|
| Posted: Wed Nov 13, 2024 4:58 pm Post subject: |
|
|
| flexibeast wrote: | | pingtoo wrote: | | Does Wayland developer currently also suffer what they criticise on Xorg? Those surroundings for X also same for Wayland. |
The difference is that the underlying design of Xorg is actually very complex, such that the Xorg devs have had to work around a lot of issues to get X to provide the functionality it currently does - refer to slide 37 onwards of Stone's presentation. Slide 46, talking of what happened with X, talks of "At least 25 more extensions / Thousands more pages of spec"; slide 70 says "Three people on this earth understand X input"; slide 71 says "really wish I wasn't one of them". Talking of working on Xorg, slides 77-82 say: "We shifted all the paradigms", "Themes got harder / We drew them client-side", "Fonts got harder / We drew them client-side", "Subwindows got in the way / We moved them client-side", "Window management got harder / We got the WM to draw everything". Then slide 96 asks "And what's the X server [nowadays]?", to which slide 97 says "Really bad IPC", with further slides going into detail about why it's so bad.
The idea with Wayland, as i understand, is to have a much less complex underlying design, which both reflects current usage requirements and patterns (e.g. those of gamers, of which i am not one!) and makes it much easier to adapt to future requirements and patterns than X has proved itself to be (cf. the details in the slides).
| pingtoo wrote: | | The major difference are Wayland code being newly written therefor it is more familiar therefor easier to follow/change. Whereas Xorg have 10s of year of code that become hard to follow and change. |
No, that's not the only difference; it's not just that the X code is old. There are fundamental architectural/design issues with X, as noted in the slides (and not only the ones i quoted). i strongly encourage people to actually read through those slides, to get an understanding of what the Xorg devs have been trying to wrestle with.
| pingtoo wrote: | | Will Wayland 30 years from now with new generation developer need to have Wayland+? |
Potentially yes, because we can't entirely foresee the future. Wayland has been developed by - amongst others - Xorg devs with concrete experience of how certain design decisions can significantly influence the ability to make changes, but they're surely not infallible, and it's certainly possible that technology will take a path that Wayland will be difficult to adapt to.
Xorg has fundamentally been working for me, and i don't 'need' Wayland in the way that others do. At the same time, i feel its important to acknowledge that this is primarily due to heroic efforts on the part of Xorg devs, and it's them saying "Xorg is a real hassle to maintain; the underlying design of Wayland will allow a number of these sort of hassles to be avoided" that's led me to actually get the bit between the teeth and move to Wayland (adding stuff i learn to the wiki along the way). |
I just read the slides. He sounds like he has a chip on his shoulder and has "I can do it better" syndrome (ie hubris). Wayland absolutely will be bloated and have architectural compromises as it adds new features to reach parity with xorg. Sure maybe it can be more straight-forward to develop and maintain but as the current devs retire/more-on and new devs come around, then it will lose most of that advantage. Large software projects are just plain complicated and difficult. No one understands the entire thing at the detailed level.
Those slides apparently were written in 2013. Over a decade on, and my computer won't wake up from screen-off when using wayland + weston. Basic functionality should work; I don't have a complicated setup or use flags and I use a modern amd gpu.
Also this comment of his about a compositor: "has too much C++ for my liking". What does that mean? He wants a higher level language or lower level one? |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6147
Location: Dallas area
|
| Posted: Wed Nov 13, 2024 4:59 pm Post subject: |
|
|
If you want to stick with X, then stick with it, no one is forcing anyone to go to wayland.
Wayland is getting lots of development, while X is basically in maintenance mode.
Don't expect things like HDR, vrr, etc to be added to X.
I've been around long enough to see X go from from servers w/attached X-terminals to X on a pc.
I also remember when X wasn't that stable/usable, X from 2000+ isn't the same as X-1995, or X-1985.
This biggest problem with X is that over time it's become a code nightmare.
Like messing with a bunch of pickup sticks. Touch one thing and something happens somewhere else you didn't expect.
No one person really understands the whole of X and how the parts interact, thus part of the reason that wayland exists.
There are some things that X does better than wayland, at the moment.
Wayland offers some things that X doesn't have or is likely to implement.
Time moves on, adjust or not, it's each individuals choice.
While X was nice in it's day, so was my 8088 pc or 80286 pc, but I don't cling to them shaking my fist at modern stuff.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
stefantalpalaru
Tux's lil' helper
Joined: 11 Jan 2009
Posts: 77
Location: Italy
|
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6147
Location: Dallas area
|
| Posted: Wed Nov 13, 2024 5:19 pm Post subject: |
|
|
It's not that X handles vrr per se, xrandr and video drivers are handling it, X just allows it.
Nothing in X takes advantage of it, applications do, but they aren't X.
The ability to turn it on or off is added to X, but that's about the extent of it.
Edit to add: It does look like they are trying to get vrr IN X, but as of as few months ago, not a lot of progress.
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1616 - and this is the guy working on it.
| Quote: | | We don't have a standard protocol for enabling VRR yet, but some time ago an ad-hoc had been made in the amdgpu driver (later also copied to modsetting), which works by client setting the _VARIABLE_REFRESH window property... |
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
