{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidcybun5lb5fxgitzegcxnvt7pihcz23nstgqhh2q3cjrw4mskvqa",
    "uri": "at://did:plc:hqad6xwuzg7oqfmwylfkvqfm/app.bsky.feed.post/3mlczp6oenbr2"
  },
  "path": "/viewtopic.php?t=33412&p=273665#p273665",
  "publishedAt": "2026-05-08T04:15:21.000Z",
  "site": "http://forum.palemoon.org",
  "textContent": "> In any event, I myself don't see Wayland \"taking over,\" no matter how hard IBM/Red Hat or anyone else tries to push it...\n\nI mean, it could take over as the default on Linux. But there's a world of difference between Wayland as a default, and no X11 support.\n\nIn my view, in a world where Wayland \"wins,\" XWayland is still needed, but over time becomes viewed in the same light as DOSBox or Wine... a compatibility layer for old programs, not something native to a modern Linux system. Probably due to security concerns related to application windows being able to see another application's position and what else is running. I mean, like I was saying, applications could, in theory, ship XWayland as an included dependency on systems that don't provide it by default, it just runs a little X Server as a client on Wayland, and then shows you the application in a window. This is not far off from what X was designed to do in the first place, and why with the right setup you can see remote X11 applications on, say, Windows and they look like they're running in their own window natively. It was basically designed so that you could use the X server with a system that doesn't run X natively and it looks seamless. Wayland just means X now has to work with Linux the same way it does Windows, classic Mac, or anything else that isn't using an X server as the native display. Plus, using XWayland means each application potentially gets its own X server and can't see other applications anyway, which still solves what Wayland advocates are complaining about mostly without breaking legacy support.\n\nSo, X11 may not be the future, but it's pretty hard to kill, if only because anything that needs it can just embed an X server cheaply, run the application on the X server, and then use some kind of native program to connect to the X server and show you the application running. Now you have an X11 application running while something else controls the display. It's that flexible and embeddable. Seriously. That's how people get Linux desktop applications running on Android when they're not supposed to... just get an X server running, use a remote X server viewer pointed at localhost, and suddenly you can see a normal desktop on your phone.\n\nX wasn’t designed around assumptions about the underlying window system or hardware. That neutrality made it easy to run on systems where it wasn’t the native display stack. Probably lots of Unix vendors in the 1980s had their own proprietary display solutions and X was a protocol that was more \"neutral\" and could allow applications to work on anything without assumptions about who has control of the display or how the underlying hardware/OS works. That ironically makes it perfect for an environment where Linux is on Wayland, Windows is Win32, Mac is Quartz/Cocoa, and stuff like Solaris or BSD is still dependent on X11. All of them can speak X and run an X server. Windows has XMing, Mac has XQuartz, Linux has XWayland. Mir even had XMir. So basically, the problem with trying to kill X11... is that anything you try to replace it with, can always create something that talks to an X server and shows you what it's doing, on the new thing you replaced X with. And the more different things you create, the more X11 backends for different things you create, until X11 is the only thing those different things have in common, and it turns back into the centralized glue that holds everything together all over again. It's like a weird self-reinforcing cycle that works in favor of anything that targets X11.\n\n* * *",
  "title": "Browser Development • Re: Linux Pale Moon with Qt toolkit",
  "updatedAt": "2026-05-08T04:15:21.000Z"
}