I'm not some anti-wayland zealot but you will pry xfce out of my cold dead hands.
Hard same. I'm using xfce on my laptop with mint xfce edition, and it's a breath of fresh air. Everything just works how you'd expect it to work, and it gets out of your way.
I tried sway a couple years ago and I lost count of the number of things I needed to go and find wayland specific workarounds for. I know things have gotten better since then, but I didn't see any benefit to switching and a whole lot of hassle.
Wayland is now about 18 years old. So, by Wayland standards, only 3 more years until it, too, will be obsolete and need to be replaced.
That day can't come soon enough. :D
Maybe the next one will actually be able to do the things I need a display system to do. Until then, at least we've still got X11. And Wayland has taught everyone all sorts of things about what not to do.
BTW, what's the policy on that sort of thing here?
I often still use just ALSA, but pipewire is at least pretty decent and mostly "just works". Unlike pulseaudio, which was kind of a plague on Linux audio for ages.
On that note, for about 15 years, a funny thing kept happening. Any time anything on my Linux boxes broke, I'd trace the issue to its origin (bug hunting was literally my job, after all), and about half, maybe even two thirds of the time... it traced back to Lennart Poettering. That man was singlehandedly responsible for more than half the bugs I encountered for a decade and a half. It became so routine that I started practicing my impression of Severus Snape, so I could shake my fist at the sky and exclaim, "Poettering!!!"
Anyway, Wayland feels like another one of those... where someone has to do it wrong and create a lot of trouble before someone else comes along to do it right. But that second part hasn't happened yet. So it's still in a broken state where half the stuff I do on a daily basis isn't even possible in Wayland.
For the life of me, I'll never understand how wayland got traction with the community.
'Hey guys, we decided to implement a display server from scratch! We broke a ton of existing functionality and made a ton of low level stuff that X used to handle the responsibility of WM/DE devs!'
A lot of the "existing functionality" that it broke has nothing to do with displays, it's stuff that got crammed into Xorg at some point whether it made sense or not.
I find it quite funny that many of the same people that rag on systemd and say it does too many things, are big fans of Xorg doing a bunch of things that "display server" probably should not be handling.
Even if Wayland was a "display server", it would still "remove existing functionality" if it meant that in any principled sense, because "display server" is only half of what Xorg does.
But sure, the transition was difficult and took a long time.
I, as an end user, do NOT care.
>A lot of the "existing functionality" that it broke has nothing to do with displays, it's stuff that got crammed into Xorg at some point whether it made sense or not.
I also don't care about ivory tower ideals of what is within the dominion of 'display' and what is not. The fact of the matter is their changes broke a ton of functionality, and instead of even trying to provide feature parity, they basically dumped all that responsibility onto the WM/DE devs.
I have no idea why the community didn't take one look at their proposal and flatly ignore them.
In other words, the Wayland people should perhaps have defined official protocol extensions early on to cover most of what X did, thus preventing all the initial interop issues when Gnome and KDE and Sway tried to reinvent them independently.
1. Add GBM to graphics drivers and start working it up the stack from the bottom, stopping at Xorg. That is, make rootful XWayland the standard Xorg before standalone even is a thing. This reduces maintenance work up front rather than belatedly.
2.a. Implement weston as a standalone compositor.
2.b. Actually make weston fully functional. Figure out everything needed to provide an actual working desktop environment with the features that users expect out of the box. Standardize all the protocols needed for at least a basic XFCE-ish environment rather than hoping someone else will do it.
3. Then, only after these things are done and working, announce to the world that wayland, a quiet project that has until now explicitly suggested nobody use it, is now the future of linux graphical systems and everyone should plan to migrate.
Can it do new things? Eh, probably not. Do I need it to do new things? Not really.
At the time, RedHat basically controlled Gnome via paid devs and donations. And the same for this Wayland nonsense. Oh, and systemd too!
Notice a pattern?
Sure Xwayland exists and mostly (not entirely) works, but that's a band-aid for what is essentially a "we broke it and don't care" approach.
This is a huge part of what "user/dev hostile" means in my book; with Wayland, getting a working desktop always someone else's responsibility, all features have to be reimplemented across DEs endlessly (with often-incompatible variations, of course), and they all blame each other and program authors for bugs while the Wayland project refuses to even acknowledge basic features like desktop automation or screen recording.
> But sure, the transition was difficult and took a long time.
And this irks me too, people are convinced they're done but I still don't have xmacro. And flameshot is broken, while the alternatives suck. And support for everything depends on the DE now. And java.awt.Robot is broken with no replacement. And the clipboard randomly misses copies. And OBS screen recording is broken for me. And there's no support for display resolution scaling. And ssh -X is gone, while waypipe doesn't work all programs.
But hey, at least there's HDR now or something! It was definitely worth replacing a functioning stack for this. I'm so glad that Plasma 6.8 removes X support!
For what it's worth Xorg is the display server, before that it was XFree86, there was also Xsgi and Xsun and for mac Xquartz, I even saw a neat project once where the Xserver was in javascript, I am trying to find it again but our modern search engines are a bit shit. The point being all of these can interoperate with one another.
Around computers it is difficult to find the correct unit of time to
measure progress. Some cathedrals took a century to complete. Can you
imagine the grandeur and scope of a program that would take as long?
-- Epigrams in Programming, ACM SIGPLAN Sept. 1982
With a reference implementation. Xsgi, Xsun, Xquartz, and all the rest used the reference implementation with platform driver glue.
Bailey: Wayland replaces Xorg
Motte: Wayland is just a protocol
> because "display server" is only half of what Xorg does.
Yes, that's a big part of the problem. X was build for I/O, Wayland was built for O and had to be dragged kicking and screaming into rudimentary I.
As it is, the community got constantly browbeat with 'this is the future' and 'it's so much faster!' when recent benchmarks have proven that to be false.
You'll probably find it to be a not great experience, since almost all the people who spend their time actually working on graphics and GUIs in the Linux world prefer to work on Wayland. So X doesn't get much love these days (and you're not entitled to their efforts after all). But it's not like they erased all the old X code from existence.
I'm confused where I'm likely to be suffering. If I start using Wayland tomorrow would I even notice? Apart from having to switch DEs, of course.
You may notice issues with some GPU drivers if you have hardware with new drivers, because older GPU drivers contain X-specific workarounds which new drivers may lack (I know this is an issue with the Apple M1 GPU, I suspect it might be an issue with Panthor as well). But that's not really relevant with typical consumer hardware.
Desktop environments have varying levels of X support these days. GNOME hasn't been adding new features to X for a while, and GNOME 50 completely drops X. So if you're a GNOME fan you may not like that. KDE ends X11 support in 6.8. But it's always possible to stay on GNOME 49 or KDE Plasma 6.7 forever, or use an X11 window manager.
The X11 back-end is deprecated in GTK 4, so don't expect a ton of improvements to it, but it'll remain supported for all of GTK 4's life so you probably won't notice anything there immediately. But it means GTK 5 will drop the X11 back-end entirely, so at some point in the coming decade, GTK applications will gradually stop working.
Regardless of GUI toolkit, applications are slowly moving towards the XDG Portal way of doing things instead of the X11 way; which is fine, there's no reason why X systems can't support the portal dbus APIs, but I suspect that there will be more issues there once applications start dropping their X11 implementations of things. This is an area under active development and I would expect X11 to not see much of that development. I have no idea if anyone has implemented a portal for X11. Maybe you'd have to do that yourself eventually to keep new versions of certain programs running, I don't know how the state of portals is on X.
There are other things too that software can do to break X11 support even when their toolkit supports X, and expect that this has started happening to some degree and will slowly continue.
Hopefully someone will come up with Wayland emulation layer for x11 then.
Open source developers are not required to spend their time prioritizing your priorities. You just have to look to Xlibre to see that a lot of contributions are quite bad quality, and in a C codebase of Xorg's complexity and security profile it's not a small job to review things.
Not a problem for obviously-correct changes of a couple of lines, but most PRs aren't like that.
Linux security inside a user's session is bad in general. It all started in the '90s from the principle that all installed software is FOSS, sources inspected, and compiled distro packages trusted.
- Permissions are per-user, not per-app. If I ever need permissions to something, every app I run gets the same permissions.
- No isolation for personal files. Any app running as me can read all of them. Bookmarks, firefox passwords, everything.
- No per-app firewall mechanisms. Any app can call home and send user's files, including those passwords.
- System events are broadcasted via dbus to any app wanting to listen to them.
More, a compromized app can execute Signal itself, attach a debugger to it, fake inputs, read outputs, read it's memory, etc. and impersonate you. Also without X.
Even on Signal Desktop, retrieving things from an outside app is very-hard-to-impossible depending on configuration and what you're after.
There's a reason most Signal bots (even benign ones) hook up an event stream to a specially configured Signal daemon and build an external record of data from Signal by watching for events over time.
> More, a compromized app can execute Signal itself, attach a debugger to it, fake inputs, read outputs, read it's memory...
I think you're missing a lot of the attack surface here. "Local execution is game over" is a technically-true-but-incomplete thought-terminating statement; it's more useful to assess "if I grant local execution, what attackers are likely to be interested in that, and what attacks are they likely to perform?"
Like sure, if you install something containing a full userland rootkit designed to attack a given application, and that application isn't running in a container such that you have to pivot through root to access it, you're screwed.
Those do exist, but there are a ton of local attack vectors that aren't that. Many pieces of malicious code that install with local apps aren't that complex, since complexity begets size and suspicious-behavior detection. Less complex malware would prefer to e.g. read Firefox's sqlite database files rather than try to execute new instances of trusted programs like Signal to get data out of them. We know from analysis of a lot of malware that it overwhelmingly prefers low-hanging fruit that's easy to harvest quickly and without doing much that risks detection. Some malware's scarier, but like Mickens said, most people a) aren't gonna get Mossad'd on, and b) can't do much about it if they are: https://www.usenix.org/system/files/1401_08-12_mickens.pdf
There are also local attack vectors that don't involve installing malware directly. Local programs that run code (browsers) and plenty of other exploits in e.g. decoders are limited enough in what's possible within the exploit chain that they can't calc.exe you and instead rely on info harvesting from speculative execution
Flatpak/Snap/etc., also can assist with a layer of local-app security here.
Put all that together, and you end up at the conclusion that a large volume of data is only practically accessible to a lot of malware by accessing another running app's memory. Two significant ways to do that are 1) reading memory directly (significantly mitigated by hardware permissioning/segmentation/ASLR) and 2) reading data those apps publish to the display system. Wayland makes that second one a lot harder.
Making server side decorations an important part of it. Oh, the irony.
Which is ironic, given that a lot of the tools that underly a container runtime were originally designed to facilitate security, not ease of deployment.
My theory about the motivation behind the extra security is that it's largely driven by corporations wanting to make desktop Linux less free and less open, and normalize proprietary software instead of open-source. Because profit. Proprietary software is inherently not trustworthy, so the execution environment needs extra security and restrictions, and must be generally less powerful to reduce the damage it can do. Essentially, proprietary software needs the same precautions as malware. So the corps needed to "androidify" desktop Linux. Hence the change from curated distro package repositories to corporate app stores, and the reason why there's so much money pushing to replace X11 with Wayland.
In an open-source ecosystem, users and developers are one and the same, or at least on the same "side", cooperating with each other to make tools which work as well as possible for everyone. Each big program tends to be a collaborative effort where a lot of people contribute to make things better for everyone. Things mostly "just work" and people can typically trust their computers not to do anything weird or hostile.
Very different than a proprietary commercial ecosystem, where users and developers have more of an adversarial relationship. Each program tends to be created in a closed silo by one person or a relatively small team, and is designed primarily to extract money from users, with all other concerns being secondary. It is very common for profit-driven developers to engage in deceptive practices, or do things the user doesn't want, like showing advertisements, collecting and selling data, sabotaging products from competitors, using the device as a node in a botnet or secret compute farm, forcing unwanted updates, microtransactions or subscription fees, etc. So nothing can be trusted, and the entire system needs extensive protections against every type of misbehavior imaginable... even if that means reducing the power and features available to the user.
I've really enjoyed the past few decades of living entirely in the open-source world, where those problems pretty much just don't exist. But with corps pushing the androidification of desktop Linux, I fear those days may be coming to an end.
See my other comment too.
There is a lot more to desktop inter-app security than “if an app had a root shell then it could compromise things”. A great many attack vectors that we see constantly have a much narrower ingress than that.
Virtualization is another thing entirely. But if you want it that way, then why not simply start a second X for the untrusted app?
Corporate drive. Originally sponsored by Intel followed by IBM (RedHat) and the rest followed suit.
> Kristian Høgsberg, I work at Intel in the graphics team in the Open Source Technology Center. I'm the founder and maintainer of the Wayland project.
You either pitch or bring it with you. Demonstrate a tech demo and you're granted an engineer or two. It's how Amiga came to be, Steve Jobs with NeXT.
And it appears you can no longer link anything from reddit without being asked to login and they've now nuked old.reddit
If you have an account this thread has some very insightful comments. https://www.reddit.com/r/linux/comments/1m0ztn/how_is_waylan...
There were only a few people willing to work on an alternative, and they didn't have to take a vote, so they just did what they wanted. Corporations and projects adopted it because they wanted something different, and it was the only other option.
Now that we have AI, it will be much easier for genuine community alternatives to emerge, even if we have to battle over the legal ramifications. I for one am willing to go without "official support" to have software that doesn't suck.
AwesomeWM for me. I've essentially fused with it. Warts and all.
I can't imagine life without AwesomeWM.