Forgive me, I'm not an expert when it comes to windowing systems but wasn't Wayland started by basically all the then current head devs of xorg? Isn't that a tacit admission my the people that know best that the project they'd dedicated years if not decades of their lives to had reached a point where further development was untenable?
Beyond the above mentioned tacit admissions, didn't nearly every major active dev on the xorg team state explicitly via various emails, blog posts, and conference talks that they saw no reasonable way forward as a matter of tech when it came to the now 21 year old xorg source, now 34 year old XFree86 source, and 41+ year old protocol model that is X11?
All that said, I wish the best of luck to the X11Libre team on their endeavors.
There is no team, it's a one man show, and the split is caused by personality conflict between the author and the rest of the xorg team that doesn't feel that simply shuffling code around without putting actual hard work justifies frequent ABI breakage that leaves users with a broken graphics system. Read this for more info:
Yeah reading those links, this should have been a fork to begin with. Too many people rely on unstable XOrg. We're all used to the Linux model where HEAD is inherently unstable and breaks constantly (ask me how many times people broke the framebuffer driver in the last 5 years). But apparently XOrg does it differently.
> That fork was necessary since toxic elements within Xorg projects, moles from certian big corp are boycotting any substantial work on Xorg, in order to destroy the project, to elimitate competition of their own products. (classic "embrace, extend, extinguish" tactics)
> This is an independent project, not at all affiliated with BigTech or any of their subsidiaries or tax evasion tools, nor any political activists groups, state actors, etc. It's explicitly free of any "DEI" or similar discriminatory policies. Anybody who's treating others nicely is welcomed.
I don't understand why the link is to the commit list for a branch and not to the repo home page, unless OP was intentionally trying to have people avoid reading the README.
The README contains a minor political rant that primarily complains about corporate influence but also takes a shot at DEI. The CoC page was intentionally left up with just the content "404". Reading between the lines, it sounds like toxicity all around.
It's abandonware. None of the grown-ups in the Linux graphics space are interested in maintaining it beyond the minimum necessary. I suppose new features could be added to Xorg, but anyone who actually knows something about the graphics pipeline is 100% committed to Wayland, so it won't be done.
And Enrico's code was apparently so shitty and disruptive he's earned himself a ban from Freedesktop.org. Or is that because he associated himself with Lunduke?
That dude had a crazy amount of patches ready to go. I don't have the technical skills to judge if the patches are any good, but that's an impressive amount of work.
I'd be a little concerned that this is just one person doing the work, but we'll see if others join in.
From looking at his Xorg contributions on FDo, his technical work amounts to mostly code style changes and cosmetic-level refactors in an attempt to clean up the codebase. In the course of this, he's broken the master branch on multiple occasions and introduced a large amount of churn in the Xorg ecosystem, all while not fixing any bugs or improving anything user-facing. The reason why he started this fork seems to be that his changes pissed off everyone working on Xorg who could review his MRs, so they started piling up without getting reviewed.
> Changing calls pScreen->DestroyPixmap to dixDestroyPixmap doesn't meaningfully improve the code or make it easier to reason about. Moving byte-swapping of requests and events from one function to another doesn't make the code more robust. Cosmetic changes to the way length fields are written doesn't help with byte vs. word unit confusion, or keep you from writing the wrong amount of data. You're just moving the complexity from point A to point G, not reducing it.
> It is possible to reduce the complexity of the code, by delving deep into the interactions between DIX/MI/FB/DDX to flatten the code flow, making some deep structural changes. Or by using structured (de)marshalling through XCB. Doing this would be incredibly risky, but at least have a much higher payoff than just cosmetic shuffling because it is 'cleaner'.
> The immense value X11 has - that it always had and will have for decades to come - is its backwards compatibility, still being able to run 40-year old apps. You correctly called the codebase 'fragile' - you've been finding this out as your changes repeatedly break things. If you're breaking apps, then what exactly is the value in a codebase which is 'cleaner' to your subjective standard but doesn't actually work?
I hope so. I've tried to use wayland more than a decade ago, it was unable to replace xorg. Again last year, same story, and we get told that it's our fault because we need to adapt our workflows to wayland. I chose Linux because I get to choose how I work.
The MR that caused the drama that caused the fork to happen complained about this author doing tons of work to tons of legacy code with no direct user-facing benefit without testing his changes properly. From the sentiment of the discussion I gather this isn't the first time either.
I think trying to improve the quality of such old code bases is good and "don't touch it in case something breaks" has caused more problems than it solved, but in this case the lack of testing caused X to die when someone runs xrandr. Not exactly a vague use case. Large restructuring work and taking care of tech debt is good, but it should go along with diligent testing.
Until all the work is done, I don't think this will be a very stable alternative to X.org. I also don't think many people will follow this guy to the new project because the comments on the MR seems very "this guy versus everyone else".
Even if the fork stabilizes, that's just where the journey begins. The X.org system interacts with tons of other systems (the kernel and GPU drivers, among others), so that work need to be kept up with. At the same time, developing all of the new features the dev wants to add will be pretty useless unless applications start making use of them, and they're not going to if the project remains small.
If the anti-Wayland people unite behind this project and maintain their own X fork, there may be promise in this fork. But looking at the history, this is more likely to become another X12/Y11, or maybe a Mir if he can get a distro to back him.
Never coded, made a change or updated X11. It always just works. But reading this thread that spawned some of the feelings around the ‘fragile’ codebase sounds like it is really hard to work on
I hope this succeeds plus I hope they are open to allow patches from OpenBSD. IIRC, Xorg would not accept patches from them, them, thus we have xenodm.
Also I hope NetBSD, FreeBSD and DrogonFlyBSD jumps on, this way the BSDs do not have to jump through loops for Wayland and they are not being forced to follow Linux.
I read through some of the context and his commits and the guy seems like an absolute liability. I’m more careful making such changes on our internal greenfield prototype…
I've often wondered why there are so many people who want X to just die and will dismiss any criticism against Wayland. They sure do like shifting the blame elsewhere instead of acknowledging that some users do have issues running their applications.
Just yesterday I checked again if anything's changed, but nope. Jitsi Meet flickers, gr-fospher flickers and doesn't even render the plot, Emacs Application Framework doesn't work, etc. All these work perfectly fine with X.
Here is an excellent opportunity for those who believe in the continued development of X to pick up maintenance and push it forward. Time will tell at the end.
Can someone explain what's the big idea with that ? I keep seeing conspiracy theories about how Red Hat is sabotaging the Linux desktop on purpose, but I would quite honestly like to see an explanation as to *why* Red Hat would do that.
While I doubt Nvidia will back this fork over the real X.org, their open source drivers should be less problematic.
Unfortunately, whether or not you can use their open source drivers depends on what year you bought your GPU, and anything not labeled RTX or GTX-16* will never get a fully functional open source Nvidia driver.
Wayland is still pretty garbage. Hyprland is the most viable window manager replacement. The community is amazing too, way better than the Sway people. Lots of help from their forums and chatroom. Still, I had trouble with some basic stuff not working. So much tool replacement! So much work, for so little reward.
With i3/X11, I can run xrandr and see all my disconnected displays. As far as I can tell, there is absolutely no way to see disconnected display outputs in any wlroots or other Wayland composer. None. There's no standard way to do screenshots or video recording. It requires some custom portal for every single composer. I've never gotten Flameshot working in Sway or Hyprland and the suggested replacements are clobbered together garbage.
I do use network transparency (ssh -Y) quite often and it's not there in Wayland.
i3/X11 is just so much better and smother and I don't see the gain of Wayland. It's 100x more difficult to write programs that need to work in different composers. I hope this project succeeded and we really do see an X11R8 out of it.
I'm old enough to remember the switch from XFree86 -> xorg. I hope we see that again and we have real competition so the Wayland devs can finally get around to fixing their broken garbage of a display regression.
> I do use network transparency (ssh -Y) quite often and it's not there in Wayland.
There's waypipe (https://gitlab.freedesktop.org/mstoeckl/waypipe), which works well in my experience. Although I must say I don't use network transparency (be it X or Wayland) much these days.
Fantastic news. Glad that someone is continuing to support functioning graphics on Unix and Unix-like operational systems. Wayland is a joke toy with no future.
Why? Well, the existing protocol is 40+ years old, widely used and seriously battle hardened. The new one would be brand new and therefore infinitely better according to basic open source logic
> ZeroMQ has support for Unix Domain sockets even on Windows.
The support for Unix-domain sockets is there, in X and in the OS, regardless of whether you add ZeroMQ in the middle. Adding ZeroMQ wouldn't solve any problem in this regard.
Forgive me, I'm not an expert when it comes to windowing systems but wasn't Wayland started by basically all the then current head devs of xorg? Isn't that a tacit admission my the people that know best that the project they'd dedicated years if not decades of their lives to had reached a point where further development was untenable?
Beyond the above mentioned tacit admissions, didn't nearly every major active dev on the xorg team state explicitly via various emails, blog posts, and conference talks that they saw no reasonable way forward as a matter of tech when it came to the now 21 year old xorg source, now 34 year old XFree86 source, and 41+ year old protocol model that is X11?
All that said, I wish the best of luck to the X11Libre team on their endeavors.
There is no team, it's a one man show, and the split is caused by personality conflict between the author and the rest of the xorg team that doesn't feel that simply shuffling code around without putting actual hard work justifies frequent ABI breakage that leaves users with a broken graphics system. Read this for more info:
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1760#no...
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1797
I'll pass.
Yeah reading those links, this should have been a fork to begin with. Too many people rely on unstable XOrg. We're all used to the Linux model where HEAD is inherently unstable and breaks constantly (ask me how many times people broke the framebuffer driver in the last 5 years). But apparently XOrg does it differently.
If I was someone who wanted to contribute to Xorg and read those links, I don't think I'd want to contribute anymore.
Conversations happening like this inside of a company would warrant a HR investigation, regardless of who's right or wrong.
those are amazing, thank you
Well-known developer Enrico Weigelt just forked the X server from freedesktop.org after getting the boot [0].
[0] https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
[1] https://github.com/X11Libre/xserver/commits/xlibre/prepare/
“Getting the boot” is rather vague. Is there any more information anywhere, background, &c.?
My general impression (quite possibly incorrect) was that X.Org Server is largely treated as “done”, making only bugfixes and such these days.
From the readme:
> That fork was necessary since toxic elements within Xorg projects, moles from certian big corp are boycotting any substantial work on Xorg, in order to destroy the project, to elimitate competition of their own products. (classic "embrace, extend, extinguish" tactics)
> This is an independent project, not at all affiliated with BigTech or any of their subsidiaries or tax evasion tools, nor any political activists groups, state actors, etc. It's explicitly free of any "DEI" or similar discriminatory policies. Anybody who's treating others nicely is welcomed.
96 replies →
The project readme has some thoughts about why X.Org is treated as done and why the dev forked; I think I get why the OP didn’t link that instead.
https://github.com/X11Libre/xserver/tree/xlibre/master
I don't understand why the link is to the commit list for a branch and not to the repo home page, unless OP was intentionally trying to have people avoid reading the README.
The README contains a minor political rant that primarily complains about corporate influence but also takes a shot at DEI. The CoC page was intentionally left up with just the content "404". Reading between the lines, it sounds like toxicity all around.
It's abandonware. None of the grown-ups in the Linux graphics space are interested in maintaining it beyond the minimum necessary. I suppose new features could be added to Xorg, but anyone who actually knows something about the graphics pipeline is 100% committed to Wayland, so it won't be done.
And Enrico's code was apparently so shitty and disruptive he's earned himself a ban from Freedesktop.org. Or is that because he associated himself with Lunduke?
[flagged]
The more I read MR discussions regarding this the less I want to use the forked version. Not that anyone is going to ship it anyway.
That dude had a crazy amount of patches ready to go. I don't have the technical skills to judge if the patches are any good, but that's an impressive amount of work.
I'd be a little concerned that this is just one person doing the work, but we'll see if others join in.
From looking at his Xorg contributions on FDo, his technical work amounts to mostly code style changes and cosmetic-level refactors in an attempt to clean up the codebase. In the course of this, he's broken the master branch on multiple occasions and introduced a large amount of churn in the Xorg ecosystem, all while not fixing any bugs or improving anything user-facing. The reason why he started this fork seems to be that his changes pissed off everyone working on Xorg who could review his MRs, so they started piling up without getting reviewed.
I think this comment from an Xorg maintainer sums things up (from this issue: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1797 ):
> Changing calls pScreen->DestroyPixmap to dixDestroyPixmap doesn't meaningfully improve the code or make it easier to reason about. Moving byte-swapping of requests and events from one function to another doesn't make the code more robust. Cosmetic changes to the way length fields are written doesn't help with byte vs. word unit confusion, or keep you from writing the wrong amount of data. You're just moving the complexity from point A to point G, not reducing it.
> It is possible to reduce the complexity of the code, by delving deep into the interactions between DIX/MI/FB/DDX to flatten the code flow, making some deep structural changes. Or by using structured (de)marshalling through XCB. Doing this would be incredibly risky, but at least have a much higher payoff than just cosmetic shuffling because it is 'cleaner'.
> The immense value X11 has - that it always had and will have for decades to come - is its backwards compatibility, still being able to run 40-year old apps. You correctly called the codebase 'fragile' - you've been finding this out as your changes repeatedly break things. If you're breaking apps, then what exactly is the value in a codebase which is 'cleaner' to your subjective standard but doesn't actually work?
1 reply →
I hope so. I've tried to use wayland more than a decade ago, it was unable to replace xorg. Again last year, same story, and we get told that it's our fault because we need to adapt our workflows to wayland. I chose Linux because I get to choose how I work.
2 replies →
The MR that caused the drama that caused the fork to happen complained about this author doing tons of work to tons of legacy code with no direct user-facing benefit without testing his changes properly. From the sentiment of the discussion I gather this isn't the first time either.
I think trying to improve the quality of such old code bases is good and "don't touch it in case something breaks" has caused more problems than it solved, but in this case the lack of testing caused X to die when someone runs xrandr. Not exactly a vague use case. Large restructuring work and taking care of tech debt is good, but it should go along with diligent testing.
Until all the work is done, I don't think this will be a very stable alternative to X.org. I also don't think many people will follow this guy to the new project because the comments on the MR seems very "this guy versus everyone else".
Even if the fork stabilizes, that's just where the journey begins. The X.org system interacts with tons of other systems (the kernel and GPU drivers, among others), so that work need to be kept up with. At the same time, developing all of the new features the dev wants to add will be pretty useless unless applications start making use of them, and they're not going to if the project remains small.
If the anti-Wayland people unite behind this project and maintain their own X fork, there may be promise in this fork. But looking at the history, this is more likely to become another X12/Y11, or maybe a Mir if he can get a distro to back him.
just to be sure, the “well-known developer enrico weigelt” here means “a well-known bona fide german fascist enrico weigelt”.
Keep calling normal things people like or need fascism and you'll find yourself surrounded by legitimate fascists.
1 reply →
Oh, it’s the vaccines are a "human experiment that basically creates a new humanoid race“ guy from LKML!
Yup. https://www.theregister.com/2021/06/11/linus_torvalds_vaccin...
Is there any discussion about him being removed from the project on a mailing list or some other channel?
I can't find a "why" in the handful of PRs I opened.
There’s some drama in https://gitlab.freedesktop.org/xorg/xserver/-/issues/1797
6 replies →
Autoritarian organizations never explain their reasons.
Wrong. The fork was planned since a long time ago.
Well-known as in notorious, right?
precisely.
Never coded, made a change or updated X11. It always just works. But reading this thread that spawned some of the feelings around the ‘fragile’ codebase sounds like it is really hard to work on
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1797
This is hilarious, can totally understand the fork and will take a look
Enrico seems like a prolific maintainer but also a frustrated one.
7 replies →
I hope this succeeds plus I hope they are open to allow patches from OpenBSD. IIRC, Xorg would not accept patches from them, them, thus we have xenodm.
Also I hope NetBSD, FreeBSD and DrogonFlyBSD jumps on, this way the BSDs do not have to jump through loops for Wayland and they are not being forced to follow Linux.
And network transparency rules :)
seconded, and yes I guess all that is back on the agenda.
I read through some of the context and his commits and the guy seems like an absolute liability. I’m more careful making such changes on our internal greenfield prototype…
It's that time of decade again.
start x
[flagged]
Screw redhat and microsoft, they have destroyed linux (gnome/systemd/secure(:clown:) boot/linux foundation)
x11 works on all my machines, wayland and gnome don't
I've often wondered why there are so many people who want X to just die and will dismiss any criticism against Wayland. They sure do like shifting the blame elsewhere instead of acknowledging that some users do have issues running their applications.
Just yesterday I checked again if anything's changed, but nope. Jitsi Meet flickers, gr-fospher flickers and doesn't even render the plot, Emacs Application Framework doesn't work, etc. All these work perfectly fine with X.
Here is an excellent opportunity for those who believe in the continued development of X to pick up maintenance and push it forward. Time will tell at the end.
[dead]
You could almost swap systemd and sysvinit out here. the biggest difference is that X and Wayland is a true dichotomy here.
The only way to make Wayland work is to burn the boats. It sucks but that's the truth.
Why was this flagged? I'm not even sure what that mean or that I've ever seen it before.
Means it was deemed inappropriate for discussion on HN, spam, or low effort content.
I agree, I am not sure why exactly this was flagged.
[dead]
I'm surprised they set up Telegram and Matrix, but not IRC for chat... you know, for those situations when X isn't working...
Both Telegram and Matrix have TUI clients! Not exactly officially supported or anything, but https://github.com/FedericoBruzzone/tgt and https://github.com/gomuks/gomuks will work more than well enough until you can get your X server working again.
#XLibre has existed on Libera since the time of your comment
I run out of mental capacity for the Wayland bullshit - I am really looking forward to this X11 fork!
https://web.archive.org/web/20210202134702/https://drewdevau...
https://old.reddit.com/r/linux/comments/layh7k/im_tired_of_t...
Have fun - there is a reason everone on freedesktop.org went to wayland more than a decade ago though.
Because they're paid by Red Hat to make the Linux desktop unusable? We know.
Can someone explain what's the big idea with that ? I keep seeing conspiracy theories about how Red Hat is sabotaging the Linux desktop on purpose, but I would quite honestly like to see an explanation as to *why* Red Hat would do that.
1 reply →
the fork looks like it is backed by nvidia, but it will be a few months until an actual new release is ready. Best linux news all year.
I am pretty sure you are wrong. They even tell in the README https://github.com/X11Libre/xserver that nvidia is going to be a problem.
While I doubt Nvidia will back this fork over the real X.org, their open source drivers should be less problematic.
Unfortunately, whether or not you can use their open source drivers depends on what year you bought your GPU, and anything not labeled RTX or GTX-16* will never get a fully functional open source Nvidia driver.
ok, why? any grand plan? what's the background and why would anyone bet on X.org when wayland has been ok for a decade now?
Wayland is still pretty garbage. Hyprland is the most viable window manager replacement. The community is amazing too, way better than the Sway people. Lots of help from their forums and chatroom. Still, I had trouble with some basic stuff not working. So much tool replacement! So much work, for so little reward.
With i3/X11, I can run xrandr and see all my disconnected displays. As far as I can tell, there is absolutely no way to see disconnected display outputs in any wlroots or other Wayland composer. None. There's no standard way to do screenshots or video recording. It requires some custom portal for every single composer. I've never gotten Flameshot working in Sway or Hyprland and the suggested replacements are clobbered together garbage.
I do use network transparency (ssh -Y) quite often and it's not there in Wayland.
i3/X11 is just so much better and smother and I don't see the gain of Wayland. It's 100x more difficult to write programs that need to work in different composers. I hope this project succeeded and we really do see an X11R8 out of it.
I'm old enough to remember the switch from XFree86 -> xorg. I hope we see that again and we have real competition so the Wayland devs can finally get around to fixing their broken garbage of a display regression.
There's waypipe (https://gitlab.freedesktop.org/mstoeckl/waypipe), which works well in my experience. Although I must say I don't use network transparency (be it X or Wayland) much these days.
> when wayland has been ok for a decade now?
Looks like developers from Valve that were tasked on working on Wayland don't agree[0].
[0] https://news.ycombinator.com/item?id=41640420
Am I missing something? I don't see where it's mentioned that Valve is exhuming the corpse of X.Org.
2 replies →
There is no grand plan. It's just more garbage piled on top of garbage.
But enough about Wayland
2 replies →
Fantastic news. Glad that someone is continuing to support functioning graphics on Unix and Unix-like operational systems. Wayland is a joke toy with no future.
[dead]
[flagged]
[flagged]
[flagged]
[flagged]
Why though? From what I've seen, the X protocol serialization is very simple, so it wouldn't solve any actually existing problem.
Why? Well, the existing protocol is 40+ years old, widely used and seriously battle hardened. The new one would be brand new and therefore infinitely better according to basic open source logic
1 reply →
Have you seen this? https://en.wikipedia.org/wiki/Mir_(software) They proposed to replace the transport layer with Protocol Buffers.
3 replies →
Please no. I've worked on code that used ZeroMQ when it it should have used a more carefully thought out protocol. That's extremely overrated.
> ZeroMQ has support for Unix Domain sockets even on Windows.
The support for Unix-domain sockets is there, in X and in the OS, regardless of whether you add ZeroMQ in the middle. Adding ZeroMQ wouldn't solve any problem in this regard.
[flagged]