The discussion of phoronix often goes towards flamewar. I hope the discussion here is more civil :)
I can understand they want to test their GPU drivers only against the main Wayland compositors. Xorg is quite another beast to support. For all I know, it might come into the context when most bugs have been ironed out in the GPU drivers.
I do hope people do not take it as general advice. Not all desktop environments have a Wayland compositor, some are quite buggy and many apps don't work yet with Wayland. I am using Xfce and for the next year at least I will be on Xorg. I do hope Wayland gets better, but it has been an undertaking of many years already. The rest of the process won't be much faster I suspect.
It is difficult to avoid flamewars when the original post itself contains flaimbait like:
Yes, not every random app and feature you use on Xorg will have a Wayland equivalent. Deal with it. The major players in desktop Linux have decided it's time to move on from Xorg, and if you want to go against the tide you're on your own.
Not to mention that talking about 'the major players in desktop Linux' is completely against what the OS ethos was supposed to be about; he said the quiet part out loud, and people strike back; it is only fair.
I don't think people understand that Xorg is truly dead. Wayland is essentially X12. Everyone who used to work on X now works in Wayland. You should not have an expectation that Xorg will keep working. You should not have an expectation that bugs will be fixed. You should not have an expectation that new hardware will work well with Xorg.
If you want to go against the tide, you truly are on your own. You should expect less and less things to work over time as Xorg's code rots, X backends for GUI frameworks rot, and new hardware and drivers expose X bugs which won't be fixed.
If this doesn't scream "it's time to move away", I don't really know what does. Nobody can force anyone to move of course. But the writing truly is on the wall.
My desktop not working, or apps being blurred, or slower, or my mouse cursor stuttering, or screen sharing not working, or Java apps not getting the hidpi settings. That’s what drives me away from Wayland, and all of those happened to me.
I don’t think anybody is against Wayland “just because”. When it matures and app support is better, we’ll switch.
I understand that it might not work for you. That's unfortunate. But you shouldn't expect Xorg to keep working for you either. The time where Xorg is a well-maintained project is past us. That's the point.
Is it, though? Wayland has solved a bunch of problems that I had become used to under Xorg to the point of not noticing anymore, and even though I bumped into new issues on Wayland at first (and tbh there are still few open out there), going back to Xorg nowadays feels like going backwards.
I mean, it's funny that you say so, because with the exception of "more environments", I've observed the exact opposite :)
I'm a simple user with simple needs, though apparently that's already pushing the limits of what Xorg can deliver: I have a high-DPI laptop scaled 140%, and a secondary high-res/average-DPI display at 100%. Mixing scaling factors has never worked well under Xorg (rendering glitches with ghost lines, applications like drop down terminals not knowing the dimensions of their viewport when opened on one screen and then or the other). And I'm not even getting into the better handling of discrete GPUs or the much smoother scrolling/animations that give it a better polish.
Xorg totally made sense in the context in which it was invented (in the long forgotten era of server-side rendering), but with applications rendering their own widgets and passing pixmaps to the compositor, Wayland is mostly about cutting the middleman and breaking-off with the obsolete/unmaintained/insecure bits. If you grab a distro with the latest gnome/kde, you should be at a point where Wayland really is only upsides.
Nope, yes as of now, no wayland is only the things needed instead of being a useless middleman between processes and compositors, has more “things” instead, what environments?
I do not expect anything from any OSS software I don’t pay for, and for sure I do not expect Asahi devs to work on Xorg. Their stance is clear. Totally fine for me.
I’m periodically re-evaluating Wayland for my own needs, and so far I chose Xorg every time. I need to do work on my ws, so I need to prioritize stableness to features. I don’t care about fancy features and I’d be ok with KDE 3.5.
Ironically, what should work way better on wayland rather than xorg (hidpi, especially with fractional settings) still works better on xorg for me.
Look at the developers who have historically been working on Xorg. Look at the organizations and projects which have historically been working on Xorg. Look at what they're working on now. Look at what Red Hat and GNOME and KDE are up to. They're not working on Xorg, except for parts relevant for XWayland.
The statement "Xorg isn't well-maintained anymore" isn't an attempt at a self-fulfilling prophecy. It's a statement of fact. The people and companies and organizations who used to do the work on X11 are now working on Wayland. The same people and groups are doing the same kind of work, just on a different protocol.
Xorg releases were done almost exclusively by Red Hat, which just recently announced that they won’t support X for their next version. So.. no, it is objectively not maintained.
Apps being blurred are old x apps running in xwayland compat mode, they are not slower at all (full-screen games can circumvent the compositor for a long time now), and the rest are not typical at all.
> Not to mention that talking about 'the major players in desktop Linux' is completely against what the OS ethos was supposed to be about; he said the quiet part out loud, and people strike back; it is only fair.
He also said[1]:
> We don't have the time
And then he said[2]:
> If you want to change that, better volunteer yourself :)
Rather, I think he's saying the loud part out loud. OSS can have an opinion, and you're free to modify it to suit your own opinion.
Disingenuous. If someone turns up willing to volunteer, there will be some other excuse. They do not want volunteer effort to do something they don't want done.
Even fully baked patches will turn out to require "incompatible architectural changes".
In social justice (a key component of how open source projects operate today) we have this concept of "doing the work", which is as much about humbling and decentering yourself and recognizing that there is a community of others involved whom your efforts must support, as it is about putting in the actual effort.
Eric S. Raymond likes to contribute to open source projects in the form of fully realized, thoroughly architected megapatches that totally upend all the assumptions about how a system/subsystem works and behaves, along with a long lecture about why his patch should be accepted which boils down to "I'm ESR, I know how this bit should be designed much better than you, so there". That is the exact opposite of doing the work. Doing the work involves empathy and respect for the needs and experiences of others.
If you want Asahi Linux to support Xorg, you have three choices:
* Accept things as is.
* Fork the project.
* "Do the work". Convince the Asahi maintainers, in terms they are likely to appreciate, why Xorg inclusion is a good idea and who will be assuming the maintenance burden with little to no effort on their part. Then try to merge your patches.
That's a horrible way to communicate something to your users, FOSS or not. A simple email in a mailing list that says they are dropping support for Xorg would have been sufficient.
At the end of the article there’s a list of complaints about X, and coincidentally it’s a list of things X users probably won’t care about.
your desktop tears
screen capture is dog slow
your media keys stop working one day
your speakers sound terrible and tinny or don't even work at all by default (once we ship that)
VSync is broken
your display looks duller and the colors muted
It’s kind of funny though how apparently Wayland is another hydra that tries to get involved with sound and other things it doesn’t really have business with.
Maybe but I don't care, I care about a desktop that works. I went back to X on my laptop after testing Wayland because something important didn't work but I can't remember what.
> screen capture is dog slow
I never realized it.
> your media keys stop working one day
Brightness controls work with some NVIDIA drivers and don't with others but there are workarounds: hotkeys bound to brightness control scripts.
I think that the next three points are specific to the work they are doing on Macs so they don't apply to my experience.
> your speakers sound terrible and tinny or don't even work at all by default (once we ship that)
> That whole blog post is angry, misinformed about the target market, and talking to no one while telling everyone to eff off. And we shall - not an issue at all.
I like the honesty of this take. I think if we’re honest with ourselves as self funded opensource developers, our projects really have a target market of 1. And you’re right - it’s not you. If the entire target market (the asahi Linux dev team) want to use wayland, that is absolutely their prerogative. You and I aren’t customers of theirs. Our needs don’t pay their bills.
Asahi’s target market is neither of those. Asahi Linux is a distro for Apple Silicon Macs. Which means their target market is like-minded tinkerers with too much cash laying around, everyone else would either use macOS, or any other (cheaper, saner) x86_64 PC.
I did just make up 2 categories who use Linux at home, from the air I've been breathing for my 30+ years of working with people who run Linux at home. That is how opinions based on experience work. Do you have a point to make besides "I want to be contrarian which makes me superior?"
Wayland has lots of problems still, and it's been being worked since what 2008.
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.
That might be true, but I believe the Asahi Linux team when they say they don’t have time to properly support for both xorg and wayland. It’s their prerogative as opensource developers to decide what they spend their time working on.
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.
Never did I say what they should or shouldn't do. Having just tried giving wayland an other try last month for the heck of it and still noticing issues. I just found it surprising how blunt they are about this topic. I like to code and code even for fun, but I definitely do understand that people only have so much time to dedicate to something.
Do they even have time to properly support Wayland? It is also fundamentally broken, just in different ways. It is the usual FOSS problem of mobody really being responsible for anything, and nobody owing anyone anything to boot. Add to that the unnecessary complications of making it a protocol from the beginning, instead of deriving a protocol from a succesful piece of software.
I think it often is more like "We have issue supporting xorg, if you want us to support xorg it is on you to find a solution to our problems; we might support you but likely wont put our resources toward it"
Alyssa Rosenzweig probably forgot more about graphics on Linux than you (or I) will ever know.
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.
Predicting the future is a hard thing. It could be the future or something else might pop up that becomes the new hotness.
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.
> Alyssa Rosenzweig probably forgot more about graphics on Linux than you (or I) will ever know.
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?
The problem is, most of the people fulminating about X being deprecated know somewhere between jack and squat about how graphics actually works now and why X is holding us back due to the enormous impedance mismatch between it and modern graphics stacks.
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 is not declared completed, it has versioned protocols. Anything deemed worthy enough and on which this bazaar style of governance can agree on will be added to a newer version/extension.
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?
X are just userland APIs/protocols. Wayland is also just another set of userland APIs/protocols.
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.
Welcome to the bazaar vs cathedral. Linux doesn’t have a cathedral, and none of its benefits/disadvantages either. One “benefit” of the cathedral approach would be dictatorial control of the project, which could share resources better - apple can just say that this framework/whatever is deprecated in the next version and that’s it. Linux’s model is nothing like that.
Compared to X, were your display server, window manager and compositor are generally distinct processes/components. This is not normally the case on wayland normally they are developed as one unit. Like consider gnome they decided to handle everything themselves. There are some wrappers/libraries that try to make developing some things separately at least easier such as wlroots.
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.
The categorical mistake that underlies the issues here is much bigger actually.
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.
I was talking about Linux as an OS platform, not just the kernel. The entire discussion here is about Wayland and its impact on the rest of userland, not the kernel.
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.
Generally speaking I agree with you. However, in case of systemd I think it is very modular. I think we're at a point now where it's convenience and reliability outweigh the negatives.
It also brings a certain common element to different distros, making it a bit easier for people new to Linux distributions. They don't have to hyperspecialize now.
Systemd has become reasonably good by now, 13 years after the release. Same with PulseAudio, now that it has been replaced by a sane implementation in Pipewire. BTRFS still sort of has rough edges, 14 years since initial release. Red Hat take their sweet time.
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.
>Honestly, not a fan of these userland utilities/systems that just throw everything into the kitchen sink.
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.
How would that even work separately from wayland compositor?
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.
> 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.
Hmmm. Seems like writing this on Mastodon is practically a sign from the heavens that they will do exactly that.
Hopefully for the sake of maintainer sanity, and assuming this really is a resource nightmare, the users in question will at least get to see a formal message somewhere, as in the classic two levels of "are you sure" dialogs, or maybe something novel like an unkillable scorpion guy appearing in their htop interface, etc.
I'll switch to Wayland once I can build custom crt modelines and blanking intervals (https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/blob/... only supports setting dimensions and not blanking intervals, and someone I've talked to reports being altogether unable to set non-EDID resolutions on Sway and wlr-randr), and once I get fractional virtual-pixel window sizes (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m... is filled with unconvincing arguments as to why it can't or shouldn't be done), and can setup Qt apps with font DPI scaling (rather than forcing them to deal with non-integer physical pixels per virtual pixel).
I don't think crt modelines/blanking are relevant at all for Asahi. In general, sure, it may be something interesting for you, but in the context of the original post... not really.
I'm fine with open source developers not working on these things.
I continue to use X simply because the distro I use pushes it. Most of the issues mentioned wouldn't bother me. And if things get to broken I guess I will move at some point.
Nobody says you can't use X, you can, just temper your expectation on bugs being fixed and so on.
> We aren't going to stop you from running ... no sound server
> your speakers sound terrible and tinny or don't even work at all by default (once we ship that)
So this sounds completely unrelated to Xorg vs Wayland. Can someone care to explain?
I do prefer Xorg currently but I can think I can live with Wayland (I tried a bunch of times before, some things I found better than Xorg, but others were blockers, although they ought to be resolved someday I guess). Both live in userland though.
Comparatively, this sounds quite surprising. Is the use of a sound server like pulseaudio or pipewire basically mandated to safely handle the audio hardware? Why should I need those?
I'm aware of the design of these Macs audio that can physically destroy speakers if not driven correctly, and I know it's being worked on, but it seems to imply the safety features are handled at the userland (pipewire I guess?) level instead of the kernel/ALSA level (which IMHO is what should be done for something that can irremediably destroy hardware).
Thus, while I can understand that it wound be quicker to develop and validate such protections in userland, but ultimately I believe the end goal would be to have safe audio hardware support right in the mainline kernel, or at the very least as an ALSA plugin (which would be equivalent to mesa for graphics support)
I believe it is essentially to replicate macOS behaviour. Part of the reason MacBooks have great audio is because instead of setting a hard volume limit they model the coil temperatures and modify limits on the fly. That’s something which is too complex to do in kernel.
> ASoC exposes the speaker array as six independent drivers - two woofers and a tweeter each for Left and Right. We want userspace to see this as a standard stereo speaker pair. The configuration fragment shipped in this package sets up a virtual sink that takes a stereo input and routes it appropriately to each driver.
> We then run into another issue - the speakers sound awful. Turns out Macs aren't magic, they sound good because Apple invest a lot of engineering effort into DSP. Apple actually handle this with odd bespoke Core Audio plugins. We use PipeWire's convolver plugin to apply impulse responses to each driver, which effectively EQs the output signals.
> The kernel driver currently makes no effort to diminish your ability to destroy your machine through misconfigured settings in userspace
This is what I find quite unacceptable from a design PoV, this kind of safety should be as close to the kernel as possible.
It can't be though. The kernel itself can't include anything requiring floating point maths, so it needs to be able to permit userspace to unlock any restrictions in order for those calculations to happen there. And Asahi is intentionally being designed for the modern systemd/wayland/pipewire stack so they're not going to work on ALSA plugins since pipewire replaces that part of the stack.
The Asahi team do say there will be a basic level of safety implemented in the kernel like this:
> some kind of “safety watchdog interlock” with the kernel that only enables higher volume limits when the daemon is active and running
> The kernel itself can't include anything requiring floating point maths,
This sounds like a limitation derived from ancient architectures and platforms. What's the barrier to allowing FP in kernel modules for platforms that are guaranteed to have FP support? Is it too much work for the kernel to save and restore FP registers and modes?
This is wrong; using floating point (or rather, the vector register set like XMM) is used for example for cryptography. It does have extra cost though (as kernel doesn't normally save FPU/vector regs).
Wouldn't this be solved by just choosing a random linux distros out there and use the options that come preinstalled? Unless one proactively looks for features of the alternative there won't ever be the situation where one has to deal with these kinds of things.
Other than that I think having options / alternatives is a great thing. And if option a) intends to replace option b), then there will be compatibility issues in various degrees.
It's not that different than with other computer components, like CPU architecture (ARM vs x86/x64), GPU chips (Nvidia vs. AMD) and many more. Choosing the most popular option will usually result in the least amount of potential compatibility issues, but any of those options will work well in most situations.
Basically all wayland implementations went the way of a single server process, and since these processes are basically the compositors, a serious bug that would kill the process, would bring down the whole desktop with every app inside it, losing their state. Xorg has a separate window manager and compositor running, so a fault may end you with an environment of your windows without decorators and without the ability to move them, but you might restart the window manager to get back to where you were.
In practice it is very seldom a problem, and the more people use wayland the more stable it becomes. Also, there is nothing inherent in wayland’s design that would make this multi-process architecture impossible, it’s just not worth it.
With the lack of proper multitouch support, using X11 on a laptop feels so terrible. The gestures don't work, and if you make them work, they're delayed and off.
There's plenty wrong with the current Wayland system on many platforms (once again looking at you and your drivers, Nvidia) but if the hardware support is there, Wayland just is a lot nicer to use.
I bet once the major players switch to Wayland by default, this is just going to be one of those things people will fight over till the very end, like how some people still get enraged if someone doesn't write a SystemV init script for them and only packages a systemd service file.
X11 may work because it has become the de facto standard for open GUIs, but it's a weird, janky system being abused for things it wasn't designed to do in the first place. The missing support for some stuff is very annoying, but that will pass. The underlying API design just makes so much more sense than X11 ever did.
Been using Wayland since it had became default on Fedora. But some applications are still having issues when running with Wayland compositor under GNOME. Qt applications are the usual suspect, e.g. KeepassXC, OBS Studio and others.
But I wanna use xbindkeys and not have to have everything integrated in the compositor. What do I gain when desktop Linux is poorly sandboxed and thus the theoretical security benefits of Wayland are trivially circumvented anyways?
93 comments
[ 2.9 ms ] story [ 144 ms ] threadhttps://news.ycombinator.com/item?id=35928000
I can understand they want to test their GPU drivers only against the main Wayland compositors. Xorg is quite another beast to support. For all I know, it might come into the context when most bugs have been ironed out in the GPU drivers.
I do hope people do not take it as general advice. Not all desktop environments have a Wayland compositor, some are quite buggy and many apps don't work yet with Wayland. I am using Xfce and for the next year at least I will be on Xorg. I do hope Wayland gets better, but it has been an undertaking of many years already. The rest of the process won't be much faster I suspect.
If you want to go against the tide, you truly are on your own. You should expect less and less things to work over time as Xorg's code rots, X backends for GUI frameworks rot, and new hardware and drivers expose X bugs which won't be fixed.
If this doesn't scream "it's time to move away", I don't really know what does. Nobody can force anyone to move of course. But the writing truly is on the wall.
My desktop not working, or apps being blurred, or slower, or my mouse cursor stuttering, or screen sharing not working, or Java apps not getting the hidpi settings. That’s what drives me away from Wayland, and all of those happened to me.
I don’t think anybody is against Wayland “just because”. When it matures and app support is better, we’ll switch.
14 years later there's still no rational reason to run Wayland, and I doubt there ever will be.
I'm a simple user with simple needs, though apparently that's already pushing the limits of what Xorg can deliver: I have a high-DPI laptop scaled 140%, and a secondary high-res/average-DPI display at 100%. Mixing scaling factors has never worked well under Xorg (rendering glitches with ghost lines, applications like drop down terminals not knowing the dimensions of their viewport when opened on one screen and then or the other). And I'm not even getting into the better handling of discrete GPUs or the much smoother scrolling/animations that give it a better polish.
Xorg totally made sense in the context in which it was invented (in the long forgotten era of server-side rendering), but with applications rendering their own widgets and passing pixmaps to the compositor, Wayland is mostly about cutting the middleman and breaking-off with the obsolete/unmaintained/insecure bits. If you grab a distro with the latest gnome/kde, you should be at a point where Wayland really is only upsides.
I’m periodically re-evaluating Wayland for my own needs, and so far I chose Xorg every time. I need to do work on my ws, so I need to prioritize stableness to features. I don’t care about fancy features and I’d be ok with KDE 3.5.
Ironically, what should work way better on wayland rather than xorg (hidpi, especially with fractional settings) still works better on xorg for me.
This statement continues to sound like its trying to become self-fulfilling.
Xorg releases still happen (I'm not going to get into a debate about what is "well" maintained)
As many people move to Wayland those interested in X long-term should be given the space to do so, and statements like this set out to prevent it.
It's even a case of "protest too much" -- saying it over and over means that probably it isn't true.
The statement "Xorg isn't well-maintained anymore" isn't an attempt at a self-fulfilling prophecy. It's a statement of fact. The people and companies and organizations who used to do the work on X11 are now working on Wayland. The same people and groups are doing the same kind of work, just on a different protocol.
What is the “typical” linux desktop workflow, btw? It’s probably an OS used by a bunch of geeks, everybody’s got his own quirks.
He also said[1]:
> We don't have the time
And then he said[2]:
> If you want to change that, better volunteer yourself :)
Rather, I think he's saying the loud part out loud. OSS can have an opinion, and you're free to modify it to suit your own opinion.
[1] https://social.treehouse.systems/@marcan/110354541574112092 [2] https://social.treehouse.systems/@marcan/110354734990416348
Even fully baked patches will turn out to require "incompatible architectural changes".
Eric S. Raymond likes to contribute to open source projects in the form of fully realized, thoroughly architected megapatches that totally upend all the assumptions about how a system/subsystem works and behaves, along with a long lecture about why his patch should be accepted which boils down to "I'm ESR, I know how this bit should be designed much better than you, so there". That is the exact opposite of doing the work. Doing the work involves empathy and respect for the needs and experiences of others.
If you want Asahi Linux to support Xorg, you have three choices:
* Accept things as is.
* Fork the project.
* "Do the work". Convince the Asahi maintainers, in terms they are likely to appreciate, why Xorg inclusion is a good idea and who will be assuming the maintenance burden with little to no effort on their part. Then try to merge your patches.
your desktop tears
screen capture is dog slow
your media keys stop working one day
your speakers sound terrible and tinny or don't even work at all by default (once we ship that)
VSync is broken
your display looks duller and the colors muted
It’s kind of funny though how apparently Wayland is another hydra that tries to get involved with sound and other things it doesn’t really have business with.
> your desktop tears
Maybe but I don't care, I care about a desktop that works. I went back to X on my laptop after testing Wayland because something important didn't work but I can't remember what.
> screen capture is dog slow
I never realized it.
> your media keys stop working one day
Brightness controls work with some NVIDIA drivers and don't with others but there are workarounds: hotkeys bound to brightness control scripts.
I think that the next three points are specific to the work they are doing on Macs so they don't apply to my experience.
> your speakers sound terrible and tinny or don't even work at all by default (once we ship that)
> VSync is broken
> your display looks duller and the colors muted
I like the honesty of this take. I think if we’re honest with ourselves as self funded opensource developers, our projects really have a target market of 1. And you’re right - it’s not you. If the entire target market (the asahi Linux dev team) want to use wayland, that is absolutely their prerogative. You and I aren’t customers of theirs. Our needs don’t pay their bills.
So... that's basically an idea you made up, yet you claim the blog is misinformed about the target market?
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.
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.
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.
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?
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.
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.
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.
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.
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.
Hmmm. Seems like writing this on Mastodon is practically a sign from the heavens that they will do exactly that.
Hopefully for the sake of maintainer sanity, and assuming this really is a resource nightmare, the users in question will at least get to see a formal message somewhere, as in the classic two levels of "are you sure" dialogs, or maybe something novel like an unkillable scorpion guy appearing in their htop interface, etc.
I continue to use X simply because the distro I use pushes it. Most of the issues mentioned wouldn't bother me. And if things get to broken I guess I will move at some point.
Nobody says you can't use X, you can, just temper your expectation on bugs being fixed and so on.
> your speakers sound terrible and tinny or don't even work at all by default (once we ship that)
So this sounds completely unrelated to Xorg vs Wayland. Can someone care to explain?
I do prefer Xorg currently but I can think I can live with Wayland (I tried a bunch of times before, some things I found better than Xorg, but others were blockers, although they ought to be resolved someday I guess). Both live in userland though.
Comparatively, this sounds quite surprising. Is the use of a sound server like pulseaudio or pipewire basically mandated to safely handle the audio hardware? Why should I need those?
I'm aware of the design of these Macs audio that can physically destroy speakers if not driven correctly, and I know it's being worked on, but it seems to imply the safety features are handled at the userland (pipewire I guess?) level instead of the kernel/ALSA level (which IMHO is what should be done for something that can irremediably destroy hardware).
Thus, while I can understand that it wound be quicker to develop and validate such protections in userland, but ultimately I believe the end goal would be to have safe audio hardware support right in the mainline kernel, or at the very least as an ALSA plugin (which would be equivalent to mesa for graphics support)
EDIT: seems like it's pipewire: https://github.com/chadmed/asahi-audio
https://asahilinux.org/2022/11/november-2022-report/
From https://github.com/chadmed/asahi-audio
> ASoC exposes the speaker array as six independent drivers - two woofers and a tweeter each for Left and Right. We want userspace to see this as a standard stereo speaker pair. The configuration fragment shipped in this package sets up a virtual sink that takes a stereo input and routes it appropriately to each driver.
> We then run into another issue - the speakers sound awful. Turns out Macs aren't magic, they sound good because Apple invest a lot of engineering effort into DSP. Apple actually handle this with odd bespoke Core Audio plugins. We use PipeWire's convolver plugin to apply impulse responses to each driver, which effectively EQs the output signals.
> The kernel driver currently makes no effort to diminish your ability to destroy your machine through misconfigured settings in userspace
This is what I find quite unacceptable from a design PoV, this kind of safety should be as close to the kernel as possible.
The Asahi team do say there will be a basic level of safety implemented in the kernel like this:
> some kind of “safety watchdog interlock” with the kernel that only enables higher volume limits when the daemon is active and running
https://asahilinux.org/2022/11/november-2022-report/
This sounds like a limitation derived from ancient architectures and platforms. What's the barrier to allowing FP in kernel modules for platforms that are guaranteed to have FP support? Is it too much work for the kernel to save and restore FP registers and modes?
This attitude right here is why I don't use desktop Linux anymore. I'm tired of caring about my system components, instead of just using them.
Other than that I think having options / alternatives is a great thing. And if option a) intends to replace option b), then there will be compatibility issues in various degrees.
It's not that different than with other computer components, like CPU architecture (ARM vs x86/x64), GPU chips (Nvidia vs. AMD) and many more. Choosing the most popular option will usually result in the least amount of potential compatibility issues, but any of those options will work well in most situations.
Then I will consider using it.
In practice it is very seldom a problem, and the more people use wayland the more stable it becomes. Also, there is nothing inherent in wayland’s design that would make this multi-process architecture impossible, it’s just not worth it.
There's plenty wrong with the current Wayland system on many platforms (once again looking at you and your drivers, Nvidia) but if the hardware support is there, Wayland just is a lot nicer to use.
I bet once the major players switch to Wayland by default, this is just going to be one of those things people will fight over till the very end, like how some people still get enraged if someone doesn't write a SystemV init script for them and only packages a systemd service file.
X11 may work because it has become the de facto standard for open GUIs, but it's a weird, janky system being abused for things it wasn't designed to do in the first place. The missing support for some stuff is very annoying, but that will pass. The underlying API design just makes so much more sense than X11 ever did.
This is straight from the Cascade of Attention-Deficit Teenagers model: https://www.jwz.org/doc/cadt.html.