Apparently you talked to somebody because this clause seems to be to patch a legal hole in this idea:
c) The license under which the derivative work is distributed must expressly prohibit the distribution of further derivative works.
I suspect you are granting too many rights to the code to prevent it from being extended with GPL code legally, and that possibly this clause fixes it.
I certainly see what you are trying to do but I would prefer some kind of modification of the LGPL where it explicitly says this code can be "used for it's intented purpose" but not "modified" without releasing the source code to the modifications. Ie none of this crap about whether it is dynamically linked or not. In your instance this would allow the TCP/IP code to be used in any operating system, but if (for instance) Micorsoft fixed a bug in the TCP/IP code itself it would be forced to release the code for the bug fix, with no effect on keeping the rest of their system closed.
A huge problem with using your idea to promote standards is that Microsoft and maybe others can "embrace and extend". More worrysome than some evil plan (Microsoft's engineers aren't that evil I think) but that bugs will get introduced to the closed-source versions that end up making the variations non-standard. I don't think this can be avoided unless the code is forced to be available.
Old graphics calls could be emulated with software to get pixel-identical results. Speed is irrelevant if that is necessary. This could probably be done by some environment variable before the program is started to load "legacy Xlib". By default it should load "fast Xlib" that crudly emulates the old calls in the fastest simulation, and also provides the "new" graphics interface.
Insistence on pixel-accurate X emulation killed NeWS 10 years ago. Lets not do that again...
I agree it can't get rid of the clipping regions, they are very useful for producing some graphics. However it would eliminate the need for the server to produce any clipping regions (other than a rectangle around the outer bounds of the window's texture memory). All complex clip regions would be part of the graphics context and under program control.
I agree that windows you can actually see through the middle of are nearly worthless except as eye candy.
However this is important in that it allows antialiased edges to the windows. Once X and Windows get off their asses and do anti-aliased polygons (like Flash and so on have done for 5 years), the window edges are the only aliased images left on the screen. True antialiasing of the edges will allow nice looking windows that are not rectangles.
Antialiased pixels are actually partially transparent. I believe support of them requires pretty much all the support that fully-transparent windows needs. Even more, ie better than the Windows hack a year ago where the transparency is equal everywhere, as the transparency is per-pixel (this OpenGL X, according to the docs, does support per-pixel transparency).
This also allows shadows along the edge, which can be nice. But the simple compositing supported by the current hardware is not going to make them as realistic as they could be, and I expect such shadows will be improved with other schemes in the future.
So the real win here is antialiased edges.
The other thing this provides as a side-effect is double-buffering. If you can manage to not redraw the screen until the texture map is updated to a stable state, the display will not blink no matter how stupid the program drawing the window is.
Ie Microsoft feels the only way they can protect XBOX is to completely seperate the system that can run anything from the "protected" system and make it impossible for the unprotected stuff from doing anything to the protected system. In the XBOX case (and also the Sony playstation and in DirectTV and many other consumer devices) the method is to use completely different hardware. However Palladium is an attempt to make a single piece of hardware act like two.
There is no way for Palladium to provide "DRM" unless there are serious restrictions on non-Palladium programs. The non-Palladium programs will be able to do about as much as that copy of Doom 3 running on a PC can do to the XBox sitting next to the PC. Most people would not consider that copy of Doom 3 to be running "on" the Xbox. Non-palladium programs will be "running" on the Palladium PC in approximately the same way.
All it takes is *ONE* useful program that requires Palladium for every user to switch it on permantly.
Of course the machine with Palladium on will run old software. Otherwise users would have the opposite incentive and be forced to turn Palladium off. MicroSoft obviously does not want that. Don't think they are doing it for any benevolent reason!
Palladium has absolutely ZERO effect on any end-user security. If the end user has a desire to be secure and has control of the machine Palladium adds NOTHING, NADA, ZILCH. All talk about "security" is a smokescreen.
Palladium cannot stop viruses at all unless all "trusted" programs that could be told to execute the virus instructions actually can't do anything, which would mean the computer is useless. Outlook viruses work by doing things that the "trusted" program Outlook thinks are perfectly benign, the actions are harmful either due to bugs in Outlook or mistakes in it's design. All palladium does is "sign" the bugs in programs and then claim they are "trusted" as though that magically made the bugs go away. It provides no more help than the kernel-mode bit that is already in the hardware and is used by Linux and Windows and does not seem to have stopped viruses on either one of them.
The purpose of Palladium is for Digital Restrictions Management (DRM). There is NO other reason for Palladium. NONE. It's purpose is to make sure that certain programs (everything not written by MicroSoft) does not run on the machine.
The "target" audience is MicroSoft themselves. They are trying to make a machine that is acceptable for playing digital content, with a design that guarantees that alternative operating systems are totally unable to play this content. Far more reliable DRM systems (hardware cards) that would work under Linux are discouraged because of the bogus promises of Palladium.
Actually none, it is copyrighted (unless some is old enough that the copyright has expired).
Normal copyright means you can't copy and distribute the information without permission from the original copyright owner.
Public-domain means you can copy and distribute it no matter what.
The GPL is in-between in that if you follow some rules you can copy and distribute it as though it was public domain. You can also follow normal copyright rules and ask for permission to do anything else with the code (a fact that Microsoft and others always ignore when arguing against the GPL).
So anyway the joke would be more like RMS being able to say "the GPL is no longer on all that code and it reverts to normal copyright, and you now must pay me to redistribute it".
Using VNC only is equivalent to arguing that "remote should not be supported". Obvously you can do some hack so the resulting picture is on another machine, you could point a video camera at the screen if you needed to. Arguing for this idea is logical, and should not be discounted.
But there seems to be some misconception that if the code to talk to remote servers was deleted from Xlib, with no other changes, that it would magically solve all the problems. I am saying that people who claim that don't know what they are talking about.
Well GTK/Qt draw a "button" without a "button manager" program running. There seems to be a lot less trouble with buttons blinking, or with latency when the user clicks a button, or with annoying bugs where the buttons react in a different order than the order the user clicked on them.
There is no reason the window borders cannot be done the same way.
Now it is true that the buttons can look different. However I think this could be solved by a "how do I draw a button" type call that everybody uses, rather than a "button manager". Same thing for window borders.
Per-window backing store would help considerably for moving windows around. It would also allow "transparent windows" (big deal) and more imporatantly it would allow shadows and anti-aliased edges of the windows.
One problems with per-window backing is that a lot of hardware acceleration does not support it (it supports "overlapping" backing store where only pixels that are visible on the screen have a backing store, this has the obvious advantage that the backing store memory is fixed-size and exactly the same size as the screen).
*Any* kind of backing store would go a long way to getting rid of blinking of displays. Even totally stupid programs would not blink, they would just have latency in getting the display updated. Also I suspect the methods used to avoid blinking on X and Win32 (ie complex clipping regions) are slower on hardware acceleration than "stupid" back-to-front drawing. X does support the DBX extension, but (like all extensions) it is a pain to use. I would prefer if you could just say "XSetDoubleBuffer(xid, true)" and it works if the server supports it, and it swaps buffers with a new code sent to the server at the moment Xlib does XGetNextEvent().
Unfortunately double buffering does not solve the resize behavior. Scaling the bitmaps is unlikely to produce a correct display, the reaction of programs to resizing is very complex. Describing the resize behavior in enough detail would require enormous amounts of data to be downloaded to the servers. Some people propose doing this (pretty much it means the entire toolkit is in the server). but I don't like that idea, as it makes the server very complex and freezes the toolkit design.
I see no solution other than a round trip to the program where it calculates and draws it's new resized display. Yes this introduces latency. However the hugest problem with X (and somewhat with Windows) is that the window resizes asynchronously with the contents, I would fix this by sending a "request to resize" to the client, so it can resize synchronously with the redraw. This will cause the resizing to lag behind the mouse but I believe this will look much better than the current blinking. I also do not believe it is possible to get nice resize drawing unless all items are drawn synchronously by the client, which is why I think the window decoration must be drawn by it as well. Latency can be improved by using display lists that contain some postscript-like math and if statements so they can draw in a given-sized box, but I would have the client invent all these display lists and send the boxes as part of it's redraw.
I have not had any luck in getting DefWindowProc to do anything different with events. It seems to read them from storage that I can't modify, in fact I can send total garbage to DefWindowProc and it still "works". In any case the result is equivalent to what X does: the system resizes the window, tells the program about it, and then the program can change it's mind and resize again. The problem is that the user sees (even for a split second) the initially-resized window (after that Windows does better than X because the new resize of the window and the redraw message are done synchronously by the system, while in X the new size is sent to the window manager which will asynchronously send resizes to the window frame and contents and also attempt to draw the window frame).
Huh? At least 60% of the "awards" are to liberal groups or individuals making asses of themselves. Such as throwing out right-wing newspapers on school campuses, or attacking a student's right of free speech because they said something religious. Yes the big awards go to the government, which happens to be Republican right now, but Democrats in power would get the big awards too.
I do agree about the stupid design of the message queues. All the messages should go to the first thread by default, no matter who creates the windows. Instead I have to be careful to create all windows in the same thread. And they MUST get rid of the assinine direct calls to WinProc, this has been a huge source of headaches and bugs (because if you destroy or change some object you must make sure any data that WinProc might look at is updated and consistent before calling ANY windows procedure, including things like WaitForObject! GAH!) This could easily be fixed by having anything that it wants to send to WinProc be sent through the GetMessage/DispatchMessage loop. Here X actually got things right and Windows loses.
Latency in dragging windows can be handled by a call that attaches a window to the cursor so it is dragged around until the mouse is released. There will be an initial latency while it decides to pick up the window but then it should move around absolutlely as fast and smooth as possible. This can probably be done by hardware nowadays, it really is just a giant mouse cursor.
I can't think of any good equivalent solutions for resizing, I think it should be left up to the program and there will be latency. However as the program can say "resize the window to this" and immediately follow it asynchronously with the new image for the resized window, there will be much less latency than the current version where the window is resized by the window manager and there has to be at least a round trip to the program to get the new drawing.
The drawing code definately should support display lists, though I don't think much of the complex structure is needed, because *some* communication is acceptable. A program that draws a hundred buttons of different sizes should be able to send a display list that can draw a button once (keeping it in the server much like an X pixmap) and then send on redraw it just has to send the rectangles and labels of all the buttons and the command to run the display list on each of them. I believe such a scheme would be much faster and easier to program than NeWS or Fresco designs where the programmer is forced to program to a layout scheme hardcoded into the server. In my experience such schemes require *more* code and communication, as the layout rules are far more complex than the resulting widget sizes. In addition, display lists designed like this would allow "themes" to be implemented by having programs retrieve named display lists that draw various items like buttons.
Having written a toolkit I can tell you that it takes far *MORE* code to talk to a window manager than it would take to draw the window borders myself (remember that the toolkit already has to draw buttons so it has the code to draw the beveled edges). The "window" object in fltk is easily more than twice the size of the text editing object.
And no matter how much code is added, I still can't get the interface to work correctly, for instance to stack the windows in the order I want, or to cleanly make a full-screen window, or to allow the window to be dragged or resized by grabbing some point inside the window. All of these would be trivial if override-redirect windows were used by all applications.
Also you said "GTK window decorations would probably look much different to KDE ones to any other TK out there" which is exactly what I expected. It took only 10 minutes for somebody to blurt out the "oh no it's inconsistent and will confuse the user". Let's try it and see rather than parrotting this crap. Somehow must people can push a button in both a KDE and Gnome app despite the different appearances...
Do you really want to move all that stuff (look, feel, window movements etc.) into GTK/Qt
Yes.
I am not very familiar with fltk (so may be you could elaborate on this too).
Fltk is one of the second-tier toolkits (there is also Fox, JX, and several others which are used about the same amount). Whether or not fltk is any good, I think any reasonable window system should allow alternative toolkits. People are happy that Linux can run both Python and Perl and nobody says "but they are inconsistent and will confuse the user" but for some reason everybody gets all nutty when the idea of multiple user interface toolkits comes up.
I expect the Qt and GTK (and other) toolkits will be rewritten to take advantage of the new X server. I very much recommend against and hope to not see an attempt by X to take functions from toolkits other than drawing libraries.
From an end-user point of view there will probably remain at least two competing "desktops". It would be a good idea to make X drawing powerful enough that "theming" is trivial and that can be shared by different toolkits easily, this would eliminate 99.5% of the complaints about working with both KDE and Gnome.
I would like to see window managers eliminated and the functions moved to the toolkits. I'm not sure if that is what is intended but I feel it would be a huge improvement to X. This of course eliminates all the window managers and means the toolkit writers will have to do some work to add the window borders (though I suspect that is *less* work than it currently takes to communicate with a window manager).
This seems to be a common request here but it is wrong. X can use a number of protocols to update the display, it is possible to write a program were everything is done in client space. In current implementations of Xlib the fact that the display is local is detected and large amounts of code is swapped so that it talks to the server using very efficient mechanisms. So in a way "remote" has already been removed and is an option.
The remote ability of X does force design decisions in the protocol and interface, but you cannot remove these, because you would make "remote" impossible. Then you would have two display interfaces, one for local and one for remote.
You could make an argument that these design decisions are hurting X and that "remote" should be completely eradicated. That would be a logical argument (though I personally disagree).
But saying "remote should be an option" as though that is a physically possible solution is just wrong.
The horrid resizing behavior is due to the seperate window manager. There is absolutley no way to get a smooth update when two competing programs are resizing different parts of the display and there is no protocol method to say "don't draw this until this other thing happens".
The solution is to put the window manager into the toolkits like the buttons and everything else is. The result will be *better* than Windows, as Windows puts it in the server so there still is communication and it is impossible to do complex restrictions on the size of a window (such as a range of ratios or multiples of certain sizes) Windows also it relies of sending an event through the user program to synchronize the window changing size and the drawing, otherwise it would look as bad as X, but I don't recommend this route at all, just put the window borders into the user program.
The problem is that a thousand sheep here are going to bleat "but that will make it 'inconsistent' and it will 'confuse the user'". This naive response from so many is probably the most serious problem we are going to have in trying to fix X. Truth is: NOBODY is "confused" because the buttons are different colors, they are confused by crap interfaces! And the great Windows DOES NOT enforce lots of things (such as what shortcuts are used for menus) that people keep complaining about when they say that "windows is consistent and Linux is not". The truth is that "consistency" is the responsibility of the application programmers and trying to force it by making complex and slow interfaces so your favorite GUI method is forced on everybody is absolutely the WORST thing you can do.
Dragging windows (not resizing) does not have problems with the seperate window manager, so it is obvious that a lot of X programs do not respond to redraws very quickly. Some Windows programs have this problem too, but I would agree that not as many as Linux. Both X and GDI32 drawing engines suck almost equally badly so the amount of code in the app is about the same, and tests where lots of letters or rectangles are drawn indicate that GDI32 and Linux X are about equal speed. I suspect this is a combination of excessively complex toolkit programming and perhaps some basic failures of X such as an inability to deliver or respond to expose events quickly enough.
The tamper-proof data you are talking about can be done by "signing" it with a private key that is known only to a trusted party (for instance it can be burned into a tamper-proof chip in the original camera). This is an excellent idea and maybe should be added to all recording devices.
But it is not DRM. Anybody can copy the data, signature and all.
Openssh assummes the parties on both ends are interested in keeping the data secret. If the party on the other end of your ssh connection piped the data to a file that data would be quite readable despite having once been encrypted. The security relies on the fact that the party on the other end has no incentive to do such a thing.
Slashdot Mirror
c) The license under which the derivative work is distributed must expressly prohibit the distribution of further derivative works.
I suspect you are granting too many rights to the code to prevent it from being extended with GPL code legally, and that possibly this clause fixes it.
I certainly see what you are trying to do but I would prefer some kind of modification of the LGPL where it explicitly says this code can be "used for it's intented purpose" but not "modified" without releasing the source code to the modifications. Ie none of this crap about whether it is dynamically linked or not. In your instance this would allow the TCP/IP code to be used in any operating system, but if (for instance) Micorsoft fixed a bug in the TCP/IP code itself it would be forced to release the code for the bug fix, with no effect on keeping the rest of their system closed.
A huge problem with using your idea to promote standards is that Microsoft and maybe others can "embrace and extend". More worrysome than some evil plan (Microsoft's engineers aren't that evil I think) but that bugs will get introduced to the closed-source versions that end up making the variations non-standard. I don't think this can be avoided unless the code is forced to be available.
Insistence on pixel-accurate X emulation killed NeWS 10 years ago. Lets not do that again...
I agree it can't get rid of the clipping regions, they are very useful for producing some graphics. However it would eliminate the need for the server to produce any clipping regions (other than a rectangle around the outer bounds of the window's texture memory). All complex clip regions would be part of the graphics context and under program control.
However this is important in that it allows antialiased edges to the windows. Once X and Windows get off their asses and do anti-aliased polygons (like Flash and so on have done for 5 years), the window edges are the only aliased images left on the screen. True antialiasing of the edges will allow nice looking windows that are not rectangles.
Antialiased pixels are actually partially transparent. I believe support of them requires pretty much all the support that fully-transparent windows needs. Even more, ie better than the Windows hack a year ago where the transparency is equal everywhere, as the transparency is per-pixel (this OpenGL X, according to the docs, does support per-pixel transparency).
This also allows shadows along the edge, which can be nice. But the simple compositing supported by the current hardware is not going to make them as realistic as they could be, and I expect such shadows will be improved with other schemes in the future.
So the real win here is antialiased edges.
The other thing this provides as a side-effect is double-buffering. If you can manage to not redraw the screen until the texture map is updated to a stable state, the display will not blink no matter how stupid the program drawing the window is.
My god some people reading this site are stupid!
There is no way for Palladium to provide "DRM" unless there are serious restrictions on non-Palladium programs. The non-Palladium programs will be able to do about as much as that copy of Doom 3 running on a PC can do to the XBox sitting next to the PC. Most people would not consider that copy of Doom 3 to be running "on" the Xbox. Non-palladium programs will be "running" on the Palladium PC in approximately the same way.
I'll believe that when I see Microsoft make an XBOX that can run "unsigned" applications.
Ten years ago was 1993, not 1988.
Of course the machine with Palladium on will run old software. Otherwise users would have the opposite incentive and be forced to turn Palladium off. MicroSoft obviously does not want that. Don't think they are doing it for any benevolent reason!
Palladium cannot stop viruses at all unless all "trusted" programs that could be told to execute the virus instructions actually can't do anything, which would mean the computer is useless. Outlook viruses work by doing things that the "trusted" program Outlook thinks are perfectly benign, the actions are harmful either due to bugs in Outlook or mistakes in it's design. All palladium does is "sign" the bugs in programs and then claim they are "trusted" as though that magically made the bugs go away. It provides no more help than the kernel-mode bit that is already in the hardware and is used by Linux and Windows and does not seem to have stopped viruses on either one of them.
The purpose of Palladium is for Digital Restrictions Management (DRM). There is NO other reason for Palladium. NONE. It's purpose is to make sure that certain programs (everything not written by MicroSoft) does not run on the machine.
The "target" audience is MicroSoft themselves. They are trying to make a machine that is acceptable for playing digital content, with a design that guarantees that alternative operating systems are totally unable to play this content. Far more reliable DRM systems (hardware cards) that would work under Linux are discouraged because of the bogus promises of Palladium.
Normal copyright means you can't copy and distribute the information without permission from the original copyright owner.
Public-domain means you can copy and distribute it no matter what.
The GPL is in-between in that if you follow some rules you can copy and distribute it as though it was public domain. You can also follow normal copyright rules and ask for permission to do anything else with the code (a fact that Microsoft and others always ignore when arguing against the GPL).
So anyway the joke would be more like RMS being able to say "the GPL is no longer on all that code and it reverts to normal copyright, and you now must pay me to redistribute it".
But there seems to be some misconception that if the code to talk to remote servers was deleted from Xlib, with no other changes, that it would magically solve all the problems. I am saying that people who claim that don't know what they are talking about.
There is no reason the window borders cannot be done the same way.
Now it is true that the buttons can look different. However I think this could be solved by a "how do I draw a button" type call that everybody uses, rather than a "button manager". Same thing for window borders.
One problems with per-window backing is that a lot of hardware acceleration does not support it (it supports "overlapping" backing store where only pixels that are visible on the screen have a backing store, this has the obvious advantage that the backing store memory is fixed-size and exactly the same size as the screen).
*Any* kind of backing store would go a long way to getting rid of blinking of displays. Even totally stupid programs would not blink, they would just have latency in getting the display updated. Also I suspect the methods used to avoid blinking on X and Win32 (ie complex clipping regions) are slower on hardware acceleration than "stupid" back-to-front drawing. X does support the DBX extension, but (like all extensions) it is a pain to use. I would prefer if you could just say "XSetDoubleBuffer(xid, true)" and it works if the server supports it, and it swaps buffers with a new code sent to the server at the moment Xlib does XGetNextEvent().
Unfortunately double buffering does not solve the resize behavior. Scaling the bitmaps is unlikely to produce a correct display, the reaction of programs to resizing is very complex. Describing the resize behavior in enough detail would require enormous amounts of data to be downloaded to the servers. Some people propose doing this (pretty much it means the entire toolkit is in the server). but I don't like that idea, as it makes the server very complex and freezes the toolkit design.
I see no solution other than a round trip to the program where it calculates and draws it's new resized display. Yes this introduces latency. However the hugest problem with X (and somewhat with Windows) is that the window resizes asynchronously with the contents, I would fix this by sending a "request to resize" to the client, so it can resize synchronously with the redraw. This will cause the resizing to lag behind the mouse but I believe this will look much better than the current blinking. I also do not believe it is possible to get nice resize drawing unless all items are drawn synchronously by the client, which is why I think the window decoration must be drawn by it as well. Latency can be improved by using display lists that contain some postscript-like math and if statements so they can draw in a given-sized box, but I would have the client invent all these display lists and send the boxes as part of it's redraw.
I have not had any luck in getting DefWindowProc to do anything different with events. It seems to read them from storage that I can't modify, in fact I can send total garbage to DefWindowProc and it still "works". In any case the result is equivalent to what X does: the system resizes the window, tells the program about it, and then the program can change it's mind and resize again. The problem is that the user sees (even for a split second) the initially-resized window (after that Windows does better than X because the new resize of the window and the redraw message are done synchronously by the system, while in X the new size is sent to the window manager which will asynchronously send resizes to the window frame and contents and also attempt to draw the window frame).
Huh? At least 60% of the "awards" are to liberal groups or individuals making asses of themselves. Such as throwing out right-wing newspapers on school campuses, or attacking a student's right of free speech because they said something religious. Yes the big awards go to the government, which happens to be Republican right now, but Democrats in power would get the big awards too.
I do agree about the stupid design of the message queues. All the messages should go to the first thread by default, no matter who creates the windows. Instead I have to be careful to create all windows in the same thread. And they MUST get rid of the assinine direct calls to WinProc, this has been a huge source of headaches and bugs (because if you destroy or change some object you must make sure any data that WinProc might look at is updated and consistent before calling ANY windows procedure, including things like WaitForObject! GAH!) This could easily be fixed by having anything that it wants to send to WinProc be sent through the GetMessage/DispatchMessage loop. Here X actually got things right and Windows loses.
I can't think of any good equivalent solutions for resizing, I think it should be left up to the program and there will be latency. However as the program can say "resize the window to this" and immediately follow it asynchronously with the new image for the resized window, there will be much less latency than the current version where the window is resized by the window manager and there has to be at least a round trip to the program to get the new drawing.
The drawing code definately should support display lists, though I don't think much of the complex structure is needed, because *some* communication is acceptable. A program that draws a hundred buttons of different sizes should be able to send a display list that can draw a button once (keeping it in the server much like an X pixmap) and then send on redraw it just has to send the rectangles and labels of all the buttons and the command to run the display list on each of them. I believe such a scheme would be much faster and easier to program than NeWS or Fresco designs where the programmer is forced to program to a layout scheme hardcoded into the server. In my experience such schemes require *more* code and communication, as the layout rules are far more complex than the resulting widget sizes. In addition, display lists designed like this would allow "themes" to be implemented by having programs retrieve named display lists that draw various items like buttons.
And no matter how much code is added, I still can't get the interface to work correctly, for instance to stack the windows in the order I want, or to cleanly make a full-screen window, or to allow the window to be dragged or resized by grabbing some point inside the window. All of these would be trivial if override-redirect windows were used by all applications.
Also you said "GTK window decorations would probably look much different to KDE ones to any other TK out there" which is exactly what I expected. It took only 10 minutes for somebody to blurt out the "oh no it's inconsistent and will confuse the user". Let's try it and see rather than parrotting this crap. Somehow must people can push a button in both a KDE and Gnome app despite the different appearances...
Yes.
I am not very familiar with fltk (so may be you could elaborate on this too).
Fltk is one of the second-tier toolkits (there is also Fox, JX, and several others which are used about the same amount). Whether or not fltk is any good, I think any reasonable window system should allow alternative toolkits. People are happy that Linux can run both Python and Perl and nobody says "but they are inconsistent and will confuse the user" but for some reason everybody gets all nutty when the idea of multiple user interface toolkits comes up.
From an end-user point of view there will probably remain at least two competing "desktops". It would be a good idea to make X drawing powerful enough that "theming" is trivial and that can be shared by different toolkits easily, this would eliminate 99.5% of the complaints about working with both KDE and Gnome.
I would like to see window managers eliminated and the functions moved to the toolkits. I'm not sure if that is what is intended but I feel it would be a huge improvement to X. This of course eliminates all the window managers and means the toolkit writers will have to do some work to add the window borders (though I suspect that is *less* work than it currently takes to communicate with a window manager).
The remote ability of X does force design decisions in the protocol and interface, but you cannot remove these, because you would make "remote" impossible. Then you would have two display interfaces, one for local and one for remote.
You could make an argument that these design decisions are hurting X and that "remote" should be completely eradicated. That would be a logical argument (though I personally disagree).
But saying "remote should be an option" as though that is a physically possible solution is just wrong.
The solution is to put the window manager into the toolkits like the buttons and everything else is. The result will be *better* than Windows, as Windows puts it in the server so there still is communication and it is impossible to do complex restrictions on the size of a window (such as a range of ratios or multiples of certain sizes) Windows also it relies of sending an event through the user program to synchronize the window changing size and the drawing, otherwise it would look as bad as X, but I don't recommend this route at all, just put the window borders into the user program.
The problem is that a thousand sheep here are going to bleat "but that will make it 'inconsistent' and it will 'confuse the user'". This naive response from so many is probably the most serious problem we are going to have in trying to fix X. Truth is: NOBODY is "confused" because the buttons are different colors, they are confused by crap interfaces! And the great Windows DOES NOT enforce lots of things (such as what shortcuts are used for menus) that people keep complaining about when they say that "windows is consistent and Linux is not". The truth is that "consistency" is the responsibility of the application programmers and trying to force it by making complex and slow interfaces so your favorite GUI method is forced on everybody is absolutely the WORST thing you can do.
Dragging windows (not resizing) does not have problems with the seperate window manager, so it is obvious that a lot of X programs do not respond to redraws very quickly. Some Windows programs have this problem too, but I would agree that not as many as Linux. Both X and GDI32 drawing engines suck almost equally badly so the amount of code in the app is about the same, and tests where lots of letters or rectangles are drawn indicate that GDI32 and Linux X are about equal speed. I suspect this is a combination of excessively complex toolkit programming and perhaps some basic failures of X such as an inability to deliver or respond to expose events quickly enough.
But it is not DRM. Anybody can copy the data, signature and all.
Openssh assummes the parties on both ends are interested in keeping the data secret. If the party on the other end of your ssh connection piped the data to a file that data would be quite readable despite having once been encrypted. The security relies on the fact that the party on the other end has no incentive to do such a thing.