The usual way to fix other concerns like that has been to add more WM atoms or add more X extensions, which is a similarly uphill battle requiring buy-in and standardization, and typically old X clients just won't be updated to support those new things. The way to get the most value out of such things would be to add support to the major toolkits, but those have already been ported to Wayland for some years now.
The backwards compatibility is done through XWayland which functions similarly to XQuartz, in that it is just the Xorg server running using Wayland as a backend driver.
In practice, placing everything in one process seems to reduce the total attack surface. There is quite a lot of code required to synchronize state between the X server, window manager and compositor. When you combine them, you can throw out most of those bits that are largely serialization/deserialization.
Maybe that's true if that's your only concern, but there are other reasons to replace X11 than just this.
Also, X11 is arguably not the whole graphics stack, at this point the DRM/Mesa piece is much larger and more significant, and Wayland doesn't replace it outright anyway -- it makes it optional if needed for backwards compatibility, in the same way that macOS has XQuartz.
In theory there could be a Wayland implementation that loads Xfree86 drivers, but why? Going forward, the implementations that want high performance and low latency (i.e. VR/XR interfaces) are likely going to target Vulkan, and you will likely never want to disable vsync there.
The demand there would be with products like Qubes and Subgraph, which are currently using Xephyr and Xpra. Eventually Wayland should be able to improve performance there, and bring some of the security benefits of those setups to other distributions.
To borrow some language from the piece, how much would you appreciate it if someone put a paragraph in the documentation saying "CaptArmchair is a poor soul filled with tremendous existential angst, who needs to be prevented from thinking so the tremendous agony of realizing CaptArmchair's own irrelevance does not again take over CaptArmchair's life" ? Even if it was a joke, would you really want that in there? (For disclosure, if it was me, I personally would probably not want any hostile things about me written across random open source documentation, so hopefully I am not cursing myself to that by writing this post)
What you're saying is entirely backwards though, from a pure maintenance perspective, the purpose of documentation is actually to reduce the amount of time you need to spend on answering questions and responding to debates. If you receive a lot of questions about what it's supposed to mean, the documentation is not doing its job and needs to be clarified.
Possibly I should have said "it stops being only that," that might have been more clear. The problem with making that 0.1% into something else is that people still get annoyed and distracted by it because it's not what they expected, and they complain, which is exactly what happened here.
I don't know you mean by lose, the original Guru Meditation is already long gone. If you have your own thing and you want to keep the joke alive by spending your time fielding a bunch of support requests from confused users asking what "Guru Meditation" means then be my guest, I can't take that away from you.
My feeling is just that if you change that message from "Guru Meditation" to "you are an ass hat" or something rude like that, you will probably get many more complaints.
>Can you be sure this is targeted at mobile game players? Have you read the tutorial page and are you perceiving things at face value? Have you considered that satire can deliver a valid criticism via irony, pastiche, wit,...? Could this also be a warning or a put down directed at mobile game companies who tend to consider gamers as consumers through their business models?
I can't answer those because as far as I can tell, none of that context was really mentioned in the piece. If the bar for understanding the documentation is "you have to go on twitter and ask the author a bunch of critical questions to explain the joke" then consider the group of people who you are limiting that documentation to.
I am not sure what you mean by some people are trying to turn something into a categorical imperative, I didn't see any statements to either of those ends. I see some people who have apparently suffered, making a specific request to another group of people to help reduce their suffering.
The constant stream of little quips and inside jokes that endear you and I to things also can be off-putting and drive outsiders away. I am sorry but I've spent my years explaining so many strange things that nobody understands like "Guru Meditation," and it's not really funny any more when you have to keep explaining the joke. And those are just the little innocent gags, it's much much worse when the joke is disparaging someone.
It also doesn't seem like this was written by some random open source contributor, it seems it was done by the maintainers, who are being paid to work on it by their patrons. They absolutely do have to answer to those patrons. While people seem to like to assign all blame for things on twitter commentators for whatever reason, it's likely the actions they took are the result of feedback from the patrons.
I'm not sure what you mean, the entire point of technical documentation is that it explains a technical subject, that is the definition of the phrase. You could add other things but then it stops being just that.
As far as I can tell people are being forced to read it if they want to learn that particular API. It wasn't some third party blog or tutorial. (Please correct me if I am wrong about this)
Sometimes I do enjoy that too, but I can also see how other people don't enjoy that type of humor and wouldn't want to be subjected to being mocked. You can't force people to think a joke is funny especially if you're intentionally doing it outside one of those designated stages, often the context is the entire reason the joke is funny. It's one thing if you're picking between 100 math books on the same subject, and you pick one of them that contains the humor that you like, but that's different from when you're shipping the official documentation which is supposed to be the one source of truth for the project. Users can't just pick a different book there if they find your jokes off-putting.
That isn't really a valid option though, if this kind of thing is in the official documentation, and you have to read it in order to use that particular feature. It would be there every time you have to refer back to the documentation or refer someone else to it.
Yes, many times, but I don't see how that is relevant. Technical documentation is not a comedy performance, you read it to learn how to use the product, not to develop your sense of humor. Why would there be jokes in there made at the expense of any group? Within the documentation, it makes perfect sense for these projects to ban any of these kind of jokes that could anger people, if what you really want is cynical hot takes and snarky jokes, there seems to be no shortage of that on HN and Twitter and other places that aren't technical documentation.
There's a lot to unpack here and I'm feeling very confused as to what you're talking about. Godot is not a major corporation, and you seem to be dismissing someone's complaint as "fake-wokism" and "professionally oppressed" when the joke in question is very clearly made at the expense of a certain group of people (mobile game players). What is fake or contrived about this if you're in that group and don't like being the butt of these jokes as is happening here? I personally can see why someone would be offended by such cynical and condescending statements, even though I am not in that group.
Also you're saying their opinions have "teeth" as if making a complaint is some kind of attack on something because it could potentially cause a change to happen, but if you take that view then what is the point of giving feedback if you know it won't be acted on? If you find yourself overreacting to someone else expressing their opinion, perhaps that is another opportunity to expand your viewpoint, instead of overreacting?
I mean Linux, it does the same but reversed: the kernel implements the ALSA API, and libaoss is provided for backwards compatibility in userspace with OSS. What else should they have done? The ALSA API is not the same as OSS and has a different set of features.
I didn't mention those because in theory a lot of that could be done by the library, or done by the daemon before passing off the fd for a peer-to-peer connection. (If a connection dies, the library would transparently handle that by sending a request back to the daemon for another connection, etc) But of course another thing that having a message bus allows you to do is reduce the amount of fds that a client has to poll on to just one for the bus socket.
It's more than 20 years later and still I don't understand these complaints. ALSA was designed to have a broader API than OSS, and it has supported OSS emulation for quite some time. What else could have been done when OSS went non-free?
Among other things, pushing everything through the message bus allows for global message ordering, and security policies down to the individual message. Rewriting the internals would work in an embedded situation like that where every application is linking against the same version of libdbus, but that is not really the case on a desktop system, where there are multiple different D-Bus protocol implementations.
If applications have hard performance requirements, most D-Bus implementations do have support for sending peer-to-peer messages, but applications have to set up and manage the socket themselves.
That won't work here, the design of pipewire is to allow for things like a confirmation dialog appearing when an application tries to use the microphone or webcam, the application can then get temporary access to the device. That is a security policy that isn't really easy to do with filesystem device file permissions.
Would it? Linux does support realtime priority scheduling, JACK has worked this way for years. The thing is you need userspace realtime threads for because that is what the clients need to use, it's not enough to change just the mixing thread into a kernel thread.
D-Bus isn't suitable for realtime, to get that to work would require additional changes within the D-Bus daemon to add realtime scheduling, and even with all that, it would still introduce latency because it requires an extra context switch from client -> dbus-daemon -> pipewire. Maybe they could have re-used the D-Bus wire format? That's the only bit that might have been suitable.
Putting this into the kernel won't solve anything that isn't already solved with things like the Linux realtime patch. The way this works is that the applications themselves need to have a realtime thread to fill their buffer, and the audio daemon has to be able to schedule them at the right time, so it's not just the daemon that needs to have special treatment from the scheduler.
Also keep in mind that these audio daemons work as an IPC to route sound between applications and over the network, not just to audio hardware. Even if you put a new API in the kernel that did the graph processing and routing there, you would still likely need a daemon for all the other things.