Earlier quoted context omitted.
If it works, it works. And some of us never bothered installing a compositor in the first place, so it's hardly a high bar.
Obviously it doesn't work if your workaround is disabling it. It is either bad hardware, or buggy driver. For the latter, it has to be some obscure hardware; popular hardware would have it fixed.
X12: Requirements for a successor to the X11 protocol (2013)
211–220 of 318 posts
Re: X12: Requirements for a successor to the X11 protocol (2013)
#212Earlier quoted context omitted.
Simply the fact that systemd turned logs into a binary format that can't be read with standard tools, and this was not (easily? at all?) possible ti cgange made me really strongly dislike it. systemd has its own tool to read its binary log format, but I've already seen it corrupt its own logs and fail to read it. And did they do the binary format for efficiency? Get this: I've never seen anything be inefficient due t…
redhat seem to have tried their best to use systemd to turn Linux into Windows NT - over-complicated service manager - binary logs that are difficult to find - incomprehensible task scheduler - hidden caching dns resolution service - disk manager - network manager - login management - crappy ntp client all it needs is svchost.exe something that was 100% reliable is now about 98% reliable, and when it inevitably break…
Systemd is trying to replace Unix, a bit more successfully than GNU Hurd.
Re: X12: Requirements for a successor to the X11 protocol (2013)
#213The discussion about "wayland vs X11" is eerily reminiscent of the discussion of "systemd vs. sysv-init"... Some people apparently really do hate it when things change that they seemingly have no control over Edit: I fully expect to be downvoted into oblivion for this post :-D
The problem is that systemd vs sysv-init is a false dichotomy. Systemd took over a ton of important non-init functionality, like DNS, logging, and interactive sessions. That could be fine if systemd did so in a nice and rock-solid way, but it was unpleasantly bug-ridden for years after being thrust on mainstream distros via a hard Gnome dependency. SysV-init sucks in many ways, it's well known, and I can personally a…
openrc: I don't believe openrc had a process supervision story 8-9 years ago. from what I recall at the time openrc was just a slightly better sysvinit.
runit: I have a lot of experience with runit, and while it works, it has many footguns and is hard to use correctly.
s6: a better runit with better footguns
A great thing that more people should read, is https://lwn.net/Articles/578210/ from one of the Debian developers who voted to switch to systemd. It touches on things like the lack of adoption of upstart, and openrc not solving the problems they had.
Re: X12: Requirements for a successor to the X11 protocol (2013)
#214Earlier quoted context omitted.
The largest issue with Wayland is it has "Linuxisms". That means no work was done by the Wayland people to make it portable to other UN*X. So the BSD folks (and other UNIX people) have a lot of work to get it going. And there still seems to be confusion if or will Wayland require systemd, from what I have seen, no 100% clear direction from anyone.
I mean, is it really wrong for linux people to focus on linux? What's the point of these different OS's if they all support the same software and software has to be made for lowest common denominator?
Few people run *BSD on desktops though (if you don't count all the macOS folks, but they don't care about Wayland anyway).
Re: X12: Requirements for a successor to the X11 protocol (2013)
#215Earlier quoted context omitted.
The largest issue with Wayland is it has "Linuxisms". That means no work was done by the Wayland people to make it portable to other UN*X. So the BSD folks (and other UNIX people) have a lot of work to get it going. And there still seems to be confusion if or will Wayland require systemd, from what I have seen, no 100% clear direction from anyone.
This used to be true, but not anymore. We have upstream support for FreeBSD in libwayland now. Other BSDs have MRs which are only waiting for CI support. Wayland itself has nothing to do with systemd, many users are running Wayland without systemd.
I am on Gentoo and using openrc and sway runs fine. The only thing that might kind of rely on systemd is sway-idle which wants logind (or to run as root iirc).
I know you know this, being the sway and wlroots maintainer and all but I figured I would show a concrete example of this working fine.
Re: X12: Requirements for a successor to the X11 protocol (2013)
#216Earlier quoted context omitted.
100% of the developers who know anything about how graphics works under Linux are focusing on Wayland. Development on Xorg is moribund, with only Xwayland getting significant attention. Hint: X was optimized for 1980s graphics, which was 90% simple blits, line draws, and fills mediated by the CPU perhaps with special fixed-function accelerators for those operations. In 2023, graphics is done with the GPU -- period. Y…
Sure but GTK and the gnome world is highly politicized by RedHat. KDE and Qt are much further away from cutting X11 off. I see the case for Wayland but similar to X11 it is already showing its age in poorly conceived design decisions. Desktop sharing for example should be a first class citizen in 2023.
Re: X12: Requirements for a successor to the X11 protocol (2013)
#217Earlier quoted context omitted.
Chiming in here to say that systemd seems to cover the 80% (or even 90%) case pretty nicely, however that last 10-20% is now really difficult. Anyone who has really delved into systemd knows this but they get shouted down as halting progress and hugging bash scripts, which is disingenuous as bash scripts (as per sysvinit) were painful and had great difficulties in areas such as determinism and parallel execution. If…
This? https://gist.github.com/thomasfr/e4e4bb64352ee574334a I don't see anything out of the ordinary there.
There's a little inline shell for Galera integration, but i suppose the rest is mostly comments,
Re: X12: Requirements for a successor to the X11 protocol (2013)
#218Earlier quoted context omitted.
> Of course, Wayland also has the problem that it's intentionally excluding some useful features that X had, like global hotkeys and screensharing Screensharing has been supported for some time already. Some apps support it, some don't. It is up to the apps to use the respective APIs, the times of free reign over framebuffer is over.
I mean, you can get screen sharing to work. But there are like 3 different incompatible "standards" for how to do it. There's no single simple answer to "how to record the screen in Wayland". This has been the state of screen sharing on Wayland for at least 7 years. I'm also very curious about what's envisioned for global hotkeys. Surely we don't expect people to manually go to their system settings and configure som…
This is basically the approach that exists in macOS for many years; I haven't heard a ton of criticisms towards it.
Re: X12: Requirements for a successor to the X11 protocol (2013)
#219Earlier quoted context omitted.
I think you’re being unfair to IPv6
In terms of usability - definitely. But it's built on top of similar unfulfilled promise: we're running out IPv4 addresses VS X11 is unmaintainable legacy full of security bugs. 20 years later IPv4 is still dominant, Wayland is still unusable and X11 just works.
Re: X12: Requirements for a successor to the X11 protocol (2013)
#220Earlier quoted context omitted.
> I've seen commentary from people who have worked intimately on both protocols and implementations of both who consider Wayland to have the better architecture. For those interested in details: https://www.youtube.com/watch?v=GWQh_DmDLKQ
This link comes up in literally every Wayland thread and it is even more bullshit now than it was in 2013 when it was first posted (and it was bullshit then too). It is titled "the real story" but it is quite the opposite. A few key points: 1) he laughs at how X has a bunch of extensions. https://wayland.app/protocols/ hypocrites much. In 2013, since it was completely unusable, it probably didn't have many. But turns…
There is an exception, which is the explicitly blockling "roundtrip" function(s), but that is meant for special cases only.
Being asynchronous was an design goal for Wayland from the very beginning.