Hacker News Reader

Comment by DCKing | Hacker News Reader

Worth noting that Firefox has run on Wayland by default on Fedora for many, many years at this point because the Fedora team patched it to do that. Firefox also uses Wayland on the default RHEL9 desktop and its derivatives, and it's been quite easy for power users to enable it in other environments. So it's quite well battle tested.

I am sensing a large momentum for Wayland in the Linux community though. Finally there is maturity for Wayland in KDE, there is very strong commitment from various projects to default to Wayland (this being one of them). Traditionally more conservative projects like Cinnamon and Wine are finally adopting Wayland too. It seems critical mass has been achieved to get things really moving in the community, and it's about time.

View on HN

> Traditionally more conservative projects like Cinnamon and Wine are finally adopting Wayland too.

I was under the impression WINE was less conservative and more that they really needed features that Wayland only recently added (relative positioning?)

I would describe it as both. Adding support for a new OS API adds a significant development, maintenance, and testing burden. When I was working on Wine, for changes in the higher-level audio APIs I would have to run tests across all of [macos coreaudio, linux alsa, linux alsa-pulse, linux pulseaudio, linux ossv4, and BSD ossv4]. Any change to those OS-level implementations had to be duplicated across all of them. It's a serious consideration to add support for new API, so we strongly preferred to offload that work to a shim layer (xwayland, alsa-pulse) as much as possible to avoid increasing the amount of code we had to write & maintain.

Desktop is even more complicated. Think about the infinite fractal of Linux windowing systems and DEs and drivers and end-user configurations, and having to maintain consistent win32 windowing behavior across _all_ of them... you realize adding in Wayland support is a massive development effort and support and maintenance commitment, even if it did have all the needed features.

Then also consider that new technologies have many bugs and change frequently; many Wine users do not use the latest version of Wine; and how important being able to build & run older Wine versions is for regression testing... it adds up to adding new OS API support being a very expensive thing to do. So yeah, it makes sense to be conservative about it. The Linux community's love for throwing away stable libraries and replacing them with a fresh new thing is a serious hindrance to writing quality software on a long timescale. (Oh look, it's PipeWire coming down the road... oh joy...)

Did it actually require a patch? I thought it just required a certain env var set, so they probably could have just made a wrapper script that set it and invoked the binary (located somewhere other than /usr/bin/firefox), which I'd expect is very minimal packing step compared to patching the code for building

I don't read "patch" as necessarily a "source code patch" per-se. Even if they just add/modify one line in the build script, I'd say that particular distribution of the Firefox application to be "patched".

I think almost every single distro's Firefox would be patched by that definition. Pretty much every package format requires at least one line of shell script to be invoked in some fashion.

I too have been using Firefox on Wayland for some time now (on Arch Linux). I'm not quite sure when that switch was made though. I recall for some time I had to manually set that flag myself, but I just checked and apparently I've been running on Wayland by default for some time now.

I am sensing zero momentum for Wayland. It was is absolutely idiotic API with lots of unnecessary arbitrary restriction and vast over-complication and over-engineering for no other reason than NIHS.

It will eventually be dropped like a hot potato, just like HAL.

I felt like I also saw the momentum the OP talks about, and then when I went to try and set up Sway as my window manager in a new Void Linux installation it was a total nightmare. I need some new thing called a "seat manager" that I never needed with X11? And the only options are the bloated elogind (the whole point of Void is to avoid systemd style programs) or the somewhat feature bare seatd, neither of which I could get to work? Pass.

Well, you're choosing the least popular (non-systemd) approach, and also skipping elogind. This stuff JustWorks on systemd based systems, so your blaim is inaccurate.

At LEAST read the docs for your distro:

https://docs.voidlinux.org/config/session-management.html

Where do you think I found out about the necessity to install either of those things in the first place?

If Wayland only JustWorks on systemd-based systems that's not exactly making a great case for it, and this thread has plenty of other downstream stuff that it seems to upend as well.

I'm not trying to make a case for it, it's the simple the truth that systemd has simplified a lot of this behind the scenes work. If you'd prefer to stick to the un-maintained X server because you value your init system more, that's up to you :)

So the largest two desktop environments defaulting to it, popular WMs (sway, etc) getting Wayland versions, PLUS agnostic projects like Firefox, is "zero momentum?" If anything, it's made (sadly) obvious which projects severely lack resources to migrate - the XFCE, enlightenment, gimp, etc. of the world.

I think we will find a lot of these projects always had the resources.

There are many people in the Linux community that are just vehemently opposed to it.

I suspect that in many cases the “lack of resources” was simply not having the resources to convince some of these people to stop being roadblocks.

GIMP hasn't even migrated to GTK3 yet. The upcoming GIMP 3 will finally use GTK3 and is slated for release in a few months, but this is years after almost everyone else. Certainly in the case of GIMP I think "lack of resources" can be substantiated pretty easily. IIRC GIMP 3 will also get Wayland support – I'd have to check to be sure.

I'm less sure about XFCE or Enlightenment. Judging from [1] the XFCE people have been working on it since Feb 2021 (when that page was created), but real issues still remain, and I'm not surprised that "let's do a substantial rewrite of much of our codebase from something that works perfectly fine to ... something else that works perfectly fine" is not hugely top priority for a fairly small project like this. Call that "people being roadblocks" if you will, but that doesn't strike me as fair. Neither of us get to decide where these people spend their time.

[1]: https://wiki.xfce.org/releng/wayland_roadmap

It's not as dire as you think :) Gimp should get Wayland support automatically when they complete the move to Gtk3 (which supports Wayland, Gtk2 does not) and the betas already support Wayland [1]. Enlightenment has clear plans for a Wayland mode [2]. Xfce has stated they'll support it too of course, but it's the largest change they'd be making in decades so it's understandable they're cautious. Maybe the momentum will have people get involved for Xfce, I'm pretty hopeful for all projects.

[1]: https://www.phoronix.com/news/GIMP-2.99.2-Released

[2]: https://www.enlightenment.org/about-wayland

Reply on news.ycombinator.com