X11 Window System Turns 25 Years Old 285
An anonymous reader writes "The widely used X11 Window System has turned 25 years old today. Version 11 of the X Window System is likely to remain in use for many years to come for backwards compatibility with the many legacy applications, BSD/Solaris systems, and Enterprise Linux distributions. Meanwhile, Wayland is still working to unseat the X Server for the common Linux desktop."
X12? (Score:4, Interesting)
Potential protocol changes were noted in the documents of version 11, such as the ICCCM which notes that the FocusIn event should have a timestamp and a previous-focus field. Has anyone out there considered just taking X11, making changes known to be needed, and dropping the protocol support for what's rarely or not needed anymore?
ssh X11Forwarding even in Cygwin (Score:5, Interesting)
One thing I love about X has always been the ability to run gui apps remotely via ssh using your local X via X11 forwarding. For those who haven't tried (or haven't tried lately) it's even pretty easy to get a shell running within X in Cygwin and run remote gui 'nix applications under Windows...too cool.
Re:X12? (Score:2, Interesting)
and unfortunately, they're also dropping things that ARE needed.
Re:X12? (Score:5, Interesting)
The people working on Wayland have used X11. Indeed, in many cases they are *also* X.org developers. Hell, one of the people working on Wayland is Keith Packard[1], who's been working on X.org since longer than I've been using Unix. Indeed, he's been working on X11 since before many of us had even used a computer, indeed for anyone younger than 24 make that "since before you were born". Hence, to say the people who are working on Wayland do not understand X is just a ridiculous argument, and does not suggest the person making that argument has much credibility on the subject.
I'll be honest, I was a little sceptical when I read about some of the design decisions in Wayland. In particular, the decision to move some of the window management to the application (in general, that means the toolkit, like Qt, GTK+, etc) makes me wince a bit, because it will lead to the hung-window-syndrome we know and love from MS Windows. However, the people involved in Wayland know far far far more about the subject than I do (I have no experience of designing or implementing windowing systems), and I'm sure they know a lot more about balancing the various trade-offs for and against all these decisions than most of us.
As for the remote displays. I was initially concerned about that capability too. However, if you look into it, well there's nothing that stops X11 being used with Wayland - indeed X server to render to Wayland already exists. Generally, there's nothing to prevent whatever style of remote display protocol being implemented for Wayland, be that in applications directly or (more sensibly) in the toolkits.
1. Keith Packard on Wayland and X: https://lwn.net/Articles/491509/ [lwn.net]
Re:X12? (Score:2, Interesting)
indeed X server to render to Wayland already exists
In the same sense that an X server to render to Windows desktops exists, yes, but that does NOT make it a replacement for the functionality in X11 today.
Re:X12? (Score:3, Interesting)
Remote display protocols, like X11, VNC, etc., will still be able to render to Wayland displays.
And Wayland will not be able to display efficiently to any other machine. It will require some shitty pixel-scraping technology like VNC.
As the world becomes more networked, the Wayland fanboys are trying to copy Windows by throwing away X11's separation of display and execution.
Re:Better than usual from Phoronix (Score:4, Interesting)
b. I get up from my desk and grab my notebook/tablet/smartphone/etc. and I want to simply transfer the remotely displayed application to the other device.. *cannot be done*.
Note how I spotted this problem 10 years ago?
Actually, I was able to do this just fine, 10 odd years ago with iPaqs handheld and GPE, which was X based. I could bounce GPE applications from my iPaq to main computer, so that I could use my main keyboard and display with the application (much handier than the pen based input on the iPaq). There's nothing in X that stops this from being implemented. It's the clients (i.e. there toolkits) which have to learn to switch between servers. Alternatively, it can be done done with an X server proxy - at least architecturally. (I can't actually remember which way the GPE solution did it).
Re:X12? (Score:5, Interesting)
And Wayland will not be able to display efficiently to any other machine. It will require some shitty pixel-scraping technology like VNC.
No, that isn't true. Nothing prevents Wayland supporting toolkits from using whatever kind of display protocol they want, from low-level pixel grabs of windows, to using more abstract drawing commands that match the higher-level structure/behaviour of the application. Indeed, a toolkit could easily use X11 as that protocol, if it wished - and that's already possible with XWayland, I understand.
XOrg's X11 (Score:5, Interesting)
...is just a "reference implementation". It is NOT the be-all and end-all.
If someone were to produce a wholly new windowing system that had a compatibility layer for the standard X11 API, support for the X11 configuration files, and the option of sending X11 packets over a network, you would have something that was compliant with the reference implementation. It would be a superset, but the reference specification would be 100% implemented according to the standard, agreed?
Indeed, since the current reference implementation is highly modular, you could replace one module at a time with something that solved the problems inherent in X but which remained 100% backwards compatible.
Let us call this new implementation X12, since it's a stepwise upgrade, similar to (but less crippling than) the upgrade from X10 to X11.
What would I imagine this X12 to look like?
Well, X is still horrible for games, so sprites and shaders make sense. (Nothing stops environments like Gnome or KDE from implementing their own, but to make games viable, you've got to have one API that always works even if you have other APIs for each desktop environment.)
Also on games, but also for multimedia, sound would be good. The challenge is that you want a universal "front end" API where you can switch between engines (such as PulseAudio or Jack) without having to change the code. You'd simply get the characteristics you want. The reasoning there is that different sound systems do have different characteristics and you want a different set for different circumstances. But, again, manufacturers don't care about your freedom to choose, they care about being able to sell to the most people with the least variation in the codebase. No problem. If there's a single universal API that forwards what applies, translates those things that are translatable, and ignores the rest, then the manufacturers are happy and the freedom people are happy. Everyone is happy. That's good.
For scientific and engineering work, you get the best results by converting from vectors to pixels at the last possible moment. Metafont/metapost have a good way to describe shapes (though you'd want to "compile" these descriptions into bytecode for efficiency), and transformation matrices aren't complicated. It would take a bit of work to get the system to work efficiently in 4D, but it would make life a lot easier.
The legacy X11 protocols aren't very efficient OR secure. They're needed because there's so many X11 terminals out there, but X12 should only use X11 to talk to X11 systems. X12 to X12 should be designed from the start to be secure, compact and extensible. It should also be transport-independent. Why should X care if it using TCP, UDP, DCCP, SCTP or something yet to be developed? Or what version of the IP protocol is involved? (If it IS involved! What's wrong with X over Infiniband?) So long as both sides of the connection know what to use, and things that have to be reliable are kept reliable, it's just a port as far as 99% of the code is concerned. Only when it comes to building it in the first place will there be any difference and that can all be hidden in an abstraction library.
Re:You Must Be Kiddin (Score:5, Interesting)
The difference is, if you tried doing it with a 32-bit alpha-blended desktop, VNC would have to shovel raw bitmaps over the network when you moved that semi-translucent terminal window that's partially-obscuring kEdit. RDP would just say, "move window XXX to a new origin of (x,y)", and all the alpha-blending window-translucency magic (and dropshadows, and everything else) would be rendered locally.
RDP between two computers running Windows works decently well over slow network connections, even with large displays and 32-bit alpha-blended eye candy. The same can't be said for VNC.