8 ms·

The discussion about "wayland vs X11" is eerily reminiscent of the discussion of "systemd vs. sysv-init"... Some people apparently really do hate it when thing

The discussion about "wayland vs X11" is eerily reminiscent of the discussion of "systemd vs. sysv-init"... Some people apparently really do hate it when things change that they seemingly have no control over Edit: I fully expect to be downvoted into oblivion for this post :-D

ranger207 4y ago
Yeah, I'm a big fan of systemd but I can accept that when it first came out it was probably a lot worse than it is today. Similarly, Wayland has a bunch of good ideas, along with a bunch of functionality that isn't there yet. Of course, Wayland also has the problem that it's intentionally excluding some useful features that X had, like global hotkeys and screensharing. I think systemd and Wayland are actually opposites in this regard, where systemd was disliked at first and then turned liked, while Wayland was liked at first but is now turning to disliked
- vetinari 4y ago
  > Of course, Wayland also has the problem that it's intentionally excluding some useful features that X had, like global hotkeys and screensharing Screensharing has been supported for some time already. Some apps support it, some don't. It is up to the apps to use the respective APIs, the times of free reign over framebuffer is over.
  - mort96 4y ago
    I mean, you can get screen sharing to work. But there are like 3 different incompatible "standards" for how to do it. There's no single simple answer to "how to record the screen in Wayland". This has been the state of screen sharing on Wayland for at least 7 years. I'm also very curious about what's envisioned for global hotkeys. Surely we don't expect people to manually go to their system settings and configure some command to run which talks to Discord over an IPC solution to start sharing my voice when I press my push to talk button and stop when I release the push to talk button? But "global hotkeys should be configured on a system basis, not an application basis" seems to be the reigning philosophy, despite being incredibly user and developer hostile.
    - vetinari 4y ago
      There is one standard and single simple answer: xdg-desktop-portal with pipewire. Some compositors might have implemented their own private APIs, but that is not a standard by definition. Global shortcuts are a bit more thorny, exactly for the reason you mentioned. You present one POV, the another is, that application-defined shortcuts are incredibly hostile, as they allow application to stomp on each other in the better case, or hijaack global state in the worse one. Some other operating systems do not allow it either, for the same reasons. The long-term solution could be defining api, that allows application to advertise global actions, and allow the user to configure shortcuts that might (or might not) call these, in some user-friendly way.
      - mort96 4y ago
        Isn't xdg-desktop-portal a flatpak thing? It claims to be so here: https://github.com/flatpak/xdg-desktop-portal https://github.com/flatpak/xdg-desktop-portal > A portal frontend service for Flatpak and possibly other desktop containment frameworks. When it comes to global shortcuts, I'm not saying it has a super easy solution, but it's something that it's essential to support. Wayland intentionally doesn't, and I can't see that changing in the short term (as you also agree)
        vetinari 4y ago
        It is dbus api, and is able to work cross-namespaces (i.e. flatpak containers too). There no harm in using it in non-flatpak apps, at least you will be ready if your app ends up in flatpak. Wrt global shortcuts, I see that there is some work done. The intentional part isn't malice, as in not willing to implement it at all. It is about not implementing temporary solution, that will be quick and dirty, and then being stuck for supporting it for next 50 years.
        Bjartr 4y ago
        So kind of like Go and generics in that regard
  - ilyt 4y ago
    > Screensharing has been supported for some time already. Some apps support it, some don't. It is up to the apps to use the respective APIs, the times of free reign over framebuffer is over. See, that's the problem, it's putting unnecessary load on everything else using it. It should have that API and it should have API that just allows dedicated app to allow/deny permissions to use that API. Not put everything on WM to duplicated more and more code for no good reason and making WM developer harder
- chimeracoder 4y ago
  > Yeah, I'm a big fan of systemd but I can accept that when it first came out it was probably a lot worse than it is today. The first "large" distro to switch from sysvinit to systemd was Arch, and that switch happened over ten years ago. The switch itself was quite rocky (the upgrade path was not particularly seamless, and while Arch users tend to be more tolerant of that sort of thing, it's worth mentioning). That said, even in 2012-2013, the end result once you completed the upgrade was significantly better than collectively expected. The original plan was to support both systemd and sysvinit (at least for a period of time), but that was quickly abandoned because not enough people wanted to actually maintain sysvinit packages, so support[0] ended up getting dropped very quickly. [0] Arch is a community project, so "support" is different from what you'd expect in (e.g.) RHEL, but it still has separations of what's considered supported and what's not.
  - Conan_Kudo 4y ago
    > The first "large" distro to switch from sysvinit to systemd was Arch No. In terms of released to users, the first was Fedora; the second was Arch; then Mageia; then openSUSE. In terms of integrated into the distribution, the first was Fedora; the second was Mageia; then openSUSE; then Arch. Cf. https://en.wikipedia.org/wiki/Systemd#Adoption https://en.wikipedia.org/wiki/Systemd#Adoption
- duskwuff 4y ago
  > Of course, Wayland also has the problem that it's intentionally excluding some useful features that X had, like global hotkeys and screensharing... Screen sharing was always a weak point in X11, actually. VNC servers like x11vnc use absurd, inefficient hacks like periodically capturing fragments of the screen and checking for changes [1] -- while an extension to provide change notifications exists, it's been unreliable for ages [2] and the standard advice is to disable it. [1]: https://github.com/LibVNC/x11vnc#algorithm https://github.com/LibVNC/x11vnc#algorithm [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815909 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815909
kelnos 4y ago
I don't really see the parallels. For the past few months I've been investigating and working on porting parts of Xfce to be usable under Wayland. It's astonishing the number of features that are just not implementable at all on Wayland, at least not without inventing new non-standard Wayland protocols. (Another option is refactoring the desktop environment so all the individual components run in the same process as the compositor, and have access to the compositor's internals, but that's unacceptable for what are hopefully obvious reasons.) Even after over a decade, Wayland still seems quite immature and poorly thought-through. The protocol standardization seems geared toward satisfying GNOME's use-cases and ignoring everyone else's. The wlroots camp has gone their own way on a bunch of things, which is fine, but fractures the landscape a bit. Making Xfce fully Wayland means turning the window manager, xfwm4, into a Wayland compositor. For someone already familiar with xfwm4's code base, that's a year or more of work (and a requirement we'd have is that it would have to support both X11 and Wayland, further complicating things). Even if fixing inherent problems in X11 (security, graphics rendering, etc.) would require compatibility breaks, personally I would find that preferable to throwing the entire thing out and having to build (and build on) an entirely new system. As much as I disagree with JWZ's attitude on a lot of things, his description of most open source projects as a "Cascade of Attention-Deficit Teenagers" seems to be pretty accurate, at least here. X11 hasn't been improved and fixed because no one wants to maintain and improve X.org anymore, and the people who used to maintain it would prefer the fun of chasing and working on new shiny things, even if it means decades of new make-work for anyone working in the Linux GUI space. Don't get me wrong, I am the first one to cut off anyone at the knees who feels they are entitled to tell open source developers what to do with their time (though it gets a bit more complicated when many of those developers are employed by corporations to do this work). But I think it's pretty shitty to push the desktop in this direction and essentially force desktop and toolkit and application developers to choose between stepping up to maintain and build on X.org (something well out of most people's wheelhouse), or spend a huge amount of time porting to a new display system. Having said that, Wayland does have promise to be a better system than X11, even though it will likely take another decade to achieve feature parity with what we already have. So I'll continue to work on getting there eventually, even though I resent the fact that I have to learn an entirely new display system so I can work on reimplementing the same features again instead of building new features, fixing bugs, and making things more polished.
JoshTriplett 4y ago
I think in both cases, there's a similar switch of philosophy. We went from "there are a bunch of components glued together, and with enough glue you can solve anything (except an excess of glue)" (shell scripts for sysvinit vs declarative unit files for systemd; X11 apps that can do almost anything, vs the privileged compositor for wayland), to a model of "we wanted things to just work without having to install glue, so we integrated more functionality people wanted, if you want to swap it out you have to swap out the whole thing and keep up enough with all the other features people want" (e.g. you have to actually get the things you want into unit file directives, or get the features you want into the compositors people use; or you have to build a completely separate compositor or a separate init). That's a tradeoff. For my part, I'm thrilled that so many more things just work out of the box; however, it's discouraging for people whose features aren't covered yet, since they have to go work on integration rather than writing a specialized tool and encouraging people to glue that tool in. But the benefit of that is that once something is integrated, it just works, with no glue required.
- WhatIsDukkha 4y ago
  You are presenting this in certain way that I think veers into inaccurate and misleading in an attempt to smooth things over and be nice. What we had before systemd was - 90% glue code, reimplemented quite badly across X distributions. That glue code was, in practice, extremely brittle and very very unfun to attempt to keep even simple daemons running "portably" distribution to distribution. The other 10% was increasingly aging and ill maintained c code snippets. That was not a nice world for people actually using it. For people making stuff up about "the old days" that didn't actually participate in the misery of making basic systemv scripts, yeah it was composable and we lost something.
  - zozbot234 4y ago
    The internals of systemd are just as brittle, and the model of unit file configuration does not really apply cleanly beyond the simplest cases. So editing unit files becomes an undocumented dark art.
jmclnx 4y ago
The largest issue with Wayland is it has "Linuxisms". That means no work was done by the Wayland people to make it portable to other UN*X. So the BSD folks (and other UNIX people) have a lot of work to get it going. And there still seems to be confusion if or will Wayland require systemd, from what I have seen, no 100% clear direction from anyone.
- ilyt 4y ago
  Linux just adopting something BSD did - "look at them, we were there YEARS before them" Linux just doing their thing - why you don't include us ?
- wmf 4y ago
  Since 99% of users are on Linux anyway, that can't be the largest issue.
  - terrorOf 4y ago
    What a typical Linux user mindset! That IS one of the largest issues for non-Linux users. Linux is by large margin a niche OS in desktop market share. So it is no issue if all programs are developed only for Windows and/or Macintosh. Right?
    - wmf 4y ago
      I admit that appealing to capitalism isn't likely to advance the Unix desktop but the "we're all in this together" excessive portability attitude didn't produce good software either.
    - ilyt 4y ago
      ...what would wayland on windows even do ? Windows already does what wayland does, it would be entirely unnecesary layer
    - adra 4y ago
      And windows / mac are now minor players compared to android / IOS, and everything is a minor players vs web pages.
_vbnz 4y ago
Wayland has a massive loss in functionality (in the name of "security" and off-loading implementation details to compositors/window managers) compared to X11 though. Stuff like xdotool, screen sharing, clipboard sharing, etc. is much harder.
- markrages 4y ago
  sloppy-focus-follows-mouse is the feature that keeps me on X. A basic Unix feature forever, completely broken in Ubuntu's Wayland.
  - csdvrx 4y ago
    It works fine on Arch with the Hyprland compositor: putting the mouse from the terminal to waybar, you can still type in the terminal. When was the last time you really tried wayland? My first (and last) time was 2017. Much has changed! In a few years, when wine support is perfected, I think people dissing wayland will be seen as quaint as those insisting on a distribution "unsoiled" by systemd are seen today :)
    - markrages 4y ago
      I tried it up to last month in Ubuntu 22.04. I changed back because I got tired of the broken focus-follows-mouse and Ubuntu tracks the bug but doesn't fix it.
- recuter 4y ago
  Wait just a second mister. Is it a loss of functionality or is it just "much harder"?
  - ChuckNorris89 4y ago
    Why not both? It's a loss in functionality because it's much harder and the Linux desktop environment ecosystem is too niche, fragmented and underfunded to make the transition complete in a way that satisfies all camps so we end up in this traditional linux situation where several solutions coexist in parallel forever.
Aardwolf 4y ago
Simply the fact that systemd turned logs into a binary format that can't be read with standard tools, and this was not (easily? at all?) possible ti cgange made me really strongly dislike it. systemd has its own tool to read its binary log format, but I've already seen it corrupt its own logs and fail to read it. And did they do the binary format for efficiency? Get this: I've never seen anything be inefficient due to logging before systemd. Shortly after archlinux switched to it, something was being super slow. Sure enough, it was systemd not being able to handle the amount of ligs something produced. I think systemd is very opinionated, and something that opinionated should not be such basic piece of the linux landscape. There should be choices of individual components.
- deleted 4y ago
  [deleted]
- blibble 4y ago
  redhat seem to have tried their best to use systemd to turn Linux into Windows NT - over-complicated service manager - binary logs that are difficult to find - incomprehensible task scheduler - hidden caching dns resolution service - disk manager - network manager - login management - crappy ntp client all it needs is svchost.exe something that was 100% reliable is now about 98% reliable, and when it inevitably breaks it's completely un-introspectable by standard tooling I have yet to see a sysadmin write a 100% correct systemd service unit file
  - haileys 4y ago
    Describing SysV init as 100% reliable is a very rose-tinted view of history, I think.
    - deleted 4y ago
      [deleted]
    - blueflow 4y ago
      At least you can throw strace or the -x flag onto it and look at it.
ilyt 4y ago
For me personally X11 just got to the point where everything I want works out of the box so switching to wayland seems like entirely pointless experience. I'm also not a fan of attitude of moving support of even basic functionality like "take a screenshot" or "handle mouse/trackpad properly" into higher layers, it just feels like a lot of work duplication and moves that repetition of work to window managers
nine_k 4y ago
The problem is that systemd vs sysv-init is a false dichotomy. Systemd took over a ton of important non-init functionality, like DNS, logging, and interactive sessions. That could be fine if systemd did so in a nice and rock-solid way, but it was unpleasantly bug-ridden for years after being thrust on mainstream distros via a hard Gnome dependency. SysV-init sucks in many ways, it's well known, and I can personally attest to that. I don't want SysV-init to be perpetuated. There were, and are, viable alternatives to both, which are a less radical rework of the well-established Unix approaches around the area, do not overreach well past the init system scope, and are sane and well-functioning. For examples, see [upstart], [openrc], [s6], [runit]. I think that the prevalence of systemd was mostly achieved not through its technical merits (which undeniably exist) but through Red Hat's strongarming, because Red Hat wants certain things work in a way convenient for their business, and they have a powerful battering ram under their control, the Gnome DE. Fortunately Wayland is not being force-fed in such a way, because, much like systemd when it was introduced, it's still in many important regards not exactly ready. I, with my 25 years of running Linux on desktop, will gladly migrate to a better graphics architecture when in becomes adequate for my purposes, if the whole current Unix architecture is not obsoleted and replaced wholesale by that time. [upstart]: https://upstart.ubuntu.com/ https://upstart.ubuntu.com/ [openrc]: https://en.wikipedia.org/wiki/OpenRC https://en.wikipedia.org/wiki/OpenRC [s6]: https://www.skarnet.org/software/s6-linux-init/ https://www.skarnet.org/software/s6-linux-init/ [runit]: https://www.skarnet.org/software/s6-linux-init/ https://www.skarnet.org/software/s6-linux-init/
- justinsaccount 4y ago
  upstart: a broken design and abandoned by its author and canonical https://lwn.net/Articles/581548/ https://lwn.net/Articles/581548/ openrc: I don't believe openrc had a process supervision story 8-9 years ago. from what I recall at the time openrc was just a slightly better sysvinit. runit: I have a lot of experience with runit, and while it works, it has many footguns and is hard to use correctly. s6: a better runit with better footguns A great thing that more people should read, is https://lwn.net/Articles/578210/ https://lwn.net/Articles/578210/ from one of the Debian developers who voted to switch to systemd. It touches on things like the lack of adoption of upstart, and openrc not solving the problems they had.
yarg 4y ago
I downvoted for the edit.

ranger207 4y ago

Yeah, I'm a big fan of systemd but I can accept that when it first came out it was probably a lot worse than it is today. Similarly, Wayland has a bunch of good ideas, along with a bunch of functionality that isn't there yet. Of course, Wayland also has the problem that it's intentionally excluding some useful features that X had, like global hotkeys and screensharing. I think systemd and Wayland are actually opposites in this regard, where systemd was disliked at first and then turned liked, while Wayland was liked at first but is now turning to disliked

vetinari 4y ago
> Of course, Wayland also has the problem that it's intentionally excluding some useful features that X had, like global hotkeys and screensharing Screensharing has been supported for some time already. Some apps support it, some don't. It is up to the apps to use the respective APIs, the times of free reign over framebuffer is over.
- mort96 4y ago
  I mean, you can get screen sharing to work. But there are like 3 different incompatible "standards" for how to do it. There's no single simple answer to "how to record the screen in Wayland". This has been the state of screen sharing on Wayland for at least 7 years. I'm also very curious about what's envisioned for global hotkeys. Surely we don't expect people to manually go to their system settings and configure some command to run which talks to Discord over an IPC solution to start sharing my voice when I press my push to talk button and stop when I release the push to talk button? But "global hotkeys should be configured on a system basis, not an application basis" seems to be the reigning philosophy, despite being incredibly user and developer hostile.
  - vetinari 4y ago
    There is one standard and single simple answer: xdg-desktop-portal with pipewire. Some compositors might have implemented their own private APIs, but that is not a standard by definition. Global shortcuts are a bit more thorny, exactly for the reason you mentioned. You present one POV, the another is, that application-defined shortcuts are incredibly hostile, as they allow application to stomp on each other in the better case, or hijaack global state in the worse one. Some other operating systems do not allow it either, for the same reasons. The long-term solution could be defining api, that allows application to advertise global actions, and allow the user to configure shortcuts that might (or might not) call these, in some user-friendly way.
    - mort96 4y ago
      Isn't xdg-desktop-portal a flatpak thing? It claims to be so here: https://github.com/flatpak/xdg-desktop-portal https://github.com/flatpak/xdg-desktop-portal > A portal frontend service for Flatpak and possibly other desktop containment frameworks. When it comes to global shortcuts, I'm not saying it has a super easy solution, but it's something that it's essential to support. Wayland intentionally doesn't, and I can't see that changing in the short term (as you also agree)
      - vetinari 4y ago
        It is dbus api, and is able to work cross-namespaces (i.e. flatpak containers too). There no harm in using it in non-flatpak apps, at least you will be ready if your app ends up in flatpak. Wrt global shortcuts, I see that there is some work done. The intentional part isn't malice, as in not willing to implement it at all. It is about not implementing temporary solution, that will be quick and dirty, and then being stuck for supporting it for next 50 years.
        Bjartr 4y ago
        So kind of like Go and generics in that regard
- ilyt 4y ago
  > Screensharing has been supported for some time already. Some apps support it, some don't. It is up to the apps to use the respective APIs, the times of free reign over framebuffer is over. See, that's the problem, it's putting unnecessary load on everything else using it. It should have that API and it should have API that just allows dedicated app to allow/deny permissions to use that API. Not put everything on WM to duplicated more and more code for no good reason and making WM developer harder
chimeracoder 4y ago
> Yeah, I'm a big fan of systemd but I can accept that when it first came out it was probably a lot worse than it is today. The first "large" distro to switch from sysvinit to systemd was Arch, and that switch happened over ten years ago. The switch itself was quite rocky (the upgrade path was not particularly seamless, and while Arch users tend to be more tolerant of that sort of thing, it's worth mentioning). That said, even in 2012-2013, the end result once you completed the upgrade was significantly better than collectively expected. The original plan was to support both systemd and sysvinit (at least for a period of time), but that was quickly abandoned because not enough people wanted to actually maintain sysvinit packages, so support[0] ended up getting dropped very quickly. [0] Arch is a community project, so "support" is different from what you'd expect in (e.g.) RHEL, but it still has separations of what's considered supported and what's not.
- Conan_Kudo 4y ago
  > The first "large" distro to switch from sysvinit to systemd was Arch No. In terms of released to users, the first was Fedora; the second was Arch; then Mageia; then openSUSE. In terms of integrated into the distribution, the first was Fedora; the second was Mageia; then openSUSE; then Arch. Cf. https://en.wikipedia.org/wiki/Systemd#Adoption https://en.wikipedia.org/wiki/Systemd#Adoption
duskwuff 4y ago
> Of course, Wayland also has the problem that it's intentionally excluding some useful features that X had, like global hotkeys and screensharing... Screen sharing was always a weak point in X11, actually. VNC servers like x11vnc use absurd, inefficient hacks like periodically capturing fragments of the screen and checking for changes [1] -- while an extension to provide change notifications exists, it's been unreliable for ages [2] and the standard advice is to disable it. [1]: https://github.com/LibVNC/x11vnc#algorithm https://github.com/LibVNC/x11vnc#algorithm [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815909 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815909

kelnos 4y ago

I don't really see the parallels. For the past few months I've been investigating and working on porting parts of Xfce to be usable under Wayland. It's astonishing the number of features that are just not implementable at all on Wayland, at least not without inventing new non-standard Wayland protocols. (Another option is refactoring the desktop environment so all the individual components run in the same process as the compositor, and have access to the compositor's internals, but that's unacceptable for what are hopefully obvious reasons.) Even after over a decade, Wayland still seems quite immature and poorly thought-through. The protocol standardization seems geared toward satisfying GNOME's use-cases and ignoring everyone else's. The wlroots camp has gone their own way on a bunch of things, which is fine, but fractures the landscape a bit. Making Xfce fully Wayland means turning the window manager, xfwm4, into a Wayland compositor. For someone already familiar with xfwm4's code base, that's a year or more of work (and a requirement we'd have is that it would have to support both X11 and Wayland, further complicating things). Even if fixing inherent problems in X11 (security, graphics rendering, etc.) would require compatibility breaks, personally I would find that preferable to throwing the entire thing out and having to build (and build on) an entirely new system. As much as I disagree with JWZ's attitude on a lot of things, his description of most open source projects as a "Cascade of Attention-Deficit Teenagers" seems to be pretty accurate, at least here. X11 hasn't been improved and fixed because no one wants to maintain and improve X.org anymore, and the people who used to maintain it would prefer the fun of chasing and working on new shiny things, even if it means decades of new make-work for anyone working in the Linux GUI space. Don't get me wrong, I am the first one to cut off anyone at the knees who feels they are entitled to tell open source developers what to do with their time (though it gets a bit more complicated when many of those developers are employed by corporations to do this work). But I think it's pretty shitty to push the desktop in this direction and essentially force desktop and toolkit and application developers to choose between stepping up to maintain and build on X.org (something well out of most people's wheelhouse), or spend a huge amount of time porting to a new display system. Having said that, Wayland does have promise to be a better system than X11, even though it will likely take another decade to achieve feature parity with what we already have. So I'll continue to work on getting there eventually, even though I resent the fact that I have to learn an entirely new display system so I can work on reimplementing the same features again instead of building new features, fixing bugs, and making things more polished.

JoshTriplett 4y ago

I think in both cases, there's a similar switch of philosophy. We went from "there are a bunch of components glued together, and with enough glue you can solve anything (except an excess of glue)" (shell scripts for sysvinit vs declarative unit files for systemd; X11 apps that can do almost anything, vs the privileged compositor for wayland), to a model of "we wanted things to just work without having to install glue, so we integrated more functionality people wanted, if you want to swap it out you have to swap out the whole thing and keep up enough with all the other features people want" (e.g. you have to actually get the things you want into unit file directives, or get the features you want into the compositors people use; or you have to build a completely separate compositor or a separate init). That's a tradeoff. For my part, I'm thrilled that so many more things just work out of the box; however, it's discouraging for people whose features aren't covered yet, since they have to go work on integration rather than writing a specialized tool and encouraging people to glue that tool in. But the benefit of that is that once something is integrated, it just works, with no glue required.

WhatIsDukkha 4y ago
You are presenting this in certain way that I think veers into inaccurate and misleading in an attempt to smooth things over and be nice. What we had before systemd was - 90% glue code, reimplemented quite badly across X distributions. That glue code was, in practice, extremely brittle and very very unfun to attempt to keep even simple daemons running "portably" distribution to distribution. The other 10% was increasingly aging and ill maintained c code snippets. That was not a nice world for people actually using it. For people making stuff up about "the old days" that didn't actually participate in the misery of making basic systemv scripts, yeah it was composable and we lost something.
- zozbot234 4y ago
  The internals of systemd are just as brittle, and the model of unit file configuration does not really apply cleanly beyond the simplest cases. So editing unit files becomes an undocumented dark art.

jmclnx 4y ago

The largest issue with Wayland is it has "Linuxisms". That means no work was done by the Wayland people to make it portable to other UN*X. So the BSD folks (and other UNIX people) have a lot of work to get it going. And there still seems to be confusion if or will Wayland require systemd, from what I have seen, no 100% clear direction from anyone.

ilyt 4y ago
Linux just adopting something BSD did - "look at them, we were there YEARS before them" Linux just doing their thing - why you don't include us ?
wmf 4y ago
Since 99% of users are on Linux anyway, that can't be the largest issue.
- terrorOf 4y ago
  What a typical Linux user mindset! That IS one of the largest issues for non-Linux users. Linux is by large margin a niche OS in desktop market share. So it is no issue if all programs are developed only for Windows and/or Macintosh. Right?
  - wmf 4y ago
    I admit that appealing to capitalism isn't likely to advance the Unix desktop but the "we're all in this together" excessive portability attitude didn't produce good software either.
  - ilyt 4y ago
    ...what would wayland on windows even do ? Windows already does what wayland does, it would be entirely unnecesary layer
  - adra 4y ago
    And windows / mac are now minor players compared to android / IOS, and everything is a minor players vs web pages.

_vbnz 4y ago

Wayland has a massive loss in functionality (in the name of "security" and off-loading implementation details to compositors/window managers) compared to X11 though. Stuff like xdotool, screen sharing, clipboard sharing, etc. is much harder.

markrages 4y ago
sloppy-focus-follows-mouse is the feature that keeps me on X. A basic Unix feature forever, completely broken in Ubuntu's Wayland.
- csdvrx 4y ago
  It works fine on Arch with the Hyprland compositor: putting the mouse from the terminal to waybar, you can still type in the terminal. When was the last time you really tried wayland? My first (and last) time was 2017. Much has changed! In a few years, when wine support is perfected, I think people dissing wayland will be seen as quaint as those insisting on a distribution "unsoiled" by systemd are seen today :)
  - markrages 4y ago
    I tried it up to last month in Ubuntu 22.04. I changed back because I got tired of the broken focus-follows-mouse and Ubuntu tracks the bug but doesn't fix it.
recuter 4y ago
Wait just a second mister. Is it a loss of functionality or is it just "much harder"?
- ChuckNorris89 4y ago
  Why not both? It's a loss in functionality because it's much harder and the Linux desktop environment ecosystem is too niche, fragmented and underfunded to make the transition complete in a way that satisfies all camps so we end up in this traditional linux situation where several solutions coexist in parallel forever.

Aardwolf 4y ago

Simply the fact that systemd turned logs into a binary format that can't be read with standard tools, and this was not (easily? at all?) possible ti cgange made me really strongly dislike it. systemd has its own tool to read its binary log format, but I've already seen it corrupt its own logs and fail to read it. And did they do the binary format for efficiency? Get this: I've never seen anything be inefficient due to logging before systemd. Shortly after archlinux switched to it, something was being super slow. Sure enough, it was systemd not being able to handle the amount of ligs something produced. I think systemd is very opinionated, and something that opinionated should not be such basic piece of the linux landscape. There should be choices of individual components.

deleted 4y ago
[deleted]
blibble 4y ago
redhat seem to have tried their best to use systemd to turn Linux into Windows NT - over-complicated service manager - binary logs that are difficult to find - incomprehensible task scheduler - hidden caching dns resolution service - disk manager - network manager - login management - crappy ntp client all it needs is svchost.exe something that was 100% reliable is now about 98% reliable, and when it inevitably breaks it's completely un-introspectable by standard tooling I have yet to see a sysadmin write a 100% correct systemd service unit file
- haileys 4y ago
  Describing SysV init as 100% reliable is a very rose-tinted view of history, I think.
  - deleted 4y ago
    [deleted]
  - blueflow 4y ago
    At least you can throw strace or the -x flag onto it and look at it.

ilyt 4y ago

For me personally X11 just got to the point where everything I want works out of the box so switching to wayland seems like entirely pointless experience. I'm also not a fan of attitude of moving support of even basic functionality like "take a screenshot" or "handle mouse/trackpad properly" into higher layers, it just feels like a lot of work duplication and moves that repetition of work to window managers

nine_k 4y ago

The problem is that systemd vs sysv-init is a false dichotomy. Systemd took over a ton of important non-init functionality, like DNS, logging, and interactive sessions. That could be fine if systemd did so in a nice and rock-solid way, but it was unpleasantly bug-ridden for years after being thrust on mainstream distros via a hard Gnome dependency. SysV-init sucks in many ways, it's well known, and I can personally attest to that. I don't want SysV-init to be perpetuated. There were, and are, viable alternatives to both, which are a less radical rework of the well-established Unix approaches around the area, do not overreach well past the init system scope, and are sane and well-functioning. For examples, see [upstart], [openrc], [s6], [runit]. I think that the prevalence of systemd was mostly achieved not through its technical merits (which undeniably exist) but through Red Hat's strongarming, because Red Hat wants certain things work in a way convenient for their business, and they have a powerful battering ram under their control, the Gnome DE. Fortunately Wayland is not being force-fed in such a way, because, much like systemd when it was introduced, it's still in many important regards not exactly ready. I, with my 25 years of running Linux on desktop, will gladly migrate to a better graphics architecture when in becomes adequate for my purposes, if the whole current Unix architecture is not obsoleted and replaced wholesale by that time. [upstart]: https://upstart.ubuntu.com/ https://upstart.ubuntu.com/ [openrc]: https://en.wikipedia.org/wiki/OpenRC https://en.wikipedia.org/wiki/OpenRC [s6]: https://www.skarnet.org/software/s6-linux-init/ https://www.skarnet.org/software/s6-linux-init/ [runit]: https://www.skarnet.org/software/s6-linux-init/ https://www.skarnet.org/software/s6-linux-init/

justinsaccount 4y ago
upstart: a broken design and abandoned by its author and canonical https://lwn.net/Articles/581548/ https://lwn.net/Articles/581548/ openrc: I don't believe openrc had a process supervision story 8-9 years ago. from what I recall at the time openrc was just a slightly better sysvinit. runit: I have a lot of experience with runit, and while it works, it has many footguns and is hard to use correctly. s6: a better runit with better footguns A great thing that more people should read, is https://lwn.net/Articles/578210/ https://lwn.net/Articles/578210/ from one of the Debian developers who voted to switch to systemd. It touches on things like the lack of adoption of upstart, and openrc not solving the problems they had.

yarg 4y ago

I downvoted for the edit.