Live data from Hacker News

X12: Requirements for a successor to the X11 protocol (2013)

x.org

211–220 of 318 posts

Re: X12: Requirements for a successor to the X11 protocol (2013)

#211

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.

Not obscure, just old. ATI Radeon HD 5000 series.

Re: X12: Requirements for a successor to the X11 protocol (2013)

#212

Earlier 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…

But look, having a stack that replaces many Unix services, and which you basically completely control, is very convenient. It allows, say, to drastically limit third-party userland in embedded systems, where Red Hat is big.

Systemd is trying to replace Unix, a bit more successfully than GNU Hurd.

Re: X12: Requirements for a successor to the X11 protocol (2013)

#213
post #196

The 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…

upstart: a broken design and abandoned by its author and canonical https://lwn.net/Articles/581548/

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)

#214
post #114

Earlier 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?

Not wrong, but if further chips away some pieces of the common open-source Unix ecosystem.

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)

#215
post #114

Earlier 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.

Yes I can confirm that Wayland runs fine 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)

#216
post #83

Earlier 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.

Xorg is maintained... by Red Hat. As steponlego pointed out, they're already binning up chunks of the code base, but that's just preparing for when they shut the lights off entirely. As soon as Red Hat says "Shop's closed, boys, we won't be updating this code anymore" KDE and Qt will happily cut out their X support. Especially since Qt has for years been targeting mobile phones, car displays, and embedded applications as its business model -- markets where Wayland is at its greatest strength.

Re: X12: Requirements for a successor to the X11 protocol (2013)

#217
post #163

Earlier 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.

That's from 9 years ago - here's the one that Debian is currently shipping (172 lines): http://paste.debian.net/1272485/

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)

#218
post #118

Earlier 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…

I don't see why a there cannot exist a daemon that handles these IPCs in a standard way (e.g. a pipe), and which can be politely asked by apps to map particular hotkeys. An API / UI should be available for the user to review and customize the mapping, and to resolve possible conflicts.

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)

#219
post #17

Earlier 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.

[deleted]

Re: X12: Requirements for a successor to the X11 protocol (2013)

#220

Earlier 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…

None of Waylands internal functions between a client and compositor are blocking or synchronous to my knowledge. Generally you fire off a message and will later receive an event back from the compositor, which is happening in an event loop.

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.

Post reply on HN