>> Wayland 1.0 doesn't mark the point that Wayland is complete and ready to replace the X11 Server as there's still a lot of work left to do but it marks the point at which there is API/protocol stability in terms of all future releases being backwards-compatible with the Wayland 1.0 release.
I conjecture that someone named Kristian Høgsberg (and perhaps his project associates) may not be a native speaker of English.
Here on the intertubes, it's easy to condemn someone for poor usage, however, remember that communicating complex ideas in a second (or sometimes third, or fourth) language is not always the easiest thing to do. Not everyone grew up soaking in it.
This is not an excuse for poor English - but is certainly a legitimate defense against condescending fucktards such as yourself.
Indeed. Phoronix survives only because Michael Larabel is basically the only person willing to sift through the graphics mailing lists and provide summaries. The writing is always atrocious and Larabel frequently makes serious mistakes in his reporting. Every time there's a benchmark the forum is filled with the same complaints; VSync, testing games that use different GL versions between drivers, etc.
Michael has dedication but not much else. If someone was interested, there is some real low-hanging fruit in that niche.
I'm hoping that Wayland will allow for faster direct rendering APIs. There seems to be too much legacy X11 stuff for embedded systems to easily operate in small memory situations.
Well the counter example of that is the Raspberry Pi, it runs X11 poorly while having more capacity and much more performance than the 486 and original Pentium (which are '90's machines). I've been working with a 'Pandaboard' which is an OMAP 4460 system, and its challenged too.
So perhaps we have a different definition of 'is fine.' :-) Have you run X11 on an RpI ? did you think that was fine?
In 1992 (or 1993 ?), I had a 486DX33 with 16 Mb of memory and 120Mb HD running linux 0.99pl12 at resolution 1152x900. It was very confortable, no problem for compiling kernel while playing tetris.
I run the default window manager which is really basic on Raspbian "Wheezy". In my application I ssh tunnel to a 'big' machine, startup Firefox and have it display full screen on the RaspPi (its a really cheap 'dashboard' machine). One window, over a gigabit link, updates, mouse movements, keyboard response, with multi-second latency. Not fun at all.
nvidia cards are quite common, so one hopes this major limitation can be worked around. Perhaps we should get Torvalds to comment in his inimitable style on the situation.
I wish Ubuntu (or other distributions) would give out numbers how many people install the proprietary drivers. So many Linux guys seem to dismiss games and 3D (which is certainly also used for VR, architecture, 3D modeling, simulations - and not just for games), so I'm somewhat curious how much it matters on the Linux desktop. At least personally I know more people using proprietary drivers on Linux than not using them, but I guess that's to be expected for a 3D developer ;-)
For me the thought of losing nvidia driver support on Ubuntu is rather scary given the current state of all other 3D drivers (and certainly other Distro's might follow with Wayland). I hope the status of other drivers improves a lot before that switch or 3D on Linux will be set back a lot.
Now that Steam is supporting Linux (and possibly making a Linux/steam box), I suspect that they will be able to push for improved graphics drivers. In fact, If I remember correctly, while working on optimizing some of their first ports to Linux, they got Nvidia to improve some elements of the drivers.
Also, given the number of people using Nvidia drivers on Ubuntu, my guess would be that Ubuntu will not switch to Wayland until the compatibility issue is solved.
nouveau drops to Unity2d on Ubuntu 12.04 when using a modest pci-e GT520 card, so I shall try a 12.10 live cd and see what cooks. Thanks for the quote/still, I was aware of that one. There might need to be another outburst if we reach a situation where a future distribution can't work properly on hardware with nvidia graphics...
Torvalds was not referring to nVidia's video support for Linux when he made that statement; he was referring to their reluctance to cooperate with development efforts on their mobile chips, Tegra. nVidia has been far and away the best provider of first-class video driver support for free POSIX systems.
The X11 and Linux display landscape has changed dramatically over the last few years. I think that nVidia chose the wise strategy of "wait and see" to pinpoint what stabilizes and have since been working on porting pieces of their proprietary driver. The recent addition of XRandR 1.2+ support probably has more to do with the announcement of Optimus development than anything else, and this work is probably a precursor to a version that supports KMS and the other technologies that will be required for compatibility into the next five years of Linux desktop.
actually since then, nvidia tried to add optimus support to their drivers. they asked for dma-buf access, but got adam coxblocked by the free software fanatics
It's complicated. Wayland can replace some parts of X11 in Linux distributions, but it relies on some other parts of X11 (like libxkbcommon).
I believe Wayland window managers [1] will replace most of X11 for most users in a couple of years, but X11 will still be around to run legacy apps (similar to the way you can run X11 applications in
I also think that Wayland will replace X11 in the way that most of the X11 developers will move to Wayland. X11 will still be around, and probably still be supported by window managers for quite a while though.
1. Wayland is actually the protocol/API, which window managers/compositors and the applications that run in them will implement. The reference compositor for the Wayland project is called Weston.
>I believe Wayland window managers [1] will replace most of X11 for most users in a couple of years, but X11 will still be around to run legacy apps (similar to the way you can run X11 applications in
This comment must have been submitted from an X11 application running in MacOS X. I am having the s
I believe Wayland's stated goal is exactly that: to replace X11. of course they don't mean they're going to wipe out X11 from existence, if you prefer that you'll still be able to use it, but wayland should eventually be able to completely fill the role that X11 currently fills.
Very few apps call the X api directly. Nearly everything uses GTK or Qt, which they'll still be able to do, except that behind the scenes GTK/Qt will hook into Wayland on Linux and X elsewhere.
> That doesn't sound good. It seems that Wayland will have a hard time to replace X11 in the next decade. Currently I see no reason why I should switch.
The reason you will switch is that plain X11 goes unsupported and will not work on modern systems.
The initial thing you will switch is not Wayland proper, it's just X11 sitting on top of Wayland. Thinking of Wayland as a competing display server is as of now not really realistic -- it's much better to think it as a refactoring of the internals of the system that uses X and compositors, taking the parts of both that need privileges on the system and really fast communication and merging them together in Wayland, leaving the rest of the parts into X.
Wayland is going to replace portions of X11 pretty much as fast as it can. Basically, the X11 devs want to drop all the parts of the pipeline that Wayland implements from X11 and move to (usermode) X11 on Wayland.
Yep. While it has it good points, it is never going to replace x11 on my laptop since it requires compositing. And i more or less had to turn off compositing on my thinkpad edge since it reduced the akku lifetime drastically and was very noisy.
I find it strange to call it 1.0 while remoting is still on the todo list. The age of vertical scaling, owning one big computer and sitting at its console, is well into decline.
Wayland is essentially to effort to move responsibilities to different layers. Some things are pushed down to the kernel (memory management, command scheduling, mode setting) or similar infrastructure (OpenGL, udev). Some things are pushed upwards to the clients (font rendering, window decorations, vector drawing, remote access). This means Wayland has much less to do compared to X.org and that is a good thing, because it removes code duplication and unecessary complexity.
Even with cloud computing, all the rendering and half of the other processing is done client-side. Pushing pixels or low-level drawing commands over the network is not the way technology is heading.
Oh, it's a trend? How often is scientific computing about pixels anyway? I'm willing to bet not very often. Most of the time the results are a bunch of digits, a few matrices at most - a configuration, a solution to a problem.
Cloud gaming can't work on the Internet as it currently exists. Latency is just too high and too variable, especially for consumer-grade connections when they get near saturation. When bufferbloat is a thing of the past, it might be possible.
However, even smartphones are coming with highly capable GPUs these days, so within a few years, any CPU no matter how cheap will be able to handle at least casual gaming at HD resolutions.
Having a release people can start using now to test their apps against and write new apps for is the most important next step for them.
Remoting isn't as important when you have options like VNC to fall back on. Its a minor inconvenience at the most and I believe the've made the right call to ship something usable now.
How could any unix user conceive that remoting is not important. 99% of the gui I launch are remote. In fact I do not even know where are half the workstation I use.
Regularly, I have to give support to portugal or italia, they open a internet connection, so that I can log on their system. With a simple ssh -Y, I can perform all the investigations I need.
What X needed was to slim down. That's something I can get behind. But the Wayland folks went too far, and the rationale seems to have been "because this is our first real opportunity to break from X"... in other words, because they could. What we needed was an X12, not something different for the sake of being different: evolution, not revolution.
I personally find vnc or NoMachine NX better than X sharing. The main reason for this is that my programs don't quit if my connection goes down. While I do hope for a good remoting system, I'm not sure that 'ssh -Y' is the best way to do it any more.
ssh works out of the box everywhere. I can be connected on as many hosts as I want, launch any graphical application, anywhere and they just display correctly. I can not imagine launching a different X server almost for each application I am running. I have a single X server and often tenth of clients running on three of four different hosts. And when I have to access an "external site", I just phone them, so that they "open" the connection, then I do my ssh -Y and I can launch many GUI running on all their hosts to investigate their issues.
I have NoMachine NX on my home computer. It is very useful, but it is far more heavy weight than a simple ssh with X11 forwarding.
1.0 means a different thing to developers than it does to consumers. API backwards-compatibility is a very important thing, and calling this 1.0 is a signal to developers that it's safe to start building things on top of Wayland that should keep running without modifications for a very long time.
Perhaps they figure VNC and SSH do enough of the job for most people. Certainly works for me... I can't remember the last time I needed more than ssh to work on some remote machine.
X protocol remoting is almost never what you want; with the client / server relationship swapped, all[1] the apps that you're running die once you disconnect. If you assume unreliable networking - not rare at all in many remote work scenarios - it's a recipe for frustration.
Please don't tell me what I "almost never want", considering it's a feature that I do use all the time. My LAN is quite reliable and fast, thanks very much.
Probably should have been "almost never what one wants," but that's quibbling over English. Even if it were true that there were no mechanism for doing remoting on Wayland (which isn't the case; remoting just moves to a separate layer in the stack, as handled by NX or VNC or whatever), it would still be a reasonable sacrifice, because it's not what most users want. Doing X remoting is the exception, not the rule, and there's no reason for the *nix world to get stuck in the Windows mentality of having to be backwards-compatible with every application and protocol written since the dawn of time. Having a huge networking layer shoved into the middle of the display stack has measurable costs in terms of both maintainability and performance, and users that have any use case other than yours suffer as a result. Android, which is now the most-installed Linux "distribution" (such as it is) ever, had to invent its own display layer because X was a terrifying, bloated hacktastrophe, and they come up with something specific to their platform such that now no other Linux users can benefit from any of their display work. That sucks. Keeping network transparency as a core feature doesn't pass the cost-benefit smell test.
Well, having spend all my day on an Xterminal, I think you are stuck in Windows mentality. Unix mentality is network transparency. Just inform you about plan9. In unix, you do not care where your program is running, it just runs and you can interact with it on your X server. VNC is windows mentality and it just happen to be useful on unix because X toolkit layers are network hogs.
I haven't owned or operated a Windows machine in almost a decade, and have ten terminal tabs open as we speak; pretty sure my Unix cred is intact, thanks. And I thought the Unix philosophy was to do one thing and do it well (Wikipedia agrees: http://en.wikipedia.org/wiki/Unix_way#McIlroy:_A_Quarter_Cen... ). Separating the thing that paints the screen from the thing that pushes pixels over the network seems in perfect keeping with this philosophy. Bash isn't network-transparent; if you want to use it over a network, you use SSH.
Bash is network transparent: you change directory in a nfs filesystem or in a curlftpfs the same way as on a local disk.
X separates the thing that paints the screen (the X server) from the things that computes (the X client).
Your idea or pushing pixels means that you need a virtual screen on the machine where programs runs and you want to copy this virtual screen to your screen. Do you imagine the complexity of window management with such a setup ? Have you already launched many VNC clients at the same time ?
X over SSH in my experience is much harder to configure, and slower
Some people claim it depends on adequately configuring X, which may be true, but it's much easier to configure VNC over SSH to have an acceptable performance
I think the main argument for remote X is that it is so easy to use between 2 true X11 environments. You just `ssh -X` to your target and start running programs.
On Windows or OSX though... If you were going to install X11 why not skip it and just install VNC?
I kind of disagree. The entire point of Wayland is to remove deprecated, crufty stuff to make a new form of display server. Remoting (in its current form) was on the list of stuff to remove.
If you need remoting, for probably a fairly long way into the future, X11 will still be supported and you can use that. If you want the new shininess of Wayland, sorry, you have to live without remote capabilities.
What is so wrong with X? I understand that it is a mess and the developers have to work hard to add new features to it. But as a user of X I virtually have no problems.
For the future Wayland might be the correct way forward but I do not see any short term gain for the users.
1. Development of X is slow. Like "the kernel supports switching between gpus flawlessly but X needs a restart"-slow. Users notice this (though I don't know the current situation of this issue).
2. X-window-managers have awful performance compared to Windows. Try dragging a window around in IceWM or every other Linux desktop. It looks like hell, flickering borders and such. Though I remember a interview with the developer who did the first push for a new scheduler before cfq as he quit kernel-development who tried to tune the kernel for this, so this hasn't to be X fault.
Just found it, Con Kolivas and http://apcmag.com/interview_with_con_kolivas_part_1_computin...
Point is: The desktop of Linux is slow and maybe Wayland will help.
3. (It is always more) That it is a mess to develop for X (and it is) leads to bugs user will notice.
Some people complain about bloat and bad compositing performance under X, but my real problem with X is that it's very insecure. Any program running on a given X server can see any keyboard input to any other program running on the same server by default. As it stands, there's not a practical solution to this.
The Qubes project is interesting in some ways, but I think they're trying to do too much in one go, and as a result the final product doesn't seem very practical. For example, applications can't use hardware accelerated video according to their FAQ [1].
So pardon me while I braindump...
It would be an interesting project to integrate an Android-style permissions permissions system(possibly using SELinux) complete with per-application virtual filesystems (using FUSE) into the system package manager. So, for example, you install a music player, the package manager sets up a virtual filesystem for it that lets the program see its own configuration directory and your music directory, but nothing else. The package manager asks if you'd like to allow network permissions to the music player (for downloading album art or whatever); if yes, a firewall rule is added specifically allowing that process to access the network, if not, none is.
One problem with that kind of system is that a lot of end-user desktop programs are written with the assumption that the entire home directory is fair game. I'm not convinced that's really necessary, though. In case a program occasionally wants to access a file outside of its normal sandbox (say, you just downloaded a podcast into your downloads directory and want to play it with that music player I mentioned previously) you could always have the supervising program ask the user if it's okay to temporarily add that file to the program's sandbox. If it happens in an expected way (e.g. the user clicks on a media file in the file manager) you could safely grant access to the file without explicitly asking the user.
Something like that, on a distro using Wayland as the windowing system (to avoid the gaping security holes in X), would provide 90% of the security that Qubes does with significantly less inconvenience to the user. It would still require a good deal of work for the package maintainers, but perhaps a distro like that could implement something like the AUR [2] so users could do a lot of the packaging work for peripheral packages.
How do you think client-side window decorations impacts this? It seems to me that it would be difficult or impossible to create a secure GUI if every application gets such complete control over user interaction.
