The X Window System is still hanging on at 40 It is 40 years since Robert W Scheifler ushered in the era of the X Window System, a windowing system that continues to stick around despite many distributions looking for alternatives. Combination of a birthday cake and the Chloe BASIC startup screen BASICally still alive: Classic language celebrates 60 years with new code …
If I understand correctly, Wayland depends on evdev for input events. Recent Xorg installations do too, but I've never got it to work. I have to use the legacy keyboard and mouse drivers, and these do not exist for Wayland.
I think my problem is that I nuked udev when it got absorbed into the systemd codebase, and installed mdev (a busybox aspect) instead. It works fine for most things (like automounting USB drives) but something about the /dev/input/eventX devices it creates doesn't make Xorg happy.
Every month or so I have another poke around, but no progress on that front, although, since it's working fine, I can stick with Xorg the way it is. Maybe for the next 10 years, yes.
Xorg has an equal problem of also being completely broken, except it's both unmaintainable and even a rewrite wouldn't fix it.
I mean geeze, I don't think people complaining about Wayland have ever tried to do a multimonitor setup in Xorg. Wayland isn't perfect primarily because it's a desperate effort to get *something* working while Xorg ages more and more while it has less and less maintainers, especially because the codebase so is utterly horrendous (there's a literal "here be dragons" warning in the source code). It's already riddled with security holes the few remaining developers are desperately trying to patch.
Xorg is actually quite nice to work with.
Especially now that all of the user-mode driver stuff has been removed and it is all homogenous "modesetting" drivers now. Additionally, you will see that many of the wayland compositors available base their modesetting drivers off the Xorg one. And why wouldn't they? It is pretty darn mature and stable by now.
The first step is to recombine the Xorg codebase, that was a bad decision by the Gnome/freedesktop guys to split in the first place.
Then just call it X12 and the kids will think its modern again.
X11 has it's own problems. The client server nature means it has significant latency- Not good for games that requires split-second response time like competitive first person shooters (not that there are many of those on Linux, most are Windows-only and also blocked from Wine/Proton by way of kernel level anticheats). Also, there seem to be some issues with Vulkan/Mesa, some games I've been playing would corrupt the screen for several seconds when launching. They don't do that on Wayland.
That said, I'm stuck with it only because the OBS devs can't get the browser plug-in working with Wayland.
Personally, I'll take "works properly over a network" over "doesn't support pretending to shoot people in real time".
If I'm still using computers in ten years, there's an excellent chance X11 will be involved. I don't think X11 will have any trouble hitting its 50th.
"The client server nature means it has significant latency- Not good for games that requires split-second response time like competitive first person shooters (not that there are many of those on Linux, most are Windows-only and also blocked from Wine/Proton by way of kernel level anticheats)."
So, basically what you are saying is although X11 has some latency due to the client/server nature, it's not a problem other than for a very, very few masochists who want to play Windows games? Personally, I find the client/server network nature of X11 incredibly useful and use it daily, running CPU hungry stuff on the "big box" with the display on my daily driver laptop. Something Wayland doesn't yet do (and as far as I know will never do), relying instead on a "Linux" version of RDS, ie running a full fat desk top on the remote machine in a window on my laptop instead of just a simple headless server and only the remote program seamlessly opening in a window on my existing desktop.
We can attribute many bad design decisions to the Gnome/Freedesktop guys over the years. If something didn't work they way they wanted Gnome to work, they had no problem breaking it for everyone else."Oh, you mean there are other desktops, not just Gnome? - sucks to be you..." seems to have been the normal response. From trashing the Gimp Toolkit to destroying traditional menu entry categorization. Nothing seems to have been off-limits. And now those same guys want to give you Wayland and retire X? No thank you.
If I remember what I read last time I looked into the gripes of X11 and multi-monitor, the biggest problem is having different scaling (especially fractional scaling) on the different monitors. It works fine with multiple monitors of the same size and type, but I am here working on a laptop with 14 inch screen, with a 22 inch monitor beside it.
Both are 1080P screens, but I cannot alter the scaling on just one so that windows would appear the same physical size on both monitors. This doesn't really bother me, as I rarely have windows that span both screens, I actually use them much as I would two different computers sharing a keyboard and mouse (although switching between them is different) with windows constrained to one screen at a time. But other people do want to do that, and that is where multi-monitor setups break down a bit in Xorg.
But I have a similar setup next to it on my desk running Windows, and I don't know how to fix it there either!.
"But I have a similar setup next to it on my desk running Windows, and I don't know how to fix it there either!."
You won't because you can't. IMHO what you are asking for is impossible: the optical 'scaling' (rendering) of each display is dependent upon physical DPI, yet the window scaling setting for applications is across the entire OS (all displays share the same scaling). You are asking the OS to handle more than resolution, you are asking the OS to track different physical DPI properties across every monitor and allow individual optical scaling settings for every said monitor - that's a big ask for the rendering engine AFAIK.
Perhaps that's true. The last time I bothered with multiple monitors, circa 1991, X11 handled heterogeneous displays just fine for my purposes. Scaling was not so much of an issue then.
(I'm about to receive a second monitor for work purposes, probably in the next week or so. I'll give it a try, but there's a good chance I won't bother using it as a second monitor, just as the single monitor when the laptop's docked. If that.)
"Both are 1080P screens, but I cannot alter the scaling on just one so that windows would appear the same physical size on both monitors. This doesn't really bother me, as I rarely have windows that span both screens,"
That actually feels like a really strange scenario to me. If the screens are different physical sizes, I think most people would expect the "physical" change in size of a windows when dragging from large screen to smaller screen and vice versa, I've got three screen on may main desktop, one of which is physically smaller than the other pair and I can't remember the last time I even wanted, let alone needed to span a window across more than one screen.
... ever tried to do a multimonitor setup in Xorg.
Yes, many times.
As a matter of fact, I have been doing it for the last eight years or so with all the distributions I tried out.
Just last month I carried out a much belated upgrade from Devuan Beowulf (via Chimaera) to Daedalus and Xorg got it right from the start using Linux nouveau drivers.
Granted, my first 3x19" multimonitor setup using the same hardware I am using now (Sun U24+2x Nvidia Quadro FX580 w/proprietary drivers) took me a good while to get right.
A custom xorg.conf was needed but there was a lot of help on-line from the Linux community and I managed quite well.
But that happened only once.
From then on, I was able to use the very same xorg.conf file with all the distributions (*.deb / *.rpm based) I put my box through by just dropping the *.conf file in place.
Can't beat that.
With Nvidia (being the assholes they are) dropping Linux support for their mothballed cards, I stalled my upgrades past a reasonable time as I expected problems.
Push came to shove and I decided to go ahead, being pleasantly surprised to see Xorg come through with colours, all monitors in place and working properly.
From the start, with no xorg.conf file needed.
Is Xorg perfect?
No, it is not but it is being taken care of and improving steadily.
As a result, the perfectly working Nvidia cards I paid through my nose for are still in service years later and thanks to Xorg+nouveau they will probably be doing their job in ten years time.
Instead of going to the landfill, like the very expensive Matrox cards (also paid through the nose for) for which I had no drivers for when I set up my first Linux box.
No, no Wayland needed in my box.
Goes without saying that if any one of my cards go bad I will have to replace them, but be sure as hell they will not be from Nvidia.
.
Obviously, mileage will vary, and it sounds as if yours has been very different from mine (and many other commentards).
I've had dual-monitor systems for maybe fifteen years now. At first, I either couldn't get it to work or could only do so if they were identical. (Should note that I didn't try all that hard to figure out the configuration files.) Embarrassingly, it _did_ work on Windows ME (the last version I used before switching to Linux).
But after maybe a couple of years, across a variety of distros and configurations, including different-sized monitors and/or one monitor in portrait mode and one in landscape (my usual preference), it all Just Worked™, with nearly "grandma-friendly" levels of simplicity. I remain ignorant of xorg.conf, simply because nothing broke.
As I write this, though, it occurs to me that all my systems are at least a few years old (I salvage rather than buy new), and have one multi-head graphics card. I wonder if you were using modern hardware and/or multiple graphics cards?
> I wonder if you were using modern hardware and/or multiple graphics cards?
Can not speak for the person you actually addressed that question to, but I (reasonably) recently built a new PC, running Devuan and X11. It didn't need any help from me to find the single new, big (to me) monitor. Nor when I plugged in the two old ones as well (aside from the obvious "this is to the left of that"), nor did it need anything from me when I plugged in a second GPU a short while later (with its own monitor). It even coped fine when I took away the first GPU again to pass through into VMs.
I've loads of notes on what I did wrong fiddling manually with all of the above (hey, do I get better results with open or proprietary nVidia drivers? Oops, that was the wrong block of incomprehensible numbers to pass through the correct GPU) but the windows kept on appearing...[1]. Ok, maybe a reboot was needed when I really messed up.
[1] to my amazement, as I do remember all the fun that could be had decades before; somewhere I still have some very thick tomes of X11 manuals from Foyles 'cos who had drive space to keep that lot online?
The concept behind X has a very interesting, and, honestly, horrifying technical history.
The reason X is a client/server system is because the original concept behind it's design is that it would be part of an entire "distributed OS", with a computer running each part of an OS independently. No, not a distributed workload, literally each individual architectural component of the OS would be split between physical systems networked together. It's a design straight out of a schizophrenic operating system developer's dreams, and probably something I would have thought would be cool back when I was 16, when I was writing a game engine that put every entity in it's own child process so they could never crash the entire game, akin to how modern web browser tabs are implemented, which is probably the greatest programming sin I've ever committed (it also didn't work).
I don't think that Project Athena (the name of the over-arching project at MIT) was ever intended to produce a fully distributed OS. The design was always intended to provide a distributed client/server environment, where process could run wherever they were most suited, available to be access from your local workstation.
In almost every implementation, the environment was made up of UNIX (and latterly Linux) servers with workstations from multiple vendors.
In later incarnations, it embraced AFS from Carnegie Mellon's Andrew project, and practically invented Kerberos and some distributed name space tools (like hesiod).
But it was not a research project. It was always intended to be a practical solution to a real problem of widening the use of computers beyond maths, engineering and computing users. As such, once it worked, it became very widely used, and some components such as X Windows (and the aforementioned Kerberos) spread widely beyond it's initial remit because it was just so useful in bridging between different vendors systems, and even different operating systems.
It is this last point that seems to have been forgotten. Only HTTP seems to have the same sort of cross platform impact in more recent years.
As far as I recall it was for running a number of thin X terminal clients all connected to a single server which served each client's desktop environment and applications (although as it's X the clients are called X servers and the server is called an X client...). Maybe it could be used to do what you say, but that's how manufacturers made money out of X in the late 80s/early 90s.
And if you wanted to do that today you still can, use a terminal on the local PC which can do X11 forwarding then set up the DISPLAY environment variable and run e.g. xeyes on the remote server.
The web browser is a display server, rendering HTML into a useable image for the User. It is fed from multiple sources - which are, to it, requests from clients. It doesn't care that there is another, totally distinct, layer of client-server interactions going on, some of which (the "interesting ones" from the p.o.v. of the User) involve network traffic, and just who initiated which part of that traffic, is irrelevant.
Trying to nail down web browsing as just a single-layer client-server relationship, because that is how the User sees it, and then compare that to the literal, technically very well defined, X11 client-server relationship, is - not a useful thing to do.
The concept of client-server is quite basic, and X11 follows it rigidly. There is no need to try to muddy the water.
the same could be said of a web browser displaying a single page with content from (as is usually the case) several places
This is true (of the Doctor's statement about a 1-to-N relationship between servers and clients), but misleading. The client/server model is based on a single distinction: Servers accept unsolicited requests (for connectionless protocols) or connections (for connection-oriented ones) from clients. For TCP, that means clients do the active open; there are equivalents for other sorts of channels.
The key is that it is the client which initiates contact between the two. The 1-server-to-N-clients relationship is common in client/server applications,1 but by no means universal.
Even with WebSockets, the browser (user agent) is the client. Normal HTTP user agents do not listen for inbound connections.
1That is, common as counted among different types of client/server applications. Since web browsing is very popular, when counting among all client/server relationships that might exist at a given time among applications, or by traffic or other metrics, it may no longer be all that common.
"xeyes on the remote server"
I'm reminded of my BOFH days at a local university running Sun boxes with sparc thin clients in the student labs.
Security was non existent initially, so I would entertain myself during the night watching student reactions on the lab security monitors while running stuff like xeyes on the sparcs.
I can't remember if it was enough to set the display variable to have the same number as the tty of the client shown in who or you also had to set the magic cookie too, but either way it was incredibly easy to make things appear on other people's clients. Not so clever if the program had a file open dialog box because then the other person could see who was doing it or overwrite their files.
This post has been deleted by its author
Wayland is taking over, but in many cases only because it has an X11 emulation layer (actually, that's a bit harsh, it's actually it's own nearly full-blown X11 server with Wayland as the compositor/rendering engine)
Most applications available in the Linux repositories still talk X11 by default, so it's not really true that Wayland is replacing X11. X11 is still there on most systems, even if they are using Wayland. There are actually very few native Wayland applications, and what ones there are appear to have really unintuitive names (who call a terminal session client "Foot" for goodness sake?)
I think a lot of people using some of the mainstream distributions haven't even noticed the change. They're still using the same applications, and unless they actually take the effort to look, they don't notice the change. This is because of XWayland, indicating that X11 is alive and well and will still have a long future.
The people who notice the change most are those (like me) who use legacy UNIX systems for which Wayland will never be an option.
> There are actually very few native Wayland applications, ...
Wouldn't it be fair to say that there are (comparatively) few "pure" X11 applications* too? Most graphical applications use some GUI toolkit or other, so that the X11 interface is hidden. So I'd imagine Wayland will become more mainstream if and when the toolkit devs Wayland-ify their software (though given the fundamental differences between Wayland and X11 perhaps I'm being naive here).
For me, the killer feature of X11 has always been the ease of running apps across a network, possibly tunnelling via ssh. If Wayland had some efficient mechanism for doing that --- my (possibly miss-)understanding is that currently that's still handled via an X11 layer --- I'd reconsider it.
*I have written one myself, as it happens, which wasn't as horrific as some posters on here would have you believe (although the documentation is, um, "terse", to say the least).
If Wayland had some efficient mechanism for doing that (my understanding is that currently that's still handled via an X11 layer), I'd reconsider it.
Wayland does have such a thing built in, its called waypipe. Here is the RH instructions for running a remote wayland application and viewing it on a local wayland client.
For running X11 applications remotely with wayland, most wayland desktops automatically include XWayland, so traditional X11 forwarding just works as it would have with X.
Waypipe works, but it is regarded as a little inefficient. It works in a similar way to X11 forwarding using SSH, in that you run something on the same machine as the client that looks like a Wayland compositor, but is, in fact, a stub that wraps up the Wayland protocol calls and sends them across the network to another process located where the compositor is actually running, where it is sent to be executed. Same thing happens in reverse.
As far as the client is concerned, the compositor is running on the local system, and as far as the compositor is concerned, the client is running on the same system as the compositor.
This is like X11 proxying (as done by SSH but there used to be other proxies around), but is not really the same as the way X11 is natively network aware, not that anybody really does the X protocol directly across the network any more, because the protocol really does not have any network security built in beyond MIT-MAGIC-COOKIE-1.
> not that anybody really does the X protocol directly across the network any more...
Oh, I dunno. I tend to take the attitude that if you are snooping on the traffic across the wired LAN in my study and attic to poach the unencrypted X11 traffic that occasionally flies around, I have far worse problems to deal with.
Whilst what you say has some truth in it, in general, once an application is compiled with it's toolsets libraries, it will run displaying on pretty much any X Windows server (obviously, X11 over time has acquired more features, so there are some limits). This is especially true if you statically compile the client, including all the toolset library routines. They become pretty much native X applications.
You have to remember that most X11 toolkits are really just sets of library routines to compile your client against. The underlying protocol that the client talks to the server over is still X11. This breaks down a bit when you consider dynamic linking, in that the system running the client has to have those libraries available, but they need nothing on the server.
Writing 'pure' X Windows clients is not hugely difficult for a simple client, but is a very hair-shirt experience. Using toolkits, even the basic XTK that was shipped with X Windows so that it could be used, make almost all operations so much easier.
Interactions with the display manager is a slightly different matter, but that is not really an X Windows issue.
I do take your point, and I did say on a post to another Wayland article some time ago that many applications could be ported from X to Wayland by porting the various toolkits such that they talk Wayland at the backend rather than X, and then re-compilng (or just re-linking maybe) the original client programs against these new toolkit libraries.
There are, however, a number of stumbling blocks because of differences in the way that X Windows and Wayland do some things, particularly in font handling, cursor warping and event handling.
> I have written one [pure X11 app] myself, as it happens, which wasn't as horrific as some posters on here would have you believe (although the documentation is, um, "terse", to say the least).
Terse? It came in a honking great fat tome[1] for Xlib! Plus another tome each for the basic toolkit, the User's guide, the Admin guide - at least 8 books in the series (My First O'Reilly Books, before the Great Plague of Animal Covers).
If they'd been any less terse, more chatty and fun to read, one loose bookshelf and you'd never survive the avalanche!
[1] clearly fans of Laurie Taylor: "one of these days I'm going to write a book, and it'll be thick enough to stun an ox"
> Terse? It came in a honking great fat tome[1] for Xlib! Plus another tome each for the basic toolkit, the User's guide, the Admin guide - at least 8 books in the series (My First O'Reilly Books, before the Great Plague of Animal Covers).
Yes, but they're all terse :-/
Seriously, though, in my case it was a strictly need-to-know exercise, and something I'm unlikely to have to do again anytime soon. My basic reference was the X Toolkit Intrinsics — C Language Interface.
> Never underestimate the stickiness of legacy technology
X11 isn't a legacy technology because it has yet to have a viable successor. In the same way that C and HTTP are not legacy technologies.
Wayland is akin to accessing a direct DRM framebuffer. We have had similar since before the DOS days. X11 was created to do better than that. And it still does with a correct UI toolkit.
Granted, most consumers don't need a network aware display system. At worst, they can stream raw rasters using RDP-subset or VNC which is all Wayland offers. But there is more to the computing industry than i.e kids playing computer games.
RHEL 9, and its variants, are supported until March of 2021. This doesn't quite get us to the 50th anniversary.
I understand that RHEL 9 will quietly install Wayland on compatible hardware, but that didn't happen on my old box.
$ pps X
PID TTY STAT TIME COMMAND
2069 tty1 Sl+ 0:03 /usr/libexec/Xorg vt1 -displayfd 3 -auth /run/user/42/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -novtswitch -verbose 3
$ cat /etc/oracle-release /etc/redhat-release
Oracle Linux Server release 9.4
Red Hat Enterprise Linux release 9.4 (Plow)
$ dmesg | grep DMI:
[ 0.000000] DMI: Dell Inc. PowerEdge R710/00NH4P, BIOS 6.3.0 09/20/2012
> RHEL 9, and its variants, are supported until March of 2021
Apple supported XQuartz until 10.7 in 2011
Because some companies no longer target a technology. It still doesn't make it legacy. It simply makes those companies "non-standard".
OpenSSH (which powers much of the world) is what will govern the success of X11. You'll see :)
It needs constant repetition.
Utterly essential to administer IT in most Big Corp environments is a networked UI. For security reasons, the display client has to be in the user device and the display server in the backend box which is running the services. X.org does networks, but it's the wrong way round. Wayland is the right way round, but it doesn't like networks. So the age-old default, to SSH in, fire up bash and administer the box the old-fashioned way, is still very much in vogue.
ONE DAY A NEEVIL NU GRU WILL WRITE A DISPLAY SYSTEM WHICH DOES BOTH, AND THEN CHANGE SIDES AND OPEN SOURCE IT.
I mean, how hard can it be?
Maybe you ought to look at Plan 9. That has a radically different model of network computing.
But the orientation of X Windows is a matter of perspective. An X Windows Server is doing exactly what it's name suggests, offering display and I/O event services on your local machine to remote clients (so 'serving' these resources out). In X Windows, everything displaying windows is treated as a remote client, including the Window Manager, even if it is on the same system (although the transport mechanism may be a little different). Recognising that this is the case makes the orientation more understandable.
You can have an environment where every client, including the Window Manager is remote, so all your local system has to do is run the X Server. This is what the most simple of X-Terminals were, just devices with a keyboard, graphical screen and mouse attached, with little to no local processing available. Thus you can keep all the important processes running in your secure enclave. This works, although the X Windows protocol is not really secure enough for this in the modern world. It would have been good to have something like SSL wrapped X11, but as far as I am aware, nobody wrote such a thing.
The fact that Wayland is not natively network aware means that there is really no comparison.
Peter Gathercole That is correct, and is precisely why X is unsuited to secure environments. It is inherently insecure for a client within a secure enclave to initiate a session with a server outside that enclave. Therefore the sysadmin outside it cannot have their X server connecting to an X client in the enclave. Period. Because privacy laws and commercial competition, Big Corps tend to have big secure environments. End of.
There's a fair amount of ways of doing X securely, usually tunneling over ssh is involved somewhere along the lines.
For example, run an X-server on your local machine, ssh into the remote machine, run whatever GUI app you want on the remote and display locally
Added benefit is that you can run compresion on the ssh channel.
Run a local X-server, use a VPN to connect into your work environment, run X-stuff on the box in the office, display on your local box.
> is precisely why X is unsuited to secure environments
Does anyone ever wonder if people who make this kind of statement are sitting at work, telling everyone how to secure their systems, that they must never allow anyone to use X11 in a secure environment? Then they post a couple of messages like that, doubling down, with so many disagreeing (and explaining why they disagree).
Come Monday, praying that nobody at work read the article & comments, or at least nobody knows what their nickname is, in case they ask awkward questions...
Although, the response would probably be "of course everyone disagreed, that just shows how much further my knowledge reaches than the unwashed commentards".
They know and nobody else does, of course.
I don't do this now but I'm pretty sure I've been tunneling X-Windows through xterm/ssh for years -- decades. Its routine. Its a handy way to run all sorts of things that would otherwise need rewriting because their protocols aren't secure.
Maybe its just me but I don't like a lot of modern code -- its bulky, buggy, inadequately tested and you're supposed to be continually updating it which, more often than not, breaks as many things as its supposed to be fixing. People have got used to this so they think its perfectly normal. Its not. Endless churn might provide jobs for many but its a total waste of productive effort.
When I said that the X protocol was not secure enough for a modern environment, I was of course referring to unwrapped X protocol, the way it used to be run in the '80s and '90s, when it was thought that LANs were secure, and any systems connected could not run in promiscuous mode without some form of privilege. This thinking changed when all the plain-text protocols (such as telnet, ftp, rsh/rlogin) were correctly deemed unsafe (basically when people stopped trusting the security of the physical medium).
As I stated in comments earlier in this comments chain, nobody really runs X Windows like that now, it is always tunnelled through something secure, but it's not SSL. I haven't been running unsecured X11 like this since I started using SSH, which is too long ago to mention (over 20 years). If you have a secure workstation, and a secure server enclave, as long as you have a way of using SSH with X11 tunnelling enabled, you can securely run X11, within the boundaries of SSH security (yes, I've seen the ways of hacking SSH with dtrace, but that requires privileged access on one end to attach to a process).
This is also the way that secure Waypipe works by default. But in theory, the simplicity of the X protocol allows pretty much any transport later to work. Come up with a secure transport mechanism for a byte stream, and you will almost certainly be able to run the X protocol over it.
I think that it is the very success and ubiquity of SSH tunnelled X11 that has prevented other transports being invented. Pretty much any UNIX/Linux system had both of these available from the time plain-text protocols were deprecated, so you did not need anything else. And Windows X server implementations followed suit when Putty was written and made freely available.
I would have loved to see an official protocol extension for the X protocol to enforce encryption and endpoint security, but as X is effectively in the public domain nowadays, there is not the resource rich controlling body to do this work. All the money has gone towards trying to replace X11 with a system that does less, but in a way that is more in keeping with modern design ethos.
《It would have been good to have something like SSL wrapped X11
Isn't that basically what you get with "ssh -X" ?》
Sort of I think.
I imagine X11 over TLS (X11s?) would have the X11 client (remote application) initiate a stream connection (tcp) with the TLS enabled X11 server's listening port which could be a dedicated TLS port $DISPLAY + 66000 (say) or negotiate STARTTLS style connection on the standard $DISPLAY + 6000 port. The X11 client system and X11 server host would present and verify each other's certificates. I suspect finer grained (per user etc) controls might be easier using kerberos rather than per user certificates.
Probably a lot of dragons lurking when trying to implement this securely which is probably why it never happened.
Stunnel + Xorg could probably mock up something similar. (Even socks does TLS if stunnel isn't up to it.)
Given ssh does X11 tunnels quite nicely there isn't any real incentive.
As I found during covid X11 doesn't like latency and Nomachine or VNC often work a lot better. I used both: Nomachine and x11vnc to maintain a disconnected session and vnc client over ssh.
It's very simple. If you are running a database system you have one server and many clients. In the same way you run a UI system you have one server, multiple clients. Your mistake is to assume that what's immediately in front of you must be a client. It isn't. It provides a service. It's a server irrespective of whether the clients are local or remote.
It's been a long time since I looked at Wayland, so these things may have been fixed, but one of my big problems with it was that it didn't have a separate window manager - clients were expected to provide their own titlebars etc - so there was no way to enforce a consistent interface to control window position, size etc. on every window no matter which application it was running or whether it was local or remote. It also apparently meant that if an application hung there was no way to drag it out of the way so you could get access to another window from which you could kill the misbehaving application.
> The Mir protocol was better,
Also alive and well.
https://www.theregister.com/2022/11/29/new_versions_of_ubuntu_touch/
https://www.theregister.com/2023/07/28/mir_canonicals_wayland_compositor/
Now in Debian and soon in Fedora.
https://packages.fedoraproject.org/pkgs/miracle-wm/miracle-wm/
I think Canonical has learned some humility.
"Never underestimate the stickiness of legacy technology"
40 years old, and yet it's still in active use. Logged into a production system today using a software X server, just like I do every day. Production staff is using hardware X terminals in the field. The machines we're connected to are 20+ years old and still going, making product worth $millions/day.
Try that with modern hardware/software.
Not so much "choice" as "that is what you get unless you try damn hard not to"[1] when installing the R'Pi OS.
[1] for most R'Pi users, switching away from the defaults isn't as easy as it is for anybody reading this comment on The Register, so any and all replies of "no, it is easy peasy to change, just do X". Even taking the plunge and selecting anything other than the default on the Raspberry Pi Imager means (the perception of) disconnecting themselves from the majority of the support available for the device - and risking doing that is damn hard!
Yes I do understand the issues with X11 - but it is a tried and tested standard and it does work.
I know that XWayland (along with WayPipes etc) should go a long way to addressing the perceived shortcomings (though WayLand will still only work on Linux ) but it XWayland still seems broken (and a bit unloved), which leaves me feeling very underwhelmed. As an example setting the minimum and maximum window size to be the same dimensions using 'XSetWMNormalHints' should result in a window that the user cannot resize, and this has worked on every X11 implementation I've come across except XWayland which I noticed was broken five years ago and still seemed broken when I last tried it earlier this year.
I suspect that people will still be using X11 for a little while yet, and hopefully it can be shown some of the love it deserves...
"There is still someone clinging to X11 for that one old app that won't run properly on anything else." And that old app might just be xterm! Try and find a terminal emulator that's stable and secure, without feature creep like networking and a ssh client built in? Oh, and since there are a lot of user preference settings that impact usability, it would be nice to have just one app that works on Darwin, Linux, and BSD. Okay, so there is just one app...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
