4 ms·

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

by DCKing 3y ago

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.

yjftsjthsd-h 3y ago
> 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?)
- coldpie 3y ago
  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...)
aquova 3y ago
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.
saghm 3y ago
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
- capableweb 3y ago
  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".
  - saghm 3y ago
    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.
sprash 3y ago
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.
- cempaka 3y ago
  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.
  - abrouwers 3y ago
    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 https://docs.voidlinux.org/config/session-management.html
    - cempaka 3y ago
      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.
      - abrouwers 3y ago
        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 :)

by DCKing 3y ago

yjftsjthsd-h 3y ago

> 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?)

coldpie 3y ago
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...)

aquova 3y ago

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.

saghm 3y ago

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

capableweb 3y ago
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".
- saghm 3y ago
  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.

sprash 3y ago

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.

cempaka 3y ago
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.
- abrouwers 3y ago
  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 https://docs.voidlinux.org/config/session-management.html
  - cempaka 3y ago
    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.
    - abrouwers 3y ago
      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 :)