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.
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.
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.
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.
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.
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 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.
> 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.
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".
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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
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 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
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.
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.
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.
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.
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.
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.
> 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.
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.
I didn’t say I cared. I said it was an undercapitalized endeavor partially due to infighting like this, and that sticking to it speaks for itself in terms of the goals and philosophy of a developer. I might have meant kudos for believing in something the world doesn’t and left it unspoken, for all you know, but your reaction to criticism of Drew DeVault tells me we are not discussing this on equal footing.
> 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.
I’m aware. That’s not relevant contextually. We are in the comments of an “essay” comparing criticism of Wayland to the belief that vaccines cause autism. As a result, his investment in Wayland is contextual and what I’ve focused on, not his other work. I have opinions on that work, too, I’ve just clearly riled his fanbase enough for one account.
>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.
Instant turn off and automatically made me close the window. It is hard to imagine he has his position because all I see is someone on top of a mountain of salt. Good thing he didn't mention the USS Liberty.
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—it always feels like the other people are doing worse. No one would objectively describe your posts in this thread as "very moderated".
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.
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])
>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).
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.
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.
>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.
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.)
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.
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.
> 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.
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.
> 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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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!"
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.
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 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.
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.
> 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.
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.
> 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.
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.
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.
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.
> 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 :)
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.
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.
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+.
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.
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).
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.
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.
> 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
> 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.
> 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.
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 ex...
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.
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.
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.
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
Old gmail is faster and normal things like opening a link in a new tab actually works like any other page and its actually a lot easier to read because of it.
In the new interface you are only given a fraction of the horizontal space for the actual mail, and I actually have to scroll sideways to see the pop out in new window control which for aesthetic reasons is only a graphic with no text label except on mouse over. Popping it out gives you a window that you may or may not need to resize or move for optimal reading and as far as I can see there is no way to just read the mail in a new tab in the same window at all which breaks most people's methodology for managing multiple tabs.
> It's not 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.
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.
> 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). 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.
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.
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.
> 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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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).
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).
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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?
>> 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.
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.
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.
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.
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.
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.
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.
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.
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. 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.
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.
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.
> 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.
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.
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.
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.
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.
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'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.
> 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.
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.
> 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.
>> 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.
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.
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.
>> 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 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.
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.
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 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!
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.
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.
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 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.
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.
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.
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.
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.
>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
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.
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.
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.
>> 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. :-)
> 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.
> 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.
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.
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.
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?
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.
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.
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".
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.
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. 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.
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.
> 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.
> 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.
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.
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.
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.
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.
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.
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
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?
>I’m out 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?
Yeah. Nvidia is engaging in shitty behavior, and I've outlined my argument for this. It's shitty to reward this behavior by buying their thousand-dollar GPUs. And, yes, I think that doing so anyway makes you a shitty consumer. And, yes, I don't want you in my userbase if you've made that decision. It's not my problem when shit breaks for you because of that.
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.
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.
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.
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".
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.
> 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“.
Welcome to free software stewardship. I too have had my ass reamed online for publishing and maintaining free software. I thought it was funny. How crazy do you need to be to shit post about a free product that has no strings attached? And yet....
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?
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
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.
> 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.
891 comments
[ 1.7 ms ] story [ 356 ms ] threadWhen 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.
Kind of like reverse survivorship bias. The only wayland sessions that get attention on the internet arw the ones that don't work.
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 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.
The Wayland community contributes a fair share due to xwayland, and we get stuck on this quite often.
And yeah, it'll need fixes. over time. It's big, complex, and interacts with device drivers that are very much in flux.
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.
XWayland is Xorg. An Xwayland fix is an Xorg fix. An Xwayland bug is an Xorg bug.
> Those who contribute to Xorg and feel stuck could step up to maintain it, if they wish. (Don't they do it already?)
No one maintains Xorg anymore, so there is no one to review patches, merge and roll new releases with them.
There's a huge difference between wanting to fix a bit and becoming an upstream maintainer.
The maintainers left for good reason, and no one wants to be stuck with that turd.
> Then, I'm sure someone will step up.
It is not "over time", it is now or never.
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.
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.
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.
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.
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.
I've seen that sometimes here, although it's more frequent on Reddit.
I try to not contribute, but even knowing about the problem I catch myself - it seems to be human nature.
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.
https://gitlab.freedesktop.org/wayland/wayland/-/commits/mas...
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.
> 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.
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".
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.
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)
I can excuse XFCE for being slow. However that is very different from the claim that because XFCE is a bit slow that Wayland is in general bad.
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.
As they just released 4.16 last month, we should see an announcement regarding dependencies for 4.18 anytime now.
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.
No real point, here. Just rambling.
I mostly agree, although I prefer OpenRC personally. I was bit by
too many times to really like SystemD, although I tolerate it on my daily driver these days.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.
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 kinda wish "proper shutdown" was never invented at all. That would've motivated so many developers to care about reliability much more :P
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.
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 a difficult problem.
[0] Well, not exactly, but you get the idea.
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.
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)?
Kill the process immediately and risk data loss?
Behave as-is but with a lower default delay?
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)
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.
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.
Being able to dump screenshots or process them in any other way, also again with bash scripts, is very modular
Being able to debug parameters of X windows, 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.
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.
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.
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.
I guess he's referring to this post? https://drewdevault.com/2019/02/10/Wayland-misconceptions-de...
And to numerous comments on HN and elsewhere.
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.
Personally the community around wayland seems to have some toxicity in it. That is the only thing I really took from the original post.
Luckily, DeVault is an insanely prolific writer of actual code, so there's no need to evaluate his attitude. His code speaks for itself.
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.
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.
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.
Instant turn off and automatically made me close the window. It is hard to imagine he has his position because all I see is someone on top of a mountain of salt. Good thing he didn't mention the USS Liberty.
https://news.ycombinator.com/newsguidelines.html
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.
Commenters routinely underestimate the amount of flamebait in their posts—it always feels like the other people are doing worse. No one would objectively describe your posts in this thread as "very moderated".
"Wayland doesn't X!"
"Actually, it's on purpose or X that is not working on Wayland because [reason]."
Sure but that doesn't make it work.
- 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.
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.
[0] https://www.electronjs.org/blog/chromium-rce-vulnerability
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.
Such as your screen locker, your terminal with a sudo prompt in it, or your graphical Apt client?
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.
No, not if input is grabbed, sorry.
> your terminal with a sudo prompt in it,
Pinentry&co are mainstream for a number of years.
VNC: https://github.com/any1/wayvnc
Does it matter why? If I use VNC to do my work, it is absolutely impossible for me to switch to wayland, no matter how justified the reasons are.
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.
XTerm has a secure mode, which even locks the keyboard.
(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.)
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.
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.
Sounds like a roughly equivalent situation either way? Personally I'd sooner use only Qt applications than have to use Gnome.
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.
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)
Plus I use firefox lockwise as password manager.
OK, so what's the solution here? Give up on screen-shotting tools forever? Or is there a plan to fix this somehow?
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.
[0] https://github.com/emersion/grim
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.
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.
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!
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.
Sandboxing arbitrary badly behaving software is just going to use the same APIs as flatpak, so this helps for your use case as well.
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.
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.
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.
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 ;)
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.
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.
But the X11 boundary can’t be resolved unless you put a whole X server into every single application’s container with XonX, or you replace X11.
Which is part of why wayland exists.
(Sorry for butchering up the quote)
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.
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.
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.
That said I would use wayland if nvidia wasn't busy fucking everything up.
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.
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.
In 2021, screen sharing and screenshots are table stakes.
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.
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).
My other machines mostly use KDE or Sway on Wayland though.
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).
Heh
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.
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.
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.
i3 is a X11 window manager and has no Wayland support at all.
Sway is a Wayland compositor that closely resembles i3.
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.
Yesterday I made a casual observation about something quite obvious, and more importantly, completely irrelevant. And without fail, the only response was that it was because of x and y. It isn't.
On facebook, the only way I ever get an answer is to use Cunningham's Law. And I even usually use the words "cunninghams law" in the comments. But it always seems to get me my answer.
It would match the ratio between good software and self promoted junk.
----
I think Ubuntu is good gauge for the real state of Wayland. They would like to switch to Wayland as soon as possible but even in the 21.04 Ubuntu still defaults to Xorg on Nvidia based systems.
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.
fucking nerds acting like it,s no big deal when shit i use every day is all changed up.
do you have any idea how much cognitive load that is for the average user to figure out new ui?
and usually for no good reason, just to change shit up so someone can get credit for a project.
don,t blame the users for software being shit. it,s shit. it,s built by arrogant emotionally-children with no concern for empathy or quality.
most software changes are unnecessary and are forced on users unnecessarily, and that,s why people hate software.
All the successful projects Linux users like to talk about nowadays (gaming now a practical thing, new kernel features, Wine getting really good) were all bankrolled by massive billion dollar corps like Valve and Google, because the community itself has no discipline to see things through.
At least GNU of the old days was organised enough to know not to break people's workflows - just look at how stable coreutils have been - but GUI software for regular people somehow doesn't deserve to get the same treatment.
"Linux"? We're discussing a category that includes Gmail UI changes. Is Gmail not popular?
Maybe discipline is a problem, but time, money and access to information is too.
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.
I don't think I can tell you immediately whether my laptop is running under Wayland or X (I only can because Wayland and FontForge haven't been talking for some time). Does it annoy me? Yes. Does it annoy me to the point of anger? I'm an adult. I have other things going on in my life besides graphical back-ends.
This is not how average people are AT ALL. Let someone use one of the above and give them something new and watch them be frustrated for at least the first entire day of usage with continuing friction happening for the next week-month every time they find a new task that they don't do that frequently but thought they knew how to do.
On the Subaru, they are clutch controls. The result was downshifting into 1st gear going 70mph/100kmh+.
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.
IMO that depends if the software is paid for or not. If I regularly pay for a software I can have demands.
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).
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.
I see your comment's flagged, maybe because of the harsh language but other than that it all rings true to me.
This. I think it's incredibly inconsiderate to do that to a user who never asked for it.
As a user, I abhor this mentality, and respond to it by leaving. And if I have to stay, I boycott the nag dialogs and just leave them open, to embarrass the developer in front of anyone who may be watching my screencast.
As a programmer, I go out of my way to ensure that my software works the way the user wants, and an upgrade is never demanded.
I design for back and forth compatibility, so that I can go back and forward to any version I desire, as long as there's a commit for it.
It may not work perfectly going back a year, but if it's a stable version, it should run.
This seems to point to the general situation of change fatigue. If you pick up a random Android device, what does the "settings" app icon look like? Individually, these things are small, but the small impedances these changes introduce does take a toll on people, especially when you're trying to just get stuff done.
I don't think there's an easy answer here when the developer needs to make fundamental changes, though.
One of the problems is a parity disconnect. A developer/PM often has very different perspective from their users: They see the new changes as they're happening and so they're all small, incremental changes, plus they're closely following development.
A lot of users only infrequently update and/or infrequently use certain features, and so for them, all these small incremental features add up to be massive change for the sake of change. This will often manifest as "Every time I go to do x, it's totally different and I have to re-learn everything!".
I find a lot of software -- especially FOSS -- also communicates change poorly. Release notes are the primary way to get across changes, yet there are several bad things people do that make it basically impossible to read:
* List every change or commit message, especially without categorizing or simplifying the wording
* Don't properly highlight feature changes (eg with screenshots and/or reasoning)
* Have dozens of betas/pre-releases, but don't consolidate the release notes into a final "here's what's changed since the last main release" document
Some examples of exceptionally good release notes: Visual Studio Code [1], Jira [2], Gitlab [3] (though if they only provided their changelog [4] it would be a good example of being overly verbose to the point of unusable).
[1] https://code.visualstudio.com/updates/v1_52
[2] https://confluence.atlassian.com/jirasoftware/jira-software-...
[3] https://about.gitlab.com/releases/categories/releases/
[4] https://gitlab.com/gitlab-org/gitlab-foss/-/blob/master/CHAN...
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.
Memory performance is not too big of a deal, IMHO given the last decade of hardware, but stability is.
Lost mental state is generally as painful as data is. People hate it viscerally.
I have seen 4 figure software get replaced by 5 figure software over that alone. 5 figure stuff runs for weeks to months at a time. 4 figure can crash daily or more often.
Stability was a primary selling point for me, and I used to maintain a session for that purpose. "My session has been active for months and 10's of projects, lets open your sample data and walk through it...." Did that on a reasonable, but not great Lenovo. Hibernate, sleep, hibernate, sleep...
Win 7 too, lol.
I came from IRIX. I would go the better part of a year, apps running, system up, all ready to go. Spoiled. Win 2k was good, Win 7 matched it, and Win 10 is solid, except for forced updates.
I would never, ever devalue stability. People who are focused, task intensive, live it, love it, will argue they need and are worth it.
Not sure they are wrong.
Play it how you will, of course. I will pass hard personally. Lack of stability is very high on my qualification list.
To be blunt, where it exists there are other priority problems.
One may just be flashy speed and other sizzle done at the general expense of the solution being robust.
May only take an event or two needed to cancel out potential gains from those things. Turn that crank a time or two and many will just get back to work.
An attempt or two again? Many will ignore the solution and or have adopted something else.
Net result? The team that did not make stability a priority likely did a lot of market building for the ones who did.
I personally am very frustrated by this constantly, but there is no way around it that will always work. Someone has to pay the cost of market building, it is a separate cost from stability, and sometimes you can't afford both.
But, what does work far more frequently is to get the solution robust early. The longer it gets put off, the more difficult doing it is, both in time, cost, users being requited to do things along the way to support it all.
If so, they can pay now, or pay later, just make sure you manage expectations so they actually do pay.
If, somehow that ended up on you, of course they refuse! Why pay for a free lunch?
So don't allow that. Seriously.
Maybe the customer finds someone hungry enough to pay for them.
Or, maybe that customer pays hard going through this cycle a few times too.
Not my problem and it does not have to be yours.
Can definitely be robust and should be.
In this scenario, it is a mutual problem. Nobody has to use the software, true. However, it again is all about managing expectations.
If it is oversold, people will end up with bad experiences and that does impact who delivered them.
This has already happened. Will again too.
On a short timeline, maybe no big. On a longer one, higher order impacts may actually be painful.
Say a decade of negative public sentiment sees a brutal regulation kind of painful.
Entities putting billions in the bank can and should make reliable software.
There is a YUGE diff between Gmail, Excel and friends, and rando OSS.
This discussion ranged far away from the initial premise.
So, let us take it back a bit.
Weyland. Wants to be the defacto display solution. Does not have the same priorities many users have. Also does have priorities many users have.
Replacing X11 was made an explicit intent too.
Well, if it does not actually do that?
"All that Weyland shit talk" is the outcome.
Maybe subtract the replace X11 part, or maybe find a way to actually replace X11, or maybe just ignore the shit talk?
Because of that problem, I have always maintained we need a way to better fund some projects.
I would love to see the display system funded and all the good stuff worked out properly. For me, the network features and general flexibility of X is worth some money.
When I ran SGI machines, that money was paid and the display systems were flat out awesome.
If it does not do those awesome things? Meh, can just run Win 10.
I used Exceed a lot. Exemplary. That program did everything nicely. I even used a CAD app on Windows that actually was built for X and it was network transparent same as any Unix box!
There is a sub $100 one out there. Maybe a bit more now. Maybe gone too. It was very good.
The freebies are respectable and great for sysadmin.
Funding a first class X11 replacement that also does some new things people want for mobile and embedded makes a ton of sense to me, and I would sign right up too.
Maybe getting a bunch of us tossing a tenner a month at this would fund a project that just gets it all done.
And we need one.
It is obvious to me X11, used as it can be, sees way more than anyone may have thought today. When I was on IRIX, X11 was flat out awesome. Shit just worked, and was fast, and 3D graphics over the wire smooth, fast, performant.
It took a long time for the rest to get there and when they did, nobody really grokked it, unless they came from a solid implementation.
And nobody from the PC, Windows camp got it. Did not even understand what an app server even was.
No fault here either. People saw what they saw, worked how they could work. I get that.
But today, people still saw what they saw, work how they work and ripping all that up is painful enough to not make sense.
If it did, we would have seen this go differently.
So maybe this should not be a volunteer effort. Matters too much to way more of us than I also believe was expected.
If we fund something thwt does what X11 can do and that also will do the new, spiffy, lean things people want today, we would have a killer environment.
Having that be OSS?
Worth it to me.
Or, we can watch the carnage for another decade...
Good discussion, BTW.
People keep saying that Wayland needs to be more of an X replacement but it's never clear what that means. You want 3D graphics over the network, that currently means Vulkan, and if you were going to do that, there doesn't seem to be much reason to tie it to any particular window system.
In a general sense, Wayland is not Unix like, in the same way systemd isn't. X11 is, as were various init systems. And fact is, at the time those things were done, multi user computing was a thing, and it was all done with those ideas in mind too.
At the time, micros were on the rise, and apart from a few exceptions, were single user, and started out single tasking.
Two different roots of thought, now well grown into trees that share intermixed and intertwined branches.
I know that is an issue. Whether it needs to be addressed is an ongoing matter. A matter I am happy to discuss, but not currently one that impacts me too much right now.
My focus is pretty far away from a lot of that. Doing lower level stuff, and often with no OS, embedded. So, write it, include it, port it if need be, then compile and deploy it.
Minimum requirement is gcc, command line, terminal. In all other areas, Win 10 is fine. I really could give two shits what OS it is otherwise. Machines are all fast enough, big enough, etc... good times (for me) actually.
Again, not dismissive, just not a focus at the moment. That could change and I might care a lot too. This kind of thing happens to people. Sometimes often.
When I use X, I tend to make good use of the network capability. It is the primary reason to use it, along with ways, means, tools that have worked forever. I value stuff like that very highly because I much prefer learning and using new things to me, not always remapping stuff I know cold.
For example, in the past, I have enjoyed weaving a single desktop environment from a pile of machines and software. Did that to support, sysadmin, train and develop for advanced engineering software users of all types. I had the industry on my desktop and could run or do almost anything on a variety of platforms from that desktop and the time savings on that as well as my general potency 2as off the charts good. Beat a lot of other people who did not really grok X too.
Log in and just do stuff, and depending on what gets done, a few machines, or just one gets the job done, served up to me nicely, consistently.
For a long while after IRIX was done, I used a machine as my head end. Just worked great for that kind of work. Pretty much nothing was as good since, and apps have become far less flexible too. A pile of VM's are required for that kind of thing today and it is a lot more work.
But, it is also a lot more lean hardware wise too. That is significant right now, though I do not know how significant given how cheap stuff can be.
Anyway, back to the UNIX part. Small programs, smart data, pipes, all that stuff is UNIX. X11 allows all that to travel where it needs to and it is a very nice way to work.
If one wants, everything can be distributed too:
Fonts from one box, X Server from another, application on yet another, running on shared files from yet another, window manager on yet another, etc... An Indy used to serve up its nice window manager for my Linux for quite a while, just for shits and giggles.
And that is the UNIX way.
Sometimes it is powerful. I see people struggle with managed data, engineering software, etc. for example.
under X, I just made a beefy box, one copy of the app, one database on local disk, one backup system, and on IRIX that could be done live while people are working with just a few set and forget scripts too.
Then, serve 20 to 30 users. They do not have to know anything other than how to use the app. And they can't really break it either.
Admin on that thing was mostly cake and the users could run whatever they wanted as long as it had a respectable X server, they were good to go. Few of them would even notice or care, and it worked great over 100-T networks too. Kind of crazy to think about today.
The nice thing was those users could not touch the data ex...
I remember my early encounters driving me absolutely mad because I did cut my teeth on that 1 seat 1 user environment.I think where I've ended up going in a different way than most is that over the years I keep cracking away at it because I want to understand it. It's an intuition thing, and you never really appreciate the miracle of it until you sit down and come to terms with what X really did. It was the glue between app logic, state, and a constantly floating set of goalposts represented by every possible set of different hardware.
I haven't even torn into the source. It's taken me so long just to grok the other layers of the problem space. Personally, I think the space X11 occupied is one of the most enticing areas of research open to me, even if I never seem to make the time for it.
Abstraction-wise, we assume we carry context with us everywhere, but an X environment driven over a network breaks you of that quite handily, and I don't think the "Cloud"/SOA solves the real life dilemma jist by lifting everything into a browser.
Agreed.
At the least, risk will be higher than it needs to be, and that puts the other validation into question as well.
Often is right?
When does robustness end up a priority?
Could be a very long time, and or never, particularly given the core value proposition and or features intended to deliver it are not themselves validated by "the market" as you say.
One solution to this is to pay people to adopt the solution.
Another is to deliver features more specific to them.
Yet another is to cover it up, make recovery robust, transparent, etc...
These are all perfectly fine ways to approach beta type cases, initial userbase, seeding for growth.
After that process has shown what the market finds compelling, stability should be right there in the list with the core set of software to build on.
You can't omit stability in life-critical software for example.
On the other hand software's usefulness can outinfluence unstability, if there are no alternatives.
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.
The point being made here is not that it always must be stable.
It is all about how often stability is not a priority when it could and or should be.
And in the no alternative scenario, it can be compelling to continue to ignore robustness to get growth and lock in.
When that happens, stability, robustness often stay in the back seat for a large fraction of the product life cycle.
For any given user, the impact may be just low enough to keep them on board too. New features, and asking more money for them, or offering them to make up for that impact can be an ugly cycle leading to users ripe for the picking later on.
Example: Steam cloud save. Countless time I have to force quit Steam's background service because Cyberpunk 2077 and GTA V freeze while saving.
Steam doesn't show the launch game button, even though the game is killed from task manager.
There are no heartbeat like mechanism to keep in check the game process state.
And there are no alternative to launch the game that I bought from steam, so the instability becomes little of nuisance.
But that's a minor issue where unstable features are unimportant ones.
> It is all about how often stability is not a priority when it could and or should be.
And I'm on your team too. That's why my argument is that stability IS A feature too. Countering grant parent's argument that says stability is ignorable as long as the features are validated by the market.
> And in the no alternative scenario, it can be compelling to continue to ignore robustness to get growth and lock in.
As a paranoid user I agree this has been a nightmare. I constantly have to make sure I wont get locked in to services that I pay for, and often time I find myself using open source solutions rather than paid one because of the same reason.
It absolutely is a feature.
Guess the externalities problem crops up in this context.
How to actualize those costs better so the equation makes more sense?
And yes! I hate lock in viscerally. Frankly, will avoid it at very considerable cost.
Which equation exactly? The balance between effort to stability and other stuffs? Sorry I'm a bit lost
This is hugely underappreciated. Last fall I decided I would get back into making videos for YouTube after 7 years away. But two videos into the new series, and the constant crashes of my video editing software I just paid $$$ for have reminded me why I stopped making videos in the first place.
Ultra painful. And anytime I hit flow, I am either gambling by not saving and disturbing flow, or leaving flow trying to save... agreed.
Scriptable may find a lot of use.
https://support.google.com/mail/answer/15049?hl=en
Old gmail is faster and normal things like opening a link in a new tab actually works like any other page and its actually a lot easier to read because of it.
In the new interface you are only given a fraction of the horizontal space for the actual mail, and I actually have to scroll sideways to see the pop out in new window control which for aesthetic reasons is only a graphic with no text label except on mouse over. Popping it out gives you a window that you may or may not need to resize or move for optimal reading and as far as I can see there is no way to just read the mail in a new tab in the same window at all which breaks most people's methodology for managing multiple tabs.
It's not merely bad its actively hostile.
Like you note, this isn't a problem unique to Linux/"free Unixy OSes". In some ways Linux is actually worse than others, consider Gnome/Gtk Updates for example. Or how things like having a library to read a particular image format are quite normal around here; except that library has like half a dozen incompatible but actively used versions and around 1000 released versions. The Linux environment is very volatile and everything constantly changes and breaks. Modern applications bitrot exceptionally fast in Linux, while the community points to "but look this Xchess binary from 1992 still works". That's neat but covers few real use cases. The same community is then bewildered that both people and enterprises opt for distributions which move at a glacial pace and only releases updated software once every five years or so.
Edit: glib not glibc
The GNU C standard library has binary backwards compatibility going back 20 years. They take great pains to preserve that. Are you thinking of glib instead of glibc? The former is from GNOME, and the latter is not.
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.)
glib 2.0 was released in March of 2002, and has preserved ABI compatibility since then.
https://developer.gnome.org/glib/stable/glib-changes.html
Details: Bluetooth headphones with microphones actually show up as 3 sound devices, one high quality output device and a pair of low quality input and output devices. Whenever a microphone is requested, the low quality pair is selected. Output quality goes to shit and any apps that don't get the memo will still send its audio to the high quality output device which has since become an inactive sinkhole. Since many apps request microphone access for non-obvious reasons, the symptoms are that you do something non-audio-related and sound in the rest of the system does some combination of {go to shit, stop working} on a per-app basis. The solution is to disable the low quality input and output devices, which keeps sound output functional and high-quality until Windows Update reverts your settings and sets the stage for the next microphone access to break bluetooth audio again. Ugh.
Interesting. I have what appears to be exactly the same bluetooth headset setup (Bose QuietComfort 35s), and use it all day every day while at work.
I have the slightly annoying thing that if I'm in a video conference all normal audio isn't heard (unless I switch the default audio output), but I only get that when actively in a VC. I have never had 'random applications requesting the microphone'.
See for example the pages of complaints about windows forced planned reboot features deemed unavoidable from the hn majority, let alone the common users.
Any one of {Bluetooth SIG, device manufacturer, Microsoft} could have independently fixed the issue. Every one of them should have forseen it. None of them foresaw it and none of them fixed it, and years later it still lingers. Yikes.
But this is a real problem: it's not good that the Linux ecosystem has been reduced to "we shall eat whatever dogfood Redhat cooks for us". Wayland didn't even start as a RH project, iirc, and didn't really gain any traction for ages, but now it's a Big Deal because RH pushes it...?
That's how I see systemd and wayland. For systemd the consensus seems to be that's it's better than the previous init systems as most distributions have adopted it. It seems we're going in that direction with wayland but we'll see how it goes.
I think the parent comment was alluding to the fact that RedHat has the ability to manufacture consensus. All the distributions use systemd (and pulseaudio and ...) because GNOME and other core components were modified to work only with systemd. So everyone agreed to use RedHat's way because there was no other way. No matter how good RH's creations might be, that's the kind of tail-wagging-the-dog power that is bad for an ecosystem.
But the point remains that, even without any ill intent, the lack of competition and compromise can produce outcomes that look like malice -- people gradually get used to making decisions that go unquestioned, and unwittingly walk all over everyone who no longer has a voice in the discussion. This pushes more people out, and the cycle of the tail winning against the dog repeats and continues.
- Audio system that ignores all the foundations of ALSA and builds Yet Another Layer instead of improving ALSA.
- Display system that leaves way too much as an "exercise for the reader".
- 10+-year-long transition periods on the above, during which nobody's use cases work well.
- Decisions made by fiat rather than by consensus.
I'm not sure what you mean by consensus, if there was consensus on everything then we wouldn't have so many Linux and BSD distributions. We'd probably have just one or two, and you'd probably be more annoyed about "wagging the dog" if that was the case.
Just one point about ALSA; most of it actually lives in userspace. The ~/.asoundrc file can specify complex routing and mixing, including the use of LADSPA filters. What's done is done, and pulseaudio is reasonably usable now, but IMO we'd be much better off if the work that went into Pulseaudio and jackd instead went into the ALSA userland.
As well it should. Because now things that used to take three seconds will take 15 minutes for a month until you learn the new interface.
The designer will respond that yes, but then once you learn the new thing it will take two seconds. And if you save one second twice a day then you'll have made back that 10 hours you spent learning the new thing in less than 50 years!
Except that they're going to change it again in less than 50 years.
And that's assuming that the new design is actually better and not just different or worse, because also, this:
https://news.ycombinator.com/item?id=25950351
Rule of thumb: If the new thing isn't better enough to cause people to switch to it voluntarily without any prodding or the removal of the option to use the old thing, it isn't better enough to be worth it.
Not saying it is right or wrong, but a lot of the upsetting changes for existing users are for the benefit of new users.
Also, "users" are "people" and the average adult lifespan (18-78) is around 60 years. That implies that the time for the "new users" to become half of the user base is around 30 years, so what does that say about how often it makes sense to do this?
But suppose you're right. Then the solution is competition. Don't take away the old thing, provide both. If the new users want to use the new thing and the old users want to use the old thing, great.
And then if the new users still want to use the old thing you've got a pretty good red flag that you messed it up.
Your new UI might be garbage, but there's no red flag here. A new user will likely need to make use of tutorials, troubleshooting, and other help online; most or all of which will be based on your old UI (and possibly coupled with comments like, 'Don't use the new UI, it's trash. Here is how to switch...'). Having been such a new user, I only pick the new UI when forced or when it's clearly better; the former being the more common case.
Sure, you can make your official documentation use the correct UI (or design your UI in such a way that the documentation can be agnostic—but then what is this big change that makes lives better?), but unless your documentation is very good, people are still going to need to reference all these other sources.
Recently ran into this issue when submitting an app to Google Play. New interface didn’t even match up to Google’s own instructions. Frustrating.
That doesn’t add up at all... you’re implying that users are gained and lost at exactly the same rate, consistently, over a span of at least 30 years.
It doesn’t invalidate your other point about competition, but it’s a flawed argument to base any reasoning upon.
The point at which "new users" are the majority of the user base never even happens.
Edit: unless there is a majority of unsatisfied customers (:
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.
It does give you a garbage stack that solves problems though.
Remote desktop is a harder problem to be sure, but it is also a pretty common use case (window remoting less so). If you're setting out to modernize and replace such a fundamental component of Linux Desktop then you should probably have a plan for that. If not in the first spec, at least a statement to the effect that it will be part of a future spec instead of just punting to "implementation defined".
An unsecured screenshot escape hatch can be used by malicious software to scrape information shown in windows on your system, and with modern OCR being what it is (or, hell, a shady Mechanical Turk transcription job), that could be an attack vector for surfacing people's private information.
The other reason is that this isn't base functionality, for example an embedded implementation has no need for screenshots.
I'm unsure what kind of graphical environment you can imagine where screenshots are not useful at all (if only to capture the screen when something weird is going on).
For debugging purposes, the display server can just dump the screen to a file or a serial port itself. The only reason you would need this in the protocol is so other arbitrary applications could capture the screen.
Also, screen sharing is not that easy of a problem if done properly (eg. allowing another app to act on the buffer and directing it here and there)
Recent issues:
* The brightness control for my screen doesn't work with it.
* The mouse sometimes lags
* Graphical corruption in Chromium when on webgl sites.
* Blank screen after resume from hibernate.
* Seems to randomly freeze forever sometimes after an OOM killer run.
* Chromecast wouldn't work
What most people mean when they "switch to Wayland" is that they're switching from Gnome on X11 to a "pure Gnome" stack that uses Wayland and a bunch of other Freedesktop standards for interopability. There is absolutely no code from the "Wayland project" running there, because the Wayland implementation is Gnome's own (it's called Mutter). Similarly, KDE's implementation is in KWin itself. The source article is from an author of yet another window manager (Sway) implementing Wayland.
What you're observing is not "Wayland not being there yet", it's Gnome not being there yet. All of these deficiencies have nothing to do with Wayland itself: they're general QA issues that plague an underfunded Linux desktop that's making a slow technology transition.
Wayland here ends up often being the scapegoat of a Linux community that looks to want to change but can't sort itself out. The result of blaming these issues on Wayland instead of - mostly - Gnome and KDE means that we're not going to the right places to have this fixed. In terms of bug reports, and contributions of code and money.
[1]: I mean, if you can come to terms with the substantial architectural differences implied by Wayland w.r.t. to X11. But that's a discussion on another level.
People, especially people trying to work done on their computers, usually mean the former.
Unknowing users can freely associate Wayland with bad vibes due to how KDE and GNOME chose to brand their new compositors but we can do better.
But if Kwin & Mutter aren't quite shit when it was combined with X, but are shit when combined with Wayland, how does that shape perceptions of Wayland?
In an alternative universe there would be Kwin the X11 display server which would replace Xorg. I’m sure it would just be as big riddled and feature incomplete in the early years of its development.
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.
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).
For a modern example of this in action, see Bluetooth and the madhouse of device 'quirks' you have to settle with day-to-day, since each device has subtly protocol-breaking opinions on how to implement it.
Wayland is a display protocol. Practically all of the pain people are experiencing has nothing to do with how Gnome/KDE/Sway really display things differently. The pain everybody experiences is that the realization that suddenly we need a new input stack too, a new way to screenshare, a new way to do clipboard access, a new way to do a bunch of other things. All stuff that also needs to made, standardized, and achieve maturity outside of the new display protocol.
It's tempting to call that fallout of other stuff that needs to be changed "Wayland" as well, but I'd say that misses the point completely and calling it that won't help anyone get this stuff fixed.
Mind that I have no formed opinion of Wayland myself, having not used it. Trying to deduce probable causes from hearing people duke it out here and elsewhere.
On Linux, there's X11 based desktops and "post-X11" desktops. "Post-X11" would involve implementations of Wayland and Freedesktop Portals [1], using libinput [2] - and some other things I'm forgetting. All these things don't depend on Wayland and run fine on X11 too (heck you can even run a Wayland compositor in an X11 window), but most of this stuff is pretty new, implementations have lots of QA issues, and application adoption is also not fantastic. On X11 you can just talk to the X11 socket directly for what you want as a workaround, but on post-X11 you have to adopt a new means of doing it. And that hurts.
[1]: https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...
[2]: https://www.freedesktop.org/wiki/Software/libinput/
But my requirements are different from yours.
If you've been shooting yourself in the foot all your life, eventually you'll stop noticing that your foot is bleeding.
It would have to rely on compositor and driver bugs in those other platforms.
If no implementation of Wayland is ‘there’, it seems pretty reasonable to say Wayland is not there yet.
I think it can be seen in OP's list that most of the issues that OP raised are actually not due to deficiencies in the display protocol. Specifically replacing of the X11 display protocol with the Wayland display protocol. But Wayland solves fewer problems than X11. So to replace things like standardized screen recording and input processing, you need other things on top of Wayland.
And that's where by far the most issues with "Wayland" come from - stuff that has nothing to do with the display protocol, but the tremendous pains it takes to replace X11.
[1]: It's worth pointing out for fairness that X11 based desktops are also pretty flawed even if you're used to some of the flaws.
Given this, it’s not surprising Wayland has become the name associated with the overall goal.
Wayland is bad design, and it shows in the users' and maintainers' attrition.
This is not something conceptual about Wayland, or intrinsic to it. Any display protocol can have multiple client/server implementations. It just so happens that most of the free desktop standardized around the X.org implementation for X11, but even for X11 there were multiple client and server implementations.
The second thing is that software duplication efforts have a well known, tried and tested solution: implement the duplicated effort in shared implementations or libraries [1] !
The thing I find hard to wrap my head around is that this complaint is given in a community that usually champions protocol-over-implementations and diversity of implementations. The people actually making a difference on the Linux desktop are damned if they do and they're damned if they don't.
[1]: https://github.com/swaywm/wlroots
What you want at that point is to agree where to read and write common configuration. I'm not sure this is likely to happen either, as gnome has gsettings/dconf and kde has simple files and you will now awaken the plaintext vs efficiency dragon.
The current situation is just how it coincidentally turned out - there's just not always a clear direction on the free desktop (and that's even what many people like about it). If wlroots or something similar had existed earlier, then this probably would have turned out differently but c'est la vie.
edit: looks like it might already be provided via wl_output::scale [1] except you get the wrong effect that way. You want to tell the client what DPI they should render at, so that you can keep scaling at = 1
[1]: https://wayland.freedesktop.org/docs/html/apa.html#protocol-...
Why not have a shared implementation?
The codebase could be re-engineered, sure, but a lot of people championing Wayland tend to see this duplication of effort as good for some reason, and at least last I engaged with them did not like the idea of a "new X11."
Personally I think something like that is an inevitability.
It'd still solve a lot of issues that X can't.
People seem to like that we have many browser implementations but when it comes to display servers it seems like they want Chrome to rule them all.
Diversity is great but equality in failure is not helpful.
X11 is a protocol. What you mean is that we end up with something like Xorg, an implementation of X11. Which is still incorrect because a major design goal of Wayland is to move as much logic as possible from the server to the client.
I wonder how long it'll take to have a Wayland server running on the AT&T Blit...
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.
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 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.
While technically true, that is a bit of deflection. In some cases none of the compositors have implemented certain things yet.
My biggest issue with gnome is that it doesnt remember where my windows were last time I ran an app. Someone over in way-land probably should have told them that would become a their-problem so it could be addressed it sooner. Same with window decorations, they should be handled by the compositor IMHO. Sometimes a new thing should come with recommendations for use.
Deflection is entirely my point here :) These things are real problems, but they should be fixed in Gnome/KDE/Sway/wherever you find them. Complaints should be addressed there, and not at "Wayland", because "Wayland" can't fix em!
Wayland is the implementation detail in Sway to have a display protocol your Gtk, Qt and XWayland apps use to draw themselves, really no need to draw more attention to it than necessary. It's the Sway implementation that does all the magic.
asshole.
Can’t speak to Chromium or Wayland, but Chrome on Mac has this problem for me and I just had to completely disable hardware acceleration.
Overall, my Linux GUI experience has never been as smooth as it is now on Wayland and I tried pretty much all common DEs/WMs in last 8 years.
X11 is not even remotely close to being "there" compared to Wayland and if Gnome implementation sucks, then please first try better implementations first before writing comments like this.
No, Wayland protocol is not perfect and yes, some niche use cases are still not covered, which is why various extensions of the protocol are still being developed. X11 at it's current state is nothing but a collection of hacks glued together. Wayland is, however, a very robust, secure and well-designed modern protocol, which, most importantly and contrary to X11, actually works.
The last two aren't applicable, since if anything has been OOM killed recently I didn't notice, and I don't have a Chromecast.
Is it just basically a backdoor going through the hardware?
Is there some way that a compositor works with Linux security so that you need a special privilege or root or something in order to record the screen?
Something similar used to frustrate me no end when asking the Python community for help trying to solve a problem.
Regularly someone would comment, "Why would you want to do that?".
I wouldn't be asking if I didn't have a need to do it!
It's bizarre that some people can't see beyond the end of their own nose and imagine different use cases to their own.
There's a lot of people out there who are happy to tell you that you have an XY problem, but when you explain why it is not, ... crickets.
https://en.wikipedia.org/wiki/XY_problem
Unfortunately in my experience it is often followed by an explanation of why what I'm trying to do isn't what I should want to do, as though I am not aware of my own goals and constraints.
Sure, some people are assholes, but that's just people. Nobody's in your mind, they can't guess your requirements, thought process and level of experience. In my experience, more often than not, asking the question "why would you want to do that?" gets you a bad reason. "I did X this way because Y. I need Z." would filter the legitimate questioning out. From there, the others are just assholes, and those are everywhere.
As for the small differences in semantics, I'm not a native speaker, neither have outright negative connotations to me, but I feel like getting tripped up on such a small thing - and simultaneously assuming the interlocutor's intentions - is kind of overblown.
"Do", in the present tense, does not carry those connotations. It implies "I have acknowledged that your want is present and real, but I need more information about your context to be able to help."
Sure, but if I told a plumber they'd understand and help me find a solution to my problem. That isn't what happens on StackOverflow, instead they try to convince you that you have to change your problem to fit the solutions they're familiar with.
But yeah - the 'XY problem!' crowd (along with the 'But The Rules!' crowd) has also totally destroyed Stack Overflow.
It seems impossible that it will be ready for use before it is hopelessly obsolete (e.g. Windows and MacOS will be beaming images straight into your brain or something.)
Wayland is (fortunately) coming, but changing a whole ecosystem is not a small feat (even with the great backward compatibility with XWayland, because unmaintained apps will never port)
agree 1000% - really don't care about X per se, but remote windowing is an awesome and unique feature, and disrespecting it by treating it like some obscure/uneeded thing and qustioning why people are mad about it conveys alot about the attitude that i don't want to get behind
If the Wayland design was weighed down by such things, it could never hope to be progress.
But actually "remote windowing/apps" is even better supported, it's a universal proxy: https://gitlab.freedesktop.org/mstoeckl/waypipe Absolutely does not require any support from the core protocol.
X-Windows is itself a weak response to remote access. I have memories of trying to use Oracle Forms over a modem connection to uni, and finding it far inferior to VNC connections to work systems - effectively unusable.
The remote-windowing mechanisms of X-Windows are coupled to aspects of X-Windows that Wayland was created to overcome. The video 'The Real Story Behind Wayland and X - Daniel Stone' discusses this.
Microsoft Windows does not do remote-windowing in the X-Windows sense. RDP is not Explorer. From what I read, a RDP-like-thing could be built, and Wayland would not get in the way of this. I think the Wayland team make a clear case for why this is out-of-scope for them.
don't throw the baby out with the bathwater, in other words
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.
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.
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.
Complain to Slack.
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.
Wayland said screen sharing is something to be solved outside of Wayland itself. That solution is still early and not complete. It's not anybody's problem, it's just how things are. It'll get fixed eventually, in the meantime X11 still runs fine for most users and in 6-12 months switching to Wayland should have fewer tradeoffs. Until then Wayland is missing some use cases X11 easy fulfills. Unfortunately X11 is also missing many use cases Wayland fills. As a result we should expect different users to be better served by different answers about how ready a Wayland environment is for them and both to be equally correct.
Screengrabbing during the last year was even better than what X11 could provide, including the ability for the user to limit the grabbing to display or window. That's something that user cannot have under control in X11.
Pipewire is also not limited to Wayland; it will work with X11 too, so the X11 users won't be abandoned just because there's Wayland support too. Firefox doesn't seem to have problem with it, Chrome has it behind flags. For apps with fast moving releases as these, I don't see any problem with them supporting 0.3 release and when/if there is API breaks, updating it.
Beats not supporting screen sharing under Wayland at all.
I.e. it's not that the tech stack or architecure is the wrong it's simply not done yet and not done to the point it's a bit silly to blame Slack for not enabling it.
It's also not the fault of wayland/pipewire/chromium/electron/slack for not all simultaneously releasing working screen sharing but it is a mistake to say you can switch from X11 to <Wayland stack> and not worry about screen sharing.
I use pipewire for screen sharing, I like it, but its not a fully baked stack and won't be for some time yet.
Are you sure? I'm pretty sure I had two tabs, one for picking displays and other for picking windows. Pretty much like this: https://bug1675764.bmoattachments.org/attachment.cgi?id=9186...
"Will this let me share individual windows?
No, only entire outputs. It would take significant work in wlroots, and likely a new protocol, to make this possible. A second rendering pass would be required, which would significantly reduce wlroots performance, so this may not be implemented any time soon (or ever).
Will this let me share all of my outputs/displays at once?
Not yet, no. It will likely never create a single stream that combines all of your outputs, but once we implement better output selection, there is no reason xdpw cannot create multiple simultaneous streams of different outputs."
So it looks like I'm shit out of luck for quite a while on sway/wlroots. Looks like Gnome figured it out. Not sure about KDE.
Thanks for the constructive and informative discussion.
https://github.com/emersion/xdg-desktop-portal-wlr/issues/12
https://github.com/swaywm/wlr-protocols/issues/93
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.
To be honest I don’t see how you can understand the first bit but not the second. Yes, they can make changes that you don’t like without consulting you.
Commercial software, like most things in life, is responsive to incentives. The people who buy things get the most say in the product.
For open source where the end users aren't buying anything, and the developers are either creating product for their own gratification, or for some more nebulous corporate goal, the incentives are rather indirect. And that makes a big difference. Software, under those conditions, will frankly be worse for the majority of users.
This seems to be the dominant culture, but it's actually pretty toxic that people feel entitled to whine about software created by people who owe them absolutely nothing.
Constructive feedback is useful, and appropriate if the creator indicates that they want it.
Whining and ranting is a waste of energy. It makes people feel bad and leads to no beneficial change.
I don't think Drew DeVault wrote this because he's received lots of useful constructive feedback.
What makes you think people owe nothing to each other in the open source ecosystem? I maintain a package for Fedora, I have submitted a few patches to the Linux Kernel, and I regularly report bugs. Do the Wayland developers not benefit from any of the above?
Even my mother, who is not very technical, has managed to identify bugs here and there which I report on her behalf. Do the Gnome developers not benefit from that?
We cannot all be contributors to every package we use, but we are all part of an ecosystem and we all have the right to ask for changes by others in that ecosystem. You call it whining, but you know what? When developers break use cases, users have the right to complain about it. If the Wayland developers do not want to hear those complaints, they should not be involved in developing software that millions of people depend on, nor should they have tried to replace software that millions of people depend on.
Actual contributions are another matter. If you contribute to a project, then sure, you should get a say proportional to the size of your contribution. And I wonder how many of the people who complain about Wayland have made sizeable contributions?
An important point here is that it's up to the maintainers to evaluate the value of your contributions from their point of view. If you don't respect this, you're again trying to impose obligations unilaterally. That is, offering help that may not really have been wanted in the first place and then expecting something in return.
>If the Wayland developers do not want to hear those complaints, they should not be involved in developing software that millions of people depend on, nor should they have tried to replace software that millions of people depend on.
This seems way off base to me. I hope this attitude is not pervasive because it seems like it's a huge discouragement to people who want to write useful software. (If you succeed to any degree, millions of people are automatically entitled to shout at you whenever they experience some inconvenience.)
How many people asked for their distro to switch to Wayland?
You seem to think that these critical packages that millions of people depend on can be treated like hobbyist projects. Yes, when your project is a hobby, you can tell people that their complaints are not your problem and that they should just fork the code if they need something different. However, distros should not make hobbyist projects core components that users are unable to avoid, nor should anyone push their hobbyist project as a replacement for a core component.
The fact is that the Wayland developers set out to replace X11. In what world are they not opening themselves to criticism from people whose use-case was supported by Xorg but not supported by Wayland? By now a decision made by the Wayland maintainers will affect the vast majority of desktop Linux users; why should they be immune from complaints? When people depend on your software you have to deal with their complaints, that is just a fact.
I don't think that's quite right. It's certainly bad manners to be rude, but the underlying complaints are one of the better - if not best - means by which the people who make the software can get feedback to ensure they're building the right thing.
Would you invest in a startup whose founders constantly complained about how their potential users whined about their product?
Aside from auxiliary revenue sources like complements and consulting, open source software has value in large proportion to how many people use it. Reputation and goodwill, if nothing else, bragging rights, job opportunities, and so on. You don't get these things from writing software than isn't used.
And you can't really expect everyone to provide constructive feedback. Often, the more emotional the rant, the more pain the user is feeling. Not all humans are dispassionate rational agents. Not every user is a professional product manager able to outline constructive incremental improvements to satisfy requirements. And it's silly to expect that. Product managers are paid well in industry to do this. Doing it for free for open source is just as much a donation.
I'll go further. If you're not willing to tolerate more and more rants as your software gets more popular, to the point that you end up not contributing or quitting, it might be better if you didn't start. Abandoned and decaying software hurts too, and it especially hurts the people who took a bet on it.
(I learned my lesson young. I created a few bits and pieces of open source, and quickly found the the effort of integrating the contributions of third parties more work than it was worth. The only way I'd do open source again is as a developer outreach / organization halo PR strategy for the benefit of a company I'm being well compensated to work for.)
If someone relies on a piece of open source software on the assumption that it will be maintained in perpetua for free, then they’re simply foolish, and they have only themselves to blame for any resulting harm.
> Not all humans are dispassionate rational agents
You seem to be forgetting that this applies just as much to the people who maintain open source projects. The endless negativity inevitably has an effect.
People in charge of large FOSS projects like Gnome should not pretend it's just some hobby project they can do whatever they want with. Those projects are essentially public infrastructure and should be treated as such. It's not their personal plaything.
Yes, people who do the work have the most say, but sometimes they really use that to do stupid things with the code. I don't know how to correct that though. Commercial software is no better about this.
They're not pretending. I'm afraid you're laboring under a misconception. Nothing obliges the GNOME team to accede to the wishes of people who contribute nothing to the project.
Nothing, until users flee and they stop receiving bug reports, patches, donations, and so forth. Moreover, because of what Gnome is, if they drive users away it will also negatively impact other projects, because for a lot of those users leaving Gnome means ditching open source software entirely and switching to e.g. OS X.
Part of the joy of open source are the freedoms it gives you, including the freedom to fork a project that doesn't meet your needs and make it so that it does. This works as it should pretty often - look at the gnome2 forks, the systemd-less distros etc. There's plenty of choice out there, and plenty of opportunity to get involved.
If you're unwilling to exercise those freedoms, then you're just whining about the stuff you're getting for free.
Losing users is always a bad thing for the open source ecosystem. Lost users means fewer bug reports, fewer patches, fewer donations, and less support from paid developers working for various corporations (easy to forget but there are people whose job is to maintain open source projects like the Linux kernel). Fewer users means less incentive for hardware companies to provide any support, even just minimal technical documentation, needed for open source developers to write drivers (let alone contribute to that).
Forks require a significant commitment of time and effort, and really should be considered a last resort. The time commitment is much greater for prominent projects that receive a lot of activity like Gnome or Linux. Most users, even those with the necessary technical skills, do not have enough spare time to maintain a fork when things break.
Your dismissive attitude is fine for a obscure hobbyist project with a dozen users. It makes no sense for desktop Linux distros that now have many millions of users.
I understand that people can be aggressive, rude, and downright hostile. I'm not suggesting that such behavior be rewarded. Nor am I suggesting that every open source project has to do everything any user says. I do, however, object to the notion that there is no obligation whatsoever between the producer of a technology and the users of that technology, regardless of whether money has changed hands.
I agree with that, projects should clearly state their goals and priorities upfront. But relying on legalese from MIT license is not the solution.
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.
I said nothing of the sort. They have an obligation to the project and its value as a piece of infrastructure used by many (including noncontributors).
Pretty sure they are aware of this, even Gnome. Gnome's Dev Team is often citing user studies etc. and I believe they are genuine in trying to produce software for the public, rather then themselves.
...Though I believe they don't grog how disruptive changes (any change) can be.
The option always remains to change it yourself or stop using it. It's not as if it's bound to the hardware (Apple) or shipped with the machine (Windows). It's not a SaaS that may vapourise or change underneath you.
There's no way to force consensus in situations like this. The best you can do is force out those maintainers you don't like with a harassment campaign.
If I changed every bit of software I dislike, I would have no time left for my actual job. Yeah, I get it, these volunteers found the time to work on this one project and therefore get more of a say about what changes will be made, but you know what? They also have to use other software, and they would not have time to work on something like Gnome if they were busy making changes to Wayland or the Kernel or whatever else.
Worse, in my experience, Gnome developers will turn down patches that do not align with their ideas about how things should work. I have had it happen to me, I have seen it happen to others -- even when we find time to change something, we cannot commit to maintaining our own private fork, and dealing with merge after merge or trying to keep up with a project that has as much activity as Gnome or Wayland. Obviously some patches need to be rejected, but in the case of Gnome I have found that rejection often comes down to their notorious "less configurability is better" attitude.
As for stopping using it, how does that work with critical packages like systemd? At some point you wind up having to ditch an entire distribution, with all its infrastructure and maintainers, just to get one use case to work. In some cases you are left with a choice between a project that has the features you need but has received no updates (including security updates) in years, or a project that does not have the features you need but is actively maintained. More often than not people will just give up on their use case, which in some cases means giving up on open source software entirely since that use case was the reason they were using open source in the first place. Some might think that is fine, users have the freedom to choose what software to run, but the fact is that fewer users means fewer contributors (including many people who make only the small but very important contribution of reporting bugs) and a less robust open source ecosystem.
They don't get "more of a say", they get ALL the say. This is the way of Free/Open Source.
As for stopping using it, how does that work with critical packages like systemd?
It works the exact same way. If you don't like it, don't use it. Simple as that.
It doesn't - you are completely free to roll back those changes, or make different changes of your own.
Maybe.
I think the discussion should happen.
Because I don't think "I wrote it, if you don't like it, you write it" is a 100% defense to hordes of upset users.
"Facilitating the unrestricted use of extensions and themes by end users seems contrary to the central tenets of the GNOME 3 design."
I don't ever remember cursing my Windows 3.11 machine that the scrollbar and toolbar icons were distracting in File Manager, nor do I crash my car when the speedometer changes and wish that the distraction of the speedo and rev counter was removed.
I remember using GNOME2 and loving it.
I often wonder constitutes a "power user" - someone who wants to actually get stuff done and not fight the UI to discover things??
I wonder when iOS became the ideal - blindly fumble around whitespace to see if some text is actually a button or if there is some unfathomable control hidden that you need a magic incantation to discover (swipe left on a list control is delete - my mum still doesn't know this)?
Is a "power user" someone who has learned all the different ways of interacting with a modern user interface? You used to learn: click, double-click and scrollwheel. Now every interaction with a control is different and impossible to learn or discover simply by using it. Absymal.
Gnome more or less optimizes for minimal configurability, the theory being that most users want the UI to be as clean as possible. They do not particularly care if someone would like to be able to change some annoying behavior, because they thought that behavior made sense and they feel the cost of adding a button to disable it, or even burying a configuration bit in gconf, is far too high. Of course, they do not have the resources needed to run actual user studies the way Apple, Google, and Microsoft do, so their idea of what users want is mostly based on their own ideas about what users want (since they usually dismiss feature requests from their actual users, because those are "power users").
"There was only one catch and that was Catch-22, which specified that a concern for one’s own UI in the face of flaws that were real and immediate was the process of a power user. Orr was an average user and could be listened to. All he had to do was write a feature request; and as soon as he did, he would no longer be an average user and would have to be ignored."
Also it doesn't even show hibernate button on the "start menu" (or whatever it's called these days) - because apparently the ability to actually power down the box while keeping all states is too confusing to have!
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.
It truly needs its own fractal of bad design essay save it would have to a farce in 7 parts.
To say that they targeted a different kind of user is insufficiently descriptive. 3.0 was the beginning of ticking off the users they actually had in order to target users they wish they could get with a total package that such users could never encounter in a million years because joe average wasn't installing Linux in 2011 regardless of how simple you made the interface.
9 years later the Linux user base is virtually unchanged and gnome 3 is no longer horrifying as 9 years of labor have rendered it modestly acceptable after the worst ideas were put off or mitigated.
If you spent 300k building a hovel where the roof fell in quarterly and you after much consternation and a decade of work figured out how to keep the roof mostly in place most of the time I would pretty much expect such a project to be the go to horror story among home builders in the neighborhood.
This isn't meanness its just honesty.
GNOME has tens of millions of users.
I do understand your sentiment. I don't like GNOME myself. But there are alternatives. If you don't like it, try using something else, contributing patches with configurable behavior or maintaining a fork.
FLOSS maintainers are a rare breed. We as a community need to find ways to not burn them out. Even if you have millions of happy users, just a couple of really toxic ones can make it feel not worth it.
I was referring to the hundreds of users who "reacted" to the bugzilla thread on this issue, but I'm sure it effects many many more.
> I do understand your sentiment. I don't like GNOME myself. But there are alternatives. If you don't like it, try using something else, contributing patches with configurable behavior or maintaining a fork.
Generally I don't use GNOME, on this occasion I was working on a laptop supplied by an employer. The frustrating thing isn't that they don't support a feature that I want, it's that they strip away features that existed before, and completely ignore and talk down to users who tell them that the feature is very useful and much wanted.
> they strip away features that existed before, and completely ignore and talk down to users who tell them that the feature is very useful and much wanted.
I'm under the impression that GNOME strives for similar UX to macOS. This behavior sounds just like Apple to me, so maybe it's just the correct way to do it.
I've used both macOS and GNOME as daily drivers and got frustrated with both. I'd certainly get frustrated if an employer forced me to use unsuitable equipment (and some have in the past). But that's not the fault of GNOME developers.
Those hundreds of user are:
1. A vocal minority, most likely. People happy about it don't go on bug trackers to support devs.
2. Not making the software, not part of the decision making process. Don't like the end result ? Fork it if you have the ability. Give constructive criticism if you want and you think the team is receptive to it (or even cares about it. Sometimes, I just don't want your genius idea).
So, yes. They're doing this for free. Don't like it? Fork it, or don't be an ass. If you can't do either of those, the third option is to fuck off.
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.
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 am not sure what you mean here. Weston, the original implementation, includes support for screenshots, screensharing and RDP. Other implementations decided to implement those in a different way, for various reasons. The way to not "punt" this would be to use libweston but that has its own set of issues, and it seems strange to blame the Weston hackers for not upstreaming every single other thing that some implementer is working on.
I'm not fully up to date on the state of these things, but if the different implementations doesn't have a common interface it's goodbye to ever having screensharing work for everyone. I think that's what the parent means.
If we're lucky Discord/Zoom/etc. will implement it for the most popular compositor(s).
Similarly with screenshots - even though it's a much simpler problem it's annoying if the program taking the screenshot is fundamentally bound to a specific compositor.
If I'm not mistaken there are standardization efforts underway today though?
No, not really. In practice what happens is Discord/Zoom/etc do implement it for the most popular compositors and then the other compositors follow suit if they want to support those applications. You would be complaining even more if they only supported weston because their screencast mechanism is pretty limited, and it would suck if the other ones just copied that.
The current "standard" is to just use pipewire and have the display server talk to the pipewire server, most commonly using xdg-desktop-portal. This is obviously outside the scope of Wayland, because any application can talk to pipewire and share/receive a video stream. I don't know about Zoom, but Chromium has support for this in the works, so Discord should get that eventually from updating their Electron: https://github.com/electron/electron/pull/26022
You can still use Xorg on most distros. In Ubuntu it's one checkmark.
Why do you feel the need to announce this to anyone, particularly the people who work on it for free and owe you nothing? Is that not his point?
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.
>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. :-)
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.
It's not just about replicating this functionality. It's about having an open framework that makes building these tools, and other unforeseen tools, easy. X11 was very accommodating of this.
For example, I like to run xsnow during the holidays. Wayland's answer to xsnow is -- we don't support that, but tell you what, draw up an RFC for a D-Bus API for desktop snow and wait 5-7 years for compositor implementors to consider incorporating it. Or something completely different. You know, whatever. It's like you have to prove your use case is valid to the community before you can even start hacking on it in a way that you can expect it to work with more than one DE.
For Wayland the attitude is "Fuck you. You get a buffer for a desktop window and that's it. [Wayland does not support nested windows.] Oh, that's not enough? You're not writing a desktop app? You want snow on the desktop/a desktop magnifier/a hall of mirrors effect toy/an anime window sitter/pinnable menus/something that responds to global hotkeys/etc.? I'm sorry, did we not anticipate your pwecious widdle use case? Fuck you. No one actually writes applications that way any more, nerd. Go back to the nerd table. We're trying to get the cool popular Mac-using kids to notice us here."
The X11 security issues are mitigatable with some changes to the server implementation. The Wayland approach really never was about security. It's about letting the cool kids define the shape of the Linux desktop to the exclusion of ordinary users/hackers.
FYI there is some prior art for poking a security hole in the Wayland server to support X11 features, but obviously not all implementations will want to support this: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/b...
This is inimical to the design principles of Wayland, whose security policy is to isolate all clients -- no exceptions, no escape.
The 1984 Mac was largely a novelty, but it was one that demonstrated possibilities. There are non-novelty applications that are precluded by Wayland. Something like EXWM could not be done. You cannot write a standalone virtual-desktop switcher, it must be integrated into the compositor. Et weary cetera. Wayland is very opinionated about the kinds of programs you can write for it, and if you want to go beyond that you must traverse the step function into "write your own compositor".
But criticizing Wayland on a pure comparison basis, clinging on to Xorg server – absolutely doesn't benefit anyone, including whoever is posting it.
X window system (the idea) and Xorg server (the project) – is kind of abandonware [1] at this point. The last release was in 2018.
Don't want to get into random philosophy about contributing vs complaining vs criticizing, etc.
But in this situation – there's just a definitive community health benefit in moving on. Not complaining, not contributing, but just moving on. There is no further value left to be added in any comparison.
1: https://www.phoronix.com/scan.php?page=news_item&px=XServer-...
Then why not include an example compositor that solves these issues?
>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.
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.
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...
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 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.
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.
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.
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.
"It's a perfect compositor, as long as it is not expected to composite." ;)
Personally I need the ability to open a remote window on my desktop, fingers crossed that someone will add that.
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.
chromium --enable-features=UseOzonePlatform --ozone-platform=wayland & disown & exit
You can also adjust your .desktop Chrome launcher to use these flags
Steam works fine. What exactly doesn't work for you?
"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.
Examples (in order of importance to me):
Until Wayland has all these (and more) and they are as stable and feature-rich as the existing apps on X, I will not willingly switch to Wayland.PS: ydotool has been touted as an equivalent of xdotool, but ydotool has only a tiny fraction of the features of xdotool.
And it's unlikely that it'll get much better any time soon, as its README says:
"Since Jun, 2019, I have little time to maintain this project"
wtype is supposed to be another equivalent to xdotool, but it has even less features than ydotool.
If the rest of Wayland's X equivalents as feature poor as these, I don't hold out much hope for Wayland in the near future.
[1] - https://old.reddit.com/r/wayland/comments/85q78y/why_im_not_...
https://blogs.gnome.org/wjjt/2012/03/14/looking-around-wayla...
No hate, just a practical problem being solved. No one is forcing you to shift prematurely, although assistance is always welcome to fix your usecase.
There are also a few forks on GitHub with native wayland patches out there too if `feature/pgtk` doesn't.
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".
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.
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.
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.
> 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.
[0]: https://boilingsteam.com/amd-vs-nvidia-are-linux-gamers-swit...
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.
Only the first group is the problem, and I think noone is bothered by the second.
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.
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.
TL;DR Theoretically libinput is a linux-wacom replacement.
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.
...
Really? "Us, open source devs demans nvidia to alter their ways". And you wonder why people are disappointed in wayland?
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.
With that in mind really nobody can wonder why NVIDIA market share is continuously getting smaller in Linux systems https://boilingsteam.com/amd-vs-nvidia-are-linux-gamers-swit...
Do you thing Nvidia would ignore them, like they ignore Linux?
On some platforms (Mac) they don't have that opportunity at all.
Drew wrote a blog entirely devoted to the Nvidia issue: https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html
Unfortunately, Wayland is dead in the water until it can run on Nvidia machines, and no amount of blog posts will change that.
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.
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
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.
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.
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.
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?
Yeah. Nvidia is engaging in shitty behavior, and I've outlined my argument for this. It's shitty to reward this behavior by buying their thousand-dollar GPUs. And, yes, I think that doing so anyway makes you a shitty consumer. And, yes, I don't want you in my userbase if you've made that decision. It's not my problem when shit breaks for you because of that.
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.
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.
[0]: https://github.com/dusty-nv/jetson-inference
[1]: https://github.com/jkjung-avt/tensorrt_demos
[2]: https://forums.developer.nvidia.com/c/agx-autonomous-machine...
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.
Basically I would say it doesn't work.
- 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".
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.
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.
> 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.
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.
Look at the sibling of your comment (link for brevity: https://news.ycombinator.com/item?id=26004250).
And other -ve comments on HN.
and so thoroughly documented! /s
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?
From your link.
Oh, hey. That was hard.
If you have nVidia, you're outta luck.
intentionally crippling a DE out of spite so it cannot run on the drivers i use every single day is also a crappy look. https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html
> 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.
tell that to DDV :)
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.
> 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.