Update On Wayland and X11 Support 315
Phoronix was at the Linux Foundation Collaboration
Summit and has two articles on the status of Wayland and X11
integration. The second talk was about the current
status of Wayland, and its impending release (version 1.0 is due
this summer). The developers also have an experimental GNOME-Shell
working on Wayland. There's a (kind of shaky) video of this
talk (attached, and at youtube for those wanting the html5
version). The first talk (by Keith Packard) covered X11
support on Wayland. It's basically ready to go, but window
management is implemented only as a hack right now. The next year
could be quite exciting for GNU/Linux and BSD users as distributions
begin including Wayland as an alternative to X.org.
Why? (Score:3)
Someone enlighten me, why Wayland?
Re:Why? (Score:5, Informative)
IIRC X11 has a lot of redundancy with stuff that's already in the Linux kernel. Weyland is a compositing window manager that removes those redundancies for better performance and code maintainability. Weyland loads X11 legacy support only as needed on an app by app basis. Benefits include Compiz working much better by bypassing X.
Re:Why? (Score:5, Funny)
Re: (Score:2, Insightful)
I did read it and basically understood it, but agree entirely they are writing like a bunch of arrogant nerds trying to look brilliant. I've lunched with a fair number of Nobel Laureates over the years -- my take away point from those hours is this -- really smart people understand the importance of starting with a simple explanation.
Re: (Score:3)
Re: (Score:3, Insightful)
No, it *is* for us.
It is for us to muck around endlessly trying to make the &^%$#@ thing work. Just like Pulseaudio.
The arrogant tone of your answer leads me to believe that you are part of the problem^H^H^H project.
Re:Why? (Score:5, Funny)
Benefits include Compiz working much better by bypassing X.
Those who would surrender basic functionality for eye candy deserve neither.
Re: (Score:2)
By your logic we should be happy with TWM and a bunch of X Terminals. Anything beyond that is purely eye candy, of course. Especially any sort of OpenGL, which doesn't work over the network.
Re:Why? (Score:4, Informative)
You are correct - anything else IS eye candy. And many of us ARE happy with TWM and X Terminals - because those are the tools we need to do our jobs.
Re: (Score:2)
Good luck running any modern CAD system without hardware accelerated 3D. X terminals are useless for much of 3D CAD work. The services available on X screens don't offer even the most basic primitives needed to efficiently draw 3D content. To draw quite rudimentary 3D stuff you at least need 2D triangles with interpolated color (gradients). You'd think XRender would offer that, but sadly it doesn't. Never mind Z buffering, texture mapping on triangles, etc.
Re: (Score:2)
Modern X servers support accelerated 3D just fine.
There are even multiple ways to implement it, with 3D being implemented either local to application or local to the display.
Re: (Score:2)
3D local to the application is otherwise known as VNC. Render however and whatever, then ship the bitmap to the screen. You don't need any of X infrastructure for that. Even if you ignore the overhead of shipping the bitmap, there's still the overhead of getting the stuff rendered by the local GPU from its memory to main RAM. Such overhead is not present when the GPU renders directly to the framebuffer.
3D local to the display requires that the display and the application (X server and client) are on the sam
It was working in 2000, why not 2012? (Score:4, Informative)
My desktop machine at work now is getting a bit old so I'm actually posting this using firefox on a fairly fast cluster node via X. While that's not 3D some of the geophysics stuff my co-workers use involves a lot of 3D content, and I've played with Blender on some nodes during setup to see how they handle it. That's with Nvidia's accelerated driver in nearly every case.
By the way, what's the "modern CAD system"? I'm only familiar with the old stuff (I'm putting the most recent AutoCAD in that category since it hasn't really changed in years and is low end anyway) so you may have a point I'm not aware of.
Re: (Score:2)
con't confuse 'better' with 'uses lots of new libraries and is so kewl!'
I've lived decades (literally) without desktop clutter. clutter in processes, in screen RE, in library dependance and complex building procedures. you kind of have to have a desktop on the commercial OSs like win and mac, but on linux, you can live really well without any desktop at all. I'm not talking about server mode, either; but a user having a display, mouse and doing local things on it but just not incurring the overhead of wh
Re: (Score:2)
The day I can't have a simple system is the day I stop using this. It absolutely sickens me what the major distros are doing these days. That's not "freedom"
The day I can't run a kernel, a minimal set of daemons, a shell, an X11 window manager started only when I choose to, and a bunch of scripts that tie it all together is the day I might as well just use Windows.
I already have to keep that around to boot into for my games anyway, since development of Linux ports has lost momentum. The last good game I bou
Re:Why? (Score:4, Interesting)
Wayland is actually simpler than X. That being said, I think it will be a very very long time, like a generation minimum, till X.org doesn't have an X for Linux. As far as games Wayland is a pure advantage.
Re:Why? (Score:4, Interesting)
you've just described me. I run fvwm 1.4 and I open a term window (whatever is the current default from the distro I have) and I run things. env DISPLAY has stuff and if I run an X app, a window comes up. the window mgr lets me move windows and iconify them. what the hell else do you want/need?
I believe in things being as lean as possible and having to prove or justify any excess. since the old DECwindows days, I've run essentially the same style of window mgr and 'xterms' work basically the same as they did 30yrs ago. you type in them, you can mouse in/out of them, you can scroll them. the paradigm has not changed, really, at all, in all these years.
I cannot justify a 'desktop'. I run a window mgr and windows come up as terms or apps and that's that. runs very fast and bug-free and stays up for months (and years) at a time.
I don't quite get the need to have to add complexity to what does not need it.
(oblig GOML)
Re: (Score:3, Informative)
I believe in things being as lean as possible and having to prove or justify any excess
This is pretty much the reason *for* Wayland -- whether you use Xorg or Wayland you have support for all the excess eyecandy (not that you have to use it), but Xorg is an exponentially growing pile of add-ons while Wayland has the features planned from day one, plus it's even smaller than that, because it lets the kernel do the heavy lifting of driver support.
Re:Why? (Score:4, Informative)
Especially any sort of OpenGL, which doesn't work over the network.
Wrong! OpenGL works over the network, in fact it was designed to.
Re: (Score:3)
The above is completely wrong.
Re: (Score:2)
Oh yes, it is!
Re:Why? (Score:5, Informative)
Because I used it for five years to run VariCAD on a server with no local video acceleration, displaying on client with Nvidia card, both running Debian.
Re: (Score:2)
Re: (Score:2)
Could you elaborate on what the basic functionality being surrendered is?
Re:Why? (Score:4, Insightful)
... Compiz ...
Those who would surrender basic functionality for eye candy deserve neither.
Compiz is pretty damn usable, with both XFCE and Gnome2. I guess you're thinking about Gnome3.
For example, on ancient machines with a semi-decent graphics card, Compiz with superfluous eyecandy turned off runs circles around regular window managers, because windows don't have to be repainted over and over every time you switch windows and/or desktops. You can see the contents, read something, focus your eyes, move the mouse to whatever you want to click, etc, giving the program inside a couple of seconds to swap itself in/etc, making you not even notice that the system is thrashing. On a regular window manager, you'll instead see an empty broken window.
Re:Why? (Score:5, Insightful)
Downsides include not having any kind of network transparency or remote desktop support. Even supporting something like VNC on top of it would require a lot of internal changes and probably kernel-level support code too, and the developers basically consider this Someone Else's Problem.
Compatability mode (Score:4, Insightful)
My understanding is Wayland is not ready for prime-time just yet, but when distros start using it will have X11 legacy support to handle stuff like this.
By putting a 1.0 out there they are telling developers of X11 apps to start planning/testing/adapting.
Re: (Score:3)
The way how OS X and Windows "support" X11, I wouldn't wish on anything to be supported anywhere.
Re: (Score:3, Insightful)
VNC is going to work the same way it does with Windows or MacOSX which doesn't involve low level support. VNC is an alternative to Network transparency.
Excrement is an alternative to food. Gotcha.
The only redeemable thing about VNC is that it's better than nothing. That's a pitifully low bar. VNC is marginally better than having somebody take a picture of their screen with their camera, and text message it to you.
VNC has a horrible user experience, it's horrifically slow, and universally ugly - the only way to get it to "work" even half-reasonably is to compress the bitmaps so severely that the artifacts make text illegible.
If you increase the bandwidth us
Re:Why? (Score:5, Informative)
As I understand it, X11 is horribly out of date.
It should be clear to anyone that there are some stone-age omissions in X:
- Basic transparency is either an ugly hack that glitches all the time (xcompmgr) or else a fairly extravagant system like compiz.
- Smooth fonts is an extra.
- Multiple displays is an extra.
- There are serious security flaws in areas such as screen locking. See this great series of points [jwz.org] by the author of xscreensaver.
Then, there's all this support for legacy technologies that don't affect 90% of Linux/BSD systems, let alone the potential general market.
All in all, X11 has fundamental weaknesses, doesn't reflect modern usage and is really too big to fix. Legacy support and compatibility are so important that problems can't be fixed.
I haven't been following Wayland too closely, but my understanding is that it will address these issues as fundamentals of the system. I hope it does address each of these issues, because they are important. Performance could certainly improve on X. Let's hope it does with Wayland.
I'm not that familiar with how display servers work either, so correct me if I'm wrong about anything. No need to rage, I'm not trollling anyone.
My prediction is that it will become fashionable to whine about Wayland, lots of people will resist it for a while, but in the end it will be the most suitable alternative and only the truly stubborn and those who need X for some reason will avoid it. See the history of PulseAudio for reference.
Sorry about the identical AC post below. I forgot to sign in.
Re:Why? (Score:5, Insightful)
Congratulation, you are severely misinformed, and everything you said is wrong.
X11 has a lot of cruft that is no longer used because it was moved to different layers -- for example, it supports display-side (server-side in X terminology) bitmap font rendering while modern toolkits use application-side (client-side for X) rendering that implements antialiased fonts. While this is a design flaw, the solution is to either not to use the old system (what all modern software already does) or add a new font rendering system if it is warranted (what may be a good idea but hardly a priority for anything). Same applies to most of X cruft.
Separately from anything stands X protocol with its excessive "chattiness". But all "alternatives to X" propose to drop the protocol completely and instead use direct function calls -- the chattiest thing that was ever created! After such a change, it would be impossible to add any remote functionality other than crude "hey, I am drew something, let's update the whole bitmap, and oh, compositing is already applied using MY screen layout!" mechanism. It's a huge step back.
Re:Why? (Score:5, Informative)
No, wayland uses a socket to communicate between the client and the compositor. It is not function calls. Many calls to the client library can be (and are) consolidated into a single block message sent to the compositor. Wayland was designed for this, by avoiding return values from the calls, so they can be asynchronous (this is where Windows fails badly, and Xlib (though not X itself) also did in many cases, because they failed to realize that some calls they thought would be rarely used and thus ok to stick a return value on are used extensively).
Re: (Score:3)
So if they don't re-invent not only the wheel, but the drive shaft as well, you won't be satisfied?
It doesn't really matter how they implement it as long as it works. There are good engineering practices. This feature-stripping and breaking existing use models isn't one of them.
Wait, so you missed the part where they're working to run X within Wayland so that you can still run your X applications if you'd like and still be able to use your X11 forwarding if you so pleased?
I don't care about X applications per se. I care about making it impossible to produce an application that will not work remotely. With X11 I have this -- anything that works locally will also work across the network as long as latency is reasonable for its use. With "oh, we will support X11 because we heard, someone wrote X11 ser
Re: (Score:2, Troll)
Then use TWM. Or hush and go use your dusty old Mac. Some people want eyecandy and the ability to have a dynamic desktop without feeding money into Apple's DRM-happy coffers.
Re: (Score:2, Insightful)
Then step the fuck up and maintain X11 and the X11 compatibility layers for the toolkits that are out there. Don't tell other people they can't move on to newer things because it would inconvenience your lazy ass.
Good luck moving on when the hardware manufacturers that matter have already said they have no plans to support Wayland. Oh and good luck bringing people in with this attitude.
Re: (Score:2, Funny)
Unixen
Germanic plural for Unix?
I am very much in favour of this.
Re: (Score:3)
Wayland offers X11 support, Linux post Wayland will be when it switches roughly as interoperable as it is now. The problem will be in the other direction as apps start to migrate to Wayland.
The conspiracy aspect (Score:2)
Giving it a conspiracy look, one might interpret it as an attempt of the unwashed hordes trying to take over Linux. Instead of going the sane unix-like route of moving graphics into virtual filesystems, like it's done on Plan9, they want to essentially replicate X11, but without its good parts. Wayland is not network transparent. It still needs libraries to be linked with your software. What you get is a bit more gimicky graphics, but you loose a lot of important features.
It's perhaps not quite as bad as th
Re: (Score:2)
Don't copy-paste other posts, especially ones that are completely wrong.
Re: (Score:3)
You are an idiot.
"Seamless blending" is the part that works "perfectly" in X already. The problem is with configurations that treat multiple monitors as separate screens, or combine incompatible hardware each with its own proprietary drivers. X users simply have higher demands and longer history of sophisticated multi-monitor suppport than Windows users.
Wayland vs X (Score:4, Interesting)
Re: (Score:3)
I can't deal with the lack of network transparency. Sure, you can run X on top of Wayland for now, but once people start writing Wayland only apps that's not going to be a viable way to work anymore.
Here's hoping Wayland flops.
Re:Wayland vs X (Score:5, Interesting)
This.
Network transparency is huge -- I often need to run graphical installers for commercial software, or run graphical diagnostic software, on systems that live in my machine room, and have fairly basic video cards, and in any case don't routinely have graphical displays attached.
The really-right answer to this, of course, is to separate the display from the the installer and/or diagnostic executable, and connect over a network socket or something, but in practice this doesn't happen. In practice, I connect via SSH with the X session forwarded, and run the graphical app that way.
The loss of network transparency makes remote access much more complicated. It's not lethal, there are things you can do with remote desktop viewers that work, but you end up hacking together a rickety, insecure new solution to what used to be a solved problem -- it really doesn't feel like progress.
Re: (Score:3)
The loss of network transparency makes remote access much more complicated. It's not lethal, there are things you can do with remote desktop viewers that work, but you end up hacking together a rickety, insecure new solution to what used to be a solved problem -- it really doesn't feel like progress.
I don't think running a VNC server bound to 127.0.0.1 with port forwarded through a ssh tunnel (ssh -L5900:localhost:5900) is much more complicated neither insecure.
Re: (Score:3)
As I understand it, you can't run Wayland at all without having a recent GPU that supports it right now because it relies on hardware OpenGL support in order to actually be able to send graphics from the Wayland applications to the compositor. So VNC is probably a no-go too.
Re: (Score:2)
Really? That's not any more complicated than 'ssh -X'? It works anywhere and everywhere, without any additional software.
Re:Wayland vs X (Score:4, Informative)
Is this a joke? Here are some of the missing steps in the VNC "solution":
Re: (Score:2)
I work remotely almost all the time, and I routinely access remote systems in all the normal ways (VNC, remote X, RDS, etc.)
> Starting the VNC server, with all the right arguments, on the remote end
$ vncserver -geometry WxH
> Making sure applications on the remote end will display on the VNC server (e.g. setting your DISPLAY variable)
VNC servers are pretty good about starting GNOME (or whatever) sessions; $DISPLAY is set correctly by default.
> Starting the VNC client on the local end, with all the r
Re: (Score:2)
Right.. Get back to me when I can do this with VNC:
1. Run matlab -nodesktop in screen on remote server
2. Let it run some calculations for a few days or so
3. Connect with ssh -X and set the DISPLAY variable
4. Plot the results
I can with X11 network transparency.. VNC is all or nothing - either I connect to an entire desktop session and waste bandwidth on sending pictures of a bunch of characters or I don't get any graphics at all.
Re: (Score:2, Insightful)
The network transparency argument is a CANARD. X *is already crappy at network transparency*. Try using X over even a decent broadband connection and prepare for agony. Oh.. try running a GUI application remoted over X on one device like your PC and then ship the same application over to your cellphone or notebook without having to close & restart the application.. YOU CAN'T. Just because Wayland is primarily directed to actually letting Linux take advantage of modern GPU hardware does not mean that
Re: (Score:3)
"Try using X over even a decent broadband connection and prepare for agony"
I do it often , never had a problem. Hell , I even used to run xterms over a modem link FFS!
"he same application over to your cellphone or notebook without having to close & restart the application"
Not a problem if the application is written to support it. There's no limit to the number of X servers an app can link to at any given time.
"Why does NX even exist if X is already perfect???"
No one is claiming X is perfect - but why wo
Re: (Score:2)
I think a better solution would be for commercial software developers to stop assuming every system you install their software on has a graphical display available.
It's even more insulting when you're installing a command line application, and the installer is graphical. WTF? And many times it's implemented in a very bloated manner, with a JVM that takes 30-40 seconds to start.
CLI based installers are the best. Not to mention they're likely a lot easier to write. The best of both worlds, yet commercial deve
Loss of network transparencey (Score:2)
Its more than more complex, its makes the entire thing totally useless and a REAL bad idea.
Great if they want to clean things up, but to go a completely different direction at this stage of the game is ludicrous.
X works. Don't break it.
Re: (Score:2)
Network transparency is huge -- I often need to run graphical installers for commercial software, or run graphical diagnostic software, on systems that live in my machine room, and have fairly basic video cards, and in any case don't routinely have graphical displays attached.
I can run an X server on Windows and do this using Putty just as I can under Linux while running X 'natively'. I don't see how this would be a real problem.
On the other hand, Wayland will make Linux desktop use more capable. It'll be faster, and being able to do something like RDP will be more tenable. Additionally, Wayland is better suited to serve as a general display manager for all ranges of Linux, not just the desktop - this is something which X fails at due to its size and complexity, neither of which
Re: (Score:2)
Those programs work the way they do becuase X11 is what it is. If there where no network transparancy the installer would probably be comandline. Likewise diagnosicsprograms would probably be better by using a simple webserver and serve to your browser. No change comes with zero flaws, but in the end X11 network transparency is used only by a few (I have definitely used it also for these examples so I know whar you are saying). But I can live without it, and X isn't really going away in 5 minutes anyway, th
Re: (Score:3)
Wayland developers have done a poor job of communicating their intentions regarding network transparency. They need to communicate a clear and credible plan that does not attempt to push the problem off to somebody else's project. The plan must not rely on application or per-desktop transparency, but transparency at a common layer that all graphical applications use. And the plan must be executed, mature and reliable before Ubuntu makes the mistake yet again of pushing out something new and shiny before it
Re: (Score:3)
Don't you prefer VNC? Every time I had to run a graphical application remotely I first tried through X but ended up using VNC.
Btw, last week I tried to run firefox from a remote machine (ssh -X) and it seemed to have opened a new instance of the local running firefox (I'm not really sure, I was just trying to do something quickly and didn't have time to verify wtf happened)... if that was the case, was that the expected behavior?
Re: (Score:2)
firefox --no-remote will open a new instance. use -ProfileManager if the existing profile gives you probs. Handy for double login on the same webapp.
Back to topic, the trend is the dumbing down of the PC. Not the interface. the PC as a whole. Wayland is handy to further that objective, so it will be a success even if it kinda sucks. Or so my model of the universe predicts.
Re:We're NOT talking (Score:4, Insightful)
Remote Desktop on Windows seems to be somewhat more intelligent then just "screen scraping".
Similarly, VNC on Linux can be like this.
But by far the best solution I've encountered is x2go, which is based on NX, which notably just caches and removes some of the overhead of straight networked X.
Surely, the better answer here would be to tackle that problem - implement a well behaved network protocol.
Re: (Score:2)
Re:We're NOT talking (Score:4, Informative)
Re: (Score:3)
No you can't. You need the X11 client installed to talk the X protocol. You don't need to be running a desktop (X11 server) but you absolutely need X11.
Re: (Score:3)
Sure, you can run X on top of Wayland for now, but once people start writing Wayland only apps that's not going to be a viable way to work anymore.
Hardly anybody is writing X apps and hardly anybody will be writing Wayland apps, instead people will continue to write Gtk+, QT, HTML or SDL applications and network transparency can happen somewhere between those and Wayland.
Also network transparency in X sucks. It's far to slow, cumbersome and inflexible for todays world. It works ok in simple situations where you have dedicated X terminals with a limited set of apps, it doesn't work for situation where you might want to move a videoplayer or game from y
Re: (Score:2)
There's no reason why the networking protocol needs to be built into the display server, and no reason why a display server that does not have its own networking protocol has to do without network transparency. From what I've seen, Wayland is flexible enough to allow for networking in multiple ways.
Re: (Score:3)
If it's provided by the display server, you get network transparency for free. If you expect application developers to implement network transparency, it's going to be spotty at best. If you use 3rd party tools it doesn't integrate well at all.
We don't need several crappy ways to run apps over the network. We need one that "just works".
Re: (Score:2)
X11 doesn't give you network transparency for free, it does it at the cost of being a crummy and overly complex set of ancient technologies that no one uses any more. And the network transparency itself is based on how a window system was expected to work 20 years ago, meaning it's extremely inefficient with modern applications (GTK, Qt, etc.). Ever tried running Firefox across a LAN with X11? It's not a pleasant experience. Perhaps NX improves it. Sticking with X11 simply because it has one outstanding fea
Re: (Score:2)
GTK and Qt don't and never will have any network transparency on their own -- they use X for this purpose, and it works JUST FINE. If any project will replace X, it will also have to replicate network transparency provided by it, and no, "let's copy bitmaps of a virtual screen" won't cut it, applications must obey window management on the user's box, and should not produce more network traffic than notoriously "chatty" X.
Re: (Score:3)
Yes, and mplayer offers two solutions to display video on VT100.
Re:Wayland vs X (Score:5, Insightful)
Okay so I understand the whole desire to toss out X and it's extreme amount of legacy code
Why? What part of "legacy code" automatically means "toss [it] out"? The Linux kernel is over 20 years old, and the core BSD code is older than that. Do you also want to just throw them out and start over from scratch because they're old? Now, I agree with you that something that is less functional than its predecessor should not be adopted as its replacement, but I hate the assumption that "old == replace from scratch" that seems to be common in software development (especially in the open source/free software community).
I have tools in my toolbox that belonged to my grandfather, and my father has tools from his grandfather (100+ years old). We still use them because they work. We have other tools that we've bought to perform other tasks, but the old tools are not replaced just because they are old.
Re: (Score:3)
Re:Wayland vs X (Score:5, Insightful)
X was designed for how video cards worked and what they could do decades ago. Support for newer features is hacked on. The kernel may be 20 years old, but the video drivers have been changing all the time. Wayland is targeted at modern hardware, and aims to be simpler to use and perform better.
Re: (Score:2)
Why can't we do this without losing important features? Features that actually do something useful instead of just look pretty?
Re: (Score:3)
Re:Wayland vs X (Score:5, Insightful)
What you don't understand is that Linux might be 20 years old, but what you call "Linux" today is almost incomprehensible compared to the original Linux other than both being mostly UNIX-like. The same cannot be said of X which is still adhering to a basic protocol that is over 20 years old and was designed long before anything that remotely resembles a modern GPU had come into existence. That's why large portions of the X server are *already being bypassed* by modern programs to give you halfway decent performance. Did you know that the large majority of graphically intensive applications (like everything using Cairo) are basically just shoving bitmap images across the X server now instead of trying to use the ancient and convoluted drawing commands that were cool in the 1980's but haven't been useful in a long time? X needs to go away.
Oh... and don't get me started about network transparency either. X's network transparency SUCKS over anything other than a gigabit LAN *and* you can't disconnect from X and resume the same GUI application on another device like any decent remote GUI system should allow (e.g. why the hell can't I start a remote GUI program on my PC then shift the same program it to my smartphone and keep working on it? The reason is that X's network protocol is *not* the be-all end-all that many people think it is). If X's network transparency was so awesome then NX would never have come into existence.
Re: (Score:3)
I think that when people talk about "legacy code", the word "legacy" isn't just supposed to mean "old", but also, "outdated or poorly written". The concept is that old programs may have been written to support hardware or situations that don't exist anymore, or else were anticipated to exist when the software was written but never materialized. Or they have features/functions that never really worked as hoped, or were not properly written or optimized at the time. This "legacy" code isn't necessarily ima
Re:Wayland vs X (Score:5, Insightful)
He didn't say everything that's legacy should "automatically" be thrown out. But X has a huge amount of cruft nobody uses anymore. Nobody actually writes towards Xlib, they use a toolkit. Nobody uses the orignal font functionality and descriptors, the bitmap fonts, the pixel-based rendering primitives, the image system that has no less than three different ways of storing an image (ximage, xpixbuf, xpixmap), that distinguish drawable and non-drawable images, depending on where they're stored. Et cetera. It's not thread-safe either.
Nobody is using the core X functionality, it's all outdated and largely replaced. The one redeeming feature of X - the network transparency, isn't that 'transparent' (again, the API distinguishes server-side and client-side stuff). Nor does it support modern stuff like drag-and-drop, and cut-and-paste has always been inconsistent (highlight-middle-click not being the same as the desktop or application's cut-and-paste buffer). Since nobody's using the core libraries anymore, the network transparency in X mostly consists of it passing events and bitmaps back and forth, something a simpler protocol like VNC can do just as well if not better.
In short, people don't need any of the things that are unique to X, and the things people actually use X for can be done better without it. It's a big load of cruft that exists for backwards-compatibility purposes only. Which is why it's entirely the correct decision to dump X11 and relegate X11 support to a compatbility library, so we don't need to have stuff held back and complicated by these legacy designs.
Re:Wayland vs X (Score:4, Insightful)
Okay so I understand the whole desire to toss out X and it's extreme amount of legacy code
Why? What part of "legacy code" automatically means "toss [it] out"? The Linux kernel is over 20 years old, and the core BSD code is older than that. Do you also want to just throw them out and start over from scratch because they're old? Now, I agree with you that something that is less functional than its predecessor should not be adopted as its replacement, but I hate the assumption that "old == replace from scratch" that seems to be common in software development (especially in the open source/free software community).
Yep, it's what jwz called Cascade of Attention-Deficit Teenagers [jwz.org] development model. And it's not the whole F/OSS community -- this disease is specific to the Johnny-come-lately Linux community. It's the flip side of CatB, and it's not pretty -- I go back and forth on whether it's worth it all or not.
Re: (Score:2)
Wayland is a huge step backwards. (Score:4, Interesting)
To start with: the best wayland-related comment of all time appeared right here on slashdot:
http://tech.slashdot.org/comments.pl?sid=2699657&cid=39198273
Second, please note that all comments in this post are regarding unix or linux as a desktop operating system as opposed to HPC or server-based usage.
Now to move on: Currently the only wayland compositor implementation is weston. Weston requires kms, which makes it pragmatically linux-only, and it also requires udev, which makes it *actually* linux-only. To compound the problem, the developers are talking about integrating it with systemd. When asked how that will affect porting efforts, developer response was along the lines of "just port systemd to bsd."
Wayland is meant to replace x.org entirely, but it simply replaces the overcomplicated xorg ecosystem with an overcomplicated mess of build-time dependencies while removing all of the features that have kept x11 on top. To make the whole situation an absolute joke, x11 integration is regarded as the most important part of wayland's code.
Fedora and Ubuntu want to switch to Wayland entirely. This is another in a series of awful interface decisions that have lead to things like Linux Mint and Scientific Linux creeping up and taking userbase away from what have been powerhouses. What I can't figure out is why no overarching community has arisen among the 'conservative' linux users. There's clearly a lot of backlash to the ridiculous things going on at freedesktop.org -- xcb, wayland, systemd, journald, et al -- but there seems to be no alternative standards committee coalescing... and that will be the death of linux as an alternative for power users.
Re: (Score:2)
What I can't figure out is why no overarching community has arisen among the 'conservative' linux users
I see what you did there.
Re:Wayland is a huge step backwards. (Score:5, Insightful)
To start with: the best wayland-related comment of all time appeared right here on slashdot:
http://tech.slashdot.org/comments.pl?sid=2699657&cid=39198273 [slashdot.org]
Second, please note that all comments in this post are regarding unix or linux as a desktop operating system as opposed to HPC or server-based usage.
Now to move on: Currently the only wayland compositor implementation is weston. Weston requires kms, which makes it pragmatically linux-only, and it also requires udev, which makes it *actually* linux-only. To compound the problem, the developers are talking about integrating it with systemd. When asked how that will affect porting efforts, developer response was along the lines of "just port systemd to bsd."
This is a prime example of Linux developers doing "Embrace, extend, extinguish" on Unix. "We're dominant - let's lock everything down to our solution, and force anybody else to play catchup."
It may not be particularly intentional to damage other systems - having Linux blinders on, it's easy to see "All the world's a Linux machine", just like it used to be "All the world's a VAX" and "All the world's a Windows machine" - but it does the same kind of damage as if it was intentional.
Eivind.
Re: (Score:2)
So what? If you are using BSD, you are perfectly welcome to continue using X.org on it. Wayland in no way "damages" it, it merely aims to replace it on Linux. Are you seriously going to cry "embrace, extend, extinguish", just because Linux developers are not interested in porting their work to your BSD?
Re: (Score:3)
And who cares about that?, we are stillt talking about Open Source. if this helps make development faster by reusing more code It's certainly welcome. If *BSD users want this functionality, they can write a compatibility layer, the same way they did with ALSA, then they have the source code for Wayland available.
Otherwise, they are giving Wayand devs the burden of mantaining all the ports and even their own video drivers (like in X11)
"Do not tightly depend on Linux-specific features" and "maintain your own ports" are different. There's significant differences between writing reasonably portable code (which I think it is fine to ask for) and to fully deal with creating all kinds of infrastructure (which I don't think it is reasonable to ask for.) systemd is a seemingly OK solution to a problem that's been solved a number of different ways, with intentional direct Linux dependency, created by somebody (Lennart Poettering) that works for
Comment removed (Score:4, Interesting)
Comment removed (Score:5, Informative)
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Same as how X11 is "implemented" on Android. It's absolutely useless.
I have my Nokia N900 running X11-based Maemo for years -- with compositing, remote X, phone-friendly window management of remote and local applications, etc.
Re:I don't understand (Score:5, Informative)
In Wayland the client draws the window borders (and before you blurt out "but they will be different from each other and 'confuse the user'" be aware that nothing on X makes anything other than the window borders draw identically, but somehow there are all these applications where they draw their own scrollbars and buttons and text editors and they all look alike and fail to "confuse the user".)
X ICCCM window management was invented before there were shared libraries, so now there is a huge messy complex api built on top of the limited atom+value and signalling that existed in X11. Having written a toolkit (fltk) I can confirm that talking to the window manager literally takes 10 to 20 times as much code as if I drew the window borders myself. And we still have horrific problems where various window managers disagree on whether a window should vanish when the app loses focus and how "stay on top" should work, and we can't put the most trivial buttons or items in the window pulldown menu, something Windows allows and is making it increasingly difficult to port applications from Windows.
Wayland wisely has decided to scrap this mess by having the clients draw the borders.
Emulating X is trivial if you just work with the windows the X client knows about and repliate them on Wayland. The problem is that all that ICCCM stuff will need to be interpreted by something and draw window borders as well. It is not clear if this should be done by a local "act like xlib" library, or by a fake X server, or by an actual X11 window manager running on the fake X server. That's why window management is currently a "hack" because this has not been decided.
Giant Step Backwards (Score:5, Insightful)
One of the features that always distinguished X from other display systems like Mac and Windows has been network transparency. You can ssh to another Linux system, start an X application, and that X application will appear on the system you ssh'd from. This is immensely useful and evidence of a well-thought-out design, but it's an afterthought to Wayland. They say they might be able to render to a VNC server, but VNC works like crap and is full-desktop forwarding rather than individual window forwarding.
It's extremely ironic that when X was created in the 80s they recognized the importance of distributed systems and network transparency, but now it's 2012, the Internet and the cloud is king, yet network transparency isn't a core feature.
All this because you can't cross-fade when switching VTs in X or have a "rotating cube" animation [freedesktop.org] (see "Is wayland replacing the X server").
Re: (Score:2)
I don't understand how or why you think Wayland will prevent you from running X apps remotely. You can do this in Windows using Xming without a problem. What it might allow you to do is use the full desktop remotely without full bitmap transfer (ala RDP).
Re: (Score:2)
While IT professionals at work run X over a network all the time because they have a lot of computers to manage, it is something 99.999% of computer users never do. Home users don't even know what ssh is and even if they did, they'd have no reason to use it. If you are a sysadmin gloating over your domain displayed in a 100-window screen session, Wayland is obviously not for you. It's for the rest of us, who are perfectly willing to give up network transparency to get a lighter, faster windowing system.
Re: (Score:3)
"That feature is not a requirement for the GUI in my car or boat."
Who gives a shit about your car or boat? We're talking about desktops and servers , not some mickey mouse Busybox system in your toyota.
"Wayland gives them a way to composite multiple OpenGL apps without the overhead and legacy crap of X."
If all you want is something that draws straight to the framebuffer then there's nothing stopping you doing it yourself.
UGH. (Score:2)
Re: (Score:3)
No comment on whether either film is an apt metaphor for the projects themselves.
Quite exciting times ahead (Score:2)
That isn't the term i would use.
tl;dr? 60 FPS on an embedded GPU! (Score:5, Interesting)
Discussions of Wayland on Slashdot tend to be all about a lack of network forwarding or missing features, so I think I'll share some of the positive things I expect to see from Wayland:
I'm not aware of any X.org implementation that's gotten 60 FPS on an embedded GPU. That's not me trying to knock X.org, say anyone should stop using it, or say people need to "upgrade" to Wayland before it's feature-complete. That's me recognizing the reality of X.org not being "one size fits all" in a world where embedded or mobile Linux (think Android) outsells (and out-deploys) Linux on big core 10 or maybe 100-to-1.
Disclaimer: A big part of my job of performance optimization of applications on Linux running on mobile devices.
Re: (Score:2)
"A graphics stack that's fast enough to get 60 FPS scrolling on an embedded GPU"
If you want that sort of performance on a limited power device just write to the framebuffer directly. X doesn't have a monopoly on talking to the graphics hardware.
Re: (Score:3)
VNC or RDP does not replace the network transparency of X. it would just be a terrible kludge to get around lost core functionality.
Re: (Score:2)