> In the case of Wayland, the “vague authority” are a bunch of volunteers who have devoted tens of thousands of hours of their free time towards making free shit for you.
That does not mean anyone is under an obligation to like it.
> Maybe Wayland doesn’t work for your precious use-case. More likely, it does work, and you swallowed some propaganda based on an assumption which might have been correct 7 years ago.
If you insist on disregarding people's use cases, don't be surprised they don't like your software. I've been down this road a lot with FOSS software: "I don't use it because it doesn't do what I need", "sure it does!", "no, it really doesn't", "well you don't need that anyway!"...
On the whole however, I can certainly understand the frustration at having to deal with a community that gets annoyed at anything that changes simply because they're already so used to the garbage pile they have that they now hold the delusion that it's actually not garbage.
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!" as though that was supposed to make it ok. People have thus harbored some inherent resentment ever since.
> I've been down this road a lot with FOSS software: "I don't use it because it doesn't do what I need", "sure it does!", "no, it really doesn't", "well you don't need that anyway!"...
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.
In my experience Gnome is the worst major FOSS project for this. Ever since Gnome 3 the design philosophy of all of their projects seems to be "find out what the users want and do the opposite."
I have no idea why it has become so common on here to dog on GNOME for being "user-hostile" because they targeted a different kind of user than the average HN engineer/startup person. You can use one of the "GNOME 2 revival" type desktop environments if that's your fancy.
They produce bad software with a bad interface based on a bad theory of how people use things and when people critique their bad software they give bad reasons, argued badly, with a bad attitude and in bad faith to boot.
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.
That's their justification, but put a non-technical user in front of a gnome system and you will find nothing but confusion. It doesn't operate like any other OS GUI, nor is it intuitive or discoverable, nor does it have feature parity. They must be designing gnome for someone, but I don't know who.
I don't know, last time I tried stock Ubuntu I found it to be pretty similar to current macOS with the launchpad and mission control. In any case, the answer to those problems you're describing would be more and more breaking changes, not less.
Because the user they were hostile to were the users that had been until then the majority of Gnome's users. It may be a good business move to ditch your existing userbase in favour of a potential larger one but the userbase you've moved on from have no obligation to be happy about that
I don't expect the community to be happy, I would say I more expect a community of engineers to be realistic. The ship has unfortunately sailed long ago and it's not coming back.
> because they targeted a different kind of user than the average HN engineer/startup person.
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 remember following the GNOME blog for some time and finally decided I'd never go back after the article on how gEdit was being "improved" by completely hiding the menubar, the toolbar and basically any usable controls. It was written such that "focus" and "distraction-free" computing was the ultimate goal and that UI controls were somehow "distracting".... The file open/save dialog involves multiple clicks before it is usable because obviously a path edit box is WAY too distracting...
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.
What is a "power user?" Sounds like the same nonsense we hear from proprietary software vendors all the time, "That feature is for enterprise users."
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."
For example, GNOME doesn't support session save out of box. I think it's an incredibly helpful feature, especially for beginners - but maybe GNOME developers simply know that, deep down, all of us yearn for a clean blank slate whenever we restart our box, and showing the apps we've been using five minutes ago will only confuse our brain.
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!
It gives them dictatorial power because it's their project.
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.
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.
Yes, obviously there's no way to tell what proportion of users think the same way.
> 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.
> I don't understand how that gives you dictatorial power over 100s of users who don't like the changes you've made.
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.
Hot take: Maybe, if you're building something (or especially changing something) as a SME that many people use, and you fuck it up in a way most people don't like, you're still a jerk.
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.
Hot take: As a software engineer, or absolutely anything else, don't owe these people anything. I'm building software in the direction that I want to bring it. If they're unhappy, they're free to leave. But to have them come on public forums and call you a jerk, that's just comical.
Imagine if you asked what makes Steven Spielberg dictatorial power over all our screens! Not even paying him money gives you a veto on his casting choices. What you are experiencing is the expectation of continuing to receive a benefit, useful software, interpreting no longer receiving the same quality software as a loss, and intuiting that you have a rights to avoid that loss. You don't because the benefit was unearned in the first place.
This doesn't mean you don't have a right to discuss or critique and discuss and if appropriately fork or write you own.
> I don't understand how that gives you dictatorial power over 100s of users who don't like the changes you've made.
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.
"The option always remains to change it yourself or stop using it."
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.
All I see here is that you're not going to get everything that you want. No-one is. We are all using software that's imperfectly adapted to our personal use cases. Unfortunately, unless we're paying, no-one is under any obligation to change it for us, and we'll have to make do as best we can.
The funny thing is that a lot of users switch to open source software because the proprietary software they had been paying for was not supporting their obscure use case. You know, it is not something worth the investment because only a handful of users care or it works against the interests of some business partner or whatever.
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 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.
Nothing wrong with that attitude if you don't mind large numbers of users, many of whom are very technically competent and able to make meaningful contributions, giving up on the open source ecosystem. Most users do not have time to figure out how to stop using systemd when that is what their distro uses, let alone how to do so while staying on top of updates for whatever they are using instead. Most users who stop using systemd are going to switch to OS X or Windows, and they will contribute less, maybe not at all, to open source projects. The result will be an open source ecosystem that is less able to keep pace with proprietary software and has an even harder time staying relevant.
> 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.
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.
They can; but they shouldn't expect a life free of complaints.
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.
>but they shouldn't expect a life free of complaints.
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.
> 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.
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.)
I think we’re talking largely at cross purposes. It might be a good idea for maintainers of open source projects to listen to all feedback. However, nothing obliges them to do so, and you’re not entitled to be angry with them if they don’t.
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.
Giving a project feedback does not impose any obligation on the maintainers of that project to help you – even if they find the feedback useful. In general, it's rude (and ineffective) to try to unilaterally impose non-trivial obligations on people without getting their prior agreement.
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.)
"I wonder how many of the people who complain about Wayland have made sizeable contributions?"
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.
>> 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.
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.
>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.
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 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.
If the users aren't willing to fork, then having them run away to osx (where, by the way, everything is also imposed on you) doesn't seem that great of a loss.
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.
You are right that with OS X you have no particular say over the features. On the other hand, you do not have to deal with poorly supported hardware, and if something goes wrong there are people whose job is to help you. Most users find those things to be advantages, but many will choose open source software because of the various other freedoms they can get. There are also people who choose open source software because they have unusual requirements that proprietary systems either cannot meet or are too difficult/expensive/onerous to deal with.
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 where this thinking comes from but I still think it's kind of a simplistic attitude. People depend on the technology they use. When you convince someone to rely on something you've produced (and, crucially, continue working on), I think you do actually create a duty to be responsive to them. They depend on your work. Are we really so limited in our ethical thinking that we require an exchange of money to create obligation?
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.
You somehow think that someone who’s done you a favor (by providing you with useful software for free) owes you more than someone who’s done nothing for you at all. That’s exactly backwards. You are obliged to them!
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.
If you read the fine print there is, quite literally, no obligation at all. From the MIT license:
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.
You will find that most other FOSS licenses contain a similar clause.
That's a legal disclaimer designed to head off a specific commercial legal liability. If you go looking to use law as a foundation for right and wrong, you're going to be sorely disappointed.
What I quoted isn't a law, this is something that authors have to deliberately put in their licenses/contracts for the specific work in question. If you wish to have other obligations with your open source software that you believe are less wrong, it would be wise to get those in writing.
It's not clear what else it is that you'd want. The MIT license seems to get used because it's short and to the point in stating priorities: Here's the software, do what you want with it, but don't take credit and don't come after us if it doesn't work for your use case or if it causes your CPU to explode. If your issue is with the "legalese," it wouldn't be any less meaningful if you stated it differently.
>> Nothing obliges the GNOME team to accede to the wishes of people who contribute nothing to the project.
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).
But by saying that they have an obligation to noncontributors you do seem to be saying something at least in the neighborhood of what I suggested. I can’t understand where you think this obligation comes from. I used GNOME for a while. I never once imagined that the people who worked on it owed me a damn thing.
> 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.
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.
> I can certainly understand the frustration at having to deal with a community that gets annoyed at anything that changes simply because they're already so used to the garbage pile they have that they now hold the delusion that it's actually not garbage.
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.
> 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.
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:
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.
Your calculation doesn't take into account the time savings for brand new users. Since they don't have to unlearn anything, they start saving the time immediately.
Not saying it is right or wrong, but a lot of the upsetting changes for existing users are for the benefit of new users.
We can start with the contention that that isn't true. Even for a new user, the change is going to bring with it a bunch of new bugs because the new code is new, and invalidate all of the solutions to problems that people can search for on the internet until the new thing is as old as the old thing (at which point somebody tries to replace it again).
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.
But the real situation is even stronger to my point, because most software in use today won't be in 30 years. So the real graph for established products is that you continue to get new users for five or ten years as young people learn and old people die, but never enough to even hit the halfway mark. Then your company folds or gets out-competed by something else, your user base falls off a cliff and the software becomes irrelevant.
The point at which "new users" are the majority of the user base never even happens.
> 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.
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.
I was working at a large real estate marketplace. Product management came up with a nice new UI for the backend every two months, because that was what they loved to do - also lots of designers hanging around that need to work! Real estate broker - the customers - hated it of course, they only wanted to get their job done, not relearn the UI every two months.
> 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.
Most of them are too frequent, automatic, plus they are not actual improvements.
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.
> Most of them are too frequent, automatic, plus they are not actual improvements.
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.
I'm sure you know this, but memory perf and stability are secondary to supporting the hard business requirements. For low-cost products intended for mass consumption, a small feature that brings in millions of new users from a new audience is usually going to be more worth it to the business than optimizing for old hardware that doesn't bring in money anymore.
Those problems have crept up into new hardware, and depending on the product, "old" may be more than a decade, because users do not need new hardware and increasing numbers of them know that.
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.
Lost mental state is generally as painful as data is. People hate it viscerally.
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.
This is super off topic, but I also find working with video UIs frustrating for this reason. For my own needs, I have been working on a video editing tool that has a workflow more similar to web dev. E.g. describe changes in text files and render the final video on the command line. https://github.com/andykais/ffmpeg-templates
That's great when the feature set you're talking about has already been validated by the market. When it's not, it's a mistake to focus on that. I believe we call that "premature optimization."
Many will not evaluate software that is unstable, because that is a clear sign the whole effort is not yet suitable for any meaningful time investment.
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.
>The team that did not make stability a priority 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.
I agree with you, but still someone has to convince the customers to pay for that, and sometimes they won't. I've been on far too many projects where the customer won't even pay for unit tests and gets angry at the suggestion.
You're preaching to the choir. I wouldn't work on such a project again, but when you say "manage expectations" what usually happens there is the customer realizes it doesn't match their expectations and then goes somewhere else and finds something that's in their price range. The point is, there is a class of customers that aren't going to pay for this. Ever. They either can't afford it or have decided it's not valuable.
To be clear, I was mostly referring to low-or-zero-cost products mentioned previously like gmail, outlook or excel, or any random zero-cost piece of open source you can download on github. If you depend on that stuff then it is your problem, that's a signal that you won't pay the extra cost for stability. The businesses that can afford the extra stability are not using the consumer offering, they pay Google/Microsoft for a long term support contract. (And yes, Xorg, Wayland, GNOME, KDE, and all the other open source Linux desktops are all under the category of random free project on github)
I do not agree all those are the same as rando OSS on github BTW.
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...
The only real option for a high-end Unix workstation with heavily integrated software that still exists seems to be the Mac Pro. Linux is really not comparable to IRIX.
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.
I do not know what it means either. I am just gonna think out loud a bit, because I do care about this stuff. But, am also not currently impacted much. Nice place to be for me at least!
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.
There's someone else who thinks like me, and well put. Worth every minute of attention.
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.
Secondly, say growth in user / subscriber base is a high priority.
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.
Serious question: when are there not 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.
Hey, if you have the kind of money that medical companies spend on testing and stability, and you want to spend that on Linux desktop environments, I won't complain. Although it probably is better to spend that on developing life saving devices than it is on fixing outdated desktop paradigms.
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.
> 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.
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.
I think a big issue is there's no discipline in the Linux community. The Kernel team has done an amazing job of preserving ABI compatibility through every last byte, but then you look at projects like glib or GNOME which seem to pride themselves on huge, sweeping, changes and don't care if downstream consumers are hurt by the changes.
The Linux kernel team does not preserve ABI in almost all scenarios, just only specifically with the syscall interface. Everything else is not stable.
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.
These days half of Linux is exported via filesystems, IOCTLs and other random pseudo-syscalls. Ignoring drivers, of course. The kernel isn't really that stable.
> there's no discipline in the Linux community [...] look at projects like glibc or GNOME
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.)
I'm aware of the equivocation, but there's absurdity in the statement "there's no discipline in the Linux community" demanding a definition that excludes Linux proper. Descriptivists and prescriptivists should agree that no matter where you lie on the spectrum, this is bonkers.
No I do agree it's a general problem with software, but we're not talking about some rando throwing leftpad code up on GH. We're talking about a set of operating systems that clearly want more mainstream adoption being bewildered when they suck at respecting the user.
> 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
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.
> 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.
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
* 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).
All UIs are clunky in some way or another.
Most people are just happy to accept it once they’ve learned it.
Changing it every five seconds makes it easier for them to try a competitor, as they’ve lost all the muscle memory
> the main use cases of whoever was funding the project (mainly redhat)
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...?
I agree that's not good but redhat seems to be one of the few organization that pays developers to improve parts of the linux ecosystem. So when redhat endorse a project it probably means it tries to address some pain points of the status quo.
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.
For systemd the consensus seems to be that's it's better than the previous init systems as most distributions have adopted it.
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.
What you are saying is a borderline conspiracy theory and is not true. GNOME still works outside of systemd, and the distributions that want to use it outside of systemd are maintaining the parts that they need, which in reality are pretty small. (I can give some more technical details if you want, but the short answer is: elogind)
Maybe things have improved over the last several years, now that systemd is fait accompli. Earlier on in its life I recall discussions of GNOME features that would only work on Linux+systemd, and the BSDs were complaining.
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.
I remember that too and the main issue was that BSD didn't have an answer to logind and it took them a while to port later versions of GNOME 3 because of it. You can't seriously expect Red Hat or some other Linux distribution to drop everything and figure out the best way to get new features to work on all the BSDs before they release something, that's something only the BSD developers can do. If the "dog" here is supposed to be BSD, the wagging is not working on them.
Not really, AFAIK this is the only part of systemd that really caused an issue, and it was because this is a capability that really needs to be provided by the OS and can't realistically be maintained as part of a desktop environment.
- Init system responsible for way, way, way more than init, gradually taking over everything to such a degree that distros are forced to abandon Upstart, SysVinit, whatever Gentoo used back in the day, etc.
- 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.
Gentoo still has their own init, some distributions still use sysvinit, and both can run GNOME. Upstart is a dead project AFAIK, and the developer dropped it and said it was strictly inferior to systemd. ALSA is just the kernel layer, there is a limit to what you can put there, so some of it has gone into another layer in userspace, that's by design in the kernel. I won't comment on the display system, everything that needs to be said there has already been said in the other 700 comments here. I also wish this stuff went faster but unfortunately it takes time to do real work.
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.
I don't understand what you're suggesting. To put the work into the ALSA userland, you would make an additional daemon on top of it and put features there, which is exactly what Pulseaudio and jackd are.
ALSA already comes (or at least did in the past) with an optional daemon for dmix and dsnoop. Putting as much of what jack and pulse do as possible into libasound (which already handles a lot IIRC), with the minimal amount necessary into a shared daemon, could have allowed all existing ALSA applications to work with the dynamic switching that is now handled by PulseAudio, or the low latency that is now handled by Jackd. ALSA already had a signal graph that could have been evolved into the independent signal graphs that PulseAudio and Jackd can now build.
elogind from what I could tell started as a hack to get gnome to work outside of systemd. It now provides a way to use gnome without systemd but it's definitely going against the grain. Your comment implies it's easy for gnome to work without systemd. I remember the early days, it was pretty buggy since gnome essentially was built to run with systemd.
> 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).
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.
Hah. I greatly prefer the Windows start menu that went away with Windows 8, and had previously configured this Windows 10 machine to use it. Then yesterday I installed patches, and it's back to the Windows 10.
Windows patch auto-revert-settings is cancer. It breaks my bluetooth every time and my setup is very typical so it probably does it to millions of others.
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.
> Since many apps request microphone access for non-obvious reasons
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'.
The Windows ecosystem is invisibly fragmented by the million policies that change depending on install version, tier and patch level and largely misunderstood.
See for example the pages of complaints about windows forced planned reboot features deemed unavoidable from the hn majority, let alone the common users.
I was on jury duty last week and watched a windows update slow-motion-trainwreck the proceedings for 30 minutes while 30-ish people sat there and waited on it.
Yes, video conferencing does it, but so does slack sometimes at startup, discord does it if you join a voice-enabled room, flash (RIP) used to do it in our HR time tracking app, and at home deviantart.com does it and games do it. However, whether or not a competent and interested nerd can figure out the underlying logic is completely beside the point. Normies don't stand a chance, so they just put up with (from their perspective) randomly broken or low-quality audio, until they can't, at which point they restart, switch devices, or maybe even buy a new device.
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 think the biggest problem is software changing from under people's feet. We used to have stable version cycles and when it was time to upgrade, users expected change and having to re-learn some stuff. But now things just change whenever. And sometimes drastically, like buttons that previously had a fixed place and were always there can now only be accessed by moving your cursor in the right place. Very frustrating.
I see your comment's flagged, maybe because of the harsh language but other than that it all rings true to me.
> I think the biggest problem is software changing from under people's feet. We used to have stable version cycles and when it was time to upgrade, users expected change and having to re-learn some stuff.
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.
The reverse is also true.
Don't blame people maintaining software for changing your routine. You make a lot of assumptions there but the reality is often much more nuanced.
Everything changes, all the time, that's a rule that is true for absolutely everything in life.
> Don't blame people maintaining software for changing your routine.
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.
Hey that's a bit dishonest. The guy is not calling you a problematic flat-earther if you're simply not using his product. He would be if you were writing angry reddit comments about how Wayland sucks because you heard it sucks, I guess. Are you?
Correct, which is why I'm amused and not upset and will happily continue using my aged-but-working software. I'm also a horrible evil 𝓷ᴠɪᴅɪᴀ user because I need CUDA for a lot of my work :)
And people wonder why Linux isn't popular outside of industry and hobbyists... Like, sure, maintainers can tell all their users to sod off, but don't be surprised when very few people are left around using your software, and especially don't get confused when companies refuse to invest in Linux ports.
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.
I didn't mean to imply that Valve's contributions have not been significant in improving the situation with Wine, only that unlike the other examples Wine was already good before the involvement of a wealthy company.
Wine was a great technical achievement, but I remember it taking me hours crawling through WineDB and reading config guides to get most games working. Even for someone in the know, it was very impractical compared to clicking "Play" in Steam. That user experience makes all the difference.
What does it even mean?
Communities build what they need for their usecase and in this regard it's highly successful. It might not be your usecase but then, you can decide to create your own community and build it or look somewhere else.
But it's not because something do not work for you that it's not successful.
Is that really true? I can get into basically any car and understand everything immediately because they are all mostly the same. If Linux could software update the insides of a Linux car it would be unrecognizable every year.
Except when they're not. I made the mistake of assuming the + and - buttons on the steering wheel of my Subaru had the same functionality as those on my Prius' steering wheel, which incrementally adjusts cruise control speed.
On the Subaru, they are clutch controls. The result was downshifting into 1st gear going 70mph/100kmh+.
You can probably walk up to a Gnome, KDE, Windows, Mac or Chrome computer and use it after a couple seconds. I don't fully understand all the configuration options my car has - I set it to "comfort" and that's it and yet I can drive it.
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.
You can. I can. With a small adjustment period where the hotkeys or actions you expect to work don't and minimal annoyance and you make small adjustments to do the same task.
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.
Actually your analogy goes more the other way. My minivan is nothing like my suburban from when I was a kid except for having a steering wheel and a gas pedal. Pushbutton electric start, automatic transmission, power steering, automatic door locks, wireless key fob, bluetooth stereo comes on by itself without asking me, and probably next year it will be an electric vehicle with completely different mechanical characteristics. Basically, /bin/bash is the same and you might compare that to the steering wheel.
Cars changes a lot. Basics do not change, but it's the same for computers to. Keyboard, mouse, display, touchscreen, all this has been there for decades.
Details though do change a lot. Compare the controls of 2 cars, one from the 70s, one from now, I'm quite sure you'll have much more buttons, a touchscreen, things to learn like how to disable airbags when needed, where to get the maintenance information. Even something like starting the car itself is likely to be different.
The insides, thank deities, would stay pretty much the same or even better (safer). If you opened the bonnet, you'd be in tears about how solid and sound everything is. You'd need to figure out where the doors are, though, and why some son of a gun decided that the steering wheel should protrude from the ceiling.
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.
The whole purpose of tools is to make people more productive. Software is just another set of tools. Software works for people. Not the other way around.
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.
With FOSS on my own devices that's usually pretty easy -- I'll install what I like, and I expect that most reasonable people won't be upset if I choose not to put their software on my machines (clearly not the case in TFA, but you can't make everyone happy).
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).
i,ve been in the software world for 2+ decades, worn all kinds of hats, and obviously been on the user and support side quite a bit too. i know what i,m talking about here.
most software changes are unnecessary and are forced on users unnecessarily, and that,s why people hate software.
Every 6 months I try switching to Wayland. I spend an hour or so using it for regular desktop gnome use and fixing minor bugs (ie. The kind I can fix with a config tweak). I then switch back again because it just isn't there yet.
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.
I'm beating a dead horse at this point, but there's no such thing as "switching to Wayland".
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.
It is actually one of the big, unfixable, conceptual problems of Wayland that all the effort is duplicated in each compositor. The Wayland concept pushes out most of the work to the DEs. That of course will result in tons of predictable inconsistency, incompatibility, bugs, delays, consolidations and general pain. Wayland devs are then generally in the lazy "worksforme, use sway (or whatever)" position while the user (of some other compositor) will be out there complaining to yet another maintainer duplicating yet another feature badly. Lather, rinse, repeat.
Wayland is bad design, and it shows in the users' and maintainers' attrition.
I honestly think this complaint is completely bogus.
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.
Once there are 2 implementations already, a 3rd reusable one won't fix the problem (the problem being that the users need to configure everything in 3 places).
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.
Right, I agree that differences of opinions between implementations is probably not productive. I was responding to the notion that this situation is somehow directly attributable to Wayland's design, which is bogus.
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.
Can we amend the protocol to allow the exchange of various settings, such as "desired DPI / scaling"
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
Config file converters are completely outside of the wheelhouse of the graphics team. Anyone can step up and build those without any graphics programming knowledge.
No, its not a programming problem, its a herding problem. That person will have to have the ability to get all 3 implementations to agree to read and write compositing configuration the same way, so users don't have to suffer.
The thing is, Wayland actually is an improvement here, because now you only have to reconcile the configuration between those implementations, compared to before where you had to do that in addition to munging configuration and state stored in the X server and in xorg.conf. It would be nice if all desktops agreed on a configuration format and a default set of options, but I don't know that we will ever get there.
This is absolutely right, and wlroots is not a fix once you already have 2 implementations
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.
Wayland isn't bad design, at least not in the way you're describing it. I feel like there's some confusion about what Wayland actually is. It's a document that describes how surfaces ("windows") should talk to a compositor ("display sever"). That's it. In a parallel universe Kwin and Mutter would be X11 display servers and we would have all the same issues. Nothing is stopping the existence of a single extensible compositor to rule them all and be the base on which every DE/WM is based but it hasn't happened yet.
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.
Because then you end up with something like X11, which we already have.
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.
Because the Xorg mono-culture was bad. There was no ability to write other X11 display servers from the spec alone. You either did what Xorg did bug for bug or apps broke. By having many different implementations all speaking a common protocol you make it harder to calcify the behaviors of any one implementation and ensure that the spec is what apps code against.
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.
That's fine, I know. But acting like Wayland is feature complete when it obviously isn't is pretty ridiculous. Instead of solving hard problems the Wayland maintainers are acting like you're stupid to want to have the features solving the hard problems enables.
I think Wayland is about as feature complete as it's gonna get at this point. Mutter, Kwin are still working on adding features to support workflows that relied on the loosey-goosey nature of Xorg. Like Xorg never had "support" for global hotkeys or screen sharing. It's just that programs were allowed access to all inputs and the screen buffer. Designing a system where only some programs are allowed to do that isn't trivial.
That's more or less why I sometimes log in under X instead of Wayland - I can't run Fontforge under Wayland (not sure why and I don't have the bandwidth do dig deeper). Luckily, the machine behaves the same way.
I don't understand why it's so important to have multiple broken implementations before having 1 working implementation.
Especially in open source where there's no monopoly risk.
Diversity is great but equality in failure is not helpful.
> Because then you end up with something like X11, which we already have.
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.
You're dancing around the problem: Wayland works (such as it is) by offloading functionality that was part of X to the desktop software like gnome or kde and then saying "but that's not our problem!" when something breaks. Never mind that program collection 'A' (including X11) was working and program colleciton 'B' (the Wayland way) wasn't.
That's just it, Xorg did tons of things that it never should have been involved with. It used to have a print server FFS.
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.
Why does this distinction matter? Gnome on X works perfectly fine, Gnome on Wayland does not. Why does it matter it to state that Wayland is a protocol, not the implementation?
Because if what's bothering you is the implementation and not the protocol, you should be talking about fixing the implementation instead of diverting attention to the protocol? I might not understand your question here.
If every implementation of a protocol seems stuck with deal-breaking bugs or incompatibilities, it's time to start asking whether the protocol itself has some problems that make it impossible to implement consistently - unstated assumptions, for example, in the reference implementation that never made it to the protocol spec.
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.
I would agree here, if you could make a reasonable case that the problems trace back the protocol. But my point here is that practically all issues at hand happen outside of what Wayland is used for.
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.
So there's a terminology conflation issue, then: people attacking Wayland proper for issues that are actually about the 'Wayland ecosystem'. I could see that generating increasing problems if there is no observable gameplan for or encouragement to develop those pieces people have come to expect of a full desktop stack.
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.
It's funny that in the case of systemd both the scenario and hence also the complaints were the complete opposite. Namely that systemd does everything, that in an idealistic world should have been decoupled from the core. (Which was also FUD since the internals actually are decoupled and work alone).
That's funny, because for me, it's exactly the opposite. I use Gnome on Wayland/Mutter and it works great - I've never had a linux desktop that had such great UI rendering. Gnome on X doesn't work and is buggy - it's riddled with graphical glitches that other platforms (even smartphones and tablets) don't suffer from. How can that be considered to "work"?
That would be pretty amazing if Xorg ever rendered in a way that was even equal to other platforms (mutter, Windows, android, MacOS, ...) given how crazy the separation of concerns in X is and how many silly boundary crossings need to be made to process events and render them.
It would have to rely on compositor and driver bugs in those other platforms.
Gnome on Wayland works pretty great for me. (No issues with brightness etc). Occasionally I log into an X11 session because Wayland screen sharing doesn't work that great.
Because Gnome on Wayland might not work, but maybe KDE on Wayland does or "i3 on Wayland" aka sway does. That's like saying "I tried switching to Linux but it doesn't work" because you couldn't make the dropbox client run. The protocol (linux ABI) works, but the implementation (dropbox on linux) doesn't.
This is be a fine distinction to make if there is an implementation of Wayland that is there. Then we can say this is just about a particular implementation, and not Wayland itself.
If no implementation of Wayland is ‘there’, it seems pretty reasonable to say Wayland is not there yet.
People use the name "Wayland" as an umbrella term for "the entire effort on the Linux desktop get rid of X11". I'd generally agree that there aren't any desktops that flawlessly replace X11 [1], but I don't like that Wayland is the name for "the entire effort on the Linux desktop get rid of X11".
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.
I mean this is all true, but it’s worth pointing out that Wayland is actually an effort to get rid of X11 on the Linux desktop by introducing a new protocol.
Given this, it’s not surprising Wayland has become the name associated with the overall goal.
>> 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.
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.
> While technically true, that is a bit of deflection. In some cases none of the compositors have implemented certain things yet.
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!
Agreed, but my point was they could have made more clear how the line was moving relative to what they were used to. Maybe they did and it's just an issue of resources.
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).
Maybe, but I think it matters when discussing it. If we talk about it like this, it seems that Wayland is to blame. But there's nothing wrong with Wayland [1].
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.
HTML was complete *it until CSS, flex box, grid, web components, etc. are invented, so users are escaped to Flash, ActiveX, and Java applets.
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.
I don’t disagree but in a forum of tech-savvy people I expect some level of preciseness. We shouldn’t be saying Wayland sucks when we’re talking about Mutter in the same way we shouldn’t say the internet crashed when we mean Chrome crashed.
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.
That doesn't work for users though. I've used KDE since the 20th century and it has been pretty reliable. Kwin hasn't been shit. Maybe it's best to say Kwin + Wayland is shit, or Mutter + Wayland is shit.
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?
“Kwin the X11 window manager” and “Kwin the Wayland compositor” are entirely different things that look similar on the surface.
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.
On the face of it that does sound even worse.. Instead of just having to fix those issues once you will now have to fix them in every desktop environment/window manager equivalent?
Yeah Sway looks really appealing to me since i'm already using i3wm. But every now and then i'm searching if screen sharing on MS Teams already works. As a Software Engineer in this pandemic i rely a lot on screen sharing. But every time i search for it i find out that it still does not work (without a work around). That's basically the only thing that holds me back. Does anyone know if Sway or Wayland is trying to fix this? Seems like a high priority fix to me in this pandemic.
xdg-desktop-portal-wlr works (with a bit of cli work) with MS Teams in chromium with a flag to enable pipewire. The Desktop app will only support it when the Electron release containing pipewire support releases & gets used in Teams.
When I'm at my framebuffer terminal, I can either type 'startx' or 'sway'. If I go from typing 'startx' to typing 'sway' does that count as "switching to Wayland"?
Since the startx command starts the X11 client and server maintained more or less straight from the X.org project, and the sway command does not start any code that came from the Wayland project, I'd say that counts as "switching to Sway".
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.
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.
They all come up with plenty of Google results when you search for them, so I assume the devs are well aware but have other things on their plate to work on.
Agreed. Tried Wayland again last year. Screen sharing in Electron doesn't work, so can't share screen in Slack. Googled, known issue.
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.
Pipewire is still 0.x as of today, let alone when they last tried it, so I don't think anybody should be going to Slack like they were too lazy to build it "right". Besides even if it was built with that the screensharing via pipewire isn't at feature parity with normal screen/monitor/window level sharing so it's not a 1:1 drop in quite yet.
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.
Yes, Pipewire is at 0.3 today; but that's not a problem. Pipewire has the ambition to replace Pulseaudio, Jack and provide APIs for several other subject, not just screen grabbing. That's the part that is missing toward 1.0.
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.
Pipewire is definitely the right path when things are complete but right now you have to build with a beta version of Electron with build flags and rutime flags to use a 0.x version of Pipewire and when you do it currently only presents the option to capture the full screen.
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.
Looking deeper into it (been meaning to anyways) it seems to be the typical Wayland compositor specific issue, and ironically I'm using ddevault's compositor sway. Pipewire doesn't seem to care what you send it but your second window looks to be part of xdg-desktop-portal-gtk if I'm not mistaken. Since I'm using sway/wlroots I need to use xdg-desktop-portal-wlr instead. In the FAQ for this package:
"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.
Support from popular apps absolutely is a problem for the platform. It might not be caused by them, but it is their problem. The user doesn't care who's fault it is, they're just going to go with the combination which works for them.
While I agree, that support for popular apps is a problem for platform, it doesn't mean that the platform will freeze for every snowflake app.
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.
You can join a meeting; you cannot share your desktop. You cannot share your desktop, because that software is buggy and without complaining, that bug will be never fixed.
I believe that this is being fixed soon if you compile Electron with "Ozone" support. Otherwise, I use the current workaround of using OBS with a "virtual webcam" which allows me to stream OBS to a webcam and just use my webcam as the screenshare. Actually ends up working better than any screenshare utility that I've used.
This doesn't seem as straightforward as 'click the screenshare button to share your screen', which is how it works in xorg mode.
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.
That's true. Hopefully Ozone will be officially released in Chromium/Electron which will make this as simple as that. At least in Discord, XOrg screenshare always gave me trouble.
There's also pipewire which doesn't depend on ozone, but is optional I guess. What's even worse, slack doesn't allow sharing from chrome which just works for MS Teams via pipewire.
As an amateur developer, I've often found that "Why would you want to do that?" is followed by an explanation of a much better way that I hadn't even thought of. Sometimes it's asshole-behaviour, but it's often people sharing the benefit of their experience; my thinking has gone awry at some point several steps back and they want to make life easier for me.
> As an amateur developer, I've often found that "Why would you want to do that?" is followed by an explanation of a much better way that I hadn't even thought of.
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.
You'd probably get the same question from a plumber if you asked him how to plug a pipe in a non-intuitive way. He has no way to know your pipes are laid out in a strange way, and the only spot you have left to add said junction without redoing your plumbing is back there - unless you tell him.
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.
In my experience, "why would you want to do that" is dismissive, defensive gatekeeping, typically used to imply that the questioner is an idiot, whereas "why do you want to do that" extracts a reason, bad or not, that can be worked with.
I'm fairly active on the Python slack channel, and this very question comes up really often when people ask for help, and in my experience, is basically never meant as disrespectful.
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.
The semantic difference is not small. "Would", using the subjunctive, implies that the "want" is theoretical, that the person asking is in some sense trying to come up with a hypothetical situation that can be written off as being unrealistic or a silly edge case. Using it diminishes the experience of the questioner and is intrinsically disrespectful. The fact that people have got used to hearing it so much that they use it without questioning how rude and unwelcoming it is says more about that community than about the grammar.
"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."
> You'd probably get the same question from a plumber if you asked him how to plug a pipe in a non-intuitive way. He has no way to know your pipes are laid out in a strange way, and the only spot you have left to add said junction without redoing your plumbing is back there - unless you tell him.
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.
To be fair, there's a lot of people asking for help on X-Y problems in the programming world, especially on python, and often the fastest way to sort out someone's issue is to walk it back to the original problem X they were trying to solve.
Yeah, but if you don't have an XY problem, you have to spend a lot of your question pre-defending the "it's not an XY problem" stance and lordy ... is that frustrating.
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.
Often asking "why" is to tease out XY problems. It's not that the experts can't see past the end of their own nose, but rather that they have the experience to recognize questions that indicate the questioner has wandered off into the weeds.
The people replying like that are in the barely-not-novice-anymore category themselves, and their mental model of the world is that everybody is just fumbling around doing everything wrong like they were doing themselves a short time ago. It's true that when you are just past the point where you're not totally useless any more, there is a point where you think you're God's gift to the world (not judging - I have felt like this many times over, it goes away after the next big hurdle you run into...), and it's impossible at that stage to imagine the type of abstract thinking you get after many more years of experience.
But yeah - the 'XY problem!' crowd (along with the 'But The Rules!' crowd) has also totally destroyed Stack Overflow.
But, it's also a reasonable response to prevent bloat. Not asking that question is how anything with backwards compatibility guarantees, especially languages, get too complex over time. Asking the question doesn't mean you've hit a wall; the maintainers may just be going through a mental checklist to try to keep this from being a major pain for them in 10 years.
Change causes stress, it's a scientific fact. It is thus not surprising that many don't like change for any reason, nor is it a reason not to change if the reasons are sound.
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.
The fact that has gone on more than seven years and Wayland is not mainstream is exactly what the problem is.
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.)
Or you know, development on Linux is not cathedral but bazaar based, and they can’t just say “this is the new display protocol”. And until a critical mass is achieved noone will even start porting apps over, and all that.
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)
>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!" as though that was supposed to make it ok.
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.
> screensharing and RDP. Other implementations decided to implement those in a different way
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?
>if the different implementations doesn't have a common interface it's goodbye to ever having screensharing work for everyone.
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
> 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.
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.
I'm not sure what are the changes in the X11 server implementation you're talking about, but if they do indeed meet every single possible use case, then maybe someone can bring them over to Wayland? I'm sorry to say, but you have to acknowledge these are novelty applications and are really not driving progress right now, the main focus is in getting all the other applications to work.
The X11 server changes would involve isolating clients by default, keeping them unaware of windows they did not create themselves... but allowing a whitelist of trusted clients that can see everything.
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".
See the protocol extension I linked, there are absolutely exceptions and escapes that can fall back on the X11 way of doing things, and could even work with such X11 client isolation, but somebody would have to take the time to actually design and implement them and figure out how to get them to work with the security model used by the Wayland implementations. That is really the problem, it's only an implementation detail if you choose to do it by hacking the X server or you choose to make a new D-Bus API for it, or whatever. (i.e. there is no real reason XWayland needs extra extensions, it could call a D-Bus API if necessary, and that may even be desirable because the D-Bus API would be forward-compatible with newer Wayland applications)
There is nothing fundamentally difficult about goddamn snow, like transparent windows are a thing in wayland, full screen overlays are supported in some compozitors, so feel free to port it over if this is really the ultimate thing you need in life?
Under the base protocol. What is great about wayland is that it has proper extensions, and it is entirely reasonable to create a new one to query the current layout for some application.
> 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!" as though that was supposed to make it ok. People have thus harbored some inherent resentment ever since.
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
Remote windowing is a legacy of the era when universities ran dozens of dumb terminals from a server. It would be bizarre to pursue that in an era of hardware-accelerated graphics.
If the Wayland design was weighed down by such things, it could never hope to be progress.
It is actually a common enough use case that Windows supports it now via Remote App, which is bit of a hack over RDP since RDP wasn't really designed for that. The use case may be relatively small but it undeniably still exists.
It is reasonable to want remote desktop access. I am unfamiliar with the RDP technique you raise, but expect it could be achieved through VNC or similar systems.
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.
this is sort of exactly my point but inverse - X windows is awesome on a lan & due to the 'native' support for individual applications, but there is definately huge room for improvement w/r/t display protocol performance / latency issues which are largely a result of relying on X server drawing architecture
don't throw the baby out with the bathwater, in other words
But this is the thing, X is not network transparent anymore. Basically no app created in the last decade use the native rendering libs of x, and thus what happens over the network (moving bitmaps) is much worse than what a decent video streaming algorithm could do.
This ignores the current tend of hosted gaming services. The pendulum regularly swings back and forth between thin and fat clients as cost and innovation evolve.
There is no reason for a display protocol to know about these things. At most it is responsible for giving access to a window’s/screen’s buffer and then any app can do whatever they want with it, eg compress it and stream it (which as I wrote in an other topic is usually better performing than today’s frameworks over whatever remained of X remoting, with bitmap transfers and the like)
How many people use TeamViewer, Anydesk, etc? I don't see how remote windowing is legacy. The feature would be a huge hit if it were modernized and made more accessible and efficient (akin to Microsoft's RDP), and that's only possible if it's a core part of the protocol.
TeamViewer/AnyDesk/VNC is not "remote windowing", it's "remote access" to a whole desktop. And that's easily available for the wlroots ecosystem https://github.com/any1/wayvnc
But actually "remote windowing/apps" is even better supported, it's a universal proxy: https://gitlab.freedesktop.org/mstoeckl/waypipeAbsolutely does not require any support from the core protocol.
That amount of negativity on the internet is just astounding sometimes. Technology Connections has called for some positivity in twitter responses. He throws out random crazy suggestions on twitter, as he points out it was designed for. But there is always someone faulting it.
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.
In HN healthy ratio is something like 10% positive 90% negative, I think.
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.
> That does not mean anyone is under an obligation to like it.
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.
Critically speaking about Wayland for what Wayland is, reporting bugs, asking for enhancements, this is good. The author is not speaking about closing down the bug board or enhancement feedback.
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.
And that punting is indicative of the problem. The reason the stacks we have are hot garbage is because they didn't have the luxury of punting on hard problems, and hard problems solved quickly make your stack hot garbage.
It does give you a garbage stack that solves problems though.
I don't see how screen shots/sharing is really that hard of a problem. Wayland's model doesn't give the ability to arbitrarily capture these things the way X did, but surely it couldn't have been that difficult to add an escape hatch for common use cases like this to the base protocol.
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".
I'm not a developer on Wayland and I haven't looked at the code, so I can't comment directly on their situation. A hypothetical I can come up with is that if they've tried to implement a very secure architecture, they may have painted themselves into a corner if there's no easy way to capture pixels post-composite... Then no one piece of the system has enough authority to see all the pixels to capture an arbitrary screenshot, and oops.
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.
Screenshots on embedded is very useful in some cases, like debugging, or information sharing or archiving, which often performed by smartphone camera today.
>> In the case of Wayland, the “vague authority” are a bunch of volunteers who have devoted tens of thousands of hours of their free time towards making free shit for you.
>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. :-)
Even if it does do exactly what it’s supposed to, free software requires marketing, same as commercial software. Make it obvious how to do it, or create a utility that does it for you if necessary.
> If you insist on disregarding people's use cases, don't be surprised they don't like your software.
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.
To be honest I find It a bit pretentious to call this a "mistake". This happens: Devs don't like to maintain old codebase, start a new one, anybody is free to start maintaining the old code. And then there is you, who calls their strategy "a mistake".
You can still use Xorg on most distros. In Ubuntu it's one checkmark.
I have no beef with Wayland specifically and I agree that if you are harassing maintainers of any project you're probably an asshole. However,
>Maybe Wayland doesn’t work for your precious use-case. More likely, it does work, and you swallowed some propaganda based on an assumption which might have been correct 7 years ago.
I'm a game developer. None of the software I use works reliably or at all on Wayland. None of it. And I'm completely fine with that, I'll keep using Xorg and you can give me a call when my "precious use-case" is handled.
that's imho the core problem with wayland advocates:
- if you rely on something that doesn't currently work on wayland and you write about it on (for example) hacker news then you're the asshole and you should be dropping that something and switch to wayland (which of course, most of us cannot do)
- if your current setup works and you'd rater spend your time doing your stuff instead of rebuilding on wayland, you're an asshole
rinse and repeat.
Most wayland advocates can't seem to understand the philosopy of "I don't really care about xorg vs wayland, my current xorg-based setup works well enough for me, i'll switch when I can be equally productive on wayland".
> ost wayland advocates can't seem to understand the philosopy of "I don't really care about xorg vs wayland, my current xorg-based setup works well enough for me, i'll switch when I can be equally productive on wayland".
Because usually the part "my current xorg-based setup works well enough for me" is not true. It will be said, when it comes to wayland, and they don't want to switch... but once hidpi or mixed-dpi displays or reliable screen-lock or something other comes on topic, then suddenly "linux" (not xorg, but linux) is behind the times, doesn't work out of the box as other systems do and requires hours and hours of configuring.
That's the "my current xorg-based setup works well enough for me" in the full glory.
>>> most wayland advocates can't seem to understand the philosopy of "I don't really care about xorg vs wayland, my current xorg-based setup works well enough for me, i'll switch when I can be equally productive on wayland".
> Because usually the part "my current xorg-based setup works well enough for me" is not true.
case in point. What do you know about my current setup for example? it works remarkably well for me.
Stop making the whole wayland thing look like a bunch of annoying people.
> Most wayland advocates can't seem to understand the philosopy of "I don't really care about xorg vs wayland, my current xorg-based setup works well enough for me, i'll switch when I can be equally productive on wayland".
Same rehash the same arguments of Linux vs Windows that people have been having for years. It's turtles all the way down :)
It's only less common nowadays around these parts since tux has become far more usable day-to-day in the last decade.
Noone is bothered by the people that simply don’t care about or can’t switch. People are bothered about “why rediscover the wheel when x11 works fine, and also this whole protocol is shit because no screenshot blahblah“.
Let's be honest, most wayland advocates do not give a single shit about people sticking on xorg.
They might care a little bit more when their only interactions are with snarky people going "sO yOu StILl CaN'T tAKe ScReEnShOts oN wAyLaNd haHaHa sHiTtY sOftWare", or legitimate assholes.
Yea i'm confused by this line. I'm a Linux-desktop-noob, but i was going to use i3-Wayland, aka Sway, and because i have an Nvidia i was told don't bother. Nvidia Drivers + Wayland sound broken?
Now that may not be true.. but it seemed clear cut. I wanted to try Wayland really bad because i have a multi-DPI monitor setup, and Xorg is awful at that. Yet, it seemed too early.
Nvidia isn't exactly some niche product. Not exactly a "Precious use-case".
On the one hand, trying to work with a company as intractable and anti-OSS as Nvidia must be incredibly frustrating and I sympathize. Nouveau is too slow and broken to be usable, and that's also NV's fault. On the other, I'm never going to choose Wayland over Nvidia (i.e. throw out all my GPUs and buy slower ones), and it obviously can't be a default in any major distros while this is still the case. So long as it's not a default, it won't have the support or pressure needed to fix its many smaller problems.
Unfortunately, Wayland is dead in the water until it can run on Nvidia machines, and no amount of blog posts will change that.
Yet again, wayland is the protocol. Wlroots based wayland compositors doesn’t support the nvidia created API, but gnome and as far as I know plasma on wayland both do so. So your statement is simply false that wayland can’t run on nvidia (proprietary. The open source version works everywhere).
if people on HN don't know or care on something like this (I didn't, and I don't), then good luck telling less HN-y people about wayland being the protocol and not the implementation.
I'm annoyed at myself for this very comment, but somehow, somebody (many people), somewhere messed up the messaging around these things.
The messaging needs to not say "wayland replaces X11", but instead "GNOME or KDE replace X11" & if someone wants to use a different compositor it's up to that compositor whether they want to match X11 features or not (& then the rest of the software ecosystem to implement support for that compositor's features)
Then it becomes a question of whether GNOME/KDE have feature parity between X11 & wayland. Then other compositors can go about implementing the interfaces they've setup to be GNOME or KDE compatible
> Nvidia users are shitty consumers and I don’t even want them in my userbase.
Can't say he isn't straightforward. If you bought your computer without thinking about running Linux on it, or if you're looking to install Linux on an employer-supplied Windows laptop, there's an excellent chance you're a shitty consumer that he doesn't want using his software.
Yeah I did think about it, which boiled down to "NVIDIA has working up-to-date Linux drivers" -- AMD used to be way worse and also there also has been a shortage of AMD-based workstation-class laptops on the market.
What I haven't considered is whether NVIDIA's Linux drivers might be implementing a particular graphics stack interface differently so that implementing Wayland on top of it becomes a PITA for some developers (not that GNOME and KDE didn't compromise to implement it anyways for users' sake). That does not make me a "shitty consumer", there is no way even a cautious consumer can take things like "GBM vs EGLStreams" fully into account every time.
Wow, so he writes an article about people being assholes about him not writing free extra stuff, and this other article saying literally “nvidia- fuck you” (and its “shitty consumers”) for not writing this other free extra stuff. He says that’s treating Linux users like shit, when a massive part of nvidia’s business is supporting Linux (GPGPU stuff), which works fantastically.
Reading OP, I figured it was righteously angry. Reading your article, I’m now figuring he’s just angry and abrasive. The OP article reads hypocritical after reading yours.
>so he writes an article about people being assholes about him not writing free extra stuff
I did write that extra free stuff, and I'm arguing that some people are being assholes because they perpetuate the lie that I didn't do the free work, and because feature "foo" doesn't work, project bar must be bad. But feature "foo" does work, and using that falsehood to say project "bar" is bad is a dick move. This is the "horseshit" that's pissing me off.
The Nvidia issue is different: Nvidia goes out of their way to prevent their hardware from being used for this purpose. For example, they use signed firmwares that we simply cannot use for implementing the features we need, relying on cryptography to lock us out of their platform unless we use their driver. Then that driver doesn't support what we need. Nvidia deliberately prevents us from putting in the effort. They have created an artificial monpoloy on the required labor, then refuse to do it.
You and I are reading the criticism differently. There’s genuine assholery, 100%. You’re entirely right that those people just make everything worse, and I’m sorry let you have to deal with them.
The other side of things is what I see differently. When folks are saying wayland isn’t ready, or even that it sucks, I mostly see them as referring to the ecosystem, not wayland itself. It’s an unfortunate quirk of language. Because foo doesn’t work, the bar ecosystem is currently bad.
On the nvidia side, I’m not going to engage further with you on that because you called me a shitty consumer and that pisses me off. Fuck me, you don’t want me in your userbase anyways, right?
Good luck, and I wish you users with the same understanding and respect for your choices. I hope nobody calls you a shitty developer because you made choices they don’t appreciate.
> when a massive part of nvidia’s business is supporting Linux (GPGPU stuff)
I've spent the last few months doing GPGPU stuff on Nvidia Jetson devices and my experience has been the complete opposite. I've rarely seen something with such bad support and documentation.
I'd love to hear more. I've only used the datacenter and flagship consumer GPUs, which work great. I hadn't heard of Jetson, but looking it up, it's a bummer to hear that something that looks that cool for hobbies doesn't hold up.
Well, don't get me wrong. I do like my Jetson Nano. For a hobbyist who likes to tinker with machine learning in their spare time it's definitely a product cool and there are quite a few repositories on Github[0, 1] with sample code.
Unfortunately… I'm not a hobbyist, I'm not tinkering and the aforementioned repositories are… about it. There is little documentation about
- how to build a custom OS image (necessary if you're thinking about using Jetson as part of your own product, i.e. a large-scale deployment). Ideally, I would like to do that as part of a CI/CD workflow. What proprietary drivers and libraries do I need to install? Nvidia basically says, here's our custom Ubuntu image with the usual GUI, complete driver stack and everything – take it or leave it. Unfortunately, the GUI alone is eating up a lot of the precious CPU and GPU resources, so using their OS image in production is no option for me.
- how deployment works on production modules (as opposed to the non-production module in the Developer Kit)
- what production modules are available in the first place ("Please refer to our partners")
- what wifi dongles are compatible (the most recent Jetson Nano comes w/o wifi)
- how to convert your custom models to TensorRT, what you need to pay attention to etc. (The official docs basically say: Have a look at the following nondescript sample code. Good luck.)
- how do I automize testing of TensorRT models & code? Why isn't there a compatibility layer which allows executing my models on non-Jetson devices / on a CPU (obviously at lower performance, but I don't mind).
- … (I'm sure I'm forgetting many other things that I've struggled with over the past months)
Anyway. It's not that this information isn't out there somewhere in some blog post, some obscure Github repo or some thread on the Nvidia forums[2]. (Though I have yet to find a wifi dongle that works reliably…) But it usually takes you days or weeks to find it. From a product which is supposed to be industry-grade I would have expected more.
Appreciate the info! I'll have to look into that. As someone who runs Computer Graphics software GPU perf is important to me. I'll be curious to look into how Nouveau behaves there
As an aside, i hate GPUs on Linux. I'm running Blender and am in the market for a new PC build. The GPU is a huge source of confusion, due to Linux.
I see so many conflicting stories about how well AMD GPUs behave and perform on Linux. Some new, many old. Some even as extreme as "I bought a new AMD GPU and there are no drivers for it yet". Furthermore for Blender specifically AMD seems to get the short stick in performance.
Really leaves me confused as to what to buy. Just venting.
Amd should work but you will most likely require the proprietary drivers which implement openCL. Amd has a second project called rocm which is meant to work with blender and be open source but it has shocking support for their products (no support for the 5700xt)
How well does Nouveau work on Wayland? On X11 it's a complete disaster compared to the proprietary drivers. Framerate drops when just moving windows around or scrolling in my editor, screen tearing, fans blasting when playing videos or just randomly.
NVidia is broken, not Wayland. They refuse to implement the same APIs as everyone other driver does.
Wayland is 10 years old, and extremely stable. If it isn't working properly it's either your driver vendor or your desktop environment that is to blame.
Sure, i'm willing to accept that - but is your solution for me to buy a new graphics card?
How much of the market share is Nvidia? A stupid quick search's top result says 80%. So 80% of PCs can't run Wayland?
To be clear, i know nothing of compositors/etc, I've had nothing but problems with Xorg, and i want to use Wayland. _and yet_ - it seems like there is not a single PC in my house, or any of my family, that can run Wayland.
I'm happy to accept your statement of where the blame lies. But if you're telling me Nvidia can't run Wayland currently.. does it matter to the end user? When "Most PCs" can't run Wayland his statement of "precious use-case" seems off base.
> How much of the market share is Nvidia? A stupid quick search's top result says 80%. So 80% of PCs can't run Wayland?
No. 80% of PCs cannot run Sway. Both Mutter (GNOME) and KWin (KDE Plasma) implement support for EGLStreams for the Nvidia driver. However, EGLStreams itself is inherently quirky and kind of broken, per Nvidia themselves. They're working on moving to DMA-BUF to fix this, and at least on the KDE side, are committing to replacing the implementation in KWin to use that once the driver is updated to use it.
You can run Wayland on NVidia drivers, but then your desktop environment has to support EGLStreams, which isn't a requirement for any other drivers and as such isn't implemented in all DEs.
> How much of the market share is Nvidia? A stupid quick search's top result says 80%. So 80% of PCs can't run Wayland?
No.
Long-term Nvidia share is about ~18%, AMD ~12% and Intel ~70%. But that's for the entire market, and since Windows gamers are skewing toward Nvidia, that makes the rest to make up the percentage.
So 80% not being able to run Wayland due to being Nvidia is grossly incorrect.
So developers should bend to abusive business partners with a big track record off being assholes just because they are currently (!) the biggest player?
> it seems like there is not a single PC in my house, or any of my family, that can run Wayland.
Huh, here at work and also privately all can run Wayland just fine; just always had issues with NVIDIA, so we would see it exactly the opposite way. We vote with our wallets and strictly prefer AMD or Intel GPUs, as they both play much better with Linux and open source in general (could always get better, though).
Note also that on Linux the market share from AMD increased from ~25% to ~40% over the course of the last two years[0], and those do not seem to be short-lived effects, and the ratio may well tip over in favour to AMD soon in the Linux world.
So yes, if you want to run Linux with a modern Graphic stack you will need to buy a GPU from a different vendor than NVIDIA. At least if hell freezes not over, and they put off their backwards bent attitude against open source drivers.
If you do not want that then fine, use your NVIDIA card, but don't expect people to put in any extra work just because NVIDIA always want to be a special snowflake; seemingly putting in extra effort to produce as much extra work as just possible to support it.
> So developers should bend to abusive business partners with a big track record off being assholes just because they are currently (!) the biggest player?
That's not at all what GP is saying. They're saying that X handles their use case, and Wayland doesn't, and that most end users won't care about who's fault that is.
A lot of the criticism of Wayland comes from uninformed jerks who want to trash the protocol over stuff that isn't a real problem, but there is also a bit of reflexive lashing out that comes from Wayland advocates. GP is just saying they can't switch to Wayland until the ecosystem around it matures. That's not an attack, you don't have to take it personally.
> you will need to buy a GPU from a different vendor than NVIDIA
I run a 4K monitor on my desktop with an ~6 year old NVidia graphics card. I run modern software on that machine, I watch movies, I run games, I do 4K art, I even boot into Blender occasionally. I'm not seeing significant slowdown or framerate problems as long as I use NVidia's proprietary drivers in X. But on Nouveau, it's unusable. Who's fault is that? Probably NVidia's! But it doesn't matter, my computer currently works well, I have no plans to upgrade in the immediate future, and this was put together during a period where NVidia was very clearly the sensible choice for anyone who cared about Linux graphics performance.
It's reasonable for people to use older hardware, and it's reasonable for them to want that hardware to work well. We're not talking about people running 32 bit OSes or something, not everybody upgrades their graphics card every 2 years, and it's not really feasible for the surrounding Wayland ecosystem to only target the people who do.
I don't have a proposal for that, I'm not saying anybody has to do anything. I'm actively rooting for Wayland, I do think it is the future. But I'm also describing why I don't run Wayland on my Arch setup and why I don't recommend it to people who ask me about getting into the more technical side of Linux. If someone wants to take even that as some kind of anti-Wayland screed instead of as a completely neutral, factual representation of the current state of the world and the Wayland ecosystem, then that's their problem, not mine.
There's this thing I'm seeing where anyone bringing up these issues just gets asked, "well, what's your suggestion? You want to force developers to do X?" I'm not suggesting anything! I'm describing why I don't use Wayland on my desktop. That's it, that's the only thing I'm doing. I don't know how to solve the problem, but the problem exists, even if it's not your fault.
> A lot of the criticism of Wayland comes from uninformed jerks who want to trash the protocol over stuff that isn't a real problem, but there is also a bit of reflexive lashing out that comes from Wayland advocates. GP is just saying they can't switch to Wayland until the ecosystem around it matures. That's not an attack, you don't have to take it personally.
Only the first group is the problem, and I think noone is bothered by the second.
> NVidia is broken, not Wayland. They refuse to implement the same APIs as everyone other driver does.
I'm extremely sympathetic to this argument, and I actually agree with ddevault's decision not to support NVidia in Sway. I think as an Open Source maintainer you don't have an obligation to burn yourself out solving a problem that is NVidia's fault, and we need real pressure on NVidia to stop being completely awful.
However.
Linux is at the point where I am able to start recommending it to ordinary people, and even technical people who are used to Windows. One the selling points I use is that a lot of hardware "just works" in Linux. NVidia is not ddevault's problem to solve, but people buy NVidia cards, and regardless of who's fault it is, if someone walks up to me and asks about switching to Linux or using a tiling window manager, I am not going to have a conversation with them about graphics cards. I'm going to point them towards X-compatible software that gets good performance regardless of their graphics card.
Doesn't mean it's anyone's fault that I can't recommend Wayland to everyone, but I can't recommend Wayland to everyone.
And I am on the Wayland hype train. I don't like X11, I want to run Wayland. In most cases, I would be defending Wayland right now. But if one of the conditions of switching over is "buy a new graphics card", if it's "redo all of your linux-wacom setup"[0], if it's running an entire embedded X session just to get Emacs working[1], if it's that common applications just don't work right now, then that's not ready for prime time. Those aren't problems that the Wayland devs can fix, but until they get fixed, I just can't in good conscience tell people that the Wayland ecosystem is mature and ready for regular usage.
The moment I have to talk to someone about throwing out hardware, I'm recommending them to stay on X. I don't care who's to blame, people want software that just works, and I don't feel confident that Wayland just works. I'm not going to recommend every i3 NVidia user throw away their graphics card, that's not a real solution. I sympathize with the devs who are being hounded to solve problems that aren't their responsibility[2], but I also sympathize with the users who are just as much not to blame for any of this. It is also not their problem to solve when they can instead just use an existing stack that works today. They have zero obligation to play Where's Waldo with the maintainers of a dozen projects just to build a working system.
----
[0]: Do equivalently powerful tools to linux-wacom even exist for Wayland right now? I can't find out. There's basically zero documentation that exists on this that I can find, compared to an extensive Arch guide about rebinding keys under X11, multiple helpful utilities like xsetwacom that are pretty well documented, and dozens of blog posts and forums that are troubleshooting even obscure issues. That's not a narrow use case, my computer is an art station. I need to know before I switch that my Cintiq will work perfectly, and DuckDuckGo doesn't know the answer to that question.
[1]: Emacs is finally working to get rid of its X dependencies, but it's still not part of the main release, I'd still need to switch to compiling Emacs myself, which... no.
[2]: And I'm also sympathetic to arguments that this just takes time, and as people start to switch more utilities will be written and driver support will get better. But it's taking a really long time. And I don't know where NVidia fits on that spectrum, because I'm not confident that they're going to magically stop being awful any time soon. Maybe someone else will write a compatibility layer around the driver or something? Eventually? Waiting for NVidia to go out of business and their hardware to vanish isn't feasible.
I think its worth pointing out that Wayland does support NVIDIA's hardware, that the two most widely used Wayland compositors (GNOME and KDE) do support NVIDIA's hardware, and that NVIDIA pays people to work full-time on Wayland, and these compositors, opensourcing their work.
The issue here is that sway, one wayland compositor, does not want to support NVIDIA hardware because they lack manpower. They are also not able to attract anyone willing to implement this support, like other compositors have done.
If you wonder why this is the case, just read this blog post again, and wonder if you'd like to spend your free time working with maintainers that write like this. Go ahead, read any of the other blogpost, or skim through the closed issues in the sway repository.
Trying to spin sway's failure to support NVIDIA's hardware as "NVIDIA hates wayland" is ridiculous in 2021.
FYI I use sway as my main DE, and I'm indeed grateful to its creators and maintainers (ddevault is not a maintainer anymore). But when I read this:
> "We’ve sacrificed our spare time to build this for you for free."
they sound to be entitled to my gratefulness. This is just such a toxic way to go through this world.
For [0], libinput from what I've seen is supposed to take the place of linux-wacom. However I have only been playing with wacom fairly recently (I got one as a Christmas present) and haven't explored linux-wacom to see what is missing. I know with respect to libinput I have had difficulties getting the extra buttons on my tablet to work and some things have been a bit rough, but I don't know if that is due to me not understanding something or what.
TL;DR Theoretically libinput is a linux-wacom replacement.
The commonly heard demand is to start working on a common ground, like AMD and Intel seems to be able just fine.
What's your proposal? Requiring paid and free-time spending software developer to bent backward and maintain some complex parallel implementation for EGL-Streams just because NVIDIA always want to be a special snowflake? Even seemingly putting in extra effort to be a PITA for all involved and produce as much extra work as just possible to support it.
EGLStreams is not only an Nvidia thing though. For instance Google provides an implementation of it (as it's you know, an actual Khronos standard unlike GBM if I'm not mistaken) on ANGLE on windows. While GBM is purely a Linux thing.
Perhaps they should be disappointed in nvidia? Or at least, think twice before buying from them? I don't think anyone here demands anything from nvidia. It's not wayland devs that feel entitled to better treatment by nvidia. It's nvidia users feeling entitled to support in wayland compositors.
Nobody pays Nvidia. Nvidia has an opportunity to enter the market (on Windows and Linux) and it is up to them to use it. It usually goes easier if it is not against the grain.
On some platforms (Mac) they don't have that opportunity at all.
If we are being pedantic, linux doesn’t support nvidia (more correctly the reverse), sway only tries to build upon the user space provided by the linux kernel.
No problem, the biggest ones I tried were Godot, Krita, and Steam. Godot does not run on Wayland although support seems to be planned somewhere down the pipeline. Krita "runs" on Wayland but a lot of the features do not work nor does pen support last time I checked. Steam just doesn't work.
Edit: A commenter on this thread mentioned Emacs. I have not tried that as I have recently switched to Emacs but if that is true then that would also be a big one for me.
I have a Linux PC that my kids mostly use, running Wayland sessions. It definitely works with Steam and Krita, although I admit that I do not know if all of Krita's features work. They have played Portal 2, Minecraft, and a few "windows-only" games with Proton.
My biggest gripe is that if you have more than one window of Chrome open it gets VERY slow. Multiple tabs are good, multiple windows are not.
Chrome regressed on Wayland after changing the default rendering path on Linux. The slowness seems to be a problem in getting proper vsync, and there are multiple cases where it was/is causing issues.
Chrome doesn’t even run on wayland, unless compiled specifically on a new enough branch so OP talks about the version running inside XWayland. It can possibly be a bug in the specific compositor’s xwayland implementation or even in chrome.
Also, your special ability to try out every compositors must be really useful.
It's a couple of years old, but this post on "Why I'm not going to switch to Wayland yet."[1] summarizes some of the concerns I have about switching to Wayland:
"at the moment there are several types of applications that not only don't work in wayland, but would be very difficult, or impossible to work natively in all major wayland compositors.
* It's not exactly the same, but I use Kanshi for dynamic output configuration. https://github.com/emersion/kanshi
* https://github.com/bugaevc/wl-clipboard
* https://hg.sr.ht/~scoopta/wofi
* https://github.com/yory8/clipman
* There's wlrobs for OBS. There's grim/slurp/wl-recorder for use outside of OBS.
* You can use grim to grab a particular color on the screen, but the UI wouldn't be as good, of course.
Yes, when Wayland acts like X then X apps sometimes work. In the process you abandon the security and performance features of Wayland.
Getting xwayland working is another story. I can't seem to get it to work at all on my PinePhone; but to Wayland's credit, the phone crashes for all sorts of reasons.
Yeah, Wayland needs to act like X when using a pure X application.
But emacs X/"gtk" frontend has been controversial for a few reasons, with work having been under way for quite a while for a new frontend, somewhat unrelated to Wayland.
Xwayland not working on pinephone is ironically primarily an X problem, as Xwayland is just xorg-server compiled with only the Wayland backend enabled.
And, as there are little to no xorg developers, fixing xorg is proving tricky as there is no one to make a new xorg release...
Why would you abandon the security of wayland by an xwayland app? It only sees at most other xwayland apps.
As for the pinephone part, I may not understand your point about “to Wayland’s credit”, do you think stability issues on the pinephone is due to wayland?
The PinePhone has unstable hardware, it doesn't matter if I run X or Wayland and it doesn't matter what distribution I use. I can't keep it operating for more than 5 minutes before the screen goes to blank and/or it gets stuck in an endless reboot cycle that requires removing the battery to halt.
Which distro? I have one as well and at least under mobian , while it is really far from stable, it works. But reboot cycles sound like a hardware bug rather than unstable hardware.
And multiple release versions of each; using multiple different sdcards as well as the on-board memory.
The only OS that doesn't exhibit the reboot/black-screen issues for me is the one used to allow flashing of the device over USB.
The factory test software works, all of the different OS variants; so if there is a hardware issue the factory test software isn't able to detect it. Notably, I've left the test software running without issue.
I've even tried turning off all the hardware dip switches.
Interesting, but if you really are enthusiastic about the pinephone than perhaps try to order another motherboard (I’m thinking about it because the older has only 2 GB of ram)
I've got the Manjaro CE version, so it should be new enough. I'm also not flush wish cash, so... Yah, I'll be buying diapers for my toddler, not a motherboard that may or may not work.
It's a shame, 'cause I really like the concept, and bought it for myself as a birthday gift. Thought it would be a fun project to hack on.
I have been plugging and unplugging multiple displays into my laptop since March. Usually I have emacs running locally (xwayland) and an emacsclient over X11 to a remote server. I have not experienced any issues so far. Maybe the readme is too conservative in this regard?
That's not strictly correct. Give the `feature/pgtk` branch from upstream a try, `make` it yourself unless your distro has a binary for it -- that (`make`'d myself) worked for me on Void Linux.
There are also a few forks on GitHub with native wayland patches out there too if `feature/pgtk` doesn't.
I'm already on 28.x/native comp. Is this branch really tested and working well enough without any performance regressions? I read the LWN article about this branch and it did not increase my confidence.
I’m using a Dell UP2718Q (3840x2160, 144dpi, 60Hz) and a Fujitsu Siemens P17-2 (1024x1280, 96dpi, 75Hz) side by side, and without Wayland this setup isn’t even possible to get working properly. Sadly, KDE still doesn’t support it nicely under Wayland (so I moved to Ubuntu Budgie), but under X11 it’s entirely impossible to run it properly, as except for Qt nothing supports mixed DPI, or mixed refresh rates properly.
Once proper wide color gamut and bitdepth support is added, it’ll be even better, as the monitors are 10-bit Rec.2020 and 8-bit sRGB. Which under X11 isn’t even possible to support, as again, Xorg only sees one single screen it’s drawing on, and it’s up to the lower levels of the stack to split that.
EDIT: Answering the most common question which is asked all the time as my comment is getting some visibility here:
Now why does wayland break screenshot and keyboard tools? Because "every program is a keylogger by default and can see any event, look at the contents of any window" is a major security issue, especially as it means the entire security model of screen lockers or containerized applications is useless.
Under X11, basically every application you run can trivially escalate itself to root. As even your Zoom client can just listen to your key events when you unlock your screen or use sudo in your terminal, save your password, and tada it can elevate itself. Under X11, there is no security whatsoever, and no separation of privileges.
EDIT2: Why is sandboxing applications important? (a) more and more proprietary software is also released for linux, which you probably shouldn’t trust. And (b) if e.g. your XMPP client is compromised, you don’t want the attacker to gain root.
EDIT3: Yes, screenshot tools and screensharing still works. I can use KDE Spectacle under Budgie or Chrome, and Slack, Teams, Discord, Jitsi all work just fine. OBS requires a patch, but also works nicely. It’s not impossible, it just requires software using it to be updated.
Professional pentester here - Wayland alone doesn't really do much for you, security wise. It is still very possible for an application simply running under a wayland compositor to do lots of nasty things.
The Wayland protocol provides the building blocks for someone to create an Android-like sandboxed environment, but doing so would break every application. Snaps and Flatpak come closer, but still generally miss the mark, since many applications require your entire home directory to be bind mounted in their container.
Running wayland alone gets you very little in terms of sandboxing. It locks the front door, but leaves the backdoor and all your windows open, because that's what every application under the sun expects.
> Under X11, you are basically running every application with root, always.
This is ... not true, either broadly or generally. You're saying this because Xorg runs as root, which means that any security flaw in Xorg yields root access. I think saying that "you are running every application with root" is stretching it a bit, but I'll accept it.
But Xorg doesn't have to run as root. OpenBSD started it years ago with Xenocara, but AFAIK Fedora also does not run Xorg as root. I'm not sure what other OSes are doing, but it's at least not a flaw of X11 in general, just a flaw of Xorg.
> This is ... not true, either broadly or generally
I’m saying that because if you ever type in your password, e.g. into a screenlocker, into a terminal with sudo, or an apt-get gui, every application can listen to those input events. Every application has the ability to be a keylogger by default. And with that captured password, it then can either inject input events into your terminal, or run sudo itself.
> The Wayland protocol provides the building blocks for someone to create an Android-like sandboxed environment, but doing so would break every application. Snaps and Flatpak come closer, but still generally miss the mark, since many applications require your entire home directory to be bind mounted in their container.
That’s true, but also not. With X11, even a flatpak without any special permissions or bind mounts can still basically control your system. Just listen for input events until you see the keys "s u d o", then listen until you see something that looks like a password, then wait until the user is not paying attention, and inject virtual input events to start a terminal and inject input events to run "sudo rm -rf /*" with the password you captured earlier.
By making the ability to intercept, record, or inject input events a special API, wayland at least allows flatpaks to be sandboxed at all.
Still, assuming a lack of other sandboxing, running a keylogger is pretty trivial. It's not by default, as you put it, but an un-sandboxed application has enough access to your filesystem to perform tomfoolery and get your credentials. At that point, there's no need to start a terminal, you just load some shellcode in whatever process you control, and say goodbye to your data.
As for sandboxing, well, you're right, although one could sandbox X11 if they wanted to. "X-on-X" is actually a thing, rarely used outside developing X, but I could see it being used for seamless sandboxing with some work. Work that, inevitably, no-one will actually do, so there's that ;)
It actually is feasible to sandbox X11 in that way, I believe this is what security-focused distributions like Qubes and Whonix do. But yeah, it is essentially working around the problems with X11 and not really suitable for ordinary use.
To me the real progress needed is that applications need to move to using sandbox-friendly APIs so they don't break when put in the sandbox, and moving to Wayland is a key part of that. Applications built around the X11 idea of always having full access to everything will need changes regardless of what sandboxing solution is in use.
> I’m saying that because if you ever type in your password, e.g. into a screenlocker, into a terminal with sudo, or an apt-get gui, every application can listen to those input events.
And any program can (on a relatively default box) trace arbitrary programs under your gid and scan memory for passwords. The real issue here is that there are very weak process boundaries within a gid (because it is historically most convenient), not necessarily a lot wrong with X11.
> With X11, even a flatpak without any special permissions or bind mounts can still basically control your system. Just listen for input events until you see the keys "s u d o", then listen until you see something that looks like a password, then wait until the user is not paying attention, and inject virtual input events to start a terminal and inject input events to run "sudo rm -rf /*" with the password you captured earlier.
Why such complication? An hostile application can simply add an "evil" line to your .bashrc and you are fucked anyway. No need to keylog anything, nor the fancy stuff that you describe. It doesn't need to be a graphical application, even. The "ls" command can do it!
Flatpak runs applications in what’s nowadays referred to as container: the application can’t see any processes outside the container, can’t access any filesystem except for files you explicitly open with the application, and especially can’t edit your .bashrc.
That’s the point of flatpak. But as long as you use X11, there’s one single privilege escalation path left, and that’s the complicated one I described above.
> Flatpak runs applications in what’s nowadays referred to as container: the application can’t see any processes outside the container, can’t access any filesystem except for files you explicitly open with the application, and especially can’t edit your .bashrc.
That's just false. Flatpak has the ability to restrict access to such resources, but it's completely up to the author of a Flatpak application if they make use of it. Like my file manager and text editor are Flatpaks fetched from flathub.org and both applications have unrestricted access to my whole home directory by default, including my shell configuration -- even the Chromium Flatpak can do that by default.
Edit: I just counted, out of 30 installed Flatpaks from flathub.org 19 have full access to either my whole home directory or the host file system.
That's true, but not really relevant. The point of flatpak is that it can sandbox applications if just the right flag is set, but this sandboxing becomes useless on X11.
Long-term, all applications should strive to be properly sandboxed this way
Of course it is. Someone who read your comment and didn't question it might now believe that Flatpaks would enforce filesystem sandboxing and prevent, say some game, from accessing their shell configuration or ssh keys. That's false and it's dangerous, because nothing is worse from a security perspective than misinformed users who have a false sense of security.
> but this sandboxing becomes useless on X11.
That's also false. For example X11 provides mechanisms like the X11 security extensions which prevent clients from accessing each others data through the X11 protocol (like key events or buffer content), which means when I run my color picker or xev in a such an X11 security context they literally stop working outside of their own window. Firejail makes this type of sandboxing easily accessible and it also provides the ability to easily isolate x11 clients with xpra or xephyr.
So it's not like it can't be done, it's just that Flatpak doesn't care about it -- which is fine. With dbus you get the same issues, because clients on the same bus aren't isolated from each other. In this instance however Flatpak cared and implemented a dbus proxy to isolate clients from each other without throwing dbus away.
> all applications should strive to be properly sandboxed this way
I agree, but definitely not this way! The sandboxing details must be 100% controlled by the user. The people who distribute the application should have no say whatsoever about their required permissions. That's ultimately for the user to decide. From the point of view of the application, all files are visible, but it may be a mock filesystem with mock resources. Letting the application distributors chose the permissions defeats the whole purpose of the sandboxing.
What if I don't trust the person that sent me the flatpack container itself? A truly secure sandboxing should be a standard OS facility, not tied to a package distribution method. The flatpack/snap model is all wrong. I need to run arbitrary hostile applications in a safe manner, not only those that the developers have decided to distribute in a certain form.
Sure, but the flatpak model is a way to get these advantages for as large a userbase as fast as possible. If you use flatpaks without bind-home under wayland today, you’ve significantly improved your actual security already.
Sandboxing arbitrary badly behaving software is just going to use the same APIs as flatpak, so this helps for your use case as well.
All the hand wringing over root privilege escalation on Linux is almost irrelevant for most single-user systems, as since there's really only one non-root account which usually has all the data the user cares about, getting access to just that non-root account would be disaster enough for the user.[1]
So if Wayland's design is standing in the way of doing useful things because they're concerned about root privilege escalation, they've got their priorities mixed up.
[1] - not to mention that once a non-root account is exploited then getting root in some other way, even if Wayland itself can't be exploited, is usually not difficult.
The goal isn’t to prevent escalation to root, but to prevent escalation out of a sandbox.
If you sandbox an application today, while it can’t access the filesystem at all, and nothing under your user account, as long as it can show you a window under X11, it can log, manipulate, and inject any input events or window contents of any other windows as well.
That’s the one single big hole in todays sandboxes under linux, and there’s only two options to solve it: put a whole separate X server into the sandbox of every single application with X-on-X, or replace X. Which is one of the things wayland fixes.
I think the point about root is not so much about whether Xorg is run as root, but rather that any application can then elevate itself as root by listening to the key events to catch your password (for example when unlocking your screen) and then sudo with it.
> You're saying this because Xorg runs as root, which means that any security flaw in Xorg yields root access.
They're saying that because every app under Xorg can do keylogging they're effectively running as root, as any of them can keylog your root password next time you type it in.
I get the frustration, but fundamentally, screen sharing and screenshots are so integral to my daily use that I couldn't even consider wayland. For nearly any remote worker at this point, at least the ones I work with, this is fundamentally true.
In 2021, screen sharing and screenshots are table stakes.
Screen sharing and screenshots do work on wayland as long as the application is updated to support it. Electron only recently gained this capability so not all electron apps have updated yet.
No one will fault you for using X because zoom hasn’t supported wayland yet. The problem is people sharing blatant falsehoods like “wayland doesn’t support screen sharing” when there are plenty of programs that can do just that on wayland.
> Sadly, KDE still doesn’t support it nicely under Wayland (so I moved to Ubuntu Budgie), but under X11 it’s entirely impossible to run it properly, as except for Qt nothing supports mixed DPI, or mixed refresh rates properly.
Sounds like a roughly equivalent situation either way? Personally I'd sooner use only Qt applications than have to use Gnome.
I’m using (except for firefox) 100% Qt applications under Ubuntu Budgie (which is a bit like elementary but with Wayland support).
The result is good enough for my use case, I don’t have to deal with toy applications and I can use the full crisp resolution.
And thanks to standard protocols, I can use KDE software like KDE Spectacle as screenshot tool or screensharing with Slack, Teams, Jitsi under Budgie just fine.
> I’m using (except for firefox) 100% Qt applications under Ubuntu Budgie (which is a bit like elementary but with Wayland support).
If your only non-Qt application was Firefox, what was your problem under X11? Certainly for me having to switch to Gnome's WM/panels/etc. much would be more disruptive than switching browsers. (You might find Firefox valuable enough to be worth switching your whole DE for, in which case fair enough, but I don't think it's an objective advantage for Wayland).
(IMO Konqueror is a much better browser, but I'm sure everyone has their own preferences)
I’m a dev, and as it turns out, as firefox is more standards-compliant than chrome, if something runs in firefox, it’ll pretty much run in every browser (the opposite is not true, as blink has lots of custom extensions to the standard you might use accidentally).
Now why does wayland break screenshot and keyboard tools? Because "every program is a keylogger by default and can see any event, look at the contents of any window" is a major security issue, especially as it means the entire security model of screen lockers or containerized applications is useless.
OK, so what's the solution here? Give up on screen-shotting tools forever? Or is there a plan to fix this somehow?
There’s an API for that. e.g. KDE Spectacle uses it, which is why it can be used as screenshot tool under wayland no matter your DE.
But by making it an explicit API, you can also apply an include/exclude list to the programs allowed to call this API, and e.g. exclude sandboxed applications from taking screenshots. Or e.g. add a permissions prompt (as on android or iOS) for an application to request to be on that include list.
The solution is to make it a permission. On macOS you can’t just record the screen, you can open the OS settings page and tell the user to allow screen recording and now your program gains access to this feature.
This is definitely not entirely true of x11. I have mixed DPI (which, admittedly, does work for shit, but can be hacked around by using a wrapper script to launch things with different DPIs) and mixed refresh rates. The mixed refresh rates work perfectly, zero issues (as configured via nvidia drivers, admittedly annoying for other reasons).
That said I would use wayland if nvidia wasn't busy fucking everything up.
> but can be hacked around by using a wrapper script to launch things with different DPIs
I have firefox windows on both monitors, and like to drag tabs over from one to the other.
Under X11, doing so is either impossible, or requires restarting firefox, which really isn’t something I’d wanna do.
There was an old XUL extension for firefox to parse QT_SCREEN_SCALE_FACTORS and apply it instead, but that’s long gone. And normal Gtk apps never worked properly.
It's probably the mixed dpi because I've been using a Qnix overclocked to 96 Hz and a Vizio at 144 Hz, both 27" 1440p for a while and I get different refresh rates and everything works normally.
The question is then: is this isolation even useful? There are a lot of attacks that still exist when a program runs in userspace and that are not inherent to GUI programs. Example: creating an executable named sudo somewhere in a directory that is in your ~ and PATH.
Sure, but if you’re under X11, then a flatpak or any other jailed application can still trivially elevate itself to root.
Jailing applications only has a meaningful benefit whatsoever under wayland, as a flatpak without bind-home under wayland is actually properly sandboxed. Still a rare case, but at least it’s possible and getting even somewhat common.
Wayland is only one piece in the security puzzle. Flatpak and SELinux are the other pieces. Under X there is no point sandboxing a GUI app since X provides an escape.
And yet on every other OS, users can take screenshots and use virtual keyboards... It's not because X's security model is broken that the solution is 'we'll just remove that functionality'.
And yet instead of looking at sibling comments you asked the same question again, so I’ll have to answer it for at least the fifth time in this thread.
Wayland allows the same as well. It’s just an include/exclude list for such APIs, so you can actually limit which programs can access what.
Under X11, jailing GUI apps is entirely useless as there is no actual security boundary. Under wayland, you as user are in control and can define whether spectacle should be able to take screenshots (sure) and whether myflashlight-flatpak should be able to access all input events and take screenshots (probably not).
The author is kind of a jerk. He complains that users don't like wayland when he entirely and wholesale rejects anyone who wants to use an nvidia graphics card.
Maintainers with attitudes like this are why we can't have nice things:
Sadly, the OSS driver doesn't support the 4k monitors I use for work well enough to actually use day to day. So my option is to use an "evil" but very stable driver and no wayland to do my job and get paid, or not.
Drew Devault is an interesting character. I find some of the ways he chooses to express himself to be pretty poor most of the time. That said, Drew does come from a place of genuine caring, erratic, divisive, and brusque opinions aside. You just have to learn to filter out most of the useless anger and frustration he tends to speak with.
All that to say, nvidia doesn't really do the work to play ball in Linux with Wayland. There is no way to improve these drivers, you can only hope Nouveau can solve your woes.
> You just have to learn to filter out most of the useless anger and frustration he tends to speak with.
Or, here is a wild idea, we stop looking for some "wisdom" in what people who often express themselves this poorly write. Most of what this "thought leader" writes that I happened to read have the same punchline, and it got old pretty fast.
Sometimes, stuff is just garbage. You don't have to look through 99% of the garbage to find some 1% that is supposedly not as garbage.
I definitely understand that it's difficult to listen to people like this. If you feel that way, my recommendation is don't engage with his content. I certainly don't recommend Drew Devault's writing or projects to anyone precisely because of this. That said, I do still listen to him because that vitriol and frustration does seem to come from a good place and genuine frustration.
A lot of OP seems to be him complaining about that same behavior in users, which is straight up hypocrisy. It’s bad for his mental health when people do it to him, but he’s not part of the problem or anything.
Or you start buying a GPU that actually supports linux? If you buy a proprietary product with no actual linux support, then why are you complaining to the unpaid volunteer to fix it, and not the multi-billion dollar company you just made several hundred dollars richer?
It does support Linux, just fine, on x11... It's also the only option for a significant portion of machine learning software.
Meanwhile we (or at least I) aren't asking any unpaid volunteers to fix anything. We're asking them to stop claiming their new software works for practically every use case when it doesn't, nothing more.
Bingo! I’m also asking him to maybe be less of a jerk about it.
He complains about users not using his software while also (literally) saying “fuck you nvidia”.
Hypocrite much? I’m a former GNOME software foundation member and was on the GNOME sysadmin team. I literally used to have root on gnome.org. I’m not the enemy here, but I’m being made out to be one because I use hardware that OSS stuff does not reliably support.
In general I don't want to name individuals, because I don't think that's productive. "Them" is a convenient way of keeping arguments from being overly personal.
In this specific case I guess it is fair to say it's Drew, since he wrote the article we're commenting on. I don't think he's alone in his statements on wayland though.
CUDA is primarily developed for Linux. You’re showing me that you totally misunderstand the problem by assuming Nvidia doesn’t build these GPUs for Linux. There is a reason that Nvidia gpus + Linux servers top the top 500 supercomputer list. It is because they’re built to work together:
Nvidia supports exactly one use case on Linux: running their GPUs in servers or workstations purely with their proprietary drivers purely for ML and CAD work.
Everything else is completely unsupported, and if you’ve got an issue with that, you’ve got to complain to Nvidia, not open source projects.
You expect a single unpaid volunteer maintaining a wayland compositor alone to somehow be able to add support for nvidias badly documented custom format?
I don't expect anything from anyone, it's about what I need. I need Nvidia GPUs in my setup to run my trainings. If Wayland maintainers wants me to move on from X11 they will have to make it work. Right now they don't want to (which is fine!) but that means I can say I do not consider Wayland to be a viable alternative to X11 for me.
Precisely! And this isn't "anti-Wayland horseshit" so much as it is simply Wayland is not viable for your use case and mine as well. He insults nvidia, insults nvidia users, and then complains that people don't want to use wayland. Very unprofessional and laughable that he expects people to agree with his POV.
More than CAD work. I'm a little out of the loop these days, but as of a few years ago, Nvidia cards were greatly preferred for all 3D work, including animation packages such as Maya. The Nouveau drivers just don't cut it for that sort of work.
"Guy who tells me I'm an idiot for using hardware to do my job also says he is tired of users not wanting to use wayland" - I think he should read the book "How to win friends and influence people", because telling people they are idiots for using hardware they have to use and then complaining they don't want to use his stuff is pretty hilarious and pathetic.
I'm not asking him to suddenly love Nvidia, but there has to be some compromise here. Nvidia works wonderfully on linux for desktop + x11 (with 4 x 4k monitors mind you) and for CUDA. I'd love for the nvidia proprietary drivers to support wayland, but I'm also tired of his hyperbole about bad users who don't want to use wayland.
Not defending the author, but aren't you totally misunderstanding the fact that Nvidia providing excellent CUDA support is irrelevant to this conversation? The fact is Nvidia has a long history of providing the bare minimum to Linux desktop users, even on X11.
Hell, I can't even fix the screen-tearing or get Optimus to work with Nvidia's proprietary drivers with X11 on my GTX 1050 Ti Max-Q laptop. It may be 'usable' in a sense that it doesn't crash, but the number of graphical glitches that I run into every single day (literally opening my laptop requires me to refresh every window) that I never run into with Intel or AMD kind of proves to me how much Nvidia cares about desktop usage.
Drew Devault might be a jerk (not my words) and have a lot of fallacies in his arguments, but that doesn't mean you should be doing the same thing.
Also worth noticing, there are other operating systems that does not use the Linux kernel. FreeBSD does have an official Nvidia driver (although a pretty limited in term of framework suppot) and Nouveau is not ported anymore. The AMD drivers are a port of the Linux drivers and are usually some versions behind because it is work to port them. So it means that I cannot try out sway on my laptop, and as I am not planning to buy a new laptop in the next few years, it is not something I can try soon. Sure I can just run Linux and I do on another drive, but I just end up with X so I can share configurations.
I don't think Nouveau ever was ported before. I actually tried it myself (unsuccessfully). Kind of a painful codebase.
> usually some versions behind
Currently on 5.4-5.5, only Big Navi is not supported yet. With the state of the GPU market right now, we'll probably catch up before the prices on those become sane :D
Funnily enough, it's Intel that's slowing the updates down more than anything. amdgpu is rarely an early adopter of new Linux kernel API surface. i915 is very much one, all the time.
No, xf86 naming is still there, but you're kinda misunderstanding what a driver is. These xf86 things are tiny pieces for the xorg server. (Irrelevant with Wayland, obviously.) The real "meat" of the driver is in two places: Mesa and the kernel. The kernel module is the hard part. You can install the higher level parts without it, they just won't be useful. You can have the xf86 thing, and libdrm_nouveau, and Mesa dri_nouveau, they don't even require any porting, but they're absolutely useless without the kernel driver, they wouldn't have anything to talk to.
In their defence until a few years ago it was nvidia that had the good linux drivers while AMD was stuck with bad ones. The tables turned after AMDGPU as far as I know.
That’s true, but that’d mean running a 900 series Nvidia card or even earlier, which wouldn’t be able to handle multiple 4K monitors natively at 60Hz with or without the proprietary driver.
Which means that the author bought an nvidia GPU at a point in time when it was already obvious that nvidia would treat linux as a second class citizen.
And even if not, you should first complain to the company you paid hundreds of dollars to, not the unpaid volunteers.
Nvidia treats Linux as a first class citizen. In fact, the CUDA stuff on Linux is industry leading. As a result, machine learning on Nvidia is really good. I work with Nick Wilt, the author of the book on CUDA. Nvidia on Linux is amazing. Nvidia on Linux without X11 (for guis) is not, sadly.
> Or you start buying a GPU that actually supports linux?
People usually don't get to chose what HW the company buys for them and, anecdotally, "the component X doesn't work with Wayland" rarely makes a difference.
I've tried Wayland many times a year over the past 5 years.
Does it? I run KDE on my desktop PC with has a GTX 1080 inside it, and whenever I experimentally turn on Wayland, I get a black screen. Been like that forever.
> This work will hopefully land in time for the start of standalone XWayland releases separate from the xorg-server. Those should begin this spring in time for the Fedora 34 release as likely the first distribution shipping standalone XWayland packages.
> With this and other NVIDIA proprietary driver work pending to improve the Wayland support, hopefully by Ubuntu 21.10 we see GNOME on Wayland by the default so that for Ubuntu 22.04 LTS is also that shift away from X.Org.
"rejects anyone who wants to use an nvidia graphics card."
Yes this part is true.
"my option is to use an "evil" but very stable driver and no wayland to do my job and get paid, or not."
So what is the problem? That you can't have nice things for free?
As someone with an nvidia card, it rubs me the wrong way that he says “Nvidia users are shitty consumers and I don’t even want them in my userbase.”
If he wants someone like me to use wayland, that’s the problem. If he doesn’t want me to use it, then there’s no problem. But I think this guy isn’t just maintaining it. He’s evangelizing it too, right? Get rid of the old broken X11 and come to the promised land of wayland where we fixed x11’s woes. And if it doesn’t work for you:
> Maybe Wayland doesn’t work for your precious use-case. More likely, it does work, and you swallowed some propaganda based on an assumption which might have been correct 7 years ago.
He seems to be saying it works and you’re dumb if you think it doesn’t. And at the same time saying he won’t support maybe the most common cards out there.
So many comments here are missing the point of the rant. If it doesn't work for you, fine, move on. But it takes a special type of asshole to go around harassing maintainers and continuously putting down their hard work and in many cases just making overly broad and incorrect generalizations or propagating outright lies. There is a big difference between constructive criticism and what drove the author to write that rant in the first place.
It boggles my mind how people can be complete assholes to people writing FOSS because the sense of entitlement that users have when it comes to FOSS is staggering, and the more technical someone believes themselves to be, oftentimes, the more caustic they tend to be in how they interact with FOSS developers. Obviously this isn't the case for everyone, but having been a silent observer on Github issues for many FOSS projects as well as reading the rants on reddit and HN against FOSS technology <X>, it really pisses me off even though I have no skin in the game.
These are real humans and people devoting their own free time to build something they are passionate about and believe in. It may not work for you, you may even think what they are doing is a terrible idea. Then provide constructive criticism if you wish and move along. That's all too rare though. In reality, what people really want is they want Wayland (or insert Technology <X> here), but they want it the way they would wish it to be, and so they will essentially engage in negging developers and their decisions trying to beat them into submission. It's despicable behavior and no one should be defending this.
Measured criticism is fine, but then move the fuck on. Let people passionate about FOSS they care about, continue working on it. But don't be an asshole and keep trying to tear them down just because you selfishly want what they are building, but you want them to really build it the way you want it and to meet your specific use cases.
> So my new approach is “fuck you”. None of the Wayland detractors have a clue.
Lumping everyone who may not have a rosy view of Wayland together.
There's a good comment by an (alleged) pentester mentioning how Wayland doesn't really buy you that much. He's right. The bigger issue is lack of isolation within a gid. I can still debug your terminal and try to get your root password.
> Blanket lumping everyone who may not have a rosy view of Wayland together.
I think it's a lot closer to the author's intent to read the post as "here's what I'm experiencing" rather than "here's a category view of the world that I want you to endorse". Obviously a statement like "no one in [group] understands [thing]" is never going to be 100% true. When people say things like that, they're venting.
But in the same comment thread by the pentester, it turns out that what wayland does is a necessary step for security that X without embedded X sessions simply lacks. It is not sufficient but noone said so and it would be stupid to even assume that eg. a kernel bug can’t be used for escalation just because someone runs Wayland.
> It is not sufficient but noone said so and it would be stupid to even assume that
Err, no, a bunch of people who bother talking about Wayland propose it as a solution to everything. Now that they are being called out on it they are walking back their positions.
I don't need to demonstrate that. What I said was: Many people who are proponents of Wayland act like it solves all security problems you get while running X11. It doesn't.
If we were in a room of 100 people, and two folks got into a shouting match, everyone would start listening. And then a group decision would get implicitly made. Is it a personal argument, best to stay out of it? Or is someone getting attacked unfairly, and it makes sense to intervene? Everyone in the room starts watching, and everyone starts thinking about what the group is going to do.
Online is nothing like that. If someone behaves like a complete asshole on one thread, most people don't see it. Especially if the asshole is "some random guy" with no standing in the community. Since there's no real drama, the incident doesn't come to the community's attention. The person on the receiving end of the abuse never gets to have that moment that you'd have in a room of 100 people, where you know everyone sees you and supports you, and maybe you get some "points" for keeping your cool. There's no points for that online, just silence. I think it can feel very isolating and frustrating, and I'm not sure how to address it.
> “Wayland sucks!” is a conspiracy theory with no basis in truth, and its supporters have spent years harassing Wayland maintainers, contributors, and users.
See that "and"? Your comment here only addresses the second half of that sentence, which is probably true, and people shouldn't do that. Most of this thread is discussing the first half, which doesn't seem like it's actually correct. You can't say "people are missing the point" when he's making two points in the same rant.
There are pro-wayland people in this thread arguing the former point ("Wayland works for almost everyone"), and mostly they aren't putting up convincing arguments. So far I've seen: "it's really someone else's fault" (ok, in the meantime wayland doesn't work for me") -- "actually no operating system should support this" (ok, back to windows or apple or non-wayland linux it is).
> More likely, it does work, and you swallowed some propaganda based on an assumption which might have been correct 7 years ago.
> [Wayland] invented some new, fixable problems in the process — most of which have been fucking fixed already, and years ago!
> Most of the lies you’ve heard about ways that it’s broken are just that: lies.
The author didn't support these statements at all (which is the whole point of the rant, he's tired of doing that. that's fine). Someone else has to do that for this rant to make sense. So people are saying, "here is my common use case. how does it work on wayland now?" If they only thought it was broken due to lies and propaganda, it would be easy to explain how it's since been fixed. But people aren't.
This hits the spot. People are acting like Wayland developers are taking X and everything they liked about it away from them when in reality you can just continue running X if you don't like any particular Wayland compositor.
The Wayland world will continue improving and chances are your problems will be sorted out one way or another in the future. But attacking people working to improve the status quo without any obligations on your side is fucked up beyond reason.
> So my new approach is “fuck you”. None of the Wayland detractors have a clue.
Mmmmkay. That's a pretty broad statement, good luck with that attitude!
> I’ve tried appealing to reason and rationally debunking each lie that some Wayland detractor flavor-of-the-week is touting to tow the party line, but it didn’t work.
The 'wayland sucks' movement is sooo annoying, even to me and I'm just a happy wayland user and haven't spent any of my free time writing those thousands of lines of code.
What are you hoping for? Someone to drop down and teach you how to do everything on wayland? I have no idea how to do keyboard automation on X11 but that says nothing about X11. This is the problem the post is talking about. Every single thread about wayland is filled with “but it can’t do Y” when it is possible to do Y.
Yes, he fancies himself a modern Stallman and spends that reputation on content-free rants like this, that an increasingly dwindling audience understands and cares about (HN notwithstanding, who largely eats up his posts on authorship). Spending your life hacking on Wayland when the world has pretty conclusively assigned capital to headless Linux use cases does speak for itself, yes.
Divisive pieces like this make that worse and shrink the TAM of desktop Linux even further, so it’s an oddly self-defeating position to have. I’m not sure comparing detractors of software to people who believe thousands of people died in a false flag operation is defensible commentary in any light nor that this community should be giving it an audience.
Which is what, exactly? Giving someone who compares disagreements over software to literal conspiracy theories a platform? The content doesn’t even fit your guidelines for intellectual interest. It’s a hateful, harmful rant with no substantive discussion. It’s literally flame bait, as evidenced by my showing up, but I don’t see you making any moves to remove the post despite it being voted up as much as my comment was. Nope, just “we are trying for something else” when someone doesn’t tow the line.
But you’re right, I’m the problem for responding to a fawning endorsement of the author with a very moderated opposing view. My bad. I’ll do better on the next account.
Of course the article doesn't meet HN's guidelines, but that's no reason to break them yourself. These are two separate issues.
Commenters routinely underestimate the amount of flamebait in their posts by 10x or more—it always feels like the other people are doing worse. No one would objectively describe your posts in this thread as "very moderated".
> Spending your life hacking on Wayland when the world has pretty conclusively assigned capital to headless Linux use cases does speak for itself, yes.
He has worked on projects other than wayland.
Sourcehut is a notable example: A free github alternative that has great e-mail integration. One of the amazing features is that the UI uses no javascript (pure server side python) and is super fast.
Why do you care so much about what someone else decides to spend their time coding on? Man, people criticize the weirdest things sometimes.
I for one greatly appreciate a lot of DeVault's work. Do I think he has the softest way of expressing his opinions? No. Do I need him to in order to appreciate the technical merits of his work? No. I'm not looking for a life partner – I'm looking for excellent software.
Acting like an arse is not the way to get your point across. Wayland definitely does not work under every use case, but claiming that anyone who does have issues with it is a conspiracy theorist is wrong
Guess what, you're using linux, and these things take time to develop and be adopted. That's the way linux always has been, you trade off less than perfect software for the benefit of endless configuration.
Wayland will be widely adopted one day, but insulting anyone who has issues with it does not help your case.
One thing I rarely see discussed - and one of the reasons I don't like Wayland personally - is the second order effect of putting everything in the compositor: It is now really hard to write a "window manager" or window tools. And this leads to a certain uniformity of desktop environments (the big ones, GNOME + Plasma, and then a bunch of keyboard driven minimal environments "for hackers")
What I mean is, back in the day with X11, all clients were equal and there were nice little tools that let you switch between virtual desktops graphically (desktop pagers). I myself wrote a little taskbar (with the kind of glow animation that moves with the cursor that Windows 7 made popular), but never published it unfortunately. A lot of people wrote or hacked on window managers. It was never really easy, but at least it was possible.
Now with wayland, you have to write not only the code that draws the titlebars, but the code that puts the pixels on the screen, input handling, clipboard handling and all kinds of stuff.
Of course you can fork an existing window manager, or use something like wlroots, but they are all opinionated. If you just want "GNOME with different titlebars" someone else wants "KDE with different titlebars" - you're out of luck. So this makes the barrier to entry really high.
On the other hand, if somebody would write a "window decorator" interface, you could write a small window decorator process (like we had with Compiz). I don't believe this will happen, because it would have to be adopted by multiple compositors to make sense. If it did, I would have a bunch of ideas I'd like to try out one day.
“Putting everything in the compositor” isn’t mandated by Wayland at all, and I think only gnome does it. If you implement the protocols defined by Kwin, you can reuse everything in KDE without using it. Yes, it’s a lot of work, but properly implementing it on X11 also is more work than you would expect. The only problem here is politics, as KDE hasn’t stabilized the interface as far as I know.
Wlroots isn’t opinionated at all. In theory, it’s perfectly possible to write a gnome shell alternative using wlroots. Writing a taskbar for nearly all wlroots based compositors is also possible.
You could even write a plugin for wayfire to implement the Kwin protocols, and write another plugin to implement a simple window manager.
As for changing the titlebars, as long as you enable CSD, you could just write a theme.
Dear god, Drew has spicy takes but this takes the cake, comparing anti-wayland sentiment to 9/11-truthers is quite the comparison. Not sure I can stomach reading past the first sentence.
I only developed on smaller FOSS projects but can tell you this blogpost ist just an abyssnormally small piece of the hate you'll get for changing things.
I think Wayland has come too close to the following pattern, which I've seen in other cases of free software which have become controversial:
- decide it's time to make a New Thing which will supersede the Old Thing rather than living beside it
- decide that some features of Old Thing will not be directly supported by New Thing; instead New Thing will be flexible enough that people could implement those features on top of it
- declare that the work done to support those features will have to be done by the people who want to use them
- declare that the time has come for New Thing to supersede Old Thing, before said work has been done
[Edit: this wasn't intended to be a list of things that are individually bad ideas. It's only the last, in combination with the others, that I think is ill-advised.]
This is exactly the kind of post that the author was talking about.
"decide it's time to make a New Thing which will supersede the Old Thing rather than living beside it"
A non-substantial argument. Whats the difference between a wayland 'superceding' X and a wayland 'living besides' X?
Does implementing Xwayland not constitute trying to 'live beside' it? your argument is vague and you can respond with more ambiguity. Install X and wayland. Nothing stops you.
"decide that some features of Old Thing will not be directly supported by New Thing; instead New Thing will be flexible enough that people could implement those features on top of it"
WHICH features? the 'old thing' can never equal the 'new thing' otherwise they would be the same. Wayland is purposefully LESS flexible (again, how is wayland more flexible? Or is that another vague statement?) in its input handling and screen handling which is why screen recorders needed to be reimplemented in the name of security.
"declare that the work done to support those features will have to be done by the people who want to use them"
How is this controversial? You seem to ascribe some kind of motivated reasoning for the statement that certain features aren't being maintained/developed by wayland developers. Dev says 'no' to a feature request, why is this controversial? EGLstreams is the closest thing to a controversy but nothing prevents anyone from forking and implementing support. Open source, no excuses.
"declare that the time has come for New Thing to supersede Old Thing, before said work has been done"
> - decide it's time to make a New Thing which will supersede the Old Thing rather than living beside it
That doesn't really describe the situation very well, seeing as XWayland works seamlessly. Wayland compositors very much support living beside X programs.
Equating between flatearthers/antivaxers and criticism of Wayland has got to be a prime example of False equivalence [1].
This style of argumentation is as bad (if not worse) than baseless rejection of Wayland because of "vague" criticism.
If I try to read between the lines, the author is worried that if more people don't jump ship and switch to Wayland, suffering through whatever trouble they might face, Wayland won't get better faster. Which although true, is a very selfish argument that does not see beyond the author's own use case.
I'd like to try Wayland sometime, so far I haven't. I don't think there will be a lot of issues that I'll have to get around, but honestly I'm not looking to find out right now. I use Xorg and I'm happy. At some point, I'll try Wayland.
I don't hate Wayland. But every time I use it random things stop working, so I'm sticking with x11 for the time being. I'm a firm believer in "If it ain't broke, don't fix it".
I have been attacked for daring to say that software can be finished. Maybe it is my fault for not having said explicitly that it does not mean that they do not get 1) security patches, 2) compatibility patches, 3) bug fixes. That said, I have been attacked for using X11, too, which pretty much works for me and has worked without an issue under Arch Linux for years. It just works, and Wayland would not because my window manager does not support it. I do not blame Wayland for it, of course, but I think many software that I use have no Wayland support.
I have been attacked for using irssi, too, instead of weechat. They still hold the view that it is not maintained despite showing them the commit history. Crazy. Make no mistake, I am not complaining, it is the Internet after all.
It depends what level of broken is okay with you. X11 by design allows any application to see what you type which I would consider broken and a security risk.
It's really rich when these types get riled up about software having very obvious flaws. I respect the author and really want to like Wayland, but there's big things missing.
I recently installed Fedora after my Windows install bombed out after an update. I went to play World of Warcraft with my buddies and found that the mouse handling in Wayland was pretty severely broken, at least for WoW. You move by clicking both of your mouse buttons, which starts moving you forward, and then you turn your mouse to steer. Under X11, your mouse is in the same place after you release your buttons (this is the intended behavior). Under Wayland, only god knows where it's going to pop up; it seems to be following your mouse movement while you turn, but not exactly. I said "whatever, it's a good thing I don't play too much WoW" and made peace with what it was.
Then I went to share my screen. I couldn't. Total showstopper -- I use this functionality every single day, and I can't part with it. Wayland is officially off the table.
I've been using X11 since. Everything has worked perfectly. I'm not going to suffer through some software that I actually need to use under WINE having fucked up mouse handling, or hold out for multiple years before I can share my screen again. I can't imagine even attempting taking Wayland seriously if I had Nvidia hardware. If somebody's take is that I should go fuck myself for expecting things to work while they tell me that my other options are wrong and bad because it works for "most people" (which is pretty stupid -- even Average Joe has a lot of showstoppers, it's why the Year of the Linux Desktop hasn't happened), they can have fun dumping time into software that's inferior in many regards.
EDIT: in response to Drew's flagged and dead comment (which I feel is quite unreasonable, he brings up a point about the compositor having some responsibility here too) -- I am not using Wayland under GNOME -- I switched to KDE and spent a fair amount of time digging through DE, WINE, and software settings trying to get these things working. I'm willing to slog through a lot of shit to get the technically correct solution, but some bridges are too far. I'm not changing my entire DE, GPU, software choices, etc. for the sake of using Wayland, even though it's superior to X11, and I think that's what a lot of proponents of it are missing.
You ignored two really important parts of my comment.
>"I said "whatever, it's a good thing I don't play too much WoW" and made peace with what it was."
and
>"I'm not going to suffer through some software that I actually need to use under WINE having fucked up mouse handling,"
I can't even play video games properly for the two hours a week that I do it. I'm not waiting for an actual headache to crop up.
When using X11, I don't have to make compromises. I have better things to do with my time, and I'll reconsider in three to five years when the situation is hopefully more stable. Mixed DPI sucks on X11, but at least works to some extent, even if pretty shittily. Worst case, you can just buy compatible monitors, like you have to do with GPUs when you're considering Wayland support/stability.
> Look, if it's ok to say don't buy nvidia graphics cards and expect to use Wayland, why is it not ok to say don't buy mixed DPI and expect to use X11?
It’s still a hard sell when everything just works on Windows and macOS. It’s yet another reason why someone won’t pick up Linux when 90% of the features they want are present.
People complain about mixed DPI all the time on macOS and Windows too. It works better, but it still doesn't just work. If you want things to just work, you'll have less fiddling to do if you get similar DPI monitors.
Well, I think that saying works better is an understatement.
On windows I just plug my external monitor with regular DPI and it auto-recognize that this external monitor have regular DPI and size it acordingly while keeping the HIDPI of my laptop perfectly untouched and also auto recognized.
While on xorg, goodluck with that.
On Wayland it works, but require manual intervention of enabling fractional scaling and setting everything manually.
Screen sharing is a pain, I did get it working on Arch finally though, but it's still a pain at this point. And I only got "screen" sharing i.e. not "app sharing" or "monitor/virtual-monitor sharing" working. Latter part could well be some more config or tweaking I need to do, regardless it's not the users fault if they can't figure this out in Wayland when it works fine everywhere else out of the box. I've gotten it to work well enough for my personal use case but it's definitely not far enough along for the typical use case.
X11 isn't that great with monitor setups with multiple DPI. It's certainly one of the biggest user facing "wins" for Wayland but much like you dismiss playing WoW as something you don't do most users don't deal with mixed DPI setups so the biggest "win" really doesn't mean much to most. That doesn't mean it can't be a great reason for you to prefer Wayland though.
Sway won't even launch on my Nvidia computers so I've just got them running Windows with WSL. I don't think it's X11/Wayland's fault on this one, Nvidia is just a bit too locked down when it comes to Linux preventing good support from anybody. At the same time the professional hardware is just better so you don't always have a choice to just use an AMD card even if you were willing to change hardware for better support.
I really like my Wayland setup but it's important to understand the tradeoffs I was willing to make and the efforts I was willing to put in don't mean Wayland was perfect it means it was better for my situation. For another user it's probably a HORRIBLE fit right now. That's not their fault, nor anyone else's fault, it's just a difference in use case.
I think Wayland is getting pretty close (particularly for the less stubborn willing to let xwayland run as well) to being ready for most users but that's what many have been trumpeting for 5 years so it's created a bit of pushback when you say it is now.
To be honest, it was not a complete dismissal on being able to run wow under wine.
In my opinion neither x11 or wayland is perfect both brings huge amount of pain. Whereas wayland brings the least amount of pain for my usecase and shows the only prospect of improvement.
If I were a sensible person I would just use windows with wsl where’s absolutely everything just works as intended and there’s no tugwar. But I’m too stubborn for that and I hope I will one day install Linux and everything just works without having to do a extensive research for compatibility and workarounds
I'm not even a wayland developer and I get annoyed by all the posts about wayland not working, I've been running it for years and it Just Works(tm) for me aside from the occasional gotcha.
The funny thing about your funny remark is that the inverse is used as primary anti-wayland argument.
Oh no, a single thing doesn't work yet, the entire system must be fundamentally broke for everyone. Definitely not just a bug or feature someone hasn't gotten to yet, no no.
If anyone wants to keep using X, they're free to step up and maintain it. So far no one has been willing.
I don't understand the point about maintenance. Is Xorg maintained? If so, are the current maintainers handcuffed to it? I assume they aren't, so what's the problem? If Xorg is not maintained, again, what's the problem? Software is known to outlive its creators and maintainers. If there's a need, it will eventually get new maintainers. Software is not magic.
X is barely maintained anymore. To a large extent all of the X developers are working on Wayland now. A lot of people have the impression that Wayland is some outside competitor to X but the truth is that the vast majority of the people who started Wayland are long-time X developers who know its flaws inside and out.
Sure, I can understand people working on software X for a long time getting fed up with it and start working on software W.
I can also understand that these people have strong opinions on why W is so much better. The only trouble is that others, who are possibly not developers of window systems, may not care, or may find that it breaks their software, or may not want to write software that depends on W and doesn't work on X.
So what if Xorg is "barely maintained"? It works. Hell, as long as it works, it's likely better for it not to change. If there are issues, in the free software world we say "patches welcome". No developer should feel chained to a project.
Why would Xorg users care about XWayland, or new releases or contributor patches?
Those who contribute to Xorg and feel stuck could step up to maintain it, if they wish. (Don't they do it already?)
If they don't wish to maintain it, maybe their contributions are a waste of everyone's time? (Then again, maybe they get paid to do it, in which case it's their money-misery trade-off to make.)
Over time, Xorg users may indeed need fixes. Then, I'm sure someone will step up.
Welp, as a user of Xorg I'm fine with what I have. You seem to be playing on both senses of Xwayland both being Xorg and not being Xorg, but Xwayland will continue to be irrelevant to me.
You say "now or never" but I've no idea what you're talking about. Your reply makes zero sense. If there's any trouble in the future, I'm sure someone will step up, as I said.
You have no idea what I am talking about because you don't engage with upstream Xorg and seem stuck in a "works on my machine" fallacy.
Your attitude to the problem is a big contributor to Xorg upstreams demise.
The biggest is, of course, that none of the maintainers wanted to deal with that dumpster fire anymore and jumped ship, and no one in the know is dumb enough to pick up the torch. But, a delusioned userbase is very unhelpful in recruiting new blood.
No, but Wayland is not a bit of software you even think about until it goes wrong. That means the internet gets disproportionately filled with posts about Wayland not working, which presents the wrong image.
When reading up on what desktop environment to use, it's hard to get a balanced view unless there are commenters like this, saying that running Wayland works.
> No, but Wayland is not a bit of software you even think about until it goes wrong. That means the internet gets disproportionately filled with posts about Wayland not working, which presents the wrong image.
Kind of like reverse survivorship bias. The only wayland sessions that get attention on the internet arw the ones that don't work.
This is confusing - "works for me" is a common joke. The point of that phrase is usually that it is not a good reason to minimize those for whom it does not work.
As someone who has no experience with Wayland: What are the telltale signs that a problem is related to Wayland and not the application itself?
I've gotten curious. I want to try Wayland in the near future. But it would be good to have an idea of what kind of issues I might encounter, so that I can change back to X11 in an emergency.
I don't think there is really much. Most of the bugs you will see stem from software having a different codepath for each. For example I know that drag and drop is a little buggy on Firefox under Wayland not because of the protocol, just a state management bug that they are trying to track down. (however Firefox still uses XWayland by default so it isn't really relevant anyways). But I suspect we are roughly around the point where the X codepaths, while more battle hardened, are probably starting to rot so the current state you are probably getting the sameish number of bugs under each (AKA applications are differently broken under both).
If you are seeing a bug I guess just try the other one out and see if it reproduces, but I can't think of the last time I did that.
The only thing that is a common issue is screen capturing not working. If you have PipeWire setup it will work for most applications but it is still quite new. So if something related to screen content grabbing is not working it could be a Wayland triggered bug.
So far every single complaint I have seen about wayland is something that wayland actually supports but that a specific program hasn’t been updated to use yet.
No one minds what you use, it’s the people who go online and post complete lies about what wayland is and what it is capable of. And then they feel entitled to tell other people that they are wasting their time on wayland instead of working on X12.
Well, people _are_ entitled to telling other people their thoughts. You say "complete lies" but it's not black and white. This devault post is an emotional hyperbole, and you're just dragging it on.
I'm writing this from my Fedora laptop where Wayland works extremely well. I want to say thank you to all the developers behind it!
I know that the process of moving to Wayland has been slow and hard. It is definitely not an easy task. I know it's frustrating when something that used to work does not any more. I know the process is not complete and there are still a few things that might not work well. But for god sake, these people are volunteers. Stop bullying them with angry posts complaining about their work. You likely don't pay a penny for all this great software that you are using. If you think that X is better, just use it, and live with its unfixable issues. If you don't like distros moving to Wayland, contribute the packages to keep using X, maintain X, these guys are offering you the keys! Please stop shitposting about the work of people trying to make things better.
Apple breaks things all the time and they don't get half of the heat. And they charge a lot of money.
> If you think that X is better, just use it, and live with its unfixable issues.
Out of curiosity: What are those issues with X? On my day to day use of Xubuntu I don't encounter any problems. What would I gain from switching to Wayland?
When you plug your laptop in to a 4K screen it sets the 4K screen at 200% scale and the laptop at 100%. When you move windows over the screen border they switch scale. On X you either have to pick one scale or have windows die and be spawned again on the next screen
Can't say I like the attitude in this post. It seems to me that either he thinks that criticism on the software is criticism of the developer, or he spends too much time reading posts by people using the kind of language he's using.
There will always be people who'll criticize what you do, especially on the internet. You can't let it get to you.
However bad people think X11 is, the engineering decision (or more likely lack of any intentional design decisions beyond the initial extremely narrow use cases?) to "replace" a huge portion of its functionality with windowing toolkits is a disaster for open source. I have written about this before, but the amount of waste and rework that it induces is completely unsustainable. If you want to see another generation wasted in the bazaar then stick with wayland. Wayland is very good at the use case it was developed to serve, which is fast booting systems for automobile backup cameras. Everything beyond that is at best an afterthought. Forcing dbus on everyone to replace xlib is like chopping off your legs because you heard that you can run faster with the new carbon fiber prosthetics -- it will work fine on a track, but the second you try to go hiking off the trail with boulders you will fall and break your skull.
Gnome developers are the ones advocating for “dbus everything”, wlroots prefers wayland protocol extensions.
And since no one company is behind the linux ecosystem, everyone works on what they want to work on, so every change is fundamentally starts with chaos in linux. But it will stabilize on a good enough solution (eg. I don’t see much ill with the current 3-4 implementation of the protocol with one of them being a minimal “lib”, that can be used for small niche window managers to build on)
Ubuntu 20.04 probably had good reasons not to ship Wayland as the default. I think this because I've had the experience of using OBS in Ubuntu 20.04-- which works-- vs OBS under Debian buster (using Wayland by default)-- which, as of two months ago, didn't. And I wasn't even looking for differences here-- just that my workflow got interrupted on Debian because of this problem. I'd wager there are surely other such outstanding issues with Wayland as the default.
The issue I ran into is being fixed-- or perhaps is already fixed-- which is great.
I'm not anti-Wayland. I'm also not a Wayland developer, or Wayland fan. All I know is it's supposed to replace another part of the stack that I don't develop or give a shit about. To the degree that things don't break when that happens, I'm happy. When they do break, I will be temporarily frustrated.
I generally like wayland, and on systems where I can use it, I use it. I'm even writing my own compositor for a side project on embedded hardware because Wayland (the protocols) better defines the roles of parts of the software and has better performance.
Functionally, though, Wayland is still not fully there yet. It's better now than it ever was, but the authors are still punting on major chunks of missing functionality.
> We’re out here trying to make things better. Wayland fixes unfixable problems with X11, and might have invented some new, fixable problems in the process — most of which have been fucking fixed already, and years ago!
Keyboard remapping has been punted on entirely and is still horrifically broken and undefined in the protocol definitions. Despite this, compositors still to this day, use XKB as the basis for keyboard input mapping because there is no standard way of doing this for a compositor. Even wlroots does this. This is a really bad workaround to the problem because XKB itself was an incomplete rewrite of the existing keyboard mapping code in the original X11 server, and even it doesn't work right, which is why Xorg desktops have awful things like ibus.
Full nvidia support is nonexistant except with nouveau, which often doesn't work correctly for basic 2D graphics. Obviously this is out of the hands of the wayland devs, but for a user it is still major functionality that is lost, and pretending that nouveau is an equivalent replacement is problematic -- I've had generic VGA drivers perform better. And "perform better" in this context means "managed to draw a coherent image to my monitor", not "maintain 60fps".
There are other features/problems that have also been punted on (remoting support, but that arguably doesnt belong in the compositor stack) that users actually need in some cases that wayland devs -- probably because of the rush to get rid of Xorg -- have avoided implementing. I get that it is hard, and major kudos for the progress that has been made, but Wayland is definitely not there yet without some coherent answer to these features. I say this as a user and a dev using wlroots.
People are dicks to maintainers of X11-based software too. I think people are just dicks.
It's one of the reasons I love stale closing bots. I don't have to pay attention to people who are dicks. I can just unsubscribe from their issues and let a bot handle it.
Okay but why not close angry issues immediately with a cookie-cutter response and avoid stale closing bots? Stale closing bots also have the tendency to close real issues just because nothing has changed regarding the issue in a while.
Because it's hard to write a "you're being a dick" cookie cutter response for every possible case. People are dicks in a huge variety of ways. I don't enjoy figuring out prose that won't offend people, I enjoy writing and reviewing code, so I do that instead.
No solution is perfect, but this one keeps me sane.
I always found systemd to be fine (I'm not a sysadmin, just prefer Linux on my PCs).
PulseAudio did have some growing pains, though. I don't remember them exactly, but I remember having to tinker way too much to get apps to work together/correctly between ALSA and PulseAudio, etc. I still have a finicky laptop that REFUSES to do audio over HDMI unless I boot the machine with the HDMI cable plugged in already.
This is not a systemd issue per-se. Whatever process it’s trying to stop is taking its time. Systemd doesn’t explicitly know what to do and most likely falls back to a reasonable compile-time default.
The other comments already explained how to change the timeout per-unit, but I wonder how would you want a “perfect” init system to handle this?
Hang forever until the process dies without any message (as far as I know this is how legacy shell-script-based inits would handle it)?
The Windows behavior (prompt the user to kill anything manually) seems like the ideal behavior. Of course, this is tricky wrt dependency issues (e.g. if remote, you need to keep sshd and its dependencies alive in order to implemnent such a prompt), but hanging forever seems like a preferable fallback.
And that is the responsibility of the display manager (and it is sort of what happens under gnome).
Systemd had as default KillUserProcesses (it may not be the exact name but it was something like that, I didn’t check it) set to true, and that caused many to hate on the whole project because I don’t know tmux and other apps that override the “normal” behavior on signals lost their sessions. So now it usually defaults to false, though I tend to override it to true.
The thing is, “with enough users someone will depend on both the public and private parts of your APIs” is true (and I am sure I butchered up this quote as well)
See, this right here is the (technical, not social) problem with systemd. Whether anyone points out that systemd is doing something stupid and wrong, the systemd shills' answer is always "well duh what did you expect when you didn't modify one of the hundred default configuration files to have `[stupidshit] = false`! You brought this on yourself!" And you're lucky if that even works to solve the problem.
What's stupid or broken in waiting for a service to shutdown?
I mean Slackware used to send a SIGTERM to all processes, wait two seconds, and send a SIGKILL. Why would anyone need more? It's the Unix way (except it isn't).
If you disagree with the default wait time then you disagree with the default wait time. So what.
On this particular issue I find it hard to fault them for using a (perhaps overly) safe default.
Summarily killing processes with a SIGKILL should really be a last resort because it can very easily corrupt data.
If you have processes which just hang for ages during shutdown, there is probably something wrong with your system (or the process's code) which might warrant further investigation.
I don't disagree, necessarily, but ACID[0] is/was quite expensive for (usually) marginal gain. These days, I'm sure it could be done a lot more efficiently (with SSDs and such), but the fact is that there's no real way to do it using just POSIX syscalls. Applications literally cannot 'signal' transaction boundaries wrt. file system writes as it is. The APIs simply aren't there.
Only if you care deeply about always having the latest data, rather than just consistent data.
I'm talking more along the lines of ZFS – I can always pull the plug without worrying about FS consistency, because the FS always goes between valid, consistent states atomically.
True, and you can even turn data journaling on. The problem is... what is an "atomic write" from the perspective of an application? There is no POSIX interface for that. Of course making a single 'write()' syscall atomic, and so forth is a good thing, but... that's not an application level 'transaction' necessarily. Libc has buffering between fwrite and write... that's pretty arbitrary (fflush notwithstanding). Also: Dirty read (A) -> Writes that are committed, but the data read (A) doesn't get committed. Uh, oh!
The problem is a thorough lack of semantics on file systems. It's the wild west.
ACID was a good start for databses, but even that is pretty vendor specific in the specifis... and nobody truly understands the basics of it anyway.
It's just another init system to me. I don't really care enough about it to get upset and complain that I had to read some documentation and edit a text file to change its behavior.
I don't, Bluetooth works smoothly, I can easily set audio per app, audio flow from BT headset to speaker when I turn off the former, nobody hears me badly in videocalls and a large etc. The only think it can be improved is the plugins management with some neat, optional GUI.
That's because all three are similar, all three throw away some of the modular unix philosophy and replace it with a system that gives less power to the user.
Sorry which modular unix philosophy is Wayland replacing? X wasn't modular except by the most generous definitions. X is a weird server that does way too many things and the window manager where the interesting logic was. These days the building blocks have been broken out allowing much more flexibility.
If you think that the window manager was modular component you can basically pretend that wlroots is X and the compositor is the window manager. It is just as modular with that logic except more efficient and capable.
Xorg didnt define policy, which is why things like window management was offloaded to the window manager process. Look and feel was also not part of the policy of Xorg, and was defined by the widget sets, window manager, etc.
In the wayland model, these previously modular components that communicated through process boundaries to cobble together those policies that make a desktop are typically subsumed into one process called the compositor. Look and feel is still the domain of the widget set, but window policy is not.
Right, and nothing prevents you from writing a compositor that talks to an external process to handle window management. It just happens that no-one does it, because it's insane and difficult to make work properly. The compositor's job literally is to juggle the clients' buffers, which includes deciding what gets drawn on the screen and how.
There are other processes involved though where the compositor and the client do talk the Wayland protocol via IPC, such that the compositor hands off various responsibilities to external processes.
As far as I understand, X11 ended up with the window manager architecture pretty much by accident; initially, window managers didn't even exist.
I may be mistaken, but PulseAudio doesn't seem to fit that definition at all. Pulse allows for a lot more functionality and modularity than ALSA, the problem people had with it was that it was just really really buggy when it was pushed as the default in a lot of distros.
Your use of "was" here is sadly, incorrect. PA is still horrifically broken on simple PC desktop systems I use (with integrated AC97 audio, btw) and on custom embedded systems I have integrated new sound chips into.
I regularly have to open pavucontrol to fix basic things like "where output audio streams are routed to", fight with audio frequency rates, etc. On new embedded designs, PA is often the bane of my existance because of the insane heuristics it runs to figure out audio policies and mixer/routing behaviors. Even the major desktop environments have trouble trying to integrate with the blasted thing.
PA is still hot garbage, straight from upstream source.
Was or is? Is, afaik, pulseaudio causes movie players to freeze when using USB audio, I have to use a bluetooth transmitter with 3.5mm jack instead to completely isolate pulseaudio from my headphones so that it doesn't wreak such unwanted havoc
That's not true for Wayland I think, Wayland is much closer to the Unix philosophy of doing one thing and doing it well: it is a (library implementation of a) local display protocol, and only handles input redirection and display configuration. It uses the kernel for device management, and puts clients fully in control of their own canvas through OpenGL.
It doesn't do output configuration, input management, application window drawing, font rendering, or remoting, all of which X did itself (although modern application rarely made use of that part of X). Those things are delegated to the kernel or to application libraries.
Nah, the thing common with them is that they are pushed onto us instead of being provided as an alternative and then left to win out on their own merit.
The modular linux philosophy is great, but it is quite obviously not the optimal solution to all problems. Some problems are better solved in a non-modular way.
Not the OP, but I'm on Fedora 33, using Gnome with Wayland (the default) and I have no issues taking screenshots (using PrtScn or Ctl-PrtScn or Shift-Ctl-PrtScn)
I agree that all three are aggressively Linux specific, but let's be real. From a market share perspective Unix is dead. Linux itself threw the Unix philosophy out the window some time ago.
It's what I like and use it for though, so please allow me to dislike those systems. If I wanted to use an OS that decides things for me, there are enough other choices.
> In the case of Wayland, the “vague authority” are a bunch of volunteers who have devoted tens of thousands of hours of their free time towards making free shit for you.
This argument is plain and simple abuse behavior. The people criticising Wayland never asked you to make free shit. They have no obligation to like it or to not voice their concerns when they might be impacted by your free shit. If you don't want to hear criticism of your free shit, get off the internet.
> It has a real cost, you know, being a dick to maintainers.
Same goes for being a dick to your users (especially those who didn't choose to be your users) or random people on the internet.
> [...] Most of the lies you’ve heard about ways that it’s broken are just that: lies
Ah yes, shouting "fake news" works so well.
I'm not even anti-Wayland really - it simply does not provide any advantages for me at the moment while breaking some things - but this kind of attitude makes me not want to touch it.
I am neither fond of Xorg nor Wayland. I have used both and I see shortcomings of both.
Xorg is Overly Bloated/Done without giving much importance to security.
On the other hand, Wayland is technically superior , might be more secure than Xorg. But, it's feature parity doesn't match with that of Xorg.
Now,i don't think those features must be pushed into Wayland itself. i don't know but something desktop oriented Wayland implementation with those missing pieces filled would be good idea.
But, will security suffer? Maybe. For example, Wayland is said to be secure because window can't see other windows. But, necessity arose due to requirement of Screen Recording so some API was created to access The Screen. So, didn't it make that security claim irrelevant because each window can access the screen? i think it's still not thought out properly.
Once upon a time, I had to write a system where the rendering architecture was broken up into an engine that ran in a separate service, and the pixels were then dumped to windows owned by client programs. Long story, it seemed like a good idea at the time.
Mac OS X had a very secure graphics architecture where no program could emit pixels into the window content of another program. As a result? We could barely support OSX. We ended up having to do rendering to pixel buffers and then using mmap through an invisible file shared between the service and client, then dumping the contents of the pixel buffer straight to screen using some code every client ran. Rendering from graphics card to RAM back to video buffer cost us half our frame rate.
On Windows? Client program passed its HWND to the service. Service bound an OpenGL target as a child of the client program's window.
Security is important, but in a graphics service, it creates a solid trade-off between what is possible and what is safe. That HWND trick can definitely be used to fake a login window and steal user passwords. But it also allows some programs to run on Windows that were technically impossible on Mac OSX without a complete rearchitecting.
(Clarification: I've gotten out of the game of writing Mac OSX software, but if I understand correctly that trick is possible under the modern architecture. It turns out Apple needed the ability for one program to write into another program's windows directly because they architected QuickTime as a service and performant video display required a similar trick to the one we were doing. So they added a mechanism for two processes to describe a shared rendering target to Quartz).
> So, didn't it make that security claim irrelevant because each window can access the screen?
No, because these APIs allow the user to audit the requests and allow or deny. You could have a default-allow policy and get back to the X security but most implementations ask you to confirm first.
It’s more of a future feature. Until we have most things sandboxed with SELinux there isn’t a whole lot of point adding a permissions dialog. But all of this work pays off in the future when Linux can match macOS in security.
Ok, here is my use case that wayland doesn't work for. I have an AMD graphics card (5700xt) and two 4k screens. I want to run firefox, chrome, emacs, and a terminal.
Using KDE or Sway, if I set my desktop scaling to 2x, all programs that run through XWayland have extremely blurry display (they've been rendered at 1x and then crudely scaled up). This includes firefox, chrome, and emacs. The browsers have ongoing work to support wayland natively, but neither is stable for me.
If I set my desktop scaling to 1x, I can then scale up individual xwayland programs with flags like `--force-device-scale-factor` if they support them. This gets me close to the behavior on X but on X I can just set a global 2x scale.
I totally understand the frustration of OSS maintainers when people demand they fix things with no intention of getting into the code. On the other hand, the marketing behind wayland encourages some unrealistic expectations. I went out and bought a new graphics card and it turns out I can't even run firefox! That was not what I expected to happen.
Yeah, here's where I think things tend to go off the rails in the wayland discussions with people having different personal experiences. I've tried to run both firefox and chrome in the native wayland mode and neither works properly _for me_. I forget what the chrome issue was, but in firefox on KWIN if I enlarge a window the portion of the window that was added doesn't render properly --- it's a flashing white rectangle --- and then if I resize it down it either crashes or garbles the whole window. I'm sure this doesn't happen to everyone.
Not sure about emacs but Chrome and Firefox can run under Wayland native these days though still a bit off from them using it on a default launch I think. As for the general workaround you landed on that kind of approach is probably still the best approach at the moment. You can also set the scaling algorithm to something else (I prefer nearest neighbor) if that helps any. There was a PR to support setting X hidpi for XWayland but it got held up somewhere in XWayland stuff apparently.
Definitely a painful use case combination still but one that should solve itself once things actually start using Wayland rather than XWayland.
Is the scaling algorithm specific to the wayland implementation? I saw a github thread about configuring it in sway but wasn't able to find anything about KWIN. I'd also love a flag to just disable scaling on a per-xwayland-app basis (so I could use the --force-device-scale-factor hack) but couldn't figure out how to do that so if you know something off the top of your head it'd really help out.
> None of the Wayland detractors have a clue. They don’t understand Wayland, they don’t understand X11, they don’t understand Linux graphics or OpenGL or Vulkan or anything else in the stack.
So, end users are not supposed to complain because they don't know the full stack by heart? What kind of crappy piece of opinion is that?
It’s ironic, seeing this sentiment from this person in particular. My short list of “people who are jerks to free software maintainers” has him at the top.
You have been trying to reinvent the wheel for a decade and splitting the whole community on petty shit like this, halving development effort on an already non-popular platform, and yet you wonder why people are angry. Instead of evolving X11 and deprecating old features to drop tech debt over time, you went and created your snowflake project and paraded over how much more secure your project is when it doesn't have features to this day, features which are working perfectly on X11. This blog post is the epitome of the whole wayland development group's selfishness. You did this thing for yourselves, for your own comfort and feel-good bullshit, not for the whole community. The Linux ecosystem has suffered too much for no good reason, to the detriment of user experience and market share.
Eh, if a bunch of X11 devs were tired enough of X11 they decided to drop it for working on Wayland I'm not upset at them for working on what they want to work on rather than what I want them to work on. I'll gladly take reinventing the wheel every 30 years over people dropping out altogether, though if they want to that's fine it's their own time and energy. If they did it for their own reasons instead of the community I'm glad if I still find value in what they made and indifferent if I didn't. It's not like I paid them to make me something or they owe me something.
I do wish tensions about it could be lower. I think there is real damage for all any time they rise.
It's not just wayland. For every single thing you can do on linux there exists several hundred different implementations/projects with the same goal of do that thing, and it has led to bad cohesion between system components. Even Microsoft couldn't figure out how to drop Win32 and introduce other safer environments without alienating everyone. How can we expect Linux to survive and become better if we treat everything in it with such a garbage attitude.
I mean things have kept on up until this point I see no point in worrying about it falling apart tomorrow for as long as some people are still hacking at things things'll keep getting hacked at. If it ever does stop chugging along at some point it's unfortunate but not something you were owed by some developer yet didn't get. On the other hand if new things keep coming out you can use for free that's great.
Maybe something will drop off but you'll want to come in and support it while you find it worthwhile, that's all anyone else is doing too.
This is just a reminder to be nice to your maintainers folks. XOrg has had 16 years to get to the functionality level it has, and there are massive holes in it's security model etc that Wayland is attempting to solve. It's going to take time for it to reach feature parity. And they have to bring along all of the popular applications while they are at it.
If you're going to complain, at least be constructive, research solutions yourself and provide feedback that has value.
I'm not sure if the Wayland contributors are overreacting, but I'm guessing people are not being nice when something doesn't work and write posts like "Wayland sucks so bad it doesn't work on XYZ" rather than posting "So I found out that Wayland doesn't work for XYZ, how can I help the project with this?"
And helping in the context might be as simple as writing up the use case and providing logs, or maybe raising the issue with the app developer.
<3 to all the maintainers out there - thanks for your hard work.
The open source ecosystem is all of ours and we should nurture it rather than just wine about it's problems. At least they are our problems and we can have a meaningful impact on them :)
No, Wayland is not currently usable for the "vast majority" of people.
Anyone that has a high DPI display and/or NVIDIA card and uses most of the popular Electron based apps or Chrome will have a bad experience.
Not saying Xorg is any good, or the scaling decisions in Wayland are bad. Just that its not objectively possible to switch away from it yet, for a large number of people
Also it's (ironically) an X11 related issue which shows up do to XWayland backwards compatibility, not something new with Wayland.
Chrome also since supports Wayland natively so the workaround in that PR isn't even needed for it anymore. Electron is still a bit behind but it's looking like Electron 12 should have native Wayland support as well, until then the workaround for X11 app scaling is there.
There are still a few things I'd like to see land (which are closing in) before saying Wayland is a better fit for most users but better DPI scaling certainly isn't one, it was one of the first wins to land to be honest.
.
Regardless sway isn't for most users and will probably never be. I'd look more to issues in KDE or similar where it's more focused on the "normal" use case, supports Nvidia just fine, and is expected to work out of the box.
An X11 presented app having DPI issues not solved by copying that up through XWayland (X11) is not a lose on Wayland's part but the apps working with multi-monitor fractional DPI awareness on Wayland are definitely wins.
The aforementioned workaround would make some X11 use cases work but not all, because X11 has no way to do multi-monitor fractional DPI awareness without rescaling so there is only so much hack workaround you can do in the meantime.
But there's no need to rush users to it just because it can work. IMO let Electron and whatnot get updated in the meantime so it's a smoother transition.
> Wayland works for almost everyone, and works for more people than is even possible with X11. Most of the lies you’ve heard about ways that it’s broken are just that: lies. And if you insist on living in that fantasy, then keep it to yourself, asshole.
But it doesn't work for me (aka. important features are buggy in the gnome/wayland/whatever stack I am using if I select wayland in gdm). Am I now a lier or an unimportant victim of the March of technology?
I am using wayland on my laptop anyway, as it comes with better scaling. I actually want to like it and I am very thankful for the developers putting so much work into it.
But the rollout, especially of gnome-wayland, was a disaster. It wasn't ready* when it came to fedora and it wasn't ready when it first came to Ubuntu and it is barely ready today. The developers (and some diehard fans) repeatly insisting it was robbed many of any faith in the project.
People are saying so much about it because they tried and something broke. And yes it may be QT's (still problems with clipboard) or Firefox's or Gnome's or Nvidia's (half of all linux desktops) fault, not the Wayland core teams or the Wayland protocol's. Doesn't matter in the end.
* With ready I mean feature parity with gnome-x11. Working for "almost everyone" (and with a very, very, significant almost at that nvidia) is just not good enough. Not if you want to replace one of the most important components of a user's desktops. At least for my day to day usage it is pros and cons, but all the pros are something we learned to live without, all the cons are fresh wounds.
>But it doesn't work for me (aka. important features are buggy in the gnome/wayland/whatever stack I am using if I select wayland in gdm).
GNOME doesn't work for you. GNOME uses Wayland, but the bugs you experienced are not the fault of Wayland. They're the fault of GNOME.
GNOME is a dumpster fire and its premature roll-out to Fedora, Ubuntu, etc was very badly done. None of that has any bearing on Wayland, except to fuel the flames for spiteful people who choose to use the botched GNOME roll-out to harass anyone who has anything to do with Wayland.
> GNOME doesn't work for you. GNOME uses Wayland, but the bugs you experienced are not the fault of Wayland. They're the fault of GNOME.
Yes, but I, and I believe most people talking about Wayland mean "user experience on current Wayland implementations", of course.
> None of that has any bearing on Wayland
No, Wayland is not a project that can stand for itself. It drives, needs and causes further work and implementation in compositors, Window libraries, applications, distributions, etc.
Wayland on it's own is a academic coriosity. Wayland that "works" for anyone is a interplay between diverse forms of software implemting or relying on parts of it. Getting Wayland to work is were the problems are, not in the protocol (at least I assume so, I don't have any real insight into it).
And that "Wayland stack" is not (completely) working for me.
Then again I don't post on the Wayland bug tracker, but on the gnome one and I don't want to make excuses for
> spiteful people who choose to use the botched GNOME roll-out to harass anyone who has anything to do with Wayland
Harrasment has no place in in this discussion, no matter what one thinks of Wayland.
... But op was not really about that (at least I didn't understand it like that). It was about "wayland not working" being lies and people not getting it being either malicious or so fooled they are living in a fantasy.
Maybe GNOME doesn’t work for your precious use-case. More likely, it does work, and you swallowed some propaganda based on an assumption which might have been correct 7 years ago.
GNOME works for almost everyone. Most of the lies you’ve heard about ways that it’s broken are just that: lies. And if you insist on living in that fantasy, then keep it to yourself.
> Not fantasy: GNOME on Wayland does not support server-side decorations.
So GNOME doesn't support your precious use-case, but it works perfectly fine for most users without server-side decorations.
This doesn't make GNOME a "dumpster fire" to anyone except the "Wayland sucks!" crowd. Or more of a dumpster fire than, say, Sway: I'm positive one can find a feature that Sway doesn't support.
GNOME is a dumpster fire is a personal judgement based on a lot of different factors.
But yes, if GNOME or Sway is missing a feature then you want, then that's on them. It would speak ill of GNOME or Sway. But it usually does not speak ill of Wayland, which is the fallacy many, many, many people make, and then fill my inbox up with hateful shit over stuff that Sway actually supports!
I'm really tired of this Wayland horseshit. If there was an actual reason for users to use it, fine, but instead it breaks forwarding and vnc and xclip, and for what exactly? Why should I upgrade?
- Multi-Monitor support (especially with multiple different resolutions)
- HiDPI support (even if some of your programs haven’t been updated for that yet)
Now why does wayland break xclip and vnc? Because "every program is a keylogger by default and can see any event, look at the contents of any window" is a major security issue, especially as it means the entire security model of screen lockers or containerized applications is useless.
Under X11, basically every application you run can trivially escalate itself to root. As even your Zoom client can just listen to your key events when you unlock your screen or use sudo in your terminal, save your password, and tada it can elevate itself. Under X11, there is no security whatsoever, and no separation of privileges.
>Under X11, you are basically running every application with root, always.
This is not even remotely true. You are able to snoop on events that use the X server - typically programs run as your user or programs that you have chosen to forward to your X server.
You are correct that the X server gets all events from all clients and therefore can log keys.
> This is not even remotely true. You are able to snoop on events that use the X server - typically programs run as your user or programs that you have chosen to forward to your X server.
Such as your screen locker, your terminal with a sudo prompt in it, or your graphical Apt client?
Well, using the typical argument promoting Wayland, just don't use screen locker, gui terminal, or gui apt, and you'll be fine!
That being said, I've been using Wayland for 2 years, and it's mostly just worked, and worked better than Xorg for many things. Unfortunately I often have to switch back to X for specific applications, but luckily Ubuntu has made that fairly painless. There are pros and cons; the arguments for and against Wayland don't really add much to the conversation, which is sort of an odd state to be in.
That’s true, but doesn’t solve the underlying issue of X11 security. You can patch some individual holes, but you can’t fix X11 to actually be properly isolated and secure (especially as that’d make compositors and DEs impossible to use).
It does, because it explains why this change has to be done by VNC client/server devs, and can’t be done in the wayland protocol or compositor.
If a new replacement would have the exact same set of supported use cases as the original, it wouldn’t be useful. The point of wayland is that it enables some new use cases, while restricting some older ones.
Wayland is still powerful enough to implement VNC (weston supports RDP in both directions) or xclip (KDE’s klipper works just fine under wayland). It just requires effort from third parties.
No, it doesn't. What matters is that xclip and vnc aren't broken on Wayland. I mean, xclip is, but it's called xclip for a reason. The use-case is not broken, and is fulfilled instead by a tool called wl-clipboard.
I wish I had the problem of having multiple monitors connected to one computer or (any of) them having too high resolution wrt. physical size! That said, thanks for reminding that all processes listening (potentially) to all events on X11. Switched now to Ubuntu's flavor of Wayland, let's see how that goes.
(Last time I tried Wayland, it was because an update changed the default to it, without me noticing. Something important to me was then broken, and I had to switch back to Xorg, manually. That left a bad taste in mouth.)
>Now why does wayland break xclip and vnc? Because "every program is a keylogger by default and can see any event, look at the contents of any window" is a major security issue, especially as it means the entire security model of screen lockers or containerized applications is useless.
XTerm has a secure mode, which even locks the keyboard.
That's because PCs aren't phones and the software run on PCs does not attack the user. This is different from phones where the user is the product to be sold and almost all software is antagonistic but it doesn't apply to the linux desktop, yet.
edit: I completely agree about "electron applications". Those are not native applications on linux, those are badly made backdoors using browser runtimes. I do not run them and I strongly recommend to my family, friends, and peers not to run them.
Microsoft has VSCode, Skype and Teams on linux, Zoom has a native linux client.
With modern electron apps, often even being able to be updated remotely, you have to start treating more and more software as hostile as well.
That said, even if you’d only have trustful software, you should still sandbox it, as if there’d be an RCE in a chat client you wouldn’t want the attacker to be able to elevate itself to root.
If you don't trust VSCode, then don't use it. Or use vscodium. But if Microsoft wanted to be evil through VS Code, they could already do enough damage by just sending your projects to them, I would imagine.
It's not a question of trust, vulnerabilities can happen to anyone. Even if the devs at Microsoft were perfect (they aren't), all it takes is an rce in one of the libraries vscode depends on. (Like Chromium, which has happened before [0])
So what's the remote login or rendering solution for Wayland? I don't really care about security or efficiency or whatever, I just want something that works.
If nothing else, because X.Org is effectively no longer maintained. Redhat announced in 2019 that they are basically the only ones who even try to do any maintenance and they do not expect there to be a 1.21 release. In fact no one seems to want to manage a 1.21 release.
Wayland still have bugs, but as Drew DeVault writes: They are fixable and importantly there are people willing to work on Wayland.
One of the more pressing issue currently is the Nvidia drivers, but that's not the fault of the Wayland developers. Users need to complain to Nvidia about that.
Why do people have to politicize everything to this degree? I guess I’m on this dude’s “enemies” list now because I don’t want to throw away the window manager I’ve used for literally two decades. I’m okay with that :)
As a Wayland (and Sway) user; Overall, I have loved the Wayland experience. I am very grateful to all of the devs who've worked to make this happen.
That said, I feel that Wayland devs (and users) are just now (re)learning the ecosystem catch-22 problem. The ecosystem hasn't caught up with Wayland's new architecture because the layers don't line up the same way. This means entirely new layers (or adapters) need to be created all the way up the stack.
Also, this new design and these interfaces are almost completely undocumented, so it makes it very hard for a non-waylander to step in and contribute. I made a couple attempts to fix bugs, but after wading through Github issues for 4 hours, and getting no help on IRC, I gave up.
Unfortunately the ecosystem is responsible for building the rest of the stack, but it's hard, because there isn't much in the way of documentation or examples in the ecosystem. That's the catch. The ecosystem is expanding very slowly because there isn't much of an ecosystem.
Oh yes, the solution to people being pissed off at you is to be even more pissed right back at them. That'll teach them how wrong they are!
Drew, all of the points that you have made here might have some backing in facts, and it is clear from the tone and overall message that you're frustrated, angry, at your wits' end....but such a rant will accomplish nothing but make you look like an asshole, which hurts everyone in the long run.
I would encourage you to delete this and start over. Even if you are a 100% right, this looks terrible, and nobody wants to see this.
I've really come to appreciate Window's DWM these last couple of years. Per monitor true fractional DPI, per monitor refresh rate, and HDR/WCG. The only other platform that has it this good is Android.
I use dwm and X11. I don’t use a “desktop” and never will. I only use one monitor, and don’t care about screen sharing. X11 works fine for me in almost all respects—the exception is some applications drawing some of their text too small on my high-resolution screen. Is there any reason for me to know about Wayland?
Wayland gives a better way for those apps to draw on high resolution displays appropriately and at worst case if they don't know about Wayland they draw all the same as now via XWayland anyways. Ddevault actually created sway which is a Wayland i3 clone so his workflow probably wasn't all that different from yours on dwm.
OK. I may want to try it, in that case. Do you know if there is a good guide somewhere to how to do this? The idea seems a bit scary, as X11 is embedded pretty deeply into the system.
I did it on a fresh secondary install first just to get an understanding of what I wanted to do. If you were going for a more prepackaged system like KDE it's just a click but dwm -> sway is basically rebuilding everything you did in dwm and (at least for me) couldn't be done in one shot on a Saturday afternoon. I hear if you're coming from i3 it's dead simple but I was coming from KDE basically so had to figure everything out plus figure the wayland bits out.
As far as documentation I think this comment chain has the perfect set of links for that https://www.reddit.com/r/swaywm/comments/l54a1a/guidestutori... and the subreddit in general is a great source of information/tips on it. In general it's going to come down to 1) packages for sway, and wayland tools for things like clipboard/screenshot/xwayland/etc, and wayland compatibility on different toolkits/libraries 2) your sway config file which ties all of those packages together and personalizes the look, feel, and functionality of your workspace 3) envvars and other configurations to signal to GTK/Firefox/QT/etc you want to prefer wayland native (otherwise a lot of things still default to X11 which will run via xwayland).
Right now I'd classify it as "no harder than getting dwm/i3 working the way you want it for the first time but a lot of work". Also like I said it gives the apps the ability to understand per monitor DPI or fractional DPI and so on, not it makes every app work perfectly. E.g. FF has really solid and performant GPU accelerated rendering and video decoding you can enable on top of webrender in Wayland but it's a GTK app so if you have it run at 1.5x scale GTK is going to render it at 2x your screen resolution at 3x your configured DPI and downscale the output by 2x to end up at your resolution with 1.5x scale like you asked. Not much different than when it was on X11, except it's a bit more performant and they say it's easier to maintain/simpler than the X11 GPU acceleration code. On the flipside you have Chromium which now has the same GPU accelerated story in Wayland (with configuration) but understands how to do 1.5x without rescaling when running in Wayland and can move to another monitor that's 1x and scale appropriately.
tl;dr: it's a lot of work and a bit scary, don't jump unless you've really got some time and interest. If you do jump it does do what it says on the tin though and apps are only going to get more native Wayland support with time not less.
Sadly the first line of the article started bad, and easily rebuttable, sugesting that if you keep reading, the risky of not learning anything is too high.
I have never even used Wayland, because it's so broken for me that I thought it's still unstable and experimental.
On that note, if the developers are so frustrated that all their work doesn't get the resonance they wished for, probably they are in the wrong business. I am very familiar with the fuck-you-all attitude. But if it comes to this on my part it is usually because I messed up really-really big somewhere and got lost, and needed self-reflection.
EDIT: Btw, I was considering to comment on his flaming, but then I read "mailing list etiquette" and figured that flaming like he does actually breaks etiquette, oh well... Let him flame, I don't care.
Oh ffs I’m quite frankly fed up of gargling alpha grade crap from people forcing it down my throats. I don’t have to drink it and praise it if it doesn’t work.
When exactly on Linux my NVidia 1660 GTX will do fractional scaling at 150% so a 27” 4K monitor is usable, doesn’t crap out every two minutes and actually ships with some distributions and importantly actually stays working every time I update it, I will stop berating it. This has been promised forever and it’s still a pile of random things I have to hack around and then I barely works.
This is a perfectly valid argument about why wayland doesn't work, from a user's perspective, not a developer's. This is precisely what users expect from the system, and frankly, Xorg made it work, despite the mess it was of a tech stack.
Wayland is a very beautiful ivory tech stack, but it was created for a much different use casw than what an average user is going to care about, and as such, it suffers greatly in the end-user's eyes vs. the old and busted Xorg.
I’m just fed up of being told constantly that something works really well when it doesn’t. I’m fed up of people telling me when it doesn’t that I’m not believing hard enough or have some obscure combination which doesn’t work on Tuesdays.
If I sit down and use something and it doesn’t work then it doesn’t work. It’s Boolean.
I think one of the biggest problems of Wayland are the "non standard, but kind of necessary" extensions.
E.g. screencapture. Does Wayland support screencapture? Yes (kind of), but I can't write a Wayland screencapture app. I need to write a Gnome screencapture app or a wslroot screencapture app, or I can even write one that supports both.
But what if someone using the new Future Desktop Environment wants to use my app? It probably won't work because it probably will use a different extension for the same behaviour. So I need to add the extension for that too...
Wayland is one of those projects that could die tomorrow and no one would really care. Which is a symptom of them deciding to rearchitect the world to solve a problem they could have solved by doing some hard work with the existing project.
That tells me pretty much everything I need to know about wayland.
This is a common misconception, thank you for bringing it up.
Wayland and modern post-KMS Xorg do not control your hardware, and have no real ability to do anything with 3D acceleration outside of what Mesa/DRI/DRM/KMS grant them the permission to do. Wayland and Xorg both call the same APIs provided by them, and call them effectively the same way.
The side effect of this is fbcon can be ran on modern "all shader/no fixed function" hardware without special hacks and I can run a 3D accelerated program on the console with no X or Wayland running... which also, by extension, makes X and Wayland both just simple normal programs that don't particularly do anything special.
If you can't run Steam games, this either means Proton (or the native Linux binary of that game, for the few that have them) has a bug that has nothing to do with Wayland, or your system isn't setup correctly (this happens most often if you accidentally install an Nvidia GPU and use binary drivers).
> this happens most often if you accidentally install an Nvidia GPU and use binary drivers
So, the vast majority of people wanting to play games? Let’s be real, Nvidia is currently the king of gaming GPUs. You can’t just handwave it away when talking about gaming on Linux.
Crashes with my Radeon card, open source drivers. My system is setup properly. Crashed with native game (Stellaris) as well as Proton. I'll give it one more time.
Why not? I use Steam under Wayland all the time. (Although it uses XWayland, but it is seamless for me). In fact I prefer it because a lot of games try to do stupid things under X like change the resolution or always put themselves on my "first" monitor (and often mess up mouse inputs if they are moved). Under Wayland they behave much better.
The only thing that I can imagine that you are talking about is lack of proprietary driver support but that doesn't really seem related to Steam.
KDE Wayland supports the Nvidia proprietary driver, Gnome Wayland kinda supports it but is still working on it. If/when Ubuntu switches from X for Nvidia users you won't have to go to the nouveau driver.
Gnome Wayland and KDE Wayland already have this figured out via xdg-desktop-portal-* and pipewire. 21.04 is going to try to do Wayland by default for non-Nvidia as part of a run up to enable it for all by default in 22.04 LTS.
> Arcan is a powerful development framework for creating virtually anything between user interfaces for specialised embedded applications all the way to full-blown standalone desktop environments.
> At its heart lies a robust and portable multimedia engine, with a well-tested and well-documented interface, programmable using Lua.
(Nothing against Wayland, I'm just mentioning it to say something potentially useful to someone.)
> In the case of Wayland, the “vague authority” are a bunch of volunteers who have devoted tens of thousands of hours of their free time [...]
> We’ve sacrificed our spare time to build this for you for free. [...]
> You’re gonna maintain Xorg yourself, because we’re not going to volunteer our time, sacrifice our weekends and evenings staying up late for your sake [...]
This surprises me - I thought Wayland was developed mostly by people who were being paid full-time to develop it, at the various commercial Linux vendors (Red Hat etc.) or companies like Collabora. (And I thought the same was true of Xorg, and has been true for many years.) Is it really true that Wayland is primarily volunteer-driven?
It's true that most people are nonetheless getting Wayland for free (and, to be absolutely clear, harassment is unacceptable even to people being paid to work on the project), but the dynamics of the situation change a lot based on whether the developers are volunteers or paid by some company.
Same here. I still remember the days of XF86Config. X.org was a great step up. And now I've never even noticed the transition to Wayland. Everything still works great.
This is a poor analogy. "Wayland sucks!" isn't a conspiracy theory, its an opinion. There is no basis in truth to the statement "Santa Claus is awesome."
Developing software is difficult and thankless, even if FOSS. I don't know what else to say other than this article feels like a waste of space.
Many of the comments here complete vindicate Drew's post. In fact he's written a few articles on Wayland, with links to others, that some commenters here would do well to read. They explain Wayland, they explain X11, they explain desktop environments. His post is well-founded.
So, I have to admit, I'm sadly under-informed on many aspects of this discussion. While I'm a "Linux diehard" and have been for decades, I care more about the command line and generally look at the desktop environment as just something to run a browser and an IDE. So I'm FAR from a "Linux Desktop UI / Graphics Geek".
With that in mind, can anybody recommend one or more good books / websites / whatever, that represent a moderately comprehensive introduction to all this "desktop stuff"? That is, graphics servers, window managers, compositors, yadda, yadda, yadda. I'd like to dig in and actually start to understand some of the underlying details of what's going on with all of this.
That covers the graphics part which is the same for the two windowing systems.
See Wayland's FAQ[1] and architecture[2] page for why it was made and how they differ.
The biggest beef I have with wayland is it's security model. Ok, you don't want to let other applications listen to keystrokes, record the screen, etc, by default? Fine. There should be some low level implementation that pops up a box asking the user if they wish to allow that app to do that, not outright breaking the practice!
Wayland feels like some ivy tower academic's ideal of what a display system should be. Everything usable is an 'exercise left to the reader'.
Look, if you're a dev working on an open source project meant to replace a critical piece of infrastructure, don't be surprised when people don't like or adopt it when it breaks a lot of their uses cases.
I was really hoping Wayland would be a bit like a programming language in that aspect. I.e. in a programming you have the language itself, the stdlib, and then the ability to load whatever other library you want. In Wayland you have Wayland itself and the ability to load whatever other stuff you want. For core use cases like screen sharing this approach has been an absolute pain. I get not wanting to specify screen sharing as part of Wayland itself but that doesn't mean throwing it to the crowd was a good answer.
There should be some base implementation of wayland (wlroots?), and this sort of thing should happen there.
I just disagree with the whole concept that a desktop environment, window manager, or whatever else has to change because the underlying display server changes. That should be fully transparent. It seems to me that these guys have handed way too much off to the desktop / window manager, washed their hands of it and said 'deal with it'.
In wlroots they probably won't implement it because that requires a GUI toolkit and they don't want to depend on any particular toolkit.
The push behind wayland happened specifically because the desktop environments wanted to implement their own display server, and it was becoming problematic to try to make it happen transparently. It's actually somewhat of the reverse of what you're saying, desktop environments can only wash their hands of things and push them off to the X server for so long before it becomes untenable.
Games: yes, albiet mostly through Xwayland, which is a compatibility layer. Most games Just Work through this compatibility layer. OBS works fine, but you need a plugin.
Caveat: this applies only to compositors based on wlroots, list of them here:
The most mature compositors from this list are sway, wayfire, hikari, and cage. YMMV with other Wayland compositors, and if you have issues with them, you should speak to them, but not blame Wayland in general. If you have Nvidia hardware, you will also have to use the nouveau driver, and YMMV with that, too. I recommend Intel or AMD GPUs, both companies are much more cooperative with the FOSS community.
Thanks for the reply. You would think that these that have the opinion that games do not work on wayland would at least provide their own response than just downvote you.
I still have mouse and keyboard issues under wayland + gnome. This bug causes the ui to drop mouse and keyboard input events whenever the rendering takes too long to complete
I agree with mostly everything Drew wrote, yet these two things are antagonistic to the main sentiment of the post, in my opinion (English isn’t my mother tongue, and I might have gotten things wrong):
> […] just to maintain that broken pile of shit.
> […] If you do know what you’re doing, though, you’ll soon realize you want nothing to do with that shitty codebase.
If it is a "broken pile of shit," and a "shitty codebase," wouldn’t the anti-Wayland be right? I do not use Linux on the desktop.
At this point, Wayland looks like GNU HURD. Probably it is better, but the milestones keep shifting. I will stick to Xorg, since it supports tiling window managers better.
Curious what makes you say the last bit. This comment coming from a tiling Wayland window manager written by the author of the post (sway, drop in replacement for i3).
Wayland folks generally, and ddevault in particular, have built the software they wanted to build, with the tradeoffs they wanted to make. That's good! Users don't have a right to demand they make different software, with different tradeoffs, that they didn't want to make, and definitely don't have the right to invective when they don't get their way.
However, proponents probably also shouldn't push 'no yes it does work for you' replies though, particularly on the Nvidia thing, since that statement has to be followed by 'if you make serious performance and capability tradeoffs that you may not want to make.'
This software disclaims support for this and that thing [1] - that's fine, just add those to your constraint set and see if you still want to use that software at the end of the day. If you don't, that's fine, either write some code to lift your constraints or move on, but don't be a dick about it.
[1]: maybe because the guys that build that thing are jerks, and aren't being good citizens. Which, sure, fine, but from a user perspective, this peg doesn't go in that hole.
I haven't gone back to re-examine Wayland for a while now, because forever I have used RDP to access my headless servers.
And before you waste time with "Instead of RDP you should..."
Save the effort, I have no interest. RDP works with XFCE exactly the way I want it to. But I understand there is a working GNOME RDP interface now, so maybe I'll give it a shot with Wayland when I bring up a new server.
“We’ve sacrificed our spare time to build this for you for free.”
Really? You are just doing it to provide free software with no returns for you? I find this hard to believe.
You aren’t doing it because you wanted to explore a particular technical area that you are unable to explore at a day job, pad one’s resume, impress your developer friends, or help maintain the software as part of your day job?
I'd love to use Wayland, but having to use proprietary nvidia drivers for performance and working screen sharing via Firefox, Chrome, Zoom and Teamviewer force me to stay with X11 for some time. Though there's much progress on the Chrome Firefox front I fear it will take some time until proprietary apps will follow.
> Maybe Wayland doesn’t work for your precious use-case.
> Wayland works for almost everyone...
Oh good. Tell me how to get XFCE running with Wayland then?
I'm not a user of X11 or Wayland, not really. I just picked a DE that I liked. I guess my choice puts me firmly in the anti-Wayland camp though since I won't be running it anytime soon.
Not sure why you are getting down-voted. I use a window manager that has no Wayland support, so I am not switching anytime soon either. Perhaps I will when and if it ever gets Wayland support, but for now, everything works on my end with Arch Linux. I also have "~/.xinitrc", "~/.Xdefaults", and I use "startx" to start my window manager. I have absolutely no clue how to have the equivalent of those in Wayland, including "xsetroot", "xset", and "setxkbmap", among a lot of other stuff, but that is due to my ignorance, so if anyone knows, lead the way please. :)
Depends on what you plan on use when you do make a switch. In general, X applications will keep using Xdefaults because they run on XWayland, and the window manager will handle input configuration, displays, wallpaper and so on.
There are some ad-hoc implementations for doing what you want iirc, but it really is more "integrated" than what you are used for.
I have to test, have not done that in quite a while, but I think that you can just call let's say "sway" on the CLI and it will start wayland directly.
That was a conscious decision by the XFCE devs. They stated they were not ready to do a technological overhaul, and update to GTK-4 (which does support Wayland) for the 4.16 release cycle.
As they just released 4.16 last month, we should see an announcement regarding dependencies for 4.18 anytime now.
XFCE works fine under X11. Stay with X11 in that case, but it's incredibly arrogant and dismissive of the Wayland folks to say "your use case will work under Wayland, you have no excuses" and then also say "well, actually, it will work if you force your upstream to port your DE to it".
Someone in the XFCE camp needs to roll up their sleeves and get it working. This is not an easy task, KDE and GNOME have been at it for many years, but it is doable.
I don't use or follow XFCE myself, but a quick search suggests the developers are working on it, though they won't get there anytime soon. (most of what I can find seems to be from 4+ years ago, so not anytime soon could be yesterday for all I know)
KDE has more manpower, and while it still has far too many bugs to be my daily driver, I only have tons of respect for the galaxy-brain maniacs who work on it.
XFCE doesn't have such a big team, and they are careful to maintain stability, so they are going to work slower. I accept this.
The reasons I _personally_ am convinced Wayland is bad has nothing to do with XFCE support, really.
If I wanted wayland, I'd run windows or MacOSX who both deliver what wayland promises.
I'd rather have X11/XWindows, and an internetwork of computers instead of an isolated desktop.
There were better solutions in the past. Still could be, and possibly better solutions for the future.
I use sway everyday and i freaking love it. Mixing monitors with different resolutions AND different refresh rates all running at their native speeds with no tearing, all while keeping my nice i3 Shortcuts? FREAKING AWESOME!
Does EVERYTHING work? Nope, somethings are broken, some require config changes or workarounds. I have an XFCE desktop installed as a backup for work when i know i need to do a lot of Zoom conferences but for my private stuff i can just avoid non-wayland software and for most things IT.JUST.WORKS. and it's superbly fast and comfy AF to use.
Complain away how wayland doesn't do everything xorg does. Stick to your abandonware for legacy reasons. That's fine. That's your freedom.
Tried it on Arch with i3 a year (maybe more) ago. Wasn't really usable back then, switched back to X11. For embedded applications I'd probably start with Wayland, but yeah, for my host machine I'm not motivated enough to be more than a mere user.
This just sounds like the heavy cost of software development. Part of providing a good user-experience is documentation, patience, user-research, understanding the sophistication level (or lack thereof) of your users, etc. From what I've observed most FOSS software doesn't have time/interest for that kind of hand-holding (and I can't blame them, they aren't getting paid and probably don't like that part).
The counterpoint is that a lot of great FOSS software that is 80-90% great but with a terrible UI, terrible documentation, or glaring incompatibility that makes the experience entirely unpalatable for a swath of users. And so a lot of people don't use it. Which is also fine.
In my case, ranting didn't help. In fact, it made things much worse.
Also, in my case, I was lucky enough to hand my project over to some really sharp, energetic and positive people that have taken my work to the next level.
Turns out, the absolute best thing that I could do for my project, was to step away from it completely (not even being a "benevolent dictator emeritus"), after ten years of dealing with some really annoying crap. My being associated with the project was actually a boat anchor. I hate to say it, but not everybody loves me, and I'm fairly good at giving as well as I get (see "didn't help," above).
I have no experience or knowledge regarding Wayland, infact this post was the first I have heard of it. That being said, if the author's rant truly reflects the attitude of the community, it's sounds pretty toxic.
Standing as an outside observer, usually when someone posts about progress on Wayland they are immediately greeted by "Well, I don't like it." "That sucks" "just use X" etc.
I've seen that sometimes here, although it's more frequent on Reddit.
It's really a shame how that happens, it is pretty much a universal problem. I have seen people get into physical fights and shouting matches IRL charitable organizations where everyone is volunteering their time.
The OP's feelings are probably justified and I can empathize with them but the rant was still jarring and probably won't have any impact on the haters but will affect others.
Just my thoughts, maybe I'm virtue signaling a bit too much.
> if the author's rant truly reflects the attitude of the community, it's sounds pretty toxic.
There's been a lot of external hostility and conflict over the years. Which unsurprisingly affects community culture.
And the reverse too. I recall encountering surprising "yikes!" even early on, from excursions from professionalism, tone-deafness, and groupthink. Which didn't help with external harmony.
It might be interesting to explore sometime, what might have been done differently long-term, to perhaps have gotten different dynamics. For instance, if replacing X11 had been envisioned as first a broadening of alternatives, and only then a narrowing to a new standard. Open source often uses forking and competing projects to defuse hostility and keep people engaged and productive. Coping gracefully with "lots of diverse everyone trapped on the same boat" isn't its strength.
I understand the frustration, but somewhat related:
I'm dismayed by how much people just categorize everything as 'anti-' or 'hit piece' (when it comes to news) or ... something that implies some sort of extreme bias or conspiracy when it comes to an opinion they don't like these days.
Nobody it seems has a valid point of view, it's so often just some sort of 'propaganda' or something...
I don't know anything about 'conspiracy of conspiracies' as much as people just reach for that type of terminology when they see an opinion they don't like.
Pipewire works for "screen" sharing (not window/monitor sharing, screen sharing) and Firefox/Chrome support it. That being said I'd still say "give it more time" before I'd say "screen sharing is solved" at the moment.
Unless you have nVidia graphics, sway is probably a drop in replacement for you, with minimal changes from your i3 config. You can literally cp ~/.config/i3/config ~/.config/sway/config and it will work.
> There are Linux kernel APIs that we (and other Wayland compositors) use to get the job done. Among these are KMS, DRM, and GBM - respectively Kernel Mode Setting, Direct Rendering Manager, and Generic Buffer Management. Every GPU vendor but Nvidia supports these APIs.
Edit: I should mention, if your hardware doesn't support given software, just don't use that software. There's just no need to go in shouting about how terrible said software is.
> if your hardware doesn't support given software, just don't use that software. There's just no need to go in shouting about how terrible said software is
Why is this sarcasm? I've rarely seen a young free software project even come close to the level of documentation of Sway! Have you tried `man 5 sway` yet?
You are correct of course, Sway does do a little more than i3 does.
That being said, you can still get the same experience as you are used to by dropping in your i3 config file. I'm not saying that you "Need to move! Using X still is evil!", I'm just saying dismissing Sway out of hand because it's "Not i3" isn't fair either.
I've been using Wayland since it became the default in Arch Linux with Gnome and it almost always worked flawlessly. There are some (rare) programs that don't work well with wayland but I assume that's mostly the programs fault.
why did ubuntu use wayland and then switch back to X?
i think this is a great piece of evidence in the case for all these open source guys to stop wasting their effort on open source projects. the amount of utility that is got per unit time and effort is pathetic. its thankless, hard work that in this case will basically be rejected by the very people it was designed for.
i think a better model is something like system76 where the core developers are paid and people get really good, well integrated hardware as well.
Big shoutout to all the wayland contributors: Thanks a ton for all the hours you spend on the project. Please keep up the good work and don‘t let the haters get to you!
I could use Wayland and deal with all the issues it has with hacky ways.
Or, I could not use Wayland and continue working with things like team viewer and do my recordings and presentations with actually useful programs and industry standards.
Just because something is a 'niche' use case doesn't mean its not important.
Yes the average programmer is just fine under Wayland.
Every other niche case Linux has been working to accommodate all these years isn't because, even if slight, Wayland causes issues.
I am also even less inclined to use it again after these comments.
There aren't any Xorg maintainers left. Xorg was abandoned, by its maintainers, because it's a broken pile of shit. Calling it a broken pile of shit is validating its (ex-)maintainers, not being a dick to them.
I highly doubt that nobody who used to work on Xorg would be offended by you calling it a broken pile of shit.
And then there's this, from you, today:
> GNOME is a dumpster fire [1]
Can you say the same about Gnome maintainers? Do you think they're not offended by you calling their project a dumpster fire? You're being hypocritical and going to great lengths to spin a narrative to justify your abusive language.
I feel you on entitled and abusive users, but stooping to their level reflects poorly on you and to a lesser extent on the projects associated with you, including Wayland. You can choose to be better than that.
Honestly, your attitude in TFA and here is doing more harm than good. Have you considered taking a hiatus for a while to re-center yourself? Maybe find another outlet for your frustrations? Or maybe consider @titzer's suggestion [2]: delete the post and start over.
>What do anti-vaxxers, flat earthers, 9/11 truthers, and anti-Wayland activism all have in common?
Bro what, are you kidding me?
When systemd got jammed down our throats all I felt was "well, I'm against it by principle, but I guess strictly speaking nothing is getting worse"...
If this half baked Wayland nonsense gets shoved down our throat, I am toast. I need good functioning color management and Wayland seems to say "well, nobody buys displays more than 100 dollars, so sRGB it is"
Just an observation, here's something that's a result of the fact that self-published opinion pieces on the Internet don't necessarily go through an editorial process before publication:
> It has a real cost, you know, being a dick to maintainers. [...] We’re out here trying to make things better [...] We’ve sacrificed our spare time to build this for you for free.
Yes, but who are you addressing? There's a subtext here that discouraging behavior can be such a burden that it takes away resources from the project. Perhaps it takes such a toll that a maintainer just calls it quits on the whole thing. That makes sense when addressing your fans who are consuming your work but nonetheless burdening you. To a detractor, who isn't using Wayland and doesn't want Wayland to succeed, discouragement leading to burnout is not failure condition. This logical slip is probably the result of leaning too heavily on the vaccine metaphor.
Now playing Devil's advocate (contra this piece):
In the real world, anti-vaxxers benefit no matter what they believe. But that's not so in Wayland v. X11 duel, which is not only a genuine a matter of preference, but there are actually shades of a zero-sum relationship here. The idea of Wayland, like a vaccine, being good for you whether you know it or not doesn't hold up. If you're in the X11 camp and oppose Wayland, improvement to the Wayland ecosystem isn't bringing nice things like herd immunity. It's actually a threat if your vision is one where X11 remains entrenched for the foreseeable future. It would also be really easy for a detractor of Wayland to use this post for ammunition, for example labelling this as self-aggrandizement and maybe claiming that there's an attitude where Waylanders see themselves as saviors, rescuing others from a plight they don't even agree exists, and that it's an attitude indicative of the project as a whole.
The author is seriously upset, insists that Wayland works for almost everyone, and if you don't like Wayland - you don't have a clue, and f... you, and you will maintain Xorg yourself, and f... you. And f... you. Did I mention f... you? That's it.
Thank you! Some arguments are just so stupid and misguided, that they don't deserve any consideration. I feel like the Wayland "truthers" are wasting their energy with absurd arguments amounting to "Everyone should use old software because I want them to!"
Reminds me of people who are staunchly anti-systemd. They are luddite masochists who prefer shit that is inconvenient or broken for the sake of being a contrarian hipster.
That does not mean anyone is under an obligation to like it.
> Maybe Wayland doesn’t work for your precious use-case. More likely, it does work, and you swallowed some propaganda based on an assumption which might have been correct 7 years ago.
If you insist on disregarding people's use cases, don't be surprised they don't like your software. I've been down this road a lot with FOSS software: "I don't use it because it doesn't do what I need", "sure it does!", "no, it really doesn't", "well you don't need that anyway!"...
On the whole however, I can certainly understand the frustration at having to deal with a community that gets annoyed at anything that changes simply because they're already so used to the garbage pile they have that they now hold the delusion that it's actually not garbage.
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!" as though that was supposed to make it ok. People have thus harbored some inherent resentment ever since.