Hacker News Reader

Comment by ddevault | Hacker News Reader

Oh, look, more non-experts spreading misinformation about Wayland on HN. Must be Sunday.

https://drewdevault.com/2019/02/10/Wayland-misconceptions-de...

Please don't take HN threads into flamewar. However wrong others may be, it's not ok to break the site guidelines by attacking them personally or impugning bad faith. If you have evidence of abuse, that's different—but the bar for 'evidence' obviously has to be higher than other commenters simply holding a different view.

Believe me I understand how frustrating it is when the community or a large subset of commenters seem to be repeatedly and perversely wrong about something. But that is the internet doing its thing. We all run into it on some topic that we know a lot about and/or feel strongly about. It can't be stopped or fixed. All you can do is share some of what you know, and yes, it's Sisyphean because the whole thing is stateless and has to be repeated every time. It won't stop because you ask it to or want it to; "it" is impersonal and doesn't have consciousness to begin with. One needs to accept that for one's own sanity (I hope it's clear that I'm talking from personal experience about this) and then patiently supply corrective information wherever you can and have the energy. Telling people to "fucking knock it off" (https://news.ycombinator.com/item?id=24889242) is only going to hurt both yourself and your cause. We also can't allow it in comments here for obvious reasons (https://news.ycombinator.com/newsguidelines.html) and we've been pleading with you for years already not to do it.

We detached this subthread from https://news.ycombinator.com/item?id=24885769.

> we've been pleading with you for years already not to do it.

The same years during which you've done nothing to prevent the spread of seditious misinformation on Hacker News. If you were better moderators I might take your guidelines more seriously.

My thread with counter-arguments is detached and languishing at the bottom of the page, meanwhile all of the misinformation dominates the conversation comfortably from the top. This is a gross failure of the moderation on HN. Are you a human script, enforcing the guidelines with blinders on? Or are you a moderator, helping to craft thoughtful and good faith discussions, and to combat misinformation and propaganda?

Detaching flamewars so that they languish at the bottom of the page is standard HN moderation and the reason we do it should be obvious. If you don't want that to happen, nothing is easier to avoid (from a moderation point of view): simply provide corrective information respectfully. Of course that is not so easy from a personal frustration point of view—that is something every HN user (certainly including me) has to work at.

I definitely don't want to penalize your counterarguments, but if you can't or won't decouple them from guidelines-breakage, what choice do we have? We do just the same with users and threads that are arguing the opposite.

There are two very different issues here: (1) Wayland; (2) protecting the commons. Important as the first one is, the second has to take precedence because it affects every topic, every thread, and the survival of the community.

The commons are full of propeganda and misinformation at the hands of your policies to "protect" them. Your guidelines are not holy writ, and are unfit for this task.

If you had responded with rebuttals to the misinformation in the article and/or comment thread, plus a link to your previous article, without the snarky tone, your comment thread probably wouldn't be languishing at the bottom of the page. It's not enough to be right; tone matters too.

I completely agree there is a lot of misinformation but you can't fight it with flame, only with facts.

* If phoronix made test maybe we need to make another one.

* If people say it is hard to make application we can show that GTK+ works on both X.Org and Wayland.

* If they say it is impossible to make screenshot show grim.

* If they say X11 networking show bitmaps traveling by network.

* If they say no Wayland improvements show video of tearing.

My arguments buried here too.

So, there are plugins somewhere that support all kinds of basic functionality. I can already see how nice will be to keep a system like this up to date.

Do the developers expect to incorporate those plugins at the main code at some time?

Wayland isn't a code base but a protocol.

Wayland is both a code base and a protocol unless you are being unreasonably technical about terminology (distinguishing between wayland and libwayland) to the point where you are deceiving casual readers.

It is for all practical intents not possible to implement a useful wayland compositor without relying on libwayland, because mesa links to libwayland and expects to be passed pointers to data structures defined in libwayland.

Another obsolete "fact" about Wayland which hasn't been true since 2015. Which is all the anti-Wayland propegandists seem to be able to come up with.

This was addressed by the linux-dmabuf protocol extension (which also works on *BSD, despite the name). The mesa route has been deprecated for years.

I do believe that the parent comment was unfair; it is possible to implement a compositor without libwayland — but I do think that there is some truth in that the C structures are the de-facto protocol from the client-side. For example graphics drivers seem to expect wl_display and wl_surface [1] rather than, say expecting the object id.

It’s not as though this is different under X though and isn’t a criticism of Wayland.

[1] https://www.khronos.org/registry/vulkan/specs/1.2-extensions...

> isn’t a criticism of Wayland.

Indeed, my comment is merely observing that wayland is both a protocol and a code base for all practical purposes, I'm trying to leave the criticism to other people ;)

Ok, so does the standard body plan on incorporating those extensions into the main standard at some point?

That's not really how Wayland extensions work. If I can reword your question as "are these protocols legitimate and standardized" the answer is "yes".

Are they optional¹ and are there alternatives to them?

If the answer is yes, then there is a problem.

1 - I imagine "optional" can be the wrong word, maybe the correct is "universally adopted".

Maybe a more concrete example will answer your question. The Wayland protocols are found here [1]. Your compositor will implement some of these protocols and not others. If I’m writing an application I will; possibly through some toolkit, ask the compositor what features it supports and configure how my application works accordingly.

This isn’t particularly different to say, an toolkit not supporting a particular form of input, such as GLEW not supporting tablet devices or certain GPU’s having more extension methods — which you can see if you look at Khronos specification. Or an even more drastic example, is an application having both a terminal display and a X11 display like Emacs.

[1] https://github.com/wayland-project/wayland-protocols/

So, it's quite possible that one gets a distro or a machine set up so everything works locally, but you can not tunnel a GUI application or run a remote desktop there. Or that you get a machine where you simply can not take a screenshot to report a bug?

So... I was one of those people rooting for anybody to replace X11 when wayland launched. But given the current situation, I'm just hopping that Red Hat finishes dying off before I have to work with somebody stupid enough to set some GUI system that I need to access, but only runs on a computer where I can not run a GUI.

Well yes — in the same way that you could have had a half-baked implementation of X on a remote desktop; but it’s unlikely because most GUI-based interfaces will bundle with some level of support. For example, I don’t expect Canonical’s Wayland compositor to not support screenshots; so while I don’t think your worry is unfounded, I do think it’s disproportionate.

Oh, ok. I imagine you had a stricter interpretation of "universally adopted" then.

If every practical system support them, they are universal enough.

Yes, they're optional, and no, they're not universally adopted, but this doesn't damn Wayland. An example of where the screenshot protocol isn't supported (and this is fine) is where Wayland is used as the driver for the dashboard display in a vehicle (which is one of the major places where Wayland adoption is strong in industry). Wayland is designed to accomodate a broader variety of use-cases than X11: it's not just for desktop systems. That's why these protocols are optional and separate from the core Wayland protocol: it gives us greater flexibility, by design.

Among desktop systems, GNOME is really the only one who maintains a concrete objection to these protocols. KDE supports most of the wlroots-sponsored protocols in theory, and a handful in practice - patches welcome for the rest. The remainder of the major Wayland implementations for desktops, and many for mobile, support most or all of the necessary protocols.

I am really getting tired of explaining this stuff, over and over and over again. Can we please just stop spreading FUD for technologies that we don't understand? I'm just so sick of it.

Why do people do this? What can be done to stop it? Obviously nothing I've done so far has been working. This feels like talking to conservatives about climate change.

From the linux-on-the-desktop perspective, I have the impression there are 2 major groups today: Red hat, going all in on both gnome and wayland, or most others on X11. So gnome having an objection to these basically means wayland does not have them. All the other wayland clients together are mostly background noise.

Stated from a programmer perspective, what I can count on being available. What is the baseline?

Desktop linux is a mess compared to windows or OSX, with gnome/KDE as major frameworks, and a ton of minor but still relevant frameworks. The one thing they have in common, the one thing that makes GUI applications work more or less together is X11. Wayland causes a split here: yet another painfull technology reset that will probably cost us a decade before everyone has migrated. Now if wayland itself is fractured between its major player and everybody else, there is a 3-way split.

It seems X11 will die, Gnome as 800 pound gorilla will dictate the technological baseline, hence end users will lose basic functionality after suffering trough wayland's maturisation.

I can understand your frustration. You've probably built something great, X11 seems a dead end, and I presume you can't do much about Gnome. But I'll either have to live with this mess or run back to windows. I've dealt with pulseaudio and systemd, and both were arrogant low-quality projects that took years to stabilize back to their original levels. I can live without beeps on my desktop for a week, or the occasional service weirding out. I can't live with a usable UI.

Maybe you deal with climate change conservatives by demonstrating they still can get their groceries without their CO2 spewing SUV.

I don't know what you mean by plugins. They're protocols, they have first-class support. X11 also uses protocols to implement these features.

The main code of what? Wayland doesn't have a codebase. There are protocols( just like x11) and different compositors support different extensions. The point is that it's much more modular this way.

I only really care about performance and Wayland hasn’t been very convincing [0] with no discernible improvement over X11.

[0] https://www.phoronix.com/scan.php?page=news_item&px=GNOME-Xo...

GNOME is not a good representative of Wayland. Wayland is just a protocol - it's up to the compositors to have good performance to distinguish it from Xorg, and GNOME does not do well in this regard. Other compositors, particularly wlroots, enjoy excellent performance.

Wayland also opens the door to many performance improvements which are not possible on Xorg, and which take advantage of newer GPU features, especially on embedded systems but moreso every year on desktop and laptop GPUs as well.

Drew, if someone posted a comment saying "there's this Linux feature that's incredibly slow on x86-64", it wouldn't be a refutation to say "it's fast on RISC-V". That would rightfully just produce a response of "that's nice for you, it's still slow on x86-64 and that's what I'm using, so from my perspective the feature is slow in an environment many people use".

If you want this to stop, make GNOME's performance better in the ways you envision, because it is the experience most Linux users get. (Quite a lot of work has been going into GNOME Wayland performance lately.) Arguments about Wayland protocol feature politics don't necessarily make the out-of-the-box experience worse; for many people it's a good "Just Works" experience. Stop telling people they need to switch desktop environments to get a better experience; some fraction of people will go "if I have to switch, I'll switch back to Windows/macOS/etc". A vanishingly small fraction of people will go "oh, sure, I should switch to a different window manager and environment that isn't what I'm used to and doesn't necessarily have the integration I'm used to, and switch my apps to match too; this makes me happy", and those people know who they are already.

"there's this Linux feature that's incredibly slow on x86-64"

This isn't the appropriate comparison. What they said is "x86-64 is incredibly slow", and then when you teased them for details, what they meant was "this Linux feature is incredibly slow on x86-64". To which the answer isn't "it's fast on RISC-V", but rather, "that's a problem with Linux, not x86-64".

If you have a beef with GNOME, then bring it to GNOME. Don't pin it on a tangentally related technology which bears none of the fault, and which has had hundreds of thousands of hours of work invested in it by volunteers all to make something nice for you to use.

Is your goal to fix people's terminology or to fix the actual problem?

It's not an end user's job to tease apart what specific thing is the root cause. If something changes, and their system feels slower, they're going to reasonably assume the thing that changed is at fault. That's doubly true if there's an easy switch to turn that thing on and off (which there often is, by picking a Wayland or non-Wayland session at login), and they can easily evaluate the difference in isolation. It might be cathartic to spend time yelling at people about who is actually at fault, but fixing the root cause would make there not be a fault to seek blame for.

People aren't going to stop running GNOME en-masse. Distributions are not going to abruptly abandon GNOME. If (and I do mean "if") there's some issue with GNOME's Wayland implementation, that's going to be many people's primary exposure to Wayland as a technology.

People will continue working on optimizations, to many places in the stack. It doesn't matter where the fault lies or where the fixes need to happen, the net result is people saying things like "I switched to Wayland and things got slower / less smooth / etc", and they're going to continue saying things like that. It'd be nice if people phrased it more that way (slowness associated with switching to Wayland, rather than Wayland being slow), and provided more details about their environment, rather than implying that "Wayland" is a single piece of software which should incur their ire. It'd be even nicer if there were less ire to go around because more things Just Work.

It's also entirely possible that some of the people in these various threads have issues with some other piece of software in the stack.

> If you have a beef with GNOME, then bring it to GNOME.

I'm not the one with a beef with GNOME; you seem to be. If you have a problem with GNOME, take it to GNOME. GNOME works great for me, and I don't care which Wayland protocols it does or doesn't choose to implement. You haven't even specified what precise change you think ought to happen there, just some general complaints about protocol extensions.

Regardless as to whether Gnome "does well" in the regard of performance, you must admit that for some of us choosing a competitor like wlroots over one like Gnome introduces a whole new adventure in replacing all the features of Gnome with standalone applications to use with wlroots. Plus a tiling window manager is a totally different workflow.

Not everyone has the time for curating a desktop environment with individual utilities, and not everyone likes tiling WMs. i3 gave me an RSI.

It's not a particularly arduous "adventure". We maintain a list[0] of programs which use these protocols. And wlroots != tiling window manager: there are multiple wlroots-based compositors which do not use the tiling paradigm, the most developed of which is probably Wayfire[1].

[0]: https://github.com/swaywm/wlr-protocols/wiki

[1]: https://github.com/WayfireWM/wayfire

Apologies; I misunderstood one of your links and thought sway had been renamed to wlroots.

To be clear the "adventure" I'm talking about is for replacing desktop environment niceties like the ones provided by gsettingsd and the tight integration provided between devices and the system management tools offered in full desktop blown environments like Gnome and KDE. I used i3 for six or seven years and it was never as nicely integrated as Gnome and I spent a LOT of time yak shaving to get it nice and keep it that way. Eventually I gave up. Gnome is really nice these days.

But maybe I missed the point of your original comment.

wlroots excellent performance => bottleneck is not Wayland.

Gnome will catch up some day.

Gnome hasn't provided a good desktop experience since 2011. By the time they figure out how to stop sucking insofar as Wayland performance they will surely have discerned new ways to err.

There are other environments that have worked well for a decade and will work well for the next decade.

Test was about GNOME, I do not understand what they were expecting. It should be about same on most workloads.

Which embedded systems actually run GLES on Linux stably enough to do anything with Wayland? My experience is the choices are:

Use a binary blob that only works with a 3 year old vendor kernel, and works most of the time (but you can't fix it when it doesn't work, and if you are compositing most of the time isn't good enough)

Use a mainline Linux kernel that is so buggy that fixing the bugs in it is a full time job

Use fbdev

Wayland has nothing to do with GLES, and some compositors support pixman-based rendering similar to Xorg on embedded devices.

Is there a benchmark where it blows X11 out of the water?

I am not aware of any up-to-date benchmarks which make a fair comparison (i.e. not just benchmarking GNOME), but I am intimately familiar with the technology and its performance characteristics.

Gnome is a fair comparison. Since it is the main comparison for many users, it is the most fair comparison.

Otherwise, this is starting the benchmark wars with meaningless comparisons at the outset. :(

It's not a fair comparison. You're benchmarking GNOME, not Wayland, and making generalizations about Wayland based on GNOME benchmarks is a false equivalency.

Is GNOME on Wayland worse than GNOME on X11? Perhaps. Is Wayland worse than X11, based on that answer? No.

I get your point. But until those benchmarks at least correlate with behavior users see, they are not worth much.

Protocol limits what is possible. Legacy defines performance. Gnome is X11 first. Wlroots in Wayland first. It should be possible to optimize Gnome.

Wayland was created because of horrible X11 performance [1]. It is not Waylands prime time yet but X.Org still works and maintained. Phoronix.com should have checked contributions [2].

[1] https://www.youtube.com/watch?v=GWQh_DmDLKQ

[2] https://github.com/freedesktop/xorg-xserver/graphs/commit-ac...

These are appealing arguments. But our industry is flooded with appealing arguments losing to pragmatic compromises.

Our industry is flooded with critics who do not contribute.

Most of the pragmatic solutions were built by contributing to existing things, not starting over.

Think risc v cisc. It isn't that there are not points to be gained from the alternatives. It is that leaving the past behind is not necessarily the best way to get progress. And even when enough time passes that the alternative gains ground, it often looks more like what it was replacing than less.

You clearly have not watched video by X.Org developer, have not you? I expect you are better informed, worked a lot with X.Org codebase and can show some links on your commits.

Or if you truly believe there is nothing wrong with X.Org you would become maintainer.

> My (often incorrect) views and opinions are my own and not those of anyone I currently or have ever worked for. Please help me make them more informed (and hopefully more correct) whenever you can!

Goal shift much? My point here has been to point out that gnome is the benchmark that matters most. That one side seems bent on ignoring that is baffling to me.

Sadly, for the most part I have been discouraged from Linux desktop usage in recent years. Shame, as I have been on Linux for a couple of decades now. That said, I confess this is opening my interest. Would love to get myself and my children contributing, and I will start looking for ways to make that possible.

> I only really care about performance and Wayland hasn’t been very convincing [0] with no discernible improvement over X11.

there would be no controversy with

"I only really care about GNOME performance and GNOME Wayland hasn’t been very convincing [0] with no discernible improvement over GNOME X11"

GNOME matters for you, it does not matter for me (xmonad, xterm, browsers). If all user see is GNOME he can decide it is Linux that is broken as well.

"The real story behind Wayland and X" by Daniel Stone (link above) specifically shows X11 performance problems, it is view from developer what is wrong with X. The story which we, as users, do not know. We can't blame developers for trying to implement something sane.

I have no contributions to core projects but I don't blame them either.

Ah, fair. Taking back to the root, I see the connection. Since you directed specifically at me, I took it just back to my entrance.

Continuing in that vein. I stand by pointing that the choice of benchmark matters. I've been burned by my own choices and choices from peers too often to agree that hypothetical benchmarks will see improvements for everyone.

I also find it dubious that there are many use cases that are better served today than in the past. I want to believe you, but the evidence is coming in weak with a ton of argument from authority. You don't get a pass just for being a developer to tell users they are wrong.

It would be nice to reproduce phoronix results. Do they run in GNOME shell? What if I run in Sway? What exactly they expect of Selenium? I've heard gedit startup example.

Sorry, I can't continue until you've watched presentation [1]

> gedit startup:

> 130 blocking InternAtom calls

> 34 blocking GetProperty calls

> 116 property change requests

> blocking because Xlib is terrible

> usually spends 25ms waiting for requests

> sometimes spends 1428ms

[1] https://youtu.be/GWQh_DmDLKQ?t=1390

> GNOME is not a good representative of Wayland.

Can you recommend me a good representative of Wayland I could try?

I've been running KDE Neon for the past few years, but as you noted elsewhere it seems KDE on Wayland needs more work still.

I love it when experts explain to users why their opinion is wrong.

Reply on news.ycombinator.com