Comment by wmanley | Hacker News Reader

Comment by wmanley | Hacker News Reader

Parent Full thread

> You're kind of getting tripped up on terminology.

I'm not. My comment doesn't address the latency of gnome shell. I understand the boring technical distinctions between wayland and wayland client libraries and wayland display servers and gnome shell and mutter and sway, blah blah blah. Much like I understand that Linux is a kernel. That it is inspired by UNIX, but it is technically not a UNIX. I also understand that if someone describes themselves as a Linux user they probably don't just mean that they have a Android phone or that the display controller in their dishwasher or wireless access point happens to include Linux the kernel.

The "well acksually wayland is just the name of the protocol" that emerges whenever a problem is brought up is a symptom of the underlying problem with wayland the system. The confusion that gives rise to these deflections is also a symptom of that problem.

By Conway's law systems end up resembling the organisations that produce them. In this way the design of wayland the system seems to be designed by people who don't want to work together. I can see a parallel with microservice architecture.

The distinction between protocol and implementation IS significant here.

Imagine comparing HTTP1.1 vs HTTP3. These are protocols, but in practice one compares implementations. I can pick curl for http1.1, but Python for http3, and http3 would very likely measures as slower.

Is that the protocols fault?

All this proves is that it's possible for a protocol to not be the determining factor; which says nothing about whether it's possible that it _is_ a determining factor.

You’re quite right. We’d need similar benchmarks done with other compositors.

I very much doubt that Wayland makes a difference for this test; Wayland is for IPC between the client and server. Moving the cursor around is done by the server, without needing to talk to the client.

>> ”well acksually wayland is just the name of the protocol" […] is a symptom of the underlying problem

> well acksually

It’s not the protocol’s fault, but the system and organisation that brought it.

Which brings up the other problem that Wayland introduced, that instead of one incredibly old inscrutable software stack doing these things there are now five (and counting!) new and insufficiently tested software stacks doing these things in slightly different ways.

It would have been nice if KDE and Valve could (would?) work together to reimplement KWin's features on top of wlroots. That would have basically made Gnome the sole holdout, and I imagine they'd eventually have switched to the extended wlroots as well, or at least forked it.

There's also EFL and one other I'm forgetting at the moment, but yeah.

It most definitely can be because the design of the protocol can force a bound on how performant it can be. While its true that certain implementations of HTTP can be faster or slower, even the best implementations of HTTP 1.1 (for example) are quite slow when you compare it to the alternatives.

I know this because I worked at a place which was entirely based around microservices using Rest HTTP as the protocol/interface, some teams had to use alternate methods because HTTP protocol was the bottleneck.

> I understand the boring technical distinctions between wayland and wayland client libraries and wayland display servers and gnome shell and mutter and sway

I do not. Does anyone know a good but quick introduction into these concepts and the problems they cause or fix?

All I know is that Wayland was supposed to be faster by taking some slow parts out of the loop, but that doesn't seem to be working, according to these figures.

Reply on news.ycombinator.com