Wayland 1.0 Released, Not Yet Ready To Replace X11 455
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."
When IPv6 is ready? (Score:2)
Re: (Score:2)
Every major OS shipping today supports IPv6 natively, the same with all new networking equipment these days. IPv6 already works. Wayland isn't quite there.
... and I thought E is going to replace X11 (Score:2)
M.any years ago they were talking about Enlightenment wanting to replace X11
While E has gone to E17(still beta), it's not replacing X11 yet.
I dunno much about the project that's the topic of TFA, so I won't know how successful it would be in replacing X11
Re: (Score:2)
Re: (Score:2)
You're not thinking of the Berlin Consortium or something are you? I think they changed their name to something catchier later, but it escapes me (<sarcasm>well that obviously worked</sarcasm>).
Enlightenment was always intended to be something on top of X11 as far as I can remember (could be wrong of course).
Version numbering (Score:3, Insightful)
what about xorg? (Score:4, Interesting)
What's different now is that a lot of infrastructure has moved from the X server into the kernel (memory management, command scheduling, mode setting) or libraries (cairo, pixman, freetype, fontconfig, pango etc) and there is very little left that has to happen in a central server process.
which bored me to tears, so I'm no longer interested, but for those who are....
Re:what about xorg? (Score:5, Informative)
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.
Re:what about xorg? (Score:5, Informative)
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
Re:what about xorg? (Score:5, Insightful)
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.
Re: (Score:3)
I remember in `99 I compiled XFree86 at home and it took 3 days to compile. Later when I first heard about X.org people were saying, they are modernizing the code. And sure enough, I tried it and it compiled in just a few hours.
Well, if we consider that the initial version of X.org came out in 2004 (5 years after your XFree86 adventure) and we take into account Moore's Law (and other advancements) I'd say 98% of the speed improvement you observed is due to the computer you were compiling it in.
Re: (Score:3)
I remember in `99 I compiled XFree86 at home and it took 3 days to compile. Later when I first heard about X.org people were saying, they are modernizing the code. And sure enough, I tried it and it compiled in just a few hours.
If I recall correctly one of the first orders of business for x.org was splitting it up into modules rather than one gigantic monolithic project. Compiling the whole stack was not significantly faster, so most likely you're comparing compiling the core server to compiling everything including the kitchen sink but it allowed developers to work more independently and spend less time waiting for compiles.
Re: (Score:3)
As I understand it, x.org replaced xfree86. Both are X11 implementation.
Re: (Score:3, Interesting)
[An X server has] a tremendous amount of functionality
X servers were working fine on resource-constrained Unix systems 20 years ago.
The idea that they're somehow too bloated compared to a modern UI subsystem is complete and utter bullshit.
It just makes me annoyed how everything becomes layer upon layer of yet more inefficient crap, yet we're supposed to worry about comparably simple "legacy protocols" possibly still having some features that could be gradually deprecated.
Re:what about xorg? (Score:5, Informative)
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.
Re:what about xorg? (Score:4, Insightful)
Remove the legacy libs and interface... Fix X11's network transparency, making it perform more like NX... Improve the insane xauth system... make sure GTK and QT still work on it... call it X12 and release it to the public.
Just because maintaining 90% of the legacy code is unnecessary, doesn't mean you need to throw it all away, including the other 10% that works well and 99% of the compatible applications use.
Re:what about xorg? (Score:4, Informative)
No, Wayland is throwing out ALL X11 compatibility, and removing network transparency, and all the programs that are designed to support it.
Fluxbox?
Re:what about xorg? (Score:5, Informative)
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.
Re: (Score:3, Interesting)
Increased performance? (Score:4, Interesting)
Imagine recreating xlib so it doesn't communicate with an X server but directly draws things on the local screen, maybe in a multithreaded fashion. In such a scenario, the ability to share a display between many programs would be lost or alternatively a badly behaviored program could disrupt the other's windows. What kind of increased performance would be obtained (if any) by replacing IPC, as used in X11 (and in wayland too?) for drawing and use in process fonctions instead?
How long? (Score:5, Interesting)
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.
Re:How long? (Score:5, Insightful)
Emphasis is mine. Other than network transparency, what advantages did X11 have that Wayland doesn't? What other advantages did X11 have period?
Losing network transparency will effect some people, but there are some solutions to that. I'd wager the majority of linux GUIs deployed in the world don't use that feature (between embedded stuff like TiVos, normal desktops, TVs running Linux, etc). But I can tell you from more than 10 years of following Linux development that no one seems to actually like X11. From what I've read the various GUI developers seem to love Wayland compared X and can't wait for it to take over. X seems to be a giant ball of mud that's always getting in peoples way, hampering performance, and a pain in the ass to configure. The fact that it handles hardware setup, drawing, input, network transparency, fonts, 3D, and so much more it's clearly not following the unix philosophy of small tools doing one job.
Every time Wayland comes up, people come out of the woodwork to declare it a failure because it won't run over a network, but that's the only real gripe I've seen. You say there are others, I'm curious to know what they are.
Re:How long? (Score:5, Insightful)
Network transparency is very useful for administering servers. It is very useful to run the various GUI programs that I run on various servers on our office network. Wayland supporters have suggested using VNC for that, but it misses the point, since that implies one VNC session per remote machine, which means multiple VNC sessions, each with its own window manager, issues with copying and pasting, etc..
The other key advantage that X11 has: if the application is mis-behaving the application's window can still be controlled by the window manager. Ever seen windows on a Windows desktop that cannot be minimized? Wayland is bringing that to Linux.
Re: (Score:2)
I think Windows fixed this in XP. I've seen programs that stop responding still be able to be minimized or force-closed with the X.
Re: (Score:3)
Only sort of mostly, but not always. (Score:3)
So just this morning I had to reboot my Win7 machine, because I had an RDP session that wouldn't die. Was it because I hibernated the machine to bring it in to the office, disconnecting the VPN in the process? I don't know, but the "Are you sure you really want to close the window, we'll save the session for you, is that ok?" dialog box wouldn't go away and wanted to be on top.
Win7 really is a lot better than XP, and XP was a lot better than 95/SE/ME were, but I still have to reboot it a couple of times a
Re: (Score:3, Informative)
Re: (Score:2)
the last 4 places I've worked only used RDP or ICA for displaying windows apps on Linux. VNC has only ever been a last resort protocol. X11's network transparency is the only way to get stripped down Linux installs for things like Oracle and their crappy dependance on a working X11 display (local or remote)
Re: (Score:3)
RDP on a Linux server? I don't think so.
As I pointed out, VNC is a solution to admin a single server, as soon as you have more than one, then you need multiple VNC sessions, which is ugly.
What I typically use is a single VNC session on one machine in the LAN, from which I run lots of X11 programs on various different systems (sending their displays to the VNC session). Then I can access
Re: (Score:3)
Really, perhaps you might try using a search engine. The xrdp and x11rdp combination provide an X11 server than spits out RDP and the necessary middleware. More than five years old...
No kidding (Score:3)
For all the crowing about network transparency, it is not the killer feature to most. In terms of network management MS's RDP easily wins out. Reason is that it works well and supports low bandwidth situations very well since it isn't just a pixel-based protocol. However for ease of use and cross platform goodness, nothing beats VNC. That's what our Linux guru uses, in the situations where a command line isn't enough, not remote X.
Frankly, given the difference between local interconnects and network speed,
Re: (Score:3)
Network transparency is very useful for administering servers
Which is fine if you want Linux to be purely a server OS. If you want Linux to have any success in other markets, then having a smooth graphical user experience is almost always more important than remote GUI admin capabilities.
What's wrong with retaining X11 for servers only, and switching to something more appropriate for other Linux installations?
Re:How long? (Score:4, Informative)
Network transparency is very useful for administering servers
You're in luck then because Wayland will provide exactly the sort of efficient remote display necessary for this and most other use cases. Here [youtube.com] is the man himself, Kristian Høgsberg, demonstrating a prototype of this. Watch and learn and try to make allowance for the fact that this stuff has probably never run beyond any anything other than Kristian's development machine.
Wayland supporters have suggested using VNC for that
The blind leading the blind. Wayland, by its nature, has precise information about what it composites. Kristian explains how this can will be used to make efficient, round-trip-free remote displays work.
Eventually Wayland will provide a better remote desktop experience than X. Please know of what you speak before you condemn it.
Re: (Score:3, Funny)
Every time Wayland comes up, people come out of the woodwork to declare it a failure because it won't run over a network, but that's the only real gripe I've seen. You say there are others, I'm curious to know what they are.
Every time the electric car comes up, people come out of the woodwork to declare it a failure because it won't go more than 100 miles without a long recharge, but that's the only real gripe I've seen. You say there are others, I'm curious to know what they are. Every time the web appliance comes up, people come out of the woodwork to declare it a failure because it won't do anything besides surf the web, but that's the only real gripe I've seen. You say there are others, I'm curious to know what they are.
Re: (Score:2)
Losing network transparency will effect some people, but there are some solutions to that.
Why do I need to find a solution for something that already works today? That's just stupid and a waste of everybody's time.
Re: (Score:2)
I wonder if you haven't cracked the code. I see Wayland as just one more thing to make Linux more like Windows. (Like that's even a goal that the Linux community should be aspiring to.)
Personally, I would rather have a root canal without anesthetic than administer UNIX/Linux systems using a Windows desktop. If it weren't for Cygwin ha
Re: (Score:2)
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.
A couple of things:
1.) Wayland isn't trying to be X.
- Every 'native' Wayland program will have to be specifically compiled for Wayland.
- Wayland has an in-development X11 server, where X.org uses Wayland as a frame buffer (instead of X.org providing its own). This is really more like Xquartz or any of the X11 implementations on Windows. Neither OS X nor Windows can run X11 apps natively, and neither will Wayland.
2.) Wayland's policy towards network transparency is best described in their FAQ: "that is outs
Might be faster than you think (Score:2)
When you consider how fast the switch to x.org from xfree86 took place in three Linux world, any clearly superior x-like implementation with fully compatible APIs and without unacceptable license encumbrances could be adopted in very short order. If the functionality requires every program and every library to be reworked, then it will probably never happen.
Not having ANY real Wayland knowledge, I can only hope it is not another change in Linux for change's sake.
Re: (Score:2, Informative)
Wayland is not compatible with X11. You can recompile a GTK program so it runs on Wayland, but existing X11 apps do not run on Wayland (they are working a crappy-ass Mac OS X like shim).
Re: (Score:3, Insightful)
Existing X11 apps? Pray tell, what would those be? Does anyone care about xeyes anymore? I mean, I'd have thought that everything of note uses a framework/library of some sort that abstracts X11 away? Sure you need to port the framework, but the applications won't even know anything changed...
Re:Might be faster than you think (Score:5, Insightful)
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).
Solution searching for a problem? (Score:3, Insightful)
So.. X11 needs to be replaced with something shiny because of...? Seems the response most often stated is the code base is a mess. Why not just clean that up instead? And has others have noted here, remote usage is still important and no, VNC is not the same thing.
Missunderstanding the issues (Score:5, Informative)
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...
Re:Hopefully another 25 years or more (Score:4, Insightful)
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.
Re:Hopefully another 25 years or more (Score:5, Insightful)
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.
Re: (Score:3)
We ran X on terminals far weaker than the average cell phone in the 90s.
Re: (Score:3, Insightful)
Actually it sort of does. Theres so much legacy garbage in the current X protocol that just wastes resources and makes it nearly impossible to maintain.
As I don't actively maintain X I have no stake in this, but if it helps to motivate new generations of developers to dive into thats great.
I can also note that I think the model Wayland is employing seems more sane, given what we've learned over the years of model and X driver development (DRI anyone?).
Re: (Score:2, Insightful)
I can also note that I think the model Wayland is employing seems more sane, given what we've learned over the years of model and X driver development
Well I can note that I think client-side decorations is so much bollocks.
Wayland seems to abdicate responsibility on a lot of stuff that really needs to work across the desktop consistently, and that X was solving commendably.
Re: (Score:2)
Theres so much legacy garbage in the current X protocol that just wastes resources and makes it nearly impossible to maintain.
I've heard much the same thing said about rxvt vs. xterm. I like xterm, and its devs have done brilliant stuff over the years keeping it relevant, fast, and working. rxvt does 99.999% of what xterm does, and does it well (except for corner cases).
Why do I feel like I'm stirring entrails?
Re: (Score:2, Insightful)
Not you again. Wayland is being built by X developers, and several other prominent X developers have said it is a good thing.
Would you say that you understand X11 A) better, or B) worse, than the people who actually write code for Xorg?
Re:Hopefully another 25 years or more (Score:5, Insightful)
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.
Re:Hopefully another 25 years or more (Score:4, Insightful)
Re:Hopefully another 25 years or more (Score:5, Insightful)
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
Re: (Score:3)
vnc is faster (Score:2)
Remote X is a pig once ping times increase due to the number of round trips required. VNC is far superior in that situation especially when it can be notified of changes efficiently.
Re: (Score:3)
Which is why we have nxproxy which optimizes those things away.
If we wanted to do something new to X11, the best thing would be to get the NX modifications rolled in as a supported capability so Remote X would just work with them.
Re: (Score:3)
Factor in the risk to get disconnected from the remote running application depending on the type of link that you have. With VNC, one can just reconnect to the VNC server.
A little details on X just for the ones who might still wonder:
Remote X:
Your Desktop runs the X server and you run client applications or even a window manager on remote machines. When the link goes down, remote applications have no longer a DISPLAY and usually crash.
VNC:
Your Desktop runs a VNC client to connect to a remote machine running
Re: (Score:3)
It's native to the windowing system on both the local and remote machine
I thought that modern linux toolkits (GTK and Qt) and windows managers (eg. kwin and metacity) render windows entirely offscreen and just tell X to draw the resulting pixmap. Remote X just sends that bitmap over the network to the remote host. There seem to be little efficiency to be gained by using remote X over VNC in this case
there is absolutely nothing I need to do to either system to pop up a remote display other than insert a 'DISPLAY=remote-host:0.0' in front of the command line.
You need to have a command line to start with. If you're starting from nothing, opening a VNC session is not really harder than opening an SSH session.
All losing the point via narrow focus (Score:4, Insightful)
VNC is one to one, but with X you can have a pile of windows open from a pile of hosts. It may not be important to many here but it's the entire reason why my workplace has linux on the desktop machines and why the MS windows machines all have X as well.
The funny thing is despite all the "cloud" hype people are forgetting one of the major advantages of being able to use the resources of more than one computer via networking. VNC is the dumb terminal approach, which is fine for many tasks, but it has limitations.
Re: (Score:3)
For one thing, I get just the application window, not a whole extra desktop in a window. I can freely cut and paste between the remote application's UI and a local one.
Re: (Score:2)
Re: (Score:3, Interesting)
Or, we could just keep X. Much better.
Re: (Score:3)
Agreed ; it's slow, even over a LAN. It's fine as a stop-gap measure (like for VirtualBox, where the GUI VM configurator is is much easier to use than the command line), but it chugs.
For serious remote desktop usage on Linux, the only thing I've tried that's actually any good is NX, although that is the only thing I've tried. Microsoft's RDP protocol is excellent. NX is the only thing that comes close to it.
I suppose I might be making some mistake with how I've got it set up, but I've never seen application
Re: (Score:3)
Re: (Score:2)
no question. I use the code, they make it. car analogy: who understands a car better (what it should do and how): the engineer or the driver?
Application and Screen on Different Machines (Score:5, Interesting)
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.
Re:Application and Screen on Different Machines (Score:4, Insightful)
Nobody ever uses network transparency. Well, okay, perhaps a few thousand people do, but rounded to the nearest 1% of the total number of Windows or Mac users, _zero_ people use it. Network transparency should be a layer on top of the window system for those who need it, not something that's present and causing breakage by default.
Re:Application and Screen on Different Machines (Score:5, Interesting)
Speak for yourself. I was just using the 'network transparency' features of X the other day, as well as NAS (Network Audio System) and going 'thank god this made it so easy!'
Literally all you had to do was have the nasd daemon running on the client and fire up the app on the server. Same deal with X. I was able to spit out my app with full audio across the network. I wouldn't want to try Quake or something over it, but I'm sure that given some work on X11 and 10G ethernet I could probably do that as well.
Honestly my problems at the moment are less with Wayland and more with them constantly fucking things up on the X11 front with the incessant streams of changes and deprecated features. In order to run MESA now you have to have a c++ compiler, and can't use any hardware other than Intel, AMD, or Nvidia (via nouveau) since all have been deprecated due to the removal of DRI1. Additionally despite YEARS of opportunity, there's still no inline way to have apps change display resolutions, so for those of us with 8/16 bit games we can't just fire them up, we have to run them in a dedicated 8 or 16 bit color X server, which oh by the way the latter doesn't work on any supported 3d hardware (MAYBE MAYBE R100/R200, although bother of those drivers are somewhat unreliable nowadays), and oh by the way we broke 8 bit palette support, so the former is in greyscale even on color displays (I ran into this after upgrading X on one of my laptops with an IGP345 on it. Horribly slow at 16/32 bit color, but with lots of 8 bit apps that'll run smooth).
It's not wayland that's FUBAR, it's how they've been handling X for the past however many years that is. They keep talking about 'improving' on X, but they can't even keep X displaying the same features it had 10 years ago due to inadequate testing, so what do you expect them to do in another 5 years when wayland is really 'mature'? Break more shit because it didn't matter to them and tack on new crap you don't care about.
That's just my 2c as an X user since the late 90s, having followed Utah-GLX, the starting of Mesa, The XF86/Xorg schism, and all the BS since.
Re:Application and Screen on Different Machines (Score:5, Interesting)
It goes the other way: unless you design for network transparency from day one, you're not going to get it and have it perform well. There's no way to decently get network transparency as a layer on top of the window system. VNC and RDP are horrible kludges and perform like crap.
Re: (Score:2)
It goes the other way: unless you design for network transparency from day one, you're not going to get it and have it perform well. There's no way to decently get network transparency as a layer on top of the window system. VNC and RDP are horrible kludges and perform like crap.
Maybe with all the fancy animations and shadows and transparency and 3D effects it just *isn't* going to work well? I can't be arsed to look up the bandwidth or latency of the 16x PCIe connection to my graphics card but I'm pretty sure it's off the charts compared to my fairly speed fiber Internet connection. Seems to me that either HTML if you want a "generic" client or a thick client that only sends and retrieves the data you need beats trying to push pixels around. Yes it's convenient in that all your ap
Re: (Score:2)
All those things nominally take comparatively little data to represent before they hit the rendering pipeline. Alas, with X11, VNC and RDP as they now stand, you push bitmaps around, and that sucks bandwidth like nobody's business. Wayland doesn't do enough. To be efficient at network transparency, all of the displaying needs to be done from a scene graph, and the application is then modifying the scene graph on whatever display it's being shown on. That's taking what made X11 well performing back in the da
Re:Application and Screen on Different Machines (Score:4, Informative)
X11 doesn't "push push bitmaps around" unless you direct it to do so.
And it pretty much always does so nowadays given that's how most modern window managers and toolkits interact with X (all rendering is done offscreen and X is simply asked to draw the resulting pixmap)
Re: (Score:3)
I can't for the life of me imagine that it's actually efficient to have a bunch of fancy animations and shadows and transparency and 3D effects, or why people who care about network transparency would be impressed by those sorts of doodads.
Re:Application and Screen on Different Machines (Score:4, Insightful)
VNC and RDP are horrible kludges and perform like crap.
I get the feeling youve never used RDP.
And if X11 is so great for network transparency, why does Citrix base all of its terminal stuff on ICA (which RDP is based off IIRC) rather than just using X11's native abilities?
Re: (Score:2)
Re: (Score:2)
a small percentage of people in the US ever use 911...so get rid of it?
and for all those who say X11 is crufty and has lots of bad code in it: YES! but, don't mix/confuse the implementation with the feature. It's the feature that is important, the X11 implementation needs some work, but it functions fine now AND NO OTHER REPLACEMENT WINDOW SYSTEM IS OFFERING IT!
Re:Application and Screen on Different Machines (Score:4, Informative)
Wayland does exactly that and should be very good at network transparency.
Yes it sends images of the windows. This is a win because it is much much simpler than any scene description and it will not be obsolete 1 year from now. It does seem like it is more data, but for modern GUI that is in fact the most efficient way to represent the picture being drawn. You are aware that many modern apis draw MORE than one polygon per pixel?
Advantages over how X11 does images is that it avoids round trips and does not require perfect end result images, allowing compression. It also has the necessary calls to do incremental update (ie the client can say what part of the window has changed since last time, something missing from X11 images).
Re: (Score:3, Insightful)
And yet, Network Transparency is one of X's biggest weaknesses as well. The truth is, X's chief purpose in providing Network Transparency was in providing thin client/mainframe/whatever support over a LAN/WAN. This is incredibly transparent in a few ways: (1) there isn't a lot of heavy effort put into minimizing the data stream, (2) nearly any sort of network hiccup will kill a connection and hence the client--something almost assured on the internet for programs running long enough--, and (3) you can't
Re:Application and Screen on Different Machines (Score:5, Informative)
You have a good point, but unfortunately the X system is fundamentally flawed at the technical level for the purpose you describe. When X was originally developed, graphics were simple aliased lines and bitmapped fonts. In the modern computer environment, this has presented itself as a grave hindrance to the usability of X.
Modern applications depend on graphics toolkits, such as GTK and Qt, which render in to X pixbufs and finally those are rendered on the display. The process by which this happens depends upon copying these toolkit-rendered images from buffer to buffer several times, quite needlessly to fit within the X framework. This is moreso true over a network connection. The very nature of modern programs has progressed way beyond what X was intended and optimized for. It is like trying to use a MUD infrastructure designed for textual interaction as the basis of a modern GUI framework, it simply isn't the right tool for the job.
An anecdote, this weekend I decided I was going to work from home. So I ssh into my work computer (6 miles, 20+ Mbps connection), and fire up an X forwarded my graphical editor session. Things were slow, but not unusable until I did something that caused a series of tooltips to be rendered. The session locked up for 2 minutes before I killed it. I then fired up a terminal-based text editor and got to work. X's network transparency was not beneficial. But there are many network protocols that have been designed for the purpose of remotely operating modern GUI applications such as VNC and RDP. These have been designed from the ground up to provide the functionality we expect on today's systems.
And before I finish my tirade, I, too, was a die-hard X fan until I decided to see what the Xorg folks had to say. Keith Packard (a lead developer on Xorg, inventor of Cairo and much more that you depend on when you fire up your workstation), has been a hard proponent of Wayland. He's given many talks outlining the design failings of X and how Wayland resolves them. I recommend you google "Keith Packard Wayland" and see what you find.
Regards,
oursland
Re:Application and Screen on Different Machines (Score:4, Interesting)
Ok, so X11 sucks for local display, and it's not very good for remote display either.
I believe the plan going forward for local rendering with Wayland, is for the toolkit to render directly. I imagine that each toolkit might end up writing their own network transport for remote access, to give a better experience than just falling back to X11.
So what I think we need, is for the core team for each major toolkit to sit in a room and try to design an extensible network transport that they can all agree to use. With a core set of features, and perhaps some toolkit specific extensions. Perhaps ending up with a process similar to the way HTML has evolved over time.
Re:Application and Screen on Different Machines (Score:5, Informative)
Note that the X.org developers are not the original X11 developers, they are just the developers of a replacement implementation that copied the old *nix code using modern techniques. They did a good job and I appreciate their work, but they aren't the reason X11 was in use when they started X.org and it really says nothing about their understanding of why the X11 features are there, or what the needs of other developers are. They know about their own code, and they features they use in their own clients.
You mention the bandwidth of your connection, but it is actually the latency that you should be measuring when you're doing remote GUI stuff. Even running GIMP remotely in like... 2000, on a 53.3 modem, it was the latency that would make it suck rather than the bandwidth.
Re:Application and Screen on Different Machines (Score:5, Insightful)
Bandwidth is very much a concern as well. All the toolkits render locally to X pixbufs and transmit them across the line. In particularly graphics heavy systems, such as GIMP, these pixbufs won't compress as well, so line compression won't help as much to cut down on bandwidth concerns.
Re:Application and Screen on Different Machines (Score:4, Insightful)
Sometime around 2000-2002 Windows and OSX added (Score:5, Insightful)
...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.
Re: (Score:3)
Also because *nix in a lot of cases feels behind Windows in this. The Windows RDP implementation does a lot of things very right - it's quick enough to use over the web, it lets you take over the local console session (and lock out the local console but also restore it - seriously, try getting this to work on any Linux distro) and it can also support multiple remote users.
Linux distros can "kind of" do this, but no one's really made it work right yet, and as I understand it an "X screen" type function simpl
Network transparency is VERY important (Score:3)
I hope Wayland has some kind of network transparency support. It doesn't have to be X protocol, it could be something new and improved, but there must be a network transparency support.
--Coder
Re: (Score:2)
Well, it certainly doesn't need replacing with another X server. What it needs replacing with is something a little less complex and wonderful.
Re:Hopefully another 25 years or more (Score:4, Insightful)
It doesn't stop X11 from running as a client over Wayland for those who need a remote app and working in practically the same way as it does now. But it does mean the vast majority of people do not need to run it and do not incur the performance penalties from doing so.
Re: (Score:2)
He already said years ago that he intends for Ubuntu to use it as soon as it is ready. I expect Ubuntu will likely be the first major distro to do so.
Re:Good enough for Ubuntu (Score:5, Interesting)
Re: (Score:3)
I, for one, am a nerd who appreciates what artists, managers, and, yes, even sales folks do to sell what I make.
Usually you get what you pay for. Sometimes you get less, sometimes you get more.
Re: (Score:3, Interesting)
Re: (Score:2)
I'm glad yours does, my Droid phone is miserable when it comes to graphics. Very slow, unresponsive, and freezes often. Never had that issue with any of my nVidia cards and Linux (Geforce 3 was the main one I did Linux gaming on (oh NWN), more recently 9800GT, GT460, and my other box a Quadro FX1800). ATi cards haven't done as nicely (especially integrated in laptops).
Re: (Score:2, Insightful)
I'm confused. When Vista came out with their Aero effects, it was a massive CPU and memory hog in addition to requiring GPU power. Compiz on the other hand ran on very basic hardware and did far more.
In Linux I have more control over font rendering and sub-pixel hinting.
In what way has Linux desktop graphics lagged at all? Mac OS X and Linux have led the way while Windows has followed poorly. And in case you haven't been paying attention, Windows 8 is coming out. It is 2012, and they still haven't figured o
Re: (Score:3)
Maybe my memory is faulty, but for all the faults Vista had "Aero CPU usage" is not one I recall-- since the ENTIRE POINT was that the desktop was graphics accelerated (hence, no cpu usage).
Re: (Score:3)
Vista was released 5 years ago. The very first release of Compiz had that problem, but Compiz was handling 3D desktops and openGL at the same time just fine 5 years ago.
Re:Why are graphics awesome on Android? (Score:5, Interesting)
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.
Re: (Score:3, Informative)
Re: (Score:2)
Because any X application that doesn't render using OpenGL can't really do much else than generate bitmaps and blit them to the screen if you're expecting any modern style of UI (vs. legacy polygons and arcs only). Since everyone and their grandma reinvents various layers of those bitmap-making functionality over an over, it all looks like crap and performs like crap. It's hard for developers to focus on making things look good when the platform they develop on (X + various libraries that sit on top of it)
Re:Why are graphics awesome on Android? (Score:5, Insightful)
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.