5 ms·

As a systemd user but Wayland "hater", to me the big difference is that you can adopt systemd without losing functionality - e.g. you can configure systemd to r

by vidarh 1y ago

As a systemd user but Wayland "hater", to me the big difference is that you can adopt systemd without losing functionality - e.g. you can configure systemd to run sysV init style init scripts if you insist and no functionality is lost. The "complaints" in the linked article, are minor and about options that can just be turned off and that are offering useful additional capabilities without taking away the old. Whereas with Wayland the effort to transition is significant and most compositors still have limitations X doesn't (and yes, I realise some of those means X is more vulnerable) - especially for people with non-standard setups. Like me. I use my own wm. I could start with ~40-50 lines of code and expand to add functionality. That made it viable. I was productively using my own wm within a few days, including to develop my wm. With Wayland, even if I start with an existing compositor, the barrier is far larger, and everything changes. I'm not going to do that. Instead I'll stick with X. The day an app I actually depend on stops supporting X, I'll just wrap those apps in a Wayland compositor running under X. And so I won't be writing blog posts about how much I hate Wayland, and hence the quotes around "hater" above. But maybe I will one day write some about how to avoid running Wayland system-wide. If Wayland gave me something I cared about, I'd take the pain and switch. It doesn't. Systemd did, so even if I hadn't liked it better than SysVinit, I'd still have just accepted the switch. If I one day give up Xorg, my expectation is that it'll be a passive-aggressive move to a custom franken-server that is enough-of-X to run modern X apps coupled to enough-of-Wayland to run the few non-X-apps I might care about directly (I suspect the first/only ones that will matter to me that might eventually drop X will be browsers), just because I'd get some of the more ardent Wayland proponents worked up.

r14c 1y ago
wayback has you covered https://gitlab.freedesktop.org/wayback/wayback https://gitlab.freedesktop.org/wayback/wayback the idea here is to make it easy for x-based wms to keep working like they always have!
- vidarh 1y ago
  That's interesting, but I really would rather write something stripped down with X as the base, though. This might be a good intermediary step, though.
  - r14c 1y ago
    I mean unless you're going to commit to maintaining xlibre or something, wayback seems like the future for x-based desktops. > [wayback] is intended to eventually replace the classic X.Org server, thus reducing maintenance burden of X11 applications, but a lot of work needs to be done first.
    - vidarh 1y ago
      As I said, I'd rather write something from scratch when the time comes that Xorg becomes a challenge.
  - bsder 1y ago
    Wayback is really the only good step in the X11 space I've seen. They could use your help. It also has the benefit that if it gets enough traction, then you can displace the backend off of Wayland and go directly to hardware. Killing Wayland would just be a bonus...
    - vidarh 1y ago
      It just feels like the wrong approach to me. Ripping the buffer management/KMS/DRI part out of a Wayland compositor as a starting point is reasonable, but if you pull XWayland along you pull most of Xorg along, with most of the maintenance / legacy hassle that brings. An X server selectively deprecating older functionality can be lean. There are lots of the protocol you can just ignore, and what's left is fairly easy to implement. Time consuming, but easy.
      - bsder 1y ago
        > An X server selectively deprecating older functionality can be lean. Is that actually true? The big problem is that Xlib uses a lot of the dusty corners and the people using X11 apps expect those dusty corners to work. And Xlib is very, very, very badly architected in many places and you still have to do something sane or the apps won't work. If you get Xcb right, you at least pick up Qt and that gets you probably 80+% of the modern apps.
gf000 1y ago
> With Wayland, even if I start with an existing compositor, the barrier is far larger, and everything changes. I mean, no one puts a gun against your head to use Wayland, X will be on life support for decades and will likely work without any issue. But with this stance, no evolution could ever happen and every change would be automatically "bad". Sure, changes have a downside of course, but that shouldn't deter us in every case.
- vidarh 1y ago
  Plenty of evolution can happen. The problem with Wayland to me is that it's not evolution, but a step backward. It's forcing a tremendous amount of boilerplate and duplication of code. X can evolve both by extensions and by "pseudo extensions" that effectively tell the server it's okay to make breaking changes to the protocol. There are also plenty of changes you could just make and accept the breakage because the clients it's break are limited. I don't mind breaking changes if they actually bring me benefits I care about, but to me Wayland is all downside and no upsides that matter to me.
gerdesj 1y ago
I remember the good old days of xfree86. It was arse but mostly worked OK on a PC. Then this blasted Xorg thing rocked up and it was worse for a while! Nowadays I can barely remember the last time I had to create an xorg.conf. Wayland has a few years to go yet and I'm sure it will be worth the wait. For me, it seems to work OK already.
egorfine 1y ago
> you can adopt systemd without losing functionality Nope. No simple way to run a single simple script on boot, which lived in /etc/rc.local for decades. Create a unit instead. It's not much but systemd is full of little annoyances like this one. > [] offering useful additional capabilities without taking away the old. Once they introduce capabilities, the old quickly becomes irrelevant due to sheer mass of systemd crowd. After they have introduced timers, it suddenly became clear that cron, which served us perfectly well for decades is now cubersome and seriously lacking. The same can be said about syslog/journald drama. Now they decided they want sudo replaced. Up next: something else that you cannot even think of, is already on their radar.
- vidarh 1y ago
  > Nope. No simple way to run a single simple script on boot, which lived in /etc/rc.local for decades. Have you tried? At least on Debian and Ubuntu, if /etc/rc.local exists and is executable, systemd-rc-local-generator will auto-generate an rc-local.service unit that will run rc.local. If the unit isn't visible for you, create an /etc/rc.local file. chmod +x it. Then run "sudo systemctl enable rc-local.service". Then try "systemctl status rc-local.service". If your distro has the relevant generator, you'll see something with a line saying "Drop-In: [some path]". If so, "systemctl start rc-local" should run your /etc/rc.local, and/or it will run after reboot. In other words, you can easily have /etc/rc.local running on boot. On Debian and Ubuntu, you can do ls /usr/lib/systemd/system/rc* to see the compatibility options for SysV init that are available to you. If your distro doesn't ship with an rc.local drop-in and generator, then put this in /etc/systemd/system/rc-local.service: ``` [Unit] Description=/etc/rc.local compatibility ConditionFileIsExecutable=/etc/rc.local After=network.target [Service] Type=forking ExecStart=/etc/rc.local start TimeoutSec=0 RemainAfterExit=yes GuessMainPID=no StandardOutput=journal+console StandardError=journal+console ``` Then run "systemctl enable rc-local.service". Now, as long as /etc/rc.local is executable, it will be run on startup after your network has come up (you can change the "After" if you want to trigger it based on another condition instead) > clear that cron, which served us perfectly well for decades is now cubersome and seriously lacking. Cron is severely limited compared to systemd timers, but nothing stops you from also running a cron. I have anacron running on my systemd setup because I agree it serves a lot of needs perfectly well. It coexists just fine and lets me use a cron for the simple stuff, and systemd timers for things that requires conditions cron can't handle, such as e.g. advanced preconditions.

by vidarh 1y ago

r14c 1y ago

wayback has you covered https://gitlab.freedesktop.org/wayback/wayback https://gitlab.freedesktop.org/wayback/wayback the idea here is to make it easy for x-based wms to keep working like they always have!

vidarh 1y ago
That's interesting, but I really would rather write something stripped down with X as the base, though. This might be a good intermediary step, though.
- r14c 1y ago
  I mean unless you're going to commit to maintaining xlibre or something, wayback seems like the future for x-based desktops. > [wayback] is intended to eventually replace the classic X.Org server, thus reducing maintenance burden of X11 applications, but a lot of work needs to be done first.
  - vidarh 1y ago
    As I said, I'd rather write something from scratch when the time comes that Xorg becomes a challenge.
- bsder 1y ago
  Wayback is really the only good step in the X11 space I've seen. They could use your help. It also has the benefit that if it gets enough traction, then you can displace the backend off of Wayland and go directly to hardware. Killing Wayland would just be a bonus...
  - vidarh 1y ago
    It just feels like the wrong approach to me. Ripping the buffer management/KMS/DRI part out of a Wayland compositor as a starting point is reasonable, but if you pull XWayland along you pull most of Xorg along, with most of the maintenance / legacy hassle that brings. An X server selectively deprecating older functionality can be lean. There are lots of the protocol you can just ignore, and what's left is fairly easy to implement. Time consuming, but easy.
    - bsder 1y ago
      > An X server selectively deprecating older functionality can be lean. Is that actually true? The big problem is that Xlib uses a lot of the dusty corners and the people using X11 apps expect those dusty corners to work. And Xlib is very, very, very badly architected in many places and you still have to do something sane or the apps won't work. If you get Xcb right, you at least pick up Qt and that gets you probably 80+% of the modern apps.

gf000 1y ago

> With Wayland, even if I start with an existing compositor, the barrier is far larger, and everything changes. I mean, no one puts a gun against your head to use Wayland, X will be on life support for decades and will likely work without any issue. But with this stance, no evolution could ever happen and every change would be automatically "bad". Sure, changes have a downside of course, but that shouldn't deter us in every case.

vidarh 1y ago
Plenty of evolution can happen. The problem with Wayland to me is that it's not evolution, but a step backward. It's forcing a tremendous amount of boilerplate and duplication of code. X can evolve both by extensions and by "pseudo extensions" that effectively tell the server it's okay to make breaking changes to the protocol. There are also plenty of changes you could just make and accept the breakage because the clients it's break are limited. I don't mind breaking changes if they actually bring me benefits I care about, but to me Wayland is all downside and no upsides that matter to me.

gerdesj 1y ago

I remember the good old days of xfree86. It was arse but mostly worked OK on a PC. Then this blasted Xorg thing rocked up and it was worse for a while! Nowadays I can barely remember the last time I had to create an xorg.conf. Wayland has a few years to go yet and I'm sure it will be worth the wait. For me, it seems to work OK already.

egorfine 1y ago

> you can adopt systemd without losing functionality Nope. No simple way to run a single simple script on boot, which lived in /etc/rc.local for decades. Create a unit instead. It's not much but systemd is full of little annoyances like this one. > [] offering useful additional capabilities without taking away the old. Once they introduce capabilities, the old quickly becomes irrelevant due to sheer mass of systemd crowd. After they have introduced timers, it suddenly became clear that cron, which served us perfectly well for decades is now cubersome and seriously lacking. The same can be said about syslog/journald drama. Now they decided they want sudo replaced. Up next: something else that you cannot even think of, is already on their radar.

vidarh 1y ago
> Nope. No simple way to run a single simple script on boot, which lived in /etc/rc.local for decades. Have you tried? At least on Debian and Ubuntu, if /etc/rc.local exists and is executable, systemd-rc-local-generator will auto-generate an rc-local.service unit that will run rc.local. If the unit isn't visible for you, create an /etc/rc.local file. chmod +x it. Then run "sudo systemctl enable rc-local.service". Then try "systemctl status rc-local.service". If your distro has the relevant generator, you'll see something with a line saying "Drop-In: [some path]". If so, "systemctl start rc-local" should run your /etc/rc.local, and/or it will run after reboot. In other words, you can easily have /etc/rc.local running on boot. On Debian and Ubuntu, you can do ls /usr/lib/systemd/system/rc* to see the compatibility options for SysV init that are available to you. If your distro doesn't ship with an rc.local drop-in and generator, then put this in /etc/systemd/system/rc-local.service: ``` [Unit] Description=/etc/rc.local compatibility ConditionFileIsExecutable=/etc/rc.local After=network.target [Service] Type=forking ExecStart=/etc/rc.local start TimeoutSec=0 RemainAfterExit=yes GuessMainPID=no StandardOutput=journal+console StandardError=journal+console ``` Then run "systemctl enable rc-local.service". Now, as long as /etc/rc.local is executable, it will be run on startup after your network has come up (you can change the "After" if you want to trigger it based on another condition instead) > clear that cron, which served us perfectly well for decades is now cubersome and seriously lacking. Cron is severely limited compared to systemd timers, but nothing stops you from also running a cron. I have anacron running on my systemd setup because I agree it serves a lot of needs perfectly well. It coexists just fine and lets me use a cron for the simple stuff, and systemd timers for things that requires conditions cron can't handle, such as e.g. advanced preconditions.