Just recently (I was on a Fedora box temporarily) I was trying to figure out how to get Nautilus to stop starting a search whenever I typed something, and instead highlight the nearest match in the current directory, y'know, like pretty much every other file manager in existence. Eventually I found a thread where the core Gnome contributors were saying "it sounds like you don't want this feature, what you really want is a better search function". They probably should never have enabled "reactions" on their bug tracker since it was piled 100's high with negative reactions - yet they still doubled down and said it's not something they're going to support (despite having supported it in the past, and Ubuntu even bundling patches to make it happen up until recently).

It's a frustrating trend in FOSS that contributors feel like "we're doing this for FREE don't you know, so whatever we say is lore and since you're not paying, we don't have to listen to you". Yes, I understand how amazing it is that this software is truly free and created by volunteers, no, I don't understand how that gives you dictatorial power over 100s of users who don't like the changes you've made.

"Facilitating the unrestricted use of extensions and themes by end users seems contrary to the central tenets of the GNOME 3 design."

It truly needs its own fractal of bad design essay save it would have to a farce in 7 parts.

To say that they targeted a different kind of user is insufficiently descriptive. 3.0 was the beginning of ticking off the users they actually had in order to target users they wish they could get with a total package that such users could never encounter in a million years because joe average wasn't installing Linux in 2011 regardless of how simple you made the interface.

9 years later the Linux user base is virtually unchanged and gnome 3 is no longer horrifying as 9 years of labor have rendered it modestly acceptable after the worst ideas were put off or mitigated.

If you spent 300k building a hovel where the roof fell in quarterly and you after much consternation and a decade of work figured out how to keep the roof mostly in place most of the time I would pretty much expect such a project to be the go to horror story among home builders in the neighborhood.

This isn't meanness its just honesty.

It is not, sometimes GNOME devs even say outright that the project is for their peers and those who share their vision. They do their testing on other GNOME aficionados. In the days of Unity, Canonical did some of their user testing on regular people, those days are long gone.

I don't ever remember cursing my Windows 3.11 machine that the scrollbar and toolbar icons were distracting in File Manager, nor do I crash my car when the speedometer changes and wish that the distraction of the speedo and rev counter was removed.

I remember using GNOME2 and loving it.

I often wonder constitutes a "power user" - someone who wants to actually get stuff done and not fight the UI to discover things??

I wonder when iOS became the ideal - blindly fumble around whitespace to see if some text is actually a button or if there is some unfathomable control hidden that you need a magic incantation to discover (swipe left on a list control is delete - my mum still doesn't know this)?

Is a "power user" someone who has learned all the different ways of interacting with a modern user interface? You used to learn: click, double-click and scrollwheel. Now every interaction with a control is different and impossible to learn or discover simply by using it. Absymal.

Gnome more or less optimizes for minimal configurability, the theory being that most users want the UI to be as clean as possible. They do not particularly care if someone would like to be able to change some annoying behavior, because they thought that behavior made sense and they feel the cost of adding a button to disable it, or even burying a configuration bit in gconf, is far too high. Of course, they do not have the resources needed to run actual user studies the way Apple, Google, and Microsoft do, so their idea of what users want is mostly based on their own ideas about what users want (since they usually dismiss feature requests from their actual users, because those are "power users").

"There was only one catch and that was Catch-22, which specified that a concern for one’s own UI in the face of flaws that were real and immediate was the process of a power user. Orr was an average user and could be listened to. All he had to do was write a feature request; and as soon as he did, he would no longer be an average user and would have to be ignored."

Also it doesn't even show hibernate button on the "start menu" (or whatever it's called these days) - because apparently the ability to actually power down the box while keeping all states is too confusing to have!

I don't use Gnome because I don't like the direction they've taken it in. But they have absolutely every right to do with it as they please. And I have every right to insist it's totally not fit for my purposes and refuse to use it.

The same way I have no (current) interest in using Wayland because it'd be too much hassle to try to replicate my workflow with it. But they're free to ignore me the way I ignore them.

GNOME has tens of millions of users.

I do understand your sentiment. I don't like GNOME myself. But there are alternatives. If you don't like it, try using something else, contributing patches with configurable behavior or maintaining a fork.

FLOSS maintainers are a rare breed. We as a community need to find ways to not burn them out. Even if you have millions of happy users, just a couple of really toxic ones can make it feel not worth it.

I was referring to the hundreds of users who "reacted" to the bugzilla thread on this issue, but I'm sure it effects many many more.

> I do understand your sentiment. I don't like GNOME myself. But there are alternatives. If you don't like it, try using something else, contributing patches with configurable behavior or maintaining a fork.

Generally I don't use GNOME, on this occasion I was working on a laptop supplied by an employer. The frustrating thing isn't that they don't support a feature that I want, it's that they strip away features that existed before, and completely ignore and talk down to users who tell them that the feature is very useful and much wanted.

> they strip away features that existed before, and completely ignore and talk down to users who tell them that the feature is very useful and much wanted.

I'm under the impression that GNOME strives for similar UX to macOS. This behavior sounds just like Apple to me, so maybe it's just the correct way to do it.

I've used both macOS and GNOME as daily drivers and got frustrated with both. I'd certainly get frustrated if an employer forced me to use unsuitable equipment (and some have in the past). But that's not the fault of GNOME developers.

Those hundreds of user are:

1. A vocal minority, most likely. People happy about it don't go on bug trackers to support devs.

2. Not making the software, not part of the decision making process. Don't like the end result ? Fork it if you have the ability. Give constructive criticism if you want and you think the team is receptive to it (or even cares about it. Sometimes, I just don't want your genius idea).

So, yes. They're doing this for free. Don't like it? Fork it, or don't be an ass. If you can't do either of those, the third option is to fuck off.

It doesn't - you are completely free to roll back those changes, or make different changes of your own.

Maybe.

I think the discussion should happen.

Because I don't think "I wrote it, if you don't like it, you write it" is a 100% defense to hordes of upset users.

This doesn't mean you don't have a right to discuss or critique and discuss and if appropriately fork or write you own.

The option always remains to change it yourself or stop using it. It's not as if it's bound to the hardware (Apple) or shipped with the machine (Windows). It's not a SaaS that may vapourise or change underneath you.

There's no way to force consensus in situations like this. The best you can do is force out those maintainers you don't like with a harassment campaign.

If I changed every bit of software I dislike, I would have no time left for my actual job. Yeah, I get it, these volunteers found the time to work on this one project and therefore get more of a say about what changes will be made, but you know what? They also have to use other software, and they would not have time to work on something like Gnome if they were busy making changes to Wayland or the Kernel or whatever else.

Worse, in my experience, Gnome developers will turn down patches that do not align with their ideas about how things should work. I have had it happen to me, I have seen it happen to others -- even when we find time to change something, we cannot commit to maintaining our own private fork, and dealing with merge after merge or trying to keep up with a project that has as much activity as Gnome or Wayland. Obviously some patches need to be rejected, but in the case of Gnome I have found that rejection often comes down to their notorious "less configurability is better" attitude.

As for stopping using it, how does that work with critical packages like systemd? At some point you wind up having to ditch an entire distribution, with all its infrastructure and maintainers, just to get one use case to work. In some cases you are left with a choice between a project that has the features you need but has received no updates (including security updates) in years, or a project that does not have the features you need but is actively maintained. More often than not people will just give up on their use case, which in some cases means giving up on open source software entirely since that use case was the reason they were using open source in the first place. Some might think that is fine, users have the freedom to choose what software to run, but the fact is that fewer users means fewer contributors (including many people who make only the small but very important contribution of reporting bugs) and a less robust open source ecosystem.

They don't get "more of a say", they get ALL the say. This is the way of Free/Open Source.

As for stopping using it, how does that work with critical packages like systemd?

It works the exact same way. If you don't like it, don't use it. Simple as that.

To be honest I don’t see how you can understand the first bit but not the second. Yes, they can make changes that you don’t like without consulting you.

Commercial software, like most things in life, is responsive to incentives. The people who buy things get the most say in the product.

For open source where the end users aren't buying anything, and the developers are either creating product for their own gratification, or for some more nebulous corporate goal, the incentives are rather indirect. And that makes a big difference. Software, under those conditions, will frankly be worse for the majority of users.

This seems to be the dominant culture, but it's actually pretty toxic that people feel entitled to whine about software created by people who owe them absolutely nothing.

Constructive feedback is useful, and appropriate if the creator indicates that they want it.

Whining and ranting is a waste of energy. It makes people feel bad and leads to no beneficial change.

I don't think Drew DeVault wrote this because he's received lots of useful constructive feedback.

I don't think that's quite right. It's certainly bad manners to be rude, but the underlying complaints are one of the better - if not best - means by which the people who make the software can get feedback to ensure they're building the right thing.

Would you invest in a startup whose founders constantly complained about how their potential users whined about their product?

Aside from auxiliary revenue sources like complements and consulting, open source software has value in large proportion to how many people use it. Reputation and goodwill, if nothing else, bragging rights, job opportunities, and so on. You don't get these things from writing software than isn't used.

And you can't really expect everyone to provide constructive feedback. Often, the more emotional the rant, the more pain the user is feeling. Not all humans are dispassionate rational agents. Not every user is a professional product manager able to outline constructive incremental improvements to satisfy requirements. And it's silly to expect that. Product managers are paid well in industry to do this. Doing it for free for open source is just as much a donation.

I'll go further. If you're not willing to tolerate more and more rants as your software gets more popular, to the point that you end up not contributing or quitting, it might be better if you didn't start. Abandoned and decaying software hurts too, and it especially hurts the people who took a bet on it.

(I learned my lesson young. I created a few bits and pieces of open source, and quickly found the the effort of integrating the contributions of third parties more work than it was worth. The only way I'd do open source again is as a developer outreach / organization halo PR strategy for the benefit of a company I'm being well compensated to work for.)

If someone relies on a piece of open source software on the assumption that it will be maintained in perpetua for free, then they’re simply foolish, and they have only themselves to blame for any resulting harm.

> Not all humans are dispassionate rational agents

You seem to be forgetting that this applies just as much to the people who maintain open source projects. The endless negativity inevitably has an effect.

What makes you think people owe nothing to each other in the open source ecosystem? I maintain a package for Fedora, I have submitted a few patches to the Linux Kernel, and I regularly report bugs. Do the Wayland developers not benefit from any of the above?

Even my mother, who is not very technical, has managed to identify bugs here and there which I report on her behalf. Do the Gnome developers not benefit from that?

We cannot all be contributors to every package we use, but we are all part of an ecosystem and we all have the right to ask for changes by others in that ecosystem. You call it whining, but you know what? When developers break use cases, users have the right to complain about it. If the Wayland developers do not want to hear those complaints, they should not be involved in developing software that millions of people depend on, nor should they have tried to replace software that millions of people depend on.

Actual contributions are another matter. If you contribute to a project, then sure, you should get a say proportional to the size of your contribution. And I wonder how many of the people who complain about Wayland have made sizeable contributions?

An important point here is that it's up to the maintainers to evaluate the value of your contributions from their point of view. If you don't respect this, you're again trying to impose obligations unilaterally. That is, offering help that may not really have been wanted in the first place and then expecting something in return.

>If the Wayland developers do not want to hear those complaints, they should not be involved in developing software that millions of people depend on, nor should they have tried to replace software that millions of people depend on.

This seems way off base to me. I hope this attitude is not pervasive because it seems like it's a huge discouragement to people who want to write useful software. (If you succeed to any degree, millions of people are automatically entitled to shout at you whenever they experience some inconvenience.)

How many people asked for their distro to switch to Wayland?

You seem to think that these critical packages that millions of people depend on can be treated like hobbyist projects. Yes, when your project is a hobby, you can tell people that their complaints are not your problem and that they should just fork the code if they need something different. However, distros should not make hobbyist projects core components that users are unable to avoid, nor should anyone push their hobbyist project as a replacement for a core component.

The fact is that the Wayland developers set out to replace X11. In what world are they not opening themselves to criticism from people whose use-case was supported by Xorg but not supported by Wayland? By now a decision made by the Wayland maintainers will affect the vast majority of desktop Linux users; why should they be immune from complaints? When people depend on your software you have to deal with their complaints, that is just a fact.

People in charge of large FOSS projects like Gnome should not pretend it's just some hobby project they can do whatever they want with. Those projects are essentially public infrastructure and should be treated as such. It's not their personal plaything.

Yes, people who do the work have the most say, but sometimes they really use that to do stupid things with the code. I don't know how to correct that though. Commercial software is no better about this.

They're not pretending. I'm afraid you're laboring under a misconception. Nothing obliges the GNOME team to accede to the wishes of people who contribute nothing to the project.

Nothing, until users flee and they stop receiving bug reports, patches, donations, and so forth. Moreover, because of what Gnome is, if they drive users away it will also negatively impact other projects, because for a lot of those users leaving Gnome means ditching open source software entirely and switching to e.g. OS X.

Part of the joy of open source are the freedoms it gives you, including the freedom to fork a project that doesn't meet your needs and make it so that it does. This works as it should pretty often - look at the gnome2 forks, the systemd-less distros etc. There's plenty of choice out there, and plenty of opportunity to get involved.

If you're unwilling to exercise those freedoms, then you're just whining about the stuff you're getting for free.

Losing users is always a bad thing for the open source ecosystem. Lost users means fewer bug reports, fewer patches, fewer donations, and less support from paid developers working for various corporations (easy to forget but there are people whose job is to maintain open source projects like the Linux kernel). Fewer users means less incentive for hardware companies to provide any support, even just minimal technical documentation, needed for open source developers to write drivers (let alone contribute to that).

Forks require a significant commitment of time and effort, and really should be considered a last resort. The time commitment is much greater for prominent projects that receive a lot of activity like Gnome or Linux. Most users, even those with the necessary technical skills, do not have enough spare time to maintain a fork when things break.

Your dismissive attitude is fine for a obscure hobbyist project with a dozen users. It makes no sense for desktop Linux distros that now have many millions of users.

I understand that people can be aggressive, rude, and downright hostile. I'm not suggesting that such behavior be rewarded. Nor am I suggesting that every open source project has to do everything any user says. I do, however, object to the notion that there is no obligation whatsoever between the producer of a technology and the users of that technology, regardless of whether money has changed hands.

I struggle to express how strongly disagree. This is like saying that someone who gives away a 3D printer on freecycle is then obliged to help you fix any problems with it.

    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

I agree with that, projects should clearly state their goals and priorities upfront. But relying on legalese from MIT license is not the solution.

I said nothing of the sort. They have an obligation to the project and its value as a piece of infrastructure used by many (including noncontributors).

Pretty sure they are aware of this, even Gnome. Gnome's Dev Team is often citing user studies etc. and I believe they are genuine in trying to produce software for the public, rather then themselves.

...Though I believe they don't grog how disruptive changes (any change) can be.

It's not just the FOSS community, look at how non technical people react every time gmail, outlook or excel makes a tiny change to the UI (not to mention big ones). It really makes people angry when things don't work the same anymore, let alone when it doesn't even work anymore for their use case.

> In my admittedly somewhat distanced opinion, Wayland's biggest mistakes were not launching with a coherent strategy for replicating functionality like screen sharing, screenshots, and to a lesser extent remote desktop/applications. They just punted and said "that's a compositor problem!"

My guess is that it wasn't a deliberate strategy, it just that like anything related to the Linux desktop, the project was underfunded so they had to focus on certain issues. In this case it was focusing on improving from xorg and making sure it doesn't break anything on the main use cases of whoever was funding the project (mainly redhat). Apple and Microsoft can afford to pour billions in their display server/protocol/windowing system. Not so much for Linux.

As well it should. Because now things that used to take three seconds will take 15 minutes for a month until you learn the new interface.

The designer will respond that yes, but then once you learn the new thing it will take two seconds. And if you save one second twice a day then you'll have made back that 10 hours you spent learning the new thing in less than 50 years!

Except that they're going to change it again in less than 50 years.

And that's assuming that the new design is actually better and not just different or worse, because also, this:

https://news.ycombinator.com/item?id=25950351

Rule of thumb: If the new thing isn't better enough to cause people to switch to it voluntarily without any prodding or the removal of the option to use the old thing, it isn't better enough to be worth it.

Not saying it is right or wrong, but a lot of the upsetting changes for existing users are for the benefit of new users.

Also, "users" are "people" and the average adult lifespan (18-78) is around 60 years. That implies that the time for the "new users" to become half of the user base is around 30 years, so what does that say about how often it makes sense to do this?

But suppose you're right. Then the solution is competition. Don't take away the old thing, provide both. If the new users want to use the new thing and the old users want to use the old thing, great.

And then if the new users still want to use the old thing you've got a pretty good red flag that you messed it up.

That doesn’t add up at all... you’re implying that users are gained and lost at exactly the same rate, consistently, over a span of at least 30 years.

It doesn’t invalidate your other point about competition, but it’s a flawed argument to base any reasoning upon.

The point at which "new users" are the majority of the user base never even happens.

Your new UI might be garbage, but there's no red flag here. A new user will likely need to make use of tutorials, troubleshooting, and other help online; most or all of which will be based on your old UI (and possibly coupled with comments like, 'Don't use the new UI, it's trash. Here is how to switch...'). Having been such a new user, I only pick the new UI when forced or when it's clearly better; the former being the more common case.

Sure, you can make your official documentation use the correct UI (or design your UI in such a way that the documentation can be agnostic—but then what is this big change that makes lives better?), but unless your documentation is very good, people are still going to need to reference all these other sources.

Recently ran into this issue when submitting an app to Google Play. New interface didn’t even match up to Google’s own instructions. Frustrating.

Edit: unless there is a majority of unsatisfied customers (:

Most of them are too frequent, automatic, plus they are not actual improvements.

https://support.google.com/mail/answer/15049?hl=en

Old gmail is faster and normal things like opening a link in a new tab actually works like any other page and its actually a lot easier to read because of it.

In the new interface you are only given a fraction of the horizontal space for the actual mail, and I actually have to scroll sideways to see the pop out in new window control which for aesthetic reasons is only a graphic with no text label except on mouse over. Popping it out gives you a window that you may or may not need to resize or move for optimal reading and as far as I can see there is no way to just read the mail in a new tab in the same window at all which breaks most people's methodology for managing multiple tabs.

It's not merely bad its actively hostile.

It seems like the developers and product managers want to show progress but the uses just want you to fix boring bugs. It will help if the product folks think of memory, perf and stability as very important features and stop chasing new features for the sake of it.

Memory performance is not too big of a deal, IMHO given the last decade of hardware, but stability is.

Lost mental state is generally as painful as data is. People hate it viscerally.

I have seen 4 figure software get replaced by 5 figure software over that alone. 5 figure stuff runs for weeks to months at a time. 4 figure can crash daily or more often.

Stability was a primary selling point for me, and I used to maintain a session for that purpose. "My session has been active for months and 10's of projects, lets open your sample data and walk through it...." Did that on a reasonable, but not great Lenovo. Hibernate, sleep, hibernate, sleep...

Win 7 too, lol.

I came from IRIX. I would go the better part of a year, apps running, system up, all ready to go. Spoiled. Win 2k was good, Win 7 matched it, and Win 10 is solid, except for forced updates.

I would never, ever devalue stability. People who are focused, task intensive, live it, love it, will argue they need and are worth it.

Not sure they are wrong.

This is hugely underappreciated. Last fall I decided I would get back into making videos for YouTube after 7 years away. But two videos into the new series, and the constant crashes of my video editing software I just paid $$$ for have reminded me why I stopped making videos in the first place.

Ultra painful. And anytime I hit flow, I am either gambling by not saving and disturbing flow, or leaving flow trying to save... agreed.

Scriptable may find a lot of use.

Play it how you will, of course. I will pass hard personally. Lack of stability is very high on my qualification list.

To be blunt, where it exists there are other priority problems.

One may just be flashy speed and other sizzle done at the general expense of the solution being robust.

May only take an event or two needed to cancel out potential gains from those things. Turn that crank a time or two and many will just get back to work.

An attempt or two again? Many will ignore the solution and or have adopted something else.

Net result? The team that did not make stability a priority likely did a lot of market building for the ones who did.

I personally am very frustrated by this constantly, but there is no way around it that will always work. Someone has to pay the cost of market building, it is a separate cost from stability, and sometimes you can't afford both.

But, what does work far more frequently is to get the solution robust early. The longer it gets put off, the more difficult doing it is, both in time, cost, users being requited to do things along the way to support it all.

If so, they can pay now, or pay later, just make sure you manage expectations so they actually do pay.

If, somehow that ended up on you, of course they refuse! Why pay for a free lunch?

So don't allow that. Seriously.

Maybe the customer finds someone hungry enough to pay for them.

Or, maybe that customer pays hard going through this cycle a few times too.

Not my problem and it does not have to be yours.

Can definitely be robust and should be.

In this scenario, it is a mutual problem. Nobody has to use the software, true. However, it again is all about managing expectations.

If it is oversold, people will end up with bad experiences and that does impact who delivered them.

This has already happened. Will again too.

On a short timeline, maybe no big. On a longer one, higher order impacts may actually be painful.

Say a decade of negative public sentiment sees a brutal regulation kind of painful.

Entities putting billions in the bank can and should make reliable software.

There is a YUGE diff between Gmail, Excel and friends, and rando OSS.

This discussion ranged far away from the initial premise.

So, let us take it back a bit.

Weyland. Wants to be the defacto display solution. Does not have the same priorities many users have. Also does have priorities many users have.

Replacing X11 was made an explicit intent too.

Well, if it does not actually do that?

"All that Weyland shit talk" is the outcome.

Maybe subtract the replace X11 part, or maybe find a way to actually replace X11, or maybe just ignore the shit talk?

Because of that problem, I have always maintained we need a way to better fund some projects.

I would love to see the display system funded and all the good stuff worked out properly. For me, the network features and general flexibility of X is worth some money.

When I ran SGI machines, that money was paid and the display systems were flat out awesome.

If it does not do those awesome things? Meh, can just run Win 10.

I used Exceed a lot. Exemplary. That program did everything nicely. I even used a CAD app on Windows that actually was built for X and it was network transparent same as any Unix box!

There is a sub $100 one out there. Maybe a bit more now. Maybe gone too. It was very good.

The freebies are respectable and great for sysadmin.

Funding a first class X11 replacement that also does some new things people want for mobile and embedded makes a ton of sense to me, and I would sign right up too.

Maybe getting a bunch of us tossing a tenner a month at this would fund a project that just gets it all done.

And we need one.

It is obvious to me X11, used as it can be, sees way more than anyone may have thought today. When I was on IRIX, X11 was flat out awesome. Shit just worked, and was fast, and 3D graphics over the wire smooth, fast, performant.

It took a long time for the rest to get there and when they did, nobody really grokked it, unless they came from a solid implementation.

And nobody from the PC, Windows camp got it. Did not even understand what an app server even was.

No fault here either. People saw what they saw, worked how they could work. I get that.

But today, people still saw what they saw, work how they work and ripping all that up is painful enough to not make sense.

If it did, we would have seen this go differently.

So maybe this should not be a volunteer effort. Matters too much to way more of us than I also believe was expected.

If we fund something thwt does what X11 can do and that also will do the new, spiffy, lean things people want today, we would have a killer environment.

Having that be OSS?

Worth it to me.

Or, we can watch the carnage for another decade...

Good discussion, BTW.

People keep saying that Wayland needs to be more of an X replacement but it's never clear what that means. You want 3D graphics over the network, that currently means Vulkan, and if you were going to do that, there doesn't seem to be much reason to tie it to any particular window system.

In a general sense, Wayland is not Unix like, in the same way systemd isn't. X11 is, as were various init systems. And fact is, at the time those things were done, multi user computing was a thing, and it was all done with those ideas in mind too.

At the time, micros were on the rise, and apart from a few exceptions, were single user, and started out single tasking.

Two different roots of thought, now well grown into trees that share intermixed and intertwined branches.

I know that is an issue. Whether it needs to be addressed is an ongoing matter. A matter I am happy to discuss, but not currently one that impacts me too much right now.

My focus is pretty far away from a lot of that. Doing lower level stuff, and often with no OS, embedded. So, write it, include it, port it if need be, then compile and deploy it.

Minimum requirement is gcc, command line, terminal. In all other areas, Win 10 is fine. I really could give two shits what OS it is otherwise. Machines are all fast enough, big enough, etc... good times (for me) actually.

Again, not dismissive, just not a focus at the moment. That could change and I might care a lot too. This kind of thing happens to people. Sometimes often.

When I use X, I tend to make good use of the network capability. It is the primary reason to use it, along with ways, means, tools that have worked forever. I value stuff like that very highly because I much prefer learning and using new things to me, not always remapping stuff I know cold.

For example, in the past, I have enjoyed weaving a single desktop environment from a pile of machines and software. Did that to support, sysadmin, train and develop for advanced engineering software users of all types. I had the industry on my desktop and could run or do almost anything on a variety of platforms from that desktop and the time savings on that as well as my general potency 2as off the charts good. Beat a lot of other people who did not really grok X too.

Log in and just do stuff, and depending on what gets done, a few machines, or just one gets the job done, served up to me nicely, consistently.

For a long while after IRIX was done, I used a machine as my head end. Just worked great for that kind of work. Pretty much nothing was as good since, and apps have become far less flexible too. A pile of VM's are required for that kind of thing today and it is a lot more work.

But, it is also a lot more lean hardware wise too. That is significant right now, though I do not know how significant given how cheap stuff can be.

Anyway, back to the UNIX part. Small programs, smart data, pipes, all that stuff is UNIX. X11 allows all that to travel where it needs to and it is a very nice way to work.

If one wants, everything can be distributed too:

Fonts from one box, X Server from another, application on yet another, running on shared files from yet another, window manager on yet another, etc... An Indy used to serve up its nice window manager for my Linux for quite a while, just for shits and giggles.

And that is the UNIX way.

Sometimes it is powerful. I see people struggle with managed data, engineering software, etc. for example.

under X, I just made a beefy box, one copy of the app, one database on local disk, one backup system, and on IRIX that could be done live while people are working with just a few set and forget scripts too.

Then, serve 20 to 30 users. They do not have to know anything other than how to use the app. And they can't really break it either.

Admin on that thing was mostly cake and the users could run whatever they wanted as long as it had a respectable X server, they were good to go. Few of them would even notice or care, and it worked great over 100-T networks too. Kind of crazy to think about today.

The nice thing was those users could not touch the data except through the app. This saved so. Damn. Much. Pain. Worth the whole setup right there.

So that is one case. That case made me a ton of money too. Edit: That case still happens online, but alsonsuggers from being online. Outages, updates, fails on the part of the provider, data being leveraged in distasteful ways, sometimes expensive ways.

Done local, with X? Total control. It is nice.

Application servers. Loved them. And with super expensive 5 figure software? Making that available and performant to the people who need it without all the installation hassles is golden. Really do miss that.

All very UNIXEY.

Other cases include multi head machines. Beefy machine shared by two people. Was pretty easy with X. Not sure what the state of things is today. Probably not good. Probably not needed either. We got crazy amount of capable cheap hardware these days.

Basically, X is multi user graphical computing and all that can mean.

Current display systems are not.

We have moved quite far away from multi user systems, frankly. The basics exist and work, but we have no display systems that work in the same way. And very large numbers of people do not even know how they could work too.

Honestly, that is probably the core issue in play, boiled down!

"No reason to tie it to a window system"

Well, given a multi user graphical display system, "particular" kind of becomes moot. Run the window manager you want, etc...

In any case, here is what I think will happen:

X11 has always had this basic problem. People who did not use it, or who cut their computing teeth on single user dominant computing think very differently from those who did.

And it is not just about displays. The same thing is true for the command line too. Watching people come from DOS/Windows onto a proper multi user environment showed these differences in thought to be just as stark as those same differences remain stark today in the display context.

Most people know what multi tasking is and expect it. That is the dominant mode today.

Far fewer know what multi user computing is, and again I am speaking from the perspective of someone who took full advantage of multi user computing, and in the graphical as well as the general sense.

And that is the clash, in my view. A secondary one is breakage of a lot of little time tested, production proven ways and means of doing things.

Focus follows mouse + middle button paste is amazing when working across various windows that may overlap, or exist across multiple virtual desktops, for example. I can tell you, that is a super hard one to get away from. I did, and have, but it hurt.

There is a ton of this "noise" and given the state of discussion, appears to add right the fuck up. Still.

But I am rambling:

What will happen is we will either prove out the idea of multi user graphical computing is not useful, or we won't.

If not useful, all this stuff will eventually go away and we will bring up the next set of users on whatever that paradigm looks like in the end and that is that. The rest will be history.

Sort of like how we see mobile dominant users and desktop dominant users today. And that is far from settled. Mobile is nowhere close to displacing desktop. I use both hard too. No way.

But, if what gets made really is not so superior? Like those "precious use cases" really do hold significant value? Or, even if they could, but die off for a while?

Then we will do all this over again, reinventing X11 just like people tend to reinvent UNIX.

And look at the current trend to serve it all up via browser! Seems to me a lot of great 70's era ideas had real legs.

And this will happen because tech never, ever really dies. Someone, somewhere will see it and build on it to complete and it is game on. Or, they will think that way again because the line of thought has merit.

I plan on watching it all with great interest.

Personally, I believe in multi user graphical computing and have seen, applied, and profited nicely from the value it has. Everything should go over the wire, just like everything is a file. So I have something I want to run on my phone? Just ask for it on the display I am using and go. That's X11. I think that kind of thinking is compelling and I think that because I got to do that and it was sweet compared to the usual, find it, install it, configure it, move / copy data to it mess.

Cloud computing does that with a browser nicely. But, it also means a few people get to rule the world too.

Whatever one may think of that, if we were to build multi user graphical computing in from ground zero, I believe it will endure for a long time, just like UNIX itself has. And it will because the core ideas are strong, very generally useful, etc.

We have seen this kind of thing before too. Really great ideas tend to stick around.

And this is not about the people doing Weyland not having great ideas at all. They are trying hard to bring some new ideas into play, much like the X11 people did.

Cool!

It is more about trying to convince everyone that the great ideas behind X11; namely, multi user graphical computing, aren't great, or can be replaced with something that fundamentally is not multi user graphical computing.

Given all that, Weyland NOT replacing X11 may well have set different, and maybe less conflict laden expectations.

But that would also have begged the question: what value does multi user graphical computing have? We may be in a better place had it been asked and answered.

I think it has a lot. And I think, like UNIX, it is most important that it can all be done, not so much that everyone needs to, or will benefit from doing it, or being forced to do it.

We shall see!

I remember my early encounters driving me absolutely mad because I did cut my teeth on that 1 seat 1 user environment.I think where I've ended up going in a different way than most is that over the years I keep cracking away at it because I want to understand it. It's an intuition thing, and you never really appreciate the miracle of it until you sit down and come to terms with what X really did. It was the glue between app logic, state, and a constantly floating set of goalposts represented by every possible set of different hardware.

I haven't even torn into the source. It's taken me so long just to grok the other layers of the problem space. Personally, I think the space X11 occupied is one of the most enticing areas of research open to me, even if I never seem to make the time for it.

Abstraction-wise, we assume we carry context with us everywhere, but an X environment driven over a network breaks you of that quite handily, and I don't think the "Cloud"/SOA solves the real life dilemma jist by lifting everything into a browser.

Agreed.

At the least, risk will be higher than it needs to be, and that puts the other validation into question as well.

Often is right?

When does robustness end up a priority?

Could be a very long time, and or never, particularly given the core value proposition and or features intended to deliver it are not themselves validated by "the market" as you say.

One solution to this is to pay people to adopt the solution.

Another is to deliver features more specific to them.

Yet another is to cover it up, make recovery robust, transparent, etc...

These are all perfectly fine ways to approach beta type cases, initial userbase, seeding for growth.

After that process has shown what the market finds compelling, stability should be right there in the list with the core set of software to build on.

You can't omit stability in life-critical software for example.

On the other hand software's usefulness can outinfluence unstability, if there are no alternatives.

The point being made here is not that it always must be stable.

It is all about how often stability is not a priority when it could and or should be.

And in the no alternative scenario, it can be compelling to continue to ignore robustness to get growth and lock in.

When that happens, stability, robustness often stay in the back seat for a large fraction of the product life cycle.

For any given user, the impact may be just low enough to keep them on board too. New features, and asking more money for them, or offering them to make up for that impact can be an ugly cycle leading to users ripe for the picking later on.

Example: Steam cloud save. Countless time I have to force quit Steam's background service because Cyberpunk 2077 and GTA V freeze while saving.

Steam doesn't show the launch game button, even though the game is killed from task manager.

There are no heartbeat like mechanism to keep in check the game process state.

And there are no alternative to launch the game that I bought from steam, so the instability becomes little of nuisance.

But that's a minor issue where unstable features are unimportant ones.

> It is all about how often stability is not a priority when it could and or should be.

And I'm on your team too. That's why my argument is that stability IS A feature too. Countering grant parent's argument that says stability is ignorable as long as the features are validated by the market.

> And in the no alternative scenario, it can be compelling to continue to ignore robustness to get growth and lock in.

As a paranoid user I agree this has been a nightmare. I constantly have to make sure I wont get locked in to services that I pay for, and often time I find myself using open source solutions rather than paid one because of the same reason.

It absolutely is a feature.

Guess the externalities problem crops up in this context.

How to actualize those costs better so the equation makes more sense?

And yes! I hate lock in viscerally. Frankly, will avoid it at very considerable cost.

Which equation exactly? The balance between effort to stability and other stuffs? Sorry I'm a bit lost

There are competing paradigms now, and that is good, but they have not yet actually reached use value and productivity levels where it is appropriate to say the desktop paradigm is out of date.

At the worst, both will become more generally flexible to keep their value to the users.

Like you note, this isn't a problem unique to Linux/"free Unixy OSes". In some ways Linux is actually worse than others, consider Gnome/Gtk Updates for example. Or how things like having a library to read a particular image format are quite normal around here; except that library has like half a dozen incompatible but actively used versions and around 1000 released versions. The Linux environment is very volatile and everything constantly changes and breaks. Modern applications bitrot exceptionally fast in Linux, while the community points to "but look this Xchess binary from 1992 still works". That's neat but covers few real use cases. The same community is then bewildered that both people and enterprises opt for distributions which move at a glacial pace and only releases updated software once every five years or so.

Edit: glib not glibc

The GNU C standard library has binary backwards compatibility going back 20 years. They take great pains to preserve that. Are you thinking of glib instead of glibc? The former is from GNOME, and the latter is not.

glib 2.0 was released in March of 2002, and has preserved ABI compatibility since then.

https://developer.gnome.org/glib/stable/glib-changes.html

So not the Linux community then. Outside it.

Do all the new GitHub-driven programmers who exclusively use MacBooks and constantly rev things with the same frequency not exist? Why is this still being presented as a freedesktop-related problem and not a general problem with creators' fickle and fleeting attention, when we have evidence that the category isn't as narrow as the pigeonhole you're trying to put things in?

Sadly, that ship has passed... long ago. When you encounter a random person about "Linux", they will think of the Linux ecosystem, not just the kernel. In other words, your and GP's definition of "Linux" is different, and they are both correct depending on how would you read it.

(And before you go almighty on definitions, the majority of linguists agree to just monitor - or "describe" - the words as normally and plainly used.)

This seems to point to the general situation of change fatigue. If you pick up a random Android device, what does the "settings" app icon look like? Individually, these things are small, but the small impedances these changes introduce does take a toll on people, especially when you're trying to just get stuff done.

I don't think there's an easy answer here when the developer needs to make fundamental changes, though.

One of the problems is a parity disconnect. A developer/PM often has very different perspective from their users: They see the new changes as they're happening and so they're all small, incremental changes, plus they're closely following development.

A lot of users only infrequently update and/or infrequently use certain features, and so for them, all these small incremental features add up to be massive change for the sake of change. This will often manifest as "Every time I go to do x, it's totally different and I have to re-learn everything!".

I find a lot of software -- especially FOSS -- also communicates change poorly. Release notes are the primary way to get across changes, yet there are several bad things people do that make it basically impossible to read:

* List every change or commit message, especially without categorizing or simplifying the wording

* Don't properly highlight feature changes (eg with screenshots and/or reasoning)

* Have dozens of betas/pre-releases, but don't consolidate the release notes into a final "here's what's changed since the last main release" document

Some examples of exceptionally good release notes: Visual Studio Code [1], Jira [2], Gitlab [3] (though if they only provided their changelog [4] it would be a good example of being overly verbose to the point of unusable).

[1] https://code.visualstudio.com/updates/v1_52

[2] https://confluence.atlassian.com/jirasoftware/jira-software-...

[3] https://about.gitlab.com/releases/categories/releases/

[4] https://gitlab.com/gitlab-org/gitlab-foss/-/blob/master/CHAN...

But this is a real problem: it's not good that the Linux ecosystem has been reduced to "we shall eat whatever dogfood Redhat cooks for us". Wayland didn't even start as a RH project, iirc, and didn't really gain any traction for ages, but now it's a Big Deal because RH pushes it...?

That's how I see systemd and wayland. For systemd the consensus seems to be that's it's better than the previous init systems as most distributions have adopted it. It seems we're going in that direction with wayland but we'll see how it goes.

I think the parent comment was alluding to the fact that RedHat has the ability to manufacture consensus. All the distributions use systemd (and pulseaudio and ...) because GNOME and other core components were modified to work only with systemd. So everyone agreed to use RedHat's way because there was no other way. No matter how good RH's creations might be, that's the kind of tail-wagging-the-dog power that is bad for an ecosystem.

But the point remains that, even without any ill intent, the lack of competition and compromise can produce outcomes that look like malice -- people gradually get used to making decisions that go unquestioned, and unwittingly walk all over everyone who no longer has a voice in the discussion. This pushes more people out, and the cycle of the tail winning against the dog repeats and continues.

- Audio system that ignores all the foundations of ALSA and builds Yet Another Layer instead of improving ALSA.

- Display system that leaves way too much as an "exercise for the reader".

- 10+-year-long transition periods on the above, during which nobody's use cases work well.

- Decisions made by fiat rather than by consensus.

I'm not sure what you mean by consensus, if there was consensus on everything then we wouldn't have so many Linux and BSD distributions. We'd probably have just one or two, and you'd probably be more annoyed about "wagging the dog" if that was the case.

Just one point about ALSA; most of it actually lives in userspace. The ~/.asoundrc file can specify complex routing and mixing, including the use of LADSPA filters. What's done is done, and pulseaudio is reasonably usable now, but IMO we'd be much better off if the work that went into Pulseaudio and jackd instead went into the ALSA userland.

Nice try Google/Microsoft developer! I'm pretty technical, your sh*t change is still sh*t.

I remember a time when updates from gmail, outlook, or excel improved upon the previous version, sadly that was about 15/20 years ago for Google/Microsoft, respectively.

Details: Bluetooth headphones with microphones actually show up as 3 sound devices, one high quality output device and a pair of low quality input and output devices. Whenever a microphone is requested, the low quality pair is selected. Output quality goes to shit and any apps that don't get the memo will still send its audio to the high quality output device which has since become an inactive sinkhole. Since many apps request microphone access for non-obvious reasons, the symptoms are that you do something non-audio-related and sound in the rest of the system does some combination of {go to shit, stop working} on a per-app basis. The solution is to disable the low quality input and output devices, which keeps sound output functional and high-quality until Windows Update reverts your settings and sets the stage for the next microphone access to break bluetooth audio again. Ugh.

Interesting. I have what appears to be exactly the same bluetooth headset setup (Bose QuietComfort 35s), and use it all day every day while at work.

I have the slightly annoying thing that if I'm in a video conference all normal audio isn't heard (unless I switch the default audio output), but I only get that when actively in a VC. I have never had 'random applications requesting the microphone'.

See for example the pages of complaints about windows forced planned reboot features deemed unavoidable from the hn majority, let alone the common users.

Any one of {Bluetooth SIG, device manufacturer, Microsoft} could have independently fixed the issue. Every one of them should have forseen it. None of them foresaw it and none of them fixed it, and years later it still lingers. Yikes.

I see your comment's flagged, maybe because of the harsh language but other than that it all rings true to me.

This. I think it's incredibly inconsiderate to do that to a user who never asked for it.

As a user, I abhor this mentality, and respond to it by leaving. And if I have to stay, I boycott the nag dialogs and just leave them open, to embarrass the developer in front of anyone who may be watching my screencast.

As a programmer, I go out of my way to ensure that my software works the way the user wants, and an upgrade is never demanded.

I design for back and forth compatibility, so that I can go back and forward to any version I desire, as long as there's a commit for it.

It may not work perfectly going back a year, but if it's a stable version, it should run.

In this case it's people maintaining software that I don't use telling me I'm problematic for not switching to their stack, away from existing software that works perfectly fine and is also actively maintained by people who don't call me a flat-earther. Easy choice.

All the successful projects Linux users like to talk about nowadays (gaming now a practical thing, new kernel features, Wine getting really good) were all bankrolled by massive billion dollar corps like Valve and Google, because the community itself has no discipline to see things through.

At least GNU of the old days was organised enough to know not to break people's workflows - just look at how stable coreutils have been - but GUI software for regular people somehow doesn't deserve to get the same treatment.

"Linux"? We're discussing a category that includes Gmail UI changes. Is Gmail not popular?

Maybe discipline is a problem, but time, money and access to information is too.

On the Subaru, they are clutch controls. The result was downshifting into 1st gear going 70mph/100kmh+.

I don't think I can tell you immediately whether my laptop is running under Wayland or X (I only can because Wayland and FontForge haven't been talking for some time). Does it annoy me? Yes. Does it annoy me to the point of anger? I'm an adult. I have other things going on in my life besides graphical back-ends.

This is not how average people are AT ALL. Let someone use one of the above and give them something new and watch them be frustrated for at least the first entire day of usage with continuing friction happening for the next week-month every time they find a new task that they don't do that frequently but thought they knew how to do.

Asking the manufacturer would open the flood gates about how ungrateful you are about all the years put into designing the thing, and how other options were "confusing" to drivers, although said drivers should clearly be of some extraterrestrial species with a different set of sensory organs and appendages.

Imagine a screwdriver that would randomly switch to requiring a hammering motion instead of rotary motion, then the next day it only works if you hold it just right, then the day after that it freezes itself to the table to download updates and the update changes the shape of the tool bit so it won't even turn the screw you are now two days late on tightening. People would riot.

Probably not your point, but I absolutely do blame maintainers of proprietary software for changing my routine. Webapps, free software, and whatnot I can understand (even if I don't necessarily like it), but if I pay in full for a lifetime license to a specific version of software then I fully expect, at a minimum, for that software to not have auto-updating backdoors for any reason (looking at you Garmin/Navionics).

most software changes are unnecessary and are forced on users unnecessarily, and that,s why people hate software.

IMO that depends if the software is paid for or not. If I regularly pay for a software I can have demands.

Recent issues:

* The brightness control for my screen doesn't work with it.

* The mouse sometimes lags

* Graphical corruption in Chromium when on webgl sites.

* Blank screen after resume from hibernate.

* Seems to randomly freeze forever sometimes after an OOM killer run.

* Chromecast wouldn't work

What most people mean when they "switch to Wayland" is that they're switching from Gnome on X11 to a "pure Gnome" stack that uses Wayland and a bunch of other Freedesktop standards for interopability. There is absolutely no code from the "Wayland project" running there, because the Wayland implementation is Gnome's own (it's called Mutter). Similarly, KDE's implementation is in KWin itself. The source article is from an author of yet another window manager (Sway) implementing Wayland.

What you're observing is not "Wayland not being there yet", it's Gnome not being there yet. All of these deficiencies have nothing to do with Wayland itself: they're general QA issues that plague an underfunded Linux desktop that's making a slow technology transition.

Wayland is bad design, and it shows in the users' and maintainers' attrition.

This is not something conceptual about Wayland, or intrinsic to it. Any display protocol can have multiple client/server implementations. It just so happens that most of the free desktop standardized around the X.org implementation for X11, but even for X11 there were multiple client and server implementations.

The second thing is that software duplication efforts have a well known, tried and tested solution: implement the duplicated effort in shared implementations or libraries [1] !

The thing I find hard to wrap my head around is that this complaint is given in a community that usually champions protocol-over-implementations and diversity of implementations. The people actually making a difference on the Linux desktop are damned if they do and they're damned if they don't.

[1]: https://github.com/swaywm/wlroots

What you want at that point is to agree where to read and write common configuration. I'm not sure this is likely to happen either, as gnome has gsettings/dconf and kde has simple files and you will now awaken the plaintext vs efficiency dragon.

The current situation is just how it coincidentally turned out - there's just not always a clear direction on the free desktop (and that's even what many people like about it). If wlroots or something similar had existed earlier, then this probably would have turned out differently but c'est la vie.

edit: looks like it might already be provided via wl_output::scale [1] except you get the wrong effect that way. You want to tell the client what DPI they should render at, so that you can keep scaling at = 1

[1]: https://wayland.freedesktop.org/docs/html/apa.html#protocol-...

Once that ship has sailed, what you want instead is a shared method of providing configuration. The goal is to have all 3 implementations read configuration (like DPI scaling etc) from one place. That way the user won't have to configure common things in 3 places to get any semblance of apps looking remotely close to eachother.

When people talk about "pushing stuff to the DE" what they mean is the Wayland project aggressively scoping the Wayland protocol to drawing surfaces and handling input events. They're not trying to become a generic desktop message bus for everything an application might want to do -- that's literally what dbus is.

Why not have a shared implementation?

The codebase could be re-engineered, sure, but a lot of people championing Wayland tend to see this duplication of effort as good for some reason, and at least last I engaged with them did not like the idea of a "new X11."

Personally I think something like that is an inevitability.

People seem to like that we have many browser implementations but when it comes to display servers it seems like they want Chrome to rule them all.

Diversity is great but equality in failure is not helpful.

X11 is a protocol. What you mean is that we end up with something like Xorg, an implementation of X11. Which is still incorrect because a major design goal of Wayland is to move as much logic as possible from the server to the client.

I wonder how long it'll take to have a Wayland server running on the AT&T Blit...

It'd still solve a lot of issues that X can't.

Wayland is trying to do one thing well, whereas Xorg did many things poorly. It's valid to feel frustration that the community doesn't coordinate to put those APIs in place, but it's very much not valid to blame Wayland developers for it.

Please be a little bit more charitable: I'm very candid about the usability problems on the Linux desktop, I'm just telling people where they need to send their time, money and concerns to fix it.

> "but that's not our problem!" when something breaks.

Which is the entire point of getting rid of X11. Wayland is a display protocol and does not intend to solve all of the problems that X11 ended up solving, same as the display stack in any OS designed after 1990 (like Windows, Mac OS X, BeOS, Android and ChromeOS) do not solve these problems either.

For a modern example of this in action, see Bluetooth and the madhouse of device 'quirks' you have to settle with day-to-day, since each device has subtly protocol-breaking opinions on how to implement it.

Wayland is a display protocol. Practically all of the pain people are experiencing has nothing to do with how Gnome/KDE/Sway really display things differently. The pain everybody experiences is that the realization that suddenly we need a new input stack too, a new way to screenshare, a new way to do clipboard access, a new way to do a bunch of other things. All stuff that also needs to made, standardized, and achieve maturity outside of the new display protocol.

It's tempting to call that fallout of other stuff that needs to be changed "Wayland" as well, but I'd say that misses the point completely and calling it that won't help anyone get this stuff fixed.

Mind that I have no formed opinion of Wayland myself, having not used it. Trying to deduce probable causes from hearing people duke it out here and elsewhere.

On Linux, there's X11 based desktops and "post-X11" desktops. "Post-X11" would involve implementations of Wayland and Freedesktop Portals [1], using libinput [2] - and some other things I'm forgetting. All these things don't depend on Wayland and run fine on X11 too (heck you can even run a Wayland compositor in an X11 window), but most of this stuff is pretty new, implementations have lots of QA issues, and application adoption is also not fantastic. On X11 you can just talk to the X11 socket directly for what you want as a workaround, but on post-X11 you have to adopt a new means of doing it. And that hurts.

[1]: https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...

[2]: https://www.freedesktop.org/wiki/Software/libinput/

But my requirements are different from yours.

If you've been shooting yourself in the foot all your life, eventually you'll stop noticing that your foot is bleeding.

It would have to rely on compositor and driver bugs in those other platforms.

If no implementation of Wayland is ‘there’, it seems pretty reasonable to say Wayland is not there yet.

I think it can be seen in OP's list that most of the issues that OP raised are actually not due to deficiencies in the display protocol. Specifically replacing of the X11 display protocol with the Wayland display protocol. But Wayland solves fewer problems than X11. So to replace things like standardized screen recording and input processing, you need other things on top of Wayland.

And that's where by far the most issues with "Wayland" come from - stuff that has nothing to do with the display protocol, but the tremendous pains it takes to replace X11.

[1]: It's worth pointing out for fairness that X11 based desktops are also pretty flawed even if you're used to some of the flaws.

Given this, it’s not surprising Wayland has become the name associated with the overall goal.

While technically true, that is a bit of deflection. In some cases none of the compositors have implemented certain things yet.

My biggest issue with gnome is that it doesnt remember where my windows were last time I ran an app. Someone over in way-land probably should have told them that would become a their-problem so it could be addressed it sooner. Same with window decorations, they should be handled by the compositor IMHO. Sometimes a new thing should come with recommendations for use.

Deflection is entirely my point here :) These things are real problems, but they should be fixed in Gnome/KDE/Sway/wherever you find them. Complaints should be addressed there, and not at "Wayland", because "Wayland" can't fix em!

There's a meta-lesson useful here for anyone who doesn't know it yet: modern software has network effects. And the same phenomena you see with other networks apply to software stacks. If everyone else has implemented a protocol wrong, for example, and your software comes along that has implemented the protocol correctly, but as a result your software doesn't work with the existing stack,

a) Odds are, the rest of the world will not change to work with your software

b) New users, using your software, will perceive the problem is your software doesn't work, not that the rest of the stack is wrong and you're the only one that did it right.

Maddening, but it's the nature of complicated systems built by thousands of people in a distributed fashion.

(I can't lay hands on the link right now, but there was an ex-Microsoft engineer who had a blog where he talked about the heroics MS developers would go to every major Windows release making sure their OS was compatible with popular user software. It didn't matter that they were the company setting the rules in their ecosystem... If the latest version of Windows broke Photoshop, they had to figure out why. In that particular instance, it was because Photoshop had gained some performance optimizations by baking binary images of default structs the OS gave it into their code instead of calling the right API to get a struct properly initialized, saving a library call. MS had to reimplement some C++ structures in C so they could maintain the memory image of the relevant structs to avoid breaking Photoshop).

Wayland here ends up often being the scapegoat of a Linux community that looks to want to change but can't sort itself out. The result of blaming these issues on Wayland instead of - mostly - Gnome and KDE means that we're not going to the right places to have this fixed. In terms of bug reports, and contributions of code and money.

[1]: I mean, if you can come to terms with the substantial architectural differences implied by Wayland w.r.t. to X11. But that's a discussion on another level.

People, especially people trying to work done on their computers, usually mean the former.

It still smells, because I cannot load my own web components library or/and my own CSS for use on all sites, so every site MUST reinvent wheel.

When Firefox for Linux used native GTK+ UI elements in web pages, with user theme applied, every web page looked like native applications. It was excellent. Then this feature was cut, because "every page must have the same look on every device/OS combination". F><k. Now every web application tries to reimplement the look of Gnome 2.x, and does it poorly.

Unknowing users can freely associate Wayland with bad vibes due to how KDE and GNOME chose to brand their new compositors but we can do better.

But if Kwin & Mutter aren't quite shit when it was combined with X, but are shit when combined with Wayland, how does that shape perceptions of Wayland?

In an alternative universe there would be Kwin the X11 display server which would replace Xorg. I’m sure it would just be as big riddled and feature incomplete in the early years of its development.

Wayland is the implementation detail in Sway to have a display protocol your Gtk, Qt and XWayland apps use to draw themselves, really no need to draw more attention to it than necessary. It's the Sway implementation that does all the magic.

asshole.

Overall, my Linux GUI experience has never been as smooth as it is now on Wayland and I tried pretty much all common DEs/WMs in last 8 years.

X11 is not even remotely close to being "there" compared to Wayland and if Gnome implementation sucks, then please first try better implementations first before writing comments like this.

No, Wayland protocol is not perfect and yes, some niche use cases are still not covered, which is why various extensions of the protocol are still being developed. X11 at it's current state is nothing but a collection of hacks glued together. Wayland is, however, a very robust, secure and well-designed modern protocol, which, most importantly and contrary to X11, actually works.

  * The brightness control for my screen doesn't work with it.

  * The mouse sometimes lags

  * Graphical corruption in Chromium when on webgl sites.

  * Blank screen after resume from hibernate.

The last two aren't applicable, since if anything has been OOM killed recently I didn't notice, and I don't have a Chromecast.

Can’t speak to Chromium or Wayland, but Chrome on Mac has this problem for me and I just had to completely disable hardware acceleration.

I don't care how much better Wayland is...if it can't do something I'm used to and need, it's going in the trash. I don't have time or interest to read mailing lists and bug trackers to know when it's fixed.

Complain to Slack.

Wayland said screen sharing is something to be solved outside of Wayland itself. That solution is still early and not complete. It's not anybody's problem, it's just how things are. It'll get fixed eventually, in the meantime X11 still runs fine for most users and in 6-12 months switching to Wayland should have fewer tradeoffs. Until then Wayland is missing some use cases X11 easy fulfills. Unfortunately X11 is also missing many use cases Wayland fills. As a result we should expect different users to be better served by different answers about how ready a Wayland environment is for them and both to be equally correct.

Screengrabbing during the last year was even better than what X11 could provide, including the ability for the user to limit the grabbing to display or window. That's something that user cannot have under control in X11.

Pipewire is also not limited to Wayland; it will work with X11 too, so the X11 users won't be abandoned just because there's Wayland support too. Firefox doesn't seem to have problem with it, Chrome has it behind flags. For apps with fast moving releases as these, I don't see any problem with them supporting 0.3 release and when/if there is API breaks, updating it.

Beats not supporting screen sharing under Wayland at all.

I.e. it's not that the tech stack or architecure is the wrong it's simply not done yet and not done to the point it's a bit silly to blame Slack for not enabling it.

It's also not the fault of wayland/pipewire/chromium/electron/slack for not all simultaneously releasing working screen sharing but it is a mistake to say you can switch from X11 to <Wayland stack> and not worry about screen sharing.

I use pipewire for screen sharing, I like it, but its not a fully baked stack and won't be for some time yet.

Are you sure? I'm pretty sure I had two tabs, one for picking displays and other for picking windows. Pretty much like this: https://bug1675764.bmoattachments.org/attachment.cgi?id=9186...

"Will this let me share individual windows?

No, only entire outputs. It would take significant work in wlroots, and likely a new protocol, to make this possible. A second rendering pass would be required, which would significantly reduce wlroots performance, so this may not be implemented any time soon (or ever).

Will this let me share all of my outputs/displays at once?

Not yet, no. It will likely never create a single stream that combines all of your outputs, but once we implement better output selection, there is no reason xdpw cannot create multiple simultaneous streams of different outputs."

So it looks like I'm shit out of luck for quite a while on sway/wlroots. Looks like Gnome figured it out. Not sure about KDE.

https://github.com/emersion/xdg-desktop-portal-wlr/issues/12

https://github.com/swaywm/wlr-protocols/issues/93

Thanks for the constructive and informative discussion.

Apple for example regularly uses pressure from users on app authors to drive improvements in their platform. I don't see why Linux distributions should flip backward to keep their platform static, to the detriment of their long term development.

Editing since I can't reply - I didn't mean to come across as rude, sorry for that. Just explaining that as a user, it doesn't work out of the box. Having to explain to users to do the above is not an ideal solution.

Something similar used to frustrate me no end when asking the Python community for help trying to solve a problem.

Regularly someone would comment, "Why would you want to do that?".

I wouldn't be asking if I didn't have a need to do it!

It's bizarre that some people can't see beyond the end of their own nose and imagine different use cases to their own.

Unfortunately in my experience it is often followed by an explanation of why what I'm trying to do isn't what I should want to do, as though I am not aware of my own goals and constraints.

Sure, some people are assholes, but that's just people. Nobody's in your mind, they can't guess your requirements, thought process and level of experience. In my experience, more often than not, asking the question "why would you want to do that?" gets you a bad reason. "I did X this way because Y. I need Z." would filter the legitimate questioning out. From there, the others are just assholes, and those are everywhere.

As for the small differences in semantics, I'm not a native speaker, neither have outright negative connotations to me, but I feel like getting tripped up on such a small thing - and simultaneously assuming the interlocutor's intentions - is kind of overblown.

"Do", in the present tense, does not carry those connotations. It implies "I have acknowledged that your want is present and real, but I need more information about your context to be able to help."

Sure, but if I told a plumber they'd understand and help me find a solution to my problem. That isn't what happens on StackOverflow, instead they try to convince you that you have to change your problem to fit the solutions they're familiar with.

There's a lot of people out there who are happy to tell you that you have an XY problem, but when you explain why it is not, ... crickets.

https://en.wikipedia.org/wiki/XY_problem

But yeah - the 'XY problem!' crowd (along with the 'But The Rules!' crowd) has also totally destroyed Stack Overflow.

While we can all agree X is a pile of something, I am in the camp that remains unconvinced by Wayland. It does not work on my hardware, it does not solve problems I have. OK, no more screen tearing, which is nice.

Wayland have to understand that if they want to replace X, they'll have to replace X.

It seems impossible that it will be ready for use before it is hopelessly obsolete (e.g. Windows and MacOS will be beaming images straight into your brain or something.)

Wayland is (fortunately) coming, but changing a whole ecosystem is not a small feat (even with the great backward compatibility with XWayland, because unmaintained apps will never port)

I am not sure what you mean here. Weston, the original implementation, includes support for screenshots, screensharing and RDP. Other implementations decided to implement those in a different way, for various reasons. The way to not "punt" this would be to use libweston but that has its own set of issues, and it seems strange to blame the Weston hackers for not upstreaming every single other thing that some implementer is working on.

I'm not fully up to date on the state of these things, but if the different implementations doesn't have a common interface it's goodbye to ever having screensharing work for everyone. I think that's what the parent means.

If we're lucky Discord/Zoom/etc. will implement it for the most popular compositor(s).

Similarly with screenshots - even though it's a much simpler problem it's annoying if the program taking the screenshot is fundamentally bound to a specific compositor.

If I'm not mistaken there are standardization efforts underway today though?

No, not really. In practice what happens is Discord/Zoom/etc do implement it for the most popular compositors and then the other compositors follow suit if they want to support those applications. You would be complaining even more if they only supported weston because their screencast mechanism is pretty limited, and it would suck if the other ones just copied that.

The current "standard" is to just use pipewire and have the display server talk to the pipewire server, most commonly using xdg-desktop-portal. This is obviously outside the scope of Wayland, because any application can talk to pipewire and share/receive a video stream. I don't know about Zoom, but Chromium has support for this in the works, so Discord should get that eventually from updating their Electron: https://github.com/electron/electron/pull/26022

It's not just about replicating this functionality. It's about having an open framework that makes building these tools, and other unforeseen tools, easy. X11 was very accommodating of this.

For example, I like to run xsnow during the holidays. Wayland's answer to xsnow is -- we don't support that, but tell you what, draw up an RFC for a D-Bus API for desktop snow and wait 5-7 years for compositor implementors to consider incorporating it. Or something completely different. You know, whatever. It's like you have to prove your use case is valid to the community before you can even start hacking on it in a way that you can expect it to work with more than one DE.

For Wayland the attitude is "Fuck you. You get a buffer for a desktop window and that's it. [Wayland does not support nested windows.] Oh, that's not enough? You're not writing a desktop app? You want snow on the desktop/a desktop magnifier/a hall of mirrors effect toy/an anime window sitter/pinnable menus/something that responds to global hotkeys/etc.? I'm sorry, did we not anticipate your pwecious widdle use case? Fuck you. No one actually writes applications that way any more, nerd. Go back to the nerd table. We're trying to get the cool popular Mac-using kids to notice us here."

The X11 security issues are mitigatable with some changes to the server implementation. The Wayland approach really never was about security. It's about letting the cool kids define the shape of the Linux desktop to the exclusion of ordinary users/hackers.

FYI there is some prior art for poking a security hole in the Wayland server to support X11 features, but obviously not all implementations will want to support this: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/b...

This is inimical to the design principles of Wayland, whose security policy is to isolate all clients -- no exceptions, no escape.

The 1984 Mac was largely a novelty, but it was one that demonstrated possibilities. There are non-novelty applications that are precluded by Wayland. Something like EXWM could not be done. You cannot write a standalone virtual-desktop switcher, it must be integrated into the compositor. Et weary cetera. Wayland is very opinionated about the kinds of programs you can write for it, and if you want to go beyond that you must traverse the step function into "write your own compositor".

agree 1000% - really don't care about X per se, but remote windowing is an awesome and unique feature, and disrespecting it by treating it like some obscure/uneeded thing and qustioning why people are mad about it conveys alot about the attitude that i don't want to get behind

If the Wayland design was weighed down by such things, it could never hope to be progress.

X-Windows is itself a weak response to remote access. I have memories of trying to use Oracle Forms over a modem connection to uni, and finding it far inferior to VNC connections to work systems - effectively unusable.

The remote-windowing mechanisms of X-Windows are coupled to aspects of X-Windows that Wayland was created to overcome. The video 'The Real Story Behind Wayland and X - Daniel Stone' discusses this.

Microsoft Windows does not do remote-windowing in the X-Windows sense. RDP is not Explorer. From what I read, a RDP-like-thing could be built, and Wayland would not get in the way of this. I think the Wayland team make a clear case for why this is out-of-scope for them.

don't throw the baby out with the bathwater, in other words

But actually "remote windowing/apps" is even better supported, it's a universal proxy: https://gitlab.freedesktop.org/mstoeckl/waypipe Absolutely does not require any support from the core protocol.

Yesterday I made a casual observation about something quite obvious, and more importantly, completely irrelevant. And without fail, the only response was that it was because of x and y. It isn't.

On facebook, the only way I ever get an answer is to use Cunningham's Law. And I even usually use the words "cunninghams law" in the comments. But it always seems to get me my answer.

It would match the ratio between good software and self promoted junk.

----

I think Ubuntu is good gauge for the real state of Wayland. They would like to switch to Wayland as soon as possible but even in the 21.04 Ubuntu still defaults to Xorg on Nvidia based systems.

He’s not asking anyone to like it; in fact, an informed dislike would be much better than the reaction many people have to Wayland.

A lot of the response the Wayland maintainership receives is instead a reflex-response of uninformed people repeating out-of-date FUD they heard somewhere, without ever having actually looked into the issue themselves. Which is something you just don’t do if you think of the people on the receiving end of it as real human beings.

(That kind of scarlet-lettering does have a place! It’s a perfect tactic to allow newer community members to assist in suppressing a widespread “old evil” which the community long ago chose to excommunicate, for complex reasons that the newer community-members haven’t been around long-enough to absorb. It’s the reason people belittle/make jokes about Multi-Level Marketing schemes, pseudoscience, etc. — or in the FOSS sphere specifically, about bought-out projects like AdBlock Plus. The people who reflexively just laugh at newbs for using $thing, are acting as part of an “insulation layer” of people defending a community from a threat at the margins without really understanding the threat themselves; and they’re acting at the behest/connivance of people closer to the core of the community who do understand the threat.)

But Wayland was never excommunicated from FOSS. There is no old threat; only old arguments. The core people working on Wayland are in fact the same people who work on X. The other core people, those working at the distros who package these components, were never against Wayland; just wary at first, because they didn’t want degraded functionality. (And even then, they’ve always been shipping it on distro spins for e.g. mobile, where using X11 has never worked.)

> They just punted and said "that's a compositor problem!" as though that was supposed to make it ok. People have thus harbored some inherent resentment ever since.

It’s not punting when the same maintainers also write the compositor. (Yes, they do!) They’re effectively doing the same thing StackOverflow does when it tells you “this is best handled on [other StackExchange site X]”: not trying to make you Somebody Else’s Problem, but rather telling you to go to the counter two paces to your left, where they’ll trundle over wearing a different hat, and then help you solve your problem there.

The whole project of Wayland was to take a monolith with mixed responsibilities (Xorg) and refactor it so that the responsibilities were each handled in the correct places, by teams who best understood that layer of the stack. As such, “Wayland” as a project staff covers all the resulting components—they’re all outgrowths of one project. But all those resulting components are all also their own codebases, with their own growing maintainerships, with their own negotiated APIs, so that they can grow separately, be swapped out for competitor projects, etc.

But criticizing Wayland on a pure comparison basis, clinging on to Xorg server – absolutely doesn't benefit anyone, including whoever is posting it.

X window system (the idea) and Xorg server (the project) – is kind of abandonware [1] at this point. The last release was in 2018.

Don't want to get into random philosophy about contributing vs complaining vs criticizing, etc.

But in this situation – there's just a definitive community health benefit in moving on. Not complaining, not contributing, but just moving on. There is no further value left to be added in any comparison.

1: https://www.phoronix.com/scan.php?page=news_item&px=XServer-...

It does give you a garbage stack that solves problems though.

Remote desktop is a harder problem to be sure, but it is also a pretty common use case (window remoting less so). If you're setting out to modernize and replace such a fundamental component of Linux Desktop then you should probably have a plan for that. If not in the first spec, at least a statement to the effect that it will be part of a future spec instead of just punting to "implementation defined".

An unsecured screenshot escape hatch can be used by malicious software to scrape information shown in windows on your system, and with modern OCR being what it is (or, hell, a shady Mechanical Turk transcription job), that could be an attack vector for surfacing people's private information.

The other reason is that this isn't base functionality, for example an embedded implementation has no need for screenshots.

I'm unsure what kind of graphical environment you can imagine where screenshots are not useful at all (if only to capture the screen when something weird is going on).

For debugging purposes, the display server can just dump the screen to a file or a serial port itself. The only reason you would need this in the protocol is so other arbitrary applications could capture the screen.

Also, screen sharing is not that easy of a problem if done properly (eg. allowing another app to act on the buffer and directing it here and there)

>That does not mean anyone is under an obligation to like it.

Doesn't seem that was the point of that statement. Rather, it's asserting that it's invalid to claim that the very people who built the thing in the first place are a "vague authority".

How true the accusation it, I dunno, but that's my read of the sentence - not that the volunteer devs are somehow entitled to endearment by virtue of their volunteering. :-)

Why do you feel the need to announce this to anyone, particularly the people who work on it for free and owe you nothing? Is that not his point?

Is it just basically a backdoor going through the hardware?

Is there some way that a compositor works with Linux security so that you need a special privilege or root or something in order to record the screen?

Then why not include an example compositor that solves these issues?

Eventually that use-case in Xorg/X11 will cease to function when it becomes obsolete and unmaintained, but I agree how bad the outright dismissal of someone's use-case can be perceived. There has to be a civil discussion on both ends.

You can still use Xorg on most distros. In Ubuntu it's one checkmark.