Hacker News new | ask | show | jobs
by olgeni 979 days ago
Reminds me of systemd: we "modern" developers despise anything that reminds us of "traditional" Unix, thus we need to rewrite it in such a way that is not only new, but actively punishes unwelcome users.

Then we will complain about "embrace and extend" while people try to replace their xdotool scripts and their perfectly working X11 setups.

Too bad for them: we don't care about custom applications, we still aim to just steal users from Windows. And 2024 will be the Year of Linux on the Desktop.

1 comments

X11 has nothing to do with "traditional" Unix. Even back in the 80s the UNIX philosophy didn't work with a graphics stack and X11 itself is very un-Unix-like. This is even more true for the modern graphics stack. That being said, X11 is one of the few APIs that had a really long run and that everybody in the community agrees upon. This is extremely rare. 38 years of backwards compatibility and still being able to deliver performance on the most modern graphics stacks is a tremendously huge value that shouldn't be thrown away just because some IBM/Redhat or Collabora employee says so.
>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 lacks backward compatibility with lots of non-standard X11 extensions that for whatever reason were either removed or were never merged upstream. At the time some of those may have been the best way to deliver performance on specific hardware but, like anything, they didn't hold up and were thrown away. It wasn't because an IBM/Redhat or Collabora employee said so. See also https://en.wikipedia.org/wiki/X_Window_System_protocols_and_...

> 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 don't need. Wayland has glaring flaws because it does not provide and standardize functionality that people need. It also has severe technical flaws like implicit sync which makes all your application stutter when one application has high GPU load.

> Xorg server actually lacks backward compatibility with lots of non-standard X11 extensions that for whatever reason were either removed or were never merged upstream.

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?

>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.

The API compatibility is not being thrown away. Xwayland will be with us for a long time for backwards compatibility (that includes stuff that lots of users care about, e.g. most Steam games). X11 will continue to be around, reduced to a more manageable size as a compatibility layer, within Wayland.
Xwayland only provides backwards compatibility for a very small subset of the X11 ecosystem (E.g. window managers or xdotool are not supported). As such it is only useful for very limited X11 clients on the level of GNOME applications and in most cases completely useless.
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, xrandr, xrdb, xsel, xset)

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?

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.