| |||||||||||||
Bad NIH, good NIHBad NIH, good NIHPosted Mar 8, 2013 19:24 UTC (Fri) by HelloWorld (guest, #56129)In reply to: Bad NIH, good NIH by nix Parent article: Canonical reveals plans to launch Mir display server (The H)
I still think that a display protocol was a very important innovation and that making drawing direct to the framebuffer the core operation is a huge step back.I don't see why. Afaics, there were essentially two reasons for putting the rendering code in the X server:
(Log in to post comments)
Bad NIH, good NIH Posted Mar 9, 2013 0:21 UTC (Sat) by Serge (guest, #84957) [Link]
> Afaics, there were essentially two reasons for putting the rendering code in the X server
X server supports both client-side and server-side rendering.
But Xorg is much more than just rendering.
(#6 is not that strong now, Wayland fans talk a lot about Xorg being bad, and that gives some bad points to Xorg and commercial Linux development, sigh...)
At the same time X11 was never rotten. On the contrary, it was always among the first to innovate. First remote graphical terminals, first desktops with multiple workspaces, multi-monitor systems, first multiseats, first 3D-desktop, first multi-touch (MPX, yeah, it was done before iPhone :)) — most (if not all) of these things were first done under X-server.
> Otoh, client-side rendering is faster because it avoids the protocol overhead
You should probably like DirectFB a lot. It's direct, client-side, and has no server, so it completely avoids any overhead possible. :)
Bad NIH, good NIH Posted Mar 9, 2013 18:45 UTC (Sat) by HelloWorld (guest, #56129) [Link]
Bad NIH, good NIH Posted Mar 9, 2013 21:58 UTC (Sat) by Serge (guest, #84957) [Link]
> 1. Nobody needs or wants X servers for Windows, Mac OS or Android.
Have you heard about windows program called "putty"? You can ssh with it to remote server with no video adapter and run X11 apps over it. How? Using X server for Windows. You can do similar things with OS X, it has its own X server. There're also X11 implementations for Android.
Yes, people need and want X server for Windows, Mac OS and Android. And they have it.
> What people want is remote applications, and they'll get those with Wayland via a VNC-like protocol. Which, by the way, works way better than X for today's applications.
You don't need Wayland to use VNC, you know that? Also, Wayland is about direct client-side hardware use, you'll get some problems when you try using it on a server with no graphical hardware.
So, you have Xorg (works always, supports X11 forwarding, VNC, xpra, NX), and you have Wayland (works sometimes, theoretically supports VNC). I don't see a reason to choose Wayland in this case, do you?
> 2. It doesn't run everywhere. Android doesn't use it, Firefox OS doesn't, Tizen doesn't, Mac OS X and iOS don't, nobody right in their mind uses it except as a compatibility crutch.
It does run everywhere. It can be run on Android (and it was done since first androids), there're X11 implementations for iOS, and it's included in Mac OS X. Also it's used by Maemo/Meego.
> 3. That will come for Wayland as well, it's just a matter of time.
Wayland design makes me think it won't. What makes you think it will? Let's take an example: directfb. It's well known, was created 12 years ago (!) and still does not have those good tools.
> 4. You can run any desktop environment on Wayland too, and you can combine any Wayland compositor with any desktop, provided it offers the needed functionality (which obviously applies on X11 as well)
Theories again? Please, run Compiz on Wayland. At least run IceWM on Wayland. Have you ever used Wayland/Weston yourself?
> 5. The toolkits that matter will soon support Wayland (or already do)
I guess you have not seen how it looks. Try it. Anyway, all toolkits already support X11. Name one reason why they should bother supporting Wayland?
> 6. The Wayland protocol is stable
You obviously have no idea what's "stable". "Stable" means that I can release program today and it will continue to work. "Stable" means good for long term commercial use.
X11 is stable. It always was. Now Wayland has v1 protocol for a few months and you can't be sure that tomorrow there won't be Wayland v2 with completely different protocol. Bear in mind that currently you can't use Wayland protocol without compositor extensions. And a few existing compositors have them different. Wayland is unstable itself and it's trying to shake Xorg by constantly attacking it ("it can't be worse than X11"). This is bad for the entire Linux community.
> and X applications are supported via XWayland.
You haven't ever used it, have you? Try using RebeccaBlackOS LiveCD. When you notice that your X11 programs don't start any more try debugging that.
> That's why many of the X.org developers themselves (including Keith Packard, Kristian Høgsberg, Daniel Stone) support Wayland. Now please don't try to tell me that you know better than them what a future-proof graphics stack looks like...
Oh, that's the biggest mystery for me. Initially I thought that Wayland was just a proof-of-concept, like "Look, Linux has such a powerful graphical stack that I can easily create a simple window system". Then I thought that Wayland could be a test of new ideas before including them into Xorg. But Wayland is still promoted as being better than Xorg, and I don't see who it's supposed to be good for.
It just was not possible to do something like Wayland before. So I understand that it's fun for smart hackers to dig though something new, something that have never been done. But for now Wayland looks like a personal toy for its developers, that brings no benefits to anybody else.
Bad NIH, good NIH Posted Mar 10, 2013 3:07 UTC (Sun) by HelloWorld (guest, #56129) [Link]
People have explained dozens of times by now what's wrong with X11 and why it's worth working on a replacement. If you still didn't understand, it's because you don't want to, and I won't waste my time trying to convince you otherwise. Fortunately, the world keeps moving despite stick-in-the-muds like you.
Bad NIH, good NIH Posted Mar 10, 2013 15:37 UTC (Sun) by hummassa (subscriber, #307) [Link]
> People have explained dozens of times by now what's wrong with X11 and why it's worth working on a replacement.
No. No one has explained what is wrong with X11 or with its implementations.
More specifically, no one has explained why any possible flaws are not fixable.
About the worth of working on a replacement, to each its own, and no one can force others to work (or to pay someone to work) on something.
Bad NIH, good NIH Posted Mar 10, 2013 18:25 UTC (Sun) by patrick_g (subscriber, #44470) [Link]
> No. No one has explained what is wrong with X11 or with its implementations.
Please look at this video : http://www.youtube.com/watch?v=RIctzAQOe44
Bad NIH, good NIH Posted Mar 11, 2013 4:58 UTC (Mon) by Serge (guest, #84957) [Link]
>> No. No one has explained what is wrong with X11 or with its implementations.
> Please look at this video : http://www.youtube.com/watch?v=RIctzAQOe44
Presentation that starts with "Noone has any idea". Saying things like "I'm the smart guy and everybody else is stupid", even if you're joking or have reasons for that, still looks... not very polite. But let's get back to the X11 talks.
There goes an interesting story of XFree86/Xorg evolution, how it looked 20 years ago and how few features it had back then, and how many features it has now, how it adopted all the modern hardware, how older extensions were replaced by their newer versions etc.
But where are the problems? Gedit startup is too slow? Then fix gedit! The rest is like "X is doing that bad, so Wayland can't do that at all" or "X does it that way, we don't like that, so Wayland does it this way" or usually it's like "Wayland is going to do it better" because it's not implemented yet or the implementation is very basic/buggy. That's all! No problems of X11 protocol or even Xorg there.
What have I missed?
BTW, it was kind of fun listening to "X isn't network-transparent any more" while running some GUI tools over ssh -Y.
Bad NIH, good NIH Posted Mar 11, 2013 9:30 UTC (Mon) by gioele (subscriber, #61675) [Link]
> BTW, it was kind of fun listening to "X isn't network-transparent any more" while running some GUI tools over ssh -Y.
The presenter explicitly said that "X is network-capable, not network-transparent". It means that you can run X applications over the network, but the software has to handle it as a special case now, given that the current normality is the use of shared memory buffers.
Bad NIH, good NIH Posted Mar 11, 2013 4:33 UTC (Mon) by Serge (guest, #84957) [Link]
> People have explained dozens of times by now what's wrong with X11 and why it's worth working on a replacement.
No! People have dozens of times explained why they CAN work on a replacement, not why it's worth working on it. Usually all those explanations boil down to "X11 has too many features" and "Wayland is not too bad". But nobody have ever explained who's going to win from it. I would be glad if you provide me a link to such explanation.
Wayland/Weston is like a HelloWorld-program. It's useless but IN THEORY you can extend it to do whatever you want... Hm... HelloWorld is the best graphical manager! It's fast and simple! You can do everything else client-side! Sounds familiar? :-)
Bad NIH, good NIH Posted Mar 10, 2013 10:44 UTC (Sun) by nix (subscriber, #2304) [Link] Nobody needs or wants X servers for Windows, Mac OS or Android. What people want is remote applications, and they'll get those with Wayland via a VNC-like protocol. Which, by the way, works way better than X for today's applicationsThat's just as wrong as it was last time you said it. Even the Wayland developers say that to accelerate things like scrolling screenfuls of text (a common case) will require toolkit-level remoting that is aware of things like glyphs rather than just considering the framebuffer to be a big image.
Bad NIH, good NIH Posted Mar 11, 2013 12:27 UTC (Mon) by dgm (subscriber, #49227) [Link]
There are many things that can run smoother over the network if done more cleverly than just copying frames around, but:
1. Most people do not need to work over the network, specially those that have the greatest need for performance: games, video playback and such. 2. Copying frames is by far the simplest solution. 3. Being able to copy frames doesn't mean you cannot _add_ a cleverer solution.
So, a local only display covers maybe 95% of user needs, and with dumb frame copying you may be getting that up to 99% (statistics right out of my hat, but still). The remaining 1% _can_ be worked out, or just keep using X11.
The alternative is forcing network "transparency" down everybody's throat, even if they do not want or need it.
It's not really that nobody needs X11. I do, for instance. But I'm not so stupid to not realize that most people don't. And forcing them to play a price for something I need doesn't sound like a great idea.
Bad NIH, good NIH Posted Mar 11, 2013 15:27 UTC (Mon) by nix (subscriber, #2304) [Link]
I find it hard to believe that you think that playing video rendered over the network (without using something like Youtube) is a more common case than rendering scrolling text buffers over the network. The latter is about 99% of what people use X remotely *for*.
Bad NIH, good NIH Posted Mar 12, 2013 12:21 UTC (Tue) by dgm (subscriber, #49227) [Link]
> rendering scrolling text buffers over the network [...] is about 99% of what people use X remotely *for*.
Probably, but what percentage of people do use X remotely, actually?
Does it make sense to design the solution around that use case? Or would it be better to design things around the *common* use case (computing and display on the same node), specially when alternative solutions do exist?
Bad NIH, good NIH Posted Mar 13, 2013 21:41 UTC (Wed) by nix (subscriber, #2304) [Link]
I can't tell you how common it is, or isn't. I don't see how you could claim that you know that non-remote use is so common that the remote case should be disregarded, either.
Bad NIH, good NIH Posted Mar 13, 2013 20:14 UTC (Wed) by HelloWorld (guest, #56129) [Link]
> That's just as wrong as it was last time you said it.
Well, it's more or less what Daniel Stone said in his recent talk about X and Wayland.
> Even the Wayland developers say that to accelerate things like scrolling screenfuls of text (a common case) will require toolkit-level remoting that is aware of things like glyphs rather than just considering the framebuffer to be a big image.
Bad NIH, good NIH Posted Mar 13, 2013 21:46 UTC (Wed) by nix (subscriber, #2304) [Link]
So... your 'argument' is that VNC-like stuff is 'good enough', even though it is clearly much worse than glyph-by-glyph stuff for the vast majority of windows that anyone ever opens using any windowing system -- those windows filled with text? (Discounting, for these purposes, games and video playback, which clearly should be local or use a video compression algorithm of some sort.)
Almost every use case (save only the GIMP, Inkscape and their ilk) can be covered by video compression or glyph-by-glyph stuff. VNC is bad for *both* of these. As far as I can tell, VNC is far suboptimal for *everything*.
Bad NIH, good NIH Posted Mar 13, 2013 22:51 UTC (Wed) by HelloWorld (guest, #56129) [Link]
Of course it's suboptimal. It's also easy to implement and doesn't need application or toolkit changes and still works better than X (which is unusable over high-latency links). Again, the question isn't whether it's possible to do better but whether someone can be bothered to invest a significant amount of work in a better solution. Given that remote applications == web applications for 95% of all users, I don't think anybody will.
Bad NIH, good NIH Posted Mar 13, 2013 23:43 UTC (Wed) by nix (subscriber, #2304) [Link]
It doesn't work better than X over even low-latency links the moment you have to scroll. Scrolling a windowful of text using normal VNC is laggy even over a quiet gigabit ethernet link: over anything slower it is hopeless.
Bad NIH, good NIH Posted Mar 14, 2013 3:10 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
you are so focused on what is the 'norm' today that you are completely blind to the future.
remote display uses that are going to become very common in the near future (especially when connected to mobile devices that do not have the CPU power to render locally, then ship VNC style full-frame images out to the remote display)
1. Google Glasses style head mounted displays.
Google is far from the only company working on this sort of thing. Many of these uses are text or simple geometric objects overlayed on the live video, shipping the video to the phone, doing the overlay, and shipping the result back out is wasting a lot of bandwidth, and battery. Not Going To Happen (at least not for very long). What's going to happen is the video will get shipped to the phone (although not necessarily in full resolution), the phone will craft the overlay, and the overlay will be transmitted back to the headpiece to be combined there with the direct feed from the camera.
2. remote displays (frequently wireless) from mobile devices to large, high-res displays.
Haven't you seen any of the many TV shows or movies recently that show people pulling something up on a phone/tablet and then 'flicking' the window over to the full display? What makes you so sure that this is not going to happen?
There are probably a lot of other examples that people could point out, but just because you don't currently use remote displays doesn't mean that they aren't going to be very popular very soon.
|
|||||||||||||