Actually, I do. Ages ago, being impressed by X11 I wanted to have something like that for Windows, so I went and built a GDI over Network layer; technically it consisted of loads of API hooks and DLL injections, it has no security or encryption. But it works. One can do remote GDI32 with it, at least using WinNT and Win2k. Never went ahead to test it with XP, Vista or 7.
It’s so rarely used, because people are not aware it is possible at all. Whenever I do this things in front of people unware of the possibilites we have for over 20 years now, their jaws drop almost to the earth’s core (also mostly they’re dumbstruck for several minutes then). People would use it, if they knew it was possible, trust me on that one.
The point is: If operating systems and network protocols provided strong security, applications don’t even have to bother about it, but just do their thing (just like remote display services), a lot of the issues we have nowadays would vanish; this would also includes getting rid of SSL and x509, which actually should be considered security threats these days, just google for “Diginotar” and “Honest Achmed Certificates”). A security protocol being broken? Update the OS and you’re fine, no need to patch each application individually.
I fully understand that neither X11 nor today’s operating systems are up for the job. However, by completely ditching the ideas of X11, sticking one’s fingers in his ears, humming “we don’t need network transparent display services; we use web technology, hence are distributed (which you are not, BTW)” is IMHO a most offensive disgrace of what people already did develop. Development of web technologies is driven by commercial internest. As such most of the stuff you find are ugly hacks, provisive kludges and not well thought about designs. Its like IBM PCs, being the outdated technology they were already when they were introduced, the shear weight of one single firm crushed the far more advanced Amigas and Ataris (on which I BTW did learn programming).
I also understand the many shortcomings of the X11 protocol. I don’t cling to X11 in particular in any way, as far as functional alternatives are concerned. Unfortunately there are none. I did sketch some ideas for a 21st century remote display protocol, that doesn’t just pushes around compressed images, but so far they only exist in form of drawings in my notebook.
Already I’m very unhappy with what happens on the Linux Desktop front. The whole thing gets dumbed down to resemble Apple and/or Windows machines. I own a Mac, I develop for MacOS X, and I hate it with passion.
Already I’m considering switching to some *BSD. Already some batshits at RedHat or Canonical think they know better than me, what I want. The day they decide they go Steve ‘I dictate what you want’ Jobs with Linux, i.e. ditch X11 this will be the last day of me using Linux. X11 is not the problem of Linux. Average users absolutely don’t care about the underlying display system. And there are not few powerusers who use Linux because it has X11.
Yeah, just turn the webbrowser into some kind of operating system of its own. Layers stacked on layers…
I bet in a few years, someone in the webbrowser business will have the “groundbreaking” idea of giving users the ability to make kernel syscalls. I like my webbrowser as a thing that processes and displays markup, executes as little code it loads from websites as possible and that’s it. I enable JavaScript strictly on a as-needed basis.
WebGL is incredibly cool and we’ll probably see a lot of online games shifting away from using native clients installed on the user’s system to the game client running in the browser. But WebGL is not remote rendering/display in the traditional sense. It’s like Java+JOGL, only with the JRE replaced with the JavaScript interpreter/JIT in the browser.
Oh well, no longer really on the original topic, but I am game.
It’s so rarely used, because people are not aware it is possible at all. Whenever I do this things in front of people unware of the possibilites we have for over 20 years now, their jaws drop almost to the earth’s core (also mostly they’re dumbstruck for several minutes then). People would use it, if they knew it was possible, trust me on that one.
I thought it was cool over 14 years ago… even had X11 server running on Windows 95 machines… ah fond idiotic nerd memories. There are even a couple of commercial X11 servers for MS-Windows (or alteast there have been) and there are some open source ones too. At the end of day, if there was a big commercial need for it, it would be used. Xorg (and before that xfree86) are open source software with very, very liberal licences. If there was a real commercial demand (or really even use) we would have seen more devices have X11 or a different network transparent display system. But we don’t. It seeks to solve a problem that although neat to see solved, is almost pointless.
A security protocol being broken? Update the OS and you’re fine, no need to patch each application individually.
ROFL. Really. Security is more than just the protocol and encryption scheme.
Already some batshits at RedHat or Canonical think they know better than me, what I want.
Did it ever occur to try to figure out why others walk the path they do? Did you ever consider examining their goals? Once you understand their goals you can understand why they do what they do. On the other hand, I am sure I can dig up an ancient Sparc from 1993 I used and you can play with that…with your notebook.
However, by completely ditching the ideas of X11, sticking one’s fingers in his ears, humming "we don’t need network transparent display services; we use web technology, hence are distributed…
WebGL is incredibly cool and we’ll probably see a lot of online games shifting away from using native clients installed on the user’s system to the game client running in the browser. But WebGL is not remote rendering/display in the traditional sense. It’s like Java+JOGL, only with the JRE replaced with the JavaScript interpreter/JIT in the browser.
Just to be clear: WebGL is a specification of binding the GL API (essentially OpenGL ES2) to JavaScript. The point is that remote rendering/display is just usually absolutely awful for performance, responsiveness and bandwidth consumption. Think of how many bytes are going to be sent all the freaking time with remote viewing with each draw. Nevermind the simple observation that usually the closer the machine is that is running your magic, the better off you are.
I bet in a few years, someone in the webbrowser business will have the “groundbreaking” idea of giving users the ability to make kernel syscalls.
Oh what the hell: it was called ActiveX. Snickers… that is not really true, but close enough.
I like my webbrowser as a thing that processes and displays markup, executes as little code it loads from websites as possible and that’s it. I enable JavaScript strictly on a as-needed basis.
Really, and what is “as needed”? Whenever there is a website you must access to you re-enable JavaScript? I guess all of Google’s offerings are a waste for you. But oh well with network transparent display system, you’ll have to trust lots of other places to have much more direct access to your GPU where as the browser bits, the data is validated before sent to the local GL(or D3D) implementation. Or someone will have to trust you to run your code on their machine to display it on yours. Um. The security fun will be fun.
Yeah, just turn the webbrowser into some kind of operating system of its own. Layers stacked on layers…
Spoken like someone that has never worked on browser implementation. But lets give you some hints ok. Read the WebKit source code and take a guess where most of it’s source code is spent handling. I’ll give you a hint: dealing HTML, CSS, etc. Even the rendering bits are only a tiny fraction of the WebKit source code.
Indeed, and that’s the problem: Many applications get security terribly wrong.
Example: Assuming: “It’s encrypted, so it’s secure”, completely neglegting the fact, that one can still corrupt the data and thus break the application (denial of service). Or not having a proper key exchange scheme, or having too few bits of entropy, or…
The problem spans misunderstanding of how to use salts, NIH implementations of cryptoalgorithms prone to side channel attacks, key exposure, timing attacks, etc. etc.
Security is such a vast and complicated field, that it should be part of the operating system services, something on which applications can build and rely upon. Also security should not be considered optional. Ideally a socket was always secured. Ideally the security is established by a web of trust, instead of CAs (which are prone to bribing, corruption, incompetence, actively being malicious) – I went as far as removing all CA root certs from my system and only accepting individual sites manually checking the SSL cert, considering if I actually trust the signing CA.
If I as a end user, being it a application programmer, or a application’s user, have to think about security, then something in the process is fundamentally wrong. We add red/yellow/green URL bars to browsers, warn about suspicious certificates, encrypt data. But this is all just reactive actionism, addressing one threat at a time.
Again I must tell you, your assumption is wrong. Around 1998 I implemented my own HTML4 parser and renderer for fun (and profit), also sending HTTP requests is easy so I added that, too – just out of curiosity. Then I implemented my own Webkit-frontend for SHR, and I’m familiar with Webkit’s sources to some degree. Add to this the product database frontend I did with xulrunner (thus covering Mozilla technology) for a small, local company I think I got my web technologies well covered.
But how does that make Webkit, or browsers in general not kind of operating systems?
The browser is a virtual machine. You feed it HTML, SVG and CSS and it renders display contents from it presenting it through an abstract screen. It gives you a DOM, representing the state and providing abstract methods for storage of the “program”'s data currently running. It provides scheduling for processes written in a scripting language.
Did you ever work on a IBM AS400 or System/36? Creating a program for those is not much different to creating a web application (I got in touch with both of them, developing aforementioned database frontend). There are the terminals, which have their own processors. Those are presented with “masks” by the mainframe (those masks came in some sort of markup, not unlike HTML with embedded CSS). One enters data into “form” areas in the mask, and once finished issues the “data release”. The terminal will first check the fields contents for validity, using code delivered with the mask (think JavaScript), then sends the data to the mainframe. However, all that processing happens by the small operating system in the terminal.
In the opposite direction I think it’s quite feasible to extend Webkit with a runtime environment, IP stack, input device access and framebuffer renderer, in such a way that it can run standalone without a “full blown” timesharing kernel. Ironically Linux’ development started out of a terminal emulator.
Maybe we’re just misunderstanding each other. To me a operating system is not just the kernel, it’s also all the system libraries, and services provided to applications. To web applications the webbrowser is their (client side) OS.
Let’s just assume, for that there are the GLX opcodes lacking, it was possible to issue a glMultiDrawElements call remotely, and that all arrays are in Buffer Objects, and that a single call to glMultiDrawElements renders the whole scene; hard to get right, difficult and inefficient in the shaders. One of course has to animate the thing, so he send a set of Uniforms beforehand. Let’s say ~200 single precision float vec4 uniforms. That makes 2400 octets. We assume use of a uniform buffer object, so a single call for that. Let’s say 50 distinct objects (of arbitrary geometric complexity, also we may use instancing), which amounts to 200 octets for the count array and 200 octets for the index array offsets. Finally lets assume a 30 octet overhead for each of those 2 calls, gratiously rounded up already but let’s go with 100 octets. This amounts for 2900 octets of data. That fits easily into a Ethernet Jumbo-Frame. But more importantly I’d like to see a high quality, compressed, arbitrarily high resolved image compressed into 3k, and let it be an B-frame. For high fidelity compressing a Full-HD video with x264 in paranoia profile you still need at least 5MBit/s at 24FPS for this to have no visible artifacts - more common are 3× the bitrate. Compare this with the mere uncompressed 800kbit/s for arbitrarily resolved rendering at the same framerate, and I bet one could put lzo on top of this and squeeze it down to 400kbit/s.
You are asking me how many octets are sent all the freaking time? I ask this you who proposes sending framebuffer contents, which not nearly compress as well, as a equally well performing alternative.
Yes, yes and yes.
Yes: I did indeed talk to the Wayland developers in IRC
They want to get X11 out of the way, so that clients can talk to the display device directly (I’m not saying hardware, as this may be a virtual machine – oh, VM’s, how did I forget, another area where networked graphics shines, I have no idea how you’d want to put a GPU into a virtual machine, the best I can think of is passing the device down to the VM, but then the Host no longer can use it). Rendering content is delegated to special purpose libraries, which do the talking to the hardware (OpenGL, OpenVG, Cairo, whatever). Another issue is getting compositing right. On this topic I spent 3 hours on the #wayland IRC channel discussing the topic. And I did not get the impression that the problems of Compositing truly were understood. I know of two particular problems with Compositing: Latency (the compositor has to wait for all clients to finish their rendering before compositing can take place) and synchronization: do clients sync to V-Blank (no tearing, but at least 1 frame latency), last client finishing (slowest client dragging on the rest causing frame drops), no sync (compositor pulls frames as needed, will cause tearing), sync to compositor (uneven frame periods, difficult to sync with), deadline (estimating time required for compositing, syncing clients to a deadline about that time + a guard before V-Blank, best solution IMHO). I was thinking about those problems from the very day Xgl, then AIGLX saw the light of day, and ever since I came to the conclusion that the deadline approach would work best. To my surprise none of the Wayland developers had thought about that then.
The why is really what puzzles me here. I understand their motivation but it seems to me too short sighted. If you want to replace X11 with something cleaned up, yet still this flexible, well, to quote a reddit meme: “shutthefuckup and take my money”. But I don’t see the flexibilty in the new approach. Running X11 on top of Wayland doesn’t seem so performant, not to mention elegant to me. And it still completely neglegts the requirement for a display system to not only provide buffers, but that there’s also the need to draw something to those buffers. Believe it or not, but around 2006 to 2008 I was thinking about how one could improve Linux’ graphics architecture, and for some time my favourite idea was quite what Wayland is – so I not only saw the rationale as an outsider, I pretty much know about the thinking process. At that time (luckily in retrospect) I was busy getting essential exams done for my “Vordiplom” (kind of a Bachelor’s degree), but my considerations went on, so I never implemented something. And then I abandoned the whole idea, because something was missing in the picture. X11 has the advantage of providing the tools for filling the buffers (drawables) with content. And it actually allowed for taking care of target device specific adjustments in the render process. Having to implement the whole of X11 for a X server is always put on the wall as the biggest drawback of X; I don’t think so (anymore), it gives one a defined interface to work with, although the interface has some well known, and arcane issues that need to be fixed (somebody should specify a X11.1 just to address that). And then there’s one thing about Wayland I really don’t like at all: Wayland puts the compositor also in charge of input processing and window management. So one can no longer implement “just” a window manager. One has to deal with reading events from the kernel and pass them to the clients as well. Now, I’ve written some evdev and libusb/libhid code before, most notably a open source driver for the 3Dconnexion SpaceNavigator: Which presents itself as a relative motion 6 axis device, while it actually measures absolute values, and indicates zero position by not sending events at all, totally messed up. It’s quirks like those for the SpaceNavigator, which would be required in each and every Wayland compositor-windowmanager-inputprocessor or in some input-quirks library to take care of this, which I frown upon. I submitted my quirks to the X.org evdev driver maintainers, so this problem has been addressed there. A window manager is a window manager and shouldn’t be required to deal with the dirty details of broken input devices.
I have two of those, though they’re not that old, add some 8 years. But there’s nothing special about Sparcs that designates them for X11. You could run Wayland on them just fine. Or Plan9, what I have installed on them ATM.
I highly doubt that, unless somebody came up with a Paper-to-IP interface. I was talking about a dead-tree notebook. You know, pencil and paper (and a eraser).