Pretty interesting approach to make an X server that is essentially "Wayland-like" (merging display server/compositor by default, isolated apps by default, no remoting of GLX, dropping legacy protocol features to the point of breaking compat with the core protocol, etc.). Not sure who this is for, but by itself it looks like a fairly reasonable set of choices.
It depends on whether their reasons for "absolutely having to have X11" hinge on actual compatibility with e.g. old binaries or wanting full remoting without streaming pixels.
This project would satisfy people who really actually want Wayland, but were upset by transitional pains or interactions they had around it and want to stick with X11 just-cause while getting some similar benefits. This arguably does describe some people but not sure it's a whole lot in the long run.
But who knows, maybe this could also make an easier to maintain XWayland some day, or a nice basis for implementing more esoteric X11 bits down the road vs. the older Xorg codebase.
From my perspective X just got to the point where it just works for me few years ago and Wayland is just introducing more issues than it solves (to be clear it solves no current issue for me, only one that I think might be better for me is handling different refresh rate displays and maybe fractional scaling... and that could probably be done within X11)
Like, why simple "copy the screen" got suddenly so complicated? Why every WM suddenly needs a bunch of features that before were just handled by display server, where they belong ? Why some(most) WMs handle title bars but GNOME doesn't ? Why someone decided title bar management is optional to window manager ?
X11 might need to go but Wayland have learned no lessons from it. It's just knee-jerk "if X11 done it this way, let's do it differently"
Whatever the issues with X11, it was properly designed. Wayland is the kind of software that adds features with nobody looking at the consequences. Who knows what they will break next version.
From all the criticisms leveled at Wayland, this is definitely the strangest I've ever heard.
I really cannot thing of any existing functionality ever broken by a new release of wayland-protocols, neither by a plain bug nor by a bad interaction. No doubt someone else will be able to recall an example, but it's really not a common thing.
This is partially because the governance model and community mindset is the opposite of what you describe. Inclusion of new protocols in the stable release requires existing, proven implementations and consensus across multiple implementors, making it a high bar. New proposals run a gauntlet where pretty much everyone is looking at the consequences in detail.
In fact a more common criticism of Wayland is that the focus on high quality and the consensus requirement are too strict and have slowed down filling in feature gaps users need filled faster. This argument I think can be successfully defended against - mainly, that it helps avoid the mess X11 became over time -, but at least has some basic merit in reality and is an avatar for genuine user pain.
As for X11, as someone who had to implement a lot of X11 specs over the years, I can tell you that their provenance between X11 itself as well as ICCCM and EMWH had plenty of super dumb ideas and cruft and inconsistencies from lack of foresight and eventually datedness. You don't want to see the towering stack of hacks and heuristics we used to have to ship to make X11 behave somewhat consistently and sane :)
In short, with all due respect, but I think you really don't know what you're talking about. We really should resist this type of narrative reality distortion field on an engineering forum.
That high bar is GNOME having an uppity whenever a Wayland protocol is suggested they don't like, that even if is accepted, if Mutter doesn't implement it then its dead in the water given its the de facto default compositor on unfortunately what people consider "Linux", aka Ubuntu.
e.g. DRM leases that only got changed because Valve has the bigger underwear. Expecting games to implement DBUS (incl. when running under Wine) to access VR headsets just for GNOME is nuts.
The government model needs a change that stakeholders who ship devices to the end users that rely on them have more of a say, whether that's Google, Valve etc. Valve is now backing and pushing KDE into average joe end users is a telling.
Wayland design choices are heavily influenced by automotive and TV where it has been industry standard way before it became mostly usable as a desktop. And that has lead to design compromises that look odd on desktop.
But hey, you can probably run automotive UIs with your desktop compositor.
And Gnome devs are just being silly at this point.
> Why someone decided title bar management is optional to window manager?
Are you implying title bars should be mandatory in all WMs? I'm using DWM on X and I love that I have no title bars. If a program tries to force one on me I disable it or use something else if that's not possible.
It should be mandatory wherein the title bar is expected/desired by the user and not inherently the responsibility of each individual app by default. The wm should have the capability of drawing a titlebar for each app and do so by default unless the app opts to draw its own OR the user configures the system to not do so.
Yes, and that's how it's handled by the desktop environments I've used. Many programs have the option to use the system, program or no title bar. But should it be mandatory for every DE/WM or can the user choose one that satisfies whatever preferences the user has?
This way people like me still have the option to use window managers that don't have title bars. Title bars are useless for power users that know what program they're in and don't need them. To me they're in the way.
I don't "actually want Wayland" because I want the simplicity of X and the ability to run my own wm, but I have no need for legacy X11 requests, for some values of "legacy". Whether this will become viable for me remains to be seen, but I need very little from my X11 server.
I remember Wayland scared me off of Linux when I tried to switch to Ubuntu a few years ago. I couldn’t watch a movie without jiggling my mouse every few minutes. At the time I feel like it was like “yeah that feature doesn’t exist yet” or something. So I switched back to Windows. It looks like there’s workarounds now but I’ve mostly switch to my fantastic M1 MacBook Air at this point.
Not for the client, or if you want to write a wm and is forced to write a compositor.
And actually I'm not even even convinced about the server if talking about a minimal server like this that insists on DRI/GBM, and ditches all the old rendering cruft.
Well, you are not really forced to write a compositor these days as there are libraries that do all the heavy lifting for you.
Check out Louvre for example. Or Smithay if you like Rust. And if you want a bit more depth, there is wlroots of course (or the hyprland version). It is not really any harder than writing an X11 WM.
Yeah, no I have my own wm in Ruby that is fewer lines of code than a typical Wayland Hello World, and that does what I want. I have no reason to want to throw that away for something that doesn't offer me any features I care about, and removes features I do. Such as the ability to just restart my wm if I make a change to it without affecting my current session at all.
Unless you can show me a solution that lets me replace my tiling and floating wm in ca 1500 lines of Ruby, what you're offering me is inferior to what I have with X
wlroots and smithay (I'm not familiar with louvre) do a lot of the difficult work for you, that most compositors will do without much variation but there's still a lot that compositor writers still have to do. It's still a significantly larger task than, for example, writing an X11 WM.
(Well, writing an X11 WM that also includes a built-in compositor is a bit more than just the WM, but I'd say still less than writing a Wayland compositor using wlroots or smithay. For example, xfwm4's compositor is around 5300 lines of C, which is... not nothing, but not crazy either.)
I said build on top of wlroots, not DWL. And I only brought it up as an example of a small Wayland compositor/window manager because the poster I was replying to wants to build their own anyway. DWL is more interesting as a learning exercise than something to use.
Xorg is still being under development, there is another fork in development too (XLibre) and you're in the comment thread for a project about a brand new X server written from scratch.
Usually things which are "no longer developed" do not have (at least) three implementations in development.
(i worked a _little bit_ on dwl) each wlroots upgrade is a pretty small diff on the dwl source. the annoying part is, as dwl is configured with patches, every patch author has to update their patch to the new 0.x, as dwl is quite minimal, and thus has no stable api. that being said, obviously, dwm doesn't have this problem :)
also, for dwl, the issue is that the initial author (not the guy that wrote that notice) is sorta mia, and he has control of the repo on codeberg, so we'd probably need to fork to be safe, and he may not want to take on project lead. (he checks every patch for merge conflicts with one another and upgrade breakages, god bless him lol)
Nearly every Wayland compositor is built on wlroots. Somehow they manage. But yeah, of course it's going to change more than X11, which is older than I am and more or less abandoned...
It's actively maintained by projects like RHEL which still have versions which are supported which in turn support X11.
Others are looking to run X11 wm under wayland with wayback, xlibre wants to keep it moving forward, and phoenix wants to replace it with a modern version.
And DWL is not super small. It's hundreds of times larger than a minimal X wm, and couple of times as big as the wm I used.
And it's C. And it'd mean I would lose my session if I want to make changes and restart it.
What you're suggesting would be to put significant effort into replacing something that works with something that in terms of features I care about is strictly inferior.
Afaik Xorg is 'only' like ~500k lines of code, which is not huge by the standards of large porjects. In fact, one of the major counter arguments against Wayland, is that the compositor + a few core libs, like wlroots necessary to provide a similar set of functionalities, is already larger that the equivalent X11 code (which has a ton of unused cruft).
What's the simple way for a bash script to get the title of the currently focused window? In X this is easy and the bash script will work with every DE. In Wayland you have to write a different solution for each compositor/DE.. Prove me wrong, please.
It shouldn't be hard, all I want to do is fuzzy match window titles to named audio streams in pipewire, but "Oohh noo that's a security flaw!" say the patronizing Wayland developers who care more about making their own lives as developers simple than supporting basic desktop functionality.
I know how to get the audio stream names, the problem is the window titles. With X it's easy, just call xdotool. I'm sure it's probably easy enough on Windows and MacOS too. Wayland is the weird one for making focused window titles privileged information.
Anyway, I do think I've created what should be considered basic desktop functionality here, a simple hotkey that mutes or otherwise changes the volume only of the focused window. Every desktop should have it.
This is just one of the tools I've made for myself with X which I do not want to do without and this makes Wayland a non-option for me. If I can't use X and can't replicate things like this with Wayland, then maybe I should switch to MacOS at that point because the dream of controlling my own computer seems like it's dying anyway.
Wayland is approximately correct in this case and Windows and Mac are behind the security curve for bincompat reasons; window titles certainly leak PII. There should be a way to do it, but it is sensitive information.
Sure, but again there's no interest in actually making a standard way to do it. I can understand it being something that arbitrary applications probably shouldn't be able to access, but that somehow turns into no way to do it, or complete fragmentation where every DE does it with arbitrary differences (or, more realistically, some DEs support it and others don't).
Okay; is there a way to do it? Can I, the user, decide that I do actually want a program to see titles? Or is it still impossible because 17 years isn't enough to implement utterly trivial APIs that people want?
Never in history. If you have software running on your system attacking you then you have so many more issues than the adversary knowing your window titles.
> In X this is easy and the bash script will work with every DE. In Wayland you have to write a different solution for each compositor/DE.. Prove me wrong, please.
I don't know what you expect people to prove other than that X and Wayland both have the same problem but since X is so complicated there is only one implementation to begin with, which makes it look like X has solved the problem even though it suffers from exactly the same problem.
There are in fact multiple implementations of X and xdotool works with all of them. Typical Wayland advocate, doesn't know what the fuck he's talking about while telling people to just ignore the problems they have with Wayland, probaby because you don't even understand the problem in the first place. Why did you even respond to me? To insult me? To waste my time?
Look into river. It has the window management and keybindings able to be offered by other tools (I have an idea to implement one using XMonad's layouts).
It also vastly improved battery on my Dell Pro laptop. 58% battery used in 7h45m (light compilation day, but no suspend).
That sounds cool, but TBQH the last thing I want to do is make myself dependent on some obscure piece of tech I've only heard of once before (just now.) My plan is to keep running X as long as I can manage to make it run. If river finds traction and is well known to me in 10 years then I'll consider it then.
This is one of my big problems with Wayland; the fragmentation of Wayland imposes an unacceptable cost to picking the wrong DE, whereas with X all my tools for X still work regardless of my DE.
Wayland made writing WMs needlessly hard, and the benefits of Wayland were frankly not real - most of the reasons given in 2011 were patched in to X11 later. All the Wayland rewrite got us was a situation where Wayland is both bleeding-edge and obsolete simultaneously. Say what you like about X11, but by the time people unironically pushed for mass Wayland adoption, X11 was stable and boringly so.
The future of WMs is, IMO, Arcan - https://arcan-fe.com/ - but that's an ambitious project and I don't blame the main developer for deliberately going out of his way to avoid advertising it before it's ready. In the meanwhile, Wayland and X11 both more-or-less work with the occasional major pain in the ass.
I think the problem is that people wanting to build that and being in position to (being paid for by their employer), are fed up with X11.
It learned no lessons from X11. It made most things harder to write and pushed more things that really every WM needs and doesn't care much to implement differently to WMs making them harder.
For example, stuff like "WM need to manage raw inputs, so they can have more power over them" is cute on paper but in reality most of them don't want to because there is no benefit to reinventing that part. Sure, that part in X11 could be better, maybe it should have better interface for WMs to configure common options in common way without getting into input-driver-specific options, but that just required rework of the idea, not throwing it into the bin and replacing with near entirely worse framework that wastes everyone time.
Tech is full of examples of 'successor' technologies, that were aiming to provide a clean rewrite without legacy, which then got bogged down with supporting a bunch of corner cases and accumulated their own share of cruft and could be no longer be considered a cleaner alternative. All the while the majority of the userbase being stuck on the old platform because the new one is buggy and doesn't offer anything tangibly better.
Vulkan, various node replacements come to mind.
Wayland at this point has existed almost as long as X11, longer if you only count the Linux years, yet its still not quite there.
Wayland and its various implementations like KDE plasma are 90% ready. Now they just need the other 90% to move from alpha to product. I expect it'll take another decade or two.
A lot of X features are actually Xorg features and they only work because there is a single implementation that everyone tried to integrate with.
Turns out the moment there are two implementations, which is hard on X and easy on Wayland, you can no longer rely on targeting a single implementation for direct integration anymore.
This means a lot of non-X but Xorg features need a protocol extension in Wayland, because things are being standardized that previously were exclusive to Xorg.
Are you saying that you can't get the title of the active window in X11 without using some features specific to the X.Org implementation?
It looks like the core X11 protocol spec [1] defines all that's needed, specifically the GetInputFocus, QueryTree and GetProperty messages. You might also want some things from the EWMH spec [2] (e.g. _NET_WM_NAME for UTF-8 or _NET_WM_WINDOW_TYPE to identify top-level application windows) but none of this seems like an implementation-specific X.Org feature.
> I think the problem is that people wanting to build that and being in position to (being paid for by their employer), are fed up with X11.
I think one of the intrinsic problems with relying on developers being paid by their employers is they can easily become personally disinvested from the thing they're maintaining; they get paid well, the day-to-day grind gets stale, they get interests and hobbies other than computing but keep working on the thing because it's their job. Eventually they find that just buying a Mac is an easier lifestyle at home, and gradually maintaining X transforms from something they do out of passion for the project into something which is just a job. So they look for ways to make their job easier, hit on the classic "instead of maintaining old thing it'll be more fun to make our own", and because they are now untethered from the needs of real users they only need to make sure the new thing supports the bare minimum to keep their employer happy. They no longer care how real users feel, any use case that isn't required in the checklists approved by management get deliberately abandoned. So we end up with Wayland lacking common sense desktop features in demand by users for years because it's simply not convienent for the developers who are now dispassionate 9-5ers.
I prefer to take my chances with enthusiasts keeping X working on shoestring budgets. Maybe a few more years of development of coding models will make ongoing maintenance easier going forward and I'll never have to switch. I'm willing to make that bet. If it turns out that in 5 years I am forced to switch, at least by then Wayland will be five years more mature, and maybe my cynicism will even be proven wrong by then and Wayland will be good by then (but I'm not holding my breath for that.) Anyway, I have nothing to lose by using X as long as humanly possible.
Replace "X" with anything and this is why i generally try to avoid relying on open source projects where the majority of the development is driven by some company if there is an alternative, even if they're jankier (and often they are).
One example would be Free Pascal and Lazarus, while there is some commercial support, the overwhelming majority of the development is community-driven and ironically both have a much better history of preserving backwards compatibility than most open source projects backed by larger companies.
Of course exceptions exist for both situations, but as a general rule i find if some project makes a big deal about the company behind them (or even worse, there is a company with the same name as the project) then i tend to look for more community-driven alternatives.
Yes, but I think in the case of Wayland also management had other priorities, i.e. GUI for mobile and/or entertainment systems.
But this is all ok, I think the main problem is that somehow too many in Linux community did not see that the technical arguments for Wayland were not actually too convincing and that giving up decades of compatibility across UNIX systems and beyond is a mistake.
It's a tradeoff, to be honest – I think of Valve's involvement with Wine, where a consistent source of $$$ and developer-hours was (and still is) needed to whack away at the open-ended problem of compatibility.
> "most of the reasons given in 2011 were patched in to X11 later"
This definitely doesn't match my memory, and I was there :) Most of the good reasons remain unavailable in X11 to this day.
There definitely were some attempts to advance X11 that post-date Wayland, most notably the proposals by Keith Packard, but they never got much traction.
Per-display DPI settings. No snooping on input without permission. Awareness of the lock screen (the compositor can know that the lock screen is active and provide alternate keybindings instead of having to configure the lock application as well). Locking is not blocked by context menus being open.
I ran XMonad for 15 years, but recently switched to river and am loving it.
fwiw, Xorg already had this, since you can set the DPI for each display through RandR/xrandr. In both X11 and Wayland it's up to the toolkit to actually detect the setting and rasterise accordingly.
Wayland actually went backwards in this respect by using "integer scales" (eg, 1, 2, 3) instead of fine-grained DPIs (eg, 96, 192, 288), so using a scale of 1.5 would result in downscale blur (toolkit sees scale as 2, then the compositor scales it down to 75%), whereas in Xorg you could just set the DPI to 144, and the toolkit could theoretically render at the correct resolution. As far as I know Qt was the only toolkit to actually do this automatically, but that's not X11's fault.
Wayland has at least since fixed this in the form of "fractional scaling" [1], but here's [0] an old thread on HN where I complained about it and provided screenshots of the resulting blur.
[1] Doing some quick searching it seems like this is still unsupported in Gtk3/Gtk4, maybe planned for Gtk5? Apparently Firefox has only just added support (December 2025), 3 years after the fractional scaling protocol was released. Seems ridiculous to me that Wayland failed to get this right from the start.
These days Xinerama is the only mainstream tool for dual head, but there used to be others. Nvidia Twinview was one. I bought my first dual head box in 1996 with two Matrox Millennium cards (although it mainly ran NT4) and those cards later went into my dual Athlon XP machine. That ran SUSE until Ubuntu came out.
Xinerama isn't a sine qua non. It's just easy so it became ubiquitous. Maybe it's time to replace it.
It's the same on Wayland. The client (usually part of a toolkit like Gtk/Qt) needs to subscribe to notifications [0] from the server so it can decide the raster size of the surface it wants to draw to. Qt does this on X11 by detecting when your window moves to a screen with another DPI and resizing/rescaling.
I guess the "third" program would be something like xrandr, so the Wayland analogue to that would be wlr-randr (for wlroots compositors), or some other DE-specific tool for configuring screen sizes. Again there's no fundamental difference here.
You can do per-display DPI just fine on X11 (through xrandr), it's just the major toolkits don't support it. GTK, for example, reads a single global DPI value from XSETTINGS; there's no reason why it has to be that way.
The annoying thing about the other things you mention is that they honestly are not that difficult to fix.
The X server can throw an error (or just silently ignore it) when one client passes the window of another client and button/key events in the mask to XSelectInput(). And the Xinput2 bits that allow for receiving all key and button events can be changed to only send events destined for windows in the same client. There: input snooping is fixed.
Lock screen awareness can be fixed with new requests/events in the MIT-SCREEN-SCREENSAVER extension (or, if that's fraught, a new extension) that allow an app to create a "special" lock-screen window, which the X server will always stack on top, and send all events to. (That new functionality should probably allow for child windows and popups for input methods as well.) This is honestly not hard!
And yes, some applications will break when you do this. But I cannot see how that's not significantly better than creating an entirely new display protocol that everyone has to port to.
There are other issues with X11, of course, mainly in the graphics pipeline (e.g. the compositor should really be in the X server), but it's hard to believe these things couldn't be fixed. It feels like no one really wanted to do that: building something new from scratch that (in theory) didn't have all of the mistakes of X11 would be more fun, and more rewarding. And I get that, I really do. But Wayland has created so much work, so many thousands (tens of thousands? hundreds of thousands? million+?) of developer-hours of work for people that maybe could have been better spent.
So I think Phoenix is a great idea. It's basically "X12"[0]: removing the old cruft and making breaking changes to fix otherwise-unfixable problems. I imagine most modern, toolkit-using X11 applications would work just fine with it, without modification. Some -- perhaps many -- won't... but that's ok. Run a nested, rootless X11 server inside "X12" if they can't be fixed, or until they're fixed.
[0] Yes, I know that an X12-type thing was considered and rejected (https://www.x.org/wiki/Development/X12/), but I still think it's a better idea, after a decade and a half of Wayland still not being able to support everything we need to port Xfce's components and maintain all of their features.
>You can do per-display DPI just fine on X11 (through xrandr), it's just the major toolkits don't support it. GTK, for example, reads a single global DPI value from XSETTINGS; there's no reason why it has to be that way.
I remember people complaining about the GTK file picker not having a preview for more than a decade, and at some point it sort of became a meme.
When it finally got added, the PR was like a 2-300 lines.
And was added after they rewrote everything for the new GTK version when there're functional patches adding thumbnails to previous versions. (Which were rejected/ignored because they didn't feel good.) A situational very in parallel to Xorg/Wayland if consider: https://news.ycombinator.com/item?id=46382940.
> It feels like no one really wanted to do that: building something new from scratch that (in theory) didn't have all of the mistakes of X11 would be more fun, and more rewarding.
My understanding from the outside is that this didn't happen, that Wayland is a spec without a reference implementation - that they didn't actually build anything and are leaving the difficult part up to everyone else.
They do have a reference implementation: weston and libweston but as far as I know, third parties don't use. They implement all their own functionality. Weston is confined more as a prototype.
If the issues are trivially resolved, why did the authors of X decided to abandon X? If the issues could be resolved, why were they not resolved?
I am using wayland for more than 5 years now, it just works. X did not. Xscreensaver/lock screens on Qubes are still broken.
What features is Wayland the protocol missing to allow supporting Xfce?
Even when you are national-state-level target, there are easier ways to grab the screen.
For local state, it's easier to just install a wireless camera and watch your screen from behind: it leaves no trace on your computer (you may spot it wireless connection, if you lucky). Moreover, they are more interested in your communication devices (your smartphone) than in your desktop.
Foreign states may exploit your notebook builtin "anti-theft" system, Intel Management Engine ("intel" is very good name for a CPU ;-), bugs in NVidia firmware (fonts, OpenGL, etc), bugs in hardware (create a second display to mirror image from primary display to, even when physical display is not attached, for example), etc.
However, I saw that my Firefox window was spied by Chromium window few years ago (I recorded it on Youtube), so this problem in X11 is real.
I am not sure what you saw, but on regular Linux processes of the user can spy on each other anyway. In any case, X had the concept of untrusted clients basically forever but nobody cared to invest even the small amount of work necessary to make it work well because nobody thought it would make a different. That this was later used as a major argument against X convinced me that this is not at all about technology.
Yeah, but with how we’re moving towards running each (desktop) application in its own cgroup, thus restricting what syscalls any given application can do, soon any old user process will no longer be able to read any other process’s memory. I don’t believe that the argument about how we need not patch a hole because another one exists right besides it is sound.
I agree. My point was only that this hole can easily be patched in X as well. So the argument was essentially "we do not bother to patch it with X, so we must rewrite X".
I care about being able to use the same password between the display manager, tty and lock screen auth. Yet, I cannot.
I think the original maintainers and developers of Xorg would be the best people to choose if it is worthwhile to continue working around X or do something else. Yes, X provided functionality that now WMs get to implement themselves - since the developers of Xorg worked closer to Gnome and Qt people, and Gnome and Qt people were OK with this, this didn’t feel like a horrible trade off. And given the diversity of Wayland window managers today, I don’t think it mattered all too much.
What? My screensaver password is the same as my login.
> I think the original maintainers and developers of Xorg would be the best people to choose if it is worthwhile to continue working around X or do something else.
"I think the owners of the Internet infrastructure would be the best people to choose what websites I'm allowed to visit"
No, the users have spoken and continue to speak up that Wayland doesn't serve their use cases.
> What? My screensaver password is the same as my login.
It is the same, yet some uppercase characters are not supported when entered via a yubikey. This has been marked as a WONTFIX. This is rather sad, because I can enter the same password in a TTY with no issues.
Kristian Høgsberg, for example, was a Red Hat employee. Then he worked at Intel, where it appears he continued work on Wayland? So Red Hat and Intel at least? People are being paid full-time to work on Wayland, so those companies.
By now I am not sure if these posts can stil be given the benefit of the doubt or are just dishonest. Who were the developers pushing wayland because of their employers? Kristian Høgsberg (who was a significant xorg developer, because people always deny that wayland was written by xorg guys) originally developed wayland in his free time, it then became a freedesktop project (I would argue not a group run by corporates).
The most active implementation (particularly in the early days) is probably wlroots, started by Drew deVault (again in his free time), who is often quite vocal against corporate control.
In fact the large desktop environments, which are much more under "corporate control", were comparitavely slow to adapt wayland IIRC.
So instead of repeating this accusation, maybe actually give some evidence?
I didn't think my explanation implied how you interpreted it.
I thought everybody knew Wayland was started by some people working on Xorg already; I did not mean to imply otherwise. Many or all were paid for their work. They believed Wayland was a better approach, and, AFAIK, at some point switched to be paid full-time to work on Wayland instead of X. Which, sounds a lot like they convinced their employer (or a new employer) to pay them to work on Wayland instead of X. Do you believe this is a fair summary of the situation?
> I didn't think my explanation implied how you interpreted it.
>
> I thought everybody knew Wayland was started by some people working on Xorg already; I did not mean to imply otherwise. Many or all were paid for their work. They believed Wayland was a better approach, and, AFAIK, at some point switched to be paid full-time to work on Wayland instead of X. Which, sounds a lot like they convinced their employer (or a new employer) to pay them to work on Wayland instead of X. Do you believe this is a fair summary of the situation?
Sorry for my combatitive before. I definitely interpreted your previous post differently and I think your clarification is a fairer assessment of the situation. I would still argue that the majority of people implementing the wayland protocol are not paid by their employers to do so (this might now have changed a bit with smithay, which is sponsored by system76 I believe).
The 3 justifications I remember for Wayland were security (isolating windows from each other), multi DPI, and eliminating tearing. All are now features of XLibre.
This is all playing a bit fast and loose with the details.
The "isolating windows from each other" stuff in Xlibre for example is the Xnamespace extension, which requires a static config file up front and lets X clients within the namespace interact as before. This may have some utility for specific scenarios (dunno, kiosks maybe?), but is nothing like Wayland's default security model.
Similarly, enabling TearTree in the modesetting driver and having another backbuffer in the driver is a huge crutch vs. having a proper architecture where the compositor can own presentation timing. For one it makes adaptive sync/VRR a lot trickier.
At around that time X.org worked entirely fine for me, sans some NVIDIA driver config I had to set up in /etc
few years after even that wasn't required.
Yeah it missed some features I could theoretically use in 2025 but I didn't had different DPI/refresh rate displays back then and those could probably be put into X11 protocol just fine
Let me know when X11 handles fractional scaling across mixed dpi and refresh rate monitors, with HDR and VRR. To me, who has finally been able to drop Windows for gaming in the last 3 months, the benefits of wayland are very real.
Technically Xorg can handle fractional scaling across mixed dpi and refresh rate monitors, but it requires support from toolkits, window managers and applications which means the developers of all of those (or at least toolkits and window managers) need to cooperate. At minimum, you need toolkit support for the most basic. AFAIK Qt6 does have this support and should be able to handle fractional scaling across mixed DPI monitors but not in an ideal way since for better experience you'd need the app/toolkit cooperating with the window manager instead of the toolkit trying to do everything on its own without knowledge of the rest of the desktop. I wrote about it in detail here[0] but the gist is that it is largely an issue of getting the developers of various projects to cooperate than some feature Xorg itself lacks (it doesn't). Wayland had it easier here because it started from scratch and developers had to worry about those things for supporting it. On a more positive note, because of Wayland (and Win32, if a toolkit support scaling there) the the hard part of the work on the toolkit side should already be there.
For VRR the issue is how current desktop compositors render their output, though it should be technically possible to make a Xorg desktop compositor to use separate outputs for each monitor (may need to use Vulkan with custom barriers for vsync though, this is something i've only ). The alternative is to not use a desktop compositor at all, which is what i'm doing (since i also dislike the desktop lag introduced by desktop compositors). I have a 165Hz VRR monitor that i used it for a bit (even connected a separate 60Hz monitor for a bit) and worked fine, though eventually i disabled the VRR functionality since at 165Hz tearing is almost imperceptible (and it never bothered me even on 60Hz monitors anyway) while my monitor is one of those that have some annoying flickering with VRR enabled. In any case, the issue is with the setup and desktop compositor used, not with Xorg itself.
Of course from a user's perspective all these most likely do not make much of a difference.
For HDR there is no support for it Xorg though. Personally, the main use for HDR would be either some movie or playing a game, i.e. fullscreen apps, and switching to another virtual terminal running a Wayland compositor (or just Gamescope) just for those is perfectly fine - having to press ctrl+alt+f1/f2 instead of alt+tab is not a deal big enough to change the entire desktop setup i've been using for many years :-P.
HDR support is still a mess with Wayland. Sometimes you can fix it with gamescope but it’s a swiss cheese thing where for example gamescope breaks some controllers in some games with some GPU drivers. Maybe in a couple more years it’ll be “it just works” territory but it’s taking a while to get there.
After a quick scan, Arcan seems to be pushing a microkernel approach, with some clients providing display server capabilities and others talking to them via shared memory. This will have the same problem as all other microkernels - nice for research, but the extra completely outweights the marginal benefits over a monolithic thing that generally has a smaller API surface to maintain.
Why? People complain that the YAML specification/protocol is too complex. This may be, but I found using YAML much, much easier and nicer than XML. So to me these two things are not necessarily interconnected. You can have a great implementation and a crappy protocol; but also a great protocol and a crappy implementation.
The people who absolutely have to have X11 like myself usually have reasons. It sounds like currently a lot of those reasons for using X11 would prevent using this X server. Like reliable non-fragmented and widely supported screenreader protocol. Or the ability to do keyboard and mouse sharing.
>Applications will be isolated from each other by default and can only interact with other applications either through a GUI prompt asking for permission, such as with screen recorders, where it will only be allowed to record the window specified or by explicitly giving the application permission before launched (such as a window manager or external compositor).
Accessibility? Sure. Everything else? Nah, I'm sorry. There are countless ways to do remoting with Wayland. There are countless ways to do kb+mouse sharing.
I love Wayland a lot, but as far as I can tell the available remoting solutions still cannot enable a headless LXC container to serve a KDE Plasma Wayland desktop. I spent the last couple days trying to cobble some solution together for it and failed miserably. If you know a way, I would be most grateful :-)
You realize that's worse, right? And to be clearer: core Wayland protocol does not have countless ways. It has zero.
Instead of a single protocol with the strong X11 reference X server the wayland compositors pick and choose between libinput, or libei, or libportal with the InputCapture PR, xdg-desktop-portal with the InputCapture interface, some I've probably missed, or maybe you have nothing at all (weston). It's a gamble if your choice of desktop environment and it's wayland compositor's non-core wayland protocols will match up with those the developer for $software chose. On X11 linux everything that works somewhere works everywhere. With the various waylands if you stay within your desktop's ecosystem you'll probably not notice, but go beyond it and you will.
Each wayland desktop pretty much runs it's own compositor with it's own set of third party libs because the wayland core protocol spec is very minimal. I would say incomplete. ref: https://wayland.app/protocols/
I mean, at least with web browsers they usually converge on a common spec eventually, and most of the time you just have a bit stupid repetition in your CSS for a bit. Wayland compositors seem to be actively against this kind of process.
It's a very forced comparison trying to swap in the web's security model, where one runs untrusted code from arbitrary third parties automatically, for a personal desktop computer context where a single user is in complete control.
Uh... lived experience? Try getting keyboard and mouse sharing working across all the waylands with the same software. Not having most of the features in the standard implementation leads to fragmentation which apparently you haven't run into with your use cases yet.
Isn't accessibility outside of the scope of Wayland, whose purpose is to composite application buffers, and deliver input events?
Something like a screen reader needs to talk to an app and query the toolkit for the contents of a window in a semantic way - that's a toolkit feature not a compositor one.
What does this matter for blind people who want to use Linux?
All that matters to them is that it's super complicated and nobody wants to work with the tech to make screen readers work on Wayland.
To my knowledge, X11 didn't offer a comprehensive accessibility API either - there's no Linux equivalent of stuff like MS Active Accessibility or MSUIA on Linux.
Even back then Qt, GTK and everyone else offered their own API and screen readers needed to integrate with every single one - this didn't really change under Wayland, only the sandboxing makes certain operations harder, but the accessibility story on Linux is not great, and never was.
The standard was Extended Window Manager Hints [0].
Above X11, implemented by GTK and everyone else. Right.
However... Wayland makes it impossible to implement EWMH. Which means the enrire EMWH standard needs to be tossed, and everyone needs to make something new.
You can't even get the title of a window, under Wayland. That's private to that process tree.
Wayland requires accessibility be implemented at the application level, not the window manager. And thats guaranteed to make it always broken for a majority of use cases.
Parts of AT-SPI are impossible to implement under Wayland.
> Wayland has no concept of global coordinates or global key bindings. The protocol itself is designed around atomicity which is a nice concept, but is fundamentally in conflict to the need of assistive technologies to control the entire state of the desktop globally. As such, atspi methods like get_accessible_at_point are impossible in Wayland.
> which allows for running full X11 desktop environments using Wayland components
Wait so is this turning Wayland into a client/server model like X11, where eventually it could support existing window managers and other stuff separate from the compositor?
I remember a year or two ago wondering if that would ever happen and I think I only got one reply saying it wouldn't happen because it was unnecessary.
Anything special about Raspberry Pi's that require X11? Raspberry Pi OS defaults to Wayland nowadays, and there's specific kiosk Wayland compositors like Cage (https://github.com/cage-kiosk/cage).
It's not a single thing. Trying to get a screen reader on GNU/Linux is awful. Getting dwell click is easy on X11 and... some Wayland implementations. Or if you like: It was bad on X, and is worse on Wayland.
"The devs of x11" is a wide category, considering how many X11 devs weren't even born when X11 was first written. Plenty of X11 devs objected to Wayland and tried to patch X11, but when half the devs decide they want to write a replacement and put the original into maintenance-mode, there's not much you can do.
You could fork it. X11 hasn't shipped a major release since 2005, the likelihood of a complete overhaul making it upstream was slim to none even in 2009. X11 developers were better-off focusing on stability, and the Wayland devs moved on. There was no conspiracy to kill either project.
So what is it, in one comment you say there were plenty of x11 devs who objected to wayland (please name and show the posts) and on the other hand you say there were not enough to keep an xorg fork going?
People are arguing that fixing the issues in X11 would have been much easier and less work than making wayland. So why could those half of x11 developers who left make wayland while the other half that was left over could not even make one release?
Valve ships a Wayland compositor that just runs XWayland for apps and doesn't even expose the Wayland socket by default. I'm really not sure how we're supposed to count that.
> by itself it looks like a fairly reasonable set of choices.
I have not tried this myself, so I can not speak from experience,
but if they have removed features that people used, then they are
in a similar situation as wayland. So I don't see what the difference
then would be. Perhaps your analysis was also incomplete?
I consider Wayland's choices reasonable as well. I.e. I
it's not surprising that a reasonable attempt to clean up X ends up looking similar to Wayland, just in a slightly different place on the xy graph that has backwards compat and cleanup as its axis.
The thing is, X11/Xorg is a huge monolith. There is simply no way to implement every single feature in one go and then release the competing implementation.
The very thing that makes people biased towards X11/Xorg both negatively and positively is that it is a huge monolith and the only X implementation on Linux. The moment you have two implementations, you're gonna get the same complaints against the second X server as Wayland is receiving.
You think this is an indictment to the second implementation and that they shouldn't bother by saying an "analysis was incomplete" but in my opinion it's exactly backwards. This is an argument that eternally perpetuates X11 not because of technical capability but rather because it was there first.
After all, the moment there is any implementation that is second it might miss a single feature that nobody actually uses, but theoretically could be used when combining an old binary with a new X implementation.
But this argument misses the obvious fact that X11/Xorg is already dead since any code change will break existing applications. Meaning X11 has become an unsalvageable fossil.
Funny, the other day I started writing an X server of my own. While I appreciate and welcome this work, I still use and write software that makes use of old X draw calls, which I intended to incorporate into my server, unlike the author of this work. So I'm glad to see my efforts have not been made largely redundant!
I'd at least consider moving older draw calls into an xlib replacement. Not all of them are suitable for that, but e.g. sufficient font handling to beat Xorgs server side handling requires the Render extension plus ca. 1500 lines of C for a basic TrueType renderer, or half that in a higher level language, or just use FreeType which is a dependency for most X clients anyway.
Tangentially related... Is it just me, but is Wayland still lagging behind X11?
From things like window placement, night light, etc. Things seem to work just out of the box in X11, and there are always issues in Wayland.
(For me this is specifically on Fedora, and I always switch back to X11 from Wayland.)
Well, isn't this compositor related? I've never had any window placement issues running Sway (i3 for Wayland). I never used night light on that machine, so I can't comment on that particular point, but the thing seems to work just as well as i3.
The only problem I have is with JetBrains IDEs, which seem to have shaky support. They're usable (meaning you can code), but the experience is so wonky that I basically consider they don't support Wayland.
The reason I switched from i3/x11 is that we've got some 27" 5k screens at work that are basically useless at 100%, and Sway handles different scaling settings flawlessly (except for IntelliJ, which seems lost).
Intellij kinda supports Wayland, but it gets confused when using scaling, at least when not all screens have the same factor. It's not blurry or anything, but it's slower, and the menus sometimes appear in random places.
When I only use a scaling factor of 1 on all the screens, it's usable enough, although it still feels sluggish.
You are not wrong. But there is a new extension protocol on the way (dunno if done, very probably not rolled out if it is) that let programs solve this problem.
Using kde on Wayland for a while now, on a Nvidia card (debian trixie, just upgraded to forky a week ago), and i can't relate to any of those issues. My only complaint is a silly kernel module warning that pollutes my syslog.
I run two different distributions myself, I know a bunch o people on even more different distributions, set of configuration and based on empirical analysis I can assure you that no one has problem with windows placement.
Out of the box I used have more problem with X11 (tearing and font rendering being the most annoyingly common ones) than I have with Wayland.
It's not just him, but for something else. HiDPI, Ubuntu 24.04, try OnlyOffice or VMWare Workstation. Both don't scale well. I assume other applications also don't scale well. Had to use X. And the scaling isn't even fractional, it's 2x.
It's not just him.
I've had issues with windows popping up on the wrong display and also their scaling.
Works without issue on X11; and I don't even know where to start looking on Wayland.
Users? Obviously xorg devs want to work on something that isn't ancient and crufty. But users want something that actually works and it has taken almost 2 decades to get to that point.
Actually I still have more issues on Wayland than X. Although it is at least starting to swing in the other direction - e.g. KDE's screen recording feature doesn't work on X. The button's still there but if you click it nothing happens.
Most users have no idea what is behind. They don't want X or anything X related, they want things to work. Most of the things worked before 2020, including legacy things through xwayland. Now all things work, except maybe remote apps through ssh ootb, but for this you can either use RDP or Waypipe.
The only thing maybe worth discussing is video acceleration. this aside, I have been using gnome on Wayland for years and no problems what-so-ever. I really don't know what the fuss is about.
I would prefer that people start moving this legacy nonsense behind and finally start accepting new and better things and focusing on things that have future. Same thing happened with systemd, it improves massively everything Linux, yet some people just want their services started with scripts.
What problems do you have when things don't work for you on Wayland?
* Dell latitude with old Intel 8gen CPU, it works fine (Linux kernel causes problems with PSR, but this has nothing to do with Wayland and disabling it fixes the problem, same thing with cstates)
* Dell latitude with 10gen CPU, works fine.
* Huawei d15 with Ryzen 3000 Apu, works fine.
ok. for accessibility it's fair enough as a critique.
I don't use it so can't say. As far as I can tell this hasn't been in focus at all. but most of this is on the toolkit side, not Wayland (even though here one thing is mentioned as Wayland specific, just briefly went through the post)
Does it matter? Your claim is that everything works, and I am here to tell you that I am a real person running real machines that do not work. Unless you're planning to fix the particular bugs and missing features that I'm hitting I don't see where the specifics actually matter. (Anyways, the first machine is a https://wiki.archlinux.org/title/Lenovo_ThinkPad_T490 with Intel graphics; this appears to work but is less stable than Xorg. The second machine is a https://wiki.postmarketos.org/wiki/Lenovo_IdeaPad_Flex_3_Chr... that doesn't run Wayland at all, which I grant is bizarre since the stock ChromeOS uses Wayland. You are welcome to point out that this is more than a little off the beaten path, at which point I will of course point out that Xorg somehow handles it just fine.)
> but most of this is on the toolkit side, not Wayland (even though here one thing is mentioned as Wayland specific, just briefly went through the post)
It varies; a11y isn't a single thing. Deep application integration to allow eg. screen readers to work well probably needs toolkit integration. But there are also things like dwell click, which is really helpful when my RSI is flaring up. In X, I just run `mousetweaks --dwell` and it works, and it works in any window manager or desktop environment, with absolutely no help needed from toolkits or applications. In Wayland, it's sometimes available on a per-compositor basis, which I would describe as purely inferior. On which note, observe that you've linked a blog post about a prototype for GNOME. They note that they're open to working with other desktop environments, but 1. that means it doesn't exist as of that blog post, and 2. I've seen how GNOME operates over the years; I fully expect portability to be a very distant second priority, and whatever they export will be an attempt to force everyone else to do everything the way GNOME does, which will go poorly. I have no interest in ever going back to GNOME, so the actual takeaway, AFAICT, is that the a11y situation on Wayland is bad and will remain bad for the foreseeable future.
if this is so, I can admit I'm wrong. so not everything works for everyone.
For myself and members of my family, I can say that absolutely everything works on gnome. And I have several machines, spread over several cpu and gpu generations, and different form factors that confirm this. not only those 3 laptops I mentioned.
Could it be that since you are not using gnome that you are hitting those problems? My experience is exclusively gnome, so maybe this is it?
a11y aside of course... given that this was not really finished. or seriously worked on.
It certainly could be GNOME vs not-GNOME. That doesn't really help me, either way, but it's not hard to imagine that different compositors have entirely different quality levels.
if you ever come into a position that you could try or would like to try gnome, I would encourage you to do it. maybe you could eliminate that bad opinion of Wayland (or confirm it)...
yes gnome has a vision of how the desktop should look like and strong behavior of "my way or the highway", but maybe you get surprised how well it works. especially on fedora.
I assumed wrongly other people (you mostly) use gnome by default, which obviously is not the case. in that case I could see it as a problem since not everyone has red hat resources for desktop development.
HiDPI scaling (not even fractional, 2x aka 200%), for some apps like OnlyOffice, VMWare Workstation, but not only, on Ubuntu 24.04. Had to switch back to X.
You can blame the apps all you want, but it's a fact of life, and Wayland has been around for 18 years.
I don't know how you can read about the many experiences people have with Wayland not working - even now, let alone 2020 - and conclude that "all things work".
I think we are finally at the point where you can say most things work and it's silly to go back to X11, but even so Wayland has clearly been a huge failure.
The name Phoenix is overused. There is an Elixir framework called Phoenix. I think I also heard of other projects with that same name before.
It's a bit like the name 'Apollo'; besides the moon landing project, I know like 2 dev projects called that and also there is a sales SaaS platform with that name.
Surely people should run a search first before choosing a name...
We get the symbolic reason. It’s still overused and lazy because it doesn’t even relate to the project itself except for its origin in the most generic way.
They could at least use PhoenX or FenX to link it with X
I can second the Apollo thing. I think it might just be a natural name to give something, because when I was a kid I was working on a voice assistant thing instead of touching grass (never finished it) and called it Apollo. This was probably my first project.
How many X servers named Pheonix are there? Surely it doesn't matter if there are frameworks and libraries of the same name in other areas. It's inevitable to have collisions like this.
It was Project Phoenix (resurrection of the Netscape browser). This resulted in the Firebird browser (Firebird and Thunderbird). But Firebird was an existing database that objected to the name. So, we got Firefox instead.
All the first 3 names were taken. They probably had to bribe even the holders of the Firefox trademark to get it (though the terms were never disclosed).
Mozilla was sued to rename Firefox (like I said) by one Phoenix Technologies. If I remember right, they picked two bad names before picking "Firefox" but I don't remember the other one.
I think Firebird was the second name they tried to use that was already taken. They were definitely sued by Phoenix Technologies for one incident. Bryan Lunduke has a podcast explaining the history of this but I saw the one about Phoenix on the Wikipedia page before posting.
Phoenix in the Elixir ecosystem is probably one of the less confusing name uses. Under that stack you get such clear library framework names as: bandit, cowboy, thousand island, and ranch. As well as mint and finch. When not riffing off of previous project names with off axis alternate names, it’s always some sort of ExThing sharing space with at least 3 other varieties of the same (e.g. ThingEx, Thingx, and ExaThing), and you're left guessing which one may have emerged as a conventional standard.
This is a great project! I like and use Wayland but the portal protocols and extension mechanism does leave a lot to be desired. Wayland is still quite a way behind Windows and macOS in terms of what productivity users need
An X11 rewrite with some security baked in is an awesome approach. Will be watching!
I thought for a long time that rather than move to Wayland, we could come up with a tidied-up version of X. Sounds like a good and useful project, I hope it progresses.
If you take the time to read through that (very partial) list of cruft and footguns in X11 it probably makes it a little easier to understand why a clean-slate approach was able to attract momentum and why many hands-on involved developers were relatively tired of X11. Critics would of course respond that backwards compatibility is worth the effort and rewrites are often the wrong call, etc. It's the Python 2/3 debate and many others.
Realistically rewrite would keep X11 compatibility layer and just do same wayland did, make new protocol.
Just... without all that mess that turned out to be at best +/-, at worst outright negative causing problems for everyone involved.
And near all of the "advantages" are "the server is built from scratch" not "the protocol was the limitation"
Python 3 was actively antagonistic to Python 2 code for no reason other than to lecture us about how we were doing things wrong, writing code to support 2 and 3 to help transition was dumb etc etc.
For example, in python 2 you could explicitly mark unicode text with u"...". That was actively BLOCKED with python 3.0 which supposedly was about unicode support! The irony was insane, they could of just no-oped the u"". I got totally sick of the "expert" language designers with no real world code shipping responsibilities lecturing me. Every post about this stuff was met by comments from pedantic idiots. So every string had to have a helper function around it. Total and absolute garbage. They still haven't explained to my satisifaction why not support u"..." to allow a transition more easily to 3.
Luckily sanity started prevailing around 3.5 and we started to see a progression - whoever was behind this should be thanked. The clueless unicode everything was walked back and we got % for bytes so you could work with network protocols again (where unicode would be STUPID to force given the installed base). We got u"" back.
By 3.6 we got back to reasonable path handling on windows and the 3 benefits started to come without antagonistic approaches / regressions from 2. But that was about 8 years? So that burnt a lot of the initial excitement.
> Python 3 was actively antagonistic to Python 2 code for no reason other than to lecture us about how we were doing things wrong, writing code to support 2 and 3 to help transition was dumb etc etc.
> [...]
> By 3.6 we got back to reasonable path handling on windows and the 3 benefits started to come without antagonistic approaches / regressions from 2. But that was about 8 years? So that burnt a lot of the initial excitement.
So it's a great analogy. Wayland started out proudly proclaiming that it intentionally didn't support features in the name of "security" but everyone should "upgrade" because this was totally better, and has been very slowly discovering that actually all the stuff it willfully dropped was useful and has mostly evolved back to near feature parity with Xorg.
Uhm no? As I mentioned, Wayland is simple because it was designed with the idea that there will be many implementations. It turns out that once you have many implementations, you can't just implement screen recording in one implementation and directly integrate with that implementation, because someone might use a different implementation. This then necessitates extensions for features that go beyond displaying things.
15 years ago I tried it and got that path error.
1 year ago I tried again and still got the same error.
I'm well aware that it's simple enough to fix. But I was baffled that the same error was still there.
I dunno there's a lot to pick from when it comes to "worst designed"!
It's definitely not well designed though.
And I agree about recommending it to beginners. Sure, a for-loop and a simple function look very friendly and easy, but good luck explaining to them why they can't import from a file in a different directory...
It was always an option, but "just" needed someone to dedicate all their time to it and pull in a group of long term maintainers. The real question is what will happen with the project in 2 years and will it be stable for day to day use.
The fact that you can "assume Vulkan exists" helps a lot (both hardware and software renderers exist). Do remember--Wayland predates Vulkan by almost a full decade.
In addition, you can offload OpenGL compatibility to Zink (again leaning into Vulkan).
> pull in a group of long term maintainers.
"Use new cool language" seems to be a prerequisite for this nowadays ...
You can't "assume Vulkan exists". Any pre-2016 hardware won't have proper hardware support for Vulkan and that's a lot of hardware still in use. Software renderers are unworthy of any serious consideration due to the perfomance drawbacks.
Just use OpenGL. I don't know when this trend to overcomplicate everything using Vulkan began, but I hate it.
Nvidia had a driver for Vulkan for Kepler which launched in 2012, AMD had support all the way back to GCN 1.0 (also 2012). Intel did have issues supporting it, I can't recall if it was for hardware reasons or just lack of desire for a driver.
Vulkan has substantial advantages for multi-threaded code, as well as exposing the underlying asynchronous nature of running code on the GPU. The kind of thing you want to be able to control with a desktop compositor where controlling vsync and present timing is very important.
I don't really understand what is supposedly missing in Wayland for productivity users? At work I have been using gnome with the wayland backend for years at this point and I can't really figure out anything that's missing.
Accessibility is apparently a big problem with wayland. E.g., the most popular / ?only? app that supports hardware eye trackers on Linux does not work with wayland, and states that it likely never will as wayland does not provide what it needs to add support (it is also the most popular app for voice/noise control). Even basic things like screen readers are apparently still an issue with wayland. Without a strong accessibility story, systems running wayland would have been banned at my last employer (a college).
Personally, I have a 3200x2400 e-ink monitor that has a bezel that covers the outer few columns of pixels. I use a custom modeline to exclude those columns from use. And, a fractional scaling of .603x.5 on this now 3184x2400 monitor to get 1920x1200 effective resolution. Zero idea how to accomplish this with wayland-- I do not think it is possible, but if anyone knows a way, I am all ears.
I ran into, at least, ten issues without solutions/work-arounds (like the issue with my monitor) when I tried to switch this year, after getting a new laptop. Reverted to a functional, and productively familiar, setup with X.
The xdg-desktop-portal stuff is still too immature. For example, my friend wanted my help after upgrading his Pop_OS to 24.04, and 24.04 replaced GNOME with COSMIC. COSMI had no RemoteDesktop portal (and still doesn't have it), so we couldn't use RustDesk like we always did without him installing a GNOME session just for that.
I've been an i3 user for almost two decades, but eventually switched to Sway - to this day there's no InputCapture portal, so I can't use Synergy with Sway, forcing me to switch to i3 while I'm working.
It's been over 10 years of things like that. There's always SOMETHING missing.
Screenshots are just completely broken. People always tell me to use other apps like flameshot but IME it just doesn't work and I don't want to have to mess around so much to take screenshots.
I'm still using Wayland because it's what came with my distro (endeavour OS, gnome), but it's really strange how it came broken out of the box.
Hmm, you mention in the README that it only works in a privileged container. This of course negates the security benefits Wayland supposedly has over X11, so it doesn't seem ideal.
My desktop is a bit long in the tooth (22.04), but I've long given up on trying to screen shot or screen share from Wayland. I have my Macbook sitting next to it and use it for those things, where it works basically flawlessly.
Kind of waiting for 26.04 to upgrade at this point, but I'm not really expecting any of this to be better yet.
edit: If I had it to do over again, I wouldn't have gone Wayland at 22.04.
Window positioning? You cannot position the window, you cannot send a hint, nothing? So my pop-up with GTK4 will randomly be placed somewhere, anywhere, without any control. OK, GTK4 went further and also removed popups without the parent, so you hack that with an invisible anchor window and then write platform-specific code for sane platforms that CAN, of course, move the window. And let's not talk about window icons that you have to put somewhere on the file system?
Have you considered if someone wants to make a compositor where each window is projected onto a facet of a hyper cube and must place windows in 4 dimensions? These are important use cases we should support, we should make cross platform software as difficult possible to develop for Linux by removing features that have been standard on desktop operating systems for decades.
I must correct you! Wayland has not and indeed cannot remove features because Wayland is a “protocol”. It is the compositors that are removing features.
This dilution of responsibility should make you feel much better.
It's not technically behind on window positioning. Rather, it was a deliberate choice not to support it. You can very reasonably object to that, but it is sorta a necessary measure to prevent clickjacking.
And common sense mitigations: if a new program I've never seen before drops an actionable control under my cursor, maybe just default to not immediately accepting the next input to it so I have a chance to see it.
I mean, you can create alternate APIs that would work for the pop-up use case: you could have a command to create a new window positioned relative to the current window’s coordinate space.
That limited capability still has a risk of denial attacks (just throwing up pop-ups that extend beyond the current window’s boundaries), but those can be mitigated in a number of ways (limit the new window’s boundaries to the current window’s, or just limit how many windows can be opened, etc.).
BS, windows and macos cant even do proper window managing for a start, and then it just goes downwards from there on.. You can perhaps install various weird third party things, but it does not come with it by default.
If you took people who absolutely never tried any computing, and gave them macos, windows, and for example Plasma, they would NOT consider windows or macos to be ready for the desktop. If you go 15 years back, even way more so.
even in the early 2000s, windows was so hilariously crappy that you had to make floppy disks to even get to install the thing. If PCs didnt come preloaded with windows, regular users would never ever be able to install it, versus the relative ease a typical linux distribution was to install. This is also one of the large reasons that when their windows slowed down due to being a piece of shit with 1000000 toolbars, people threw it out and bought a new, despite the fact that a reinstall would have solved it.
Windows in early 2000s didn't even detect your early 2000s SATA drive
Windows in early 2023 didn't even detect the network card it needed to download network card drivers. After changing mobos I needed to boot into linux to download network drivers for windows...
Windows in early 2025 still uses SCSI emulation to talk with NVMe and only now the server part got a proper driver
Windows in early 2025s still need virtio driver injection to boot properly as a VM without IDE emulation
"Drivers working out of the box" were never windows strong part
> Windows in the early 2000s installed just fine without a floppy directly from CD or PXE booting.
when was it sata became the norm? im thinking circa 2001-ish, and what windows was latest here? im thinking windows xp. lets try remember, did windows xp include sata drivers on the installation medium?? oh wait, it didnt. There wasnt even ahci at the time, and windows xp didnt include a single sata driver for any of the chipsets at the time
> A Window Manager and Window Server don't come by default with Linux... It's always an install-time option on the major distros.
desktop distributions generally come with a desktop environment default selected, or prompt you to choose between a few. one feature that has been there since more or less forever is alt + left/rightclick mouse to move/resize windows, which is significantly better than finding the title bar or corners like. for an operating system called "windows" its pretty hilarious it has the worst window management of them all, dont you think?
> If you took people who absolutely never tried any computing, and gave them macos, windows, and for example Plasma, they would NOT consider windows or macos to be ready for the desktop.
There's some truth to this. I've been installing fresh Windows 11s on family computers this holiday season, and good lord is it difficult to use.
The number of tweaks I had to configure to prevent actively hostile programs from ravaging disk read/writes (HDD pain), freezing and crashing, or invasive popups was absurd.
As someone who came from Windows, and has used Linux as my primary OS for 15 years, and MacOS here and there (cos work provided laptop), I can tell you that Linux was not ready for prime time 15 years ago. Today, I feel it is, but definitely not 15 years ago.
With prime time I mean being comfortable enough to install it for a non-technical user. Even during Ubuntu's Unity days it didn't feel like I could install it on a computer for my parents or siblings for them to use as a daily driver.
My parents did fine with Linux. My mom still does; it's certainly less maintenance effort from me than Windows would require.
It was fine for non-technical users since at least early GNOME 2, if you're ready to help them set up and maintain. Semi-technical users (Windows power users, gamers, &c — people who like to install and configure things, but fear the deep dark abyss of the terminal) were and remain more problematic.
Unity days were the nadir of linux desktop ux — it was when Gnome 2 was gone, and 3 not yet there. Still better than contemporaneous Windows 8, though.
I can bet there’s no OS that are easy to install for a non-technical user. And that start from booting the installation media. Give someone a OS with their software already installed and they will use whatever OS that is.
People are always task-oriented, not tool oriented unless they’re nerds.
I had Kubuntu installed on my grandfather's computer for a year. I ended up replacing it for Windows because my aunt likes to install stuff on it. But my grandfather was happy with it. He only needed a working web browser and a program to use the TV tunner.
15 years back people were given Windows macOS and Linux and people voted which OS were ready for the Desktop and which were not. The only BS is your inflammatory contribution to this topic.
Nope, Macs were expensive stuff games did not run on, and linux was just not pushed by near anyone.
It was not a war "which desktop is easier to use", it was "which system can run stuff I need". And if "the need" was "video games and office stuff", your only choice was windows.
they were not, they purchased what was in the stores, which was only windows. all the way from first windows to windows xp it was the biggest pile of shit imaginable. the average user wouldnt even have half a chance of installing it, and certainly couldnt use it with any kind of reasonableness, it was a giant mess, it was just the mess people were used to. Most people would throw out their computer and buy a new when windows became slow, because, of course it gradually becomes slower, makes perfect sense, no?
KDE from 15 years back was HUGELY better than windows at the time, and frankly, also windows now
Windows is reasonably OK, but MacOS' window management has always been really terrible.
Just think through the many different iterations over the years of what the green button on the deco does, which still isn't working consistently, same as double-clicking the title bar. Not to mention that whatever the Maximize-alike is that you can set title bar double click too (the options being Zoom and Fill, buried in settings somewhere) is different from dragging the title bar against the top of the screen and chosing single tile. Which is different from Control-Clicking the green button. Maybe. It depends on the app.
What a mess.
Both of them miss (without add-ons) convenience niche features I cherish, such as the ability to pin arbitrary windows on-top, but at least the basics in Windows work alright and moreover predictably and reliabily. Window management in MacOS just feels neglected and broken.
There may be many other ways in which MacOS shines as a desktop OS, and certainly in terms of display server tech it has innovated by going compositing first, but the window manager is bizarrely bad.
There is at least one area where both macos and windows suck - handling window focus. MacOS is regularly having trouble with tracking focus across multiple monitors and multi-window apps, making it unusable with keyboard only. And Windows just loves to steal focus in the most inappropriate moments.
>> windows and macos cant even do proper window managing for a start
> Well they certainly manage them better than x11 and wayland.
X11 doesn't manage Windows. You'd know this if you used it, and if you've used it, you'd know why some consider the window management on Windows and MacOS very primitive.
> X11 doesn't manage Windows. You'd know this if you used it, and if you've used it, you'd know why some consider the window management on Windows and MacOS very primitive.
Sure. Windows and macos are also fallible. But there has never been a project that competes with these two brands that can boast a similar commitment to stability and usability.
I don't use a Mac, but have you ever used Windows?
I mean, maybe you have, but if you are not fussy then at worst MacOS is quirky and Windows and Linux are identical and merely have different icons.
If you pay a little bit of attention you will notice that on linux things seem more flexible and intuitive.
If you are very finnicky, there is nothing that comes close to X11 window managers when it comes to window management flexibility, innovation and power.
Windows allows you to launch applications from a menu or via search. You can switch between windows with a mouse or keyboard shortcuts. Windows can either be floating, arranged in pseudo-tiled layers, or full screen. KDE can pretty much do the same under Wayland. Ditto for Gnome under Wayland, albeit to a lesser degree. That covers the bases for most people.
X11 window managers were a mixed bag. While there were a few standouts, most of the variation was in the degree to which they could be configured and how they were configured. There may be fewer compositors for Wayland because of the difficulty in developing them, but the ones that do exist do standout.
> I don't use a Mac, but have you ever used Windows?
I have
> I mean, maybe you have, but if you are not fussy then at worst MacOS is quirky and Windows and Linux are identical and merely have different icons.
Neither have keybindings that make any sense. The other failures are secondary
> If you pay a little bit of attention you will notice that on linux things seem more flexible and intuitive.
Only for windows refugees that have never used Mac OSX
> If you are very finnicky, there is nothing that comes close to X11 window managers when it comes to window management flexibility, innovation and power.
Unless you want to copy and paste, or have consistent key bindings cross applications, or take screenshots. Sure
I can agree on Windows, but there is no such thing as "keybindings that don't make sense" on a proper Linux WM given that you can literally make up any keybindings you want. I mean this strictly from a window management perspective, yes applications running in those windows have often got their own idea of what good UX is, and this clashes. That's just a trade-off of Linux and to a lesser extent Windows not being complete walled gardens.
> that have never used Mac OSX
I have _used_ Mac OSX. It was and continues to be a confusing experience every time. I'm not saying that this would be the case if I bothered to learn it, but in all the times I have used it, I have failed to see any feature which would make me want to switch to it over i3 or which I feel like is missing in i3. Really it doesn't seem like there is any way of making it act remotely close to i3. Tiling as an option on top of whatever Mac OSX has is just as appealing to me as tiling on top of what Windows has.
> Unless you want to copy and paste, or have consistent key bindings cross applications, or take screenshots. Sure
I've never had copy and paste fail on Linux. The only issues I've had is with more modern applications not implementing the selection properly which is a feature you don't have on windows in the first place. No idea about Macs.
Screenshots have always and will continue to work (the way I want them to) because I can, as mentioned, bind any key to any action.
As the application author you can set the release mode in the build script so that the release flag looks like `zig build --release` instead, and the user doesn't choose the optimization mode.
As a user you can pass `--release` to `zig build` to request release mode. If the application doesn't want to pick for you, you'll get an error and then you can pick for yourself.
In this case, it looks like the author of Phoenix wants to choose ReleaseSafe as the official release mode of the application.
This is the kind of initiative I’d prefer to see from X preservationists. Great job, I hope it succeeds. I prefer Wayland, but there’s still a place in the world for X; it just needs new dev teams to shoulder the burden.
Which one? The Gnome Wayland, the KDE Wayland, the xroots wayland, Weston, or one of the others? Each one is an independent implementation of a Wayland compositor, with a differing, incompatible set of extensions.
X11 was a single, pretty janky implementation. Wayland is the worst of both worlds -- it's cleaned up a little, but it's still kinda janky. In exchange for a little bit of cleanup, mainly around bitmap fonts, it's no longer a unified protocol.
And to top it off -- it kept the worst part of the X11 protocol, the XKB extension, but got rid of input handling entirely, which means that every platform needs to reach for platform specific code to implement reading from the mouse and keyboard.
If we're hypothesising a perfect world, ideally they standardise some way of sharing framebuffers between programs into Wayland. I suppose maybe they already have I gave up on the ecosystem in the early 2020s. That seems like it should be long enough ago now that they've got even advanced features like screenshots under control and rolled out.
Sure, but I don't see a world where keeping X11 alive, in addition to all of this, makes anything better or easier, for anyone in the medium to long term.
If, as an application developer, you target X11, you have a program that will work on Linux and BSD with all desktop environments. It'd even work on Wayland via Xwayland. If you want to use it on other OSes, it's less smooth, but also working on MacOS via Xquartz, and Windows via Xming. There's even an X11 compatibility layer for Haiku (Xlibe).
With Wayland, you don't even get compatibility with Gnome and KDE. You need conditional compilation to get mouse events if you port to FreeBSD Wayland.
For the medium term, if your goal is to reduce fragmentation, X11 is the portable target, even if you use Wayland.
It makes things a lot better for me, for one, and clearly there are more of us. You may not think it matters, and that's fine, but X11 won't go away because there are enough of us that won't let it.
> The choices in the Linux ecosystem lead to unnecessary fragmentation and development/packaging nightmares.
You cannot possibly use this as an argument in Wayland's favor. X11 sucked because it baked everything, including multiple outdated kitchen sinks, into a single Xorg monolith. Wayland sucks because it factors out everything, including really important features, into optional extensions, ensuring that anything more interesting than "draw pixels to a window" will always be different on every single compositor.
The *original* X11 should die, but the modern Linux GUI stack has long abandoned most of its features anyway. X11 was already reduced to a bit-blitter protocol long before Wayland.
So, in theory, we can embrace a rather-minimal X11 implementation that can run the modern UI, including some desktop features missing in Wayland.
Linux on the desktop only took of because Ubuntu, with mixed results and a lot of controversy, decided to standardize and polish the experience for "normies".
The distribution sprawl I largely see as a detriment to the ecosystem.
I would argue that Desktop Linux finally took off because of Steam Proton, and because of Windows 10/11 and macOS starting version fartascular or whatever their versions are named.
I remember seeing Linux gaining some traction 15 year ago, and Ubuntu focusing on polishing the user experience (with initiatives such as fixing "One hundred paper cuts"), but then this changed instead of keeping this stable the great rewriting began. Seeing Wayland (which is just one example) users having a problem with screen sharing just convinces me how much of a self-own this was from the Linux community.
Yeah but Ubuntu screwed up switching from Gnome to Unity back then, which sent tons of users elsewhere. You can't just rug-pull the entire GUI people were used to, which was also similar to Windows.
There isn't a successful Linux desktop OS. The Linux kernel is successful on servers and appliances, but only the kernel. And there aren't many even-split choices on your typical server. Like yeah zsh has a bit of a following, but everyone assumes you use bash, which is a good thing.
> I say let X11 die, bury it, and never let it rise again.
totally awesome! And once we are done with X11, lets put pulseaudio to the grave! We can all focus on having an audio stack that does realiably stream to many sinks!
> And once we are done with X11, lets put pulseaudio to the grave!
That'll happen first, I think. The trick is that pipewire is actually a fully functional replacement, instead of trying to declare everything out of scope, so with only minor effort people can just switch and everything works.
Please prioritize to keep accessibility features working.
This is really the main issue with wayland. Yes, it might be more stable these days and work fine for you. We can talk how how it makes writing you own WM needlessly complicated and all that but the one thing that makes wayland unacceptable is its lacking accessibility story. After so many years.
Accessibility is not something you can worry about adding later. It is the first thing you should think about when designing new software.
As someone who is not deep into linux desktop history: Can you please elaborate on the missing accessibility features in wayland or direct me to resources on that?
I've been using wayland for a while now and am very happy with it, but my accessibility needs are pretty basic.
> Accessibility is not something you can worry about adding later.
I don't think there's any concrete proof of this. Ideally I think people want accessibility handled by their WM/DE; you're not getting Windows or macOS-quality a11y "for free" unless your desktop embraces it. At which point you might as well make it a separate, aftermarket protocol and slap it into d-bus.
If the Linux ecosystem is going to be fragmented and move past single-point-of-failure, polishing Xorg's accessibility works against the goal of standardized a11y.
Same author behind https://git.dec05eba.com/gpu-screen-recorder/about/ , the best screen recorder for wayland imo (I had tried other alternatives but none of them helped in recording at 4k 60fps, this worked out of the box).
I have no idea how well this one works, but I am all up for
more projects that can compete against the singularization
that corporations currently try (see paid developers for
wayland, GNOME and now also KDE). I wonder how much money
would be needed to make the xorg server adapt to the modern
era; I don't even know the featureset that is missing for
this either. But I also know that wayland, after 20 years
(!!!), will never cover those requests users had over tohse
20 years, simply because it tries to cater to a narrow
specification wanted by corporations rather than the people -
so much is now clear (wayland protocol was released in
2008, so it is soon 20 years actually; in a few days we
have 2026, so it will be 18 years).
I gave it a quick go and very few things work at the moment. None of the programs you listed do.
From the README:
At the moment it can render simple applications that do GLX, EGL or Vulkan graphics (fully hardware accelerated) nested in an existing X server.
And that sounds about right. As far as I can tell it doesn't yet have a lot of the core X11 stuff that "normal" clients expect. For example xterm doesn't start because requests like X_AllocColor, X_OpenFont, X_PutImage (a few picked at random from the error output) are not implemented yet.
It’s possible that most of old X11 toys would not work properly, because many of them rely on X11 drawing APIs, but they are pretty simple to implement anyway.
That's very true, and I believe Wayland has a DRM leasing extension just for this use case. SteamVR uses it to punch through the compositor and draw straight to the screen.
Multiple screens support is listed as non-goal. Would that prevent its usage with window managers which support virtiaul desktops? I am i3 user and it is a critical feature for me.
Is this why back in the day sometimes a Linux distro would have a multi-monitor setup where each monitor was an actual different desktop cube for example. There was a time when each window for an Nvidia graphics card in that type of configuration could not be moved from one screen to another, etc.
Given that they're fine with adding breaking changes to the protocol, I think it's a shame that they're not supporting multi-screen. This will lead to the same problem with Xrandr based multi-monitor where you get screen tearing with mixed refresh rate displays. I would prefer to see "traditional X11 multihead but you can move programs between screens" as the solution for multiple monitors. Even if it worked like Mac OS X where you can't have a single window span across multiple monitors, it would still be better than the current state of X11.
As others have already mentioned, the continuous multi-monitor(Xinerama) was an afterthought. A good news is that, by design, it’s actually pretty easy to add in the later steps.
Some things do but for some details I'm amazed what I need to do to make it work, like going to sleep with multiple displays. Maybe it's a sway thing and I'm not complaining at all, crafting a solid minimal configuration has its charms.
I'm just thinking why did it take me so long to do the switch. I still keep X around, but not sure how long. Like keeping vim around after switching to nvim few years back..
What are the things specifically that work better? because most of the case people dont have issues because of the x11 (the protocol), but because of how the xorg server works
Bit of an observation, but I've noticed that there's been quite a few pragmatic projects started in Zig. Bun vs Deno comes to mind (one focused on DX, the other on security), and now this vs Wayland. Not to say that designing something properly is wrong, just that it tends to throw away a lot of important interoperability.
Yeah, we should introduce competition. It doesn’t feel like Wayland is improving these days. Missing features force me to hit X11 regularly, and I still get Wayland session crashes etc, while X11 could happily run over a year without crash and run all applications I need without issues.
If you are not going to implement X11 drawing ops and XRender (which I, and many others, still use heavily), what's even the point? Any 'modern' program that only does client-side rendering already supports Wayland. AFAIK GTK 3 doesn't even support DRI on X11 unless you somehow trick it into using the abandoned OpenGL Cairo backend, but that's not modern enough apparently.
It talks about trimming 'legacy' features and specifically says they are omitting 'font-related' operations. That obviously means no useful core X11 application will work (unless you count xlogo and xeyes). Whether the XRender glyph cache mechanism is included is unclear. It also says only DRI is *currently* supported, but maybe that's incidental?
XRender isn't part of the core protocol so it should be implemented in the future. There is already some xrender code in there. Almost no applications use x11 core protocol font, except for cursor. Since the x11 core protocol font (on xorg server at least) is rendered without anti aliasing and doesn't really support unicode.
Core fonts absolutely support Unicode. My (non-Xft) xterm windows are full of Unicode characters right now. It is true that anti-aliasing is not supported by the X.Org server, although scalable fonts have been for a while (https://www.x.org/archive/X11R7.5/doc/fonts/fonts.html#AEN49...). But you don't need anti-aliasing on a high-DPI display, and on a low-DPI display you can use any of the many beautiful bitmap fonts, unlike a lot of ‘modern apps’ these days.
This is cool. What X is really missing though is a little bit of love from the toolkit side, e.g. proper latency hiding using XCB, support for dis- and reconnect or support for moving windows to display on different devices.
The part that is counterintuitive to most people when it comes to the "server" terminology is that, with X, your end-user workstation (which may be an incredibly dumb X terminal) is the "display server", which means you remote into a server (in the traditional sense) elsewhere, which then acts as an X client by making requests to your local machine to display windows.
The way most people think about it, "client" is your local machine and "server" is the remote machine that has lots of applications and is potentially multi-user, but X turns that backwards. The big iron is the client and the relatively dumb terminal is the server.
I think the confusion is obvious, given a little empathy for the range of people who use computers.
The server is usually a remote machine, especially back in the time when "client-server" architecture was emerging in mainstream (business) vernacular.
Please don't imagine that I don't fully understand this.
Nevertheless, X11 "server" and "client" have confused very smart and highly technical people. I have had the entertainment of explaining it dozens of times, though rarely recently.
And honestly, still, a server is usually a remote machine in all common usage. When "the server's down", it is usually not a problem on your local machine.
Yes, it’s simultaneously logical if you look at how it works and immensely strange if you don’t understand the architecture. (As has been noted all the way back to the UNIX-HATERS Handbook[1], although, pace 'DonHopkins, the NeWS Book uses the same terminology—possibly because it was written late enough to contain promises of X11/NeWS.)
There is nothing at all strange about the terminology. Go run ps on macOS and marvel at the "WindowServer" process. The generic architectural term is "display server".
Programmers aren't good at checking if the name is taken. We've done this particular one before. Phoenix (Firefox) had to change names because of Phoenix Technologies, then again because of the Borland Firebird Database.
The issue (to my understanding) is that it is a very different protocol, which makes it quite onerous for application and desktop environment developers to transition to. Also, since some desktop environments have really grown opposed to Wayland (e.g. XFCE) it puts the application developer in the position of having to wait.
XLibre is a joke. They're making changes for the sake of changes: for example, commit aefde9 strips out vendoring in an ad-hoc, incomplete fashion (introducing a minor spacing bug in the process); and commit aafd986 replaces `int` with `unsigned int` (instead of `size_t`), failing to properly fix the bug that the compiler warnings identified (albeit, also removing an unrelated C footgun along the way, so this does look like a bug fix). The main author has a history of cowboy commits: 533c45e (which made it into mainline Xorg before he got kicked out) straight-up prevents hw/xfree86/os-support/bsd/arm_video.c from compiling, so it's clear there's no actual testing taking place.
I doubt the XLibre authors understand the X security model, either – they never do, in forks like this – and they've alienated most of the security researchers who might otherwise clean up after them.
Phoenix and Wayback are much more interesting projects, in my book. Wayback's designed to actually work, and I expect it to be production-ready much sooner; but I expect Phoenix to be the more technically interesting project, since it's deliberately breaking from the X11 spec.
Here's two complaints: it's a security theater, and it's horribly balkanized by design.
On X, I can run tools like xmacro or xdotool to automate the desktop to my heart's content. On Wayland, this isn't supported "for my security" and my remaining options boil down to either using a tool that works one level of abstraction lower (requires root and/or a daemon), or a tool made exclusively for my DE if one even exists. What used to be a cohesive environment with portable knowledge and tools is replaced by incomplete, broken, or outright missing tools and a complete lack of parity across DEs. For what? Am I supposed to be happy about this?
What is the point of automating another UI/Desktop than the one you are actually using? If you allow people to build different type of systems you can't expect them to function the same and have the same API.
> most of the Wayland complaints you read are handwave-y bullshit, idk what else to say.
The dislike of the product among users is certainly sincere. I feel like somewhere there is probably an author of a young adult novel with a title like “He’s Just Not That Into You” with a cathartic and cautionary ending and that author should write a pamphlet or something specifically for the benefit of the Wayland people.
OK, you can't have your preferred environment because someone else has a different use-case.
Moreover, people will condescend to you and insist your setup never worked, nobody ever used it, and nobody cares that it's going away. Plus, they state that you are just being difficult, if not delusional, when you say that you are quite happy with how things are. I mean, your way never worked, so how could it have been your way at all? You must be a troll, troll. Stop trolling.
Cool project I guess, don't see the point but technically interesting. Will be cool to have another modern display protocol/server. I personally would have rewritten Wlroots in Zig or something, but I guess this is more interesting.
This is a really really bad comment.
I've never heard of the framework you're talking about and I thought you were talking about the Firefox prototype.
I don't have an opinion on the matter, but it's pretty popular. According to [1], Phoenix "was used extensively over the past year" by 2.4% of responders.
It's still a silly comment. The Phoenix web framework is a little over a decade old, and there are many other tech things named Phoenix that pre-date it, even just within the web application space. I assume Apache Phoenix and the web framework have a lot more to be annoyed at each other for.
I'm also pretty sure that there was an "Elixir" in IT before there was the language said framework is written in… I mean, given that the letter "X" is in both Unix and X11, I'm pretty sure most words containing it have already been used once or twice.
(I still think they should've stuck with "Firebird", little danger of confusing a browser with a database system mostly used by Delphi devs)
I’ve been on hn for almost 10 years, and have been doing mostly frontend development for the whole time. As far as I know I have never seen it mentioned. But then I have no interest in elixir, so I might just not have remembered the name even if I saw it.
Pretty interesting approach to make an X server that is essentially "Wayland-like" (merging display server/compositor by default, isolated apps by default, no remoting of GLX, dropping legacy protocol features to the point of breaking compat with the core protocol, etc.). Not sure who this is for, but by itself it looks like a fairly reasonable set of choices.
For people who absolutely have to have X11 this looks like a better plan than XLibre.
It depends on whether their reasons for "absolutely having to have X11" hinge on actual compatibility with e.g. old binaries or wanting full remoting without streaming pixels.
This project would satisfy people who really actually want Wayland, but were upset by transitional pains or interactions they had around it and want to stick with X11 just-cause while getting some similar benefits. This arguably does describe some people but not sure it's a whole lot in the long run.
But who knows, maybe this could also make an easier to maintain XWayland some day, or a nice basis for implementing more esoteric X11 bits down the road vs. the older Xorg codebase.
From my perspective X just got to the point where it just works for me few years ago and Wayland is just introducing more issues than it solves (to be clear it solves no current issue for me, only one that I think might be better for me is handling different refresh rate displays and maybe fractional scaling... and that could probably be done within X11)
Like, why simple "copy the screen" got suddenly so complicated? Why every WM suddenly needs a bunch of features that before were just handled by display server, where they belong ? Why some(most) WMs handle title bars but GNOME doesn't ? Why someone decided title bar management is optional to window manager ?
X11 might need to go but Wayland have learned no lessons from it. It's just knee-jerk "if X11 done it this way, let's do it differently"
Whatever the issues with X11, it was properly designed. Wayland is the kind of software that adds features with nobody looking at the consequences. Who knows what they will break next version.
From all the criticisms leveled at Wayland, this is definitely the strangest I've ever heard.
I really cannot thing of any existing functionality ever broken by a new release of wayland-protocols, neither by a plain bug nor by a bad interaction. No doubt someone else will be able to recall an example, but it's really not a common thing.
This is partially because the governance model and community mindset is the opposite of what you describe. Inclusion of new protocols in the stable release requires existing, proven implementations and consensus across multiple implementors, making it a high bar. New proposals run a gauntlet where pretty much everyone is looking at the consequences in detail.
In fact a more common criticism of Wayland is that the focus on high quality and the consensus requirement are too strict and have slowed down filling in feature gaps users need filled faster. This argument I think can be successfully defended against - mainly, that it helps avoid the mess X11 became over time -, but at least has some basic merit in reality and is an avatar for genuine user pain.
As for X11, as someone who had to implement a lot of X11 specs over the years, I can tell you that their provenance between X11 itself as well as ICCCM and EMWH had plenty of super dumb ideas and cruft and inconsistencies from lack of foresight and eventually datedness. You don't want to see the towering stack of hacks and heuristics we used to have to ship to make X11 behave somewhat consistently and sane :)
In short, with all due respect, but I think you really don't know what you're talking about. We really should resist this type of narrative reality distortion field on an engineering forum.
> making it a high bar
That high bar is GNOME having an uppity whenever a Wayland protocol is suggested they don't like, that even if is accepted, if Mutter doesn't implement it then its dead in the water given its the de facto default compositor on unfortunately what people consider "Linux", aka Ubuntu.
e.g. DRM leases that only got changed because Valve has the bigger underwear. Expecting games to implement DBUS (incl. when running under Wine) to access VR headsets just for GNOME is nuts.
The government model needs a change that stakeholders who ship devices to the end users that rely on them have more of a say, whether that's Google, Valve etc. Valve is now backing and pushing KDE into average joe end users is a telling.
Wayland design choices are heavily influenced by automotive and TV where it has been industry standard way before it became mostly usable as a desktop. And that has lead to design compromises that look odd on desktop.
But hey, you can probably run automotive UIs with your desktop compositor.
And Gnome devs are just being silly at this point.
This car runs KDE Plasma's KWin, along with many other Mercedes-Benz models currently launching:
https://youtu.be/wo5As8et1G8
https://youtu.be/pqJ-9SUPFwY
Notably this deployment doesn't use any of the old-gen automotive Wayland cruft like ivi-shell though. It's pretty much the desktop stack now.
I miss the 1990s Benz 190E I used to drive: the only electronics in sight were the tape deck/radio. Even the door locks ran off a vacuum system.
I will never buy a car that runs an X-windows server.
It's a Wayland compositor, not an X-windows server!
and even if it wasn't Wayland, it would be an X Window server.
> Why someone decided title bar management is optional to window manager?
Are you implying title bars should be mandatory in all WMs? I'm using DWM on X and I love that I have no title bars. If a program tries to force one on me I disable it or use something else if that's not possible.
It should be mandatory wherein the title bar is expected/desired by the user and not inherently the responsibility of each individual app by default. The wm should have the capability of drawing a titlebar for each app and do so by default unless the app opts to draw its own OR the user configures the system to not do so.
Yes, and that's how it's handled by the desktop environments I've used. Many programs have the option to use the system, program or no title bar. But should it be mandatory for every DE/WM or can the user choose one that satisfies whatever preferences the user has?
This way people like me still have the option to use window managers that don't have title bars. Title bars are useless for power users that know what program they're in and don't need them. To me they're in the way.
I don't "actually want Wayland" because I want the simplicity of X and the ability to run my own wm, but I have no need for legacy X11 requests, for some values of "legacy". Whether this will become viable for me remains to be seen, but I need very little from my X11 server.
I remember Wayland scared me off of Linux when I tried to switch to Ubuntu a few years ago. I couldn’t watch a movie without jiggling my mouse every few minutes. At the time I feel like it was like “yeah that feature doesn’t exist yet” or something. So I switched back to Windows. It looks like there’s workarounds now but I’ve mostly switch to my fantastic M1 MacBook Air at this point.
Wayland still doesn't support screensavers last I checked, which is wild to me. Truly bizarre that such longstanding feature is just absent.
It's a matter of designing and proprosing a protocol for it. X11's screensaver support was also a protocol extension.
There probably hasn't been much interest in it because screens can easily be powered off remotely, which was not the case in 1992.
Yeah, most of those real gaps have been solved at this point. I'd encourage you to give it a shot now with Avahi
Fair! Though I'm actually not sure I understand what you mean with simplicity. X11 is so vastly more complicated than Wayland.
For the server/compositor.
Not for the client, or if you want to write a wm and is forced to write a compositor.
And actually I'm not even even convinced about the server if talking about a minimal server like this that insists on DRI/GBM, and ditches all the old rendering cruft.
Well, you are not really forced to write a compositor these days as there are libraries that do all the heavy lifting for you.
Check out Louvre for example. Or Smithay if you like Rust. And if you want a bit more depth, there is wlroots of course (or the hyprland version). It is not really any harder than writing an X11 WM.
Yeah, no I have my own wm in Ruby that is fewer lines of code than a typical Wayland Hello World, and that does what I want. I have no reason to want to throw that away for something that doesn't offer me any features I care about, and removes features I do. Such as the ability to just restart my wm if I make a change to it without affecting my current session at all.
Unless you can show me a solution that lets me replace my tiling and floating wm in ca 1500 lines of Ruby, what you're offering me is inferior to what I have with X
It's called an extension. What's the point of mandating a (bad) IPC API?
Th point is that with X I could start with less than 100 lines and switch to using my wm, and stepwise refine it while using it.
You might consider that a bad API, but to me any solution without it is massively inferior and not something I will ever consider.
wlroots and smithay (I'm not familiar with louvre) do a lot of the difficult work for you, that most compositors will do without much variation but there's still a lot that compositor writers still have to do. It's still a significantly larger task than, for example, writing an X11 WM.
(Well, writing an X11 WM that also includes a built-in compositor is a bit more than just the WM, but I'd say still less than writing a Wayland compositor using wlroots or smithay. For example, xfwm4's compositor is around 5300 lines of C, which is... not nothing, but not crazy either.)
https://github.com/CuarzoSoftware/Louvre
So build on top of wlroots or something. DWL for example is super small...
Current status:
> 2025-08-16: dwl IS CURRENTLY UN-MAINTAINED. AT THE PRESENT TIME, I (@fauxmight) DO NOT HAVE THE TIME OR CAPACITY TO KEEP UP WITH wlroots CHANGES.
https://codeberg.org/dwl/dwl
I said build on top of wlroots, not DWL. And I only brought it up as an example of a small Wayland compositor/window manager because the poster I was replying to wants to build their own anyway. DWL is more interesting as a learning exercise than something to use.
The -IMO- important part of that quote is "NOT HAVE THE TIME OR CAPACITY TO KEEP UP WITH wlroots CHANGES".
X11 is backwards compatible, you do not have to "keep up" with its changes.
wlroots seemingly isn't. This is a significant issue when it comes to relying on most 3rd party libraries.
> X11 is backwards compatible, you do not have to "keep up" with its changes.
That's certainly one way to say "no longer developed".
That was also true back when it was actively developed though. X apps compiled a long time ago still run fine today.
Xorg is still being under development, there is another fork in development too (XLibre) and you're in the comment thread for a project about a brand new X server written from scratch.
Usually things which are "no longer developed" do not have (at least) three implementations in development.
Mature projects often don't change much or quickly even when actively maintained or improved.
(i worked a _little bit_ on dwl) each wlroots upgrade is a pretty small diff on the dwl source. the annoying part is, as dwl is configured with patches, every patch author has to update their patch to the new 0.x, as dwl is quite minimal, and thus has no stable api. that being said, obviously, dwm doesn't have this problem :)
also, for dwl, the issue is that the initial author (not the guy that wrote that notice) is sorta mia, and he has control of the repo on codeberg, so we'd probably need to fork to be safe, and he may not want to take on project lead. (he checks every patch for merge conflicts with one another and upgrade breakages, god bless him lol)
> I said build on top of wlroots, not DWL.
Turns out, the wlroots API is so volatile atm that even the developer of the super small compositor DWL has to throw in the towel for now.
> DWL is more interesting as a learning exercise than something to use.
The same is said about DWM, its xorg counterpart, but I, for one, am a happy user of DWM.
Nearly every Wayland compositor is built on wlroots. Somehow they manage. But yeah, of course it's going to change more than X11, which is older than I am and more or less abandoned...
It's actively maintained by projects like RHEL which still have versions which are supported which in turn support X11.
Others are looking to run X11 wm under wayland with wayback, xlibre wants to keep it moving forward, and phoenix wants to replace it with a modern version.
This isn't what abandoned means.
No, I do not. I pointed out that with Wayland I'd be forced to. And DWL is an illustration of how much work that is relative to an X11 wm.
Why would I?
And DWL is not super small. It's hundreds of times larger than a minimal X wm, and couple of times as big as the wm I used.
And it's C. And it'd mean I would lose my session if I want to make changes and restart it.
What you're suggesting would be to put significant effort into replacing something that works with something that in terms of features I care about is strictly inferior.
Afaik Xorg is 'only' like ~500k lines of code, which is not huge by the standards of large porjects. In fact, one of the major counter arguments against Wayland, is that the compositor + a few core libs, like wlroots necessary to provide a similar set of functionalities, is already larger that the equivalent X11 code (which has a ton of unused cruft).
> like wlroots necessary to provide a similar set of functionalities, is already larger that the equivalent X11 code
I absolutely don't buy this.
You shouldn't, cause it's wrong.
libwayland is 40k lines of code. wlroots is 60k loc.
And just to check, sway is about 49k loc.
What's the simple way for a bash script to get the title of the currently focused window? In X this is easy and the bash script will work with every DE. In Wayland you have to write a different solution for each compositor/DE.. Prove me wrong, please.
It shouldn't be hard, all I want to do is fuzzy match window titles to named audio streams in pipewire, but "Oohh noo that's a security flaw!" say the patronizing Wayland developers who care more about making their own lives as developers simple than supporting basic desktop functionality.
> all I want to do is fuzzy match window titles to named audio streams in pipewire,
> basic desktop functionality
I feel your pain, but find your idea of "basic" functionality amusing.
That said, `pw-dump` / `pactl` will give you client names, which often match the window titles.
I know how to get the audio stream names, the problem is the window titles. With X it's easy, just call xdotool. I'm sure it's probably easy enough on Windows and MacOS too. Wayland is the weird one for making focused window titles privileged information.
Anyway, I do think I've created what should be considered basic desktop functionality here, a simple hotkey that mutes or otherwise changes the volume only of the focused window. Every desktop should have it.
This is just one of the tools I've made for myself with X which I do not want to do without and this makes Wayland a non-option for me. If I can't use X and can't replicate things like this with Wayland, then maybe I should switch to MacOS at that point because the dream of controlling my own computer seems like it's dying anyway.
Wayland is approximately correct in this case and Windows and Mac are behind the security curve for bincompat reasons; window titles certainly leak PII. There should be a way to do it, but it is sensitive information.
Sure, but again there's no interest in actually making a standard way to do it. I can understand it being something that arbitrary applications probably shouldn't be able to access, but that somehow turns into no way to do it, or complete fragmentation where every DE does it with arbitrary differences (or, more realistically, some DEs support it and others don't).
Okay; is there a way to do it? Can I, the user, decide that I do actually want a program to see titles? Or is it still impossible because 17 years isn't enough to implement utterly trivial APIs that people want?
Is there any documented attack on macOS or Windows that utilized window title information?
Never in history. If you have software running on your system attacking you then you have so many more issues than the adversary knowing your window titles.
> In X this is easy and the bash script will work with every DE. In Wayland you have to write a different solution for each compositor/DE.. Prove me wrong, please.
I don't know what you expect people to prove other than that X and Wayland both have the same problem but since X is so complicated there is only one implementation to begin with, which makes it look like X has solved the problem even though it suffers from exactly the same problem.
There are in fact multiple implementations of X and xdotool works with all of them. Typical Wayland advocate, doesn't know what the fuck he's talking about while telling people to just ignore the problems they have with Wayland, probaby because you don't even understand the problem in the first place. Why did you even respond to me? To insult me? To waste my time?
> There are in fact multiple implementations of X and xdotool works with all of them
Are there non-Xorg X servers for Linux that are usable? Asking because I'd like to try them if they exist
Look into river. It has the window management and keybindings able to be offered by other tools (I have an idea to implement one using XMonad's layouts).
It also vastly improved battery on my Dell Pro laptop. 58% battery used in 7h45m (light compilation day, but no suspend).
That sounds cool, but TBQH the last thing I want to do is make myself dependent on some obscure piece of tech I've only heard of once before (just now.) My plan is to keep running X as long as I can manage to make it run. If river finds traction and is well known to me in 10 years then I'll consider it then.
This is one of my big problems with Wayland; the fragmentation of Wayland imposes an unacceptable cost to picking the wrong DE, whereas with X all my tools for X still work regardless of my DE.
I don't have any interest in river. I have my own wm that does exactly what I want, so why would I switch?
Wayland doesn't solve any problems I have, and would create new ones, such as having to adapt to new tools or write my own compositor.
Battery life just isn't a relevant consideration for me.
Wayland made writing WMs needlessly hard, and the benefits of Wayland were frankly not real - most of the reasons given in 2011 were patched in to X11 later. All the Wayland rewrite got us was a situation where Wayland is both bleeding-edge and obsolete simultaneously. Say what you like about X11, but by the time people unironically pushed for mass Wayland adoption, X11 was stable and boringly so.
The future of WMs is, IMO, Arcan - https://arcan-fe.com/ - but that's an ambitious project and I don't blame the main developer for deliberately going out of his way to avoid advertising it before it's ready. In the meanwhile, Wayland and X11 both more-or-less work with the occasional major pain in the ass.
I think the problem is that people wanting to build that and being in position to (being paid for by their employer), are fed up with X11.
It learned no lessons from X11. It made most things harder to write and pushed more things that really every WM needs and doesn't care much to implement differently to WMs making them harder.
For example, stuff like "WM need to manage raw inputs, so they can have more power over them" is cute on paper but in reality most of them don't want to because there is no benefit to reinventing that part. Sure, that part in X11 could be better, maybe it should have better interface for WMs to configure common options in common way without getting into input-driver-specific options, but that just required rework of the idea, not throwing it into the bin and replacing with near entirely worse framework that wastes everyone time.
Tech is full of examples of 'successor' technologies, that were aiming to provide a clean rewrite without legacy, which then got bogged down with supporting a bunch of corner cases and accumulated their own share of cruft and could be no longer be considered a cleaner alternative. All the while the majority of the userbase being stuck on the old platform because the new one is buggy and doesn't offer anything tangibly better.
Vulkan, various node replacements come to mind.
Wayland at this point has existed almost as long as X11, longer if you only count the Linux years, yet its still not quite there.
Wayland and its various implementations like KDE plasma are 90% ready. Now they just need the other 90% to move from alpha to product. I expect it'll take another decade or two.
https://news.ycombinator.com/item?id=46382947
Read this including my response.
A lot of X features are actually Xorg features and they only work because there is a single implementation that everyone tried to integrate with.
Turns out the moment there are two implementations, which is hard on X and easy on Wayland, you can no longer rely on targeting a single implementation for direct integration anymore.
This means a lot of non-X but Xorg features need a protocol extension in Wayland, because things are being standardized that previously were exclusive to Xorg.
Are you saying that you can't get the title of the active window in X11 without using some features specific to the X.Org implementation?
It looks like the core X11 protocol spec [1] defines all that's needed, specifically the GetInputFocus, QueryTree and GetProperty messages. You might also want some things from the EWMH spec [2] (e.g. _NET_WM_NAME for UTF-8 or _NET_WM_WINDOW_TYPE to identify top-level application windows) but none of this seems like an implementation-specific X.Org feature.
[1] https://x.org/releases/X11R7.7/doc/xproto/x11protocol.html
[2] https://specifications.freedesktop.org/wm/latest/
> I think the problem is that people wanting to build that and being in position to (being paid for by their employer), are fed up with X11.
I think one of the intrinsic problems with relying on developers being paid by their employers is they can easily become personally disinvested from the thing they're maintaining; they get paid well, the day-to-day grind gets stale, they get interests and hobbies other than computing but keep working on the thing because it's their job. Eventually they find that just buying a Mac is an easier lifestyle at home, and gradually maintaining X transforms from something they do out of passion for the project into something which is just a job. So they look for ways to make their job easier, hit on the classic "instead of maintaining old thing it'll be more fun to make our own", and because they are now untethered from the needs of real users they only need to make sure the new thing supports the bare minimum to keep their employer happy. They no longer care how real users feel, any use case that isn't required in the checklists approved by management get deliberately abandoned. So we end up with Wayland lacking common sense desktop features in demand by users for years because it's simply not convienent for the developers who are now dispassionate 9-5ers.
I prefer to take my chances with enthusiasts keeping X working on shoestring budgets. Maybe a few more years of development of coding models will make ongoing maintenance easier going forward and I'll never have to switch. I'm willing to make that bet. If it turns out that in 5 years I am forced to switch, at least by then Wayland will be five years more mature, and maybe my cynicism will even be proven wrong by then and Wayland will be good by then (but I'm not holding my breath for that.) Anyway, I have nothing to lose by using X as long as humanly possible.
Replace "X" with anything and this is why i generally try to avoid relying on open source projects where the majority of the development is driven by some company if there is an alternative, even if they're jankier (and often they are).
One example would be Free Pascal and Lazarus, while there is some commercial support, the overwhelming majority of the development is community-driven and ironically both have a much better history of preserving backwards compatibility than most open source projects backed by larger companies.
Of course exceptions exist for both situations, but as a general rule i find if some project makes a big deal about the company behind them (or even worse, there is a company with the same name as the project) then i tend to look for more community-driven alternatives.
Yes, but I think in the case of Wayland also management had other priorities, i.e. GUI for mobile and/or entertainment systems.
But this is all ok, I think the main problem is that somehow too many in Linux community did not see that the technical arguments for Wayland were not actually too convincing and that giving up decades of compatibility across UNIX systems and beyond is a mistake.
It's a tradeoff, to be honest – I think of Valve's involvement with Wine, where a consistent source of $$$ and developer-hours was (and still is) needed to whack away at the open-ended problem of compatibility.
[dead]
> "most of the reasons given in 2011 were patched in to X11 later"
This definitely doesn't match my memory, and I was there :) Most of the good reasons remain unavailable in X11 to this day.
There definitely were some attempts to advance X11 that post-date Wayland, most notably the proposals by Keith Packard, but they never got much traction.
> This definitely doesn't match my memory, and I was there :) Most of the good reasons remain unavailable in X11 to this day.
You two here don't mention any of the reasons. It is hard to discuss this when there are no specifics, so what was needed, and what was not added?
Per-display DPI settings. No snooping on input without permission. Awareness of the lock screen (the compositor can know that the lock screen is active and provide alternate keybindings instead of having to configure the lock application as well). Locking is not blocked by context menus being open.
I ran XMonad for 15 years, but recently switched to river and am loving it.
> Per-display DPI settings
fwiw, Xorg already had this, since you can set the DPI for each display through RandR/xrandr. In both X11 and Wayland it's up to the toolkit to actually detect the setting and rasterise accordingly.
Wayland actually went backwards in this respect by using "integer scales" (eg, 1, 2, 3) instead of fine-grained DPIs (eg, 96, 192, 288), so using a scale of 1.5 would result in downscale blur (toolkit sees scale as 2, then the compositor scales it down to 75%), whereas in Xorg you could just set the DPI to 144, and the toolkit could theoretically render at the correct resolution. As far as I know Qt was the only toolkit to actually do this automatically, but that's not X11's fault.
Wayland has at least since fixed this in the form of "fractional scaling" [1], but here's [0] an old thread on HN where I complained about it and provided screenshots of the resulting blur.
[0] https://news.ycombinator.com/item?id=32021261
[1] Doing some quick searching it seems like this is still unsupported in Gtk3/Gtk4, maybe planned for Gtk5? Apparently Firefox has only just added support (December 2025), 3 years after the fractional scaling protocol was released. Seems ridiculous to me that Wayland failed to get this right from the start.
You can have different dpi and refresh rate per monitor in X, but you cannot do it while having a shared desktop across them.
X11 can do it. It's Xinerama that can't.
These days Xinerama is the only mainstream tool for dual head, but there used to be others. Nvidia Twinview was one. I bought my first dual head box in 1996 with two Matrox Millennium cards (although it mainly ran NT4) and those cards later went into my dual Athlon XP machine. That ran SUSE until Ubuntu came out.
Xinerama isn't a sine qua non. It's just easy so it became ubiquitous. Maybe it's time to replace it.
> As far as I know Qt was the only toolkit to actually do this automatically, but that's not X11's fault.
Well if three independent programs have to coordinate to make it work, then I would state that it do not support it at all.
It's the same on Wayland. The client (usually part of a toolkit like Gtk/Qt) needs to subscribe to notifications [0] from the server so it can decide the raster size of the surface it wants to draw to. Qt does this on X11 by detecting when your window moves to a screen with another DPI and resizing/rescaling.
I guess the "third" program would be something like xrandr, so the Wayland analogue to that would be wlr-randr (for wlroots compositors), or some other DE-specific tool for configuring screen sizes. Again there's no fundamental difference here.
[0] https://wayland.app/protocols/fractional-scale-v1#wp_fractio...
Is that any different from Wayland? I'm not opposed to declaring that Wayland doesn't support mixed DPI, but it is a funny conclusion
You can do per-display DPI just fine on X11 (through xrandr), it's just the major toolkits don't support it. GTK, for example, reads a single global DPI value from XSETTINGS; there's no reason why it has to be that way.
The annoying thing about the other things you mention is that they honestly are not that difficult to fix.
The X server can throw an error (or just silently ignore it) when one client passes the window of another client and button/key events in the mask to XSelectInput(). And the Xinput2 bits that allow for receiving all key and button events can be changed to only send events destined for windows in the same client. There: input snooping is fixed.
Lock screen awareness can be fixed with new requests/events in the MIT-SCREEN-SCREENSAVER extension (or, if that's fraught, a new extension) that allow an app to create a "special" lock-screen window, which the X server will always stack on top, and send all events to. (That new functionality should probably allow for child windows and popups for input methods as well.) This is honestly not hard!
And yes, some applications will break when you do this. But I cannot see how that's not significantly better than creating an entirely new display protocol that everyone has to port to.
There are other issues with X11, of course, mainly in the graphics pipeline (e.g. the compositor should really be in the X server), but it's hard to believe these things couldn't be fixed. It feels like no one really wanted to do that: building something new from scratch that (in theory) didn't have all of the mistakes of X11 would be more fun, and more rewarding. And I get that, I really do. But Wayland has created so much work, so many thousands (tens of thousands? hundreds of thousands? million+?) of developer-hours of work for people that maybe could have been better spent.
So I think Phoenix is a great idea. It's basically "X12"[0]: removing the old cruft and making breaking changes to fix otherwise-unfixable problems. I imagine most modern, toolkit-using X11 applications would work just fine with it, without modification. Some -- perhaps many -- won't... but that's ok. Run a nested, rootless X11 server inside "X12" if they can't be fixed, or until they're fixed.
[0] Yes, I know that an X12-type thing was considered and rejected (https://www.x.org/wiki/Development/X12/), but I still think it's a better idea, after a decade and a half of Wayland still not being able to support everything we need to port Xfce's components and maintain all of their features.
>You can do per-display DPI just fine on X11 (through xrandr), it's just the major toolkits don't support it. GTK, for example, reads a single global DPI value from XSETTINGS; there's no reason why it has to be that way.
I remember people complaining about the GTK file picker not having a preview for more than a decade, and at some point it sort of became a meme.
When it finally got added, the PR was like a 2-300 lines.
And was added after they rewrote everything for the new GTK version when there're functional patches adding thumbnails to previous versions. (Which were rejected/ignored because they didn't feel good.) A situational very in parallel to Xorg/Wayland if consider: https://news.ycombinator.com/item?id=46382940.
Does it really have to be said that a PR is built upon previous work. It was not a 400 line delta for the whole feature.
> It feels like no one really wanted to do that: building something new from scratch that (in theory) didn't have all of the mistakes of X11 would be more fun, and more rewarding.
My understanding from the outside is that this didn't happen, that Wayland is a spec without a reference implementation - that they didn't actually build anything and are leaving the difficult part up to everyone else.
They do have a reference implementation: weston and libweston but as far as I know, third parties don't use. They implement all their own functionality. Weston is confined more as a prototype.
If the issues are trivially resolved, why did the authors of X decided to abandon X? If the issues could be resolved, why were they not resolved? I am using wayland for more than 5 years now, it just works. X did not. Xscreensaver/lock screens on Qubes are still broken.
What features is Wayland the protocol missing to allow supporting Xfce?
> If the issues are trivially resolved, why did the authors of X decided to abandon X?
They convinced their employers Wayland would be better?
> Xscreensaver/lock screens on Qubes are still broken.
Most people aren't nation-state-level targets and don't worry about security to that degree. But they do like global hotkeys.
Even when you are national-state-level target, there are easier ways to grab the screen.
For local state, it's easier to just install a wireless camera and watch your screen from behind: it leaves no trace on your computer (you may spot it wireless connection, if you lucky). Moreover, they are more interested in your communication devices (your smartphone) than in your desktop.
Foreign states may exploit your notebook builtin "anti-theft" system, Intel Management Engine ("intel" is very good name for a CPU ;-), bugs in NVidia firmware (fonts, OpenGL, etc), bugs in hardware (create a second display to mirror image from primary display to, even when physical display is not attached, for example), etc.
However, I saw that my Firefox window was spied by Chromium window few years ago (I recorded it on Youtube), so this problem in X11 is real.
I am not sure what you saw, but on regular Linux processes of the user can spy on each other anyway. In any case, X had the concept of untrusted clients basically forever but nobody cared to invest even the small amount of work necessary to make it work well because nobody thought it would make a different. That this was later used as a major argument against X convinced me that this is not at all about technology.
Yeah, but with how we’re moving towards running each (desktop) application in its own cgroup, thus restricting what syscalls any given application can do, soon any old user process will no longer be able to read any other process’s memory. I don’t believe that the argument about how we need not patch a hole because another one exists right besides it is sound.
I agree. My point was only that this hole can easily be patched in X as well. So the argument was essentially "we do not bother to patch it with X, so we must rewrite X".
It was my understanding that changing the original codebase to fix it would’ve been involved enough as to warrant a rewrite.
I think this is nonsense.
I care about being able to use the same password between the display manager, tty and lock screen auth. Yet, I cannot.
I think the original maintainers and developers of Xorg would be the best people to choose if it is worthwhile to continue working around X or do something else. Yes, X provided functionality that now WMs get to implement themselves - since the developers of Xorg worked closer to Gnome and Qt people, and Gnome and Qt people were OK with this, this didn’t feel like a horrible trade off. And given the diversity of Wayland window managers today, I don’t think it mattered all too much.
What? My screensaver password is the same as my login.
> I think the original maintainers and developers of Xorg would be the best people to choose if it is worthwhile to continue working around X or do something else.
"I think the owners of the Internet infrastructure would be the best people to choose what websites I'm allowed to visit"
No, the users have spoken and continue to speak up that Wayland doesn't serve their use cases.
> What? My screensaver password is the same as my login.
It is the same, yet some uppercase characters are not supported when entered via a yubikey. This has been marked as a WONTFIX. This is rather sad, because I can enter the same password in a TTY with no issues.
What employers?
Also, this level of security is wanted even on a "I don't want my sister to look at my stuff" level, no need to go nation-state level.
Kristian Høgsberg, for example, was a Red Hat employee. Then he worked at Intel, where it appears he continued work on Wayland? So Red Hat and Intel at least? People are being paid full-time to work on Wayland, so those companies.
By now I am not sure if these posts can stil be given the benefit of the doubt or are just dishonest. Who were the developers pushing wayland because of their employers? Kristian Høgsberg (who was a significant xorg developer, because people always deny that wayland was written by xorg guys) originally developed wayland in his free time, it then became a freedesktop project (I would argue not a group run by corporates).
The most active implementation (particularly in the early days) is probably wlroots, started by Drew deVault (again in his free time), who is often quite vocal against corporate control.
In fact the large desktop environments, which are much more under "corporate control", were comparitavely slow to adapt wayland IIRC.
So instead of repeating this accusation, maybe actually give some evidence?
I didn't think my explanation implied how you interpreted it.
I thought everybody knew Wayland was started by some people working on Xorg already; I did not mean to imply otherwise. Many or all were paid for their work. They believed Wayland was a better approach, and, AFAIK, at some point switched to be paid full-time to work on Wayland instead of X. Which, sounds a lot like they convinced their employer (or a new employer) to pay them to work on Wayland instead of X. Do you believe this is a fair summary of the situation?
> I didn't think my explanation implied how you interpreted it. > > I thought everybody knew Wayland was started by some people working on Xorg already; I did not mean to imply otherwise. Many or all were paid for their work. They believed Wayland was a better approach, and, AFAIK, at some point switched to be paid full-time to work on Wayland instead of X. Which, sounds a lot like they convinced their employer (or a new employer) to pay them to work on Wayland instead of X. Do you believe this is a fair summary of the situation?
Sorry for my combatitive before. I definitely interpreted your previous post differently and I think your clarification is a fairer assessment of the situation. I would still argue that the majority of people implementing the wayland protocol are not paid by their employers to do so (this might now have changed a bit with smithay, which is sponsored by system76 I believe).
HDR something that can't be brought to X11 without breaking backwards compatibility.
https://github.com/reaperx7/HDR10-X11
First line of the readme: Non-functional implementation work-in-progress framework code for getting HDR10 working under X11.
The 3 justifications I remember for Wayland were security (isolating windows from each other), multi DPI, and eliminating tearing. All are now features of XLibre.
This is all playing a bit fast and loose with the details.
The "isolating windows from each other" stuff in Xlibre for example is the Xnamespace extension, which requires a static config file up front and lets X clients within the namespace interact as before. This may have some utility for specific scenarios (dunno, kiosks maybe?), but is nothing like Wayland's default security model.
Similarly, enabling TearTree in the modesetting driver and having another backbuffer in the driver is a huge crutch vs. having a proper architecture where the compositor can own presentation timing. For one it makes adaptive sync/VRR a lot trickier.
These things are overall not equivalent.
It isn't clear why any of this would require a rewrite.
At around that time X.org worked entirely fine for me, sans some NVIDIA driver config I had to set up in /etc
few years after even that wasn't required.
Yeah it missed some features I could theoretically use in 2025 but I didn't had different DPI/refresh rate displays back then and those could probably be put into X11 protocol just fine
Let me know when X11 handles fractional scaling across mixed dpi and refresh rate monitors, with HDR and VRR. To me, who has finally been able to drop Windows for gaming in the last 3 months, the benefits of wayland are very real.
Technically Xorg can handle fractional scaling across mixed dpi and refresh rate monitors, but it requires support from toolkits, window managers and applications which means the developers of all of those (or at least toolkits and window managers) need to cooperate. At minimum, you need toolkit support for the most basic. AFAIK Qt6 does have this support and should be able to handle fractional scaling across mixed DPI monitors but not in an ideal way since for better experience you'd need the app/toolkit cooperating with the window manager instead of the toolkit trying to do everything on its own without knowledge of the rest of the desktop. I wrote about it in detail here[0] but the gist is that it is largely an issue of getting the developers of various projects to cooperate than some feature Xorg itself lacks (it doesn't). Wayland had it easier here because it started from scratch and developers had to worry about those things for supporting it. On a more positive note, because of Wayland (and Win32, if a toolkit support scaling there) the the hard part of the work on the toolkit side should already be there.
For VRR the issue is how current desktop compositors render their output, though it should be technically possible to make a Xorg desktop compositor to use separate outputs for each monitor (may need to use Vulkan with custom barriers for vsync though, this is something i've only ). The alternative is to not use a desktop compositor at all, which is what i'm doing (since i also dislike the desktop lag introduced by desktop compositors). I have a 165Hz VRR monitor that i used it for a bit (even connected a separate 60Hz monitor for a bit) and worked fine, though eventually i disabled the VRR functionality since at 165Hz tearing is almost imperceptible (and it never bothered me even on 60Hz monitors anyway) while my monitor is one of those that have some annoying flickering with VRR enabled. In any case, the issue is with the setup and desktop compositor used, not with Xorg itself.
Of course from a user's perspective all these most likely do not make much of a difference.
For HDR there is no support for it Xorg though. Personally, the main use for HDR would be either some movie or playing a game, i.e. fullscreen apps, and switching to another virtual terminal running a Wayland compositor (or just Gamescope) just for those is perfectly fine - having to press ctrl+alt+f1/f2 instead of alt+tab is not a deal big enough to change the entire desktop setup i've been using for many years :-P.
[0] https://news.ycombinator.com/item?id=45858043
HDR support is still a mess with Wayland. Sometimes you can fix it with gamescope but it’s a swiss cheese thing where for example gamescope breaks some controllers in some games with some GPU drivers. Maybe in a couple more years it’ll be “it just works” territory but it’s taking a while to get there.
Thanks for linking Arcan, looks interesting.
After a quick scan, Arcan seems to be pushing a microkernel approach, with some clients providing display server capabilities and others talking to them via shared memory. This will have the same problem as all other microkernels - nice for research, but the extra completely outweights the marginal benefits over a monolithic thing that generally has a smaller API surface to maintain.
First time I've heard of Arcan. Sounds intriguing.
IMO, if you have to rewrite a display server implementation then you're already proving all the protocol advocates right.
Why? People complain that the YAML specification/protocol is too complex. This may be, but I found using YAML much, much easier and nicer than XML. So to me these two things are not necessarily interconnected. You can have a great implementation and a crappy protocol; but also a great protocol and a crappy implementation.
[dead]
The people who absolutely have to have X11 like myself usually have reasons. It sounds like currently a lot of those reasons for using X11 would prevent using this X server. Like reliable non-fragmented and widely supported screenreader protocol. Or the ability to do keyboard and mouse sharing.
>Applications will be isolated from each other by default and can only interact with other applications either through a GUI prompt asking for permission, such as with screen recorders, where it will only be allowed to record the window specified or by explicitly giving the application permission before launched (such as a window manager or external compositor).
Accessibility? Sure. Everything else? Nah, I'm sorry. There are countless ways to do remoting with Wayland. There are countless ways to do kb+mouse sharing.
I love Wayland a lot, but as far as I can tell the available remoting solutions still cannot enable a headless LXC container to serve a KDE Plasma Wayland desktop. I spent the last couple days trying to cobble some solution together for it and failed miserably. If you know a way, I would be most grateful :-)
Me too!
>There are countless ways to do kb+mouse sharing.
You realize that's worse, right? And to be clearer: core Wayland protocol does not have countless ways. It has zero.
Instead of a single protocol with the strong X11 reference X server the wayland compositors pick and choose between libinput, or libei, or libportal with the InputCapture PR, xdg-desktop-portal with the InputCapture interface, some I've probably missed, or maybe you have nothing at all (weston). It's a gamble if your choice of desktop environment and it's wayland compositor's non-core wayland protocols will match up with those the developer for $software chose. On X11 linux everything that works somewhere works everywhere. With the various waylands if you stay within your desktop's ecosystem you'll probably not notice, but go beyond it and you will.
Each wayland desktop pretty much runs it's own compositor with it's own set of third party libs because the wayland core protocol spec is very minimal. I would say incomplete. ref: https://wayland.app/protocols/
The point of the protocol spec being minimal is that it enables a wide variety of implementations, something it definitely succeeded at.
I still don't know how people twist this obvious success into a failure.
Xorg fans reverse all the normal Open Source logic.
Imagine we were talking about web browsers…
There should only be one! No security makes all my extensions work!
Imagine if web browsers all had mutually incompatible DOM implementations for basic functionalities.
That's the situation with Wayland that people are complaining about. I don't need innovation in keyboard and mouse sharing, I need it to work.
I mean, at least with web browsers they usually converge on a common spec eventually, and most of the time you just have a bit stupid repetition in your CSS for a bit. Wayland compositors seem to be actively against this kind of process.
It's a very forced comparison trying to swap in the web's security model, where one runs untrusted code from arbitrary third parties automatically, for a personal desktop computer context where a single user is in complete control.
Uh... lived experience? Try getting keyboard and mouse sharing working across all the waylands with the same software. Not having most of the features in the standard implementation leads to fragmentation which apparently you haven't run into with your use cases yet.
That wide variety of implementations is a big part of the problem!
> There are countless ways to do kb+mouse sharing.
Wait, what? I tried this last year. I didn't find any way to do this that wasn't dependent on the WM.
Until Wayland actually has an accesibility story, X is really the only choice. Don't think most grassroots projects will have that.
Isn't accessibility outside of the scope of Wayland, whose purpose is to composite application buffers, and deliver input events?
Something like a screen reader needs to talk to an app and query the toolkit for the contents of a window in a semantic way - that's a toolkit feature not a compositor one.
What does this matter for blind people who want to use Linux? All that matters to them is that it's super complicated and nobody wants to work with the tech to make screen readers work on Wayland.
To my knowledge, X11 didn't offer a comprehensive accessibility API either - there's no Linux equivalent of stuff like MS Active Accessibility or MSUIA on Linux.
Even back then Qt, GTK and everyone else offered their own API and screen readers needed to integrate with every single one - this didn't really change under Wayland, only the sandboxing makes certain operations harder, but the accessibility story on Linux is not great, and never was.
The standard was Extended Window Manager Hints [0].
Above X11, implemented by GTK and everyone else. Right.
However... Wayland makes it impossible to implement EWMH. Which means the enrire EMWH standard needs to be tossed, and everyone needs to make something new.
You can't even get the title of a window, under Wayland. That's private to that process tree.
Wayland requires accessibility be implemented at the application level, not the window manager. And thats guaranteed to make it always broken for a majority of use cases.
[0] https://specifications.freedesktop.org/wm/latest/
pretty sure at-spi is independent from the display server
Parts of AT-SPI are impossible to implement under Wayland.
> Wayland has no concept of global coordinates or global key bindings. The protocol itself is designed around atomicity which is a nice concept, but is fundamentally in conflict to the need of assistive technologies to control the entire state of the desktop globally. As such, atspi methods like get_accessible_at_point are impossible in Wayland.
https://news.ycombinator.com/item?id=45237411
Long term if x11 starts having issues then probably https://gitlab.freedesktop.org/wayback/wayback will be it
> which allows for running full X11 desktop environments using Wayland components
Wait so is this turning Wayland into a client/server model like X11, where eventually it could support existing window managers and other stuff separate from the compositor?
I remember a year or two ago wondering if that would ever happen and I think I only got one reply saying it wouldn't happen because it was unnecessary.
Yes basically. It's one full screen xwayland context you run a normal x11 wm in
Long term? Perhaps, if successful. I am hopeful.
But, right now, XLibre[0] is available, ready for use and very active.
0. https://github.com/X11Libre/xserver
Just got a major release as well with tons of new contributors and fixes/additions: https://github.com/X11Libre/xserver/releases/tag/xlibre-xser...
I’m not sure this satisfies X11 needs without remote display capability.
I WANT to use X11, its simply better than wayland
Rewriting it from scratch is so very rarely a better plan than improving what you already have.
Why a new incomplete implementation would be better to use than a project that is stable, full-featured, and with a proven track record?
My rpi dashboards are gonna love it
Anything special about Raspberry Pi's that require X11? Raspberry Pi OS defaults to Wayland nowadays, and there's specific kiosk Wayland compositors like Cage (https://github.com/cage-kiosk/cage).
Tho admittedly kiosk-wm (https://github.com/JOT85/kiosk-wm) is much more succinct.
I write dashboards using X11/OpenGL for displaying otel metrics.
GLFW for my window library.
Wayland is overkill.
I would go straight /dev/fb if it meant I could also antialias and make it pretty and didn’t need a cursor.
less RAM and power usage
Well there is XWayland then.
Depends why you need it. XWayland is worthless for a11y.
Arguably, there is no sane a11y on GNU/Linux anywhere.
iOS/Mac/Android is on completely other level.
It's not a single thing. Trying to get a screen reader on GNU/Linux is awful. Getting dwell click is easy on X11 and... some Wayland implementations. Or if you like: It was bad on X, and is worse on Wayland.
People who want to use X11 are likely to be the same people using older software and hardware, which this doesn't support.
I don't use any old hardware, and I have argued for a new X server following almost exactly the steps this project outlines.
Good news. The devs of x11 agree and made a replacement called... Way... Oops
"The devs of x11" is a wide category, considering how many X11 devs weren't even born when X11 was first written. Plenty of X11 devs objected to Wayland and tried to patch X11, but when half the devs decide they want to write a replacement and put the original into maintenance-mode, there's not much you can do.
> there's not much you can do.
You could fork it. X11 hasn't shipped a major release since 2005, the likelihood of a complete overhaul making it upstream was slim to none even in 2009. X11 developers were better-off focusing on stability, and the Wayland devs moved on. There was no conspiracy to kill either project.
Forking a project when the issue is that half of the staff left the project does nothing to alleviate the staffing issue, does it?
So what is it, in one comment you say there were plenty of x11 devs who objected to wayland (please name and show the posts) and on the other hand you say there were not enough to keep an xorg fork going?
People are arguing that fixing the issues in X11 would have been much easier and less work than making wayland. So why could those half of x11 developers who left make wayland while the other half that was left over could not even make one release?
Isn't that the greatness of FOSS over commercial software that keeps being spoken about?
and failed to learn any lesson from X11
Yeah, no, the X11 devs made pretty much all the wrong tradeoffs for me.
I wonder why Valve disagrees.
Valve ships a Wayland compositor that just runs XWayland for apps and doesn't even expose the Wayland socket by default. I'm really not sure how we're supposed to count that.
Valve being eminently pragmatic, as usual.
Presumably Valve cares about different things than me.
I wonder why you think what Valve does has any relevance to my experience or priorities.
[flagged]
> by itself it looks like a fairly reasonable set of choices.
I have not tried this myself, so I can not speak from experience, but if they have removed features that people used, then they are in a similar situation as wayland. So I don't see what the difference then would be. Perhaps your analysis was also incomplete?
I consider Wayland's choices reasonable as well. I.e. I it's not surprising that a reasonable attempt to clean up X ends up looking similar to Wayland, just in a slightly different place on the xy graph that has backwards compat and cleanup as its axis.
The thing is, X11/Xorg is a huge monolith. There is simply no way to implement every single feature in one go and then release the competing implementation.
The very thing that makes people biased towards X11/Xorg both negatively and positively is that it is a huge monolith and the only X implementation on Linux. The moment you have two implementations, you're gonna get the same complaints against the second X server as Wayland is receiving.
You think this is an indictment to the second implementation and that they shouldn't bother by saying an "analysis was incomplete" but in my opinion it's exactly backwards. This is an argument that eternally perpetuates X11 not because of technical capability but rather because it was there first.
After all, the moment there is any implementation that is second it might miss a single feature that nobody actually uses, but theoretically could be used when combining an old binary with a new X implementation.
But this argument misses the obvious fact that X11/Xorg is already dead since any code change will break existing applications. Meaning X11 has become an unsalvageable fossil.
The Linux kernel is also a monolith yet has worked forever without a rewrite.
I think there is a reasonably agreed on set of things that can be removed from X, like server-side drawing primitives, and GLX
The Linux kernel was not born obsolete on arrival like the X Window System was. At least, not fully obsolete.
It will be obsolete someday, anyways.
“Obsolete” means that a replacement exists which is as good as, or better than, the thing it aims to replace, in every significant way.
X11 is far from obsolete.
In what way was X11 obsolete in 1987?
Funny, the other day I started writing an X server of my own. While I appreciate and welcome this work, I still use and write software that makes use of old X draw calls, which I intended to incorporate into my server, unlike the author of this work. So I'm glad to see my efforts have not been made largely redundant!
I'd at least consider moving older draw calls into an xlib replacement. Not all of them are suitable for that, but e.g. sufficient font handling to beat Xorgs server side handling requires the Render extension plus ca. 1500 lines of C for a basic TrueType renderer, or half that in a higher level language, or just use FreeType which is a dependency for most X clients anyway.
It's just a hobby, won't be big and professional like Xorg. Aiming for as much protocol completeness as I can manage within those constraints.
Tangentially related... Is it just me, but is Wayland still lagging behind X11? From things like window placement, night light, etc. Things seem to work just out of the box in X11, and there are always issues in Wayland.
(For me this is specifically on Fedora, and I always switch back to X11 from Wayland.)
Well, isn't this compositor related? I've never had any window placement issues running Sway (i3 for Wayland). I never used night light on that machine, so I can't comment on that particular point, but the thing seems to work just as well as i3.
The only problem I have is with JetBrains IDEs, which seem to have shaky support. They're usable (meaning you can code), but the experience is so wonky that I basically consider they don't support Wayland.
The reason I switched from i3/x11 is that we've got some 27" 5k screens at work that are basically useless at 100%, and Sway handles different scaling settings flawlessly (except for IntelliJ, which seems lost).
Wayland intellij ide support is in the works, IDEs support X11 out of the box, but you can enable Wayland support explicitly (just search for it).
As per Windows placement, Firefox won't restore windows on original positions supposedly because of Wayland, somebody please correct me if I'm wrong.
Intellij kinda supports Wayland, but it gets confused when using scaling, at least when not all screens have the same factor. It's not blurry or anything, but it's slower, and the menus sometimes appear in random places.
When I only use a scaling factor of 1 on all the screens, it's usable enough, although it still feels sluggish.
You are not wrong. But there is a new extension protocol on the way (dunno if done, very probably not rolled out if it is) that let programs solve this problem.
Uh, there are plenty of extensions. Session management perhaps? In experimental state.
Uh, was thinking of one that explicitly deals with window positioning of new windows.
Using kde on Wayland for a while now, on a Nvidia card (debian trixie, just upgraded to forky a week ago), and i can't relate to any of those issues. My only complaint is a silly kernel module warning that pollutes my syslog.
At this point it is just you.
I run two different distributions myself, I know a bunch o people on even more different distributions, set of configuration and based on empirical analysis I can assure you that no one has problem with windows placement.
Out of the box I used have more problem with X11 (tearing and font rendering being the most annoyingly common ones) than I have with Wayland.
It's not just him, but for something else. HiDPI, Ubuntu 24.04, try OnlyOffice or VMWare Workstation. Both don't scale well. I assume other applications also don't scale well. Had to use X. And the scaling isn't even fractional, it's 2x.
It's not just him. I've had issues with windows popping up on the wrong display and also their scaling. Works without issue on X11; and I don't even know where to start looking on Wayland.
A lot of people would have preferred this to Wayland if it had come much earlier.
If it also runs Wayland apps, many may prefer it actually.
wondering who those people are given that Wayland was done by xorg devs
Users? Obviously xorg devs want to work on something that isn't ancient and crufty. But users want something that actually works and it has taken almost 2 decades to get to that point.
Actually I still have more issues on Wayland than X. Although it is at least starting to swing in the other direction - e.g. KDE's screen recording feature doesn't work on X. The button's still there but if you click it nothing happens.
Most users have no idea what is behind. They don't want X or anything X related, they want things to work. Most of the things worked before 2020, including legacy things through xwayland. Now all things work, except maybe remote apps through ssh ootb, but for this you can either use RDP or Waypipe.
The only thing maybe worth discussing is video acceleration. this aside, I have been using gnome on Wayland for years and no problems what-so-ever. I really don't know what the fuss is about.
I would prefer that people start moving this legacy nonsense behind and finally start accepting new and better things and focusing on things that have future. Same thing happened with systemd, it improves massively everything Linux, yet some people just want their services started with scripts.
What problems do you have when things don't work for you on Wayland?
Wayland:
* straight up doesn't work on at least one of my laptops (driver problems AFAICT)
* does run on the other one, but crashes at an alarming rate compared to Xorg
* breaks all of my accessibility tools (some have (worse) replacements, some don't)
what laptop? what hardware?
here is my state of laptops:
* Dell latitude with old Intel 8gen CPU, it works fine (Linux kernel causes problems with PSR, but this has nothing to do with Wayland and disabling it fixes the problem, same thing with cstates)
* Dell latitude with 10gen CPU, works fine.
* Huawei d15 with Ryzen 3000 Apu, works fine.
ok. for accessibility it's fair enough as a critique. I don't use it so can't say. As far as I can tell this hasn't been in focus at all. but most of this is on the toolkit side, not Wayland (even though here one thing is mentioned as Wayland specific, just briefly went through the post)
https://blogs.gnome.org/a11y/2024/06/18/update-on-newton-the...
> what laptop? what hardware?
Does it matter? Your claim is that everything works, and I am here to tell you that I am a real person running real machines that do not work. Unless you're planning to fix the particular bugs and missing features that I'm hitting I don't see where the specifics actually matter. (Anyways, the first machine is a https://wiki.archlinux.org/title/Lenovo_ThinkPad_T490 with Intel graphics; this appears to work but is less stable than Xorg. The second machine is a https://wiki.postmarketos.org/wiki/Lenovo_IdeaPad_Flex_3_Chr... that doesn't run Wayland at all, which I grant is bizarre since the stock ChromeOS uses Wayland. You are welcome to point out that this is more than a little off the beaten path, at which point I will of course point out that Xorg somehow handles it just fine.)
> but most of this is on the toolkit side, not Wayland (even though here one thing is mentioned as Wayland specific, just briefly went through the post)
It varies; a11y isn't a single thing. Deep application integration to allow eg. screen readers to work well probably needs toolkit integration. But there are also things like dwell click, which is really helpful when my RSI is flaring up. In X, I just run `mousetweaks --dwell` and it works, and it works in any window manager or desktop environment, with absolutely no help needed from toolkits or applications. In Wayland, it's sometimes available on a per-compositor basis, which I would describe as purely inferior. On which note, observe that you've linked a blog post about a prototype for GNOME. They note that they're open to working with other desktop environments, but 1. that means it doesn't exist as of that blog post, and 2. I've seen how GNOME operates over the years; I fully expect portability to be a very distant second priority, and whatever they export will be an attempt to force everyone else to do everything the way GNOME does, which will go poorly. I have no interest in ever going back to GNOME, so the actual takeaway, AFAICT, is that the a11y situation on Wayland is bad and will remain bad for the foreseeable future.
fair enough.
if this is so, I can admit I'm wrong. so not everything works for everyone.
For myself and members of my family, I can say that absolutely everything works on gnome. And I have several machines, spread over several cpu and gpu generations, and different form factors that confirm this. not only those 3 laptops I mentioned.
Could it be that since you are not using gnome that you are hitting those problems? My experience is exclusively gnome, so maybe this is it?
a11y aside of course... given that this was not really finished. or seriously worked on.
Thanks.
It certainly could be GNOME vs not-GNOME. That doesn't really help me, either way, but it's not hard to imagine that different compositors have entirely different quality levels.
if you ever come into a position that you could try or would like to try gnome, I would encourage you to do it. maybe you could eliminate that bad opinion of Wayland (or confirm it)...
yes gnome has a vision of how the desktop should look like and strong behavior of "my way or the highway", but maybe you get surprised how well it works. especially on fedora.
I assumed wrongly other people (you mostly) use gnome by default, which obviously is not the case. in that case I could see it as a problem since not everyone has red hat resources for desktop development.
HiDPI scaling (not even fractional, 2x aka 200%), for some apps like OnlyOffice, VMWare Workstation, but not only, on Ubuntu 24.04. Had to switch back to X.
You can blame the apps all you want, but it's a fact of life, and Wayland has been around for 18 years.
At this point you'd hope they'd pull an early 90s Microsoft: https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii...
I don't know how you can read about the many experiences people have with Wayland not working - even now, let alone 2020 - and conclude that "all things work".
I think we are finally at the point where you can say most things work and it's silly to go back to X11, but even so Wayland has clearly been a huge failure.
[dead]
The name Phoenix is overused. There is an Elixir framework called Phoenix. I think I also heard of other projects with that same name before.
It's a bit like the name 'Apollo'; besides the moon landing project, I know like 2 dev projects called that and also there is a sales SaaS platform with that name.
Surely people should run a search first before choosing a name...
From the ashes of some previous project is born some new project.
It's symbolic.
I remember people naming new software projects this back in the 1980s for the same reason.
We get the symbolic reason. It’s still overused and lazy because it doesn’t even relate to the project itself except for its origin in the most generic way.
They could at least use PhoenX or FenX to link it with X
It's a great name but way overused. I guess everything these days rose from ashes of past failures. Sector is highly competitive.
Ya, and that's the same reason all those other projects picked this name too
Not in the case of Elixir. It’s a play on BEAM processes being revived.
Remember when every project acronym used to be YA-something for “Yet Another…”? Or when recursive acronyms were the hot trend?
Don't forget startup names that randomly dropped vowels. I don't miss the days of twttr.
I can second the Apollo thing. I think it might just be a natural name to give something, because when I was a kid I was working on a voice assistant thing instead of touching grass (never finished it) and called it Apollo. This was probably my first project.
I think all the cool one-word names are used, and overused, by now.
How many X servers named Pheonix are there? Surely it doesn't matter if there are frameworks and libraries of the same name in other areas. It's inevitable to have collisions like this.
Firefox tried to use it and was sued for trademark infringement. wxPython also has a Phoenix project. It's definitely a catchy, but overused, name.
I don’t think the problem was with “phoenix”.
It was Project Phoenix (resurrection of the Netscape browser). This resulted in the Firebird browser (Firebird and Thunderbird). But Firebird was an existing database that objected to the name. So, we got Firefox instead.
At least that is how I remember it.
Wasn't it renamed because of these people? https://en.wikipedia.org/wiki/Phoenix_Technologies
Yes, and that was just the start lol... https://www.zdnet.com/article/mozilla-holds-fire-in-naming-f...
Yeah, me too. https://website-archive.mozilla.org/www.mozilla.org/firefox_...
https://www.zdnet.com/article/mozilla-holds-fire-in-naming-f...
All the first 3 names were taken. They probably had to bribe even the holders of the Firefox trademark to get it (though the terms were never disclosed).
Mozilla was sued to rename Firefox (like I said) by one Phoenix Technologies. If I remember right, they picked two bad names before picking "Firefox" but I don't remember the other one.
Firefox was Firebird, not Phoenix.
I think Firebird was the second name they tried to use that was already taken. They were definitely sued by Phoenix Technologies for one incident. Bryan Lunduke has a podcast explaining the history of this but I saw the one about Phoenix on the Wikipedia page before posting.
Edit: Here you go: https://www.zdnet.com/article/mozilla-holds-fire-in-naming-f...
Phoenix in the Elixir ecosystem is probably one of the less confusing name uses. Under that stack you get such clear library framework names as: bandit, cowboy, thousand island, and ranch. As well as mint and finch. When not riffing off of previous project names with off axis alternate names, it’s always some sort of ExThing sharing space with at least 3 other varieties of the same (e.g. ThingEx, Thingx, and ExaThing), and you're left guessing which one may have emerged as a conventional standard.
Better not ask them to think outside the box or they'll come up with something like fushichou.
There’s an AI coding tool called phoenix.love as well
This is a great project! I like and use Wayland but the portal protocols and extension mechanism does leave a lot to be desired. Wayland is still quite a way behind Windows and macOS in terms of what productivity users need
An X11 rewrite with some security baked in is an awesome approach. Will be watching!
I thought for a long time that rather than move to Wayland, we could come up with a tidied-up version of X. Sounds like a good and useful project, I hope it progresses.
I thought this too and originally thought that’s what Wayland was going to do but it went off and did its own thing.
I’m all for an X12.
An X12 was briefly considered by the community before adopting Wayland: https://www.x.org/wiki/Development/X12/
If you take the time to read through that (very partial) list of cruft and footguns in X11 it probably makes it a little easier to understand why a clean-slate approach was able to attract momentum and why many hands-on involved developers were relatively tired of X11. Critics would of course respond that backwards compatibility is worth the effort and rewrites are often the wrong call, etc. It's the Python 2/3 debate and many others.
Realistically rewrite would keep X11 compatibility layer and just do same wayland did, make new protocol.
Just... without all that mess that turned out to be at best +/-, at worst outright negative causing problems for everyone involved. And near all of the "advantages" are "the server is built from scratch" not "the protocol was the limitation"
Python 3 was actively antagonistic to Python 2 code for no reason other than to lecture us about how we were doing things wrong, writing code to support 2 and 3 to help transition was dumb etc etc.
For example, in python 2 you could explicitly mark unicode text with u"...". That was actively BLOCKED with python 3.0 which supposedly was about unicode support! The irony was insane, they could of just no-oped the u"". I got totally sick of the "expert" language designers with no real world code shipping responsibilities lecturing me. Every post about this stuff was met by comments from pedantic idiots. So every string had to have a helper function around it. Total and absolute garbage. They still haven't explained to my satisifaction why not support u"..." to allow a transition more easily to 3.
Luckily sanity started prevailing around 3.5 and we started to see a progression - whoever was behind this should be thanked. The clueless unicode everything was walked back and we got % for bytes so you could work with network protocols again (where unicode would be STUPID to force given the installed base). We got u"" back.
By 3.6 we got back to reasonable path handling on windows and the 3 benefits started to come without antagonistic approaches / regressions from 2. But that was about 8 years? So that burnt a lot of the initial excitement.
> Python 3 was actively antagonistic to Python 2 code for no reason other than to lecture us about how we were doing things wrong, writing code to support 2 and 3 to help transition was dumb etc etc.
> [...]
> By 3.6 we got back to reasonable path handling on windows and the 3 benefits started to come without antagonistic approaches / regressions from 2. But that was about 8 years? So that burnt a lot of the initial excitement.
So it's a great analogy. Wayland started out proudly proclaiming that it intentionally didn't support features in the name of "security" but everyone should "upgrade" because this was totally better, and has been very slowly discovering that actually all the stuff it willfully dropped was useful and has mostly evolved back to near feature parity with Xorg.
Uhm no? As I mentioned, Wayland is simple because it was designed with the idea that there will be many implementations. It turns out that once you have many implementations, you can't just implement screen recording in one implementation and directly integrate with that implementation, because someone might use a different implementation. This then necessitates extensions for features that go beyond displaying things.
There’s a reason they’re called Pythonistas
It’s always drama and they’re the center of it.
(I’m joking of course, Merry Christmas)
Python is really one of the worst designed languages. It always baffles me that people recommend it to beginners.
15 years ago I tried it and got that path error. 1 year ago I tried again and still got the same error. I'm well aware that it's simple enough to fix. But I was baffled that the same error was still there.
I dunno there's a lot to pick from when it comes to "worst designed"!
It's definitely not well designed though.
And I agree about recommending it to beginners. Sure, a for-loop and a simple function look very friendly and easy, but good luck explaining to them why they can't import from a file in a different directory...
Except for all the others (that anyone uses)…
I’ve been here since the beginning.
I remember Usenet.
X11 was built for multi-user terminals a kin to today’s Microsoft VDI garbage.
There’s some good. A lot of bad. And some WTF in there.
Be the change you want to see.
Also happy winter solstice.
It was always an option, but "just" needed someone to dedicate all their time to it and pull in a group of long term maintainers. The real question is what will happen with the project in 2 years and will it be stable for day to day use.
The fact that you can "assume Vulkan exists" helps a lot (both hardware and software renderers exist). Do remember--Wayland predates Vulkan by almost a full decade.
In addition, you can offload OpenGL compatibility to Zink (again leaning into Vulkan).
> pull in a group of long term maintainers.
"Use new cool language" seems to be a prerequisite for this nowadays ...
At least Zig is very compatible with C.
You can't "assume Vulkan exists". Any pre-2016 hardware won't have proper hardware support for Vulkan and that's a lot of hardware still in use. Software renderers are unworthy of any serious consideration due to the perfomance drawbacks.
Just use OpenGL. I don't know when this trend to overcomplicate everything using Vulkan began, but I hate it.
Nvidia had a driver for Vulkan for Kepler which launched in 2012, AMD had support all the way back to GCN 1.0 (also 2012). Intel did have issues supporting it, I can't recall if it was for hardware reasons or just lack of desire for a driver.
Vulkan has substantial advantages for multi-threaded code, as well as exposing the underlying asynchronous nature of running code on the GPU. The kind of thing you want to be able to control with a desktop compositor where controlling vsync and present timing is very important.
There are Xorg and XLibre for pre-2016 hardware.
I don't really understand what is supposedly missing in Wayland for productivity users? At work I have been using gnome with the wayland backend for years at this point and I can't really figure out anything that's missing.
Accessibility is apparently a big problem with wayland. E.g., the most popular / ?only? app that supports hardware eye trackers on Linux does not work with wayland, and states that it likely never will as wayland does not provide what it needs to add support (it is also the most popular app for voice/noise control). Even basic things like screen readers are apparently still an issue with wayland. Without a strong accessibility story, systems running wayland would have been banned at my last employer (a college).
Personally, I have a 3200x2400 e-ink monitor that has a bezel that covers the outer few columns of pixels. I use a custom modeline to exclude those columns from use. And, a fractional scaling of .603x.5 on this now 3184x2400 monitor to get 1920x1200 effective resolution. Zero idea how to accomplish this with wayland-- I do not think it is possible, but if anyone knows a way, I am all ears.
I ran into, at least, ten issues without solutions/work-arounds (like the issue with my monitor) when I tried to switch this year, after getting a new laptop. Reverted to a functional, and productively familiar, setup with X.
I don't know about other DE, but at least with Plasma there is a "overscan" option to compensate for hidden borders.
Thanks for that.
Overscan is not supported in wlroots yet. Seems the issue is that handling overscan is display driver specific.
But, now I know the keyword to look for.
The xdg-desktop-portal stuff is still too immature. For example, my friend wanted my help after upgrading his Pop_OS to 24.04, and 24.04 replaced GNOME with COSMIC. COSMI had no RemoteDesktop portal (and still doesn't have it), so we couldn't use RustDesk like we always did without him installing a GNOME session just for that.
I've been an i3 user for almost two decades, but eventually switched to Sway - to this day there's no InputCapture portal, so I can't use Synergy with Sway, forcing me to switch to i3 while I'm working.
It's been over 10 years of things like that. There's always SOMETHING missing.
Screenshots are just completely broken. People always tell me to use other apps like flameshot but IME it just doesn't work and I don't want to have to mess around so much to take screenshots.
I'm still using Wayland because it's what came with my distro (endeavour OS, gnome), but it's really strange how it came broken out of the box.
I'm curious what OS you are running that has broken screen shots on wayland because that hasn't been my experience on Fedora.
It's right there in my comment
Yeah, my bad sorry.
Headless remote desktop, at least for KDE, is very much not possible today as far as I can tell. It's the last thing I miss from Xorg.
FWIW, like everything else in Wayland, it's per-compositor. Here's a working headless sway in a container:
https://gitlab.com/yjftsjthsd-g/docker_sway-vnc
(This is not a defense of Wayland, just trying to share useful information)
Hmm, you mention in the README that it only works in a privileged container. This of course negates the security benefits Wayland supposedly has over X11, so it doesn't seem ideal.
It really doesn't. The security benefits of Wayland are about isolating applications from each other, which this still has.
Also that's only really relevant to this running in a container. My point was that you can have headless Wayland.
>what is supposedly missing in Wayland
My desktop is a bit long in the tooth (22.04), but I've long given up on trying to screen shot or screen share from Wayland. I have my Macbook sitting next to it and use it for those things, where it works basically flawlessly.
Kind of waiting for 26.04 to upgrade at this point, but I'm not really expecting any of this to be better yet.
edit: If I had it to do over again, I wouldn't have gone Wayland at 22.04.
I'm running fedora and have been screenshoting and screen sharing (with the teams PWA) just fine. So might be time to get something newer.
What keeps you from going to Ubuntu 24.04? I have been screen sharing and screen shotting on Wayland (Gnome and KDE) without problem.
I am on KDE never had any problems taking screenshots.
Autoclickers and screen macros on Wayland are all janky
> Wayland is still quite a way behind Windows and macOS in terms of what productivity users need
What's missing?
Window positioning? You cannot position the window, you cannot send a hint, nothing? So my pop-up with GTK4 will randomly be placed somewhere, anywhere, without any control. OK, GTK4 went further and also removed popups without the parent, so you hack that with an invisible anchor window and then write platform-specific code for sane platforms that CAN, of course, move the window. And let's not talk about window icons that you have to put somewhere on the file system?
Have you considered if someone wants to make a compositor where each window is projected onto a facet of a hyper cube and must place windows in 4 dimensions? These are important use cases we should support, we should make cross platform software as difficult possible to develop for Linux by removing features that have been standard on desktop operating systems for decades.
I must correct you! Wayland has not and indeed cannot remove features because Wayland is a “protocol”. It is the compositors that are removing features.
This dilution of responsibility should make you feel much better.
It's not technically behind on window positioning. Rather, it was a deliberate choice not to support it. You can very reasonably object to that, but it is sorta a necessary measure to prevent clickjacking.
I'm amazed how both wayland and x11 miss the logical solution: let the user decide.
Any function that is a threat should be behind capabilities.
A program should be able to request moving its windows. The user should ultimately decide what should happen: allow or nah.
And common sense mitigations: if a new program I've never seen before drops an actionable control under my cursor, maybe just default to not immediately accepting the next input to it so I have a chance to see it.
And that, to me, is a sufficient reason not to consider Wayland as a serious option.
Did such an attack with crazy moving windows happen in the past?
It does on Android
Happened a lot in browsers.
I mean, you can create alternate APIs that would work for the pop-up use case: you could have a command to create a new window positioned relative to the current window’s coordinate space.
That limited capability still has a risk of denial attacks (just throwing up pop-ups that extend beyond the current window’s boundaries), but those can be mitigated in a number of ways (limit the new window’s boundaries to the current window’s, or just limit how many windows can be opened, etc.).
Ads in the start menu, forced screenshotting of all your activity, and AI integration in every aspect of the desktop experience.
lol
BS, windows and macos cant even do proper window managing for a start, and then it just goes downwards from there on.. You can perhaps install various weird third party things, but it does not come with it by default.
If you took people who absolutely never tried any computing, and gave them macos, windows, and for example Plasma, they would NOT consider windows or macos to be ready for the desktop. If you go 15 years back, even way more so.
even in the early 2000s, windows was so hilariously crappy that you had to make floppy disks to even get to install the thing. If PCs didnt come preloaded with windows, regular users would never ever be able to install it, versus the relative ease a typical linux distribution was to install. This is also one of the large reasons that when their windows slowed down due to being a piece of shit with 1000000 toolbars, people threw it out and bought a new, despite the fact that a reinstall would have solved it.
> You can perhaps install various weird third party things, but it does not come with it by default.
A Window Manager and Window Server don't come by default with Linux... It's always an install-time option on the major distros.
> even in the early 2000s, windows was so hilariously crappy that you had to make floppy disks to even get to install the thing.
Windows in the early 2000s installed just fine without a floppy directly from CD or PXE booting.
Windows in early 2000s didn't even detect your early 2000s SATA drive
Windows in early 2023 didn't even detect the network card it needed to download network card drivers. After changing mobos I needed to boot into linux to download network drivers for windows...
Windows in early 2025 still uses SCSI emulation to talk with NVMe and only now the server part got a proper driver
Windows in early 2025s still need virtio driver injection to boot properly as a VM without IDE emulation
"Drivers working out of the box" were never windows strong part
Unless you needed a SATA driver not included in the installer because you wanted to avoid a legacy IDE emulation for your disks.
> Windows in the early 2000s installed just fine without a floppy directly from CD or PXE booting.
when was it sata became the norm? im thinking circa 2001-ish, and what windows was latest here? im thinking windows xp. lets try remember, did windows xp include sata drivers on the installation medium?? oh wait, it didnt. There wasnt even ahci at the time, and windows xp didnt include a single sata driver for any of the chipsets at the time
> A Window Manager and Window Server don't come by default with Linux... It's always an install-time option on the major distros.
desktop distributions generally come with a desktop environment default selected, or prompt you to choose between a few. one feature that has been there since more or less forever is alt + left/rightclick mouse to move/resize windows, which is significantly better than finding the title bar or corners like. for an operating system called "windows" its pretty hilarious it has the worst window management of them all, dont you think?
> If you took people who absolutely never tried any computing, and gave them macos, windows, and for example Plasma, they would NOT consider windows or macos to be ready for the desktop.
There's some truth to this. I've been installing fresh Windows 11s on family computers this holiday season, and good lord is it difficult to use.
The number of tweaks I had to configure to prevent actively hostile programs from ravaging disk read/writes (HDD pain), freezing and crashing, or invasive popups was absurd.
As someone who came from Windows, and has used Linux as my primary OS for 15 years, and MacOS here and there (cos work provided laptop), I can tell you that Linux was not ready for prime time 15 years ago. Today, I feel it is, but definitely not 15 years ago.
I use Linux on the desktop since 1997, and there was no point where Windows was even slightly more attractive.
I don't know what "prime time" means here.
edit: apart from, you know. Applications and drivers for random hardware.
With prime time I mean being comfortable enough to install it for a non-technical user. Even during Ubuntu's Unity days it didn't feel like I could install it on a computer for my parents or siblings for them to use as a daily driver.
My parents did fine with Linux. My mom still does; it's certainly less maintenance effort from me than Windows would require.
It was fine for non-technical users since at least early GNOME 2, if you're ready to help them set up and maintain. Semi-technical users (Windows power users, gamers, &c — people who like to install and configure things, but fear the deep dark abyss of the terminal) were and remain more problematic.
Unity days were the nadir of linux desktop ux — it was when Gnome 2 was gone, and 3 not yet there. Still better than contemporaneous Windows 8, though.
I can bet there’s no OS that are easy to install for a non-technical user. And that start from booting the installation media. Give someone a OS with their software already installed and they will use whatever OS that is.
People are always task-oriented, not tool oriented unless they’re nerds.
I had Kubuntu installed on my grandfather's computer for a year. I ended up replacing it for Windows because my aunt likes to install stuff on it. But my grandfather was happy with it. He only needed a working web browser and a program to use the TV tunner.
15 years back people were given Windows macOS and Linux and people voted which OS were ready for the Desktop and which were not. The only BS is your inflammatory contribution to this topic.
Nope, Macs were expensive stuff games did not run on, and linux was just not pushed by near anyone.
It was not a war "which desktop is easier to use", it was "which system can run stuff I need". And if "the need" was "video games and office stuff", your only choice was windows.
The average user only cares what they can run on the desktop. Linux did not have as much choice back then.
they were not, they purchased what was in the stores, which was only windows. all the way from first windows to windows xp it was the biggest pile of shit imaginable. the average user wouldnt even have half a chance of installing it, and certainly couldnt use it with any kind of reasonableness, it was a giant mess, it was just the mess people were used to. Most people would throw out their computer and buy a new when windows became slow, because, of course it gradually becomes slower, makes perfect sense, no?
KDE from 15 years back was HUGELY better than windows at the time, and frankly, also windows now
I can’t tell if this is satire.
[flagged]
Windows is reasonably OK, but MacOS' window management has always been really terrible.
Just think through the many different iterations over the years of what the green button on the deco does, which still isn't working consistently, same as double-clicking the title bar. Not to mention that whatever the Maximize-alike is that you can set title bar double click too (the options being Zoom and Fill, buried in settings somewhere) is different from dragging the title bar against the top of the screen and chosing single tile. Which is different from Control-Clicking the green button. Maybe. It depends on the app.
What a mess.
Both of them miss (without add-ons) convenience niche features I cherish, such as the ability to pin arbitrary windows on-top, but at least the basics in Windows work alright and moreover predictably and reliabily. Window management in MacOS just feels neglected and broken.
There may be many other ways in which MacOS shines as a desktop OS, and certainly in terms of display server tech it has innovated by going compositing first, but the window manager is bizarrely bad.
> Windows is reasonably OK,
Doesn't windows conflate window and process? That should kick it to the bottom of the bin by default.
> There may be many other ways in which MacOS shines as a desktop OS
May I suggest examining why your keyboard has a "home" key
There is at least one area where both macos and windows suck - handling window focus. MacOS is regularly having trouble with tracking focus across multiple monitors and multi-window apps, making it unusable with keyboard only. And Windows just loves to steal focus in the most inappropriate moments.
> making it unusable with keyboard only
oh no
"Oh no" is what you'd say after getting yourself some nice RSI and discovering that your hands hurt due to mouse or trackpad usage.
>> windows and macos cant even do proper window managing for a start
> Well they certainly manage them better than x11 and wayland.
X11 doesn't manage Windows. You'd know this if you used it, and if you've used it, you'd know why some consider the window management on Windows and MacOS very primitive.
> X11 doesn't manage Windows. You'd know this if you used it, and if you've used it, you'd know why some consider the window management on Windows and MacOS very primitive.
Sure. Windows and macos are also fallible. But there has never been a project that competes with these two brands that can boast a similar commitment to stability and usability.
Also obviously fuck windows
I don't use a Mac, but have you ever used Windows?
I mean, maybe you have, but if you are not fussy then at worst MacOS is quirky and Windows and Linux are identical and merely have different icons.
If you pay a little bit of attention you will notice that on linux things seem more flexible and intuitive.
If you are very finnicky, there is nothing that comes close to X11 window managers when it comes to window management flexibility, innovation and power.
Windows allows you to launch applications from a menu or via search. You can switch between windows with a mouse or keyboard shortcuts. Windows can either be floating, arranged in pseudo-tiled layers, or full screen. KDE can pretty much do the same under Wayland. Ditto for Gnome under Wayland, albeit to a lesser degree. That covers the bases for most people.
X11 window managers were a mixed bag. While there were a few standouts, most of the variation was in the degree to which they could be configured and how they were configured. There may be fewer compositors for Wayland because of the difficulty in developing them, but the ones that do exist do standout.
> I don't use a Mac, but have you ever used Windows?
I have
> I mean, maybe you have, but if you are not fussy then at worst MacOS is quirky and Windows and Linux are identical and merely have different icons.
Neither have keybindings that make any sense. The other failures are secondary
> If you pay a little bit of attention you will notice that on linux things seem more flexible and intuitive.
Only for windows refugees that have never used Mac OSX
> If you are very finnicky, there is nothing that comes close to X11 window managers when it comes to window management flexibility, innovation and power.
Unless you want to copy and paste, or have consistent key bindings cross applications, or take screenshots. Sure
> Neither have keybindings that make any sense.
I can agree on Windows, but there is no such thing as "keybindings that don't make sense" on a proper Linux WM given that you can literally make up any keybindings you want. I mean this strictly from a window management perspective, yes applications running in those windows have often got their own idea of what good UX is, and this clashes. That's just a trade-off of Linux and to a lesser extent Windows not being complete walled gardens.
> that have never used Mac OSX
I have _used_ Mac OSX. It was and continues to be a confusing experience every time. I'm not saying that this would be the case if I bothered to learn it, but in all the times I have used it, I have failed to see any feature which would make me want to switch to it over i3 or which I feel like is missing in i3. Really it doesn't seem like there is any way of making it act remotely close to i3. Tiling as an option on top of whatever Mac OSX has is just as appealing to me as tiling on top of what Windows has.
> Unless you want to copy and paste, or have consistent key bindings cross applications, or take screenshots. Sure
I've never had copy and paste fail on Linux. The only issues I've had is with more modern applications not implementing the selection properly which is a feature you don't have on windows in the first place. No idea about Macs.
Screenshots have always and will continue to work (the way I want them to) because I can, as mentioned, bind any key to any action.
> and Windows and Linux are identical and merely have different icons
At least on this we can agree, but windows never had to reboot the window server in my experience
I've definitely experienced parts of the windows UI crash. explorer.exe isnt just a file browser, half of the UI runs on top of it.
As the application author you can set the release mode in the build script so that the release flag looks like `zig build --release` instead, and the user doesn't choose the optimization mode.
As a user you can pass `--release` to `zig build` to request release mode. If the application doesn't want to pick for you, you'll get an error and then you can pick for yourself.
In this case, it looks like the author of Phoenix wants to choose ReleaseSafe as the official release mode of the application.
Phoenix is the name of my hometown, btw.
This is the kind of initiative I’d prefer to see from X preservationists. Great job, I hope it succeeds. I prefer Wayland, but there’s still a place in the world for X; it just needs new dev teams to shoulder the burden.
I disagree. The choices in the Linux ecosystem lead to unnecessary fragmentation and development/packaging nightmares.
I say let X11 die, bury it, and never let it rise again.
Then we can all focus on making just one display server as good as possible.
Which one? The Gnome Wayland, the KDE Wayland, the xroots wayland, Weston, or one of the others? Each one is an independent implementation of a Wayland compositor, with a differing, incompatible set of extensions.
X11 was a single, pretty janky implementation. Wayland is the worst of both worlds -- it's cleaned up a little, but it's still kinda janky. In exchange for a little bit of cleanup, mainly around bitmap fonts, it's no longer a unified protocol.
And to top it off -- it kept the worst part of the X11 protocol, the XKB extension, but got rid of input handling entirely, which means that every platform needs to reach for platform specific code to implement reading from the mouse and keyboard.
Yay.
If we're hypothesising a perfect world, ideally they standardise some way of sharing framebuffers between programs into Wayland. I suppose maybe they already have I gave up on the ecosystem in the early 2020s. That seems like it should be long enough ago now that they've got even advanced features like screenshots under control and rolled out.
Your "perfect world" sounds suspiciously similar to a remote infiltrator's paradise.
Sure, but I don't see a world where keeping X11 alive, in addition to all of this, makes anything better or easier, for anyone in the medium to long term.
If, as an application developer, you target X11, you have a program that will work on Linux and BSD with all desktop environments. It'd even work on Wayland via Xwayland. If you want to use it on other OSes, it's less smooth, but also working on MacOS via Xquartz, and Windows via Xming. There's even an X11 compatibility layer for Haiku (Xlibe).
With Wayland, you don't even get compatibility with Gnome and KDE. You need conditional compilation to get mouse events if you port to FreeBSD Wayland.
For the medium term, if your goal is to reduce fragmentation, X11 is the portable target, even if you use Wayland.
It makes things a lot better for me, for one, and clearly there are more of us. You may not think it matters, and that's fine, but X11 won't go away because there are enough of us that won't let it.
The answer has been Gnome Wayland for years
> The choices in the Linux ecosystem lead to unnecessary fragmentation and development/packaging nightmares.
You cannot possibly use this as an argument in Wayland's favor. X11 sucked because it baked everything, including multiple outdated kitchen sinks, into a single Xorg monolith. Wayland sucks because it factors out everything, including really important features, into optional extensions, ensuring that anything more interesting than "draw pixels to a window" will always be different on every single compositor.
Completed in 2007.
https://www.x.org/wiki/ModularizationProposal/
The *original* X11 should die, but the modern Linux GUI stack has long abandoned most of its features anyway. X11 was already reduced to a bit-blitter protocol long before Wayland.
So, in theory, we can embrace a rather-minimal X11 implementation that can run the modern UI, including some desktop features missing in Wayland.
This is the worst argument ever. The choices in the Linux community is what's made it the best OS in the world today.
Linux on the desktop only took of because Ubuntu, with mixed results and a lot of controversy, decided to standardize and polish the experience for "normies".
The distribution sprawl I largely see as a detriment to the ecosystem.
I would argue that Desktop Linux finally took off because of Steam Proton, and because of Windows 10/11 and macOS starting version fartascular or whatever their versions are named.
I remember seeing Linux gaining some traction 15 year ago, and Ubuntu focusing on polishing the user experience (with initiatives such as fixing "One hundred paper cuts"), but then this changed instead of keeping this stable the great rewriting began. Seeing Wayland (which is just one example) users having a problem with screen sharing just convinces me how much of a self-own this was from the Linux community.
Yeah but Ubuntu screwed up switching from Gnome to Unity back then, which sent tons of users elsewhere. You can't just rug-pull the entire GUI people were used to, which was also similar to Windows.
There isn't a successful Linux desktop OS. The Linux kernel is successful on servers and appliances, but only the kernel. And there aren't many even-split choices on your typical server. Like yeah zsh has a bit of a following, but everyone assumes you use bash, which is a good thing.
> I say let X11 die, bury it, and never let it rise again.
totally awesome! And once we are done with X11, lets put pulseaudio to the grave! We can all focus on having an audio stack that does realiably stream to many sinks!
And polkit... su and sudo should have been enough
> And once we are done with X11, lets put pulseaudio to the grave!
That'll happen first, I think. The trick is that pipewire is actually a fully functional replacement, instead of trying to declare everything out of scope, so with only minor effort people can just switch and everything works.
Sound like you should use a BSD instead of Linux if you don't like choice.
FreeBSD is indeed nicer to use than your average Linux distro, and has a really good manual. The blocker is that everything is made for Linux.
I’d love to have a proper x11.
Run gui apps in your container, local or remote.
Perfect
Why would a new rewrite be better preservation strategy than a full refactor and refresh of existing stable and working codebase?
Please prioritize to keep accessibility features working.
This is really the main issue with wayland. Yes, it might be more stable these days and work fine for you. We can talk how how it makes writing you own WM needlessly complicated and all that but the one thing that makes wayland unacceptable is its lacking accessibility story. After so many years.
Accessibility is not something you can worry about adding later. It is the first thing you should think about when designing new software.
As someone who is not deep into linux desktop history: Can you please elaborate on the missing accessibility features in wayland or direct me to resources on that?
I've been using wayland for a while now and am very happy with it, but my accessibility needs are pretty basic.
See this comment for example: https://news.ycombinator.com/item?id=46380075#46381858
Here is a slightly-hopeful article: https://fireborn.mataroa.blog/blog/i-want-to-love-linux-it-d...
thank you!
> Accessibility is not something you can worry about adding later.
I don't think there's any concrete proof of this. Ideally I think people want accessibility handled by their WM/DE; you're not getting Windows or macOS-quality a11y "for free" unless your desktop embraces it. At which point you might as well make it a separate, aftermarket protocol and slap it into d-bus.
If the Linux ecosystem is going to be fragmented and move past single-point-of-failure, polishing Xorg's accessibility works against the goal of standardized a11y.
Not just WM/DE, but also the toolkit too.
Same author behind https://git.dec05eba.com/gpu-screen-recorder/about/ , the best screen recorder for wayland imo (I had tried other alternatives but none of them helped in recording at 4k 60fps, this worked out of the box).
I have no idea how well this one works, but I am all up for more projects that can compete against the singularization that corporations currently try (see paid developers for wayland, GNOME and now also KDE). I wonder how much money would be needed to make the xorg server adapt to the modern era; I don't even know the featureset that is missing for this either. But I also know that wayland, after 20 years (!!!), will never cover those requests users had over tohse 20 years, simply because it tries to cater to a narrow specification wanted by corporations rather than the people - so much is now clear (wayland protocol was released in 2008, so it is soon 20 years actually; in a few days we have 2026, so it will be 18 years).
So … does xterm work? emacs? xfig? ghostview? xload? xev? oclock? xmodmap? xpilot?
I gave it a quick go and very few things work at the moment. None of the programs you listed do.
From the README:
And that sounds about right. As far as I can tell it doesn't yet have a lot of the core X11 stuff that "normal" clients expect. For example xterm doesn't start because requests like X_AllocColor, X_OpenFont, X_PutImage (a few picked at random from the error output) are not implemented yet.glxgears on the other hand does work :)
It’s possible that most of old X11 toys would not work properly, because many of them rely on X11 drawing APIs, but they are pretty simple to implement anyway.
motif apps? xmag? xfontsel? forwarding over ssh? ~/.XCompose? "links2 -g"?
> The compositor will get disabled … if the client runs a fullscreen application and disabled vsync in the application.
This is interesting to me, why would vsync being enabled mean that the desktop compositor needs to stick around for a full screen app?
I imagine because vsync and triple buffering introduce latency. There are cases like games where you don't want all that lag.
If the goal was to reduce latency, wouldn’t you want the desktop compositor out of the way when vsync is on?
That's very true, and I believe Wayland has a DRM leasing extension just for this use case. SteamVR uses it to punch through the compositor and draw straight to the screen.
Multiple screens support is listed as non-goal. Would that prevent its usage with window managers which support virtiaul desktops? I am i3 user and it is a critical feature for me.
In short: No.
In X11 "screen" has a particular meaning, and only supporting a single screen doesn't preclude multi-monitor support or virtual desktops.
Is this why back in the day sometimes a Linux distro would have a multi-monitor setup where each monitor was an actual different desktop cube for example. There was a time when each window for an Nvidia graphics card in that type of configuration could not be moved from one screen to another, etc.
Yep!
Given that they're fine with adding breaking changes to the protocol, I think it's a shame that they're not supporting multi-screen. This will lead to the same problem with Xrandr based multi-monitor where you get screen tearing with mixed refresh rate displays. I would prefer to see "traditional X11 multihead but you can move programs between screens" as the solution for multiple monitors. Even if it worked like Mac OS X where you can't have a single window span across multiple monitors, it would still be better than the current state of X11.
As others have already mentioned, the continuous multi-monitor(Xinerama) was an afterthought. A good news is that, by design, it’s actually pretty easy to add in the later steps.
I finally caved and switched to Wayland 6 months ago or so. Things just work so much more smoothly.
Some things do but for some details I'm amazed what I need to do to make it work, like going to sleep with multiple displays. Maybe it's a sway thing and I'm not complaining at all, crafting a solid minimal configuration has its charms.
I'm just thinking why did it take me so long to do the switch. I still keep X around, but not sure how long. Like keeping vim around after switching to nvim few years back..
What are the things specifically that work better? because most of the case people dont have issues because of the x11 (the protocol), but because of how the xorg server works
Bit of an observation, but I've noticed that there's been quite a few pragmatic projects started in Zig. Bun vs Deno comes to mind (one focused on DX, the other on security), and now this vs Wayland. Not to say that designing something properly is wrong, just that it tends to throw away a lot of important interoperability.
Nice! We do need more X servers, since Wayland refuses to incorporate essential protocol elements due to religion.
Yeah, we should introduce competition. It doesn’t feel like Wayland is improving these days. Missing features force me to hit X11 regularly, and I still get Wayland session crashes etc, while X11 could happily run over a year without crash and run all applications I need without issues.
“Wayland” cannot crash, its a protocol. Your complaints are to your compositor.
Wayland is a display system design, and is responsible for problems arising from the system design.
Another potentially interesting project is zigx, an X11 client library for Zig applications:
https://github.com/marler8997/zigx
https://www.youtube.com/watch?v=aPWFLkHRIAQ
Compared to libX11, it avoids dynamic dependencies, uses less memory, and provides better error messages.
If you are not going to implement X11 drawing ops and XRender (which I, and many others, still use heavily), what's even the point? Any 'modern' program that only does client-side rendering already supports Wayland. AFAIK GTK 3 doesn't even support DRI on X11 unless you somehow trick it into using the abandoned OpenGL Cairo backend, but that's not modern enough apparently.
Where do they say they're omitting drawing and xrender?
It talks about trimming 'legacy' features and specifically says they are omitting 'font-related' operations. That obviously means no useful core X11 application will work (unless you count xlogo and xeyes). Whether the XRender glyph cache mechanism is included is unclear. It also says only DRI is *currently* supported, but maybe that's incidental?
XRender isn't part of the core protocol so it should be implemented in the future. There is already some xrender code in there. Almost no applications use x11 core protocol font, except for cursor. Since the x11 core protocol font (on xorg server at least) is rendered without anti aliasing and doesn't really support unicode.
Core fonts absolutely support Unicode. My (non-Xft) xterm windows are full of Unicode characters right now. It is true that anti-aliasing is not supported by the X.Org server, although scalable fonts have been for a while (https://www.x.org/archive/X11R7.5/doc/fonts/fonts.html#AEN49...). But you don't need anti-aliasing on a high-DPI display, and on a low-DPI display you can use any of the many beautiful bitmap fonts, unlike a lot of ‘modern apps’ these days.
Is there anything at a protocol level that prevents using a modern font rendering stack for it?
We get the window management APIs back perhaps, unlike the eternally broken Wayland ecosystem.
If I could give a comment HN Gold, it would be this comment. 3 times.
Between this and zigx zig can become the whole x11 stack
https://github.com/marler8997/zigx
This is cool. What X is really missing though is a little bit of love from the toolkit side, e.g. proper latency hiding using XCB, support for dis- and reconnect or support for moving windows to display on different devices.
First my mind went to Phoenix (elixir framework), then to X (twitter) before it clicked what this was actually about. Some very overloaded names
The meaning of 'X server' has been well-established for 30+ years.
(tangent)
This is true, although entertainingly, the "server" part has always been easily confused.
In X11, the "server" runs on your local machine, and the "client" frequently runs on a remote system.
The server runs on the machine that allows clients to connect to it. What is the confusing part about this?
The part that is counterintuitive to most people when it comes to the "server" terminology is that, with X, your end-user workstation (which may be an incredibly dumb X terminal) is the "display server", which means you remote into a server (in the traditional sense) elsewhere, which then acts as an X client by making requests to your local machine to display windows.
The way most people think about it, "client" is your local machine and "server" is the remote machine that has lots of applications and is potentially multi-user, but X turns that backwards. The big iron is the client and the relatively dumb terminal is the server.
X has the terminology the other way around compared to all other consumer facing software.
This is because of its mainframe style history and technically it does make sense, it's just that everybody else does things the other way around.
For the people who weren't around in the ancient mainframe times who end up messing with Linux for the first time, this is confusing for a while.
Xhost and xapps
I think most of the confusion arises because when you are tunneling X via ssh, the X client/server is the reverse of the shh client/server.
Add to that that the user manages the ssh connection while the X connection is managed for them...
I think the confusion is obvious, given a little empathy for the range of people who use computers.
The server is usually a remote machine, especially back in the time when "client-server" architecture was emerging in mainstream (business) vernacular.
The server is not usually a remote machine. The server is the app accepting remote connections.
This has been true for decades.
https://en.wikipedia.org/wiki/Server_(computing)
Please don't imagine that I don't fully understand this.
Nevertheless, X11 "server" and "client" have confused very smart and highly technical people. I have had the entertainment of explaining it dozens of times, though rarely recently.
And honestly, still, a server is usually a remote machine in all common usage. When "the server's down", it is usually not a problem on your local machine.
Yes, it’s simultaneously logical if you look at how it works and immensely strange if you don’t understand the architecture. (As has been noted all the way back to the UNIX-HATERS Handbook[1], although, pace 'DonHopkins, the NeWS Book uses the same terminology—possibly because it was written late enough to contain promises of X11/NeWS.)
[1] https://www.donhopkins.com/home/catalog/unix-haters/x-window...
There is nothing at all strange about the terminology. Go run ps on macOS and marvel at the "WindowServer" process. The generic architectural term is "display server".
https://en.wikipedia.org/wiki/Windowing_system#Display_serve...
Programmers aren't good at checking if the name is taken. We've done this particular one before. Phoenix (Firefox) had to change names because of Phoenix Technologies, then again because of the Borland Firebird Database.
Phoenix was also the name of Mozilla's browser before they changed it to Firefox
I'm hoping they go with phoenix11 #seewhatididthere
Does this mean we can finally be done with the farce of pretending that Wayland is a serious contender for replacing X11?
Why is it not? I get the impression Wayland has been built by former X devs
The issue (to my understanding) is that it is a very different protocol, which makes it quite onerous for application and desktop environment developers to transition to. Also, since some desktop environments have really grown opposed to Wayland (e.g. XFCE) it puts the application developer in the position of having to wait.
Seems interesting that they're not using the XML protocol specs for code gen, the way the Xorg server does.
Complements XLibre[0], an active fork of the X11 server from Xorg.
XLibre is trying to advance the existing implementation which Xorg abandoned, whereas Phoenix is writing a new, compatible server from scratch.
0. https://github.com/X11Libre/xserver
XLibre is a joke. They're making changes for the sake of changes: for example, commit aefde9 strips out vendoring in an ad-hoc, incomplete fashion (introducing a minor spacing bug in the process); and commit aafd986 replaces `int` with `unsigned int` (instead of `size_t`), failing to properly fix the bug that the compiler warnings identified (albeit, also removing an unrelated C footgun along the way, so this does look like a bug fix). The main author has a history of cowboy commits: 533c45e (which made it into mainline Xorg before he got kicked out) straight-up prevents hw/xfree86/os-support/bsd/arm_video.c from compiling, so it's clear there's no actual testing taking place.
I doubt the XLibre authors understand the X security model, either – they never do, in forks like this – and they've alienated most of the security researchers who might otherwise clean up after them.
Phoenix and Wayback are much more interesting projects, in my book. Wayback's designed to actually work, and I expect it to be production-ready much sooner; but I expect Phoenix to be the more technically interesting project, since it's deliberately breaking from the X11 spec.
[flagged]
Here's two complaints: it's a security theater, and it's horribly balkanized by design.
On X, I can run tools like xmacro or xdotool to automate the desktop to my heart's content. On Wayland, this isn't supported "for my security" and my remaining options boil down to either using a tool that works one level of abstraction lower (requires root and/or a daemon), or a tool made exclusively for my DE if one even exists. What used to be a cohesive environment with portable knowledge and tools is replaced by incomplete, broken, or outright missing tools and a complete lack of parity across DEs. For what? Am I supposed to be happy about this?
What is the point of automating another UI/Desktop than the one you are actually using? If you allow people to build different type of systems you can't expect them to function the same and have the same API.
This is obtuse.
[dead]
> most of the Wayland complaints you read are handwave-y bullshit, idk what else to say.
The dislike of the product among users is certainly sincere. I feel like somewhere there is probably an author of a young adult novel with a title like “He’s Just Not That Into You” with a cathartic and cautionary ending and that author should write a pamphlet or something specifically for the benefit of the Wayland people.
OK, you can't have your preferred environment because someone else has a different use-case.
Moreover, people will condescend to you and insist your setup never worked, nobody ever used it, and nobody cares that it's going away. Plus, they state that you are just being difficult, if not delusional, when you say that you are quite happy with how things are. I mean, your way never worked, so how could it have been your way at all? You must be a troll, troll. Stop trolling.
Cool project I guess, don't see the point but technically interesting. Will be cool to have another modern display protocol/server. I personally would have rewritten Wlroots in Zig or something, but I guess this is more interesting.
the xserver implementation itself is only part of the problem. the other part is the X11 protocol is just bad, and IMHO can't be solved by subsetting.
this might make a good alternative to Xwayland though, which can be exciting.
Funny that this shows up now. I just started trying to write an entire window server + DE combined in Rust, for educational purposes.
Nice but 2008 called and want their git web UI back. I can't take anything "modern" seriously if it seems firmly archaic, my problem I get it.
Very much your problem.
https://git.kernel.org
Are different DPIs for different monitors supported too?
This is very good.
We can see innovation in this space.
Next I suppose is porting Motif to Windows.
So this can be an interesting option for XWayland?
Well no because it's not actually compatible with X11
The README mentions xwayland so maybe it could be in the future
Look, my setup works for me. Just add an option to reenable spacebar heating.
The Wayland people were right about everything
No active development in the last 4 months?
It's christmas and not april fools!
But this is a treat, not a silly joke!
[dead]
[dead]
[flagged]
This is a really really bad name. There's already a Phoenix that is well known in tech. https://phoenixframework.org/
OP if you're the author I suggest you rename to avoid confusion. Don't name it Rails either haha!
This is a really really bad comment. I've never heard of the framework you're talking about and I thought you were talking about the Firefox prototype.
I don't have an opinion on the matter, but it's pretty popular. According to [1], Phoenix "was used extensively over the past year" by 2.4% of responders.
[1] https://survey.stackoverflow.co/2025/technology
Phoenix is a well known web app framework regardless of your ignorance of it.
It's still a silly comment. The Phoenix web framework is a little over a decade old, and there are many other tech things named Phoenix that pre-date it, even just within the web application space. I assume Apache Phoenix and the web framework have a lot more to be annoyed at each other for.
I'm also pretty sure that there was an "Elixir" in IT before there was the language said framework is written in… I mean, given that the letter "X" is in both Unix and X11, I'm pretty sure most words containing it have already been used once or twice.
(I still think they should've stuck with "Firebird", little danger of confusing a browser with a database system mostly used by Delphi devs)
If you’re in software dev or frequent hn, how have you not heard of Phoenix? It is consistently voted as most loved web framework.
I’ve been on hn for almost 10 years, and have been doing mostly frontend development for the whole time. As far as I know I have never seen it mentioned. But then I have no interest in elixir, so I might just not have remembered the name even if I saw it.
Your link is about a nice web framework written in Elixir.
But I don't see how a X server implementation should avoid name collision with web frameworks.