I wish KDE and Gnome efforts were consolidated - that would have sped up the progress of the Linux desktop, but what can you do. I personally prefer KDE.
Stuff like switch to Wayland takes decades because of this split.
Stuff like switch to Wayland takes decades because of this split.
My understanding is the switch to Wayland has taken ages because basically everyone who thought it would be a "quick" thing vastly underestimated the number of stakeholders they would need to get on board with the change and how much work would need to go into making those people consent to switching.
Also, because X works over a socket, it’s language-agnostic in a way that a library just can’t be: libraries like CLX allow Common Lisp graphical applications with no dependency on a C library.
I keep reminding people that one of the most known models for security is "confidentiality, integrity and availability".
If it isn't available your security is still somehow broken however well one scores on confidentiality.
It looks useless now but without every part being fixed individually it will be impossible to create a secure linux desktop that runs proprietary applications.
I don't see why this is an issue. The user still has full power to do anything and its is only programs which are restricted. Under the new model, instead of a tool just grabbing your screen, it must now make a request to the OS which will show a popup asking if you want to allow access and if you accept the program can continue as it would have before.
About depending on C code, Wayland is pretty much the same as X11 there. If you don't want to use libwayland, you can write your own implementation of the wire protocol.
If you consider linking against libGL and libEGL to be okay but not libwayland then there actually is a workaround: forget the EGL wayland platform and have your custom wayland implementation use the EGL GBM platform. There's some extra code you have to write here but unless something changed that I missed, the same problem exists with Xlib if you try to use the EGL X11 platform, or if you want to use direct rendering in GLX. (Mesa's libEGL/libGLX links against libX11 and expects to get a structure with the C ABI. Keep in mind if you are using GLX calls in that CLX library, you are probably not getting direct rendering, you would have to do a similar thing and reimplement the DRI2/DRI3 path from Mesa in your toolkit or application)
I don't share your pessimism.
Yes, it is harder to exploit users with [FLO] software; so there is less profit to be made; and that will discourage some companies from making it. But I can easily imagine that with a modest income from donations, a project like [Black Mesa] would be happy to make their game open source. Also yes, most software projects today cannot make a living off of donations. But there's no inherent reason this has to be so. People have shown they are willing to pay money for software; in principle, it is ["just"] a matter of redirecting that money from proprietary software to FLO software. And yes, solving the free-rider problem is a very ambitious "just".
But addressing a collective action problem like this requires a coordination mechanism, and the [existing crowdfunding platforms] don't have that. So, I am actively working on one that does — [Snowdrift.coop] — and am not yet ready to throw in the towel.
> But we can sandbox them. Even open source tools could do with being sandboxed.
I agree, but I don't think the operating system is the right level of abstraction to do this. Sandboxing is complex. Implementing it in the OS pushes that complexity on every program, which makes tinkering much harder. I absolutely do not want to have to deal with sandboxing and permission prompts in my .bashrc aliases and shell scripts. I write shell scripts to make my life easier by automating common actions, and having to set flatpak/SELinux type permissions every time I do that would defeat the purpose, or at least substantially raise the bar for how much friction is required before I turn to a script. Writing a simple program on Android/Linux is soo much more work than writing one for GNU/Linux, and soo much less accessible.
Also, we already have an excellent application sandboxing platform for running untrusted and borderline malicious programs — the web. The result of that sandboxing is incredible complexity which makes it a herculean task to develop a web browser. That's a real shame; I'd love to see the "web of documents" split off from the "web of applications" (e.g. to a different protocol, like gopher). I don't want to see desktop environments go the same way. When I install and run a program natively, I am indicating that I trust it and want to leave the restrictions and complexity of the web sandbox behind.
I do see a case to be made for a sandboxing tool for graphical applications specifically. Because building a GUI is already a lot of work compared to writing a CLI, so the relative effort to handle permissions, etc is not as large. But this should be built into and enforced by the packaging tool (e.g. flatpak permissions), not the operating system. And, to bring this discussion back on topic, not by the display manager.
Here's a concrete example: I use Mumble for voice chat. I use push-to-talk. [PTT on Wayland] doesn't work, because the display server only sends keyboard events to the client that has focus. You can look at the linked issue and see all the complexity that results. So for now I am still running X. Yes, there are workarounds. No, I don't want to have to deal with them. Not having to deal with them is the kind of nice thing we can't have if we accept sandboxing by default, rather than sandboxing only the few programs that we cannot trust to run directly on our machines.
---------------------------
[FLO]: https://wiki.snowdrift.coop/about/free-libre-open#flo
[Black Mesa]: https://store.steampowered.com/app/362890/Black_Mesa/
["just"]: https://blog.snowdrift.coop/crazy-ambition/
[existing crowdfunding platforms]: https://wiki.snowdrift.coop/market-research/other-crowdfundi...
[Snowdrift.coop] besides the main site, our wiki has more/better information: https://wiki.snowdrift.coop/
[PTT on Wayland]: https://github.com/mumble-voip/mumble/issues/3243
Not really. Engines can be open source, you don't need to make art assets open to use them.
Projects like Godot are progressing well.
That's a scary one IMO.
I mean, if you are a dev who has devoted an enormous amount of your efforts into making a replacement for the stuff that displays all the stuff from all the other GUIs, seems like the identity function would be recording the shit you're displaying. The fact that OBS doesn't yet work under Wayland makes me wonder if sufficient (or any) dogfooding is going on.
It'd be like if in the 90s you still couldn't easily compile code from inside Emacs. It's a smell.
(Disclaimer: I did some of the work on this port)
For the record:
* I'm running Debian bullseye
* I'm running Gnome version 3.38.2
* I'm running OBS installed from apt: version 26.0.2+dfsg1-1+b1 (64 bit)
Given a poster on this thread boldly claims that "Wayland is already done and ready," I'd say my setup is more than recent enough to test whether that claim is indeed usable in practice.
Lo and behold, when I run OBS I get a blank screen staring back at me.
If I log back in with Gnome running under X11, OBS works just fine.
It's wonderful that the issue is being addressed, and I thank you for your work on it. But my point is that Wayland+OBS working together is a litmus test. The fact that the two are just beginning to play well is a big red light to me switching away from X11 any time soon.
Anyway, that "done and ready" quote is really the source of my frustration. If I have to set an arbitrary timeout after a "loaded" event to get it to work properly, "loaded" is a probably misnomer.
We're talking about two different things.
You're talking about whether Wayland devs are ready for other devs to start leveraging their work.
I'm talking about whether any Wayland-based distro is ready for a stable release. Clearly none are if a best-in-class screen recorder just gained the ability in a dev branch to recorder the screen under Wayland.
Ubuntu understands what I'm talking about-- 20.04 is not Wayland-based, and I doubt it took look for them to make that decision.
Whether best-in-class applications run correctly under Wayland is a perfectly reasonable and practical metric for Wayland's current value to users.
Also, most DEs have really good backwards compatibility thanks to xwayland - because frankly some app will never be ported. (Also, accessibility is unfortunately quite the last thought on even paid platforms - and last I heard it was not all that great to begin with on linux)
On X11, a client can view the contents of any arbitrary window, simulate input, read input — this is necessary obviously for screen sharing applications; though one can argue that maybe a permission model needs to exist to allow some clients to run with lower privileges — the funny thing is that it does; it's called te XSECURITY extension, it's very easy to use, and seldom used for whatever reason though SSH uses it whenever it can.
On Wayland, no client can do such things, but many clients such as screen sharing tools, profiling tools, and whatever else that needs to simulate input and read surfaces obviously needs to.
Wayland developers simply say “It must be built into the compositor”, but no compositor can be expected to provide all that, and no compositor does.
>no compositor does
This is not correct. GNOME's compositor actually does support screen sharing, sharing of individual surfaces, and simulated input. And I'm not entirely sure what you mean by profiling tools, can you elaborate?
Also, wayland also uses sockets..
I'm all for Wayland transition, but things could benefit from concentrated efforts for sure.
Wayland removed many features and use cases from X11 because they thought no one used them. This is what happens when isolated developers without market research make the shots I suppose.
Originally libinput did not even offer a way to disable mouse acceleration as they thought no one would ever do that — anyone who plays video games would obviously laugh at this notion since the præcision required for many video games is completely compromised by the floaty feel of m.a., but they don't play them I suppose.
Talking with many of the Wayland devs reveals their ignorance, this would be fine if they were willing to listen, but at this point it has clearly become an issue of tribalism and because they probably heard it so many times they simply become defensive now as admitting it this point would be admitting defeat an that they were wrong, with pride on the line they continue to insist that one does not “need” these features because the compositor can provide everything, yet no compositor exists that does and it would be madness to expect any to.
However, the original designers of the X11 protocol no longer even work on X for the most part, and some of them are dead.
And even with the hardware it was inherited, it is true that the developer of libinput was the maintainer of synaptics, but he did not originally designed it, and found useless many of it's features that he was forced to maintain for backwards compatibility — with libinput hwas free to drop them, and initially did, but after many complaints has yielded to bring some of them back.
synaptics and all the Xorg input drivers are really quite configurable allowing one to even edit the transformation matrix used for pointer acceleration directly, or to manually control the size of the touchpad scroll region, or configure rather præcisely via what criteria palm detection works — Hutterer originally removed this from libinput and considered it unnecessary overkill, but has later restored much of it after complaints, finding that many users indeed used and configured this.
Wayland is a display server - xorg started out as one as well, but it got extended to such an extant that at one point it contained a printing service as well. Wayland goes back to the base problem - how to display a window on a/many screens - and solves it splendidly. And leaves the rest to the actual desktop environment because it is not display related. UNIX phylosophy is not all that sexy when it is actually useful is it?
But wayland developers were clever enough to add a proper extension management system so a client can query what is available and use what’s given.
Does implementing wayland by multiple DEs consist of some duplicate work? Sure. Should we not refactor all the technical debt that accumulated over DECADES to the point where a new hardware was introduced? I think the answer is no.
And I’m not sure which group is tribalist, the ones who blindly hate on something because - surprisingly - without work there would be nothing, or those who make the new thing usable.
Fedora is probably the only distro actually pushing things forward without being tied down to vendors. When CgroupsV2 came out it was disabled for many years because docker didn't support it. Until fedora decided to turn it on and suggest users use podman instead which got docker to update to v2.
Because of all that I'm still using X11 session.
A very simple reason that I can't use Wayland is that I have a piece of software I sometimes use that is bugged and doesn't properly exist when it's window closes at times, so I actually run a very simple daemon that checks whether the window is gone, and if that be so, sends a signal to close it that way so I don't have to do it manually every time — I can't do such simple things on Wayland because asking for a list of all open windows is “insecure”.
busctl call --user org.gnome.Shell /org/gnome/Shell \
org.gnome.Shell Eval s \
'global.get_window_actors().forEach(w =>
w.meta_window.wm_class == "firefox"
&& w.meta_window.delete(global.get_current_time()))'And, you know, developing a complete desktop operating system. (Fedora's developers are its users, almost universally).
Writing software is really not something that is demanding of the features of a display protocol — and that Wayland is developed by those that write software without consulting users that say, play videogames is why it's so lacking.
At the end of the day, playing even the simplest video games tends to be more of test for the merits of a display protocol than writing said video game from scratch, without playing it.
https://www.debian.org/releases/buster/amd64/release-notes/c...
Debian 10 "buster" released July 6th, 2019