Slashdot Mirror
Wayland 1.0 Released, Not Yet Ready To Replace X11
An anonymous reader writes "After being talked about for four years, Wayland 1.0 was released today. The Wayland 1.0 release doesn't mark it yet as being ready for Linux desktop usage but just being API/protocol stable for future expansion. Wayland will now maintain backwards compatibility going forward, but how much longer will it take to replace X11 on the Linux desktop? Quite a while seems likely."
I guess all of the X11 developers that are the ones developing Wayland don't understand X11 that well. You should send them a link to the classes you're teaching.
x.org is not a replacement for X11. x.org is X11.
It's an implementation of an X11 server.
x.org split off from XFree86 over licensing arguments, if I recall properly.
Try never. Yes, I know that it should be possible to write a Wayland client that provides X11 server capability, but in that case, it is the Wayland client that is replacing X11, not Wayland.
Seriously, though, the Wayland effort appears to be throwing out every advantage the X11 display had over the Windows display for a replacement that will probably never be quite as good as a Windows. I just hope that developers of programs which currently support X11 continue to support X11, or my life will get much more difficult. In fact, for much of what I do, without X11 support (and only Wayland display supported), I would probably be better off with a Windows desktop instead of a Linux desktop.
The real "Libtards" are the Libertarians!
Yep, the issue with constantly pushing forwards and looking for the next new thing means that you can periodically make a bad choice. Shuttleworth, while some of his descisions haven't been the best, has been instrumental in pushing the Linux desktop to where it is today. Linux has never enjoyed so many desktop users. That brings good and bad, but its still an overall positive.
The licensing thing was basically just the last straw in a long line of disagreements, especially the lack of innovation and communicating and coordinating with the rest of the community, like projects such as KDE and Gnome.
If you think x.org's development is glacial, it's nothing like what XFree86's BS was.
--
BMO
Unfortunately, developers are the second worst group for understanding what users need. The only part of X11 that people need is network transparent remote display, but that's the one part that the developers are absolutely hell bent on removing.
The important feature about X Windows was Network Transparency - You could run an application on one computer with its screen output and keyboard and mouse input on a different computer. Sure, there are other ways to do it - lots of ssh sessions, or web browsing (especially with AJAX etc.), or competing window systems like NeWS, or screen emulators like VNC and Windows Remote Desktop - but fundamentally it's a lot cleaner to have some kind of network-transparent window system than to have an application need to drive a "screen" on its own machine.
25 years later, do we still need this? Yes! Virtual machines are taking over the computer business, so you can't expect the application to be running on your desktop (even if it _is_ running in a VM on top of your desktop), screens are a wide range of different sizes and capabilities (laptops, tablets, big monitors, etc., which often don't resemble the machine the app is running on), web browsers are getting used in increasingly complex ways because Windows didn't have a convenient X interface, and there's more and more ugliness around, and more waste of resources trying to emulate things that X did adequately well.
There are lots of good reasons to replace X, but Network Transparency is still the core feature, even if you want the application to have more control over the screen and its associated hardware than we had back in the 1980s, or if you want to move processing functions to different points between the client and the server (e.g. NeWS and NeXT's Display Postscript did some things differently, and Plan 9 and its successors had their own opinions about how to implement everything), but if Wayland doesn't offer Network Transparency yet, it's not an adequate X replacement.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
x.org split off from XFree86 over licensing arguments, if I recall properly.
That was the breaking point but there was very much tension between XFree86's Core Team and the other developers over the development model. Both the developers and distros rapidly abandoned XFree86 so their first release under the new license was essentially already dead and buried. It was something of an eye opener to see how quickly you could go from being president for XFree86, used in pretty much every form of *nix systems to having an empty title while all the people and all the work continued over at x.org. It really goes to show that open source projects are at the mercy of the grassroots, if you act like a dick or an idiot your project will be forked and dead like if someone pulled the rug out from under you.
Live today, because you never know what tomorrow brings
Google invested a lot of money to get their Application client stacks to work very well with a sane OpenGL implementation, and OEM's shipping Android make sure that there are sane OpenGL implementations on Linux. The later cannot be said for any of the desktop players that have dropped the ball due to lack of interest for well over a decade.
Android proves that graphics on Linux can be quite successful functional, but it also proves at how little interest existing industry heavy weights have at supporting Linux in general. The question now looms, can AMD, Nvidia, Intel, and co continually give half hearted attempts at supporting Linux when their markets are now in more danger than they ever have before? Can they continually look a blind eye to one of the fastest growing consumer electronics segments in a long while? Time will tell, and the drivers (and standards bodies) will be the tell tale sign that they can truely embrase a world outside Windows PC's.
Bye!
I guess all of the X11 developers that are the ones developing Wayland don't understand X11 that well.
"Don't understand X11 that well", I don't know (though I'd doubt they don't understand X). As for whether X11 needs replacing; not here, no.
I do worry that they're ignoring the ideals of X, and focusing too much on cellphone/*pad interfaces, as opposed to the original X ideal (any device *should* be able to handle it, regardless of what your particular prejudices might be).
Does Fluxbox run on Wayland? If so, I'll try it.
"Tongue tied and twisted, just an Earth bound misfit
The deal is that the way of rendering that both X11 and windows GDI support is 20 years behind the times. Nobody renders like that. The only way to reuse such an API to render modern UIs (without using GPU functionality) is to generate bitmaps using various modern rendering libraries and toolkits (like Qt does!) and push those to the screen. Thus, for a modern application, X11 and GDI are bitblt and input with lots of other junk nobody cares about. Yeah, X servers were working fine on resource constrained Unix systems 20 years ago, but then the UIs back then consisted of relatively simple primitives that the X server could actually draw. These days the X server doesn't support the primitives the application designers need, because to do so would mean reimplementing, for example, a path based compositing renderer.
The legacy APIs are useless, they don't scale anymore. Back in times of X, any application that drew anything complex had to maintain its own scene graph of some sort and maintain its own space partitioning to choose what to redraw. This led to obscene duplication of effort, and various applications had their own glitches, shortcomings and inefficiencies because everyone was reimplementing what wasn't all that easy to implement correctly in the first place.
Given the graphics hardware available today, those legacy APIs of GDI and X vintage expose a model that is so far detached from how the hardware processes the geometry, that applications that merely use the API can't leverage the available graphics horsepower. IOW, if you code to X or GDI APIs, your application will perform poorly and there's no way for something on the implementation side of the API to fix it for you.
When designing an application of any sort, the graphics API needs to present primitives and abstractions that translate well into efficient uses of graphics hardware. I'm sure people who deal with accelerating modern frameworks like Qt will tell you all there's to know about how broken the legacy API is when faced with modern hardware.
A successful API design takes a mixture of software design and pedagogy.
...network abstraction layers to their GUIs, specifically to enable people to mirror and share their desktops efficiently.
The mundane, non-vertically integrated *nix world still doesn't have this ability after all these years. X11 can't mirror/share, its also laggy over broadband connections, VNC is primitive and slow, etc. The NoMachine people have claimed they can support screen sharing in NX, but I haven't seen a working example yet (and those features are in the proprietary version anyway); otherwise they did a good job of making X11 usably network transparent for use cases not contained within a single LAN (i.e. most situations).
Personally, I'm tired of seeing all the hand-waving about X11's network transparency. It doesn't help in the vast majority of instances where people want to share an app or screen during a teleconference. X11 is not advanced in this respect -- just sadly out of touch. It mainly addresses the rather outdated use case where you have a handful of engineer types who open a CLI and type an ssh command, possibly fiddle with the display variable, then type in the desired app as a command so they can run one expensive, customized app on a server in a specially cooled room 3 floors down.
I looked through the other replies to see if I could mod someone up, but unfortunately no one answered your question and most posts missed the point.
The difference has nothing to do with the kernel. The difference in in the graphics architecture and how the subsystem works with the hardware.
First, Android's graphic subsystem is probably closer to Wayland than X11. The reason X11 is slow (or rather seems slow) is because X11 is an asynchronous API. That means things like window resizing and widget redrawing are all done without any synchronization, at roughly the same time, but not in any particular order. This means that you often get stuttering and tearing. So oddly enough if you use a compositing manager on Linux (any modern desktop), moving windows around is very snappy. Resizing windows is much better than it used to be because the widget toolkits have gotten much better at things like event compression, and even using synchronization extensions to X11 to time redraws to coincide with refresh rates. Also the API involves a lot of round-trips to the server, so over the network it's extremely chatty and subject to latency.
As allude to, X11 is a client/server architecture, which is a very powerful concept, but also causes some problems in making things appear smooth and fast (the asynchronous issue I just mentioned). X11's most powerful feature, is network transparency. I can remote log into any number of machines, and run individual apps and interact with them all on my desktop. Sure vnc or rdp can do this sort of thing, but not at an app (really per window) basis. I run remote apps as if they were local. I use this feature every day. It's not perfect; doesn't connect my local drive to the remote app, and it doesn't do sound. And if you're not on a LAN, it's better to use FreeNX.
Android is pretty much just OpenGL compositing onto a frame buffer screen. This can be very fast and smooth, and Wayland will likely be as fast and smooth. But it lacks the remote network transparency of X11.
Never say never :)
I hear you, honestly, but do keep in mind that sometimes change can be a good thing too. If they do it right, and it works everywhere, and gives you everything you had before but more.. why hold back? Sure, stay with what works for you for now but don't write off your options forever-more just because they're not there yet. I remember a time when I wouldn't own any phone but a Nokia, and wouldn't use a laptop because they were too underpowered and the screens were terrible. I wouldn't use anything that wasn't x86 and 32bit due to compatibility and stability. I wouldn't use wifi when ethernet was available because it was way slower and unreliable. I wouldn't consider using the internet on a phone due to cost and performance. All that's changed now and I couldn't be happier that it has
The deal is that the way of rendering that both X11 and windows GDI support is 20 years behind the times.
So?
I hear this a lot. The thing is, the code might have been large and complex 25 years ago when X11 was new. The code hasn't grown. By modern standards it's small and simple. And if it's rarely used, then it will sit on disk un-paged and never getting in the way. Actually with the removal of many things which used to be but no longer are optimizations it's shrunk.
Rarely used code does not affect performance.
Nobody renders like that.
I'm going to keep using xterm thanks. And I'd appreciate if you didn't make false claims about me.
These days the X server doesn't support the primitives the application designers need, because to do so would mean reimplementing, for example, a path based compositing renderer.
Firstly, X11 does support basic compositing now, and has for a while. Secondly, what's with the claim about "reimplementing"? One could easily make a cairo-x11 extension. In fact there used to be a x11-DPS extension so it's clearly possible.
The legacy APIs are useless, they don't scale anymore.
[citation needed]
Anyway WHO CARES? Modern toolkits don't use the "legacy" APIs and old programs aren't big. So it's all happy and nice.
IOW, if you code to X or GDI APIs, your application will perform poorly and there's no way for something on the implementation side of the API to fix it for you.
Your claim is something like 20 years out of date. X11 has had a standardised interface to hardware accelerated OpenGL since before PCs even had 3D cards. Most people don't and didn't use it because even the "poorly performing" "legacy" APIs are entirely fine for almost all programs which sit there doing nothing until a key is pressed.
When designing an application of any sort, the graphics API needs to present primitives and abstractions that translate well into efficient uses of graphics hardware. I'm sure people who deal with accelerating modern frameworks like Qt will tell you all there's to know about how broken the legacy API is when faced with modern hardware.
Well, yes, but then again. they probably don't use "legacy" APIs, prefering to use things like XComposite, XFixes and so on and so forth.
Basically, the X11 prorocol is really well designed, upgradeable and does a lot of things very well. One part of it (the original drawing protocol) was basically due for a major upgrade. That partly happened with XComposite and off-screen rendering. It could (and probably should) be continued with a higher level (e.g. SVG) drawing protocol.
Other parts of the X11 protocol have aged very gracefully, and are still very good.
SJW n. One who posts facts.
Existing X11 apps?
Yes.
Pray tell, what would those be?
Well, all the good window managers for a start. One of the HUGE advantages of X11 is that any user can freely replace the window manager. The move to Wayland would involve client side decorations (nothing inhernet in wayland, but the collective insanity of the Wayland developers seems to be pushing this policy), which massively limit what the compositor could realistically do.
X11 allows GUIs as diverse as Unity and ratpoison. I sit in a happy medium with FVWM, and I like it very much. That I would lose with Wayland.
And I still use xterm (I prefer it to any of the more modern terminals), xfig (still has some must have features) and xv (seriously? this program wasn't new in 1994! why do all subsequent views suck compared to it). I also have the odd hacked up thing using raw X11 because I find it very simple to use.
(Oh yeah and network transparency.)
<rant>
At this point a whole bunch of people ususally come out of the woodwork and tell me how only 1% of users or whatever use that feature and most users don't care and blah blah blah.
Well guess what Linux is never going to "win" the desktop. It is forever going to be used by people like me who take the effort to seek out something different. It used to be hacker friendly, letting you do stuff because you could, not blocking it because only 1% would use it or some other bullshit reason.
Hobbling Linux in a misguided attempt to capture some "market" that it will never capture will only wreck it for the rest of us who actually like it for what it is aren't using it because we're too cheap to buy a Mac or Windows or whatever. I love it because I find I do weird 1% stuff all the time. If I want OSX I know where to get it, and I really, really don't want it.
This is also the reason behind why firefox and gnome seriously break if you try to use (for instance) NFS mounted home directories. Because only 1% of users want it and so it is no longer well supported (and gives really idiotic error messages).
SJW n. One who posts facts.
The two main complaints I see discussed here appear to derive from some fundamental misunderstandings about what Wayland is.
Wayland is a Protocol and an optional helper library to implementing that protocol. This protocol says nothing about net work transparency, in both the sense of enabling or prohibiting it. It also says nothing about client decorations. The key points here is not to make a decision for or against any particular technology or methodology and then be stuck with that decision for the next 20 years, like we are with X.
How or if, either of these work is all down to the compositor. The reference compositor 'Weston' does not do network transparency and leaves window decoration to the client or its toolkit. However none of the big desktops, i.e end users, will be using this compositor. For example KDE will continue to use Kwin as their wayland compositor, and KDE have already clearly said that Kwin will be decorating their windows and not the clients!
As to network transparency, all windows are drawn to their own back buffers, and where these buffers will be eventually displayed is also the choice of the compositor, and it might well just decided to send them over a network connection. e.g. like what VNC does.
I think if you base your opinion on what other people say, including me, then maybe you shouldn't comment? All of this is discussed first hand on the Wayland web site and/or mailing list.
Unfortunately since I've posted a bit late, I doubt many will read this...