[HN Gopher] Phoenix: A modern X server written from scratch in Zig
___________________________________________________________________
Phoenix: A modern X server written from scratch in Zig
Author : snvzz
Score : 613 points
Date : 2025-12-24 22:43 UTC (1 days ago)
(HTM) web link (git.dec05eba.com)
(TXT) w3m dump (git.dec05eba.com)
| superb_dev wrote:
| > 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?
| amiga-workbench wrote:
| I imagine because vsync and triple buffering introduce latency.
| There are cases like games where you don't want all that lag.
| superb_dev wrote:
| If the goal was to reduce latency, wouldn't you want the
| desktop compositor out of the way when vsync is on?
| sergiotapia wrote:
| 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!
| manytimesaway wrote:
| 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.
| viccis wrote:
| Phoenix is a well known web app framework regardless of your
| ignorance of it.
| sho_hn wrote:
| 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.
| killthebuddha wrote:
| 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
| cpursley wrote:
| 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.
| MobiusHorizons wrote:
| 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.
| mhd wrote:
| 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)
| hu3 wrote:
| 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.
| kombine wrote:
| Are different DPIs for different monitors supported too?
| snvzz wrote:
| 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
| wizzwizz4 wrote:
| 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.
| s08148692 wrote:
| First my mind went to Phoenix (elixir framework), then to X
| (twitter) before it clicked what this was actually about. Some
| very overloaded names
| gldrk wrote:
| The meaning of 'X server' has been well-established for 30+
| years.
| quesera wrote:
| (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.
| mananaysiempre wrote:
| 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...
| the_why_of_y wrote:
| 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_se
| rve...
| hitex wrote:
| The server runs on the machine that allows clients to
| connect to it. What is the confusing part about this?
| quesera wrote:
| 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.
| bdhcuidbebe wrote:
| 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)
| quesera wrote:
| 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.
| jeroenhd wrote:
| 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.
| jbverschoor wrote:
| Xhost and xapps
| cloudfudge wrote:
| 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.
| drdec wrote:
| 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...
| BearOso wrote:
| 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.
| SoftTalker wrote:
| Phoenix was also the name of Mozilla's browser before they
| changed it to Firefox
| donpdonp wrote:
| I'm hoping they go with phoenix11 #seewhatididthere
| gldrk wrote:
| 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.
| drpixie wrote:
| Where do they say they're omitting drawing and xrender?
| gldrk wrote:
| 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?
| gooberman wrote:
| 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.
| gsnedders wrote:
| Is there anything at a protocol level that prevents using
| a modern font rendering stack for it?
| gldrk wrote:
| 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 (ht
| tps://www.x.org/archive/X11R7.5/doc/fonts/fonts.html#AEN4
| 9...). 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.
| nixosbestos wrote:
| If I could give a comment HN Gold, it would be this comment. 3
| times.
| esjeon wrote:
| We get the window management APIs back perhaps, unlike the
| eternally broken Wayland ecosystem.
| sho_hn wrote:
| 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.
| wmf wrote:
| For people who absolutely have to have X11 this looks like a
| better plan than XLibre.
| sho_hn wrote:
| 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.
| vidarh wrote:
| 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.
| sho_hn wrote:
| Fair! Though I'm actually not sure I understand what you
| mean with simplicity. X11 is so vastly more complicated
| than Wayland.
| vidarh wrote:
| 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.
| dismalaf wrote:
| So build on top of wlroots or something. DWL for example
| is super small...
| ggdG wrote:
| 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
| dismalaf wrote:
| 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.
| badsectoracula wrote:
| 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.
| mackeye wrote:
| (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)
| gf000 wrote:
| > X11 is backwards compatible, you do not have to "keep
| up" with its changes.
|
| That's certainly one way to say "no longer developed".
| ggdG wrote:
| > 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.
| dismalaf wrote:
| 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...
| vidarh wrote:
| 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.
| vidarh wrote:
| 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.
| LeFantome wrote:
| 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.
| kelnos wrote:
| 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.)
| LeFantome wrote:
| https://github.com/CuarzoSoftware/Louvre
| vidarh wrote:
| 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, and will
| let me restart without restarting my session, what you're
| offering me is inferior to what I have with X
| gf000 wrote:
| It's called an extension. What's the point of mandating a
| (bad) IPC API?
| vidarh wrote:
| 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.
| mikkupikku wrote:
| 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.
| imtringued wrote:
| > 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.
| mikkupikku wrote:
| 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?
| yjftsjthsd-h wrote:
| > 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
| saint_yossarian wrote:
| > 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.
| mikkupikku wrote:
| 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.
| KerrAvon wrote:
| 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.
| wpm wrote:
| Is there any documented attack on macOS or Windows that
| utilized window title information?
| torginus wrote:
| 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).
| gf000 wrote:
| > like wlroots necessary to provide a similar set of
| functionalities, is already larger that the equivalent
| X11 code
|
| I absolutely don't buy this.
| mathstuf wrote:
| 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).
| mikkupikku wrote:
| 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.
| vidarh wrote:
| 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.
| wincy wrote:
| 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.
| QuercusMax wrote:
| Wayland still doesn't support screensavers last I
| checked, which is wild to me. Truly bizarre that such
| longstanding feature is just absent.
| jml7c5 wrote:
| 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.
| Qwertious wrote:
| 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.
| bigyabai wrote:
| IMO, if you have to rewrite a display server
| implementation then you're already proving all the
| protocol advocates right.
| shevy-java wrote:
| 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.
| sho_hn wrote:
| > "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.
| shevy-java wrote:
| > 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?
| yepguy wrote:
| 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.
| sho_hn wrote:
| 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.
| uecker wrote:
| It isn't clear why any of this would require a rewrite.
| mathstuf wrote:
| 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.
| maxdamantus wrote:
| > 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.
| gf000 wrote:
| > 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.
| yxhuvud wrote:
| You can have different dpi and refresh rate per monitor
| in X, but you cannot do it while having a shared desktop
| across them.
| lproven wrote:
| 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.
| kelnos wrote:
| 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.
| eptcyka wrote:
| 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?
| coryrc wrote:
| > 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.
| oddmiral wrote:
| 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.
| uecker wrote:
| 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.
| eptcyka wrote:
| 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.
| uecker wrote:
| 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".
| eptcyka wrote:
| It was my understanding that changing the original
| codebase to fix it would've been involved enough as to
| warrant a rewrite.
| gf000 wrote:
| 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.
| coryrc wrote:
| Kristian Hogsberg, 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.
| eptcyka wrote:
| 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.
| coryrc wrote:
| 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.
| cycomanic wrote:
| 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 Hogsberg (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?
| coryrc wrote:
| 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?
| cycomanic wrote:
| > 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).
| Izkata wrote:
| > 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.
| torginus wrote:
| >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.
| forgotpwd16 wrote:
| 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.
| TingPing wrote:
| 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.
| Zardoz84 wrote:
| HDR something that can't be brought to X11 without
| breaking backwards compatibility.
| Zardoz84 wrote:
| https://github.com/reaperx7/HDR10-X11
| jherskovic wrote:
| First line of the readme: Non-functional implementation
| work-in-progress framework code for getting HDR10 working
| under X11.
| PunchyHamster wrote:
| 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
| seanw444 wrote:
| First time I've heard of Arcan. Sounds intriguing.
| PunchyHamster wrote:
| 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.
| mikkupikku wrote:
| > _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.
| badsectoracula wrote:
| 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.
| uecker wrote:
| 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.
| imtringued wrote:
| 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.
| ptx wrote:
| 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/
| torginus wrote:
| 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.
| samiv wrote:
| 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.
| extropy wrote:
| 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.
| denkmoon wrote:
| 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.
| badsectoracula wrote:
| 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
| KerrAvon wrote:
| 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.
| PunchyHamster wrote:
| 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"
| extropy wrote:
| 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.
| sho_hn wrote:
| 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.
| Telemakhos wrote:
| 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.
| sho_hn wrote:
| It's a Wayland compositor, not an X-windows server!
| PaulDavisThe1st wrote:
| and even if it wasn't Wayland, it would be an X Window
| server.
| coliveira wrote:
| 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.
| sho_hn wrote:
| 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.
| ChocolateGod wrote:
| > 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.
| superkuh wrote:
| 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).
| nixosbestos wrote:
| 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.
| superkuh wrote:
| >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/
| imtringued wrote:
| 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.
| LeFantome wrote:
| 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!
| XorNot wrote:
| 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.
| superkuh wrote:
| 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.
| MrDrMcCoy wrote:
| 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 :-)
| LeFantome wrote:
| Me too!
| lelanthran wrote:
| > 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.
| reactordev wrote:
| My rpi dashboards are gonna love it
| c-hendricks wrote:
| 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.
| PunchyHamster wrote:
| less RAM and power usage
| reactordev wrote:
| 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.
| GaryBluto wrote:
| People who want to use X11 are likely to be the same people
| using older software and hardware, which this doesn't
| support.
| vidarh wrote:
| I don't use any old hardware, and I have argued for a new X
| server following almost exactly the steps this project
| outlines.
| nixosbestos wrote:
| Good news. The devs of x11 agree and made a replacement
| called... Way... Oops
| vidarh wrote:
| Yeah, no, the X11 devs made pretty much all the wrong
| tradeoffs for me.
| bigyabai wrote:
| I wonder why Valve disagrees.
| yjftsjthsd-h wrote:
| 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.
| mikkupikku wrote:
| Valve being eminently pragmatic, as usual.
| vidarh wrote:
| Presumably Valve cares about different things than me.
|
| I wonder why you think what Valve does has any relevance
| to my experience or priorities.
| Qwertious wrote:
| "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.
| bigyabai wrote:
| > 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.
| ablob wrote:
| Forking a project when the issue is that half of the
| staff left the project does nothing to alleviate the
| staffing issue, does it?
| pjmlp wrote:
| Isn't that the greatness of FOSS over commercial software
| that keeps being spoken about?
| cycomanic wrote:
| 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?
| PunchyHamster wrote:
| and failed to learn any lesson from X11
| singpolyma3 wrote:
| Long term if x11 starts having issues then probably
| https://gitlab.freedesktop.org/wayback/wayback will be it
| Izkata wrote:
| > 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.
| singpolyma3 wrote:
| Yes basically. It's one full screen xwayland context you
| run a normal x11 wm in
| adastra22 wrote:
| I'm not sure this satisfies X11 needs without remote display
| capability.
| shakna wrote:
| Until Wayland actually has an accesibility story, X is really
| the only choice. Don't think most grassroots projects will
| have that.
| torginus wrote:
| 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.
| KetoManx64 wrote:
| 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.
| nialv7 wrote:
| pretty sure at-spi is independent from the display server
| themafia wrote:
| Rewriting it from scratch is so very rarely a better plan
| than improving what you already have.
| snvzz wrote:
| 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
| KetoManx64 wrote:
| Just got a major release as well with tons of new
| contributors and fixes/additions:
| https://github.com/X11Libre/xserver/releases/tag/xlibre-
| xser...
| kiney wrote:
| I WANT to use X11, its simply better than wayland
| gf000 wrote:
| Well there is XWayland then.
| yjftsjthsd-h wrote:
| Depends why you need it. XWayland is worthless for a11y.
| gf000 wrote:
| Arguably, there is no sane a11y on GNU/Linux anywhere.
|
| iOS/Mac/Android is on completely other level.
| yjftsjthsd-h wrote:
| 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.
| shevy-java wrote:
| > 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?
| sho_hn wrote:
| 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.
| imtringued wrote:
| 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.
| torginus wrote:
| 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
| creatonez wrote:
| 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.
| LeFantome wrote:
| 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.
| criticalfault wrote:
| wondering who those people are given that Wayland was done by
| xorg devs
| IshKebab wrote:
| 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.
| criticalfault wrote:
| 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?
| yjftsjthsd-h wrote:
| 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)
| IshKebab wrote:
| 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.
| linuxhansl wrote:
| 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.)
| vladvasiliu wrote:
| 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).
| mihular wrote:
| 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.
| yxhuvud wrote:
| 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.
| mihular wrote:
| Uh, there are plenty of extensions. Session management
| perhaps? In experimental state.
| vladvasiliu wrote:
| 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.
| Rygian wrote:
| 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.
| gabrielgio wrote:
| 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.
| oblio wrote:
| 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.
| bitwize wrote:
| 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!
| ccakes wrote:
| 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!
| drpixie wrote:
| 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.
| reactordev wrote:
| 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.
| sho_hn wrote:
| 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.
| glzone1 wrote:
| 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.
| reactordev wrote:
| 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)
| someguyiguess wrote:
| Python is really one of the worst designed languages. It
| always baffles me that people recommend it to beginners.
| zbentley wrote:
| Except for all the others (that anyone uses)...
| IshKebab wrote:
| 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...
| cons0le wrote:
| 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.
| yjftsjthsd-h wrote:
| > 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.
| imtringued wrote:
| 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.
| reactordev wrote:
| 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.
| PunchyHamster wrote:
| 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"
| bdhcuidbebe wrote:
| Be the change you want to see.
|
| Also happy winter solstice.
| viraptor wrote:
| 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.
| bsder wrote:
| 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.
| throwaway92841 wrote:
| 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.
| MindSpunk wrote:
| 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.
| redeeman wrote:
| 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.
| MangoToupe wrote:
| > windows and macos cant even do proper window managing for a
| start
|
| Well they certainly manage them better than x11 and wayland.
| What a fucking nuts thing to say. Are you rms?
| Arch-TK wrote:
| 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.
| II2II wrote:
| 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.
| MangoToupe wrote:
| > 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
| Arch-TK wrote:
| 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.
| MangoToupe wrote:
| > 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
| sho_hn wrote:
| 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.
| MangoToupe wrote:
| > 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
| binarin wrote:
| 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.
| MangoToupe wrote:
| > making it unusable with keyboard only
|
| oh no
| lelanthran wrote:
| >> 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.
| MangoToupe wrote:
| > 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
| 7bit wrote:
| 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.
| grim_io wrote:
| The average user only cares what they can run on the
| desktop. Linux did not have as much choice back then.
| PunchyHamster wrote:
| 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.
| redeeman wrote:
| 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
| someguyiguess wrote:
| I can't tell if this is satire.
| p_ing wrote:
| > 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.
| tstenner wrote:
| Unless you needed a SATA driver not included in the
| installer because you wanted to avoid a legacy IDE
| emulation for your disks.
| PunchyHamster wrote:
| 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
| redeeman wrote:
| > 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?
| figmert wrote:
| 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.
| akho wrote:
| 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.
| figmert wrote:
| 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.
| Zardoz84 wrote:
| 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.
| akho wrote:
| 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.
| OsrsNeedsf2P wrote:
| > 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.
| reppap wrote:
| 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.
| sillystuff wrote:
| 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.
| pezezin wrote:
| I don't know about other DE, but at least with Plasma there
| is a "overscan" option to compensate for hidden borders.
| sillystuff wrote:
| 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.
| OsrsNeedsf2P wrote:
| Autoclickers and screen macros on Wayland are all janky
| MrDrMcCoy wrote:
| 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.
| phito wrote:
| 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.
| linsomniac wrote:
| >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.
| reppap wrote:
| 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.
| foxrider wrote:
| 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.
| nish__ wrote:
| > Wayland is still quite a way behind Windows and macOS in
| terms of what productivity users need
|
| What's missing?
| quantummagic wrote:
| Ads in the start menu, forced screenshotting of all your
| activity, and AI integration in every aspect of the desktop
| experience.
| nish__ wrote:
| lol
| gen2brain wrote:
| 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?
| bloppe wrote:
| 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.
| gen2brain wrote:
| Did such an attack with crazy moving windows happen in
| the past?
| hanikesn wrote:
| It does on Android
| foxrider wrote:
| Happened a lot in browsers.
| bmacho wrote:
| 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.
| XorNot wrote:
| 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.
| vidarh wrote:
| And that, to me, is a sufficient reason not to consider
| Wayland as a serious option.
| gsnedders wrote:
| 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.).
| MindSpunk wrote:
| 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.
| vzaliva wrote:
| 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.
| sho_hn wrote:
| 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.
| ddtaylor wrote:
| 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.
| sho_hn wrote:
| Yep!
| ndiddy wrote:
| 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.
| esjeon wrote:
| 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.
| vitalnodo wrote:
| 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.
| iamnothere wrote:
| 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.
| grim_io wrote:
| 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.
| nish__ wrote:
| This is the worst argument ever. The choices in the Linux
| community is what's made it the best OS in the world today.
| grim_io wrote:
| 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.
| kesor wrote:
| 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.
| uecker wrote:
| 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.
| morshu9001 wrote:
| 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.
| esjeon wrote:
| 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.
| yjftsjthsd-h wrote:
| > 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.
| rabf wrote:
| Completed in 2007.
|
| https://www.x.org/wiki/ModularizationProposal/
| ori_b wrote:
| 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.
| grim_io wrote:
| 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.
| ori_b wrote:
| 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.
| vidarh wrote:
| 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.
| roenxi wrote:
| 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.
| bigyabai wrote:
| Your "perfect world" sounds suspiciously similar to a
| remote infiltrator's paradise.
| morshu9001 wrote:
| The answer has been Gnome Wayland for years
| jbverschoor wrote:
| I'd love to have a proper x11.
|
| Run gui apps in your container, local or remote.
|
| Perfect
| bashkiddie wrote:
| > 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
| noosphr wrote:
| Sound like you should use a BSD instead of Linux if you don't
| like choice.
| morshu9001 wrote:
| 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.
| noosphr wrote:
| Sound like you want to eat your cake and have it too. The
| reason why everything is made for Linux is because you
| can make Linux into anything. The reason is choice. The
| more you try taking that away the less things will run on
| it until it's just a worse BSD.
| bnolsen wrote:
| It's christmas and not april fools!
| nine_k wrote:
| But this is a treat, not a silly joke!
| AndyKelley wrote:
| 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.
| smj-edison wrote:
| 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.
| grumps wrote:
| I finally caved and switched to Wayland 6 months ago or so.
| Things just work so much more smoothly.
| ilvez wrote:
| 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..
| gooberman wrote:
| 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
| shmerl wrote:
| So this can be an interesting option for XWayland?
| PeakKS wrote:
| Well no because it's not actually compatible with X11
| gooberman wrote:
| The README mentions xwayland so maybe it could be in the future
| Levitating wrote:
| No active development in the last 4 months?
| dismalaf wrote:
| 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.
| __d wrote:
| So ... does xterm work? emacs? xfig? ghostview? xload? xev?
| oclock? xmodmap? xpilot?
| esjeon wrote:
| 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.
| donio wrote:
| 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.
|
| glxgears on the other hand does work :)
| CerryuDu wrote:
| motif apps? xmag? xfontsel? forwarding over ssh? ~/.XCompose?
| "links2 -g"?
| shevy-java wrote:
| 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).
| immibis wrote:
| Nice! We do need more X servers, since Wayland refuses to
| incorporate essential protocol elements due to religion.
| esjeon wrote:
| 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.
| TingPing wrote:
| "Wayland" cannot crash, its a protocol. Your complaints are
| to your compositor.
| socketcluster wrote:
| 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...
| wewewedxfgdf wrote:
| 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.
| socketcluster wrote:
| It's a great name but way overused. I guess everything these
| days rose from ashes of past failures. Sector is highly
| competitive.
| bloppe wrote:
| Ya, and that's the same reason all those other projects
| picked this name too
| thiht wrote:
| 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
| wakawaka28 wrote:
| 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.
| LeFantome wrote:
| 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.
| lmz wrote:
| Wasn't it renamed because of these people?
| https://en.wikipedia.org/wiki/Phoenix_Technologies
| wakawaka28 wrote:
| Yes, and that was just the start lol...
| https://www.zdnet.com/article/mozilla-holds-fire-in-
| naming-f...
| loeg wrote:
| Yeah, me too. https://website-
| archive.mozilla.org/www.mozilla.org/firefox_...
| wakawaka28 wrote:
| 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).
| wakawaka28 wrote:
| 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.
| loeg wrote:
| Firefox was Firebird, not Phoenix.
| wakawaka28 wrote:
| 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...
| travisgriggs wrote:
| 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.
| mths wrote:
| Better not ask them to think outside the box or they'll come up
| with something like fushichou.
| rplnt wrote:
| 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.
| cheschire wrote:
| Remember when every project acronym used to be YA-something for
| "Yet Another..."? Or when recursive acronyms were the hot
| trend?
| elestor wrote:
| 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.
| underdeserver wrote:
| I think all the cool one-word names are used, and overused, by
| now.
| zingar wrote:
| There's an AI coding tool called phoenix.love as well
| PixelForg wrote:
| 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).
| ori_b wrote:
| Seems interesting that they're not using the XML protocol specs
| for code gen, the way the Xorg server does.
| fithisux wrote:
| This is very good.
|
| We can see innovation in this space.
|
| Next I suppose is porting Motif to Windows.
| uecker wrote:
| 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.
| nialv7 wrote:
| 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.
| isopede wrote:
| Look, my setup works for me. Just add an option to reenable
| spacebar heating.
| Shekelphile wrote:
| Does this mean we can finally be done with the farce of
| pretending that Wayland is a serious contender for replacing X11?
| paulryanrogers wrote:
| Why is it not? I get the impression Wayland has been built by
| former X devs
| liampulles wrote:
| 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.
| webprofusion wrote:
| 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.
| lloydatkinson wrote:
| Very much your problem.
| Zambyte wrote:
| https://git.kernel.org
| cardanome wrote:
| 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.
| hambes wrote:
| 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.
| cardanome wrote:
| 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...
| hambes wrote:
| thank you!
| bigyabai wrote:
| > 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.
| gsnedders wrote:
| Not just WM/DE, but also the toolkit too.
| mkoubaa wrote:
| The Wayland people were right about everything
___________________________________________________________________
(page generated 2025-12-25 23:00 UTC)