Elon Musk tweeted on his official account on Sunday that Twitter would be changing its logo to an “X” and that all the birds will be disappearing from the platform.
No, I’m thinking of Xorg. The development on it has slowed to less than a crawl, and not because it’s feature-complete. It’s unmaintainable, and hell to manage for anyone that’s not a senior Xorg developer.
What features is it missing? They started decoupling GPU drivers from the X server a long time ago (about a decade), that’s why Linux has DRM, and what enabled making Wayland. At this point the only feature needed of Xorg, is a compatibility layer between X clients and Wayland.
The ability to stop applications from keylogging you, secure and efficient screenshare, decent compositing, not to mention all of the cruft it’s obtained over the years that stops it from obtaining all of these. And, as a whole, Xorg is completely incompatible with multi-monitor setups - no fractional scaling, and no multi-monitor scales, as well as refresh rates as you mentioned.
All we should be using nowadays at most is Xwayland. You only get a pass for bare X if:
Yes, I am well aware of that. When someone refers to X, or Xorg, or X11, they’re usually referring to bare metal X - you know, the insanely broken thing that people still want to use for some inane reason.
So what’s your point? Why does this conversation continue to go on? It’s clear that Xorg is unmaintained and will not be fixed, and Xwayland is the only thing that matters. Why argue it?
When someone refers to X, or Xorg, or X11, they’re usually referring to bare metal X
Well… I don’t; I refer to X as the X protocol… which is also outdated, hacked out of its mind, and still has some bizarre legacy cruft that nobody in their sane mind even uses anymore… but isn’t the same dumpster fire as “bare metal X”. Hope we can agree on that? 🙂
The protocol is also framerate agnostic, other than having a V-sync option.
If you have a multi-monitor setup, with different characteristics for each monitor… well, the original X11 design was to have a separate terminal (computer) per monitor, with each terminal doing its own stuff to display an application’s image… so that’s why nowadayws we have Wayland as a middleware between drivers and X applications.
If the drivers and/or Wayland aren’t supporting some of Xorg’s features, that still leaves Xorg feature complete.
Xorg doesn’t support any of that. Multimonitor is nonexistent if you want to use it on a desktop, Xwayland still suffers from the lack of multimonitor (fractional+integer) scaling, and it tears horribly if you don’t want to use inefficient and annoying vsync (Wayland’s is fine).
Xorg is feature complete for its time; not for this time. The opposite goes for Wayland. Technically it’s a “feature” that any application can keylog on Xorg, that doesn’t mean that they should be free to do so without limit on Wayland too. If that means Wayland isn’t feature complete and Xorg is, then so be it.
I used to run a multi-monitor desktop setup with Xorg, via the nVidia drivers. Two identical monitors, single framebuffer, no scaling, no tearing, single vsync.
That was quite a while ago, and it worked great. Then I discovered I could run an nVidia and an AMD card, both at the same time, on Windows 7, so made the switch… but still.
I used to run a multi-monitor desktop setup with Xorg, via the nVidia drivers. Two identical monitors, single framebuffer, no scaling, no tearing, single vsync.
One monitor, one framebuffer, an old use case that for some doesn’t even exist now, inefficient and slow tearing prevention, laggy vsync.
That wasn’t a multi-monitor desktop setup. That was a hacked together multi-display, single-screen setup.
Also why would you link an LD_PRELOAD attack? That’s not Wayland-specific in any way. Any other protocol and library is vulnerable to that too. But let’s point out one major issue with that: the LD_PRELOAD needs to be loaded in before the compositor in order to be relevant. With X, you can do that at runtime. Let’s also read the README from the repository:
This program is in no way meant as criticism of the Wayland project. It simply demonstrates that creating a secure desktop requires more than just a few server-side restrictions.
Wayland isn’t the only software we need for a secure desktop; it just handles making the display secure. For libraries and application sandboxing, you want Flatpak, and we’re making progress on dynamic permissions there.
So? What’s your point? Nothing here is a Wayland-specific argument. Your setup wasn’t functional, it was fundamentally a hack, and one that not-NVIDIA/Intel/AMD hardware doesn’t support. Your argument is falling flat on its face.
Nobody is actively working on it now; the same can’t be said for Wayland. Recently, it even hit a development low of all time. The only ones working on it are the ones getting paid to work on it, and even then, only those familiar with the codebase. Looking at the history, the only major changes are for Xwayland, and aren’t at all often.
If (almost) all of the developers have abandoned something in favor of a newer piece of software that does the job better, I think it’s sufficient to say that it’s deprecated and unmaintained.
Ironic how he chose an X in a strikingly similar style to the (old, unmaintained, and deprecated) Xorg. That was certainly a choice of all time.
X.org - stable release 29 March 2023
You may be thinking of XFree86 (est. 1991) or X11 (est. 1984).
No, I’m thinking of Xorg. The development on it has slowed to less than a crawl, and not because it’s feature-complete. It’s unmaintainable, and hell to manage for anyone that’s not a senior Xorg developer.
What features is it missing? They started decoupling GPU drivers from the X server a long time ago (about a decade), that’s why Linux has DRM, and what enabled making Wayland. At this point the only feature needed of Xorg, is a compatibility layer between X clients and Wayland.
Multi high and differing refresh rate HDR monitor setups require Windows or OSX to use to their full potential.
The ability to stop applications from keylogging you, secure and efficient screenshare, decent compositing, not to mention all of the cruft it’s obtained over the years that stops it from obtaining all of these. And, as a whole, Xorg is completely incompatible with multi-monitor setups - no fractional scaling, and no multi-monitor scales, as well as refresh rates as you mentioned.
All we should be using nowadays at most is Xwayland. You only get a pass for bare X if:
Otherwise, get the fuck off of Xorg. The ecosystem has matured enough such that Wayland Just Works for basically everyone.
Xwayland support has been merged into Xorg since 2014 🤷
Yes, I am well aware of that. When someone refers to X, or Xorg, or X11, they’re usually referring to bare metal X - you know, the insanely broken thing that people still want to use for some inane reason.
So what’s your point? Why does this conversation continue to go on? It’s clear that Xorg is unmaintained and will not be fixed, and Xwayland is the only thing that matters. Why argue it?
Well… I don’t; I refer to X as the X protocol… which is also outdated, hacked out of its mind, and still has some bizarre legacy cruft that nobody in their sane mind even uses anymore… but isn’t the same dumpster fire as “bare metal X”. Hope we can agree on that? 🙂
X/X11/Xorg supports 48-bit color by default: https://linux.die.net/man/3/xcolor
The protocol is also framerate agnostic, other than having a V-sync option.
If you have a multi-monitor setup, with different characteristics for each monitor… well, the original X11 design was to have a separate terminal (computer) per monitor, with each terminal doing its own stuff to display an application’s image… so that’s why nowadayws we have Wayland as a middleware between drivers and X applications.
If the drivers and/or Wayland aren’t supporting some of Xorg’s features, that still leaves Xorg feature complete.
No.
Xorg doesn’t support any of that. Multimonitor is nonexistent if you want to use it on a desktop, Xwayland still suffers from the lack of multimonitor (fractional+integer) scaling, and it tears horribly if you don’t want to use inefficient and annoying vsync (Wayland’s is fine).
Xorg is feature complete for its time; not for this time. The opposite goes for Wayland. Technically it’s a “feature” that any application can keylog on Xorg, that doesn’t mean that they should be free to do so without limit on Wayland too. If that means Wayland isn’t feature complete and Xorg is, then so be it.
I used to run a multi-monitor desktop setup with Xorg, via the nVidia drivers. Two identical monitors, single framebuffer, no scaling, no tearing, single vsync.
That was quite a while ago, and it worked great. Then I discovered I could run an nVidia and an AMD card, both at the same time, on Windows 7, so made the switch… but still.
Isn’t that still a “feature” of all PC desktops? https://github.com/Aishou/wayland-keylogger
Some good ideas here, but Windows/Linux are still lagging behind: https://news.ycombinator.com/item?id=25971395
One monitor, one framebuffer, an old use case that for some doesn’t even exist now, inefficient and slow tearing prevention, laggy vsync.
That wasn’t a multi-monitor desktop setup. That was a hacked together multi-display, single-screen setup.
Also why would you link an LD_PRELOAD attack? That’s not Wayland-specific in any way. Any other protocol and library is vulnerable to that too. But let’s point out one major issue with that: the LD_PRELOAD needs to be loaded in before the compositor in order to be relevant. With X, you can do that at runtime. Let’s also read the README from the repository:
Wayland isn’t the only software we need for a secure desktop; it just handles making the display secure. For libraries and application sandboxing, you want Flatpak, and we’re making progress on dynamic permissions there.
So? What’s your point? Nothing here is a Wayland-specific argument. Your setup wasn’t functional, it was fundamentally a hack, and one that not-NVIDIA/Intel/AMD hardware doesn’t support. Your argument is falling flat on its face.
I feel like I have to point out that Xorg is neither unmaintained nor deprecated. It is old as tits though.
Nobody is actively working on it now; the same can’t be said for Wayland. Recently, it even hit a development low of all time. The only ones working on it are the ones getting paid to work on it, and even then, only those familiar with the codebase. Looking at the history, the only major changes are for Xwayland, and aren’t at all often.
If (almost) all of the developers have abandoned something in favor of a newer piece of software that does the job better, I think it’s sufficient to say that it’s deprecated and unmaintained.