| |||||||||||||
LPC: Life after XLPC: Life after XPosted Nov 5, 2010 22:15 UTC (Fri) by dskoll (subscriber, #1630)Parent article: LPC: Life after X
I don't understand why "Network Transparency" and "High-Performance" need to be mutually-exclusive. It seems to me that if the design is done carefully, then the graphics API can dynamically load a high-performance library that renders directly on the local machine for local clients, and a network-aware library for remote rendering otherwise. Something like this pseudo-code:
if (running_locally()) {
handle = dlopen("fast_local_renderer.so");
} else {
handle = dlopen("slow_network_renderer.so");
}
/* Now use handle for all rendering calls internally */
All of this would be hidden from the application. It would just make calls to the rendering library and not know or care which rendering engine is actually used. Of course, on the other end, there would need to be a network-listening application to accept connections from clients, but that wouldn't even have to be a core part of the renderer. It would just use whatever network protocol is decided on and boil it down to local rendering requests. Mobile devices that don't need network transparency just wouldn't ship slow_network_renderer.so or the network-aware server application.
(Log in to post comments)
LPC: Life after X Posted Nov 5, 2010 22:37 UTC (Fri) by drag (subscriber, #31333) [Link]
> I don't understand why "Network Transparency" and "High-Performance" need to be mutually-exclusive.
I don't think that people are suggesting that. At least especially Keith is not suggesting that.
It is just that X, without big changes, is mutually exclusive with performance. At least without huge headaches that nobody has to put up with on any other platform.
Something like that.
If getting a simpler and faster Linux means dumping X then sacrificing X Windows may be worth it. And it's not even true then that we need to give up X altogether. Windows and OS X users can use X remotely just as about as much as we can with Linux. They both can even host X clients... but you have to realize the fact that almost nobody does that may help indicate how little utility most people get from X Windows networking.
I like the networking aspect, certainly. Hell we finally have a decent sound server to go along with X networking: PulseAudio. Then AIGLX works on most hardware. I can host a Linux KVM Guest on my Ubuntu laptop running Redhat or Fedora and use GDM's secure remote login stuff to be able to get full GUI, natively, with OpenGL acceleration and sound with a VM!!! Gnome/GTK folks have put a lot of work optimizing their applications for it. X networking is better then it's ever been in the past!
But it still may not be enough. I just don't know. X Windows networking is just one good feature among a huge number of really bad and obsolete features that is becoming increasingly burdensome with no really positive effect except backwards compatibility.
LPC: Life after X Posted Nov 7, 2010 20:00 UTC (Sun) by eru (subscriber, #2753) [Link] Windows and OS X users can use X remotely just as about as much as we can with Linux. They both can even host X clients... but you have to realize the fact that almost nobody does that may help indicate how little utility most people get from X Windows networking.That is because using remote X11 apps on Windows (I have no Mac experiences) is highly painful, compared to doing the same thing on Linux. There are just too many impedance mismatches with the native window system, and you need add the huge X11 server software. I expect the same thing would happen on Linux with a non-X11 "native" window system. Remote X11 (or running legacy X11 apps locally) would get a lot less convenient.
LPC: Life after X Posted Nov 8, 2010 5:04 UTC (Mon) by jzbiciak (✭ supporter ✭, #5246) [Link]
Well, there is one fundamental reason why it might turn out differently: If the folks who most recently maintained X develop its successor with bridging from X in mind, it's more likely to be seamless.
Bridging from X was never a design goal of Windows or MacOS.
LPC: Life after X Posted Nov 8, 2010 9:31 UTC (Mon) by quotemstr (subscriber, #45331) [Link] I'm not so sanguine about compatibility: we're talking about people who simply deny the existence of legitimate user requirements like network transparency. It'd be a small step for them to simply deny that users need to run X programs as well. Hopefully, they'll just be ignored. People have been trying to replace X for decades but nothing's taken off yet. I see no reason why this effort would succeed where previous ones failed.
LPC: Life after X Posted Nov 8, 2010 10:01 UTC (Mon) by jzbiciak (✭ supporter ✭, #5246) [Link] People have been trying to replace X for decades but nothing's taken off yet. Hmmm.... I believe X has probably 1% - 2% share in graphical desktops across all computers. Just because nothing's displaced it in the UNIX/Linux space doesn't mean it's a model of wild success writ large. And that's more than adequate to explain the lack of attention X usability / compatibility / impedance matching gets from the Windows and Mac crowds. It's not surprising X clients don't interoperate well with the native environment in those worlds. Given then fact that Wayland's coming from within the 1% - 2% community gives me at least some hope that they actually understand how X gets used and how to make it work and work well. As to the network transparency debate: There seems to be multiple levels here, and it all gets oversimplified when people fixate on the fact that local clients are the default focus of Wayland. There's the X way of doing things, which everyone is comfortable with inasmuch as they have programs that use it that they rely on and that they know work. At the far other end of the spectrum are windowing environments that offer no remote access model. These are an endangered species. And in between we have a number of different options, ranging from NX, which apparently keeps the drawing-primitive flavor of X with a lot of other improvements, to VNC/RDP, which move more in the bitmap-drawing direction. Personally, I'm still not 100% sold on the network transparency at the graphic-primitive level. Nothing in Wayland seems to truly get in the way of network transparency, as long as you're comfortable with a rendered-bitmap level protocol between client and server, rather than a more highly structured graphic primitive protocol.
LPC: Life after X Posted Nov 8, 2010 10:42 UTC (Mon) by nhippi (subscriber, #34640) [Link]
> People have been trying to replace X for decades but nothing's taken off yet.
Heard about the newfangled fads "windows" and "Os X" ? X11 market share is truly marginal compared its heyday. Even considering only Linux/Unix, there are probably more android users than X11 users.
As Keith points out, network transparency is done mostly with HTTP these days.
LPC: Life after X Posted Nov 22, 2010 6:31 UTC (Mon) by dododge (subscriber, #2870) [Link] There are just too many impedance mismatches with the native window system, and you need add the huge X11 server software.It's better than it used to be. In my current office the workstations are controlled by corporate IT, and so I'm forced to use a Windows XP desktop to do my Linux development. XMing is a small and free native X server for Windows that is very easy to install and run, and can mix remote X11 clients with native Windows apps on the same desktop. Many current X11 applications use client-side text rendering, which greatly reduces the headaches of getting core fonts working well on the Windows side. Microsoft's own TweakUI will enable X-style pointer focus to work across the entire desktop, which helps to smooth things out. By adjusting a registry setting I even have caps lock mapped to work like a second left-control key across all applications, and since it's part of my profile (rather than a system setting) it doesn't cause trouble for other users of the same machine. It's certainly not perfect, but my desktop is about 3/4 Linux+X11+ssh applications and aside from the native ones not doing middle-mouse pasting it's very easy to forget that there's any Windows stuff on there at all.
LPC: Life after X Posted Nov 6, 2010 6:07 UTC (Sat) by russell (subscriber, #10458) [Link]
mobile devices would benefit greatly from network transparency. To use a proper keyboard and mouse would be great.
LPC: Life after X Posted Nov 6, 2010 6:45 UTC (Sat) by elanthis (guest, #6227) [Link]
Yeah, funnily enough, that's exactly what X does now.
And still doesn't work out that well, because you've got a few big ticket issues. First is that you need to develop and maintain that network-aware protocol, which is actually pretty hard. Image-based network transparency needs a single protocol for transmitting image deltas and input events, and nothing else. An accelerated protocol either needs a generic RPC framework (which has historically proven to be heinously inefficient) or a custom-tailored protocol that has to be updated every few months for the new OpenGL versions and extensions. Plus, the network protocol _still_ is transmitting images all over the place, because modern apps still do a ton of image processing client-side, and rely on really fast buses between the client app and the GPU to keep things running smoothly, so you still end up needing a fast image transfer portion to the protocol. Plus there's the latency issues -- and this is the real killer -- because apps are using the GPU more and more for non-graphical processing, and data needs to transition back and forth between the GPU and CPU many times when carrying out even relatively simple tasks. For instance, picking an object when you click a mouse button can and is implemented in many apps and frameworks by rendering silhouettes in fixed colors to a buffer, then selecting the color at the texel corresponding to the cursor. Separating the CPU and GPU will make this god-awful slow.
Turns out that the image-based remoting works damn fast. Modern image compression techniques blow away what we had when VNC and X were still the top dogs in remoting. It's really quite trivial to push 60 frames per second of 1080p image content reliably on low-bandwidth pipes (and that's FAR more than any app other than a video player or game would ever need), and then all you need is the input events being sent back.
And there's no reason this has to be a whole-desktop affair and not a trivially easy to use per-application transparent setup. Wayland, in fact, makes this way easier than X does! Redirect the app to an offscreen buffer (just like the compositor already does), but instead of rendering it to the screen you instead compress, motion-diff, and encode the data and push it across a channel in your SSH session (just like X already does), and then the remote end decodes and displays the result. Send input events back. Super easy and there's no reason it would be any more difficult to use as an end-user than what X gives you today. And it works better, is forward-compatible with whatever advances come about in GPU technology, etc.
About the only thing you'll lose is the ability for a headless box with no GPU to get accelerated rendering on your desktop, but as I pointed out above you don't have that anyway, at least not for anything beyond the incredibly anemic and borderline useless 1.x versions of OpenGL.
Oh, and the Wayland-based network transparency could reuse an existing image-based protocol so it actually becomes easy to display those networked UNIX/Linux apps on a Windows/OSX/iOS/whatever machine without needing to jump through the hoops of getting a huge crazy X server installed. In fact, it can transparently work with any app from any OS. Neat.
Is all this written and working yet? No, of course not. That's no reason to claim it can't be written, though, or that it won't. In the end, the people who actually need something better than X and are willing to put in that effort are going to get what they want, and the people who want to keep esoteric X features but aren't willing to do the work to keep them on the modern architecture will lose out. That is the way of Open Source, as it is.
LPC: Life after X Posted Nov 6, 2010 7:53 UTC (Sat) by dskoll (subscriber, #1630) [Link] Turns out that the image-based remoting works damn fast. Modern image compression techniques blow away what we had when VNC and X were still the top dogs in remoting. The problem is that image-based remoting needs to use lossless compression or your applications end up looking like crap. I'm not so sure that can be done as easily as you suggest.
LPC: Life after X Posted Nov 6, 2010 10:36 UTC (Sat) by nim-nim (subscriber, #34454) [Link]
1080p is far more than a video player needs, but it is far less than most apps need.
Because most apps display text, and clean text rendering requires a lot more pixels than that (not to mention that all the current tricks to mitigate the effects of the lack of pixels for text rely on knowing exactly the hardware pixel layout, something you can't do with a generic image protocol)
Image protocols are good enough only if you restrict remoting to special emergency users where text redered like crap does not matter.
LPC: Life after X Posted Nov 6, 2010 11:43 UTC (Sat) by alankila (subscriber, #47141) [Link]
Completely hypothetically:
Why couldn't there be a negotiation that describes the optimal pixel format so that GUI programs could render their text optimally?
Also text doesn't change all the time, so it probably takes far less bandwidth to deal with than video in average, because you only have to transmit the pixels once, and then user spends a lot of time reading. If you know you're dealing with text (say, because the user told you so) you could disable lossy compression schemes too.
Favorite rant of mine:
Not that I expect introduction of Wayland to result in good text rendering on Linux. The text layering on window image has always been treated as a gamma=1.0 alphablending problem on Linux, the end result being awful color fringing and varying weight on diagonals. These problems are not going to go away until someone finally designs it right from day one.
All I can hope for is that by complaining about this eventually someone will wake up and design a text layering pipeline that can do gamma-corrected alphablending. Until that way, our fonts will continue to suck. There has been some hope recently with sRGB surface support specced in OpenGL, so I can only hope and beg that this flag will get turned on whenever a bitmap representing text is about to get combined with underlying graphics.
Color Management in a Wayland World Posted Nov 7, 2010 15:06 UTC (Sun) by ccurtis (guest, #49713) [Link]
There is a link to the mailing list from the project site here: http://wayland.freedesktop.org/
Nothing is mentioned in any of the documentation I've been able to find and I think it's valid to ask who's doing color management. Wayland appears to be oblivious to the issue and pushing it into every client seems like a mistake.
I hear this issue is basically solved on the OSX display server and whatever comes after X needs to have parity here. The problem may be most obvious in fonts and antialiasing, but it's certainly not limited to it.
LPC: Life after X Posted Nov 6, 2010 13:00 UTC (Sat) by Los__D (guest, #15263) [Link]
Errr, what are you talking about?
Most displays today is less than 1920x1080, and by far the most apps needs less than that.
LPC: Life after X Posted Nov 6, 2010 14:44 UTC (Sat) by dskoll (subscriber, #1630) [Link] Plus, the network protocol _still_ is transmitting images all over the place, because modern apps still do a ton of image processing client-side And that's the real problem. If apps restricted themselves to using drawing primitives, the network wouldn't be a problem. Requesting the server to draw rectangles, polygons, etc. is extremely efficient and beats any kind of image compression. The problem is that apps decided they wanted fancy textures, background images, etc. So they essentially did all the rendering client-side and treated the X protocol as a big dumb pipe for shipping images. The correct approach is to move more support for fancy effects into the server so the clients don't have to render on their end. Unfortunately, there's no easy way to get around the use of textures and images, so here's a radical concept: Don't do it unless it's necessary (eg, for games.) And provide an escape-hatch (eg, shared memory) for local apps that really do need to sling lots of images and textures around.
LPC: Life after X Posted Nov 6, 2010 18:51 UTC (Sat) by drag (subscriber, #31333) [Link]
With X a lot of the problem for poor performance is latency, not bandwidth.
Sending a compressed texture that is something like 1024x768 over most networks is not going to be a problem any more in a lot of cases.
A lossless 1280x800 PNG image itself is only something like 260.1KB, which will transfer over most internet connections in a fraction of a second. High quality JPEG or WebP is even smaller and compresses much faster with relatively little discernible image problems.
It's when you run into issues with applications that want to have something like a animated menu or whatever that takes 100 redraws to go from start to finish. When your on a local machine something like that is just stupidly fast and it is irrelevant. When your over the internet something that used to take 0.1 second now takes 5 due to all the time lost to latency from going back and forth 'draw' 'finished draw' 'draw again' etc etc.
When the fastest network most people had was 10 people sharing a single 10Mb/s ethernet on a single hub with all of them sharing the same collision domain... THEN that was when X networking was very troublesome in terms of Mb/s used.
Nowadays even common consumer internet connections are faster then that.
But when you have 128msec latency and it takes 2000 round trips between a server and a client to draw a new web page on your browser.... THEN that is when you run into serious performance problems. It does not matter if your sending 10's of KBs of information or your just sending 5Bs each trip it's going to create huge delays.
Your far better off just taking a image of a 1024x768 desktop at 15 FPS, sending it over a network then working on some special protocol to relay input back. (I am not sure about SPICE or ICA, but I am pretty sure that their technology is more sophisticated then just that.)
This is why people report VNC working better then X when it's obvious that in terms of actual bandwidth used X is often going to be better.
But it's not like VNC or X is even close to the state of the art. Both of them are obsolete with their own set of problems.
Seriously, check out:
While people have been arguing over the merits of being able to remote access a single application over X vs a entire desktop over VNC.... the ability to remotely access your GUI over the internet has gone mainstream.
ANY PC, ANY Mac. Over your browser. Very simple to setup, relatively inexpensively, adequately secure, and good enough that the average customer can use it without pulling their hair out.
You can even do it on your iPhone or IPad....
Sure I am not going to use it and it's not suitable if you care about your security, but the networking aspect of X is far from unique or special anymore and it's performance in common situations is inadequate compared to contemporary solutions.
LPC: Life after X Posted Nov 6, 2010 18:55 UTC (Sat) by drag (subscriber, #31333) [Link]
Oh. And with my job I have the unfortunate requirement of having to use a number of windows-only applications on a regular basis.
Many of these applications are, in fact, virtualized and are individually remote'd to my desktop. The way it is done is completely transparent and there is not a single non-technical user on a corporate windows desktop that will be able to tell you what applications are remote and which ones are local. They will not even be able to tell you that they are using virtualized applications remotely at all.
The experience is completely integrated and there is no discernible way, in terms of performance or image quality, to tell the difference between local and remote apps.
LPC: Life after X Posted Nov 6, 2010 20:09 UTC (Sat) by dskoll (subscriber, #1630) [Link] It's when you run into issues with applications that want to have something like a animated menu or whatever that takes 100 redraws to go from start to finish. So it's just bad application design, then. Or if you really want fancy animations, you do as I suggested: Let the server do the fancy effects. The client sends a little bit of information specifying how to do the animation (start, number of steps, time increment, etc.) and the server handles it. Augmenting X or something similar to do that wouldn't be too hard. Somewhat off-topic: The contraction of "you are" is "you're", not "your". Sorry... just a pet peeve...
LPC: Life after X Posted Nov 7, 2010 4:39 UTC (Sun) by drag (subscriber, #31333) [Link]
> So it's just bad application design, then.
Sometimes. Or bad toolkit design, or maybe just a different theme that the user selected. And it's only bad design if your trying to run your software over a high latency link, otherwise it's probably quite sane.
> Or if you really want fancy animations, you do as I suggested: Let the server do the fancy effects. The client sends a little bit of information specifying how to do the animation (start, number of steps, time increment, etc.) and the server handles it.
Ya. OpenGL works surprisingly well sometimes. When AIGLX first was supported on my video card I ran 1024x768 Wolfenstien (Quake3 improved engine) over wireless. Worked very well and I got about 48-60 FPS.
It was playable for the most part, except the mouse lagged horribly. Keyboard input was fast and everything rendered fine otherwise.
Cairo and Clutter may help out quite a bit I suppose. I don't know for certain.
> Augmenting X or something similar to do that wouldn't be too hard.
It's called NoMachine NX. ;)
LPC: Life after X Posted Nov 7, 2010 7:14 UTC (Sun) by mfedyk (guest, #55303) [Link]
"It was playable for the most part, except the mouse lagged horribly. Keyboard input was fast and everything rendered fine otherwise."
that is because mouse processing takes so many round trips. to see this in action run dstat in a terminal, then move your mouse in a slow steady circle. your context switches per second will go up several hundred.
Facts of life Posted Nov 7, 2010 15:35 UTC (Sun) by khim (subscriber, #9252) [Link] So it's just bad application design, then. Sure. Or if you really want fancy animations, you do as I suggested: Let the server do the fancy effects. No - because client-side solution is even simpler to implement. The client sends a little bit of information specifying how to do the animation (start, number of steps, time increment, etc.) and the server handles it. No again. It's harder then to write the loop in program. Augmenting X or something similar to do that wouldn't be too hard. Well - can you do it in such a way as to make that it's easier to use your scheme then the naive animation implementation? You can not do that. Applications the sole justification for the fancy protocols, kernels and computers. Thus application writers dictate the rules. The only time when you can impose some restrictions is when they are caused by the law of physics. Because it's the only situation where all alternatives will impose the same restrictions so application developers will have no choice: otherwise the solution with the simplest usage from coder POV will always win. Witness fate of transputers and modern CPUs: today way have 16-way SMP on desktop while transputers offered 32 or 64 twenty years ago. Why we've only switched to SMP on desktop five years ago? Easy: before that it was possible to create more and more powerful UP machines. Only when UP machines hit the hard limit (speed of light, essentially) the direction changed. The same with animated menus today: application developers do and will continue to do applications which abuse fast CPU<->GPU connection till it works on desktop. They will not change their designs to accommodate "network transparency" - because their users mostly don't care. Thus all these ideas are not worth even talking about. If you can explain why/if they will stop working even on desktop - we can talk about redesign.
LPC: Life after X Posted Nov 8, 2010 4:46 UTC (Mon) by elanthis (guest, #6227) [Link]
Your so-called solutions goes against X's core design and principle, though. X doesn't do fancy effects, or any effects. X is mechanism, not policy. X is just a dumb rendering and event pipeline, by design.
The drawing primitives suck. You may not realize this, it's probably been a long time since you've seen or worked with a mainstream app that limits itself solely to the X drawing primitives (probably).
We don't want that. Users don't want that. The whole world -- other than a teeny tiny little fraction of people so small in significance as to be entirely irrelevant -- wants pretty UIs. Pretty UIs are actually _more usable_, as tasteful and skillful application of that prettiness results in more easily comprehensible and digestible information display and user focus direction. Put plainly: that shit matters.
If you're really that interested in continuing to use the Xerox Parc UI innovations and nothing else, knock yourself out. Arguing today that the people designing the graphics framework that goes beyond what X is capable of should instead stick to basic rendering primitives is every last bit as stupid as an old-time radio host arguing the radio is the best media ever while the Internet already started killing off TV which already killed radio dead.
The other problem is that you seem to have no grasp of how modern rendering is done. When I say "the client" does the rendering, what I actually mean is that the client is programming a GPU to do the rendering. What you end up wanting to do things your way then is a complete implementation of OpenGL over the pipe (which GLX is NOT in any way). You also completely ignored the parts about using the GPU for more than just graphics, too, including input handling and other general computation that you absolutely do not want in the display server, at all, period.
Your notion of how the desktop should work is wrong, dated, and (thankfully) totally irrelevant as you're not the one making the development decisions.
LPC: Life after X Posted Nov 8, 2010 9:27 UTC (Mon) by quotemstr (subscriber, #45331) [Link]
You missed the point. He's proposing something like a motion-XRENDER, not animation done using the traditional drawing primitives. There is no reason modern UIs cannot be accommodated in X's extension framework. If people like you make "development decisions", we'll all be impoverished.
LPC: Life after X Posted Nov 8, 2010 16:44 UTC (Mon) by dskoll (subscriber, #1630) [Link] Your so-called solutions goes against X's core design and principle, though. X doesn't do fancy effects, or any effects. X is mechanism, not policy. X is just a dumb rendering and event pipeline, by design. Yeah, so? Change that aspect of X rather than throwing out the whole thing. Eventually, the best way to do things would be to have toolkits like Qt and Gtk be loadable modules that get installed in the X server rather than in client applications. That could greatly reduce the number of network round-trips required and greatly mitigate the latency problem. There are plenty of security concerns with this, of course. You wouldn't want to load Gtk or Qt into the X server unless it's running with your UID. But that's a much easier problem to solve and a much smoother transition to the future than throwing out X completely.
Smooth transition? From what? Posted Nov 9, 2010 15:23 UTC (Tue) by khim (subscriber, #9252) [Link] But that's a much easier problem to solve and a much smoother transition to the future than throwing out X completely. How come? You seem to assume that developers are using X and the only problem here is some shortcomings. Well, newsflash: no, they don't! Most applications today are written for Windows, PS3, Wii, iOS or Android. Not for X. Developers know toolkits (mostly GDI, but sometimes WPF or even Qt) and DirectX/OpenGL. They don't know X and then don't want to know X. This is fact of life. That's why all these band-aids are doomed: they impose burden on developers for megligible benefit. X is this thing down there which only exist to make our life misarable - this is POV of many (most?) developers. That's why it must be removed. Eventually, the best way to do things would be to have toolkits like Qt and Gtk be loadable modules that get installed in the X server rather than in client applications. But why introduce this stupid layer at all? Give the developers the means to run client app which talks with GPU and server - and he'll decide how to split the work. This is how it works on Windows, XBox360 and PS3 - and it certainly attracted significantly more developers then X redesigns ever could.
Smooth transition? From what? Posted Nov 17, 2010 7:11 UTC (Wed) by mcrbids (guest, #6453) [Link]
<QUOTE>Most applications today are written for Windows, PS3, Wii, iOS or Android. Not for X. Developers know toolkits (mostly GDI, but sometimes WPF or even Qt) and DirectX/OpenGL. They don't know X and then don't want to know X.</quote>
As an application developer with over 10 years of experience, I can say with certainty that this is not true, at least, not for me.
I don't write applications for Windows, PS3, Linux, Android, or *any* of the platforms listed. I write for the web browser! I write complex, data-driven applications and it's been a very, very long time since I wrote anything that wouldn't easily work on Win/Mac/Lin/Android/Iphone/Xbox and anything else with a reasonable browser.
The browser I most target is Firefox since it seems to be the most "Cross platform" although Chrome is close. I develop on Linux, it runs FF well, I don't worry about viruses and stuff like that, and can offer excellent compatibility with all my clients.
I don't want to replace X - I get the best of all possible worlds by making the specific rendering requirements of my applications something handled by the context of the user. And I use network transparency all the time - I can run several Firefox instances concurrently, on the desktop, as different users, without any danger of cookie or session interaction between browsers. As a web-based, network application developer, this is so incredibly useful!
LPC: Life after X Posted Nov 8, 2010 16:48 UTC (Mon) by dskoll (subscriber, #1630) [Link] Your notion of how the desktop should work is wrong, dated, and (thankfully) totally irrelevant as you're not the one making the development decisions. That certainly deserves a *plonk*. How about trying to stay civil?
LPC: Life after X Posted Nov 8, 2010 12:16 UTC (Mon) by dgm (subscriber, #49227) [Link]
> The problem is that apps decided they wanted fancy textures, background images, etc.
No, the problem is that users want this. You can blame them as much as you want, but it's all futile because in the end users still want that.
We have two options, we can build the stuff that's needed, of we can close our selves in our small ivory tower and wait until the world goes away. Which one do you want to chose?
LPC: Life after X Posted Nov 8, 2010 14:17 UTC (Mon) by madscientist (subscriber, #16861) [Link]
> We have two options, we can build the stuff that's needed, of we can
> close our selves in our small ivory tower and wait until the world > goes away.
The question is, build what's needed by WHOM?
You've had many, many people (myself included) state that what the users (us) want and need is the equivalent of today's network transparency features that X provides.
Yet many people here seem perfectly happy to ignore and pooh-pooh the users who really matter (those that we already have!) in some quest to obtain users that we don't have (those that use, and almost certainly will continue to use, Macs and Windows systems).
Ivory tower dwellers are people too!
WHOM is right :-) Posted Nov 9, 2010 15:57 UTC (Tue) by khim (subscriber, #9252) [Link] The question is, build what's needed by WHOM? Well, paying customers, obviously. Someone must pay for the development of the new hardware and software - and "he who pays the piper calls the tune". You've had many, many people (myself included) state that what the users (us) want and need is the equivalent of today's network transparency features that X provides. Sure. And there are many, many people who care about z80 programming on TI-84. Should we now think about z80 compatibility when we write USB drivers? Yet many people here seem perfectly happy to ignore and pooh-pooh the users who really matter (those that we already have!) in some quest to obtain users that we don't have (those that use, and almost certainly will continue to use, Macs and Windows systems). Huh? Where have you got this idea? Fact: most Linux users don't care about network transparency at all. Proof: more then 50 million Android phones were sold till now. There are less then 1.5 billions PCs in the world today so if we assume 3% of them are using Linux (typical estimate) we'll find out that there are more Android users then desktop Linux users. "Traditional Linux users" who care about network transparency and other such things are fast becoming minority - and this is exactly why we are talking about "life after X" today. We can, of course, say that we only care about ourselves and say that Android, ChromeOS, MeeGo and other such things are "not Linux" and "we don't care" - but it'll only mean that Linux will be left in dust and non-Linux (based on the same kernel!) will replace it.
WHOM is right :-) Posted Nov 12, 2010 0:40 UTC (Fri) by jmorris42 (subscriber, #2203) [Link]
> Proof: more then 50 million Android phones were sold till now.
Who cares. Seriously, counting Android as Linux users is as crazy as counting OS X users as UNIX, in both cases the *NIX underpinnings are only used as a hardware abstraction to host an alien environment to the typical Linux/GNU/X we typically call "Linux" as a shorthand. More power to em and all, but lets not make Apples to Oranges comparisions.
> "Traditional Linux users" who care about network transparency
Well take yer asses off and do your clone of all the bad ideas the existing userbase fled screaming from. It is Free Software after all. Here is a clue: Most of us came to *NIX because we saw the benefits and could also see the horrid mess the DOS/Windows world was. Why do we now want to toss one of the most wonderful ideas in computing to become more like the mass market drones? The network is the computer, the computer is the network. It isn't just a marketing slogan for some of us.
Besides, I never understood why suddenly everything needs to be rendered client side as bitmaps. Extend X to give it the mechanisms to support things it can't currently do and make sure they can run over the wire. Why can't X do the modern font tricks, compositing or whatever over the wire? Why isn't the default scalable SVG artwork? Isn't it normally sufficient to note that Apple does something enough to end an argument? Well they do Display Postscript (ok, they had to modernize the terminology to Display PDF) on OS X so obviously the idea is still mainstream, right?
Is it good that Linux is finally getting the last chunk of device support and taking over mode setting and general driving of the video hardware? Of course. Is it good that makes it easier for upstarts to experiment with new display systems? Of course! Might this someday lead to replacement for X? Perhaps. But any replacement has to be able to do the things X does if the target is a general computing environment instead of embedded. We have decades of existing apps and little desire to toss em all and start over. If we wanted to do that we could all just ditch the whole stack and go run Haiku or something.
LPC: Life after X Posted Nov 11, 2010 10:09 UTC (Thu) by dgm (subscriber, #49227) [Link]
> The question is, build what's needed by WHOM?
By us, of course! I'm sorry, because I'm going to introduce a little bit of FUD, but I think it's a healthy dose:
The problem is not that we are not well served by what we currently have. The problem is that most computer users out there are not. And as a consequence those people select other operating systems. Why should we care? Because marginal platforms can only survive thus far. Yes, there are still people writing code for the C64 and the Amiga, but they are few and mostly irrelevant, except for themselves. Do you want to see Linux there? I certainly don't.
So, It's OUR need to appeal to as many users as we can, and serve them well in as many use cases as we can, to ensure our own survival. Specialization and immobilism will be death for the platform.
LPC: Life after X Posted Nov 6, 2010 20:48 UTC (Sat) by njs (guest, #40338) [Link]
> Redirect the app to an offscreen buffer (just like the compositor already does), but instead of rendering it to the screen you instead compress, motion-diff, and encode the data and push it across a channel in your SSH session (just like X already does), and then the remote end decodes and displays the result. Send input events back. Super easy
Yeah, it's entirely feasible to do this with the current X stack (start a head-less X session, run apps in there, and then attach as a compositing manager to get at the pixels in each window and ship them across SSH individually). I use this every day, and the initial version was a two weekend hack.
It turns out that all the hard parts are in dealing with X nonsense -- coordinating app<->WM interaction between the two sides is nasty, you have to juggle this ridiculous stack with your headless X server, and I'm not convinced that it's possible to get keyboard handling really right.
So I agree with those saying that X network transparency is not very interesting anymore -- we can and will accomplish network transparency somehow, and it'll likely be better for not being baked into the gui system itself. OTOH, a lot of that complexity I mention is just intrinsic in the task -- you need conventions for how apps will talk with each other, input will be configured and routed, etc., and that complexity will end up in your protocol one way or another.
|
|||||||||||||