Clearing Up Wayland FUD, Misconceptions 240
An anonymous reader writes "In clearing up common misconceptions about Wayland (e.g. it breaking compatibility with the Linux desktop and it not supporting remote desktops like X), Eric Griffith (a Linux developer) and Daniel Stone (a veteran X.Org developer) have written The Wayland Situation in which they clearly explain the facts about the shortcomings of X, the corrections made by Wayland, and the advantages to this alternative to Canonical's in-development Mir."
Remoting (Score:2, Interesting)
Better remoting than with X11? Seriously? I'm in!
Just recall to support authentication (certificates, kerberos, and/or ssh piping), and root windowless operation, and you will get every admin that works in corporate environments at least to test Wayland. If it manages to fulfill the promise on better reactivity (== better usability), Wayland will catch like wildfire.
Re: (Score:3, Interesting)
I really appreciate what Cnonical has done for Linux. I think they've helped push it to a much wider audience than it would have had otherwise ... but I'd liek to know why the hell they can't play nice with others and use/contribute to Wayland, KDE, Gnome, etc? They've come up with their own desktop, which is not bad, but now they're creating Mir instead of Wayland, and are apparently creating a new package manager as well. We'dget much better products out sooner if everyone worked towards the same goals.
Re:Remoting (Score:5, Insightful)
I've been a supporter of X11 for some time, but only as a user. I know how to use it, and it's more or less the same as it was ages ago. That heritage will be difficult to break, especially the network transparency it has (which some claim it doesn't really have if you're using DRI2 etc, but you don't have to use those).
However, I've read enough of these rants from both camps to start looking at this differently.
Back when X.org started, I was surprised that it became the norm so quickly. It did so because it worked, could be dropped in, and had some improvements.
AFAICT, Wayland isn't done yet. As a user, we're judging too early. Right now, they really only need to be convincing toolkit, driver, and X developers to get that development on board.
Once Wayland is drop-in usable with all common apps, it won't matter to the user except for how it performs in their various tasks. Once it gets to the point that, for example, a Ubuntu user could "sudo apt-get install wayland-somethingorother && dpkg-reconfigure somethingorother" to try it out, then we'll see if it lives up to the hype.
There are plenty of things it's saying it'll do that sound good. The parts that worry me from my naive perspective will be answered when it's usable, such as:
* apps having to do all the rendering. What about apps that don't do this now? Are we really going to force them through X, or will there be some middleware they can use, etc?
* the mini x server solution... there was a problem noted due to the change in coordinate systems. How will that be solved? What other problems may we run into? etc.
* the network transparency question. They haven't completed this yet. They may not ever do it (might be 3rd party). There's already some other attempts at this that show something can be done with it, but it's just not finalized yet. We just have to wait and see.
* remoting apps, and how that will relate to interoperability. Sounds like I'll be able to pull an X app up on my local Wayland desktop and have it displayed using the built in mini x server (maybe). What about the reverse? How do you export a Wayland app to a client that is only running X.org?
Seems to me that those are all solvable. Will the solutions pan out? well.. seems like those are still a work in (early) progress.
It's far enough now that there's no point in asking, "why do this?" or "why not fix X?" etc.. they're doing it, period. I'm done reading these things now, cause it's just a matter of "will it succeed?" (and it won't unless all the stuff people have been bitching about are solved, so who cares for now?)
Re:Remoting (Score:5, Interesting)
* apps having to do all the rendering. What about apps that don't do this now? Are we really going to force them through X, or will there be some middleware they can use, etc?
Apps can use the Cairo library to render. That is what most of them are doing now anyway, since that is the only practical way to get antialiased lines and scalable images on X.
* the mini x server solution... there was a problem noted due to the change in coordinate systems. How will that be solved? What other problems may we run into? etc.
The problem was not really described correctly. The Wayland developers have this idea that applications should not know what their window positions are (I don't agree with this btw). X applications when they do the X api to figure out the window position are told it is at 0,0. On X an application wanting to make a popup menu not go off the screen, compared it's window position to the screen position, and thus knew where to place the menu (on Wayland the client says what position it wants the menu in (relative to it's window) and is told how it will be clipped, so the client can try another position). This means some errors with the popup of menus in X applications.
I was under the impression that they "fixed" this by allowing the X emulation to get at the secret information about where the window is. I complained on the mailing list that this means that X clients have a special privledge and they really should allow regular clients to get this secret info, but was ignored.
* the network transparency question. They haven't completed this yet. They may not ever do it (might be 3rd party). There's already some other attempts at this that show something can be done with it, but it's just not finalized yet. We just have to wait and see.
* remoting apps, and how that will relate to interoperability. Sounds like I'll be able to pull an X app up on my local Wayland desktop and have it displayed using the built in mini x server (maybe). What about the reverse? How do you export a Wayland app to a client that is only running X.org?
It looks like they are planning to use per-window RDP. This makes sense because the api and remote clients already exist, and you would run an X RDP client to display the Wayland windows.
Re: (Score:2)
It's called Firefox, IE, Opera, Chrome, Webkit for the remoting aspect. That's one of the reasons Wayland isn't investing effort into duplicating functionality that's in X11. It's no longer needed. Better options exist such as RDP or even god forbid "Cloud Apps" as were seeing alot more of.
What I'm hoping is that they reach the point that the 2d-3d performance allows me to handle any DX9+ game in Wine at max monitor speed (50-60 fps) as I'm using an LCD. I don't game much but I'd love to have the ability t
Sounds like it's still "all pixels" (Score:4, Interesting)
Each application does its own rendering? 31-bit pixel counter?
This sounds like it's all pixels, like X, rather than geometry, like NeWS or display postscript.
So if I have monitors with high resolution I still have to tell all the applications to change their size, individually, or use a microscope to read the text, right?
If I stretch a window (intending to scale it, rather than just see more of what it shows) it has to go back to the application for re-rendering, right?
And if I have adjacent monitors with different resolutions they won't match up. Heaven help me if I lay a window across the boundary between two, the T between 3, or the + between four. Right?
Or have I missed something?
Re:Sounds like it's still "all pixels" (Score:4, Insightful)
You're using a modern toolkit, one that scales depending on the DPI reported by the display server, right? Wayland is entirely correct to be aware of pixels, it's your toolkit that should provide and operate with geometry which it translates into a rendered output that is placed into the buffer that Wayland manages.
If the toolkit is any good, the application won't be aware of it.
A bit of reading would suggest that scaling would be employed on a per-monitor basis, I don't have time to read in depth to figure out what the logic is behind it.
Re: (Score:2)
Sorry, I phrased that from a developer's perspective. Few developers really have any need to worry about pixels in their UI, and shouldn't be for this very reason.
Well if it's an arbitrary, raster-based toolkit then I assume it'll be scaled by some system default, just like they're scaled on OS X. It's a transitional period where we're going to be breaking things for a
shhh dont actually list facts (Score:2)
you will scare the nutjobs who like to draw castles in their cheerios and tell you to go live there.
Re: (Score:2)
I have been witnessing the failure of vector-based toolkits. Even as this brave new world rolls on, it has forgotten something, and that is vector-based toolkits produce abysmally bad font rendering on low-DPI monitors.
That's one way of putting it. Another way to describe the same issue: rendering decent text on low-DPI monitors requires a bunch of atrocious hacks (hinting, subpixel antialiasing, etc.). Therefore, low-DPI monitors suck, and we should work to get rid of them as soon as possible.
My light s
Re:Sounds like it's still "all pixels" (Score:4, Insightful)
Not much, except that all modern Linux software already does this because X is utterly obsolete as a drawing toolkit. Wayland is pretty much the answer to "If we assume the toolkits look at X like a dumb framebuffer, how much of X can we throw away? And fix some deep design issues in a process." That's it, nothing more. It's not an either-or, nothing prevents you from building an overlay that talks geometry to clients and pixels to Wayland, if you can get any traction for that. But then you're probably going to compete with similar functionality in GTK+, Qt, wxWidgets, OpenGL, OpenGL ES, SDL and so on that all like to render pixels. Unless you can force developers to use one library like Windows and OS X can you'll be just another library clamoring for support. But they all need something to render on and that's Wayland.
Re: (Score:2)
Basically in the past we had a big fat X11 with big fat clients. Now it will be a thin display server with big fat clients. Much of the bulk in X11 was not being used or being done separately in the client anyway. Ie, clients are already doing all the pixels themselves rather than doing geometry if they're built on top of modern toolkits.
However what's not being talked about is what sort of layer is going to sit between Wayland and the clients. It won't be big and bulky though, it'll probably be thin.
Nice but (Score:2)
I could play with Wayland API and help it to take off but not if I have to wait 5+ years for Wayland to get X11 features and drivers.
Re: (Score:3)
Yes the development version includes the ability to run a wayland "desktop" inside an X window. It will do this automatically if $DISPLAY is set when you run Wayland.
For me that is the only version that works. I have two monitors and I have set it up so Wayland runs a full-screen version on one of them, making testing pretty accurate and easy.
They may not like it but that is probably the way it is going to work first with full nVidia acceleration.
no, thanks, Wayland, I need REAL networking (Score:3, Interesting)
I use the networking capability of X (process on IP address X using display on address Y, same or different IP, different user) every day, all the time.
For example, I always run a X server on Windows boxes, because I can then run some Linux process on the Windows display "root" window. Productivity is higher because I don't have to switch "containers", in order to switch applications, and copy/paste is trivial.
Similarly, I can have a process in a different, more locked-down, user running on the root window of "my" desktop, toggling between applications without having "switch user", open a different VM, ...
I'll keep using X11 as long as I can.
Re: (Score:3)
I don't see why any of those things precludes Wayland. It looks like it will go the route of per-app RDP. RDP works fine with copy/paste and doing it per app should let you have fine grained control over the users those apps run as.
Re:no, thanks, Wayland, I need REAL networking (Score:4, Insightful)
A subset of people like me use their desktop as primarily a terminal to connect to more powerful servers. I want to know if Wayland will let me "ssh me@oldserver-running-X xterm" and then use the remote xterm to start a bunch of programs that open their own windows. I don't want to know how it does it, only if it will work.
If the Wayland developers don't want to commit to making something like this work, that's fine. It just means Wayland isn't designed for me. If they *are* going to make it work, I would feel more comfortable is they would come and say for certain that they are committed to supplying this functionality.
This same point comes up again and again. I think that the developers at some level don't understand the question, because there never seems to be an answer that is straightforward and pitched at the level of the user. (Not that anyone *owes* me an answer. I am just making a request.)
Re: (Score:2)
Of course it will, it's very useful.
Unless there's something preventing the implementation of a dummy Wayland server (memory backed) then (if I understand how this thing works...) starting a "remote" Wayland app would need a wrapper that would instantiate a dummy Wayland render space and some signal ssh would have to carry back to launch a Wayland client on your console side, and ssh would have to plumb the I/O. ssh would probably need a flag to start this (too bad -W is taken) and obviously somebody has t
Re: (Score:3)
run VNC. Some of us want a fast responsive GUI that doesn't rely on 30 year old protocols.
Run VNC? Do you even understand how people use X? I guess not. I ssh into another box & run some program and up it pops on my local screen. Quick, easy, simple, works. Now, setting up VNC works in some cases, but now we are talking about something completely different and completely different use cases. You have some server somewhere, you want to run a GUI config program or whatever real quick, you just type the command and it works. You do not want to spend 15 minutes installing all sorts of VNC crap,
NOT a misconception (Score:4)
It's a backwards step to the non-networked, single user, single platform mindset. That's not even what people are looking for in gaming consoles any more.
The ramifications are that new wayland only apps are only going to be useful if you are sitting right in front of the computer you want to use - an insane restriction now that phones and tablets with wifi are at the point where they can be effective terminals to a desktop computer doing the heavy lifting (video, graphics, voice recognition whatever).
The single platform restriction also sucks - linux only due to a deliberate design choice.
Sorry kids, a dumb framebuffer is not a new idea and a trip back to the 1970s has got to be justified with new features and good benchmarks before it can be proclaimed as better. For now there's only stupid block diagrams that pretend any internal complexity and internal communication is faster than something with more blocks in a diagram even if they are a lot simpler - it's just smoke and mirrors without benchmarks.
Even calling it Metro for linux at this point would be giving it too much credit - save the hype for when it delivers on a performance promise and has more features than SVGAlib from 1995.
Re: (Score:3)
A major problem is not whether Wayland supports old X applications but instead that new Wayland applications are not going to be network transparent like X ones. That limits them to one to one network connection via third party hacks like VNC instead of the many to one and one to many options that X gives you. It's a backwards step to the non-networked, single user, single platform mindset.
You want network transparency? Why does the display server have to provide you with it? You want to drag networking, authentication, and encryption code/hooks into the display server. So much for the UNIX philosophy. There is already a "network transparency" protocol which your applications can use: https+xhtml+javascript. Fire up the transmission Web server/client to see a stellar example. You will never, never, never obtain the efficiency and the responsiveness of a Web app through the display server. A c
Re: (Score:2, Informative)
Because it would require completely rearchitecting and breaking the protocol.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
Mark-t hasn't been keeping up to date [h-online.com]
Comment removed (Score:5, Informative)
Re: (Score:3)
I've never delved too deeply into X, but none of the issues pointed out in the article really seemed all that compelling.
They seemed like the kind of quirks you end up in any large system. I assume wayland will trade them for a completely different set of quirks.
Re: (Score:2)
Here you go! [youtube.com]
Re: (Score:2, Insightful)
Re:The Manchurian Candidate (Score:5, Informative)
Well he gave an answer in the article: if you move to "fix X", you end up making X12. And when you do that, all the stakeholders in X come out of the woodwork and insist on preserving all the legacy parts of the system that, frankly, don't belong.
The way things have unfolded, X11 will become a library on top of Wayland. And that's perfectly fine.
Re: (Score:3)
> The way things have unfolded, X11 will become a library on top of Wayland. And that's perfectly fine.
Sounds like X running on Windows.
If you don't understand what's wrong with that, or you try to claim there is nothing wrong with that, then you really have no clue why people are resisting Wayland.
Re: (Score:3)
Re: (Score:3)
I've seen what happens when you run X11 apps on windows. All the fancy widget themes and whatnot break. If that's not it, then I invite you to enlighten me.
I love the blind implication that the exact same whatever will happen with Wayland and, therefore, we should oppose Wayland.
The only argument I've seen is the lack of network transparency, often poorly wo
Re:The Manchurian Candidate (Score:5, Insightful)
The only argument I've seen is the lack of network transparency, often poorly worded with no actual technical argument behind it.
Sounds like you aren't interested in hearing the arguments, but I'll try. Practically all X11 apps can run remotely - the ones that can't are likely to be inherently limited, like video players or 3d first person shooters that have bandwidth and latency requirements that are transport constrained. Outside of those types and pathological configurations, remote X11 just works for all apps.
V) "Wayland can't do remoting." Wrong. Wayland should be BETTER than X at remoting, partially do its asynchronous-by-design nature. Wayland remoting will probably look a like a higher-performance version of VNC, a prototype already exists. And this is without us even giving it serious thought about how to make it better. We could probably do better if we tried.
"We haven't given it serious thought" is a particularly bad approach to convince people to quit bitching. Show us a well thought out plan to support per window/application remoting, not vnc-style desktop remoting and that will shut up practically everyone. Act like you really don't give a shit and nobody will have any confidence that it ever will "better than X."
Re:The Manchurian Candidate (Score:5, Interesting)
I've seen demos of Wayland that had per window remoting, including moving and cloning per window across different diplays. Wouldn't it be nice if xmove still actually worked for most applications? If you could just move your application across Xservers as you wished and didn't have to worry about temporary network outages killing you application? Well apparently Wayland can do that. So it seems to me that Wayland has potentially more to offer in terms of network transparency than X. It isn't done yet, so let's wait and see. Everything I've seen looks very promising.
Re: (Score:3)
It isn't done yet, so let's wait and see. Everything I've seen looks very promising.
I don't know what you saw, but what I just read at the cited article is that the people designing wayland have barely given it a second thought. That attitude does not deserve the benefit of the doubt.
Re:The Manchurian Candidate (Score:5, Insightful)
They have barely given it second thought because they've established that it can be done in principle, and it isn't the stuff they're working on (which is getting the actual display working cleanly and efficiently). They can worry about it when they've gotten the fundamentals pinned down. Do you really want excellent networking for a display system that doesn't display well, or is horribly slow? First things first and all that. As long as nothing they do makes it infeasible, or overly complicated there's no point in worrying about it till the very core functionality is working as they wish.
Re:The Manchurian Candidate (Score:4, Informative)
There was a time when displays did everything by passing around rendering primitives -- lines, rectangles, black and white bitmap pattern tiles. At that time it made a lot of sense to integrate network at the low level because you had to figure out how to send and decode all those drawing primitives over the wire.
Display technology moved on. Displays became rich and complex and colourful, and different applications had very different needs and took on more and more of the rendering task themselves and simply pushed bitmap buffers to the display system. Now the task of the display system was to mediate and manage and request complex bitmap buffers from the various clients.
At this point remote display was a matter of having the client send (potentially compressed) bitmap buffers -- let the clients do their own rendering. This is how most remote display systems written in the last 15 years do it. Indeed, that is how X does it these days for most applications: the applications do their own rendering via GTK or QT and Cairo and X pushes the pixmaps down the wire.
If all you are doing is throwing around bitmap buffers, and the display software is simply mediating and displaying those, then remote display doesn't need a whole lot of thought at the display level -- all it has to do is mediate and display the bitmaps it gets from clients. Now, providing a remoting system to let remote clients get their bitmap buffers to the display when requested ... well that's still a thing that needs to be done, but it the base display software doesn't have to care too much about how that gets done.
Think of it as teasing out the layers in the software. The base layer is pushing pixels to the screen (no matter where the data for those pixels came from, remote or local). That's one job: pixels on screen. Focus on that and do it well. Another job is getting the data that the base layer is going to display to it, and you can worry about remote/local differences in that layer.
Re: (Score:2)
No, I'm just tired of bad arguments.
That's nice. But it's a very limited subset of how computers are used, and there's noth
Re: (Score:2)
Augh, bad engrish today.
should read
Re: (Score:2)
Maybe because they know you won't even when they make an entirely point and put it in front of you? Read what he said:
I read that everything he said was qualified with the word PROBABLY. What did you read?
Re: (Score:2)
Ah, yes because he said "we could probably do better" it's instantly terrible and doomed.
I read it as someone who was confident of their solution but unsure of the final form, believed that their prototype implementation was already better than X11/VNC, and acknowledged that there was room for improvement but wasn't sure how much. You read it as "we don't care" and I'll wager that if anyone here is off base, it's you.
Re: (Score:2)
Ah, yes because he said "we could probably do better" it's instantly terrible and doomed.
Hyperbole considered bad.
I read it as someone who was confident of their solution but unsure of the final form
"Probably" was not the only qualifier in the paragraph, pretty much everything he wrote was explicitly qualified. However you are welcome to support your beliefs with a citation to some documentation for even alpha level protocols for remoting wayland apps.
What I've seen is stuff like this GSoC participant who discovered that its not as simple as he thought. [jakemp.org] No one's touched his work since. Seems like the only work to come since then has been RDP based DESKTOP forwarding, [phoronix.com] not app
Re: (Score:2)
Ah, yes because he said "we could probably do better" it's instantly terrible and doomed.
That is not what he wrote at all. It is right there for all of us to read. And this from the person who complained about being tired of bad arguments? Did you really mean being tired of resorting to bad arguments?
"Wayland remoting will probably look a like a higher-performance version of VNC,"
Re: (Score:2)
I'm mocking him. He sees a tiny bit of uncertainty in the guys comments and reads it as if the guy is completely blowing off remote access when it's obvious that he's not.
Re: (Score:2)
What, I can't be sarcastic?
Looks like he hasn't touched his other projects either.
And RDP supports rootless forwarding just like X11. But that's just one possible way of forwarding them. It's not like its impossibe.
Nothing is stopping you from continuing to stick to Xorg, of course. Wayland won't fully displace X11 for a while.
Re: (Score:2)
Looks like he hasn't touched his other projects either.
(A) He tried it and wasn't as simple as all the big talk
(B) no one else has picked it up.
And RDP supports rootless forwarding just like X11.
Bit-blasting just trades the latency problems with X11 forwarding for bandwidth problems.
But that's just one possible way of forwarding them. It's not like its impossibe.
"Not impossible" is a far cry from being designed, much less implemented.
That's a tacit admission on your part that work is not being done on the issue.
Re: (Score:3)
So running an app over the internet is a pathological configuration?
X11 is utterly garbage at remoting because it was never designed for it, it was designed for LAN use with near-zero latency. That's why the calls are syncronous.
Sure, it's possible to forward an X11 connection across 100+ ms of latency, but I wouldn't call the resulting clusterfuck 'usable'. There's a reason that the nX library is used to make it r
Re: (Score:2)
Yes, because if it's not X12 then you can actually break it. If it's X12 then you'll be forced to keep some broken stuff. Maybe you'll be allowed to say that something is deprecated until X13 though, but that means it could be another 26 years until it's removed.
Re:The Manchurian Candidate (Score:5, Interesting)
Why not fix X?
The simplest and most obvious answer: it's easier and faster to just not bother and start from scratch.
In addition, X was originally written when networks and client systems were slow(er). Many of original design decisions are no longer appropriate with respect to the X server code complexity and maintenance requirements. A long (long) time ago, I wrote a program (called CXC - Concurrent X Control) to manage the low-level X protocol (think everything in the X11 Volume 0 book) and support transparent X traffic interception, blocking, redirection and insertion for a CBT application (called CAST) and, if I remember correctly, I remember wanting to off myself (or at least start drinking heavily) after trying to make sense of it all. Just my $.02.
Re: (Score:2)
So if Wayland only works on a fast network, it will not win me. Heck, many X11 applications are far too slow over DSL (I guess those are the applications which do not use the X core, but all those "better" alternatives). I prefer a less pretty window I can interact with to a pretty one which I is too slow to use.
Re: (Score:2)
X was also designed when your workstations were very expensive, so having things like an X Server dumb terminal was a good idea. Keep all the jobs running on your departmental super mini computer, and hand out xterms to the staff. Save money and you get a larger display than you would otherwise (meanwhile PCs are still running DOS).
What's interesting is that in the intervening decades that all the power moved over to the client on the desktop, and now it's starting to be moved back to the backoffice again
Re: (Score:2)
Re: (Score:3)
Re:The Manchurian Candidate (Score:4, Informative)
Why not fix X?
The article answers that question on the very first page. (Scroll down to the bottom.)
Re: The Manchurian Candidate (Score:3)
And, maybe if you had either
A) RTFA or
B) watched http://www.youtube.com/watch?v=RIctzAQOe44&autoplay=1 [youtube.com]
You could have added something Intelligent to this conversation.
Re:The Manchurian Candidate (Score:5, Informative)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Informative)
First, SDL isn't an alternative display technology, it's a library which works on top of X (and Weston). Second, I am running KDE on Weston right now and it is working pretty well. It's not ready to replace X for most users yet, but it's stable and getting close to ready for mass consumption.
are you running X? (Score:2)
if you arent running without X, then you arent running without X.
you missed the whole point of my rant
Re:show me hello world on my own pc or STFU (Score:5, Insightful)
Yes, I did it on my Raspberry Pi using the implementation of Weston that they discussed.
Making your ignorance plain is quite helpful to others in knowing to avoid you.
Yes, here we are, still with X. That doesn't make X good and it doesn't mean Wayland has made no progress. In fact the biggest driver of the Wayland transition is the wide availability of graphics accelerators that we didn't have back in 1997.
I won't really shed a tear when X is reduced to a library that sits on top of Wayland. I will enjoy improved performance and compositing that Wayland brings.
SurfaceFlinger. Of course, no one has actually adopted it. It's just prevalent because of Android.
Re: (Score:2)
I don't NEED it, but I'm excited to try it. And now here I am without a file manager, or reall
Re: (Score:2)
Given that the "huge pile of instructions" are build instructions, unless you're familiar with building from source it's probably best avoided.
Probably LD_LOAD_PATH, because their setup is installing to the user's home directory and not the system, to keep things clean. It's entirely testing centric at this point.
bullshit, horse shit, cow shit (Score:3)
if a program cannot build easily on a standard linux machine, its not going to be adopted by hundred of millions of people and its not going to topple an installed standard with a huge userbase
the 'user is wong' attitude is what doomed every display system before and will doom wayland just the same.
get the thing to compile out of the box or dont ship it. a simple philosophy. we have cmake, autoconf, scons, choose your poison
Re:show me hello world on my own pc or STFU (Score:4, Interesting)
Re: (Score:3)
The only "asshole" here is you. Just look at your mad ranting.
Re: (Score:2)
I don't understand why you are making a big deal out of building wayland. X11 is very difficult to build (took hours the last time I did it). Who cares? When it's ready, you will be able to install it with aptitude install wayland. Building from source is always more complicated than installing from a binary package. This has nothing to do with support. why the attitude?
because im sick of all the lies man (Score:3)
this shit doesnt work, people keep saying it will replace everything.
they call anyone who challenges them purveyors of "fear uncertainty and doubt.
FEAR - im afraid it doesnt fucking work
uncertainty - im uncertain if i should spend 40 hours porting my shit to this 'next big thing, or ubuntu's MIR, or ubuntu phone's ShitFlinger or whatever teh fuck its called.
Doubt - I Doubt anyone will ever write a game for linux if this is the fucking situation with the graphics layer - 4 to 5 different subsyetems with inco
Re: (Score:2)
i dont have a raspberry pi (Score:2)
which is why i said 'on my desktop PC'. which has a user base of, oh, several ten-million
not some niche little fad product with 512mb of RAM that has a month waiting list so hipsterss can pretend they are saving money
Re: (Score:2)
I see you were never interested in having an honest discussion. Rather, you were waiting for a response of any kind so you could lash out angrily and move goal posts.
Which is in no way relevant.
So beyond being a raging asshole, you ignore the fact that the Pi runs Debian, same as the desktop, and has a Weston build targeted that works right now.
Re: (Score:2)
Actually learning that Wayland is being developed by former X developers removed most of my ancieties about it. Now I just want to know when it's going to be production ready and if it is going to support my craphics card.
Re: (Score:3)
Re: (Score:2)
My Mac has X on it. It came with OSX as an optional install until recent releases and it's still a free download.
Mac doesn't necessarily mean no X. In fact, some programs REQUIRE IT like some high end math stat programs.
its a closed source non-linux system (Score:2)
i mean, we might as well discuss windows and directx
Re: (Score:2)
That's 20 years since linux was created. 20 years and the only widely adoptd alternative to X is on Android, and i dont even know what its' called.
Hold on there, cowboy – you can't just hand-wave away Android, since Android deployments outnumber desktop X11 deployments by several orders of magnitude! Android is succeeding at end-user adoption where X11 has failed miserably for your "20 years", so you should be looking at Android for guidance, not dismissing it as a blip.
By the way, when Linux is use
Re: (Score:2)
The only lesson to be learned here is that if you've got Google driving you, you're probably going to succeed. Suggesting that there is anything to be learned here about X11 vs. SurfaceFlinger is ridiculous.
Which is entirely untrue. B
my desktop PC is not an embedded system (Score:2)
show me how to write OpenGL hello world programs for DirectFB on my desktop PC
Re: (Score:2)
its just utter vapor ware.
http://www.youtube.com/watch?v=mQ97cK4Jp8I [youtube.com]
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
> There are far more Windows boxes too.
Ironically, you Wayland fanboys are going to make sure that the remote access features that have been adopted by Windows are ripped out of Linux.
Re: (Score:2)
I see we're whipping out the baseless attacks now!
do it without X installed (Score:2)
congrats you missed the point
Re: (Score:3)
there is more than one page
Re: (Score:2)
Okay, I see now. Some other observations: 1) It sounds like Wayland doesn't do remoting yet. 2) The way they're talking about it suggests it's desktop-only -- no starting an application on some other machine and displaying it on the local machine.
#1 isn't too bad -- they're working on it. #2 has me more concerned. Are they planning on having it be able to export individual applications rather than just the entire deskstop?
Re: (Score:2, Informative)
FTFA, page 3, point VI:
every X app just gets its own mini X-server to deal with
That sounds like it will be pretty straightforward to support individual apps remotely.
Re: (Score:2)
That's for X apps. I'm talking about Wayland apps. Can native Wayland apps be remoted? I don't want to have a situation where I'm given a native Wayland app to control something and that something is on a remote machine. I don't want to have a situation of "Well, it's native Wayland. You have to be on the system's console to see that." Further, I don't want to have to fire up an entire desktop session to watch a window that takes up a tiny fraction of the screen.
Re: (Score:2)
Remoting of individual native Wayland applications has already been demonstrated. The protocol is similar to VNC, capturing changes in the per-window rendering surface, compressing them, and sending them over the network. "Similar to VNC" does not mean remoting a whole desktop; a VNC-like protocol is merely used to transfer the contents of the window, in the absence of shared memory.
Modern X11 toolkits do more or less the same thing, but without the change tracking and compression. Having been designed to t
Re: (Score:2)
And they should know since many of them worked on these very features in X11.
Re: (Score:2)
As per the article, there IS a workaround. It's called Wayland.
Re: (Score:2)
I went digging after reading this article, here's the only thing I've found:
Mir in Kubuntu [martin-graesslin.com]
Halfway down, he compares the two - it doesn't look like there's much concrete info about Mir though.
Summary: Philosophical differences in development style, server-allocated buffers vs. client-allocated buffers.
Re: (Score:2)
There isn't anything about Mir. I think Phoronix made a booboo in their summary. It was only intended to explain some things about Wayland, Mir is out of scope.
Re: (Score:3)
Wayland is being made because the guy who writes it want too, not because there is anything inherently wrong with X.
Most Wayland developers are X developers, they did it exactly because X is a pile of bull crap...
Re: (Score:2)
Wayland and Weston are separate programs.
Weston is currently the only window manager for Wayland.
Re: (Score:2)
It really does seem like a baby+bath water out the window type thing. the X12 link at the bottom of the article actually was much more interesting to me and seemed like a much more sane architecture roadmap.
that made more sense than all Wayland/MIR articles (Score:3)
i have ever read.
Re: (Score:3)
Many of X's recent "everything as pixels" shortcomings and network bottlenecks came to be because the exact same developers who are pushing to abondon X11 tried to make it into iPhone graphics. That didn't work very well and so they decided to abandon it in favor of the Wayland rewrite. Which is ok, fine, they can work on whatever they like. But when the same exact developers justify thier work with the statement that X is broken, and they're the bloody ones that broke it and abandoned it what way in the f