No, the standard body should do its job and produce good standards. Whether Microsoft implements it or not is not their problem. A good standard which Microsoft does not use is much better than a mess which nobody can implement correctly.
The additional cost for renewables for German consumers in 2014 is 6.24 ct/kWh (and parts of the industry is exempt) which is less than other taxes paid on electricity. While solar is still expensive (but went down a lot) wind is clearly one of the cheapest source of energy.
Participating scientists are not compensated for their efforts.
Depends on what you consider to be "compensation"...
They aren't all doing it for nothing, rest assured...
I am not sure what you are implying. I think it is very obvious that a scientist who is selling out would be on the other side of this debate. The side with the money. Not the side we you have to do a lot of boring volunteer work without pay in addition to your regular duties.
Yes, the daemon process forking a child and exits only after initialization is complete. This is a nice and clean solution. Systemd adds an interface so that "new-style" daemons can notify about completion. I hate this stupid complexity.
The numbers seem to imply other wise. Profitable with increasing sales before and loss-making and collapsing sales after declaring Symbian dead and switching to Windows Phone. In don't doubt that there was infighting which delayed things a lot, but the awesome N9 and its brother (with keyboard) were ready before Lumia - even when it took a long time, they had their own modern smartphone OS which got a lot of praise. And then there was always Android as an option. Switching to Windows Phone which was already loosing on the market was simply the most stupid thing to do.
You are mostly right about open source. I am not telling people where to spend their time. I merely pointing out that there are users which depend on features which are not supported by Wayland. And - as such a user - I would find a switch to Wayland unfortunate.
What makes me angry is that people say that this discussion is not based on facts. The statement that network transparency is already broken is - as such - obviously not true. (and yes, I use modern GTK3 and Qt4 and other applications over the network - so far there is no problem.) The statement that Wayland will be much faster is atleast questionable.
You are also right, that Xrender was implemented to save network transparency a decade ago. Xrender is an excellent example how you can develop a protocol in a backwards compatible way without breaking existing features.
Because you obviously were mixing pixel scraping (used by RDP) with pixel pushing. Quoting yourself: "Why? RDP also pushes pixels"
Doesn't it push the pixels over the network after scraping them?
You were also obviously confusing using Xrender to push pixels and using Xrender in a way which leads to low bandwidth usage. Again, quoting yourself The term "software rasterizer" does not necessarily imply that it does not use Xrender.
Which is true. I don't see any confusion here on my part. Pixels can be pushed over the network and used in different ways on the server usind Xrender or not. Exactly as I said: the term "software rasterizer" does not imply exactly what is done.
Using the X protocol for a screen scraper is a bad ideia: a) it does not provide means to compress the image on the wire.
This is true, but if used with ssh -X there would be some compression at a lower level. Also adding an extension to transfer compressed images would be very easy.
b) the display X server won't always keep the contents of the window. Eg, if you minimize and then restore a window, the display X server may require the contents of the window to be re-send, although they haven't been changed by the application.
Yes, but the application can store stuff at the X server and then later access it. I know, I wrote such code.
I really can't fathom why you insist on using the X protocol for a pixel scraper. There isn't anything new here. We have a bunch of pixel scrapers around for a long time (VNC, RDP, Xpra and, to some degree, NX) and they've all found it useful to use a specific protocol.
Because using X would backwards/forwards compatible, cross-platform, widely supported on UNIX/Linux (so far), and effortless (just use ssh -X). It also would keep the door open for applications which want to do something more clever than pixel scraping.
Some people like RDP because despite being owned by MS (and subject to patents) the FreeRDP project provides a good implementation of the RDP protocol, which AFAIK, compares favourably with other pixel scrapers.
Last time I tried to connect to a Windows server from Linux it simply did not work. But I am not opposed RDP. But I like X more because of the aforementioned reasons.
I am merely pointing out that I use network transparency on a up-to-date Linux system (not with gnome3 but with gnome3 applications). So the statment that network transparency is already broken is obviously false. If he said something else then it was not me who put it out of context.
I also like how I am modded troll merely for pointing out that it works for me.
So he hacked X to make it work in wayland - among many other things he does with X. This does not imply he gave up working on X in favour of Wayland. A better indications about doing the development activity and who is doing what are the mailing lists:
The idea that all/most X hackers gave up on X and are now working on Wayland as its successor is far from the truth.
Also - maybe I gave a false impression - but I am not opposed to Wayland. It is rather nicely designed and well written piece of software. What makes me angry is the idea that it is declared the future of Linux we all have to switch to when it clearly also has some downside, e.g. broken compatibility and network transparency. But those things are not openly discussed, instead they are "adressed" by FUD such as "network transparency is already broken". Oh, you are using it? You must be a lier because Daniel Stone told us it is already broken.
I don't see why you think I am mixing this up. I understand this well and fully agree with your description. What I meant is that you can implement method 3 without having a special protocol but by using the X protocol. The local pixel scraper would compute the changes could use the X protocol (instead of its own special protocol) to transfer them to any standard X server. The X protocol can be used to copy stuff on the server around when some screen region moved without retransmission of the data or update only parts of the window which have changes etc...
Or in other words, you could do the same as RDP but using X as protocol even for clients which are not optimized for remoting (while keeping the door open for clients which want to support this even better). And I am not sure why people like RDP so much, it is a proprietary and patent-protected (with a free license under some conditions) protocol from Microsoft with a lot of extensions (if people joke about the print server in X and then point to RDP I can only lough - because RDP has it too)
Obviously, shared memory and direct access to the hardware are not network transparent. Guess how many applications require it?
Now re-guess how many applications would adopt it in the name of smoother faster and (I'll admit this will creep in) shinier UI animations if it didn't break something in the process?
The fact that most of the X-window system isn't hardware accelerated is really nothing to be very proud of. In any case it's not the job of the application, it's the job of the toolkit or framework to do that.
Not many. Also most users don't care about about shinier UI and turn effects off and most distributions went back on desktop effects in their default applications. But there is another more important thing wrong with your comment: Wayland will not offer smoother or faster effects. This is a myth. You can do exactly the same things with X. Wayland will simplify things on the developer side by getting rid of old cruft (at the cost of backswards compatibility), but it will not make things fundamentally faster or smoother.
Well, I also find strange that people say they see no difference.
I see no difference on my work or home network. I admit (and have done so several times in this thread) that the experience is different if you have high latency. The Wayland proponent's argument seems to be that because it does not work well in all cases, it is ok to break it for the other use cases as well. Since I am using it just fine, I am not happy about that kind of argument.
From the top of my head, GTK3 applications are the only ones based on a modern toolkit that still run very well.
Yes, also Qt4 seems to work well, I don't know about Qt5. It would be a shame if they broke it.
The fact that Qt5 needs libXrender doesn't mean it has a Xrender based backend. AFAIK, Qt5 only has two backends: software rasterizer and OpenGL. I've never seen any evidence of other backends.
The term "software rasterizer" does not necessarily imply that it does not use Xrender. Also both could work over the network, but I haven't tried any Qt5 application so I do not know how well this works.
Trying to forward Wayland clients over the X prototol is dumb. Wayland clients (application) do nothing but to push pixmap buffers to the server. Try to forward that directly over the network in any shape or form and you get terrible performance.
Why? RDP also pushes pixels and it supposed to be faster than traditional X remoting (also whenever I tried to use it it never worked for some stupid compatibility reason) . Also Xrender essentially pushes pixels and works well - atleast for Gtk. The question is only how to push the pixels. The X protocol is really very flexible, so I think one could make this fast, e.g. only transmit changes.
The only solution is either to have a pixel scrapping mechanism or to have Wayland clients (applications) support some other protocol. Which most Wayland clients (applications) already do: they support X.
Yes, a pixel scrapping mechanism which then send the pixels using X is what I had in mind.
Hey, if you like RDP better, why don't you just use it. There are clients for X. I am not the one who wants to break your user experience. All I am asking for is that you don' please break mine, because for me X works just fine.
Obviously, shared memory and direct access to the hardware are not network transparent. Guess how many applications require it?
You know, this discusson is rather surreal. I run remote applications right now and you guys keep telling me it is broken. It is like sitting in an airplane and your seat neighbor claims that flying is actually impossible.
Ofcourse. This is not about the power of the device. My phone runs X just fine too. The point is that when you are intel or collabora and your customers are people who build entertainment systems for cars, TV set-top boxes, or mobile devices, then the UNIX legacy, which includes network transparency, and backwards compatibility, or support for customizable window managers, etc... just does not have any priority. Getting rid of all that complexity is then a rational choice. For the Linux desktop this would be a major loss. But this is not a market which counts and half of the users can be fooled into thinking that Wayland would be faster than X and network transparency is broken already.
1) X devs with decades of understanding and benchmarks claim X has horrible bottlenecks that can make Wayland 10x-100x faster for cases that are becoming more common
because he read it on the internet somewhere but doesn't bother to give a source.
2) Uecker claims X is fine because he installed X
Indeed. I know that X works fine because I use it - even over the network. If somebody comes a long and tells you that something you do is actually impossible you know they are full of shit.
Modern X applications (well, the toolkits) are resorting so much to simply pushing bitmaps to the X server that X is becoming unusable over the network.
I always find it strange that people make such claims. I use X over the network and I do not feel any difference to local clients. I might not work as well on your network, but claiming X is "unusable" or "network transparency is broken" just plain ignores that it works very well for some of us.
Eg, the Qt developers found sometime ago that their client side rendering backend was much faster for local usage than the Xrender backend. So they made it the default for Qt4.4 And for Qt5 they didn't even bother with a Xrender based backend.
The client side rendering backend pushes so much data Kate is actually painful to use over a Gigabit Ethernet local network, don't even mention working from home. And this can be said for many other applications I use daily.
I use gnome software such as nautilus, evince, eog, gedit over the network just fine. I just installed kate to test and it also works perfectly... I could not notice any difference to a local client. Your Gigabit ethernet must be much slower than my gigabit ethernet....
I run applications remotely on a daily basis. But now it's mostly under Xpra instead of plain X forwarding. Good performance over the network is buried very deep in the priority list of most graphical application developers, if it's on the list at all.
And an Xpra like solution is something you can implement for Wayland.
Unfortunately, rewriting the GUI over and over again seems high on the priority list of graphical application developers. I actually hope somebody just implements a solution which uses the X protocol to forward Wayland clients remotely...
There are 3 situations involving applications, networking and graphics a) Running an application on a machine sharing ram with the video card. b) Running applications on a machine close enough to the video card that the latency between them is lowish and the bandwidth is plentiful and performance is irrelevant. c) Running applications on a machine where either the latency is high or the bandwidth is limited X11 does terrific for (b) in exchange for damaging (a) and (c). X11 was designed in a world where (b) is common. In today's world (b) is uncommon.
Nonsense. For (a) X can do fundamentally exactly the same thing as Wayland: Direct Rendering and and messages over a UNIX domain socket. (b) is still very common and I use X over such a network every day. In fact (b) is much more common now than when X11 was designed because we have much better networks now and a good wireless network falls into this category. (c) is a problem for X, but this is not a fundamental problem with X but with Xlib which could be fixed. But even there Wayland does not offer any advantage with its RDP: You can use RDP with X as well.
Other issues:
1. The mixing of signed and unsigned coordinates causes problems both in the protocol, where 3/4 of the coordinate space is often unrepresentable, and in the C language bindings. 2. The X protocol is asynchronous for efficiency: in general, neither the server nor clients wait for replies. But the protocol’s synchronization mechanisms are insufficient, and leave many unavoidable race conditions. 3. The X protocol attempts to be policy-free and tries not to dictate any particular style of window management. However, some desirable window manager features cannot be implemented correctly, because there are window attributes which the window manager can neither fetch nor monitor. 4. The X protocol provides visibility notification events so that clients can avoid computation of obscured window contents. However, this notification doesn’t work well for nested windows or for windows with backing store. 5. None of the several ways that an application can implement interactive mouse tracking of crosshairs, bounding boxes, etc., allow both efficiency and correctness. 6. Popping up menus and dialog boxes is slow because it requires too many round trips and generates too many events. Repainting when portions of a window become visible is often slow. 7. Exceptional conditions are poorly handled. Faulty programs can freeze the server, and clients cannot kill queued requests if the user doesn’t want to wait for the server to finish servicing them.
You seriously had to steel your arguments from a document from 1990? How is this still relevant?
Hania Gajewska, Mark Manasse, and Joel McCormack, "Why X Is Not Our Ideal Window System," Software Practice and Experience, Vol. 20, No. S2 (special issue), October, 1990. http://www.std.org/~msm/common...
X is network transparent. I use it *every* day with different applications. If some clown comes along and says it is already broken (because his direct-rendered wobbly windows do not work over the network or something) then this is simpy FUD. And you are an idiot if you believe it.
Seriously, what's so broken about X? Is it just a pain in the ass for developers to work with?
If X, or more specifically the X.org implementation, had been written by Leonard Poettering every article would be followed by a gazillion comments whining about how it is a monolithic single point of failure (which had to run as root until very recently on many systems),
X could run as non-root for quite some time. There is nothing fundamentally wrong in X which could prevent this. That no Linux distribution spent the time and effort to make this work is a different matter (AFAIK Openbsd did it for a while).
it has terminal NIH syndrome (everything from ELF library loading to low-level graphics drivers to stippled line rendering),
Funny, I would call MIR and Wayland a result of a NIH syndrome. One reason X has a lot of stuff is that it supported a lot of different obscure operating systems. I guess that is why it had an ELF loader (if this is even true). Again, this has nothing to do with X by itself.
it "violates the UNIX philosophy" by doing multiple things (it's a remote display protocol, it's a input event multiplexer, it's a bitmap typeface renderer),
Maybe, redesigning the implementation of the X server and split things up is certainly a good idea. Fundamentally, X splits policy and mechanism (e.g. window managers are not part of the server) and I think this is good design.
it is not easily extensible
Are you kidding me? It has an extension mechanism which has been used in the past to extend in backwards compatible ways.
(extending the core protocol is often not portable so GNOME and KDE etc overload scores of "window properties" to serve as a quasi-protocol),
This is a good thing: New clients can use new protocols to communicate with each other using old servers. I think this is an example for great design.
it's full of useless crud
This is true. But that crud does no harm and is needed for backwards compatibility. Backwards compatibility is a good thing.
(for example, with modern toolkits the much-vaunted 'network transparency' usually boils down to sending pre-rendered bitmaps, as the aforementioned stippled line support is not considered sufficient) etc.
Yes, and this works great! I use it every day!
Of course, X11 was a gift stolen by Prometheus from the Unix gods.
No, but the protocol is actually very good and lot of criticism is simply not justified.
Slashdot Mirror
No, the standard body should do its job and produce good standards. Whether Microsoft implements it or not is not their problem. A good standard which Microsoft does not use is much better than a mess which nobody can implement correctly.
The additional cost for renewables for German consumers in 2014 is 6.24 ct/kWh (and parts of the industry is exempt) which is less than other taxes paid on electricity. While solar is still expensive (but went down a lot) wind is clearly one of the cheapest source of energy.
Participating scientists are not compensated for their efforts.
Depends on what you consider to be "compensation"...
They aren't all doing it for nothing, rest assured...
I am not sure what you are implying. I think it is very obvious that a scientist who is selling out would be on the other side of this debate. The side with the money. Not the side we you have to do a lot of boring volunteer work without pay in addition to your regular duties.
Participating scientists are not compensated for their efforts.
Yes, the daemon process forking a child and exits only after initialization is complete. This is a nice and clean solution.
Systemd adds an interface so that "new-style" daemons can notify about completion. I hate this stupid complexity.
ttp://www.freedesktop.org/software/systemd/man/daemon.html
The numbers seem to imply other wise. Profitable with increasing sales before and loss-making and collapsing sales after declaring Symbian dead and switching to Windows Phone. In don't doubt that there was infighting which delayed things a lot, but the awesome N9 and its brother (with keyboard) were ready before Lumia - even when it took a long time, they had their own modern smartphone OS which got a lot of praise. And then there was always Android as an option. Switching to Windows Phone which was already loosing on the market was simply the most stupid thing to do.
You are repeating yourself. Learn to have a discussion: This implies replying to the things I wrote.
Well, the users who actually do work with their computer probably do not comment as much... For speed, let's just wait for the benchmarks.
You are mostly right about open source. I am not telling people where to spend their time. I merely pointing out that there are users which depend on features which are not supported by Wayland. And - as such a user - I would find a switch to Wayland unfortunate.
What makes me angry is that people say that this discussion is not based on facts. The statement that network transparency is already broken is - as such - obviously not true. (and yes, I use modern GTK3 and Qt4 and other applications over the network - so far there is no problem.) The statement that Wayland will be much faster is atleast questionable.
You are also right, that Xrender was implemented to save network transparency a decade ago. Xrender is an excellent example how you can develop a protocol in a backwards compatible way without breaking existing features.
Because you obviously were mixing pixel scraping (used by RDP) with pixel pushing.
Quoting yourself: "Why? RDP also pushes pixels"
Doesn't it push the pixels over the network after scraping them?
You were also obviously confusing using Xrender to push pixels and using Xrender in a way which leads to low bandwidth usage.
Again, quoting yourself The term "software rasterizer" does not necessarily imply that it does not use Xrender.
Which is true. I don't see any confusion here on my part. Pixels can be pushed over the network and used in different ways on the server usind Xrender or not. Exactly as I said: the term "software rasterizer" does not imply exactly what is done.
Using the X protocol for a screen scraper is a bad ideia:
a) it does not provide means to compress the image on the wire.
This is true, but if used with ssh -X there would be some compression at a lower level. Also adding an extension to transfer compressed images would be very easy.
b) the display X server won't always keep the contents of the window. Eg, if you minimize and then restore a window, the display X server may require the contents of the window to be re-send, although they haven't been changed by the application.
Yes, but the application can store stuff at the X server and then later access it. I know, I wrote such code.
I really can't fathom why you insist on using the X protocol for a pixel scraper. There isn't anything new here. We have a bunch of pixel scrapers around for a long time (VNC, RDP, Xpra and, to some degree, NX) and they've all found it useful to use a specific protocol.
Because using X would backwards/forwards compatible, cross-platform, widely supported on UNIX/Linux (so far), and effortless (just use ssh -X). It also would keep the door open for applications which want to do something more clever than pixel scraping.
Some people like RDP because despite being owned by MS (and subject to patents) the FreeRDP project provides a good implementation of the RDP protocol, which AFAIK, compares favourably with other pixel scrapers.
Last time I tried to connect to a Windows server from Linux it simply did not work. But I am not opposed RDP. But I like X more because of the aforementioned reasons.
I am merely pointing out that I use network transparency on a up-to-date Linux system (not with gnome3 but with gnome3 applications). So the statment that network transparency is already broken is obviously false. If he said something else then it was not me who put it out of context.
I also like how I am modded troll merely for pointing out that it works for me.
So he hacked X to make it work in wayland - among many other things he does with X. This does not imply he gave up working on X in favour of Wayland. A better indications about doing the development activity and who is doing what are the mailing lists:
http://lists.x.org/archives/xo...
http://lists.freedesktop.org/a...
The idea that all/most X hackers gave up on X and are now working on Wayland as its successor is far from the truth.
Also - maybe I gave a false impression - but I am not opposed to Wayland. It is rather nicely designed and well written piece of software. What makes me angry is the idea that it is declared the future of Linux we all have to switch to when it clearly also has some downside, e.g. broken compatibility and network transparency. But those things are not openly discussed, instead they are "adressed" by FUD such as "network transparency is already broken". Oh, you are using it? You must be a lier because Daniel Stone told us it is already broken.
I don't see why you think I am mixing this up. I understand this well and fully agree with your description. What I meant is that you can implement method 3 without having a special protocol but by using the X protocol. The local pixel scraper would compute the changes could use the X protocol (instead of its own special protocol) to transfer them to any standard X server. The X protocol can be used to copy stuff on the server around when some screen region moved without retransmission of the data or update only parts of the window which have changes etc...
Or in other words, you could do the same as RDP but using X as protocol even for clients which are not optimized for remoting (while keeping the door open for clients which want to support this even better). And I am not sure why people like RDP so much, it is a proprietary and patent-protected (with a free license under some conditions) protocol from Microsoft with a lot of extensions (if people joke about the print server in X and then point to RDP I can only lough - because RDP has it too)
Obviously, shared memory and direct access to the hardware are not network transparent. Guess how many applications require it?
Now re-guess how many applications would adopt it in the name of smoother faster and (I'll admit this will creep in) shinier UI animations if it didn't break something in the process?
The fact that most of the X-window system isn't hardware accelerated is really nothing to be very proud of. In any case it's not the job of the application, it's the job of the toolkit or framework to do that.
Not many. Also most users don't care about about shinier UI and turn effects off and most distributions went back on desktop effects in their default applications. But there is another more important thing wrong with your comment: Wayland will not offer smoother or faster effects. This is a myth. You can do exactly the same things with X. Wayland will simplify things on the developer side by getting rid of old cruft (at the cost of backswards compatibility), but it will not make things fundamentally faster or smoother.
Well, I also find strange that people say they see no difference.
I see no difference on my work or home network. I admit (and have done so several times in this thread) that the experience is different if you have high latency. The Wayland proponent's argument seems to be that because it does not work well in all cases, it is ok to break it for the other use cases as well. Since I am using it just fine, I am not happy about that kind of argument.
From the top of my head, GTK3 applications are the only ones based on a modern toolkit that still run very well.
Yes, also Qt4 seems to work well, I don't know about Qt5. It would be a shame if they broke it.
The fact that Qt5 needs libXrender doesn't mean it has a Xrender based backend. AFAIK, Qt5 only has two backends: software rasterizer and OpenGL. I've never seen any evidence of other backends.
The term "software rasterizer" does not necessarily imply that it does not use Xrender. Also both could work over the network, but I haven't tried any Qt5 application so I do not know how well this works.
http://qt-project.org/wiki/Qt5...
Trying to forward Wayland clients over the X prototol is dumb.
Wayland clients (application) do nothing but to push pixmap buffers to the server. Try to forward that directly over the network in any shape or form and you get terrible performance.
Why? RDP also pushes pixels and it supposed to be faster than traditional X remoting (also whenever I tried to use it it never worked for some stupid compatibility reason) . Also Xrender essentially pushes pixels and works well - atleast for Gtk. The question is only how to push the pixels. The X protocol is really very flexible, so I think one could make this fast, e.g. only transmit changes.
The only solution is either to have a pixel scrapping mechanism or to have Wayland clients (applications) support some other protocol. Which most Wayland clients (applications) already do: they support X.
Yes, a pixel scrapping mechanism which then send the pixels using X is what I had in mind.
Hey, if you like RDP better, why don't you just use it. There are clients for X. I am not the one who wants to break your user experience. All I am asking for is that you don' please break mine, because for me X works just fine.
Obviously, shared memory and direct access to the hardware are not network transparent. Guess how many applications require it?
You know, this discusson is rather surreal. I run remote applications right now and you guys keep telling me it is broken. It is like sitting in an airplane and your seat neighbor claims that flying is actually impossible.
Ofcourse. This is not about the power of the device. My phone runs X just fine too. The point is that when you are intel or collabora and your customers are people who build entertainment systems for cars, TV set-top boxes, or mobile devices, then the UNIX legacy, which includes network transparency, and backwards compatibility, or support for customizable window managers, etc... just does not have any priority. Getting rid of all that complexity is then a rational choice. For the Linux desktop this would be a major loss. But this is not a market which counts and half of the users can be fooled into thinking that Wayland would be faster than X and network transparency is broken already.
Bengie believes,
1) X devs with decades of understanding and benchmarks claim X has horrible bottlenecks that can make Wayland 10x-100x faster for cases that are becoming more common
because he read it on the internet somewhere but doesn't bother to give a source.
2) Uecker claims X is fine because he installed X
Indeed. I know that X works fine because I use it - even over the network. If somebody comes a long and tells you that something you do is actually impossible you know they are full of shit.
Then half of the windows on my desktop cannot actually exist...
That's not what he meant I think.
Modern X applications (well, the toolkits) are resorting so much to simply pushing bitmaps to the X server that X is becoming unusable over the network.
I always find it strange that people make such claims. I use X over the network and I do not feel any difference to local clients. I might not work as well on your network, but claiming X is "unusable" or "network transparency is broken" just plain ignores that it works very well for some of us.
Eg, the Qt developers found sometime ago that their client side rendering backend was much faster for local usage than the Xrender backend. So they made it the default for Qt4.4 And for Qt5 they didn't even bother with a Xrender based backend.
That does not seem to be true: http://qt-project.org/doc/qt-5...
The client side rendering backend pushes so much data Kate is actually painful to use over a Gigabit Ethernet local network, don't even mention working from home. And this can be said for many other applications I use daily.
I use gnome software such as nautilus, evince, eog, gedit over the network just fine. I just installed kate to test and it also works
perfectly... I could not notice any difference to a local client. Your Gigabit ethernet must be much slower than my gigabit ethernet....
I run applications remotely on a daily basis. But now it's mostly under Xpra instead of plain X forwarding.
Good performance over the network is buried very deep in the priority list of most graphical application developers, if it's on the list at all.
And an Xpra like solution is something you can implement for Wayland.
Unfortunately, rewriting the GUI over and over again seems high on the priority list of graphical application developers. I actually hope somebody just implements a solution which uses the X protocol to forward Wayland clients remotely...
There are 3 situations involving applications, networking and graphics
a) Running an application on a machine sharing ram with the video card.
b) Running applications on a machine close enough to the video card that the latency between them is lowish and the bandwidth is plentiful and performance is irrelevant.
c) Running applications on a machine where either the latency is high or the bandwidth is limited
X11 does terrific for (b) in exchange for damaging (a) and (c). X11 was designed in a world where (b) is common. In today's world (b) is uncommon.
Nonsense. For (a) X can do fundamentally exactly the same thing as Wayland: Direct Rendering and and messages over a UNIX domain socket. (b) is still very common and I use X over such a network every day. In fact (b) is much more common now than when X11 was designed because we have much better networks now and a good wireless network falls into this category. (c) is a problem for X, but this is not a fundamental problem with X but with Xlib which could be fixed. But even there Wayland does not offer any advantage with its RDP: You can use RDP with X as well.
Other issues:
1. The mixing of signed and unsigned coordinates causes problems both in the protocol, where 3/4 of the coordinate space is often unrepresentable, and in the C language bindings.
2. The X protocol is asynchronous for efficiency: in general, neither the server nor clients wait for replies. But the protocol’s synchronization mechanisms are insufficient, and leave many unavoidable race conditions.
3. The X protocol attempts to be policy-free and tries not to dictate any particular style of window management. However, some desirable window manager features cannot be implemented correctly, because there are window attributes which the window manager can neither fetch nor monitor.
4. The X protocol provides visibility notification events so that clients can avoid computation of obscured window contents. However, this notification doesn’t work well for nested windows or for windows with backing store.
5. None of the several ways that an application can implement interactive mouse tracking of crosshairs, bounding boxes, etc., allow both efficiency and correctness.
6. Popping up menus and dialog boxes is slow because it requires too many round trips and generates too many events. Repainting when portions of a window become visible is often slow.
7. Exceptional conditions are poorly handled. Faulty programs can freeze the server, and clients cannot kill queued requests if the user doesn’t want to wait for the server to finish servicing them.
You seriously had to steel your arguments from a document from 1990? How is this still relevant?
Hania Gajewska, Mark Manasse, and Joel McCormack, "Why X Is Not Our Ideal Window System," Software Practice and Experience, Vol. 20, No. S2 (special issue), October, 1990. http://www.std.org/~msm/common...
X is network transparent. I use it *every* day with different applications. If some clown comes along and says it is already broken (because his direct-rendered wobbly windows do not work over the network or something) then this is simpy FUD. And you are an idiot if you believe it.
Wayland sends messages over a socket using a protocol - exactly as X does.
Seriously, what's so broken about X? Is it just a pain in the ass for developers to work with?
If X, or more specifically the X.org implementation, had been written by Leonard Poettering every article would be followed by a gazillion comments whining about how it is a monolithic single point of failure (which had to run as root until very recently on many systems),
X could run as non-root for quite some time. There is nothing fundamentally wrong in X which could prevent this. That no Linux distribution spent the time and effort to make this work is a different matter (AFAIK Openbsd did it for a while).
it has terminal NIH syndrome (everything from ELF library loading to low-level graphics drivers to stippled line rendering),
Funny, I would call MIR and Wayland a result of a NIH syndrome. One reason X has a lot of stuff is that it supported a lot of different obscure operating systems. I guess that is why it had an ELF loader (if this is even true). Again, this has nothing to do with X by itself.
it "violates the UNIX philosophy" by doing multiple things (it's a remote display protocol, it's a input event multiplexer, it's a bitmap typeface renderer),
Maybe, redesigning the implementation of the X server and split things up is certainly a good idea. Fundamentally, X splits policy and mechanism (e.g. window managers are not part of the server) and I think this is good design.
it is not easily extensible
Are you kidding me? It has an extension mechanism which has been used in the past to extend in backwards compatible ways.
(extending the core protocol is often not portable so GNOME and KDE etc overload scores of "window properties" to serve as a quasi-protocol),
This is a good thing: New clients can use new protocols to communicate with each other using old servers. I think this is an example for great design.
it's full of useless crud
This is true. But that crud does no harm and is needed for backwards compatibility. Backwards compatibility is a good thing.
(for example, with modern toolkits the much-vaunted 'network transparency' usually boils down to sending pre-rendered bitmaps, as the aforementioned stippled line support is not considered sufficient) etc.
Yes, and this works great! I use it every day!
Of course, X11 was a gift stolen by Prometheus from the Unix gods.
No, but the protocol is actually very good and lot of criticism is simply not justified.