For applications that were written with X11 in mind it works much much better than that.
One example was the controlling a telescope.
The computers in the control room were thin clients pretty much and displayed various windows from various machines across the mountain - even across multiple different operating systems! Some machines were running Solaris and some linux.
The different machines belonged to different aspects of the telescope: some controlled the telescope itself and some machines belonged to the different scientifc instruments on the telescope.
And it all worked quite well with no real noticeable lag.
> For SSH forwarding you could have SSH ask the X server for a new socket for forwarding purposes - so remote clients can't snoop on local clients.
SSH pretty much already does this. Per default (using -X) X11 forwarding is in untrusted mode, which makes certain unsafe X11 extensions unavailable.
So remote clients already cannot snoop the whole keyboard input.
IPv6 clients (or in theory any kind of IPv4 successor) can reach IPv4 servers via some kind of translation layer (for example NAT64) - so IPv6 is backwards-compatible with IPv4 in that direction.
The inverse direction (IPv4 client to IPv6 server) is however not possible, since IPv4 is not forward-compatible with any possible successor, because it is not possible to encode more information into 32-bit than 32-bit.
That has very little to do with the ICE train itself though, which can do above 320 km/h just fine in regular service (on international connections though, since in Germany the global train speed limit is 300 km/h I believe).
While the high-speed tracks in Germany are indeed quite a bit of a patch-work, there are over 1000 km of track certified for >= 250 km/h (as of 2015; quite a number of more lines got finished since then, but I could not find the updated number that included them) and by now really rather long corridors are very high-speed.
The route from Munich (south of Germany) to Berlin is now mostly covered with upgraded routes for example.
I think the 4 hours for that route are quite competitive to Shinkansen times.
The fastest Shinkansen route (from the listed operating speed the only one that actually operates at 320 km/h; all others only operate at 260-300 km/h) is the Tōhoku Shinkansen line, which takes 3 hours and 20 minutes for the same distance traveled.
The lack of dedicated tracks for high-speed passenger service matters a lot though. It’s part of the reason why those (very impressive) scheduled Munich-Berlin times are so often not achieved. The “slot” for the service is relatively small because slower trains (in particular freight) must be scheduled as well, so if the slot is missed for any reason, delays can compound very badly. I take the train between Munich and Berlin reasonably often and it’s usually running late, and sometimes by an hour or more.
Reliability is certainly one aspect where dedicated tracks helps a lot, but is not the only solution (see for example Switzerland).
For Germany the issue is the overall too large utilization of the network and the large backlog of required maintenance of the rail infrastructure (in my opinion).
If I read the datasheet correctly you still need an inductor and some passive components externally.
The only thing that is not needed is an external switch mode power supply chip.
The X11 primary selection buffer is an even better variant of that though.
It allows single-shot copy&paste (meaning only one application can grab it) from the password manager to the target application and it tells the password manager the name of the application that grabbed it.
I think it shouldn't be too hard to hack in a dialog to password managers to confirm if the destination is correct before replying to the data request.
But even without that one at least notices that a malicious/wrong application grabbed the password.
X11 does have various ways to restrict access (one of which ssh does use for instance) and some more advanced security extensions. But as far as I can tell there has never been that much motivation to widely deploy any of it.
It is only one old C codebase however (or a couple if one counts the *BSD semi-forks separately) instead of many different fresh c codebases (one per compositor with some shared code between some of them to be fair). I don't buy that this is actually better for security. It is a lot of more fun/less painful than cleaning up and improving some legacy codebase however.
There's nothing that forces a Wayland compositor to be written in C. I've seen ones written in C++, Zig, and Rust, but you could really use any language as long as you can still call the appropriate system/kernel APIs
Nothing preventing you from writing a X11 server in something else either (and people have done so!). But fact is, most wayland compositors right now are either pure C or C++ (and I think the rest uses at least wlroots?).
Many X11 window managers are written in non-c languages too and I don't think I am too far off the mark when I say that a decent fraction of wayland compositors would just be external window managers if there existed a standardized interface for window managers when they were written (I think some compositors have an interface for external window managers now, but is there a standard interface by now?).
Linux is not as secure as most tech people would assume at first glance. The monolithic kernel with all device drivers in ring0 is, let's just say, not the best approach if one were writing a new OS from scratch.
It is mostly "secure" due to it being used in practically every server and billions of devices, so there is an active maintainer community around it. Xorg has none of that.
Eh, wlroots is in C. Tons of the Wayland stuff is in C. There's a bunch of good reasons to prefer Wayland, but this is probably the worst reason I've seen yet.
That's perfectly possible with X11 to attach via VNC to an existing session.
But what X11 over (local) network does way better than either RDP or VNC is to run individual applications remotely while having them seamlessly integrate with the rest of desktop.
At the observatory for example we were running thin clients in the control room while all the control panel windows were coming from many different machines across the mountain and it felt like all the applications were running locally on the machine in the control room (while in reality nothing was running there).
Yes, of course it is possible to use VNC with X11 as we use RDP with Windows. But it is additional protocol. Why do we need it if "X11 is network transparent"?
It is different models: X11 assume you have only one terminal (effectively client, but "server" in X11 parlance) and many system to run software (effectively servers, but "client" in X11 parlance).
VNC/RDP works other way around: one server, which runs all you programs, and you can attach to it from different terminals/clients.
It is not exactly so, as RDP can forward only some programs (windows) and not full screen, of course, but close enough.
I cannot speak for everybody, but for me (and my friends with whom I discussed this) second use case is much more important, than first one.
About speed: maybe, with 10Mbit Ethernet it was true. But now I could work with Photoshop (!) from my office (client) on my home workstation (server) via RDP and don't notice delays. Yes, I have 1000/100Mbit asymmetric connection at home and I don't know what is used by my office. One time I've forgot that it is RDP to my home sysmtem and started Youtube video. I was surprised, that video and sound is slightly off-sync, and only after that recognized that it is RDP, not local browser!
Much worse connection is enough for less demanding tasks, I've worked with "normal" not graphics-heavy programs via 4G connection in India (my home system is in the Netherlands) and it was not painful. Yes, there was perceivable delay, but for task like "Open PDF, open browser, fill form on site by copy-n-pasting strings from PDF, submitting form and authorize with 2FA from phone" it was perfectly Ok.
But, yes, if you need to assemble 10 windows from 10 remote machines on one screen, X11 is the best.
That is a bloody lie. Nothing on X feels like it's running locally except for actually locally running applications. String an Ethernet cable across the room, and run X apps remotely over it, and you'll get lag and chug.
RDP actually delivers on the promise of local-feeling remote apps.
(The revenge of the UNIX-HATERS is that Microsoft designed a better shell than sh (PowerShell), a better X than X (RDP), and a better Emacs than Emacs (Visual Studio Code).)
Maybe the problem was with your specific setup or applications?
Because at the observatory it worked flawlessly.
Between the local data reduction machine (beefy server) and the desktop computer in my office the same.
And I used that setup for years and it worked just fine (and I really really hate any lag or glitches).
VNC really sucked on the other hand, not being able to transparently share single windows (at least I never figured out how to), some windows would fail to refresh and I would need to drag them around to get them to redraw, copy and paste was always a pain, sometimes inputs not registering properly.
To be fair to VNC though, over the internet plain X11 forwarding really sucked (latency is the real killer here) and VNC won out there.
Unless one was using NX proxy, then it blew VNC out of the water (while using X11 on both ends).
Only RDP was somewhat on par with NX over the internet, but locally still beaten by X11.
X11 with modern frameworks passes only damaged bitmaps too...
No local font rendering, not vector primitives.
And for me inability to detach whole session from one server (in X11 terms) and attach to another is showstopper.
X11 needed something like console "screen"/"tmux" from the very beginning, in the core protocol, IMHO. Not for multiplexing of workspaces or desktops, but for this session re-attaching.
That is not true. There are extensions to the X11 server that can resolve many of the security issues, but almost no one cares enough to use them.
If you are doing X11 forwarding via SSH it defaults to a more restricted configuration that only allows a more restricted access to the server (no direct sniffing of the input devices for instance).
