Hacker News new | past | comments | ask | show | jobs | submit
I don't get the frustration with wayland (the protocol) in the comments. This project shows that having a separate window manager was always possible. First we got wlroots as a library that did most of the heavy lifting, and now we got river as an even higher level abstraction.

Sure I agree that wayland (the project) could have provided these abstractions much earlier. But anyone else could have done it, too. We get all of this for free, so we shouldn't complain if other people don't do the work that we could do just as well.

> I don't get the frustration with wayland (the protocol) in the comments.

They took a firm principled stance against screenshots to start with, which set them up for the COVID WFH wave. Then we've got this questionable design that seems hard to make accessible since accessibility is a security risk and we're heading right into Agentic AI which will be interesting. I've been avoiding the Wayland ecosystem for as long as I can after the initial burn and it'll be curious to see how well it supports bringing in new AI tooling. Maybe quite well, I gather that Pipewire is taking over the parts of the ecosystem that Wayland left for someone else and maybe the community has grown to the point where it has overcome the poor design of Wayland's security model by routing around it.

My guess is the frustration is coming from a similar perspective because it is a bit scary seeing Wayland getting picked up everywhere as a default and the evidence to date is they don't really consider a user-friendly system as a core design outcome. Realistically Wayland is 2 steps forward even if there is a step back here or there. The OSS world has never been defined by a clean and well designed graphics stack.

loading story #47400187
I'm not sure I get the link between being against screenshots and working from home during COVID ?
I think wayland is OK as a user. But Wayland is just not really that UNIX.

As ordinary user, I actually don't care about any of this. However, from another perspective, I think this is a bad thing—open source projects have become product-centered, defaulting to the assumption that users are ignorant fools. This isn't how community projects should behave, but those projects is not that community-driven anyway.

After all, for a long time, so-called security has only been a misused justification—never letting users make mistakes is just a pretty excuse, meant to keep users from being able to easily access something, and eventually from ever accessing it at all.

Mostly agree, but X11 does not fit well into the unix model either.
First they said we couldn’t have screenshots because they were insecure. Then they added them back in.

Next, it was accessibility APIs and I guess copy paste is still flaky.

Now, it’s window managers.

What’s next, Remote Desktop?

The whole reason given for wayland’s replacement of x11 was that those things are all fundamentally bad ideas.

It’s been 15 years. Linux desktops are more fragmented than ever, and they’re still going forward with mass deletion of legacy x11 applications.

The only benefits to end users are things like HDR, or backporting a compositor feature or two, which X11 could easily be extended to support.

Instead we get two decades of the digital equivalent of book burning for reasons no one understands.

> like HDR

And variable refresh rate, better fractional scaling (and per-monitor scaling), atomic updates, native touch & gestures. And the isolation/sandboxing is important. The problem is Wayland didn't have portals in the beginning (hence the screenshot issue).

Wayland isn't the problem. The pace at which distros (and GNOME, lets be real who is behind the push here) started stripping out X11 was too fast, and too early.

loading story #47400091
> I don't get the frustration with wayland (the protocol) in the comments. This project shows that having a separate window manager was always possible.

Wayland is 17 years old. At this point, it's almost more frustrating to have one of its bigger architectural problems potentially addressed, precisely because it shows that it was always possible, and the people pushing for its adoption just... didn't bother doing the things that would make it easier to adopt.

I'd guess it's because of the general attitude of the project's community, specifically GNOME people and their “my way or highway” style of answering questions e.g. about CSD or other non-critical stuff, not directly related to core protocol. If they were a bit more accommodating to reasonable requests from outside, they'd get less backlash in comments. There's plenty of exemplar behaviour elsewhere in adjacent communities, they could have taken hint multiple times.

That they provide this stuff for free would be a good argument if the stuff wasn't pushed down people's throats with no working alternative and Xorg being discontinued.

meanwhile i have 0 issues atm with kde wayland which i have been running for 3 years

because the devs actually have implemented things that i cared about

And how would they be able to "push stuff down people's throats" if people could walk away towards alternatives? When such alternatives don't exist, that's exactly how "they do stuff for free and nobody else is putting in the work to make something else" looks like.

The problem isn't they "pushing stuff down your throats", it's nobody else (including you) making alternatives that you like better. You are voluntarily ingesting their stuff because your only alternative is starving.

> And how would they be able to "push stuff down people's throats" if people could walk away towards alternatives?

It's a forcing of their narrow opinion on what should be allowed onto the ecosystem at large, because all of these things are connected. You can leave to a different DE/distro, but if every DE is doing its own thing for global hotkeys or whatever, then software in the ecosystem is going to be hacky/bespoke or have an unreasonable maintenance burden.

Even if you in particular can move elsewhere the ecosystem is still held back. We only recently got consensus on apps being able to request a window position on screen, which is something x11, macos, and windows all allow you to do. CSD and tray icons are other examples of things found everywhere else that they did not want to support. Some applications are just broken without tray icon support.

This bleeds over into work for folks releasing software for Linux in general. By not supporting SSD they were pushing the burden of drawing window decorations onto every single app author, and while most frameworks will handle this, it's not like everyone is using qt or gtk. App authors will get bug reports and the burden of releasing software on Linux needlessly climbs again.

Hard to convey how unreasonable I feel their stance was on tray icons / SSD. It should be the domain of the DE from a conceptual but also practical point of view, even from just the amount of work involved. It reminds me of LSP's enabling text editors to have great support for every language. And again, Gnome was the odd man out in this, they want extra attention and work when Linux is the lowest desktop marketshare by far, and they themselves are not the overwhelming majority but they are large enough that you really do need to make sure your software runs well on Gnome even if you want to support Linux.

People think Gnome push stuff down your throat because they have the power and influence to impact the ecosystem, and they use that power and influence to die on absolutely absurd hills.

loading story #47399138
{"deleted":true,"id":47396005,"parent":47395914,"time":1773645844,"type":"comment"}