Open Source Software Community - it's about ethics in Code of Conducts

[jeff7989]

with low latency

Haha, good one, maybe on simple setups.

 

[Curious George Jetson]

KDE dropping X is just the latest in a long line of changes made to kill UNIX.
It wasn't talked about enough when systemd became a thing, that what they were actually doing was removing the UNIX from Linux. In the process of removing the UNIX from Linux, major desktop environments deprecated support for other init systems, removing support for other UNIX systems.
You used to be able to relatively easily get all of these desktop environments running on the rest of the UNIX world because Linux was for the most part UNIX compatible. They used to be mature, portable systems, and they decided to stop doing that.

I don't think it was the right way to go.

 

[Kola]

"I don't care how well your "AI" works"

https://fokus.cool/2025/11/25/i-dont-care-how-well-your-ai-works.html

An anti-AI seething diatribe by a transvestite who wants to be called "Fiona Fokus". Anyone know his real name?

 

[Creative Username]

KDE dropping X is just the latest in a long line of changes made to kill UNIX.
It wasn't talked about enough when systemd became a thing, that what they were actually doing was removing the UNIX from Linux. In the process of removing the UNIX from Linux, major desktop environments deprecated support for other init systems, removing support for other UNIX systems.
You used to be able to relatively easily get all of these desktop environments running on the rest of the UNIX world because Linux was for the most part UNIX compatible. They used to be mature, portable systems, and they decided to stop doing that.

I don't think it was the right way to go.

on the other hand sometimes you need to break compatibility with something that hasn't changed since the 80s to make some of the jank go away
wayland might not be the best way to do it (always take more hints from plan 9 if possible) but it has the most general support so every sensible person who wants a new graphics protocol is going to support wayland and not some shit they just cooked up to increase the fragmentation

in general i do think wayland is a bit more in line with the unix philosophy than x11 and i hope it matures nicely

 

[Mikoyan]

in general i do think wayland is a bit more in line with the unix philosophy than x11

What is your reasoning on this? I don't intuitively get it. I mean X11 isn't the most Unixy thing in the world, but neither is Wayland to my thinking.

 

[Creative Username]

What is your reasoning on this? I don't intuitively get it. I mean X11 isn't the most Unixy thing in the world, but neither is Wayland to my thinking.

a more simple implementation (a very important quality of unix software) and the general "do one thing, do it well" thing

they've just sort of simplified a lot of things, and the protocol provides mostly the things that applications actually do instead of a bunch of weird shit
one of the core ideas of x11 is providing a bunch of low-level primitives and not really enforcing tons of shit on applications
the older x11 toolkits liked using x11's drawing primitives a lot, but in modern times they really just use x11 to request a framebuffer and push frames, because x11's drawing commands actually still do impose a little bit of shit on you
enter wayland, which is basically just a way to obtain the kind of shared memory buffer setup that 99% of x11 programs use these days without anybody needing to care about drawing lines (most people use a library for that nowadays)
there are also some other cleanups like not having magical xauth bullshit

the increased simplicity is why several different compositors exist for wayland while x has 1 server with 1 fork. people shit on systemd for being a huge 1-implementation lump that everything everywhere depends on but xorg is apparently completely ok because it was forced on everybody back before the 90s or so
apart from a bunch of gay libraries depending on dri and epoll, i don't think there's really too much preventing wayland compositors from being created or ported to other unix-like kernels and userspaces such as openbsd or (inshallah) the hurd

 

[Dante Alighieri]

And I just switched back to X11 KDE (Wayland would just black screen and not output a signal, no idea)

 

[prollyanotherlurker]

on the other hand sometimes you need to break compatibility with something that hasn't changed since the 80s to make some of the jank go away
wayland might not be the best way to do it (always take more hints from plan 9 if possible) but it has the most general support so every sensible person who wants a new graphics protocol is going to support wayland and not some shit they just cooked up to increase the fragmentation

in general i do think wayland is a bit more in line with the unix philosophy than x11 and i hope it matures nicely

I feel like a lot of people don't fully get what wayland is, or at least they don't really think about it much. I think people are used to the x11 way. So when they just generically say wayland is this or that, it doesn't really apply in the same way it does with x11. Like you implied it's a simple set of protocols to set up a display server with a compositor/window manager. It's not a single huge display server, that then has to communicate back and forth with a compositor, and a window manager. Which does have benefits. When it's a graphical program, where you can feel latency, not having to communicate back and forth through different separate programs, does actually allow it to be more efficient. And Wayland itself because it is so simple, does allow a wide range of use cases, for people that want to design something around it. Like designing a phone UI, or doing some kind of embedded work on the console in a car. But my point is, when people talk about "wayland" its not really the same as talking about xorg. because what wayland is depends on the compositor, and what is implemented by it. The experience someone has running gnome wayland isn't really reflected much in what I see running hyprland, or someone that's running cinammon or xfce's experimental wayland session.

There are of course some negatives that come with that also. Although there are also solutions for that, like if you want to build your own wayland compositor. Wlroots, or smithay are there to cut out duplication of work. I think also in the next few years, as the number of users of wayland based de's and compositors continues to increase, we will see a lot of libraries like those pop up to make things simpler. And we will just naturally see more standarization across different compositors. And also people implementing protocols themselves for things that have been bikeshedded by the actual wayland devs. Then those becoming standardized by their adoption among the linux ecosystem. That kind of thing is just bound to happen naturally. It's how these things tend to go. I said a lot of this just now in the linux thread, but the same topic is being talked about in both.

 

[Creative Username]

There are of course some negatives that come with that also.

the main ones are just the general breakage from uprooting something so deeply entrenched as x11 and all the work required to port some fairly advanced uses of x11 by graphical programs that might need to involve some keylogger-type shit
otherwise wayland is quite possibly one of the most aryan ways to open up a window and then draw shit to it (and when the compositor isn't shitting itself due to miscellaneous graphics stack spaghetti, it will always render perfectly clean frames with no screen tearing)

I think also in the next few years, as the number of users of wayland based de's and compositors continues to increase, we will see a lot of libraries like those pop up to make things simpler.

we have already seen a few such libraries, such as libinput, that are widely used by wayland compositors to implement input handling shit. they are not necessary, however; a wayland compositor can be anything that can speak the protocol. in fact libinput has been backported into x11 which can actually be viewed as a kind of graphical compositor that tends to offload the actual compositing to some other process whenever alpha transparency or not causing horrible screen tearing are needed

And we will just naturally see more standarization across different compositors. And also people implementing protocols themselves for things that have been bikeshedded by the actual wayland devs. Then those becoming standardized by their adoption among the linux ecosystem. That kind of thing is just bound to happen naturally. It's how these things tend to go. I said a lot of this just now in the linux thread, but the same topic is being talked about in both.

this is probably how it will end up going. it might end very well, it might end not so well, but at least if you want to write a wayland compositor you will not be completely forced to write all 3000 features, including a stack of complex font selection logic that nobody really uses anymore because fontconfig is the expected option these days

 

[reactionary]

I just want to be able to use my computer, why does everything have to be so retarded?

 

[Creative Username]

I just want to be able to use my computer, why does everything have to be so retarded?

it would have been nice if somebody thought of wayland before 2000 or stole whatever bullshit from plan 9 or something, but we waited until now to deal with the crusty bullshit from the 80s so now the predictable result is happening
worse option: just leave the old shit in unchanged forever (what are we, fucking windows?)

if you just want to use a computer, install mint. i think they have things generally figured out. whatever it installs on your computer will probably work reasonably well and you don't have to worry about it because all the package maintainers are busy doing that for you
also on wayland it is very easy to run x11 apps because most compositors start a tard-wrangled version of the x server called xwayland. guess what it does (if you guessed "implement an x server that seamlessly turns all x11 windows into wayland windows so well that it can be actually hard to tell which is which in many circumstances" you are right)

the actual chaos seems to be dying down somewhat because e.g. it is now possible to use wayland on nvidia without burning your house down. i feel like the end is starting to barely come in on the horizon for the graphics protocol wars

 

[dec05eba]

a more simple implementation (a very important quality of unix software) and the general "do one thing, do it well" thing

they've just sort of simplified a lot of things, and the protocol provides mostly the things that applications actually do instead of a bunch of weird shit
one of the core ideas of x11 is providing a bunch of low-level primitives and not really enforcing tons of shit on applications
the older x11 toolkits liked using x11's drawing primitives a lot, but in modern times they really just use x11 to request a framebuffer and push frames, because x11's drawing commands actually still do impose a little bit of shit on you
enter wayland, which is basically just a way to obtain the kind of shared memory buffer setup that 99% of x11 programs use these days without anybody needing to care about drawing lines (most people use a library for that nowadays)
there are also some other cleanups like not having magical xauth bullshit

the increased simplicity is why several different compositors exist for wayland while x has 1 server with 1 fork. people shit on systemd for being a huge 1-implementation lump that everything everywhere depends on but xorg is apparently completely ok because it was forced on everybody back before the 90s or so
apart from a bunch of gay libraries depending on dri and epoll, i don't think there's really too much preventing wayland compositors from being created or ported to other unix-like kernels and userspaces such as openbsd or (inshallah) the hurd

I would say thats true for the old drawing primitives in x11, but if you ignore that (since nobody really uses that anymore) then x11 is much simpler than wayland and composable. Just compare the way you capture a window on x11 vs wayland. On x11 you get a graphics reference to a window by the window id with a single x11 call. There is no complexity hidden in an api to make that work. On wayland, you cant even do that to begin with. But for desktop use you need that, so the wayland solution is to introduce desktop portal. In practice a wayland system has a dependency on desktop portal.

Desktop portal is implemented with dbus and the screencast (screen capture) api also has a mandatory dependency on pipewire directly in the protocol, which means each desktop portal for every wayland compositor needs to support dbus + pipewire and so does every client. This is because desktop portal is made by flatpak people who are redhat devs and pipewire is also a redhat project. So to capture the screen you need to use wayland, do multiple dbus requests back and forth, get a pipewire node and then communicate with pipewire which requires manual setup of the protocol with bytecodes, etc. The pipewire client library uses gnu c extensions with macros for this, lmao. You end up writing 2000 lines of client code and the wayland desktop portal has extra complexity to deal with behind the scenes and so does the wayland compositor (as the desktop portal communicates with both the wayland compositor and pipewire), to do what took 1 line of code in x11. The x11 code is also usable for more things (compositing). None of this has anything to do with wayland "security" btw.

Even with simpler things its more complicated. On x11 you can just move a window on the screen. On wayland you need a whole new wayland protocol, which has taken many years and its still not finished. On x11 you can set window properties, on wayland you need a new protocol everytime you want to add more information. Which is why even gamescope wayland compositor uses x11 to do this, since it's much easier: https://github.com/ValveSoftware/gamescope/blob/master/src/steamcompmgr.cpp#L7458.
X11 got support for VR in 2 months (both the specification and xorg server implementation) while in wayland it took them 2 years just to discuss it (because of wayland philosophy) and another 2 years to implement it. This has to do with x11 mechanism over policy rather than wayland policy over mechanism. Mechanism over policy fits much better with the unix way of doing things.

One thing that all other display servers (and the graphics system on other OS) is parent/child windowing (embedding), which is done without any extra complexity. This is actually a part of standard DAW (Digital Audio Workstation) plugin interface, and it required to make things work properly. Wayland doesn't support this and they instead tell you to implement a whole compositor in your application (several thousands of lines of code instead of 1 line). This unironically is a security feature that wayland is missing (it would allow putting certain parts of a program into another process and use OS level restrictions on what the process can do. All browsers do things like this).

These things are also the reason why there aren't simple fully functional wayland "window mananagers" (or call them compositors if you would like). You cant compose applications on wayland (unlike unix philosophy). The compositor and window manager has to be in a single application, unless you design your own protocol for that. Wlroots helps with it a bit, but even that isn't enough and its still a million times more complex than x11 and applications end up being wlroots specific, not wayland. A lot of "wayland" applications are wlroots applications, not wayland applications (despite them advertising as being wayland applications).

Lastly I've been working on my own x11 server and I can say that as long as you dont deal with old drawing primitives (which 99% of users dont use) then an x11 server from scratch isn't really harder to make than a wayland compositor. I would argue that it's easier. The most complex part isn't even graphics, but input (xkb). xkbcommon library handles a lot of that if needed, which is what's used for wayland as well.

 

[The Taxman]

I haven’t seen this being posted yet, but this absolute retard behind this pure slop PR is hilariously deranged:

https://github.com/ocaml/ocaml/pull/14369

 

[Creative Username]

In practice a wayland system has a dependency on desktop portal.

Desktop portal is implemented with dbus and the screencast (screen capture) api also has a mandatory dependency on pipewire directly in the protocol, which means each desktop portal for every wayland compositor needs to support dbus + pipewire and so does every client. This is because desktop portal is made by flatpak people who are redhat devs and pipewire is also a redhat project.

and is this a horrible thing? most desktop applications, x11 or wayland, already depend on dbus somehow anyway. idk how niggerlicious pipewire is but i assume it's not any worse than pulseaudio was (which pipewire apparently killed now, nice?)

The pipewire client library uses gnu c extensions with macros for this, lmao.

based, the only real c library is glibc and gnu c is the true c (but c99 conformance is cool if you can do it)

 

[dec05eba]

and is this a horrible thing? most desktop applications, x11 or wayland, already depend on dbus somehow anyway. idk how niggerlicious pipewire is but i assume it's not any worse than pulseaudio was (which pipewire apparently killed now, nice?)

It's a discussion about complexity and unix philosophy. Requiring dbus + pipewire in the display server is retarded. That's 3 different protocols just to do a single thing (wayland + dbus + pipewire). All in all combined, it's probably near 5000 lines of code to do what is a few lines of code in X11 (without the complexity being hidden behind anything). Pipewire is far worse than pulseaudio when it comes to api and protocol design. They now actually recognize that its retarded and are making a wayland protocol to not require pipewire nor dbus. But of course, this wont be implemented by gnome so you will have to use the desktop portal anyways and wayland compositors will still need to implement the desktop portal since most applications will use that so what ends up happening is duplicate work.

based, the only real c library is glibc and gnu c is the true c (but c99 conformance is cool if you can do it)

it's macros that uses gnu c extension, which means you cant use it from other languages (including zig, etc). IIRC you cant even use it from c++. You have to construct the binary protocol messages manually, byte for byte.

 

[Creative Username]

They now actually recognize that its retarded and are making a wayland protocol to not require pipewire nor dbus.

interesting, hopefully it's properly sandboxable and it wins out in the end

But of course, this wont be implemented by gnome so you will have to use the desktop portal anyways and wayland compositors will still need to implement the desktop portal since most applications will use that so what ends up happening is duplicate work.

that gnome tactic is actually best defeated by using the same tactic against them. make your application say "this application cannot run since the wayland compositor, mutter, does not implement the proper extensions. this is a problem with mutter, not our software" and then wait for the inevitable
let's see what gnome niggers think after 5 million issue reports on their tracker from confused users

also are you just assuming this or did gnome developers literally say they won't be implementing it? maybe they don't have a huge stick up their ass today

 

[dec05eba]

also are you just assuming this or did gnome developers literally say they won't be implementing it? maybe they don't have a huge stick up their ass today

Our favorite ebussy said so (they have also stated that in the freedesktop wayland issues repo)

 

[prollyanotherlurker]

This was an interesting watch. Also it brings up a part of windows decision back in the day to basically make sure things that were made on their platform weren't portible (from what I understand that also went into how they designed their syntax for their filesystem with \ instead of / like literally everything else, just to make things less portable). Then other operating systems get criticized becausr X program can't run on it, when its not really the fault of the OS, but the company making it, and microsoft. I would be shocked if there wasn't some form of collusion there.


Anyway it goes into more than that. That was just one thing that gets mentioned.

I just happened to come across this so I figured I would toss it in.

 

[Mikoyan]

from what I understand that also went into how they designed their syntax for their filesystem with \ instead of / like literally everything else, just to make things less portable)

That's a DOS holdover and to call anything about MS-DOS a well-thought-out plan is pretty funny.

Now holding onto it like they did, maybe.

 

[pellegrino31415]

This was an interesting watch. Also it brings up a part of windows decision back in the day to basically make sure things that were made on their platform weren't portible (from what I understand that also went into how they designed their syntax for their filesystem with \ instead of / like literally everything else, just to make things less portable). Then other operating systems get criticized becausr X program can't run on it, when its not really the fault of the OS, but the company making it, and microsoft. I would be shocked if there wasn't some form of collusion there.


Anyway it goes into more than that. That was just one thing that gets mentioned.

I just happened to come across this so I figured I would toss it in.

View attachment 8224441

I know this is a meme. But this is the reason. A non technical lead is going to look at this and say that you don't have a plan, and everything is risky, so lets go with what "works".