Hacker News Reader

Comment by UltraSane | Hacker News Reader

Once applications moved local and GPUs became the rendering path X11's network transparency became pure overhead for 99% of users. Wayland fixes this by making shared-memory buffers the core primitive and remote access a separate concern.

View on HN

Not to mention that the complexity of X11 shots through the roof once shared buffers comes into play.

X11 was ok for it's time, but fundamentally it's an really outdated design to solve 80s/90s issues over the network in the way you solved it back then.

It is INCREDIBLY outdated and forces all graphics to flow through a crappy 80s era network protocol even when there is no network. It is the recurrent laryngeal nerve of graphics technology.

If Wayland doesn't need network transparency why do Wayland clients and "server" still communicate through a socket though?

Why not use a much simpler command buffer model like on 3D APIs, and only for actually asynchronous commands (but not simple synchronous getters)?

PS: is io_uring using sockets for its "shared memory ringbuffers"? If not why? Too much overhead? And if there's notable socket overhead, why is Wayland using sockets (since it has to solve a simar problem as io_uring or 3D APIs).

It's only using sockets to pass a handle to a buffer though. Sockets are plenty fast, but not moving stuff in the first place can't be beaten.

Is it 99% of users? Of the linux (desktop/laptop) users I know, the majority use X-forwarding over ssh at least occasionally, while non-linux (desktop/laptop) also use X-forwarding (this is in an academic context), so while this may be an improvement for a subset of linux (desktop/laptop) users, across the whole linux user base (excluding both Android, which does not use wayland, and embedded, which I understand does use wayland), it's not.

I don't think I have used X-forwarding in the last 10 years unless for checking whether it's still there. Most of the time, it was, and running a browser even on a nearby machine was not a pleasant experience. Running Emacs was less bad, but the only things that actually worked well were probably xlogo and xload.

X-forwarding isn't used nearly enough to justify it having to be used all the time.

...and then you have long time Linux users (like me) who cannot feel any of the benefit of removing that overhead. The only difference I can tell between X and Wayland on my machines is that Wayland doesn't work with some stuff.

and then there are probably as many if not more that notice zero difference at all. and a sizable amount of people who notice things that are BETTER, such as for example actual support for HDR and 10bit, per-screen refresh rates etc

I'm pretty sure it simplifies the code a lot.

That doesn't help when the code talking to Wayland becomes much more complicated.

Why would it be more complicated?

Most apps are just using GTK and qt and doesn't even care about their x or Wayland backends.

This is what I was thinking when I read this. Wouldn't it just be easier to use GTK (or Qt) everywhere? They are already well supported on every other platform and can look very native the last time I checked.

> Wouldn't it just be easier to use GTK (or Qt) everywhere?

Which of those? GTK apps look alien on KDE desktops, and Qt apps look alien on GNOME desktops. Also, if you only need to create a window with a GL or Vulkan canvas, pulling in an entire UI framework dependency is overkill. There's SDL, GLFW, winit etc etc - but those also don't fix the 'native window chrome' problem in all situations and they all have to work around missing Wayland features. The bare window system functionality (managing windows - including window chrome and positioning(!), clipboard, drag'n'drop, ...) should really be part of the OS APIs (like it is on *every other* desktop operating system). Why does desktop Linux have to do its own thing, and worse (in the sense of: more developer hostile) than other desktop operating systems?

Frankly I don't get your problem or how is it different on any other OS. So your solution to GTK or qt looking alien is to look alien to everyone? Like there is no universe where "GTK doesn't look good, I will go with a custom written vulkan canvas" is a realistic scenario. Especially when all this has been blown way out of proportion when companies happily wrap their web apps into a browser and ship it as their software.

So again, how is it different elsewhere? What about windows, where even their own frameworks look alien because they have 3-4 of them? How is that the fault of Wayland somehow?!

> So your solution to GTK or qt looking alien is to look alien to everyone?

No? Where did I write that? I want my window to look and feel consistent with all other Linux desktop applications, and this is mainly achieved by having common window decorations (a problem that had already been solved by any other desktop operating system in the last 50 years).

> a problem that had already been solved by any other desktop operating system in the last 50 years

I just gave you an example of Windows that by default fails this requirement (see settings vs control panel or what that is called), let alone when you install applications using sorts of different frameworks.

Maybe other OSs solved this, but Windows didn’t - it just kept adding new UI libraries replacing older ones so that old software could still run and look old.

Reply on news.ycombinator.com