Graphical desktop system X Window just turned 38 The X window system turned 38 years old this week, and although it has more rivals than ever, it is still the go-to for a graphical desktop on Unix. The first public release of the X window system, according to Robert W. Scheifler's announcement, was 19 June 1984. X itself was a rewrite of an older windowing system called W, …
-> The X project is largely unchanging these days
Good. It means there is a stable API. So what if it is *old*?
Imagine like the Devilfish you had gone all in on Unity, only to have the rug pulled out from under your feet. Canonical did it once, they can do it again with Mir.
I don't have anything against Wayland per se, but I haven't looked at it for a quite a while. I'm a fan of Nvidia graphics cards generally (with the binary drivers that work), and I recall Wayland not working properly or well with them. For me that means forgeddaboutit.
-> XWayland
And it had better keep working too. It's all very well for somebody to devise some new graphical desktop, but it's quite another to then expect other people to rewrite their code to work with it. If XWayland disappears that will immediately render the Linux desktop less useful.
The issue isn't that X is unstable, it is that it is obsolete. Huge chunks of it aren't used and haven't been used for years - the drawing primitives, fonts, damage model etc. Yet it all has to be maintained or it isn't the same protocol any more. And to do things approaching modern desktop requirements it had to be patched up by extensions which have to jump through hoops to function and had their own limitations and complexity.
That is why everyone including the people who wrote it have abandoned it for Wayland. It doesn't stop X running over Wayland, but X is no longer underpinning the desktop itself. This means you can still run X software but your desktop as a whole benefits from being more responsive & efficient.
There is a good overview of what Wayland is on its home page.
https://wayland.freedesktop.org/architecture.html
I'm aware of all of this. I'm also aware that Wayland is about 14 years old now, and it is only in the last three or four years that *stable* distros have started to use Wayland as the default. (Fedora while mostly stable is not the same thing as RedHat). Ubuntu had problems with Wayland and went back to XOrg, then back to Wayland.
Does Wayland play nice with Nvidia? It's a yes or no question, not a "well if you spend hours looking through forums to see the problems that other people have had and find something which matches your problem then see if there is a solution" question.
If I do a search right now for "wayland nvidia problems" I see plenty. And I am not going to change my graphics card just to get a different graphics display.
If and when Wayland works out of the rpm/dpkg/tarball with Nvidia drivers, and XWayland also works the same, I will change. But PLEASE stop the FUD and just pretend that Wayland is the answer to a lot of problems (a lot of problems that I personally do not experience with XOrg), because it brings its own problems too.
As there is an article about Manjaro, perhaps it is relevant to quote from a Manjaro thread about Wayland and Nvidia: Currently the biggest issue is that NVIDIA does currently not support Xwayland properly, so apps that require it get software rendering. This includes most games, which are the most common use case for proprietary NVIDIA drivers. This is why GNOME automatically disables Wayland if you have NVIDIA.
It's no good pointing the finger at Nvidia. These same cards work with XOrg.
As a boring user the only case I can make for Wayland over X is that on a hi-res screen laptop it makes fonts readable in an ancient application for which I need WINE. I guess that is pretty niche.
When Wayland leaves things in the same state as it found them I'll probably not care. Until then X seems to just work.
Apparently there are lots of reasons why Wayland is a good idea but from over here it still feels like a solution searching for a problem.
It didn't quite make it across. They replaced went from PostScript based to PDF based in the move from NeXT to macOS. As well as being simpler and more suited to the present day it happily avoided paying Adobe any money as PDF was an open standard.
https://stackoverflow.com/a/49846861
Some X11 servers came with the DPS X extension built in. AIX's did, for one. (There aren't any AIX workstations now, I believe, just headless servers; so "AIX X11 server" is a thing of the past.)
I remember doing a bit of DPS stuff under X11 on AIX 3 back in the day.
I suggest you read the link I provided to understand what Wayland is. It has nothing to do with your graphics card. It is a protocol that facilitates communication between clients and window managers. e.g. it allows an application to tell the desktop that it wants to create a surface, and that it wants to render its surface, or listen for events etc.
But how the client draws into the client or how the window manager composites are their own business. Most will render with OpenGL ES and will expect a driver capable of doing this. That goes too for however XWayland work which is going to assume a functioning driver.
So if there is an issue with a driver, e.g. NVidia then the issue is with the driver. And yes you can point the finger at NVidia if things function well with in other drivers whether they are hardware or software based.
Well, I'm going to argue against form here.
Most applications do not deal with X directly now (and they really haven't from the early days of Widget sets). They use various toolkits and graphics libraries that isolate them from the underlying rendering infrastructure.
Provided that you can do a complete re-implementation of the toolkits to use Wayland, in theory you don't need to change the applications. Just re-link the application objects with the new toolkits, and off you go. You may even be able to do this with dynamic linking at run-time, rather than compile time.
I know this is an idealistic argument, and that some applications may still need to be a little knowledgeable about the way that X works, but for most desktop type applications, there is probably not the case, and other, more graphics intensive operations use a variant of GL to render complex objects anyway.
I'm not arguing for Wayland here, just pointing out that it is possible.
-> Provided that you can do a complete re-implementation of the toolkits to use Wayland
Exactly my point above! Rewrite everything to be Wayland friendly just to get to where we already are. My X programs already work.
Wayland, if *they* had thought it through properly, would have been a complete drop in replacement for X with stubs for all the bits they don't want or need. Instead they have gone down the Gnome route of breaking everything, then expect everyone to follow their lead. We have seen how that worked out with some distros stubbornly sticking to older (and some say better) versions of Gnome.
I don't doubt the sincerity of the people doing Wayland, but I feel they are misguided.
> It is X that runs on Wayland. You don't even have to recompile your code.
So why not just use X then? I thought the idea was to get rid of stuff no longer being used, but if XWayland is X on wayland then it must essentially be the same as vanilla X no?
Or is XWayland the tidy up of X that everyone probably really needed instead of Wayland itself?
Because X is arcane and filled with obsolete code and patched up with hack extensions to allow it to provide a passable desktop experience. Read the link I provided at the top, it explains it quite clearly.
XWayland is just the X running over Wayland for software that wants. i.e. you can run X11 apps if you want but the entirely desktop isn't crippled from also running it.
> Provided that you can do a complete re-implementation of the toolkits to use Wayland, in theory you don't need to change the applications. Just re-link the application objects with the new toolkits, and off you go. You may even be able to do this with dynamic linking at run-time, rather than compile time.
That would be acceptable for me.
Erm, what is this stupidity? The vast majority of code is already Wayland friendly because GTK and QT have Wayland backends and will automatically use it or X at startup depending on your environment. And for code that isn't Wayland friendly, use XWayland.
This should not be hard to understand especially since it has already happened.
"The issue isn't that X is unstable, it is that it is obsolete"
OBSOLETEt? By WHO'S OPINION? what else is obsolete, a fork and a knife? If you are concerned about unused legacy code/features, make them optional compile or loadable extensions then.
THIS! DOES! NOT! JUSTIFY! WAYLAND! JUST! TAKING! OVER! (follow the money on who is pushing this)
*I* *HATE* *WAYLAND* the way *I* *HATE* *SYSTEMD* (and 2D FLATTY, etc.). XWayland or not, *IT* *SUCKS*
*WITHOUT* "DISPLAY" environment variable support for X SERVERS ALCOSS A NETWORK, *EMBEDDED* *DEVELOPMENT* *WITH* *LINUX* *WILL* *BE* *IMPOSSIBLE*.
And *EVERY* Linux release that runs on an embedded device had BETTER NOT DEFAULT TO WAYLAND. People like ME have INFLUENCE, and already ONE board did NOT get picked for future development BECAUSE IT SHIPPED WITH UBUNTU/WAYLAND as its "supported" OS !!!
People who do embedded understand this. X11 is a "known" and spending HOURS of company development time adapting to a MOVING TARGET (Wayland) is *NOT* *WORTH* *IT* !!!
But forking X.org WOULD be worth it... which is WHY it is STILL BEING USED.
Obsolete in the opinion of the people who wrote and maintained X. Hence the reason that X is moribund and going nowhere because nobody is working on it and all the desktop dists are moving to Wayland. But fret not, since if you want X, you can just run XWayland. X is no longer the critical path but it's there.
Did you get that? X is still there, it just doesn't hamstring the entire desktop's performance for the handful of apps that still need it.
As for embedded, your reasoning is all over the shop. It is likely that the embedded board used Wayland since it resulted in better performance for the device - less context switching, closer to metal rendering. The whole purpose of Wayland existing. Not to mention the better input handling on devices with multi-touch displays and the like. And if you were desperately worried about rendering you wouldn't be using X or Wayland, you'd be using the direct rendering manager through QT embedded or similar. In fact I can't think of any sane reason to use X in an embedded device unless you had some old application that absolutely needed to run on it.
> Huge chunks of it aren't used and haven't been used for years - the drawing primitives, fonts, damage model etc.
OK, so, step 1: make a detailed itemised list.
> Yet it all has to be maintained or it isn't the same protocol any more.
Also fine. Step 2: get the existing X.12 discussion moving by listing all the stuff that can be removed to make X.12 smaller, simpler and cleaner than X.11.
Step 3: a way for a server and a client to agree to use X.11 or X.12.
> And to do things approaching modern desktop requirements it had to be patched up by extensions which have to jump through hoops to function and had their own limitations and complexity.
They do, it is true.
The key points are, though:
[1] This has been done, and it works and it works well.
[2] The exact same thing is also applicable more generally to Linux in general, and indeed to Unix in general.
[3] And that the same argument applies to any successor display server as well, AFAICS.
So I do not find any of them compelling, TBH.
1) It's not hard to find such discussions. Most of X is untouched by modern libraries like QT, GTK3/4. They basically use X for receiving input, cut & paste, and shoving pixmaps around for compositing & rendering. Everything else is obsolete. Hence the reason they have Wayland backends.
2) Or just use Wayland since the purpose of it was to be a stripped down API that facilitates what modern libraries need and does away with the rest. Maybe they should have just called it X12.
3) Client and server already agree to use X11 or Wayland. Compositors like Kwin fire up XWayland during startup so if your environment sets DISPLAY and your legacy X application just runs. The likes of QT or GTK have ways to set which backend to use when apps launch.
The problem with Wayland is it doesn't actually exist.
It is a specification, thats it. This may work but it leaves way to much of the low level stuff to the clients. Each program with a UI now has to handle everything that X once did, and they ca do it in their own way.
It reads like a back of the envelope agreement, so generic that it can be interpreted in all ways you can imagine.
I don't like that. I like substance, a standard that everything that talks to it will expect the same behavior. Instead we will have UI elements rendered by the client, in why which way it fancies, different from the rest, a complete mess. Like someone fitting smart bulbs in their home that all are set to different settings and each talk their own implementation of the protocol so one app can talk to all but they don't look the same when you tell them to be blue.
It's much better ti use a lampshade.
For technical reasons which are unlikely to ever go away, I want to be able to do GUI things without having any extra stuff in my process address space. The X protocol gives me that, and it sounds like Wayland has no intention of doing so. So, I'm glad things like XWayland exist and hopefully will continue to do so. My Linux is suffiently old that it still has the traditional X server, so I don't have any experience with Wayland.
And yes, I fully understand that using the X protocol makes high intensity graphical games unlikely to work. That's fine.
I'm not sure what you think Wayland makes your client do that it doesn't already do in X. Virtually every single modern application is rendering into a pixmap whether you're using X or Wayland. That is because the likes of GTK and QT are not using the 1980s drawing primitives in X, but instead use their own hardware accelerated rendering libraries like Cairo / QT Render. These render into a pixmap and the pixmap is what is presented to the compositor to draw on the screen.
When applications run locally therefore they're doing pretty much the same from a memory standpoint albeit with less context switching in Wayland. When X apps are running remotely they're also shoving pixmaps around. Wayland leaves it to the window manager to implement RDP or VNC instead of doing it as part of its own protocol.
About the only difference in Wayland is that the windows decorations (frame, buttons etc.) are rendered client side. In X, the client renders the contents of the window and the window manager renders the frame around it. From that point of view it's probably using even more memory since you have 2 surfaces - frame and frame content instead of a single surface containing both.
"Wayland leaves it to the window manager to implement RDP or VNC instead of doing it as part of its own protocol."
Are you saying that Wayland has relented and implemented a system wher by I can run a graphical client program on a remote system which has no GUI installed and have it display its window on my local graphical server? Or do you mean I have to run a full remote desktop in a window? If the former, then that's quite a turnaround. If the latter, then why would I want a full on GUI installed on a fast, remote machine just to be able to run a graphical program remotely and display it's output on my slower, local machine?
Relent?
Wayland has always treated networking as an orthogonal problem. The compositor can offer RDP or VNC or whatever as a remote solution and the major compositors already do. Or you could carry on using X.
e.g. the Weston compositor offers RDP and there is a real world example of it doing exactly what you want of launching apps.
Microsoft's WSLg launches Wayland and X11 apps direcly on a Windows desktop. How does it work? It's a containerized Weston & XWayland dist that runs as a local display server. If I type "nethack-x11" from Ubuntu bash it finds this server, which in turn launches mstsc in Windows and my app just pops up on the desktop. It's virtually seamless.
If Microsoft can do it I assume others can too, using RDP remotely too if they wish. This is orthogonal to Wayland however.
> Or you could carry on using X
Hang on a second, we are being told exactly the opposite!
> If Microsoft can do it I assume others can too, using RDP remotely too if they wish
Microsoft cant do what X does. RDP presents an image of a remote DESKTOP. RDP and VNC have no ability to allow a client to render its UI on a remote machine. If it did then I should be able to launch notepad on a machine that has no graphical capabilities (which we know is not possible in windows, well unless its a specific version but lets assume we dont have a gui) and have that UI presented to me on my desktop, as if it were running locally.
Operating Systems like Plan 9 take this even further but basically I should not need to know that my application is NOT running locally. RDP and VNC are old fashioned and popular methods from the days when users were forced to be aware that an app was running remote.
Unless RDP or VNC has the ability to render the remote apps UI, locally, with no remote desktop, menus or notifications from the remote machine then it is a major step backwards. Wayland seems to think that full screen, full desktop remote control is ok, well it is not. I HAVE a desktop already, use THAT. Remote programs should use my local desktop as their own, which is what X does. Should not have to see a remote desktop at all.
Wayland insisting on "remote desktop", god it makes me laugh, is like getting rid of the paradigm of having one directory tree when drives, remote and local are mounted into it, so that users and processes don't need to know or care where or on what system those files are on. Thats how it works NOW and if wayland were to be for the filesystem as what t is for the GUI we would be told that we will be mapping drives to drive letters. It is totally mad, we should move forward not back!
X may be old, but the replacement moves backwards in that regard.
I suggest you break out wireshark and see what modern apps are doing when they run remotely over X. Clue - they're not invoking X drawing primitives. Instead they're just pushing huge pixmaps around over the wire. It's even more inefficient than RDP which will push differential changes.
Of course maybe your entire world is running some 30 year old X code, in which case why do you care what a modern desktop chooses to do to get rid of X?
If you are rendering into pixmaps and transferring them to the server, X has been able to do partial updates of what has changed since, I don't know, X11R4 maybe or possibly R3, basically forever the way that computing has changed.
X was always optimized to to this so that it could cope with expose events, backing store, save-unders and opaque window moves. It was all thought out to cope with many client programs from different remote systems on a single display, over networks that could carry a fraction of the capacity that modern networks carry.
The client program could be told by the server to redraw just part of it's window, with the shape and size being informed to it by the window manager. The client could decide whether it could re-draw the part indicated, or whether it had to redraw the entire window. The X server kept track of which windows had been obscured, and would need to be redrawn.
The X primitives allowed for a clip window which could be set to the boundaries of the expose event, which would minimize the amount of redrawing effort needed (things outside the clip window would be culled from the operations that needed to be done without the client having to actually decide itself.
X comes from the days of 10MB/s networking, and was written, even with local client pixmap rendering, to be very frugal in network use.
I always get the impression that the people who claim that X is arcane, inefficient and outdated are all from the Windows generation where the client program controlled the whole presentation of a window as the norm, without them actually understanding what they were asking to be removed.
The font model comes to mind. The X font model was quite well thought out, and actually allowed the client program to be very frugal about it's use memory use for mainly text only operations. All it had to know was the metrics of the font, not the complete bitmaps or scalable model. The server sorted that out. But many client program writers disliked the fact that they were subservient to the X server for the available fonts, even though with the X11 font server support, and the later inclusion of spline based scalable fonts, an application could add and use custom fonts quite easily. But they never bothered learning how to use them, and instead resorted to rendering the whole window themselves, relegating X to just a pixmap transfer protocol.
If that's all you use it for, then pretty much any transfer method will work. But X was always much more than that!
there have been some extensive graphics performance improvements in X over the last 2 decades like glx (a proprietary open GL in the case of NVidia). There is NO need to not follow the same path of simply extending the capabilities of the X server while retaining backwards compatibility.
TigerVNC also has an X server but it does 100% software rendering because it has to. Same protocol, applications run just fine.
"For technical reasons which are unlikely to ever go away, I want to be able to do GUI things without having any extra stuff in my process address space. The X protocol gives me that, and it sounds like Wayland has no intention of doing so. "
This has been my concern ever since Wayland first breached my awareness threshold a decade or so ago and has been worrying me on and off ever since. The Wayland team don't seem to have any interest whatsoever in network aware resources. The client/server model is deprecated as far as they are concerned. It's like the want to remove a prime USP from *nix and got eh Windows desktop route where the only access to remote system is a shared full fat desktop.
I use Zoom on Wayland (Debian 11) and it can record sessions just fine, although the novelty of recording my weekely drunken virtual pub sessions wore off in the early stages of the first lockdown.
I haven't tried Teams, and based on my friend's experiences I really don't want to either.
>I use Zoom on Wayland (Debian 11) and it can record sessions just fine
I would expect Zoom to be able to record sessions just fine - its part of the app, so no privacy issues. The privacy issues arise when you want to do a Screencam recording of the entire desktop and thus all applications running.
So the privacy problems impact Teamviewer and other Remote Desktop style tools.
I think it means that you can't just plug in between the application and the display, as you easily can in X11 (reparenting just one window, or even the whole screen by inserting between the display manager and the root window), although this always was a bit of a security issue if done incorrectly.
This might make screen sharing a little more difficult, but any application will still be able to record a session in the application itself, that won't change.
"One of the central functions of X is that it works over a network connection, something that Wayland by design does not do"
This is THE deal-breaker for me. Beyond just using a local display, this is the core X11 function that I use. And I do it quite frequently (last weekend, I actually had VirtualBox running on a remote system using X to display it where I happened to be). It still work reasonably well, but some applications wanting to talk to the display via D-bus or one of the other in-system communication methods does not work (so why require it in the applcations?)
XWayland and the various types of VNC or RDP, whilst they do work, I find them obnoxious, jerky, prone to block, and as they are basically remote control applications for the console of the remote box are just a broken idea for multi-user systems.Not tried waypipe, but if it works like ssh tunnelling of X, it may work OK. IMHO, for everything I do, X11 works far better, and can cope with different display resolutions on server and client (whichever way you want to see this). I also work with non-intel legacy system, and for that X11 is still a must.
This really is a case of throwing the baby out with the bath water.
Back in the last century, I worked in an environment where we had powerful centralized servers with IBM X Stations on people's desks. It worked really well for the majority of what needed to be done, and passably well for most of the other tasks, with the exception of running Windows applications (which was not a huge issue at the time). It was easy to administer (just a handful of servers serving a community of 100+ workstations), and meant that people could pretty much work on any desk without having to move any hardware around.
I regard the move to desktop Windows workstations and now laptops as a really regressive move.
I use X2go quite frequently to connect to a remote machine and get the XFCE remote desktop. I find it works much better than VNC or RDP as it seems much more responsive even over ADSL as long as a port on the remote server is open for SSH you can connect and it without needing to open up any other ports.
Hopefully there will be still at least one DE sticking with X.org for a while yet so I can continue to use this feature
>"One of the central functions of X is that it works over a network connection, something that Wayland by design does not do"
This is THE deal-breaker for me.
Given when Wayland was being designed, access over a network was pretty normal - web browsers had been around for a decade or so, the absence of a sensible network connection solution does bring into doubt just what were the designers of Wayland thinking.
I ought to point out that using Web technologies to render graphical application is also one of the items on my hate list, alongside Wayland, Pulse Audio and dare I say it, Systemd.
It's come a long way from it's origin, but browsers were meant to handle largely static, mainly one-way communication. Extending that into an application display framework always seemed like an ugly fudge to me, and I think the bloat and inefficiency in our modern web browsers, which are now probably the biggest resource hog in any workstation just shows how poor a decision that was.
Just imagine if X had been kept modern, with proper access control, encryption and keeping the efficient graphics transport across the network, application rendering in web pages would not have been necessary. And I believe that we would all have been much better off.
It's come a long way from it's origin, but browsers were meant to handle largely static, mainly one-way communication. Extending that into an application display framework always seemed like an ugly fudge to me, and I think the bloat and inefficiency in our modern web browsers, which are now probably the biggest resource hog in any workstation just shows how poor a decision that was.
I wholeheartedly agree. Dynamic content in the form of CGI was far enough. This current fad of "web apps" is infuriating. They're not exactly "just run in the browser" anyway, as many require downloading additional crud/plugins to work.
Same. I've been using X for years and years (at least since DECwindows was a thing; maybe even earlier) and running X across the network was always *the* killer feature.
When I hear Wayland proponents tossing out words/phrases like "obsolete", "1980s", "30-year old" one cannot help but interpret their argument as "old == bad" which not a convincing argument at all[1]. If X needs improving, then improve it. Of course, nobody wants to do maintenance so we get something like Wayland.
[1] -- Unless you can't get parts for it any more.
I think you need to watch this in order to understand what the developers of Wayland were thinking.
I'm not going to watch it again, because it really sums up the attitude of the developers, and every time I watch it, I feel my blood pressure start to rise.
The days of 4MB workstations, X10.4 ran quite happily on them but X11 needed 8MB of RAM installed.
Wouldn't the animated icons have been down to window manager you were using? X doesn't really have icons it is the window manager that tells the server to stop displaying the window and then creates a new little window as an icon for the original one.
Remember toys like the greyhound demo for X10?
"One of the central functions of X is that it works over a network connection, something that Wayland by design does not do"
I remember writing about that in an Acorn mag, back in the day.
The trouble with X is that if you, say a sysadmin, log in to your desktop on a remote server host, the X server is running on your client workstation. This creates the situation where a server process (the workstation) initiates a session with the client process (the remote server). This is a big security no-no, especially in secure environments.
Last I looked, the only windowing solution which ran the sever process on the server host was (feel the back of your neck start to prickle) Windows NT.
If you want your bright new thing to be leaped on and loved by the uber-geeks, just make sure it does that. But pur-leeeze do not include BSOD too, even as an easter egg!
Doesn't running X over SSH remove that problem?
Well, I say "remove" but I mean sidestep, since the X connection is running oblivious to the security being provided by the SSH connection underneath it, the latter having been set up in the traditional direction.
Well, you've got the client/server bit the right way around, but generally speaking, a client on the remote system opens a session to the server, not the other way around.
Of course, you may be thinking of starting applications from the window manager, but it is possible to run the window manager itself on the remote system (as is often the case if you are running an X-terminal or an X Station). It's even possible to run a remote window manager in a managed window inside your local X server (as a nested window manager).
X does not have a mechanism for the X server itself to open a new session. A client can (and the window manager is just a client, after all), and that other client has to have a mechanism outside of X to do some form of RPC if it runs on a different machine. The X11 protocol is just a transport, not an RPC mechanism.
When I was working in a purely X environment, it was normal for a menu item in the local window manager to run a command on a remote machine using SSH, or some kerborised RPC, and fire up a client session on the remote system back to the local X server. It's as secure as the RPC tool you use. I presume that in your scenario, the admin had a secure method of getting from their workstation to the remote server as well.
X Windows was written in a more trusting age. There were glaring security holes. Xauth and cookie support was added to get some degree of access security, but for years now, people have tended to use X11 sessions through SSH tunnels so the X protocol is encrypted across the network and SSH is performs the authentication.
But it would have been possible to extend cookie support to include better cryptographic authentication, and an encryption layer in the X protocol itself would have been pretty easy to add, but it wasn't, presumably because SSH tunnels seemed good enough.
After all, it fitted into the UNIX way quite well.
X Windows was written in a more trusting age.
This!
Back before the MIT magic cookies you could have great fun :-)
telnet or rlogin to someone's workstation, set your DISPLAY variable and run
xhost +
Now you can play with their screen, xshrink, xmelt, xscrawl xbounce etc...
I was writing X11 applications, window managers, libraries, and extensions in the late 1980s / early 1990s, and I didn't need a "wall" of documentation. There was book 0, the protocol (which was also the specification); book 1 for the libx11 API; and book 2 for the major widget sets, if memory serves. It wasn't something you'd slip into your hip pocket but it wasn't SNA, either.
1985 was also the year that Richard Stallman issued the GNU manifesto [Stallman] and launched the Free Software Foundation. Very few people took him or his GNU project seriously, a judgment that turned out to be seriously mistaken. In an unrelated development of the same year, the originators of the X window system released it as source code without royalties, restrictions, or license code. As a direct result of this decision, it became a safe neutral area for collaboration between Unix vendors, and defeated proprietary contenders to become Unix's graphics engine.
https://homepage.cs.uri.edu/~thenry/resources/unix_art/ch02s01.html
I'd like to see a document or written tutorial on how to migrate from using Xlib to using Wayland. Along with code examples that work.
It's dead easy to do a lot of simple things using Xlib that I've wasted way too much time trying to figure out how to do in a wayland environment.
Remote X is however the killer USP. ssh can be used for security if needed.
VNC/RDP has is it's place but I find neither satisfactory.
I tend to use nomachine but only with Windows and X servers. Not tried with a wayland session.
I use also use Nvidia graphics cards and I'm not changing. The reason is that I need the graphics debuggers. The debuggers for other gpu's just don't cut it. I've also bumped into too many issues with both AMD and Intel implementations of modern OpenGL, so I develop for Nvidia first then fix elsewhere.
I am however very impressed with Intels development of thier Mesa drivers. I wish Nvidia would move quicker to embrace a similar approach.
Wayland throws out the network aware client server model.
This will make it essentially DOA as it prefers a holdover from a bygone age of RDP and VNC. Yes Wayland developers/fans, your love of RDP and VNC is, well, too funny. You want to know what is obsolete, RDP and VNC and anything that works like they do.
The client/server model needs to be EXTENDED. Sure X needs cleaning up, so does OpenSSL, so clean it up already. A replacement should replace and extend the original, not move backwards to do what toy operating systems such as windows do, with sending compressed screenshots around the network.
Plan 9 has already shown us the way, no compressed screenshots there and a simple elegant fully network agnostic process space. My ENTIRE desktop of running apps may all be remote, running on multiple separate machines, yet appear to all be local to my smartphone. So Wayland, you have the chance to implement the 9P protocol and move beyond X. Take it. But you wont, you will just let it sit and rot as everyone uses RDP and you say "well someone else can implement 9P if they really want to". Do it yourselves. If you want to replace X, actually replace it.
So RDP and VNC? surely that must be a joke? Seriously, to use a remote application/program I must launch a RDP or VNC client, enter an IP address, enter a password, then use f*cking scrollbars to navigate around a live image of a remote desktop?
Anyone who thinks that is good has no idea of what it means to use an X client over the network.
Wayland thus seems to only exist because someone cant stand the headache of debugging X, so they in their limited scope decide to chuck it away totally ignoring the main feature set that they should be extending as we all know that what Plan 9 does is the future of computing.
True cloud computing, where local and remote resources, client UI's and even processes and HARDWARE will appear all together locally in your hand or on your desk. Sure, some things will NEED to be actually local, like the flash drive you just plugged in, or the printer in the house, but your applications may not even be running on your machine, or may only be in part. Wayland with RDP totally breaks that, yet X, the old bloated beast that we know it is, does it just fine.
Just think about it. Why have a powerful GPU when you can use a remote GPU? System builders like me will love a nice GPU sure, but why cant we let a mobile phone on a train use the computing power of a remote GPU, as if it is local? No, use your laof, I dont mean that we UPLOAD a job to a remote SERVICE, then download the result, the remote GPU will be LOCAL and exist in /dev so we open it like any really local GPU.
So tell me Wayland, if you cant (dont want to) do the simple act of letting a remote program render its UI locally to me, without sending screenshots of a desktop to me, how do you think your project is relevant going forward considering what we will eb able to do with what I described above?
We don't really use the network features of X enough yet. But we will. Windows etc will have to migrate to this new paradigm to remain relevant, it will happen on mobiles and tablets first most likely. Linux, with X will just need a little shove to get going, heck Linux will be used to develop it for the mobiles anyway so the shove will probably be a tickbox on the distro installer. But with Wayland, yeah, wont happen, not without someone coming along and re-implementing a network aware GUI protocol. If we are lucky, Wayland will take it from Plan 9. If we are not, some windows gamer kid will write something that looks cool and windowsy.
I like the way you think on this.
We don't really use the network features of X enough yet. But we will
I came up with a 'clever' way of creating panel icon shortcuts for Firefox runnin as a specific user with a button click that leverages 'DISPLAY' to run it as a user like, say, 'twitter', which would have no privileges, and its own context (FF may delete all history on exit, or simply allow script and tracking in THAT context). Then you are just aware of the tracking etc. in THAT context if you look at stuff, follow links, etc.. But OTHER contexts could have script blockers, cookie blockers, anti-tracking, whatever. So I end up having one for 'slack' that is work related, one for 'twitter', one for 'script' (let script run, but erases all history on exit), and all of those users have no privs whatsoever. Then you cleverly set up ssh with a cert-based login [no password prompt] and invoke the firefox program with appropriate info and DISPLAY exported, and you're there with a single button click.
(I use the 'script' one to view youtube vids or use one-time web sites that need script to work. carefully of course. Stupid gummint ones are often 'scripty' too. works for those as well)
Also fun thing, different instances have different windows and the title bar says 'as slack' or whatever in it.
All of this is possible BECAUSE of X11's client/server network aware protocol.
I first saw it running on NCD Xterminals 1988. I was the 1st beta tester for the Xfree86 project (Tseng ET4000 card, good times, running on Dell's SVR4 release), and have a lot of memories of the futzing around required. Also at work on ICL DRS3000s and BW NCD Xterms.
I joined up just to comment on how wild it is not a single person here has anything but positive things to say about X server.
My first Linux experience was the first version of Ubuntu off a disk my uncle brought over when I was a kid. Ever since then I have never had a single good thing to say about X.
Its been an absolute garbage fire the entire time. Configuration options, tools, multi monitor, hot swapping displays, virtual displays, drivers, screen tearing, text rendering, stability, screen recording, full screen applications, rendering and display buffer issues, video playback I could go on.
I understand it has some cool features, but it is death by 1000 paper cuts for using the desktop like a regular person, and no one is working on fixing them.
But I can install fedora 36 on any computer I have and it just works, with gnome 42 and pipewire and Wayland. Fast too. 5 screens hotplugged for fun? No problem. Smooth video? Animations? All good.
No one is working on fixing X's many many problems and I can't wait until its not even on my system for compatibility.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
