Live data from Hacker News

Gnome developer proposes removing the X11 session

theregister.com

101–110 of 122 posts

Re: Gnome developer proposes removing the X11 session

#101
post #96

Earlier quoted context omitted.

That's the same limitation as XQuartz or any other rootless X server. And you have this exactly backwards. The majority of X clients that users care about are ordinary programs, not window managers or xdotool.

> The majority of X clients that users care about are ordinary programs This is simply not true. The only "odinary" programs according to your definition that I am running are a browser and a terminal. All other xclients I'm running go beyond that and can not work with Xwayland or XQuartz. (a quick ´grep "^[x,X]" .bash_history´ reveals xautolock, xbacklight, xbel, xcalib, xcape, xdpyinfo, xdotool, xkill, xmodmap, xra…

Which X clients are these? You didn't name any so let's just look at some of the popular and recent flathub apps: https://flathub.org/

I see a lot of games, chat apps, text editors, photo apps, office apps. These all will work fine in XWayland and XQuartz. But also, it's relatively easy to get them running on Wayland natively.

Re: Gnome developer proposes removing the X11 session

#102
post #95

Earlier quoted context omitted.

>X11 is one of the few APIs that had a really long run and that everybody in the community agrees upon Outside of a very small niche of obscure window manager developers, this isn't true. GNOME and KDE have been trying to get rid of it for decades. The glaring flaws in the API have been known for that long. >38 years of backwards compatibility and still being able to deliver performance No, the Xorg server actually l…

> GNOME and KDE Both are are really bad desktop environments and part of the reason the FOSS desktop never took off. Also they are mostly developed by full time paid employees with zero community involvement. As such they are the small niche. > The glaring flaws in the API have been known for that long. X11 has flaws but I wouldn't call them "glaring". They are a nuisance at best. You don't pay for functionality you…

>Also they are mostly developed by full time paid employees with zero community involvement.

No. Both of them have a good mix of community contributors to do the fun stuff, and paid employees to do the annoying tasks no one wants to do for free. A good project needs both. Are you really suggesting that another desktop is somehow going to spring up and succeed with no paid employees and no business case? If what you're saying is true, wouldn't that have already happened and left GNOME and KDE in the dust long ago?

>You don't pay for functionality you don't need.

You actually do if you're maintaining the X server and protocol.

>Wayland has glaring flaws because it does not provide and standardize functionality that people need.

These can be fixed by extending the protocol, unlike in X11 where the flaws can't be fixed because they're built into the core.

>It also has severe technical flaws like implicit sync which makes all your application stutter when one application has high GPU load.

This is actually a kernel/driver problem. It also happens in X11 if you use a driver with implicit sync.

>Great, so there is a regular organic and efficient clean up process happening that keeps the unused or unpopular stuff out of X11. There shouldn't be much "old cruft" around then. If this is the case, why do we need Wayland?

No that's not what's happening either. Lots of current X11 extensions (such as Big Requests, XC Misc, XFixes, XSync) actually exist only to paper over old cruft in the core protocol that can never be removed. It's possible to remove other extensions from the core and still keep the core intact. When the core X11 protocol itself becomes unused and unpopular (which it is) then it's time to remove the whole thing.

Re: Gnome developer proposes removing the X11 session

#103

Earlier quoted context omitted.

No it actually doesn't, I've heard tons of complaints about X clients not scaling correctly. Sure it might work for the subset of clients that are reading the DPI value the way you intended, but in doing so you've silently broke a lot of other clients.

The "subset" of clients using Xcb or Qt? I'm fine with only counting them, personally...

This comment makes no sense, XCB isn't a toolkit. You might be thinking of something else with a similar acronym.

But anyway, any solution that tells users to only use a small subset of compatible clients is about as disruptive as just switching wholesale to Wayland. It's not the reason anyone is hanging on to the X server.

Re: Gnome developer proposes removing the X11 session

#104

Earlier quoted context omitted.

> So, basic functionality is still not there 15 years after release. X11 didn't have what we currently consider "basic functionality" for decades after its release. The design of X11 says that every application connected to your display is completely trusted, hence why it can grab any key (and thus be a keylogger if it wants to be). The design of Wayland starts with the premise that every application connecting to yo…

It has nothing to do with security and everything to do with hollowing out all generic functionality and passing it on to the compositor. In other words, the devs are lazy and went for a minimalist approach and now we all get to suffer.

Wow calling FOSS developers lazy is pretty low.

Re: Gnome developer proposes removing the X11 session

#105
post #38

Earlier quoted context omitted.

It is not a strange premise. It is the security model that for example Android uses. Unix security model is dated, and it is good that steps are taken in this direction.

Android is different, it is built to run untrusted apps. My Linux Desktop runs Chromium, xterm, IntelliJ and occasionally Gimp. Do I need the Wayland security model? Hardly so. Am I an outlier among Linux Desktop users? Hardly so.

The point is to reduce the attack surface, especially for browsers that run untrusted input. You don't want a local exploit in your browser (that hopefully is also configured not to have access to your entire filesystem) to screenshot other apps and websites. Maybe you disable all the warnings in IntelliJ too that prompt you to be careful when opening a new Git project from a remote source?

Re: Gnome developer proposes removing the X11 session

#106

Earlier quoted context omitted.

"Python 2.8" implies it's the One True Continuation of Python 2.7, as opposed to someone's random fork.

Is there another continuation of Python 2.7 you know of? He literally took over an abandoned codebase, and got sued for calling it the codebase's name.

You can't release new code that is incompatible with Python and call it Python if you have not been allowed to do so by the Python Software Foundation. It's like, basic trademark law.

Re: Gnome developer proposes removing the X11 session

#107

GNOME (and many others) have spent years telling anyone who has issues with Wayland that lead them to run an X session to report bugs, and has put a lot of effort into fixing those bugs. This seems like a reasonable next step. > This plan seems to The Reg's FOSS Desk to be strong-arming people into adopting Wayland. Or, more reasonably, to maintain less code for alternate paths in favor of fixing the issues that lead…

If the article is still correct, and Wayland doesn't work with the Nvidia binary drivers then that's a hard blocker for at least myself. :/ That being said, I'm still using Ubuntu 20.04 LTS on my desktop as I prefer stable systems. That way I can put time into the things I'm interested in more. :) So, as long as it all works nicely by the time I need to change from Ubuntu 20.04, then I likely won't particularly care…

It works perfectly fine on Debian testing (in fact the X session developed show-stopper bugs that forced me to use Wayland), so it should be on Ubuntu soon.

Re: Gnome developer proposes removing the X11 session

#108
post #12

Earlier quoted context omitted.

The way multihead works in modern XOrg is basically a hack to enable seamless dragging of windows across physical display boundaries. Once upon a time you'd do multihead on X with discrete screens and your display environment variable would be something like DISPLAY=:0.0 vs. DISPLAY=:0.1 where the last digit after the dot was the screen number. But your X client would then be confined to that screen. In this old mann…

IDK if ability to drag a window between screens is something more important than properly supporting different DPIs; but that might be a decent level of ignorance on my part

Eh, I lived with the limitation back in the XFree86 4.0 / beta multihead support days on an array of Matrox Millenium PCI cards.

While it technically works, you quickly discover the importance of being able to organize windows to different physical displays after the programs are already running / the windows have been created.

Requiring exiting and relaunching things to migrate them to different physical screens gets old fast.

Re: Gnome developer proposes removing the X11 session

#109
post #96

Earlier quoted context omitted.

That's the same limitation as XQuartz or any other rootless X server. And you have this exactly backwards. The majority of X clients that users care about are ordinary programs, not window managers or xdotool.

> The majority of X clients that users care about are ordinary programs This is simply not true. The only "odinary" programs according to your definition that I am running are a browser and a terminal. All other xclients I'm running go beyond that and can not work with Xwayland or XQuartz. (a quick ´grep "^[x,X]" .bash_history´ reveals xautolock, xbacklight, xbel, xcalib, xcape, xdpyinfo, xdotool, xkill, xmodmap, xra…

Replying again because you edited your comment.

xbacklight, xcalib, xcape, xmodmap, xrandr, xset: These are utilities specific to configuring the X server. They're needed on non-X11 window systems.

xbel: I don't know what this is.

xdotool: Some commands will still work. Other commands that require interaction from the window manager might not work, but they won't work on some X11 window managers either.

xrdb, xsel, xkill: These still work, although for obvious reasons they won't affect native Quartz or Wayland applications.

By the way, none of those are ordinary X applications. Notice how none of them actually display any windows or having graphical interactions with the user? You know, that thing that X11 is designed to do? Put windows on the screen?

Re: Gnome developer proposes removing the X11 session

#110
post #105

Earlier quoted context omitted.

Android is different, it is built to run untrusted apps. My Linux Desktop runs Chromium, xterm, IntelliJ and occasionally Gimp. Do I need the Wayland security model? Hardly so. Am I an outlier among Linux Desktop users? Hardly so.

The point is to reduce the attack surface, especially for browsers that run untrusted input. You don't want a local exploit in your browser (that hopefully is also configured not to have access to your entire filesystem) to screenshot other apps and websites. Maybe you disable all the warnings in IntelliJ too that prompt you to be careful when opening a new Git project from a remote source?

Browsers are already sandboxed.
Post reply on HN