14 ms·

> what's so wrong with X11 so people need to replace it 1. Security - Any program using X11 can read keystrokes, passwords, or the contents of any other window

by gary_0 11mo ago

> what's so wrong with X11 so people need to replace it 1. Security - Any program using X11 can read keystrokes, passwords, or the contents of any other window. Fixing this would break all existing X11 applications. 2. Performance - X11's client-server model doesn't work with hardware accelerated graphics, requiring hacks to get around. X11 is basically stuck with this legacy. The ground-up re-design of X11 to fix those two issues is Wayland.

Pet_Ant 11mo ago
> X11's client-server model doesn't work with hardware accelerated graphics I really wish they would figure this out. It just feels like with Threadripper etc the time is perfect for a return of thin-clients/not-so-dummy terminals running X11-like applications over the network on a server. Especially for development where many of us are running under-powered laptops and could use the boost to compilation from a beefy machine.
- ChocolateGod 11mo ago
  It's not really something to figure out, it's just X protocol design was made for when thin clients running over the network was assumed to be the future, it wasn't. Unfortunately though unlike Mac or Windows the migration to a better protocol has been ugly. When you start to consider things such as HDR, hardware planes (important if you want energy efficient video decoding) etc, the protocol just doesn't make that kind of thing easy, compared to Wayland which does by it's use of surfaces etc.
- Balinares 11mo ago
  There is nothing to figure out, unfortunately. The design of X11 precludes hardware acceleration; the hardware acceleration you see on a X11 desktop works by using extensions to entirely route around the X11 client-server model. To make it work they'd need to rethink the design. And they did -- that's how we got Wayland.
  - Pet_Ant 11mo ago
    > The design of X11 precludes hardware acceleration I wasn't talking about X11, just that capability. Never heard of Waypipe before, but it was mentioned in a sibling comment, and that might be exactly what I'm looking for. https://gitlab.freedesktop.org/mstoeckl/waypipe/ https://gitlab.freedesktop.org/mstoeckl/waypipe/
- aseipp 11mo ago
  If you want thin client like behavior, you should look at stuff like Waypipe or just outright using RDP directly, both of which are much better at the job of "display remote graphical application on my computer" than X11's client-server design ever managed to accomplish. If anything, the variety of alternative solutions for that today -- everything from single-app to high-res full-desktop game streaming -- are much more robust and viable on modern networks than the X approach ever was, even if it was a neat-o "freebie" thing that fell out of its design. You get what you pay for, I guess.
- account42 10mo ago
  It has already been figured out long ago, which is how we have hardware acceleration on X today. Wayland fanboys calling it a "workaround" does not change that it works.
ferguess_k 11mo ago
Thanks. I see both are very valid reasons to drop X11.
ottah 11mo ago
I 100% agree with the performance improvement goals, but I think the security claims are overblown, and overly cautious. I honestly don't understand the point of trying to implement the security boundary in the display manager. It solves one class of security issues, while breaking a lot of accessibility and automation. The display manager just shouldn't be enforcing rigid per processes security controls, that's better done further down the stack. Or at a minimum security controls should respect user freedom enough to let a user access normally restricted features, with out the all or nothing elevation to root. There's a middle ground here where we don't break the world, and they get their shiny security policies.
- creatonez 11mo ago
  > that's better done further down the stack If you do it further down the stack, you break accessibility and automation even more... this has been tried. Doesn't work. The end goal is to have actually working Android-like sandboxing rather than some broken firejail crap.
  - ottah 11mo ago
    So we don't get the security benefits or accessibility. I'm not sure what is being solved. I'm all for a modern display system, I'm just not convinced the security claims are in anyway justified.
    - creatonez 10mo ago
      How is preventing apps from spying on each other through the display manager not justified? That's the lowest hanging fruit for desktop sandboxing.
- aidenn0 11mo ago
  I think The fact that people e.g. run the ydotool service as root is an example of this. It's like making a safe that is so hard to open that people just drill a hole in the bottom; you end up with something less secure than a safe that was easier to open.
- 11mo ago
duckmysick 11mo ago
On the other hand, #1 makes it extremely difficult (if not impossible at all) to have a decent UI automation on Wayland. Sure, you can still do it if you're not leaving the terminal or a web browser, but anything else (including Electron apps) is a no-go. All the existing tools are written for X11. The last time I looked into it, I found out I would have to deal with each compositor separately. On top of that, the target apps would have to be written with the new API in mind.
pabs3 10mo ago
> 1. Security - Any program using X11 can read keystrokes ... IIRC: this isn't quite correct, there was an extension called XACE that can block this. Probably Xorg didn't implement it and desktops didn't have support for it though. https://www.x.org/archive/X11R7.5/doc/security/XACE-Spec.html https://www.x.org/archive/X11R7.5/doc/security/XACE-Spec.htm...
account42 10mo ago
> 1. Security - Any program using X11 can read keystrokes, passwords, or the contents of any other window. Fixing this would break all existing X11 applications. This is a feature not an issue. And it's how every computer that hasn't tried to take away control from its users has worked. I WANT my programs to be empowered to act on my behalf. If you want a gimped platform to run untrusted apps go buy a phone. > 2. Performance - X11's client-server model doesn't work with hardware accelerated graphics, requiring hacks to get around. X11 is basically stuck with this legacy. It works very well in fact. What you call hacks is something you probably cannot comprehend: Actual long term backwards compatibility. All programs should strive to have more of that, but especially central ones like the display server. > The ground-up re-design of X11 to fix those two issues is Wayland. It does limit what programs can do and breaks backwards compatibility, yes. That's the problem.
- gary_0 10mo ago
  While Wayland has kind of been a disaster I disagree with your premise. > 1. Security Linux (and Unix before it) has always had security mechanisms built in. File permissions, setuid bits, namespaces. Any old program shouldn't be able to access /etc/passwd, and likewise the `<input type="password">` in my browser should be protected. Wayland's problem isn't that it tried to add security, but that the design and development process went horrifically wrong so that 17 years after the first release, people still have trouble with screen sharing. > 2. Performance The client-server model is obsolete and unsupported by modern applications (and nowadays there are easier ways to do remote GUI access) and keeping it was just a big pile of tech debt. The problem wasn't that Wayland tried to fix things, it's that the process took 17 years and still isn't finished or particularly successful. My uneducated guess at why Wayland failed to succeed is that it went for extreme modularity and refused to say (back in like 2009) "Here's the security mechanism everyone has to use to take screenshots, etc. If this breaks your spacebar heater, sucks to be you." Rather than just define a single API where 99% of graphical applications and desktop utilities can do the sorts of things they already do on Windows and MacOS, and call it 1.0, instead they built a sprawling monument to bikeshedding and over-engineering.
  - Sprocklem 10mo ago
StillBored 10mo ago
https://www.x.org/releases/X11R7.6/doc/xextproto/security.html#image_security https://www.x.org/releases/X11R7.6/doc/xextproto/security.ht... Is the security extension from 1996, which has a section on keyboard security and its crazy to me that this anyone can claim X11 can't be off loaded, which its been doing for decades. From all the crazy blt/pattern HW acceleration to GL/vulcan implementations to the fact that the entire server can be on the other side of a network pipe, meaning it could be anywhere, including entirely encapsulated on a graphics card/smart nic/etc. And if your talking about the xlib serialization, that was largely fixed with XCB.

by gary_0 11mo ago

Pet_Ant 11mo ago

> X11's client-server model doesn't work with hardware accelerated graphics I really wish they would figure this out. It just feels like with Threadripper etc the time is perfect for a return of thin-clients/not-so-dummy terminals running X11-like applications over the network on a server. Especially for development where many of us are running under-powered laptops and could use the boost to compilation from a beefy machine.

ChocolateGod 11mo ago
It's not really something to figure out, it's just X protocol design was made for when thin clients running over the network was assumed to be the future, it wasn't. Unfortunately though unlike Mac or Windows the migration to a better protocol has been ugly. When you start to consider things such as HDR, hardware planes (important if you want energy efficient video decoding) etc, the protocol just doesn't make that kind of thing easy, compared to Wayland which does by it's use of surfaces etc.
Balinares 11mo ago
There is nothing to figure out, unfortunately. The design of X11 precludes hardware acceleration; the hardware acceleration you see on a X11 desktop works by using extensions to entirely route around the X11 client-server model. To make it work they'd need to rethink the design. And they did -- that's how we got Wayland.
- Pet_Ant 11mo ago
  > The design of X11 precludes hardware acceleration I wasn't talking about X11, just that capability. Never heard of Waypipe before, but it was mentioned in a sibling comment, and that might be exactly what I'm looking for. https://gitlab.freedesktop.org/mstoeckl/waypipe/ https://gitlab.freedesktop.org/mstoeckl/waypipe/
aseipp 11mo ago
If you want thin client like behavior, you should look at stuff like Waypipe or just outright using RDP directly, both of which are much better at the job of "display remote graphical application on my computer" than X11's client-server design ever managed to accomplish. If anything, the variety of alternative solutions for that today -- everything from single-app to high-res full-desktop game streaming -- are much more robust and viable on modern networks than the X approach ever was, even if it was a neat-o "freebie" thing that fell out of its design. You get what you pay for, I guess.
account42 10mo ago
It has already been figured out long ago, which is how we have hardware acceleration on X today. Wayland fanboys calling it a "workaround" does not change that it works.

ferguess_k 11mo ago

Thanks. I see both are very valid reasons to drop X11.

ottah 11mo ago

I 100% agree with the performance improvement goals, but I think the security claims are overblown, and overly cautious. I honestly don't understand the point of trying to implement the security boundary in the display manager. It solves one class of security issues, while breaking a lot of accessibility and automation. The display manager just shouldn't be enforcing rigid per processes security controls, that's better done further down the stack. Or at a minimum security controls should respect user freedom enough to let a user access normally restricted features, with out the all or nothing elevation to root. There's a middle ground here where we don't break the world, and they get their shiny security policies.

creatonez 11mo ago
> that's better done further down the stack If you do it further down the stack, you break accessibility and automation even more... this has been tried. Doesn't work. The end goal is to have actually working Android-like sandboxing rather than some broken firejail crap.
- ottah 11mo ago
  So we don't get the security benefits or accessibility. I'm not sure what is being solved. I'm all for a modern display system, I'm just not convinced the security claims are in anyway justified.
  - creatonez 10mo ago
    How is preventing apps from spying on each other through the display manager not justified? That's the lowest hanging fruit for desktop sandboxing.
aidenn0 11mo ago
I think The fact that people e.g. run the ydotool service as root is an example of this. It's like making a safe that is so hard to open that people just drill a hole in the bottom; you end up with something less secure than a safe that was easier to open.
11mo ago

duckmysick 11mo ago

On the other hand, #1 makes it extremely difficult (if not impossible at all) to have a decent UI automation on Wayland. Sure, you can still do it if you're not leaving the terminal or a web browser, but anything else (including Electron apps) is a no-go. All the existing tools are written for X11. The last time I looked into it, I found out I would have to deal with each compositor separately. On top of that, the target apps would have to be written with the new API in mind.

pabs3 10mo ago

> 1. Security - Any program using X11 can read keystrokes ... IIRC: this isn't quite correct, there was an extension called XACE that can block this. Probably Xorg didn't implement it and desktops didn't have support for it though. https://www.x.org/archive/X11R7.5/doc/security/XACE-Spec.html https://www.x.org/archive/X11R7.5/doc/security/XACE-Spec.htm...

account42 10mo ago

> 1. Security - Any program using X11 can read keystrokes, passwords, or the contents of any other window. Fixing this would break all existing X11 applications. This is a feature not an issue. And it's how every computer that hasn't tried to take away control from its users has worked. I WANT my programs to be empowered to act on my behalf. If you want a gimped platform to run untrusted apps go buy a phone. > 2. Performance - X11's client-server model doesn't work with hardware accelerated graphics, requiring hacks to get around. X11 is basically stuck with this legacy. It works very well in fact. What you call hacks is something you probably cannot comprehend: Actual long term backwards compatibility. All programs should strive to have more of that, but especially central ones like the display server. > The ground-up re-design of X11 to fix those two issues is Wayland. It does limit what programs can do and breaks backwards compatibility, yes. That's the problem.

gary_0 10mo ago
While Wayland has kind of been a disaster I disagree with your premise. > 1. Security Linux (and Unix before it) has always had security mechanisms built in. File permissions, setuid bits, namespaces. Any old program shouldn't be able to access /etc/passwd, and likewise the `<input type="password">` in my browser should be protected. Wayland's problem isn't that it tried to add security, but that the design and development process went horrifically wrong so that 17 years after the first release, people still have trouble with screen sharing. > 2. Performance The client-server model is obsolete and unsupported by modern applications (and nowadays there are easier ways to do remote GUI access) and keeping it was just a big pile of tech debt. The problem wasn't that Wayland tried to fix things, it's that the process took 17 years and still isn't finished or particularly successful. My uneducated guess at why Wayland failed to succeed is that it went for extreme modularity and refused to say (back in like 2009) "Here's the security mechanism everyone has to use to take screenshots, etc. If this breaks your spacebar heater, sucks to be you." Rather than just define a single API where 99% of graphical applications and desktop utilities can do the sorts of things they already do on Windows and MacOS, and call it 1.0, instead they built a sprawling monument to bikeshedding and over-engineering.
- Sprocklem 10mo ago

StillBored 10mo ago

https://www.x.org/releases/X11R7.6/doc/xextproto/security.html#image_security https://www.x.org/releases/X11R7.6/doc/xextproto/security.ht... Is the security extension from 1996, which has a section on keyboard security and its crazy to me that this anyone can claim X11 can't be off loaded, which its been doing for decades. From all the crazy blt/pattern HW acceleration to GL/vulcan implementations to the fact that the entire server can be on the other side of a network pipe, meaning it could be anywhere, including entirely encapsulated on a graphics card/smart nic/etc. And if your talking about the xlib serialization, that was largely fixed with XCB.