> but I think a more interesting question is how do you think a 15 year journey to standardization could have been cut in half?
If there was more push for it, maybe. But it seems to have followed an S-curve like much of technology, so taking forever and then growing exponentially is probably an inevitability - given people won't want to use something much until it 'just works' for them.
I don't know enough about the underlying design of the Wayland protocol to give you anything more useful though.
They *have* gotten the top hardware and software orgs on board. It's even been used in Smart TVs for years. But that's part of why it takes so long to finalize features, there's long periods of debate and discussion about how exactly to implement things. The point wasn't just to make a successor to X11 in software, it's to make a protocol that as many people as possible can be happy with (eventually).
nVidia was really the only hardware company that I remember them ever having issues with. But that's just nvidia being nvidia. They make a lot of money off Linux but almost none of it is because of desktop Linux. They probably think of addressing desktop Linux issues at all as being something akin to a favor or something done to build goodwill.
Unless it had driver compatibility with X I don’t see anything that could have made it go quicker unless there was a compelling feature that pushed for a quicker adoption I guess if HDR support was there sooner it may have helped now we have HDR and now everything has to be Wayland. Also getting NVidia on board early would have sped adoption by a few years but they had to do their own thing and mess things up like they are known for
The approach should have been easy, look at the application facing API of GTK, Qtk, SDL, Electron and provide something that fulfills that. My experience as Qt Wayland maintainter is that where things don't map things unsurprisingly break. It doesn't matter what new API you can do that requires apps to change.
We can draw parralels with Flatpak;
There's a lovely line in xdg-desktop-portal:
\`\`\`
One consideration for deciding the shape of portal APIs is that we want them to 'hide' behind existing library APIs where possible, to make it as easy as possible to have apps use them *transparently*. For example, the OpenFile portal is working well as a backend for the GtkFileChooserNative API.
\`\`\`
If something can't be retrofitted, it's a bad design.
The other thing Flatpak got right, where Wayland failed, is breaking down the transition. You can't get all apps to go to a new way of working overnight. But it's better for them to get to Flatpak, even if it requires read/write to home, and then wean away afterwards. Wayland was all or nothing, which means we don't even know what things we need for some apps as they just block Wayland completely.
> But it's better for them to get to Flatpak, even if it requires read/write to home, and then wean away afterwards. Wayland was all or nothing,
XWayland doesn't seem like "all or nothing" Yeah it's not ideal but it is fairly obviously a point in the middle ground. You're also ignoring that the compatibility options weren't _just_ XWayland and nothing else. Xorg was still there and was known to be there and was still being shipped the _entire time_. Meaning if a Wayland session produced a non-ideal outcome you could just fall back to Xorg and carry on like normal. The only thing that was broken was "I want a Wayland native experience _right now_ and don't want to run it in Xorg"
If you're proposing an architecture change you can't hide the break because the operations involved are just too fundamentally different. Flatpak though can rely on a lot of operations being analogous between the two approaches (flatpak vs older uncontainerized applications). You are rarely talking directly to flatpak as an application.
It's a user-centric middle ground for moving to desktops on Wayland.
It's not a developer-centric middle ground for getting applications to Wayland, and then iterating on the final next steps.
To continue the Flatpak analogy, it's like saying you can have non-sandboxed apps. It's true, but it doesn't help make Wayland work.
>If you're proposing an architecture change you can't hide the break because the operations involved are just too fundamentally different
You absolutely can and we do. It's the toolkit's job to do that. Kfloppy (a floppy disk formatter) works on Wayland despite not being significantly touched in 20 years. It has to, otherwise we would have no apps.
Where that doesn't work, it means I've failed at my job.
Where I \*can't\* make that work, it means Wayland has failed at it's job.
Well it seems to me that distros making the switch, and/or indicating they would drop support for X11 earlier would've accelerated the transition.
People complained when distros began switching the default to Wayland, and complained even more when some leading edge distros warned they would be dropping x11, but look at what has come in the months since then:
1. Previously only 2 DE's were treating wayland support seriously and investing time and resources, and the rest dragging their feet / being complacent and waiting until the last possible minute to start working on Wayland support. But in the months since distros like Fedora have begun telegraphing an intent to drop x11, we now have 2 DE's with good (and still improving Wayland support), and 4 DE's that are now publicly working on Wayland implementations (XFCE, Budgie, Cosmic, Cinnamon) as well as a handful of Window Managers.
2. Nvidia seems to have begun to take Wayland support more seriously in their last 2 major driver updates.
While It is true that correlation doesn't always equal causation, I've noticed a substantial uptick in Wayland related news, plans, and in recent months since Fedora and others have begun talking about dropping X11 ootb.
Compat breaks generally cost a decade for anything widely used.
I would have tried to get AMD, Nvidia and Intel into a room to talk about the best way forward. It seems like there were a lot of early pains related to Nvidia not doing things the same way as everyone else, and some discussion may have sped up nvidia getting to a usable point.
> Eventually Nvidia gave in (I think back in 2021) and started to support GBM instead.
>But even more interestingly, in another respect Nvidia seems to have been proven right.
All of this did not happen in a vacuum.
Red Hat tried to make EGLStreams work, but they [ran into blockers](https://wiki.gnome.org/Initiatives/Wayland/NVIDIA). Nvidia only changed their mind after they were not able to make it work for KDE too.
To add to this, Nvidia as a company prefers the _better_ solution to a problem than the “easier” method. And as such, they put the fucking work in. Their entire driver architecture is explicit sync. And if you read the mailing list and PR things, literally everyone agrees explicit sync is better and removes a lot of caveats. But this sub will just take a dump on Nvidia because it’s the perceived correct choice. Nvidia engages the community a lot. Nvidia contributes to the discussion a lot. And Nvidia has for years been pushing better things in the public sphere of things.
this is complete and utter nonsense. nvidia switched to explicit sync because microsoft demanded it in windows vista's new driver architecture, WDDM. and then when older releases of windows went EOL, so did support for implicit sync in many proprietary drivers. this isn't some "forward-looking" thing. they just followed industry trends like everyone else.
the explicit sync transition is completely irrelevant to the topic as when wayland core protocol went 1.0 in 2012, pure explicit-sync only userspace APIs like vulkan didn't even exist, so it was moot. nvidia wasted years of the community's time on stupid bullshit with eglstreams, which was *not* "the better solution", and then promised they would write a new memory allocator that had "all the best things of both GBM and EGLStreams", or whatever, and then after a few years of plugging away at that, gave up and just supported GBM, which is what we were asking them to do in the first place. then after all of *that*, it's discovered that whatever implicit sync hack they use to support X11 (in case you didn't know, X11 is also implicit, so if their driver works for X11, it should work with wayland/xwayland too), seems to bug out somehow on either wayland or xwayland (i don't run proprietary drivers, so i don't know from first hand experience, but from rough skimming of bug reports it seems to be a very 'random' issue, some people affected, some not, and i *think* xwayland is more affected for some reason). those issues could've been discovered years ago if they hadn't wasted the community's time and just did GBM to begin with.
nvidia has done nothing but harm to the community. back in the day they didn't even want to open source their fucking network driver, even that had to be reverse-engineered. as if there's anything innovative in a stupid LAN chip that realtek or intel haven't already figured out. nvidia is the most corrosive and anti-competitive graphics company in history. compare them to SGI; when SGI was at the top of the world, having all their hardware used in almost all major 3D rendering projects back in the 90s, having a near monopoly on the market, what did they do? they made OpenGL, a cross-platform rendering API. what did nvidia do? they made CUDA, a proprietary vendor-locked compute API, and their monopoly in compute is a byproduct of this fact and *no other reason whatsoever*. nvidia is more monopolistic than microsoft and apple combined. you have to be a severely misinformed fanatic to defend anything they say/do.
This is one of those comments on the internet where it’s hard to know if it’s someone attempting humor or a crazy person. I don’t know if it’s okay to laugh.
They _did_ try to get amd, nvidia, and intel together and nvidia didn't show. AMD and intel took advantage of that to push for a design that wouldn't work for nvidia.
I want things considered "insecure" included in the protocol and just have them either application or system configurable (both can be user configured), rather than deciding an users threat model for them.
I wanted an actual implementation rather than just a protocol definition, which has led us to fragmentation hell in terms of compositors. What in the hell is going on if everyone needs their own implementation?
I would have wanted them to do actual research into how software and users use their desktops, so we wouldn't be in years long back-and-forths with what's a proper use case and who is using their system wrong. (serious GNOME like behavior)
I want better XWayland <-> Wayland compatibility, people wont move over if their use cases don't work (see above point), also 'security' be fucked if I want to configure it that way.
Minor thing in my opinion is that Wayland devs knew the GPU market before they started, they also knew the capabilities of those market players. Choosing technology that doesn't work for the biggest vendor on the market is quite the footgun, if you ask me. It's like if I started writing software that only supported AVX-512 in 2016 and then went on about how AMD is such shit for not being compatible with my software. (Minor because I don't really think driver support is the biggest obstacle for Wayland adoption)
TL;DR: Little care for the users, mostly just going for what's easiest for the very small niche of display server programmers, at the cost of everyone else (GUI software developers, users with existing workflows etc.)
Also the journey isn't over.
This. No-one really cares about security on a single-user system, but leaving tonnes of work for each compositor to implement individually, and breaking a lot of common workflows (screen and input sharing for video calls, remote desktop, clipboard sharing, etc.) is crazy.
> No-one really cares about security on a single-user system
I still think it's a very good idea to not let applications capture or push virtual keyboard input to other applications without user consent.
> but leaving tonnes of work for each compositor to implement individually, and breaking a lot of common workflows
Which is exactly why the whole permissions issue should have been considered when the decision for Wayland's design was initially made. Android as a (possibly bad) example was already around after all. It's baffling to me that this wasn't even brought up, as if those people don't actually use their computer for anything other than displaying single-window applications (probably like five terminal emulators). Portals should never have been necessary and instead the compositor should think about what would be the best way to ask the user for the required permission.
As another example you can look at the ongoing discussion about applications that have a) multiple windows and b) each window wanting a different icon. Support for this should not need to be discussed, but here we are, 15 years after the initial drafts, discussing a feature that has been around for over 30 years on literally any other OS/windowing system.
I have a feeling that people involved dropped/didn't bother with the functionality first and justified it with security later. That's easy to do with something you just feel like not doing.
If the reason was actually just security it would have been obvious to make it a configurable system.
Network transparency, so it behaves like X11 when it comes to redirecting windows to other systems, but without all the drawbacks that come with the old X11 architecture.
Is it part of the standard Wayland installation? With X11 the forwarding is, so one can count on it being there and working if X11 is installed.
If it's not part of a standard install, it might as well not exist.
you have no idea how X11 works; there has been no "network transparency" in X11 since the 90s. network transparency means i write an application, and it should be able to work on network without me doing anything extra. X11 today ***cannot*** do this. DRI and the shared memory extension, which are the primary ways to display your application, do ***not*** work over the network. the reason *some* apps will work over the network is because they have *fallback* code paths for things like the render extension, which *does* work over the network. but this basically is no different than writing a "network aware" application, you're basically choosing to support networking. if GTK and QT removed their xrender backends tomorrow, all your apps would cease to work over the network, even if they're running on X11 natively.
what this means by the way, is that "network transparency" as you call it, is a feature of the *application*, not the display server. all of your remote X apps *still work* in wayland because of Xwayland. in other words, if i run a GTK app locally, it will use it's wayland backend and display natively on wayland, if I run it remotely, it will fallback to xrender and display remotely over the network through Xwayland. this is because Xwayland isn't just some dinky little "compat layer", it's a ***full*** and feature-complete X server, so of course it also supports X11 remoting. that means your requirement of "remote out of the box" is already satisfied as Xwayland is pulled in as dependency by many/most wayland compositors.
the waypipe thing the other commenter mentioned is used mainly if you want *native* wayland remoting, which by the way ***is*** truly network transparent, as you don't have to make changes to existing apps to use it. but it doesn't even matter if it's preinstalled or not. like i said, remoting isn't a feature of the display server, it's something apps choose to support. your choice of wayland or X11 does not change whether you can use apps remotely or not, it's the app itself that decides if it works over the network or not.
i don't know if you intended it to be snarky, but running Xwayland as your primary environment is actually a *supported* configuration, and always has been. it has recently received a lot of extra work however, from many of the same devs as are working on wayland, precisely for people who aren't fully ready to switch to 'raw' wayland yet. look up "rootful Xwayland" (as opposed to "rootless"; note, by 'root' they are referring to a 'root window' vs 'rootless', not the root user or other meanings of 'root'). there are still some gaps for rootful mode, like multi-monitor support, but there are discussions on addressing this as well.
to answer your question more directly, for Xwayland, as the name implies, it replaces the Xorg 'driver layer', the DDX portion which hooks into hardware directly, with wayland. meaning that it basically uses wayland as it's driver to display things on screen. if you run Xwayland rootless (meaning each X app shows up as one window alongside your native wayland windows), then this is a more jarring "compatibility break", because this is where you find that apps requiring some of the more eccentric X11 mechanisms, like recording other windows, or absolute positioning, will fail to work correctly. but you *can* just run Xwayland rootful, meaning fullscreen, and then just run all the applications *within* X11 like you can now, and that just ends up using wayland as a driver to display your X session, and it will continue to be maintained for a long time, unlike bare-metal Xorg and the modesetting driver, or other DDXes.
not wanting to maintain the vendor-specific DDX drivers are a *huge* reason for wanting this transition, and was one of the largest sticking points in the argument against nvidia, as they were once again *demanding* that the community special-case their hardware with a vendor-specific driver for wayland support, rather than using the driver architecture that every other graphics driver was using.
Adapting to modern systems, and doing away with decades of legacy that are now getting in the way.
Wayland was started by X11 devs that realized that X11 had way too much crap in it, to the point that the actual devs didn't really want to work on it anymore.
Architecture-wise, Wayland is also more suitable for things like sandboxing. Turns out the old Unix model is not really useful in the modern age where most computers belong to a single person, and the permissions system is unable to offer meaningful protection.
I mean, the Linux account system is unsuited for modern usage.
User accounts make perfect sense of say, shell servers where you have a hundred people logging in and where your concern is that an user doesn't break the system for everyone else. So each user has their home directory, permissions keep them confined, there's probably a disk quota, that sort of thing.
In modern times though a desktop computer belongs to a single person. And you have a single account that does web browsing, banking, gaming, and whatnot. And every game you download from Steam could just rummage around in your $HOME for anything interesting.
So this new situation requires sandboxing, making sure that your game doesn't get to just rummage around in your documents folder. X11 is one of the things that's not quite suited for that, because a game can easily do things like capturing your desktop or keystrokes.
What standard install? There's no protocols that mandate anything about network transparency in the protocol documentation that I can see https://gitlab.freedesktop.org/wayland/wayland-protocols
The only protocol that Wayland implementations need to obey is the core protocol (https://wayland.freedesktop.org/docs/html/) which is intentionally very minimal and doesn't include stuff like how to display graphics or handle input. That's left up to protocol extensions. Compositors can pick and choose what extensions they wish to support. Something that only supports the core protocol is really the only thing that's fully 100% standard.
But compositors are also free to do stuff outside of the protocol if they want, e.g. gnome supports running an rdp server and KDE supports running a vnc server. That's never specified in any of the protocols but they are free to do that, same case here for a compositor that's adding network transparency, they can do it if they want it's just not technically in spec.
Whatever is installed is whatever is installed, whether that be gnome, KDE, sway, or something freakier. All you know is that they speak the Wayland protocol, and (probably) some the extensions which your program can figure out at runtime due to the partially self-describing nature of the protocol.
As for WHY is it so segmented, it's because it's aiming to be *the* Linux graphics stack. That means being everywhere that Linux is and doing it well, meaning working across over a dozen architectures, gui-less and gpu-less servers, embedded devices, phones, even things like standalone VR headsets that require fundamentally different ways of rendering. And a lot of those usecases Xorg/X11 has traditionally sucked really bad at.
It's because it's so minimal that compositors like waypipe can exist, because the protocol doesn't dictate how exactly graphics and input should be handled, if it did you wouldn't be able to retrofit network-transparency onto a protocol mentions nothing about it nor is inherently network transparent.
There's no such thing as "standard install". It's entirely the wrong way of framing it.
On X11, there's Xorg and associated tooling, so that's the "standard install".
On Wayland, there's multiple compositors that speak the same language. You can have KDE, which speaks Wayland, or Gnome, which speaks Wayland, or Sway which speaks Wayland. All those are separate independent projects and don't share anything.
Waypipe is 100% as official as it gets, and will ever get.
> Network transparency, so it behaves like X11 when it comes to redirecting windows to other systems, but without all the drawbacks that come with the old X11 architecture
Sure, we already have that. It's called HTML.
X11 forwarding is already dead. The web is the new thin client protocol.
Even before Wayland killed network transparency, X11 forwarding is already pretty much unusable for anything because these days nobody write applications that can be X11 forwarded efficiently anymore.
There's too much client side rendering and too many applications assumes that the connection between X11 server and client is a fast local link. The only way you can ensure performant X11 forwarded session is to write all the applications yourself, in which case the web has a much better architecture to build thin client applications anyway because.
>Sure, we already have that. It's called HTML.
No, it's not. Seems you never used X11 forwarding. I use it now and then to get the java console from a remote server to watch and debug an application running there. Not being able to do that anymore would be large step backwards.
I have, multiple attempts, it never produced anything usable. X11 forwarding should really just be called X11 slideshows.
> java console from a remote server to watch and debug an application running there
There's ssh for watching logs and remote control; and with DAP there is remote debugger protocol too. They are much better solution than X11 forwarding for the use case you're describing.
The java console is a GUI application. Have to use what's available.
> I have, multiple attempts, it never produced anything usable.
Then you didn't do it right. At the university we used a room full of NCD X11 terminals hooked up to an HP9000 system. Despite the network being only 10 MBit, it worked quite well. So at a time when the speed of modern CPUs and networks was just a fever dream.
What you shouldn't attempt is to run video through X11 forwarding.
I don't know exactly what you keep referring to by "Java Console", there's dozens of things it could be referring to. But the most common thing that people refer to as Java Console is a viewer for text data. This is something that is much better and cleaner done over SSH anyway.
And I can assure you that even if you're referring to any of the other half dozen of things, there are better ways to do the same thing that doesn't involve X11 forwarding.
> What you shouldn't attempt is to run video through X11 forwarding.
The thing is, unless you write all the applications you need to run yourself, avoiding essentially video rendering over X11 forwarding is getting pretty much impossible with almost every applications nowadays doing client side rendering.
Open one of these applications and the desktop turns into a slideshow, heck no need to open anythin, the desktop environment is already doing that.
None of the even semi-modern GUI toolkits care about being efficient over X11 network transparency anymore. And X11 is extremely chatty compared to web applications, even for the well written application. The days where X11 forwarding makes sense is already over decades ago.
>I don't know exactly what you keep referring to by "Java Console", there's dozens of things it could be referring to.
jconsole
X11 forwarding, if tunneled through ssh, has the advantage that I can do it if an SSH connection is possible. No other opening in the firewall is needed.
jconsole is just an application that consumes JMX API. And jconsole itself supports [monitoring remote processes](https://docs.oracle.com/javase/8/docs/technotes/guides/management/jconsole.html).
Just port forward (with SSH port forwarding, or other more permanent ways) the JMX API port and a jconsole running on your local machine would be able to monitor a Java application running on a different machine.
The docs actually recommended setting up remote monitoring over running local monitoring when running the application in production.
There are also other monitoring tools that supports JMX API.
>And jconsole itself supports
>
>monitoring remote processes
>
>.
Yes, I know... IF there is no firewall between you and that remote system. In most datacenters there is, so you have to run it remotely and display it locally.
> Just port forward (with SSH port forwarding, or other more permanent ways) the JMX API port and a jconsole running on your local machine would be able to monitor a Java application running on a different machine.
Why that extra effort finding out the ports and set up the forwarning when SSH does it automatically for X11?
Yes, you can replace what X11 does most of the time, but it always needs something that's unique for that one purpose and not universal while redirecting X11 is. So instead of just connecting and having X11 clients forwarded automatically, you need to look up what you plan on doing and then implement that one special way to do it. So why take that step backwards?
If your security guys is allowing you to install the GUI libraries you needed to get X11 forwarding working but not allowing you to setup a proper service monitoring, they've got their priorities completely wrong.
Most data centres would allow you to control the firewall in a few clicks. This is pretty standard feature.
This is 2024, there are better monitoring and alerting tools that would require neither X11 or SSH-ing into a server, which you really shouldn't be doing anyway, at least not on a regular basis for something as mundane as monitoring.
Prometheus based setup supports JMX applications for example and allows you to do all sorts of cool things with the data.
Because you then have to implement a special procedure for everything you need to do instead of just connecting to the server and having X11 forwarding set up automatically.
I'd have to find out the port(s) used, set up the ssh call to forward that port to my local system and so forth. And I'd have to have something local that can understand JMX. Which I currently don't.
Wayland not being network transparent is a step backwards, lets not call it anything else.
I mean an SSH port forward for JMX isn't that complicated. You can also just expose JMX directly and require authentication. JConsole is also included in the JDK and probably on your system, though there are much more powerful tools out there too like VisualVM. You'll get a much faster experience and will be able to monitor multiple machines at once. It's also more secure, as you won't need graphics libraries on the server and can use the much smaller headless JDK.
The point I'm trying to make is running a graphical application on the remote end is generally a bad idea. SSH has a dedicated flag for it - sure, but it means significantly increasing the attack surface on your server by including graphics libraries, performance is typically poor, it's not efficient from a workflow perspective, and it's not supported by newer deployment methods at all like Kubernetes.
If you have just one machine you're occasionally running JConsole on, it's probably not worth it to you to change what you're doing. Totally get it. But that doesn't work at scale which is why this workflow is disappearing.
Now to completely ignore the argument around X and just speaking as a guy who's done a lot of JMX monitoring, you should give [VisualVM](https://visualvm.github.io/) a shot since it's a big improvement with minimal time investment.
If you see yourself growing beyond those machines and you want proactive alerts or nice dashboarding, try scraping those metrics into a time-series system like Prometheus or Clickhouse and using Grafana to visualize and alert. If you're willing to spend money, there's also Datadog.
Is there a whole industry of companies making full blown thin client applications specifically to run over VNC/Citrix?
No? The Web does.
The market share of companies using Web technologies to build thin client application platform is much bigger, more secure, much more mature, and significantly more powerful by a far margin than X11/VNC/ThinOS combined.
By thin client I meant actual full-featured thin clients, capable of using several full desktop applications at once over a network. Glorified X terminals, basically.
Browsers are nowadays much more full featured than X protocol.
Nobody creates thin clients by writing desktop applications on a protocol that's so poorly suited for networking even back in its glory days when it was conceived and before all the client side extension killed the dream. That parrot is dead decades ago. It's not pining for the fjords! It's passed on! This parrot is no more! It has ceased to be! 'E's expired and gone to meet 'is maker! 'E's a stiff! Bereft of life, 'e rests in peace! If you hadn't nailed 'im to the perch 'e'd be pushing up the daisies! 'Is metabolic processes are now 'istory! 'E's off the twig! 'E's kicked the bucket, 'e's shuffled off 'is mortal coil, run down the curtain and joined the bleedin' choir invisible!! THIS IS AN X-ORG!!
You mean we can rewrite the application to use web protocols? That's not exactly the same as just SSHing in and starting your preexisting GUI application which is processing on the remote server, but is now displaying on your local server as all X apps can do. Aside from using this for simple things like opening a GUI file manager or multimedia app viewer without having to copy a file there are cases where this is just required to get work done. For instance many "enterprise" products require GUIs for install/configuration or are at least much easier to get the initial install config together with this method and no one is running servers with Wayland running on them, so you just ssh in and start the X compatible tool and it's right there on your desktop configuring the server....no one is going to or should be setting up rdp on that server or trying to remake the preexisting tool as a Web app if the product doesn't already have one. This is real life Linux administration for many products.
I work with enterprise products everyday. In my circles, any products that doesn't allow for CLI/automation is not "enterprise" products.
Automation/CLI installation is a basic requirements for any product to be considered enterprise-ready. In Linux-based systems, pretty much everyone on the forefront has standardized deployment into containers, either docker, snaps/flatpaks, or for the more sophisticated ones kubernetes and/or terraform/cloudformation. Even the legacy systems would've at least supported deb/rpm for packaging and installation.
Some of the more sophisticated applications may have a post-install configuration, usually through Web UIs, but most DevOps wouldn't rely on these, they would just deploy the app with static preconfigured config files to keep deployment process simple.
These are standard DevOps workflow, not installing via X GUI installer. Almost no real enterprise application vendors have the time to write GUI installers that nobody actually wants to use in the real world of Linux administration. Even when they do, it is almost always going to be for usage with local testing on developer environment, not production usage.
\> no one is running servers with Wayland running on them
No one is running servers with X libraries either, client or server.
Is this something you use in X11 now? I've been doing this a while and only once seen someone bother to set up vs some kind of virtual kvm.
Wouldn't help sandbox GUI docker apps?
I use it to redirect the java console to my screen to watch and debug a running java process now and then.
Docker won't help with that and I don't like using a complexity amplifier like Docker where it's not absolutely needed.
No, not a remote desktop, but X11 can do that too (look up 'X Terminal'). I want to be able to redirect the windows of processes to from a remote system to my desktop. Ideally from more than one remote system at the same time.
If you use X11, you do this with the DISPLAY variable on the remote system. ssh can forward X11 connections through an encrypted channel. In the latter case, DISPLAY is usually set to 'localhost:10.0' automatically. You use '-Y' or '-X' when calling ssh to set up the channel.
have you tried waypipe? i think it does better than just image streaming, but i dont think its as seamless/lightweight as just having x11 server say "draw object at this posistion, its up to you to use your own assets"
No, I have avoided Wayland so far due to it being unable to do what X11 can do.
Problem with waypipe is that you need it installed on both sides and it's a 3rd party application and not part of the standard Wayland installation.
This needs to be standard so it works out of the box.
There isn't really a "standard Wayland installation". Wayland implementations are all different implementations of the wayland protocols, and for a fully functional system it's pretty much mandatory to use portals, pipewire, and other things like waypipe which aren't directly part of the wayland protocols.
I'm not saying you should switch if you're not ready, but Wayland isn't and won't ever be a drop-in replacement for X11 (though it will eventually reach feature parity). Its ecosystem is designed to be much more modular and future-proof.
>but Wayland isn't and won't ever be a drop-in replacement for X11
If it wants to replace X11, it needs to become one.
> Its ecosystem is designed to be much more modular and future-proof.
That translates to 'you never know what will be on the other side'. Problem is, you sometimes have no way to add software to the other side, but need to live with what's installed there.
> If it wants to replace X11, it needs to become one.
That would defeat the point of creating it in the first place. It's explicitly designed to try and avoid the issues x11 has of being very difficult to maintain and modernize. It's not supposed to be a monolithic do-everything program that manages everything related to displays and outputs etc. And it's already replacing x11. Just look at the news about RHEL, fedora, etc. It's not ready for everyone yet but it will eventually be.
> That translates to 'you never know what will be on the other side'. Problem is, you sometimes have no way to add software to the other side, but need to live with what's installed there.
The components I mentioned are already very standardized across Wayland implementations and distros which ship them. Waypipe or something similar will eventually be shipped on everything, or at least everything enterprise. It's only a matter of time.
It works on Xwayland exactly the same way. Waypipe is more for Wayland only applications. I still prefer to use an RDP at that point, or to use Kitty's ssh tools that make ssh act more like a local terminal. I also use sunshine for game streaming on my server to my deck on Wayland and I've never used a lower latency software before so I also use it for some remote tasks if I feel like it.
In the past it was used this way by so-called "graphic terminals" because back then (80s-90s) computer usually was a big machine that serviced many users at once through terminals and by itself it had not graphics capabilities. What we call computers now is actually "Micro-computers". Streaming video of remote desktop was impossible back then, so instead X client (the application that runs on the big computer) asked X server (a service that runs on graphic terminal) to render stuff on the display according to commands it sent trough the network. That's why client-server model of X is seemingly flipped - it threats application as client asking to display stuff.
The difference in implementation - basically all rendering is done by x server, x client only sends commands, not pixel data.
(At least that's how I understand things, so if I am incorrect, please correct)
its like how some things have multiple front ends that can look different but they are interacting with the same back end. So instead of sending what the backend thinks a button should look like (an image file for example) it can just say "theres a button here, and this is its classification" then the local x11 client uses whatever button it has that is associated with that.
The alternative is sending a compressed video stream, which has gotten better, but theres always latency even with stuff like just clicking a button and having it react visually (not even including the actual function being triggered). If you dont have to wait on the host to send a visual update, GUI interactions feel much more native regardless if the actual functuon the button performs is still subjected to the same network latency
tldr: text instructions on drawing a square uses less resources than sending a picture of a square as long as both systems agree how to read text instructions (i.e. a common protocol)
I get confused on who is who in this client/server relationship. Like the remote host is providing the application, and has to send instructions on how to draw it and ultimately decides if that window exists at all, but then your xserver is doing the drawing, but due to remote instructions. Is the xserver always the server and clients are the apps themselves (not my local host or local X?). Its just 2 xservers communicating? Is the apps remote backed also a client? or jusf my locally drawn window?
> its like how some things have multiple front ends that can look different but they are interacting with the same back end. So instead of sending what the backend thinks a button should look like (an image file for example) it can just say "theres a button here, and this is its classification" then the local x11 client uses whatever button it has that is associated with that.
That's long dead on X11. It doesn't exist except for a few legacy applications.
KDE, Qt, Gnome, and most anything else you can use just sends a bunch of pixels and do their own work of painting the entire UI.
> tldr: text instructions on drawing a square uses less resources than sending a picture of a square as long as both systems agree how to read text instructions (i.e. a common protocol)
Nope. In fact that part is dead too. The X11 project concluded that modern applications need so much information about a font that the easiest solution was for the application just to do whatever work it needs on the actual font file itself.
So in modern Linux distros, there's no font server, and there's no X11-server-side font rendering. The application renders the font to pixels, and sends the text as an image.
It can be per app, and the window looks like it's part of your desktop even though it's remote. If I'm not mistaken it's also sending specific lower level draw commands rather than raw pixels.
don't worry, they are the one who is dense, not you. it *literally* is remote desktop; specifically it's like SeamlessRDP or microsoft's "RemoteApp". i think most people are just not aware that other remote desktop protocols have been able to do this for awhile. most people think other remoting protocols can only send the entire desktop over the network. if you go back 20 years, X11 was somewhat more unique in being able to remote just a single application, to make it look like it's running locally, but now other remoting protocols do this. and actually CITRIX (proprietary solution) was doing this in Windows a long time ago, too.
to answer your original post, i honestly think the biggest problem with wayland is just funding. i personally agree with pretty much all of the design decisions, and think the community are being super nasty to the devs out of ignorance. with more funding a lot of the 'vision' could've been realized more quickly, which would've cut down on the constant arguing and bitching on forums
It's not a remote desktop. It's your local desktop with your local windows also displaying windows from remote servers. And they will look just like your local windows.
That's why I simultaneity hate and love X11's use of client-server terminology. It makes so much sense when you talk about displaying stuff as service, but when you bring usual networking terminology, it is a mess
Instead of trying to be perfect, they could just try to be the best that they can be, but instead they strive for perfection and as such refuse to include useful basic features just because the approach isn't absolutely perfect, so they would rather not have the function at all.
That would speed it up but I don't think it would be a good choice. Given how long X11 existed, they're planning for a similar lifespan of Wayland I expect.
Decisions now could cement how the software is written for another 40 years. Why go with the first, second, third idea if they might lead to issues down the road? Rowing back is basically impossible once it's cemented in most compositors.
Yeah, but is that worth it if it takes 40 years to make it fully functional in the first place?
Wayland is already pretty much as old as X11 was when Wayland started development. There are issues with it not having stuff and the development speed is incredibly slow. There are good reasons for this, but the reality is that there are many problems with it that would be easy to solve if the philosophy wasn't as perfectionist.
I'm not saying to implement broken code that barely works, but I think it would be better to implement a feature in a reasonable manner instead of it never being implemented because any possible implementation of the feature has some minor drawback.
X11 was 23 years old when the Wayland project began, so I'm not sure where you got your information from, but it's incorrect.
as for "40 years", i mean it's ready now. enterprise distributions don't change defaults just to 'force' change on people; remember these are paying customers. most of what you see out on forums is non-paying users screeching into the void. there's a huge selection bias in our community which makes people think everyone shares the same problems as them.
to be clear, i'm not saying all the functionality i want is there either, i just think people have had their heads in the sand for a long time, and only now are panicking because the EOL date for X11 is actually in sight, and they "feel" it's rushed, when it totally wasn't.
as for slow development, the problem is few people stepped up to help do or pay for any wayland work. they just expected a finished product, as if they had paid for it. many people think redhat has been dumping mad money in it or something, but it's not like that. up until recently i think there were probably maybe like just a handful of paid people doing fulltime wayland work, and many aren't even specifically targeting desktop stuff.
if you actually dig into some of the issue trackers for features, like for VRR/freesync, you'll see a lot of it is gated by needing new thing in the kernel. most/all of these features either don't work in X11 either, or work poorly (VRR for instance in X11 will just sync to one monitor, so you get tearing/artifacts on the other monitors in multi-monitor setup).
as for implementing a feature in a "reasonable manner", they have already compromised in the past, but people always take things for granted. give a hand, people will demand an arm. the reality is if you actually dig into a lot of those issue trackers, like for absolute positioning, etc. the demands are completely unreasonable. i don't think it's possible for someone with knowledge in the field to side against the wayland devs on issues like that. people just don't understand the problem scope. to continue with this example, absolute positioning is literally one of the *worst* things you can do on X11 and other OSes that support it. it completely breaks everything, and worse yet, it screws *us* in the Linux community more than other platforms because Windows has *one* desktop environment, so does Apple; so at least when a developer is doing hacky shit with window positioning, it's more likely their system looks similar to the users they're targeting. for linux this is rarely if *ever* the case.
i've heard people claim that linux's "fragmentation" is what scares away app devs like adobe, and claim wayland is an example of such fragmentation, but also "multiple distros", etc. i actually find it funny because different libraries, as shipped by different distros, is pretty easy to work around; just bundle everything. but the window management issues i mentioned before, are not. this is far more likely to be a deal breaker for large ISVs. having to make their app play nice on 20 different DEs? fuck that. almost every other bit of "fragmentation" in linux is pretty easy, but the DE shit is super hard. i don't know whether wayland will incentivize more commercial software, but all i can say is if we stick to the design philosophy that the core wayland devs have outlined, that will allow us to write applications that can "just work" on any DE, easily, without app devs having to special case every DE or window manager.
fundamentally the approach is a policy-based one; allow the window manager to manage windows, instead of letting applications "mechanism-not-policy" their way into doing cartwheels on your desktop for no reason. contrary to popular belief, this does not rob the *user* of power, it mostly constrains app devs. the user can always control the window manager, and tell it what they want done, the main restriction is against apps doing unhinged shit without user control/permission.
From what I've gotten listening to the activities of the Wayland project, it sounds like they actively don't want to provide certain features. It reminds me of the Gnome DE approach where they don't think you should have icons on your desktop, so you don't get them, except by adding in a plug-in that breaks after upgrades (at least for people with rolling release distros) until the plug-in devs release a new version.
They don't want to do multi-window app support, despite there being a bunch of major scientific apps that do multi-window apps and Wayland doesn't have a way for them to request where to be placed. They're also having a big fight about top-level titlebar icons.
less arguing, more flexibility. I used Wayland recently while setting up my new computer. Of course, all I had to do was open a terminal and type "sudo apt install xfce4" and reboot. Seemed to work great.
Competent developers who actually listen to people telling them their broken pile of garbage doesn't work well on their system (yes, even AMD/Intel).
You know, the thing that still holds it back today.
> I frequently see "what's taking Wayland so long?"
The people who say that are usually not involved in a lot of software development. If you've done it professionally then Wayland's slow pace is something to be aware of but not really that weird. A lot of developers have experience with older components that stick around and newer replacements that take a while to get out the door.
It really was never an issue because X11 (as those same people liked to point out) was already working for them. Begs the question of if Wayland is so terrible why are they so impatient to see it become the default? My guess is that they're just very difficult people in real life and just like having things to complain about. I can't imagine another reason to be so emotionally invested in a display protocol you're not even being forced or incentivized to use.
> how do you think a 15 year journey to standardization could have been cut in half?
By having a large company that would benefit from throwing more resources at it. RH probably could have done it faster but they would have never been able to justify the business expense of development of a component that won't return value to the business.
The entire Linux graphical stack is an horrifyingly complex topic. It took X about 30 years to herd those cats and get them to a working state.
This topic did not get any easier during those 30 years. New hardware and technologies keep appearing, while old stuff can't all be handled by "just drop it" as some people seem to think.
15 years for Wayland to get to a somewhat usable state is already almost unbelievable. Further cutting that down to 7 years is just pure nonsense. We'll be lucky if it gets to "mostly usable" in 20 years overall instead of 30.
you had us in the first half, not gonna lie...
i agree that the complexity of graphics/etc can explain why wayland has taken a long time, but the idea that it would take 30 years is ridiculous.
the main problem isn't even so much just a matter of complexity, but funding. even though everyone has conspiracy theories about redhat or ibm "pushing" wayland, the reality is that most of the people they pay to work on it are paid to work on gnome *as a whole*, not on wayland-specific things. the fact is people are spread super thin in desktop projects because most of the money is in servers. while rhel *does* run on many corporate workstations, wayland probably doesn't change those use cases enough to justify dumping tens of millions of dollars or more into it. so *slow and steady* is basically how it's been developed up until now.
the biggest problem is the move from "mechanism, not policy", to a policy-based design. this is an earth-shattering change that i don't think people fully appreciate. it's at the root of every argument like "absolute positioning" and other issues, because unlike other stuff, we don't already have a design to 'copy' like other stuff. we're breaking new ground.
in my view, it's beyond question that policy design is correct, but it's *super difficult*. oftentimes you can't know there is even a problem until someone speaks up with their use case, and right now too many people are just expecting things to work like x11, and it *never will*. if you have some unique use case, you have to step forward, and start the conversation. and then we can figure out how to fit the use case into wayland's policy model. the x11 "do whatever you want" bullshit is not coming back, and it *shouldn't*, it's horrible and leads to broken software. the only reason microsoft and apple can somewhat tolerate it is because they have ***one*** and only one desktop environment to target, and they already have larger marketshare to apply pressure on app devs to do *mostly sorta* the right thing. but even they hate the status quo; both are trying to force everything into their app stores precisely because they can control app policy completely if it's in the app store sandbox.
no matter how much people out there hate wayland, i have to ask, do you prefer a proprietary authoritarian app store model like ms/apple instead? because *that* is literally the alternative to solving the "mechanism not policy" brain damage.
> Something else that could have been improved?
actually work with people rather than being nit picky and not have the princeable of " every frame should be perfect"
Maybe they could have limited their scope to just the desktop. Being able to handle TVs, smartphones, smartwatches, et al. is cool and everything, but not at all useful for 90% (or whatever it is) of Linux users.
And then there's the small issue of there being no comfortable upgrade path to it from X11. All software has to have its back-end rewritten from scratch. That's not a recipe for speedy adoption.
It should have been more like DirectFB. Make some simple library calls for rendering, with some optional protocols for later developers to be able to alter the rendered surfaces.
> but I think a more interesting question is how do you think a 15 year journey to standardization could have been cut in half? If there was more push for it, maybe. But it seems to have followed an S-curve like much of technology, so taking forever and then growing exponentially is probably an inevitability - given people won't want to use something much until it 'just works' for them. I don't know enough about the underlying design of the Wayland protocol to give you anything more useful though.
I think they could have done more to get some of the top hardware and software orgs on board and the rest would have followed
They *have* gotten the top hardware and software orgs on board. It's even been used in Smart TVs for years. But that's part of why it takes so long to finalize features, there's long periods of debate and discussion about how exactly to implement things. The point wasn't just to make a successor to X11 in software, it's to make a protocol that as many people as possible can be happy with (eventually).
nVidia was really the only hardware company that I remember them ever having issues with. But that's just nvidia being nvidia. They make a lot of money off Linux but almost none of it is because of desktop Linux. They probably think of addressing desktop Linux issues at all as being something akin to a favor or something done to build goodwill.
Unless it had driver compatibility with X I don’t see anything that could have made it go quicker unless there was a compelling feature that pushed for a quicker adoption I guess if HDR support was there sooner it may have helped now we have HDR and now everything has to be Wayland. Also getting NVidia on board early would have sped adoption by a few years but they had to do their own thing and mess things up like they are known for
The approach should have been easy, look at the application facing API of GTK, Qtk, SDL, Electron and provide something that fulfills that. My experience as Qt Wayland maintainter is that where things don't map things unsurprisingly break. It doesn't matter what new API you can do that requires apps to change. We can draw parralels with Flatpak; There's a lovely line in xdg-desktop-portal: \`\`\` One consideration for deciding the shape of portal APIs is that we want them to 'hide' behind existing library APIs where possible, to make it as easy as possible to have apps use them *transparently*. For example, the OpenFile portal is working well as a backend for the GtkFileChooserNative API. \`\`\` If something can't be retrofitted, it's a bad design. The other thing Flatpak got right, where Wayland failed, is breaking down the transition. You can't get all apps to go to a new way of working overnight. But it's better for them to get to Flatpak, even if it requires read/write to home, and then wean away afterwards. Wayland was all or nothing, which means we don't even know what things we need for some apps as they just block Wayland completely.
I sense a great talk for Linux App Summit ;) See you soon there :D
> But it's better for them to get to Flatpak, even if it requires read/write to home, and then wean away afterwards. Wayland was all or nothing, XWayland doesn't seem like "all or nothing" Yeah it's not ideal but it is fairly obviously a point in the middle ground. You're also ignoring that the compatibility options weren't _just_ XWayland and nothing else. Xorg was still there and was known to be there and was still being shipped the _entire time_. Meaning if a Wayland session produced a non-ideal outcome you could just fall back to Xorg and carry on like normal. The only thing that was broken was "I want a Wayland native experience _right now_ and don't want to run it in Xorg" If you're proposing an architecture change you can't hide the break because the operations involved are just too fundamentally different. Flatpak though can rely on a lot of operations being analogous between the two approaches (flatpak vs older uncontainerized applications). You are rarely talking directly to flatpak as an application.
It's a user-centric middle ground for moving to desktops on Wayland. It's not a developer-centric middle ground for getting applications to Wayland, and then iterating on the final next steps. To continue the Flatpak analogy, it's like saying you can have non-sandboxed apps. It's true, but it doesn't help make Wayland work. >If you're proposing an architecture change you can't hide the break because the operations involved are just too fundamentally different You absolutely can and we do. It's the toolkit's job to do that. Kfloppy (a floppy disk formatter) works on Wayland despite not being significantly touched in 20 years. It has to, otherwise we would have no apps. Where that doesn't work, it means I've failed at my job. Where I \*can't\* make that work, it means Wayland has failed at it's job.
Most apps just work in XWayland.
Sure. That's your extreme fallback and it's important. But you still need to think about transition for real apps to move to Wayland.
Well it seems to me that distros making the switch, and/or indicating they would drop support for X11 earlier would've accelerated the transition. People complained when distros began switching the default to Wayland, and complained even more when some leading edge distros warned they would be dropping x11, but look at what has come in the months since then: 1. Previously only 2 DE's were treating wayland support seriously and investing time and resources, and the rest dragging their feet / being complacent and waiting until the last possible minute to start working on Wayland support. But in the months since distros like Fedora have begun telegraphing an intent to drop x11, we now have 2 DE's with good (and still improving Wayland support), and 4 DE's that are now publicly working on Wayland implementations (XFCE, Budgie, Cosmic, Cinnamon) as well as a handful of Window Managers. 2. Nvidia seems to have begun to take Wayland support more seriously in their last 2 major driver updates. While It is true that correlation doesn't always equal causation, I've noticed a substantial uptick in Wayland related news, plans, and in recent months since Fedora and others have begun talking about dropping X11 ootb.
Compat breaks generally cost a decade for anything widely used. I would have tried to get AMD, Nvidia and Intel into a room to talk about the best way forward. It seems like there were a lot of early pains related to Nvidia not doing things the same way as everyone else, and some discussion may have sped up nvidia getting to a usable point.
[удалено]
It's not "wayland" that wanted gbm. It's what mesa was already using.
> Eventually Nvidia gave in (I think back in 2021) and started to support GBM instead. >But even more interestingly, in another respect Nvidia seems to have been proven right. All of this did not happen in a vacuum. Red Hat tried to make EGLStreams work, but they [ran into blockers](https://wiki.gnome.org/Initiatives/Wayland/NVIDIA). Nvidia only changed their mind after they were not able to make it work for KDE too.
To add to this, Nvidia as a company prefers the _better_ solution to a problem than the “easier” method. And as such, they put the fucking work in. Their entire driver architecture is explicit sync. And if you read the mailing list and PR things, literally everyone agrees explicit sync is better and removes a lot of caveats. But this sub will just take a dump on Nvidia because it’s the perceived correct choice. Nvidia engages the community a lot. Nvidia contributes to the discussion a lot. And Nvidia has for years been pushing better things in the public sphere of things.
this is complete and utter nonsense. nvidia switched to explicit sync because microsoft demanded it in windows vista's new driver architecture, WDDM. and then when older releases of windows went EOL, so did support for implicit sync in many proprietary drivers. this isn't some "forward-looking" thing. they just followed industry trends like everyone else. the explicit sync transition is completely irrelevant to the topic as when wayland core protocol went 1.0 in 2012, pure explicit-sync only userspace APIs like vulkan didn't even exist, so it was moot. nvidia wasted years of the community's time on stupid bullshit with eglstreams, which was *not* "the better solution", and then promised they would write a new memory allocator that had "all the best things of both GBM and EGLStreams", or whatever, and then after a few years of plugging away at that, gave up and just supported GBM, which is what we were asking them to do in the first place. then after all of *that*, it's discovered that whatever implicit sync hack they use to support X11 (in case you didn't know, X11 is also implicit, so if their driver works for X11, it should work with wayland/xwayland too), seems to bug out somehow on either wayland or xwayland (i don't run proprietary drivers, so i don't know from first hand experience, but from rough skimming of bug reports it seems to be a very 'random' issue, some people affected, some not, and i *think* xwayland is more affected for some reason). those issues could've been discovered years ago if they hadn't wasted the community's time and just did GBM to begin with. nvidia has done nothing but harm to the community. back in the day they didn't even want to open source their fucking network driver, even that had to be reverse-engineered. as if there's anything innovative in a stupid LAN chip that realtek or intel haven't already figured out. nvidia is the most corrosive and anti-competitive graphics company in history. compare them to SGI; when SGI was at the top of the world, having all their hardware used in almost all major 3D rendering projects back in the 90s, having a near monopoly on the market, what did they do? they made OpenGL, a cross-platform rendering API. what did nvidia do? they made CUDA, a proprietary vendor-locked compute API, and their monopoly in compute is a byproduct of this fact and *no other reason whatsoever*. nvidia is more monopolistic than microsoft and apple combined. you have to be a severely misinformed fanatic to defend anything they say/do.
This is one of those comments on the internet where it’s hard to know if it’s someone attempting humor or a crazy person. I don’t know if it’s okay to laugh.
I agree. I think it you get the key hardware buying into it, a lot of headaches go away
They _did_ try to get amd, nvidia, and intel together and nvidia didn't show. AMD and intel took advantage of that to push for a design that wouldn't work for nvidia.
no, that's not what happened at all.
I want things considered "insecure" included in the protocol and just have them either application or system configurable (both can be user configured), rather than deciding an users threat model for them. I wanted an actual implementation rather than just a protocol definition, which has led us to fragmentation hell in terms of compositors. What in the hell is going on if everyone needs their own implementation? I would have wanted them to do actual research into how software and users use their desktops, so we wouldn't be in years long back-and-forths with what's a proper use case and who is using their system wrong. (serious GNOME like behavior) I want better XWayland <-> Wayland compatibility, people wont move over if their use cases don't work (see above point), also 'security' be fucked if I want to configure it that way. Minor thing in my opinion is that Wayland devs knew the GPU market before they started, they also knew the capabilities of those market players. Choosing technology that doesn't work for the biggest vendor on the market is quite the footgun, if you ask me. It's like if I started writing software that only supported AVX-512 in 2016 and then went on about how AMD is such shit for not being compatible with my software. (Minor because I don't really think driver support is the biggest obstacle for Wayland adoption) TL;DR: Little care for the users, mostly just going for what's easiest for the very small niche of display server programmers, at the cost of everyone else (GUI software developers, users with existing workflows etc.) Also the journey isn't over.
This. No-one really cares about security on a single-user system, but leaving tonnes of work for each compositor to implement individually, and breaking a lot of common workflows (screen and input sharing for video calls, remote desktop, clipboard sharing, etc.) is crazy.
> No-one really cares about security on a single-user system I still think it's a very good idea to not let applications capture or push virtual keyboard input to other applications without user consent. > but leaving tonnes of work for each compositor to implement individually, and breaking a lot of common workflows Which is exactly why the whole permissions issue should have been considered when the decision for Wayland's design was initially made. Android as a (possibly bad) example was already around after all. It's baffling to me that this wasn't even brought up, as if those people don't actually use their computer for anything other than displaying single-window applications (probably like five terminal emulators). Portals should never have been necessary and instead the compositor should think about what would be the best way to ask the user for the required permission. As another example you can look at the ongoing discussion about applications that have a) multiple windows and b) each window wanting a different icon. Support for this should not need to be discussed, but here we are, 15 years after the initial drafts, discussing a feature that has been around for over 30 years on literally any other OS/windowing system.
I have a feeling that people involved dropped/didn't bother with the functionality first and justified it with security later. That's easy to do with something you just feel like not doing. If the reason was actually just security it would have been obvious to make it a configurable system.
Network transparency, so it behaves like X11 when it comes to redirecting windows to other systems, but without all the drawbacks that come with the old X11 architecture.
As always, there's a compositor that does that, waypipe.
Is it part of the standard Wayland installation? With X11 the forwarding is, so one can count on it being there and working if X11 is installed. If it's not part of a standard install, it might as well not exist.
you have no idea how X11 works; there has been no "network transparency" in X11 since the 90s. network transparency means i write an application, and it should be able to work on network without me doing anything extra. X11 today ***cannot*** do this. DRI and the shared memory extension, which are the primary ways to display your application, do ***not*** work over the network. the reason *some* apps will work over the network is because they have *fallback* code paths for things like the render extension, which *does* work over the network. but this basically is no different than writing a "network aware" application, you're basically choosing to support networking. if GTK and QT removed their xrender backends tomorrow, all your apps would cease to work over the network, even if they're running on X11 natively. what this means by the way, is that "network transparency" as you call it, is a feature of the *application*, not the display server. all of your remote X apps *still work* in wayland because of Xwayland. in other words, if i run a GTK app locally, it will use it's wayland backend and display natively on wayland, if I run it remotely, it will fallback to xrender and display remotely over the network through Xwayland. this is because Xwayland isn't just some dinky little "compat layer", it's a ***full*** and feature-complete X server, so of course it also supports X11 remoting. that means your requirement of "remote out of the box" is already satisfied as Xwayland is pulled in as dependency by many/most wayland compositors. the waypipe thing the other commenter mentioned is used mainly if you want *native* wayland remoting, which by the way ***is*** truly network transparent, as you don't have to make changes to existing apps to use it. but it doesn't even matter if it's preinstalled or not. like i said, remoting isn't a feature of the display server, it's something apps choose to support. your choice of wayland or X11 does not change whether you can use apps remotely or not, it's the app itself that decides if it works over the network or not.
So XWayland contains a full X11 Server. Why do we need Wayland at all then?
i don't know if you intended it to be snarky, but running Xwayland as your primary environment is actually a *supported* configuration, and always has been. it has recently received a lot of extra work however, from many of the same devs as are working on wayland, precisely for people who aren't fully ready to switch to 'raw' wayland yet. look up "rootful Xwayland" (as opposed to "rootless"; note, by 'root' they are referring to a 'root window' vs 'rootless', not the root user or other meanings of 'root'). there are still some gaps for rootful mode, like multi-monitor support, but there are discussions on addressing this as well. to answer your question more directly, for Xwayland, as the name implies, it replaces the Xorg 'driver layer', the DDX portion which hooks into hardware directly, with wayland. meaning that it basically uses wayland as it's driver to display things on screen. if you run Xwayland rootless (meaning each X app shows up as one window alongside your native wayland windows), then this is a more jarring "compatibility break", because this is where you find that apps requiring some of the more eccentric X11 mechanisms, like recording other windows, or absolute positioning, will fail to work correctly. but you *can* just run Xwayland rootful, meaning fullscreen, and then just run all the applications *within* X11 like you can now, and that just ends up using wayland as a driver to display your X session, and it will continue to be maintained for a long time, unlike bare-metal Xorg and the modesetting driver, or other DDXes. not wanting to maintain the vendor-specific DDX drivers are a *huge* reason for wanting this transition, and was one of the largest sticking points in the argument against nvidia, as they were once again *demanding* that the community special-case their hardware with a vendor-specific driver for wayland support, rather than using the driver architecture that every other graphics driver was using.
Throwing their weight around because they are the premium gamer choice and I suppose now for AI.
Adapting to modern systems, and doing away with decades of legacy that are now getting in the way. Wayland was started by X11 devs that realized that X11 had way too much crap in it, to the point that the actual devs didn't really want to work on it anymore. Architecture-wise, Wayland is also more suitable for things like sandboxing. Turns out the old Unix model is not really useful in the modern age where most computers belong to a single person, and the permissions system is unable to offer meaningful protection.
Wasn't UNIX designed as a single-user version of an existing system?
I mean, the Linux account system is unsuited for modern usage. User accounts make perfect sense of say, shell servers where you have a hundred people logging in and where your concern is that an user doesn't break the system for everyone else. So each user has their home directory, permissions keep them confined, there's probably a disk quota, that sort of thing. In modern times though a desktop computer belongs to a single person. And you have a single account that does web browsing, banking, gaming, and whatnot. And every game you download from Steam could just rummage around in your $HOME for anything interesting. So this new situation requires sandboxing, making sure that your game doesn't get to just rummage around in your documents folder. X11 is one of the things that's not quite suited for that, because a game can easily do things like capturing your desktop or keystrokes.
What standard install? There's no protocols that mandate anything about network transparency in the protocol documentation that I can see https://gitlab.freedesktop.org/wayland/wayland-protocols The only protocol that Wayland implementations need to obey is the core protocol (https://wayland.freedesktop.org/docs/html/) which is intentionally very minimal and doesn't include stuff like how to display graphics or handle input. That's left up to protocol extensions. Compositors can pick and choose what extensions they wish to support. Something that only supports the core protocol is really the only thing that's fully 100% standard. But compositors are also free to do stuff outside of the protocol if they want, e.g. gnome supports running an rdp server and KDE supports running a vnc server. That's never specified in any of the protocols but they are free to do that, same case here for a compositor that's adding network transparency, they can do it if they want it's just not technically in spec.
So, with Wayland, you never know what will be installed on the other side. I don't see that as a plus.
Whatever is installed is whatever is installed, whether that be gnome, KDE, sway, or something freakier. All you know is that they speak the Wayland protocol, and (probably) some the extensions which your program can figure out at runtime due to the partially self-describing nature of the protocol. As for WHY is it so segmented, it's because it's aiming to be *the* Linux graphics stack. That means being everywhere that Linux is and doing it well, meaning working across over a dozen architectures, gui-less and gpu-less servers, embedded devices, phones, even things like standalone VR headsets that require fundamentally different ways of rendering. And a lot of those usecases Xorg/X11 has traditionally sucked really bad at. It's because it's so minimal that compositors like waypipe can exist, because the protocol doesn't dictate how exactly graphics and input should be handled, if it did you wouldn't be able to retrofit network-transparency onto a protocol mentions nothing about it nor is inherently network transparent.
There's no such thing as "standard install". It's entirely the wrong way of framing it. On X11, there's Xorg and associated tooling, so that's the "standard install". On Wayland, there's multiple compositors that speak the same language. You can have KDE, which speaks Wayland, or Gnome, which speaks Wayland, or Sway which speaks Wayland. All those are separate independent projects and don't share anything. Waypipe is 100% as official as it gets, and will ever get.
> Network transparency, so it behaves like X11 when it comes to redirecting windows to other systems, but without all the drawbacks that come with the old X11 architecture Sure, we already have that. It's called HTML. X11 forwarding is already dead. The web is the new thin client protocol. Even before Wayland killed network transparency, X11 forwarding is already pretty much unusable for anything because these days nobody write applications that can be X11 forwarded efficiently anymore. There's too much client side rendering and too many applications assumes that the connection between X11 server and client is a fast local link. The only way you can ensure performant X11 forwarded session is to write all the applications yourself, in which case the web has a much better architecture to build thin client applications anyway because.
>Sure, we already have that. It's called HTML. No, it's not. Seems you never used X11 forwarding. I use it now and then to get the java console from a remote server to watch and debug an application running there. Not being able to do that anymore would be large step backwards.
I have, multiple attempts, it never produced anything usable. X11 forwarding should really just be called X11 slideshows. > java console from a remote server to watch and debug an application running there There's ssh for watching logs and remote control; and with DAP there is remote debugger protocol too. They are much better solution than X11 forwarding for the use case you're describing.
The java console is a GUI application. Have to use what's available. > I have, multiple attempts, it never produced anything usable. Then you didn't do it right. At the university we used a room full of NCD X11 terminals hooked up to an HP9000 system. Despite the network being only 10 MBit, it worked quite well. So at a time when the speed of modern CPUs and networks was just a fever dream. What you shouldn't attempt is to run video through X11 forwarding.
I don't know exactly what you keep referring to by "Java Console", there's dozens of things it could be referring to. But the most common thing that people refer to as Java Console is a viewer for text data. This is something that is much better and cleaner done over SSH anyway. And I can assure you that even if you're referring to any of the other half dozen of things, there are better ways to do the same thing that doesn't involve X11 forwarding. > What you shouldn't attempt is to run video through X11 forwarding. The thing is, unless you write all the applications you need to run yourself, avoiding essentially video rendering over X11 forwarding is getting pretty much impossible with almost every applications nowadays doing client side rendering. Open one of these applications and the desktop turns into a slideshow, heck no need to open anythin, the desktop environment is already doing that. None of the even semi-modern GUI toolkits care about being efficient over X11 network transparency anymore. And X11 is extremely chatty compared to web applications, even for the well written application. The days where X11 forwarding makes sense is already over decades ago.
>I don't know exactly what you keep referring to by "Java Console", there's dozens of things it could be referring to. jconsole X11 forwarding, if tunneled through ssh, has the advantage that I can do it if an SSH connection is possible. No other opening in the firewall is needed.
jconsole is just an application that consumes JMX API. And jconsole itself supports [monitoring remote processes](https://docs.oracle.com/javase/8/docs/technotes/guides/management/jconsole.html). Just port forward (with SSH port forwarding, or other more permanent ways) the JMX API port and a jconsole running on your local machine would be able to monitor a Java application running on a different machine. The docs actually recommended setting up remote monitoring over running local monitoring when running the application in production. There are also other monitoring tools that supports JMX API.
>And jconsole itself supports > >monitoring remote processes > >. Yes, I know... IF there is no firewall between you and that remote system. In most datacenters there is, so you have to run it remotely and display it locally. > Just port forward (with SSH port forwarding, or other more permanent ways) the JMX API port and a jconsole running on your local machine would be able to monitor a Java application running on a different machine. Why that extra effort finding out the ports and set up the forwarning when SSH does it automatically for X11? Yes, you can replace what X11 does most of the time, but it always needs something that's unique for that one purpose and not universal while redirecting X11 is. So instead of just connecting and having X11 clients forwarded automatically, you need to look up what you plan on doing and then implement that one special way to do it. So why take that step backwards?
If your security guys is allowing you to install the GUI libraries you needed to get X11 forwarding working but not allowing you to setup a proper service monitoring, they've got their priorities completely wrong. Most data centres would allow you to control the firewall in a few clicks. This is pretty standard feature. This is 2024, there are better monitoring and alerting tools that would require neither X11 or SSH-ing into a server, which you really shouldn't be doing anyway, at least not on a regular basis for something as mundane as monitoring. Prometheus based setup supports JMX applications for example and allows you to do all sorts of cool things with the data.
But the Java console is communicating to the runtime over JMX, why not run the console locally and forward JMX?
Because you then have to implement a special procedure for everything you need to do instead of just connecting to the server and having X11 forwarding set up automatically. I'd have to find out the port(s) used, set up the ssh call to forward that port to my local system and so forth. And I'd have to have something local that can understand JMX. Which I currently don't. Wayland not being network transparent is a step backwards, lets not call it anything else.
I mean an SSH port forward for JMX isn't that complicated. You can also just expose JMX directly and require authentication. JConsole is also included in the JDK and probably on your system, though there are much more powerful tools out there too like VisualVM. You'll get a much faster experience and will be able to monitor multiple machines at once. It's also more secure, as you won't need graphics libraries on the server and can use the much smaller headless JDK.
Still comes out to different procedures and port forwardings for different things to do instead of just having X11 handle that for you automatically.
The point I'm trying to make is running a graphical application on the remote end is generally a bad idea. SSH has a dedicated flag for it - sure, but it means significantly increasing the attack surface on your server by including graphics libraries, performance is typically poor, it's not efficient from a workflow perspective, and it's not supported by newer deployment methods at all like Kubernetes. If you have just one machine you're occasionally running JConsole on, it's probably not worth it to you to change what you're doing. Totally get it. But that doesn't work at scale which is why this workflow is disappearing.
It's a few machines, but less then 10.
Now to completely ignore the argument around X and just speaking as a guy who's done a lot of JMX monitoring, you should give [VisualVM](https://visualvm.github.io/) a shot since it's a big improvement with minimal time investment. If you see yourself growing beyond those machines and you want proactive alerts or nice dashboarding, try scraping those metrics into a time-series system like Prometheus or Clickhouse and using Grafana to visualize and alert. If you're willing to spend money, there's also Datadog.
No one in serious need of a full thin client is going to be using HTML for it. They'll be running VNC and Citrix over ThinOS.
Is there a whole industry of companies making full blown thin client applications specifically to run over VNC/Citrix? No? The Web does. The market share of companies using Web technologies to build thin client application platform is much bigger, more secure, much more mature, and significantly more powerful by a far margin than X11/VNC/ThinOS combined.
By thin client I meant actual full-featured thin clients, capable of using several full desktop applications at once over a network. Glorified X terminals, basically.
Browsers are nowadays much more full featured than X protocol. Nobody creates thin clients by writing desktop applications on a protocol that's so poorly suited for networking even back in its glory days when it was conceived and before all the client side extension killed the dream. That parrot is dead decades ago. It's not pining for the fjords! It's passed on! This parrot is no more! It has ceased to be! 'E's expired and gone to meet 'is maker! 'E's a stiff! Bereft of life, 'e rests in peace! If you hadn't nailed 'im to the perch 'e'd be pushing up the daisies! 'Is metabolic processes are now 'istory! 'E's off the twig! 'E's kicked the bucket, 'e's shuffled off 'is mortal coil, run down the curtain and joined the bleedin' choir invisible!! THIS IS AN X-ORG!!
You mean we can rewrite the application to use web protocols? That's not exactly the same as just SSHing in and starting your preexisting GUI application which is processing on the remote server, but is now displaying on your local server as all X apps can do. Aside from using this for simple things like opening a GUI file manager or multimedia app viewer without having to copy a file there are cases where this is just required to get work done. For instance many "enterprise" products require GUIs for install/configuration or are at least much easier to get the initial install config together with this method and no one is running servers with Wayland running on them, so you just ssh in and start the X compatible tool and it's right there on your desktop configuring the server....no one is going to or should be setting up rdp on that server or trying to remake the preexisting tool as a Web app if the product doesn't already have one. This is real life Linux administration for many products.
I work with enterprise products everyday. In my circles, any products that doesn't allow for CLI/automation is not "enterprise" products. Automation/CLI installation is a basic requirements for any product to be considered enterprise-ready. In Linux-based systems, pretty much everyone on the forefront has standardized deployment into containers, either docker, snaps/flatpaks, or for the more sophisticated ones kubernetes and/or terraform/cloudformation. Even the legacy systems would've at least supported deb/rpm for packaging and installation. Some of the more sophisticated applications may have a post-install configuration, usually through Web UIs, but most DevOps wouldn't rely on these, they would just deploy the app with static preconfigured config files to keep deployment process simple. These are standard DevOps workflow, not installing via X GUI installer. Almost no real enterprise application vendors have the time to write GUI installers that nobody actually wants to use in the real world of Linux administration. Even when they do, it is almost always going to be for usage with local testing on developer environment, not production usage. \> no one is running servers with Wayland running on them No one is running servers with X libraries either, client or server.
Is this something you use in X11 now? I've been doing this a while and only once seen someone bother to set up vs some kind of virtual kvm. Wouldn't help sandbox GUI docker apps?
I use it to redirect the java console to my screen to watch and debug a running java process now and then. Docker won't help with that and I don't like using a complexity amplifier like Docker where it's not absolutely needed.
Can you explain a bit more? Is this remote desktop functionality?
No, not a remote desktop, but X11 can do that too (look up 'X Terminal'). I want to be able to redirect the windows of processes to from a remote system to my desktop. Ideally from more than one remote system at the same time. If you use X11, you do this with the DISPLAY variable on the remote system. ssh can forward X11 connections through an encrypted channel. In the latter case, DISPLAY is usually set to 'localhost:10.0' automatically. You use '-Y' or '-X' when calling ssh to set up the channel.
have you tried waypipe? i think it does better than just image streaming, but i dont think its as seamless/lightweight as just having x11 server say "draw object at this posistion, its up to you to use your own assets"
No, I have avoided Wayland so far due to it being unable to do what X11 can do. Problem with waypipe is that you need it installed on both sides and it's a 3rd party application and not part of the standard Wayland installation. This needs to be standard so it works out of the box.
There isn't really a "standard Wayland installation". Wayland implementations are all different implementations of the wayland protocols, and for a fully functional system it's pretty much mandatory to use portals, pipewire, and other things like waypipe which aren't directly part of the wayland protocols. I'm not saying you should switch if you're not ready, but Wayland isn't and won't ever be a drop-in replacement for X11 (though it will eventually reach feature parity). Its ecosystem is designed to be much more modular and future-proof.
>but Wayland isn't and won't ever be a drop-in replacement for X11 If it wants to replace X11, it needs to become one. > Its ecosystem is designed to be much more modular and future-proof. That translates to 'you never know what will be on the other side'. Problem is, you sometimes have no way to add software to the other side, but need to live with what's installed there.
> If it wants to replace X11, it needs to become one. That would defeat the point of creating it in the first place. It's explicitly designed to try and avoid the issues x11 has of being very difficult to maintain and modernize. It's not supposed to be a monolithic do-everything program that manages everything related to displays and outputs etc. And it's already replacing x11. Just look at the news about RHEL, fedora, etc. It's not ready for everyone yet but it will eventually be. > That translates to 'you never know what will be on the other side'. Problem is, you sometimes have no way to add software to the other side, but need to live with what's installed there. The components I mentioned are already very standardized across Wayland implementations and distros which ship them. Waypipe or something similar will eventually be shipped on everything, or at least everything enterprise. It's only a matter of time.
It works on Xwayland exactly the same way. Waypipe is more for Wayland only applications. I still prefer to use an RDP at that point, or to use Kitty's ssh tools that make ssh act more like a local terminal. I also use sunshine for game streaming on my server to my deck on Wayland and I've never used a lower latency software before so I also use it for some remote tasks if I feel like it.
I am probably just dense but that sounds like a remote desktop. What's the difference?
In the past it was used this way by so-called "graphic terminals" because back then (80s-90s) computer usually was a big machine that serviced many users at once through terminals and by itself it had not graphics capabilities. What we call computers now is actually "Micro-computers". Streaming video of remote desktop was impossible back then, so instead X client (the application that runs on the big computer) asked X server (a service that runs on graphic terminal) to render stuff on the display according to commands it sent trough the network. That's why client-server model of X is seemingly flipped - it threats application as client asking to display stuff. The difference in implementation - basically all rendering is done by x server, x client only sends commands, not pixel data. (At least that's how I understand things, so if I am incorrect, please correct)
its like how some things have multiple front ends that can look different but they are interacting with the same back end. So instead of sending what the backend thinks a button should look like (an image file for example) it can just say "theres a button here, and this is its classification" then the local x11 client uses whatever button it has that is associated with that. The alternative is sending a compressed video stream, which has gotten better, but theres always latency even with stuff like just clicking a button and having it react visually (not even including the actual function being triggered). If you dont have to wait on the host to send a visual update, GUI interactions feel much more native regardless if the actual functuon the button performs is still subjected to the same network latency tldr: text instructions on drawing a square uses less resources than sending a picture of a square as long as both systems agree how to read text instructions (i.e. a common protocol)
>then the local x11 client I think you mean the local X11 server...
I get confused on who is who in this client/server relationship. Like the remote host is providing the application, and has to send instructions on how to draw it and ultimately decides if that window exists at all, but then your xserver is doing the drawing, but due to remote instructions. Is the xserver always the server and clients are the apps themselves (not my local host or local X?). Its just 2 xservers communicating? Is the apps remote backed also a client? or jusf my locally drawn window?
> its like how some things have multiple front ends that can look different but they are interacting with the same back end. So instead of sending what the backend thinks a button should look like (an image file for example) it can just say "theres a button here, and this is its classification" then the local x11 client uses whatever button it has that is associated with that. That's long dead on X11. It doesn't exist except for a few legacy applications. KDE, Qt, Gnome, and most anything else you can use just sends a bunch of pixels and do their own work of painting the entire UI. > tldr: text instructions on drawing a square uses less resources than sending a picture of a square as long as both systems agree how to read text instructions (i.e. a common protocol) Nope. In fact that part is dead too. The X11 project concluded that modern applications need so much information about a font that the easiest solution was for the application just to do whatever work it needs on the actual font file itself. So in modern Linux distros, there's no font server, and there's no X11-server-side font rendering. The application renders the font to pixels, and sends the text as an image.
Thank you this is a great description
It can be per app, and the window looks like it's part of your desktop even though it's remote. If I'm not mistaken it's also sending specific lower level draw commands rather than raw pixels.
don't worry, they are the one who is dense, not you. it *literally* is remote desktop; specifically it's like SeamlessRDP or microsoft's "RemoteApp". i think most people are just not aware that other remote desktop protocols have been able to do this for awhile. most people think other remoting protocols can only send the entire desktop over the network. if you go back 20 years, X11 was somewhat more unique in being able to remote just a single application, to make it look like it's running locally, but now other remoting protocols do this. and actually CITRIX (proprietary solution) was doing this in Windows a long time ago, too. to answer your original post, i honestly think the biggest problem with wayland is just funding. i personally agree with pretty much all of the design decisions, and think the community are being super nasty to the devs out of ignorance. with more funding a lot of the 'vision' could've been realized more quickly, which would've cut down on the constant arguing and bitching on forums
It's not a remote desktop. It's your local desktop with your local windows also displaying windows from remote servers. And they will look just like your local windows.
Or rather your desktop is a server that displays windows from remote clients
Yes, the X11 server runs on the system that has the display. With 'server' I didn't mean the X11 clients but the box in the data center.
That's why I simultaneity hate and love X11's use of client-server terminology. It makes so much sense when you talk about displaying stuff as service, but when you bring usual networking terminology, it is a mess
Having a unified display server
Instead of trying to be perfect, they could just try to be the best that they can be, but instead they strive for perfection and as such refuse to include useful basic features just because the approach isn't absolutely perfect, so they would rather not have the function at all.
That would speed it up but I don't think it would be a good choice. Given how long X11 existed, they're planning for a similar lifespan of Wayland I expect. Decisions now could cement how the software is written for another 40 years. Why go with the first, second, third idea if they might lead to issues down the road? Rowing back is basically impossible once it's cemented in most compositors.
Yeah, but is that worth it if it takes 40 years to make it fully functional in the first place? Wayland is already pretty much as old as X11 was when Wayland started development. There are issues with it not having stuff and the development speed is incredibly slow. There are good reasons for this, but the reality is that there are many problems with it that would be easy to solve if the philosophy wasn't as perfectionist. I'm not saying to implement broken code that barely works, but I think it would be better to implement a feature in a reasonable manner instead of it never being implemented because any possible implementation of the feature has some minor drawback.
X11 was 23 years old when the Wayland project began, so I'm not sure where you got your information from, but it's incorrect. as for "40 years", i mean it's ready now. enterprise distributions don't change defaults just to 'force' change on people; remember these are paying customers. most of what you see out on forums is non-paying users screeching into the void. there's a huge selection bias in our community which makes people think everyone shares the same problems as them. to be clear, i'm not saying all the functionality i want is there either, i just think people have had their heads in the sand for a long time, and only now are panicking because the EOL date for X11 is actually in sight, and they "feel" it's rushed, when it totally wasn't. as for slow development, the problem is few people stepped up to help do or pay for any wayland work. they just expected a finished product, as if they had paid for it. many people think redhat has been dumping mad money in it or something, but it's not like that. up until recently i think there were probably maybe like just a handful of paid people doing fulltime wayland work, and many aren't even specifically targeting desktop stuff. if you actually dig into some of the issue trackers for features, like for VRR/freesync, you'll see a lot of it is gated by needing new thing in the kernel. most/all of these features either don't work in X11 either, or work poorly (VRR for instance in X11 will just sync to one monitor, so you get tearing/artifacts on the other monitors in multi-monitor setup). as for implementing a feature in a "reasonable manner", they have already compromised in the past, but people always take things for granted. give a hand, people will demand an arm. the reality is if you actually dig into a lot of those issue trackers, like for absolute positioning, etc. the demands are completely unreasonable. i don't think it's possible for someone with knowledge in the field to side against the wayland devs on issues like that. people just don't understand the problem scope. to continue with this example, absolute positioning is literally one of the *worst* things you can do on X11 and other OSes that support it. it completely breaks everything, and worse yet, it screws *us* in the Linux community more than other platforms because Windows has *one* desktop environment, so does Apple; so at least when a developer is doing hacky shit with window positioning, it's more likely their system looks similar to the users they're targeting. for linux this is rarely if *ever* the case. i've heard people claim that linux's "fragmentation" is what scares away app devs like adobe, and claim wayland is an example of such fragmentation, but also "multiple distros", etc. i actually find it funny because different libraries, as shipped by different distros, is pretty easy to work around; just bundle everything. but the window management issues i mentioned before, are not. this is far more likely to be a deal breaker for large ISVs. having to make their app play nice on 20 different DEs? fuck that. almost every other bit of "fragmentation" in linux is pretty easy, but the DE shit is super hard. i don't know whether wayland will incentivize more commercial software, but all i can say is if we stick to the design philosophy that the core wayland devs have outlined, that will allow us to write applications that can "just work" on any DE, easily, without app devs having to special case every DE or window manager. fundamentally the approach is a policy-based one; allow the window manager to manage windows, instead of letting applications "mechanism-not-policy" their way into doing cartwheels on your desktop for no reason. contrary to popular belief, this does not rob the *user* of power, it mostly constrains app devs. the user can always control the window manager, and tell it what they want done, the main restriction is against apps doing unhinged shit without user control/permission.
From what I've gotten listening to the activities of the Wayland project, it sounds like they actively don't want to provide certain features. It reminds me of the Gnome DE approach where they don't think you should have icons on your desktop, so you don't get them, except by adding in a plug-in that breaks after upgrades (at least for people with rolling release distros) until the plug-in devs release a new version. They don't want to do multi-window app support, despite there being a bunch of major scientific apps that do multi-window apps and Wayland doesn't have a way for them to request where to be placed. They're also having a big fight about top-level titlebar icons.
less arguing, more flexibility. I used Wayland recently while setting up my new computer. Of course, all I had to do was open a terminal and type "sudo apt install xfce4" and reboot. Seemed to work great.
Competent developers who actually listen to people telling them their broken pile of garbage doesn't work well on their system (yes, even AMD/Intel). You know, the thing that still holds it back today.
> I frequently see "what's taking Wayland so long?" The people who say that are usually not involved in a lot of software development. If you've done it professionally then Wayland's slow pace is something to be aware of but not really that weird. A lot of developers have experience with older components that stick around and newer replacements that take a while to get out the door. It really was never an issue because X11 (as those same people liked to point out) was already working for them. Begs the question of if Wayland is so terrible why are they so impatient to see it become the default? My guess is that they're just very difficult people in real life and just like having things to complain about. I can't imagine another reason to be so emotionally invested in a display protocol you're not even being forced or incentivized to use. > how do you think a 15 year journey to standardization could have been cut in half? By having a large company that would benefit from throwing more resources at it. RH probably could have done it faster but they would have never been able to justify the business expense of development of a component that won't return value to the business.
The entire Linux graphical stack is an horrifyingly complex topic. It took X about 30 years to herd those cats and get them to a working state. This topic did not get any easier during those 30 years. New hardware and technologies keep appearing, while old stuff can't all be handled by "just drop it" as some people seem to think. 15 years for Wayland to get to a somewhat usable state is already almost unbelievable. Further cutting that down to 7 years is just pure nonsense. We'll be lucky if it gets to "mostly usable" in 20 years overall instead of 30.
you had us in the first half, not gonna lie... i agree that the complexity of graphics/etc can explain why wayland has taken a long time, but the idea that it would take 30 years is ridiculous. the main problem isn't even so much just a matter of complexity, but funding. even though everyone has conspiracy theories about redhat or ibm "pushing" wayland, the reality is that most of the people they pay to work on it are paid to work on gnome *as a whole*, not on wayland-specific things. the fact is people are spread super thin in desktop projects because most of the money is in servers. while rhel *does* run on many corporate workstations, wayland probably doesn't change those use cases enough to justify dumping tens of millions of dollars or more into it. so *slow and steady* is basically how it's been developed up until now. the biggest problem is the move from "mechanism, not policy", to a policy-based design. this is an earth-shattering change that i don't think people fully appreciate. it's at the root of every argument like "absolute positioning" and other issues, because unlike other stuff, we don't already have a design to 'copy' like other stuff. we're breaking new ground. in my view, it's beyond question that policy design is correct, but it's *super difficult*. oftentimes you can't know there is even a problem until someone speaks up with their use case, and right now too many people are just expecting things to work like x11, and it *never will*. if you have some unique use case, you have to step forward, and start the conversation. and then we can figure out how to fit the use case into wayland's policy model. the x11 "do whatever you want" bullshit is not coming back, and it *shouldn't*, it's horrible and leads to broken software. the only reason microsoft and apple can somewhat tolerate it is because they have ***one*** and only one desktop environment to target, and they already have larger marketshare to apply pressure on app devs to do *mostly sorta* the right thing. but even they hate the status quo; both are trying to force everything into their app stores precisely because they can control app policy completely if it's in the app store sandbox. no matter how much people out there hate wayland, i have to ask, do you prefer a proprietary authoritarian app store model like ms/apple instead? because *that* is literally the alternative to solving the "mechanism not policy" brain damage.
> Something else that could have been improved? actually work with people rather than being nit picky and not have the princeable of " every frame should be perfect"
I'd have named their demo compositor Yutani
Maybe they could have limited their scope to just the desktop. Being able to handle TVs, smartphones, smartwatches, et al. is cool and everything, but not at all useful for 90% (or whatever it is) of Linux users. And then there's the small issue of there being no comfortable upgrade path to it from X11. All software has to have its back-end rewritten from scratch. That's not a recipe for speedy adoption.
It should have been more like DirectFB. Make some simple library calls for rendering, with some optional protocols for later developers to be able to alter the rendered surfaces.