If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I can run Citrix with Microsoft Windows hosted in a Xen virtual machine 50 miles away over a busy internet connection and response time is immediate.

Citrix is closed source and costs $$$$. Show me a Free/Open Source alternative to secure X-forwarding, and I'll believe you. Otherwise, I'm not ready to give up the beauty, convenience and ease of X-forwarding.

Comment

One thing that people seem to be missing here is that wayland is being intentionally written to make it hard to do networking transparently .

Form the FAQ "No, that is outside the scope of Wayland. To support remote rendering you need to define a rendering API, which is something I've been very careful to avoid doing. The reason Wayland is so simple and feasible at all is that I'm sidestepping this big task and pushing it to the clients. It's an interesting challenge, a very big task and it's hard to get right, but essentially orthogonal to what Wayland tries to acheive. "

The other big thing people are missing is people will be writing apps for wayland. Simply putting X on wayland won't work to run those apps. Just like OS X has support for X but you can't run an OS X app over it.

The reason Apple and M$ don't have native network transparency is they are commercial platforms and the commercial companies that sell software to run on them want you to pay for each machine that runs the app. If everyone can run an app off one machine it eats into their profit margin.

The only real problem with the way X does networking is it sends large uncompressed bitmaps over the network. Running ssh with compression on can alleviate this to some degree.

Comment

Citrix is closed source and costs $$$$. Show me a Free/Open Source alternative to secure X-forwarding, and I'll believe you. Otherwise, I'm not ready to give up the beauty, convenience and ease of X-forwarding.

Well the best we have now is from Redhat in the form of the SPICE protocol.

Latency does not affect it like X is. It heuristically determines animations and compresses them using MJPEG. You can disconnect and reconnect without losing your session. It beats out ICA and RDP in terms of performance.

The downside is that it requires virtualization as it does the networking at the driver level instead of the GUI. I don't see why that can't be duplicated on a host machine with proper drivers and a 'virtual' video card. I don't know the details enough to know the feasibility of it.

I think that something as brute force as just doing a screen capture at 1024x768 with 15fps compressed to a optimized version of WebM/MPEG-4 streamed to your machine with a second protocol designed to route clicks and keyboard input back to the display manager will easily yield superior results then X networking. Especially over high latency links. This may sound like it means high cpu usage, and it does now... even the most basic IGP video devices (aka Intel) will come with codec acceleration.

----------------------------

But my point is that even with ICA being all proprietary and $$$$ it still has dominated the market were X11 has been around for years.

The other big thing people are missing is people will be writing apps for wayland. Simply putting X on wayland won't work to run those apps. Just like OS X has support for X but you can't run an OS X app over it.

That's for native Wayland applications.

X is not going anywhere any time soon and you don't need a X Server running your display to use X11 networking or use X applications. In fact I am willing to bet that X11 on Wayland will be better then X11 on Xfree DDX.

Even after Wayland (if that every happens) become standard the vast majority of applications people use on it are still going to be X. There really isn't a reason not to. And out of the native applications for Wayland they are mostly going to be using GTK or QT, which will provide X if you need it.

The reason Apple and M$ don't have native network transparency is they are commercial platforms and the commercial companies that sell software to run on them want you to pay for each machine that runs the app. If everyone can run an app off one machine it eats into their profit margin.

You have no clue.

The remote desktop support that Microsoft provides built into Windows is vastly superior to X11 in terms of performance and features. It supports audio and file transfer, for example. Try doing "ssh remote.example.com firefox", go to a website and download a file.

We just recently got decent audio network support for Linux and people all over the planet are crying and bitching about it saying how stupid and pointless it is. Microsoft, meanwhile, has had that for years.

And have you ever priced out a X thin client? Most of them are more expensive then a cheap desktop running Windows AND almost all of them support ICA and RDP as well as X11.

I've used X11 for well over a decade now on almost a daily basis. To this day. But to be honest most Windows users are not missing out on anything.

Comment

-For server-client configs that are usefull in the internet age we already have the cloud/webapps like gmail, facebook, etc.;

Cloud apps work for somethings but in other instances they are a HUGE bottleneck.

-Remote filesystem mounting makes it even more useless as you can simply run your own app local on the networked data as if it was local data;

Great in theory but real world bottlenecks such as remote bandwidth capability comes in to play. This is why the world doesn't operate on VPN's.

-Existing crappy remote desktops solutions (MS Windows style) are good enough to just turn on a remote app in case of remote scientific calculations that need to be put in action on a powerfull remote 'super'computer;

Even "supercomputers" have their bottlenecks. Again this is all very app dependent. No one solution fits all. You don't even have to go into heavy scientific calculation to justify running on a remote desktop. My companies realtime software for example absolutely chokes if you are trying to run it over vpn just from the sheer size of the databases if you were to have the client doing the calculations. On the flipside however the more people you have trying to run it via remote desktop on the server creates another issue of CPU overload when multiple people login and try to do some large queries.

-In case of special cases, such as audio and video there are dedicated protocols and apps for that already. Think of VLC for networked music and video and 'that' HD video streaming on devices such as a Playstation 3 for which there are also apps available that can use this protocol on your computer.

Now X11 protocol is not a solution that enables you to do things you couldn't do otherwise anymore. But the problem is that while the X.org implementation doesn't exclusively creates advantages, it still fully imposes all (or most/many) of its downsides.

So Wayland is not such a bad thing to considder.

You are not really looking at the bigger picture here. Wayland on it's own is good for some tasks, for others it is not. Same goes for X. In short there is no "one size fits all" solution.

Comment

You are not really looking at the bigger picture here. Wayland on it's own is good for some tasks, for others it is not. Same goes for X. In short there is no "one size fits all" solution.

I'm not saying that it's ideal, but I'm saying X isn't the excluvie way to do 'stuff' anymore and that paves a way for Wayland adoption.

What I increasingly see is that webapps are used on smartphones, tablets and netbooks. The problem with ISP's is that everywhere around the globe they are starting to make use of datalimits due to unpredicted rapid adoption and thus use of wireless networks, like 3G. That in turn results in API's for these apps, where the app runs localy and the data is streamed over the network so limit the data send.

Things like remote file systems are only used for small things like storing relatively small files like photo's and music. This, again, is what John Doe user does.

X.org remain a powerfull tool to run on top of Wayland for the power users, but that userbase is very small. These users probably have computers that are powerfull enough for this, but for the majority of users (like 99,99%) Wayland is improving thir situation.

BTW X11 isn't that great when it comes to networked apps. It would be much better to have something like NeWS, but done better. Also, with all these more clean and more dedicated solutions it would be cleaner to let the widget toolkit do the networking, Pulse to do the networking sound and Wayland to do the networked input and alternative also the Fuse FS to complement this all for storage. Having all that neatly integrated into the OS with the option of X.org for pro's would be very nice.

Comment

One thing that people seem to be missing here is that wayland is being intentionally written to make it hard to do networking transparently.

Bullshit. Wayland is being written in such a way that adding network transparency is dead easy. Just use a network-based compositor.

Everyone keeps forgetting that Wayland IS JUST A PROTOCOL. Other than a couple protocol-based libraries, there is no Wayland Display Server. That's a myth.

The idea is that KDE or GNOME or E or whoever implements their own Wayland Display Server. And it can use DRI2/KMS/EGL to display straight to your local display. Or it can talk over some other protocol over the network. Or it can talk to an X server it's nested in. Or it can just stream out stuff to disk for debugging. Or whatever else you want.

Form the FAQ "No, that is outside the scope of Wayland. To support remote rendering you need to define a rendering API, which is something I've been very careful to avoid doing. The reason Wayland is so simple and feasible at all is that I'm sidestepping this big task and pushing it to the clients. It's an interesting challenge, a very big task and it's hard to get right, but essentially orthogonal to what Wayland tries to acheive. "

That doesn't mean what you are implying it means. Either you need to retake English Compression 101 or (and I think this the more likely case) you need to stop intentionally misrepresenting other peoples' words for your own ends.

The other big thing people are missing is people will be writing apps for wayland.

No, they won't. Nobody writes apps for X11. Seriously. People write apps for _GTK_ or _Qt_ or one of the other handful of toolkits out there. Nobody freaking writes raw X11 code anymore unless they're implementing a toolkit backend or writing an X11 window manager.

The same will be true for Wayland. People are just going to expect GTK and Qt and so on to gain Wayland protocol support. And they're going to expect their applications to need zero porting effort to run on Wayland.

In fact, the GTK users can _already_ expect their apps to transparently run on both X11 and Wayland without so much as a recompile or relink, because the toolkit can now host multiple backends in the same library, so those application binaries can just run on either protocol; you can even switch between them when you start the application by setting the appropriate environment variables, if you feel some need to force an X11 connection despite the default being Wayland in some theoretical distribution.

The reason Apple and M$ don't have native network transparency is they are commercial platforms and the commercial companies that sell software to run on them want you to pay for each machine that runs the app. If everyone can run an app off one machine it eats into their profit margin.

Except that both of them fully support remoting. I'm unsure about Apple, but Microsoft even offers their own free remoting tools. They're just not tightly integrated in like X11. Mostly because nobody is asking for it and implementing that level of integration would just give them all the problems of X11 with no benefits that barely anybody cares about.

The only real problem with the way X does networking is it sends large uncompressed bitmaps over the network. Running ssh with compression on can alleviate this to some degree.

You don't understand X11 or its problems at all. X is slow over the network because of the round trips it requires for operations that really have no business requiring round trips. In a latency-high environment (such as anybody using wireless internet connections or even just wireless home routers in most average interference-heavy buildings... which is most of us, these days) it takes a very long time for X11 apps to respond to and deal with events.

The competing protocols aren't faster because of image compression. Image compression is actually the least valuable thing you can do for these protocols for mainstream broadband users. The competing protocols are faster because they stream input events and they stream screen updates rather than requiring a complex dance of request/response/acknowledgement messages for every single event.

A latency heavy network is a lot like the regular mail system. Whether you are sending a single letter or a huge crate, it takes a while to get to the destination. X11 is implemented in such a way that if you want to do a session over snail mail, you'd have to send a letter, wait for a response letter, and then send another letter... almost a week per event before it can even be processed. And then and only then can the next event be sent. The other protocols just drop letters in the mailbox as fast as they need to, and the events are processed as soon as they are received at the other end. So the latency in the communication medium can be felt, but even in a very latency-heavy network thousands and thousands of events can be processed per week while in the X11 world only one or two events could be processed per week. If we're talking about the Internet, just replace letters/boxes with IP packets and replace "weeks" with "seconds" when talking about the timescales. Not-X: tons of events per second even with high latency; X: one event per second with high latency.