261–270 of 335 posts
Earlier quoted context omitted.
I would venture to say that there is little overlap between X11 users and people with high-DPI screens.
There is no particular reason for this theory to be true. X supports high DPI screens well and has for ages.
Earlier quoted context omitted.
Good question. It makes sand-boxing security impossible. The moment a process has access to the Xorg socket, it has access to everything. It is weird that this oftentimes misses from the discussion though.
Can't this aspect be improved, vs. switching to something else?
Any extra effort on X11 might help to buy more time, but will in the end be for nothing. And in this time of supply-chain attacks, vs-code plugins, npm packages, agents and what-not, X11 is just too dangerous.
Earlier quoted context omitted.
Wayland has a philosophy of "every frame is perfect", which means fixing every race condition. However, X11 doesn't have this philosophy. If the window manager is slow and doesn't respond to a notification that a window has been resized, drawing the new window content over the old borders is the correct thing to do . What sense does it make to freeze the whole display just for a window border? Similarly, tearing gets…
Perfect frames is what Mac and Windows provide and what Linux should also aim for. Border tearing is a display bug, correctness should come first, Wayland's approach is right. X was designed for CPU and IO constraints that no longer apply. _Graceful_ degradation of slow UI should lower the frame rate, not compromise rendering of individual frames.
Citation needed. Windows has its own share of graphics bugs, even on "corporate" hardware (HP).
Earlier quoted context omitted.
X.org picked the right level of abstraction (even if implementation could use a rewrite). No WM should care about handling raw inputs or forced to be proxy between driver and the app for the output (it could be, if it needed/wanted, but there is no reason to add another layer of abstraction and cycle-wasting for most use cases). And it shows in complexity and even in power use. Wayland basically failed to learn the l…
That's easy to say in hindsight. It is only with the specific failures of Wayland that we see which lessons it could have learned from X11.
Earlier quoted context omitted.
No, the lesson of “separate display server from window manager” was very clear when Wayland was started. People have been discussing this over the years ever since. (See also “client-side decorations” for another part of this issue that was heavily discussed.)
I seem to remember reading in an old paper (1990s?) that the asynchronous nature of the connection between the X server and the window manager results in essentially unfixable protocol-level races.
https://donhopkins.medium.com/the-x-windows-disaster-128d398...
https://news.ycombinator.com/item?id=22491561
https://news.ycombinator.com/item?id=15035419
https://news.ycombinator.com/item?id=28522534
https://news.ycombinator.com/item?id=44045304
https://news.ycombinator.com/item?id=29964737
https://news.ycombinator.com/item?id=15327339
https://www.donhopkins.com/home/catalog/unix-haters/x-window...
https://blog.dshr.org/2024/07/x-window-system-at-40.html
David Rosenthal wrote:
>There is a certain justice in The UNIX-HATERS Handbook's description of my efforts:
Ice Cube: The Lethal Weapon
One of the fundamental design goals of X was to separate the window manager from the window server. “Mechanism, not policy” was the mantra. That is, the X server provided a mechanism for drawing on the screen and managing windows, but did not implement a particular policy for human-computer interaction. While this might have seemed like a good idea at the time (especially if you are in a research community, experimenting with different approaches for solving the human-computer interaction problem), it can create a veritable user interface Tower of Babel.
If you sit down at a friend’s Macintosh, with its single mouse button, you can use it with no problems. If you sit down at a friend’s Windows box, with two buttons, you can use it, again with no problems. But just try making sense of a friend’s X terminal: three buttons, each one programmed a different way to perform a different function on each different day of the week — and that’s before you consider combinations like control-left-button, shift-right-button, control-shift-meta-middle-button, and so on. Things are not much better from the programmer’s point of view.
As a result, one of the most amazing pieces of literature to come out of the X Consortium is the “Inter Client Communication Conventions Manual,” more fondly known as the “ICCCM”, “Ice Cubed,” or “I39L” (short for “I, 39 letters, L”). It describes protocols that X clients must use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late — by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past.
The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn’t work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It’s so difficult, that many of the benefits just aren’t worth the hassle of compliance. And when one program doesn’t comply, it screws up other programs. This is the reason cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application. If you want to write an interoperable ICCCM compliant application, you have to crossbar test it with every other application, and with all possible window managers, and then plead with the vendors to fix their problems in the next release.
In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry’s standard naked emperor.
Earlier quoted context omitted.
X.org picked the right level of abstraction (even if implementation could use a rewrite). No WM should care about handling raw inputs or forced to be proxy between driver and the app for the output (it could be, if it needed/wanted, but there is no reason to add another layer of abstraction and cycle-wasting for most use cases). And it shows in complexity and even in power use. Wayland basically failed to learn the l…
> Wayland basically failed to learn the lessons from X11 To me the biggest issue of Wayland is that it aimed, on purpose, to imitate Windows or OS X or any GUI that is not built on the idea of a client/server protocol. From TFA: > I’ll also need a solution for running Emacs remotely. If only there was something conceived from the start as a client/server display protocol...
Freedesktop.org really looks like a Microsoft subsidiary. Only if they could learn from the past.
A rather big problem is that Wayland is just a protocol, not an implementation. There are many competing implementations, like Gnome, KDE and wlroots. The problems you have with one of them might not appear in another. The reference compositor, Weston, is not really usable as a daily driver. So while with Xorg you have a solid base, and desktops are implemented on top of that, with Wayland the each desktop is reinven…
The real problem with post X compositors is that the Wayland developers assumed that the compositor developers will develop additional working groups (an input protocol, a window management protocol, etc) on top of the working group that exclusively focuses on display aka Wayland. Wayland was supposed to be one protocol out of many, with the idea being that if Wayland ever turns out to be a problem it is small in sco…
so, as Douglas Adams put it: someone elses problem.
Earlier quoted context omitted.
Perfect frames is what Mac and Windows provide and what Linux should also aim for. Border tearing is a display bug, correctness should come first, Wayland's approach is right. X was designed for CPU and IO constraints that no longer apply. _Graceful_ degradation of slow UI should lower the frame rate, not compromise rendering of individual frames.
> Perfect frames is what ... Windows provide Citation needed. Windows has its own share of graphics bugs, even on "corporate" hardware (HP).
Earlier quoted context omitted.
I use it as my daily driver. I used Sway for a very long time, tried Hyprland for a bit and am now running niri as my daily driver. Sway and niri are wlroots based, Hyprland at some point rolled its own because they didn't want to wait for wlroots protocol extensions. Sometimes I have to switch to Gnome to do screen sharing. 2026 and you will still run into plenty of issues with random behaviour, especially if you ru…
There also isn't nearly as much choice for wms. My favorite WM is cwm, but the closest alternative on Wayland is Hikari which is abandoned. I noticed it's far far more work to build a wm for Wayland than it is for Xorg.