That aside it gives similar vibes to systemd. Honestly, not a fan of these userland utilities/systems that just throw everything into the kitchen sink.
It really effects the modularity of things when suddenly things start depending on them.
This not to say X does not have it's own problems and I even find it a bit on the monolithic side.
And generally I think it’s really healthy for everyone when developers boldly refuse to take on too much. The result is more focused work and less maintainer burnout. It also clears the way for someone else to pick up the slack.
If xorg support on apple silicon is important to you, you’re welcome to spearhead that work yourself. Nobody else will do it. And at a risk of sounding rude, opensource isn’t a democracy. I don’t get a say in what you work on, and you don’t get a say in what the asahi linux team works on.
Things can be incredibly modular and depend on each other. In reality, the more modular something is the more dependable things are on each other.
Tools before systemd also depended on each other.
Systemd is plenty modular, its just managed in one project. Just like BSDs. So it is modular and depends the different parts depend on each other.
However, just considering wlroots this is not the only library probably (the most popular probably), but if you want to switch to using something else good luck.
Also the wayland team definitely has opinions about certain things and that definitely rubs some people the wrong way, but more importantly this makes some things not as easily doable in wayland.
Linux took off because different people could work on parts of it independently.
That is the case because the overall architecture is modular. You can rip out nearly any part and replace it with another one if it does not suit you. These parts were developed in different projects that could be agnositic towards other projects.
If you increase dependencies on very specific parts of other projects, you stop being agnostic. You lose huge amounts of velocity and you lose potential developers because setting up your project and testing is now much more complicated.
If the Linux world continues to make these mistakes, Linux development will not only slow down, we will see a lot of parts rotting away.
The kernel being a monolith is less of an issue, because there are enough companies that care about it. These companies can pour resources into the mentioned problems like setup and testing.
Desktop Linux does not benefit from that because most companies only care about Linux as a server environment.
Everyone -- everyone -- with deep expertise on how graphics works has the same advice: Forget X. Use Wayland. Period. The X developers largely stopped developing X and put all their effort into Wayland.
Wayland is the future. You can either be on that train or watch all your software bitrot as new software just stops supporting X.
I don't give a fuck about knowledge, I want a working system and Wayland has this misfeature that it has been declared "complete" long before any DE had the chance to reinvent the X APIs it dropped.
> You can either be on that train or watch all your software bitrot as new software just stops supporting X.
The question is what is it going to support instead? Wayland moved most of the X features into the hands of the desktop environments on one end and graphics drivers on the other end. The gigantic fuck up with NVIDIA compatibility was already a pain in the ass, do I even want to know how many GNOME and KDE versions (just to mention the big two) will need special treatment to make things work?
Those with expertise in this area have chosen Wayland. If Wayland isn't doing it for you, make it better. File bug reports, write some code. Just realize that there is an active, interested community surrounding Wayland, not so much for X anymore.
Wayland implementations only depend on the kernel’s abstractions for video cards/buffers. Blame only NVIDIA that they were unable to support the kernel for so long. Xorg just had a hacked userspace support for nvidia cards via a binary proprietary patch — is that really the tooling you would want to use?
It's an implementation detail users don't care about. Users care about being able to complete tasks. For that they need good documentation, plenty of examples online, good availability of flexible software tools, and a good bonus is non-fragmented ecosystem for the basis of the system they're configuring/extending ...
Wayland compositor kitchen sink approach is kinda working against easy adoption here. It's like now there are 8 different Xorg servers each with different bugs protocol feature support, configuration mechanisms, and driver compatibility issues.
Having seen cycles like this over and over. Some project develops over decades which included many corner cases that need covered. It then becomes difficult to work with or adapt to some newer "things" (in this case modern gpus).
So people start to look at making a new project "taking" the bits they deem in important or adopting a strategy to work better with those newer things. Then after many years the project in some aspects starts to resemble a state of what it replaced. Repeat...
Now maybe I should have been a little more explicit I just kinda surprised how blunt the developers of this distro are being here. Having just decided to play around with wayland again just this last month and still noticing issues. I can see plenty of reasons why people would not want to switch just yet.
Then I will consider using it.
So far all the software I use runs in X.
It has been over a decade and I keep finding myself disabling Wayland still. That said, Linux is not my primary driver, I just can not be bothered.
Even in the hand-edit modelines days, even then I never saw X itself crash if it started at all.
Modern Windows, by contrast, knows how to restart a crashed video driver, without the clients even knowing anything has happened.
In fact, I don’t remember any crashes from the past 3 years from continuous usage.
The X server is restarted, my apps are still open.
Then you should love Wayland, since it explicitly keeps its slope as small as possible, unlike X11. Hence why a bunch of stuff is done separately from Wayland, e.g. screen capture.
Compositor either has to setup writeback if hardware supports it, or do the composition in software during capture, and provide the buffers to a recording app.
In that it solves a hard problem well?
> not a fan of these userland utilities/systems that just throw everything into the kitchen sink
So I guess you dislike Xorg, then, and prefer the much more “do one thing well” approach of Wayland? Wayland is a tiny protocol only, that builds on kernel APIs to manage buffers instead of reimplementing it in userspace and it’s implementations are much more easier to reason about than the truly monolithic XOrg - which included everything from printing to whatnot.
Asahi Linux is way younger, moves way faster, and I hope they don't share the same mentality. Also, they are much smaller, and can't spread themselves too thin. If I were an Asahi user, and cared about X.org there, I'd seriously consider helping fix issues with it somehow.