Bad NIH, good NIH [LWN.net]

Bad NIH, good NIH

Posted Mar 10, 2013 10:44 UTC (Sun) by nix (subscriber, #2304)
In reply to: Bad NIH, good NIH by HelloWorld
Parent article: Canonical reveals plans to launch Mir display server (The H)

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 applications

That'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.

(Log in to post comments)

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.
Sure, it's not perfect, and it's probably possible to obtain better performance with a protocol that caters to the needs of modern applications (i. e. something other than X). But is it really worth the effort? Supporting a higher-level drawing protocol in the toolkits is probably somewhat harder than a VNC-like approach. And if you want really good performance, you actually want more than just drawing. You want something like stored procedures in SQL: the possibility to execute code in a confined environment on the server. A toolkit would then be able to upload a procedure to, say draw a button, and the next time it wants to draw a button, it merely has to call that procedure. Adobe actually tried something like that with Display Postscript. And perhaps you also want a server-side scene graph given that today's toolkits like Qt5 and Clutter use scene graphs. It's probably quite hard to retrofit current toolkits to make good use of such facilities, and you may well need toolkit-specific functionality to do a good job.
And let's not forget that remote applications (VNC/X11/RDP etc.) are increasingly being displaced by web applications. So I think that the best thing to do is to settle for something that's Good Enough, and a VNC-like protocol may be just that.

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.