Not really a relevant thing to talk about here, but I find there's this trend in Linux ecosystem that people are explicitly implementing more and more policies on the code level instead of making flexible abstractions and data-fying user decisions. I'm not talking about exposing user-friendly configuration options, but is about mechanism-over-policy. The presenter mentioned "use-case over mechanism/policy", but, given a good mechanism, use-cases are just policies.<p>Although I do understand the value of the current approach in the industry (i.e. MVP), I think it does come with a cost - you get a large corpus of low density code that gives a lot of surprises in many different corners. Redhat-funded projects are really leading this trend (I'm looking at you systemd, the project). If you read their code, you'll instantly notice that they are becoming more and more labor-intensive, and less and less hacker-friendly. We are losing smartness for the sake of grunting.<p>Some might think Wayland is a smart approach, but it's actually not. It's mostly just pure grunting - a showcase of large engineering horsepower. It's a large-scale refactoring & optimization of the modern day X11 desktop ecosystem. Everything works in the exact same way, but things happen in <i>slightly</i> different places, and some features are banned by policy (arbitrarily outlined by wayland devs). These missing <i>special</i> features now need to be implemented explicitly as "protocols".<p>Now, I really want to ask - where are we heading here? Are we really stepping forward? I don't think so. We're just going side ways.
Waiting for the steam client to have wayland->x11 fallback runtime tables of functions. xwayland is there for software which has no more technical maintenance (not the steam client, yet).<p>But I plan to write my own wayland compositor, probably based on linux dma-buf, like the one running on the steam deck (basically an improved fork of valve one).<p>And in assembly, x86_64 at first, but I am lurking on risc-v.
This talk hurts to watch.<p>All the block diagrams prominently putting systemd-logind between X11/Wayland-compositor are <i>very</i> misleading, and seems likely to create more misinformed ire for systemd.<p>systemd-logind is basically just an arbiter of the seats for reasons like you can only have one drm-master on a given drm device at a time. It's <i>not</i> involved in all X11/Wayland-compositor<->kernel interactions. Once the seat has been acquired it gets out of the way. That should not be some huge box right in the middle of the two.<p>You can trivially confirm this by stracing systemd-logind on your system while interacting with your desktop. It's just sitting idle in epoll_wait().
I really wanted to like wayland as the 'next big thing', but for the life of me I can't.<p>* I've yet to see any actual, honest to god benefits for the <i>end user</i>. Literally everything I've seen is the fact that it makes development easier for the wayland devs and harder for literally everyone else.<p>* Trying to use a wayland window manager outside of gnome or kde leaves you reliant on a bunch of hackish utilities (redshift, taskbar, screen recording / sharing, etc) which are available on AUR and basically no where else<p>* Scaling and perf for xwayland apps (i.e. most apps) is pretty bad.<p>Is wayland the future? Maybe, but I'll happily use xorg for the next decade if needed until the user experience is rock solid over on wayland.
I'd rather not. More people should write wayland clients though, and complain to the makers of existing compositors where they fall short. Which is in a lot of places, and they are definitely not sufficiently robust.