"under some circumstances, X will store arbitrarily large amounts of pixel data *outside* of the windows bounds"
"Arbitrarily large amounts" is the same as saying "any number of units between 1 and infinity". Are you talking about an X which is a Universal Turing Machine:-) Are you sure you meant to refer to X instead of XFree86. In other words, have you really identified a problem in the design of X rather than a bug in the implementation in XFree86? Whether or not you like the design of backing-store mechanism in X, there are commercial Xservers which have implementations of backing-store that correctly follow the X specification.
"No, it's not the App's fault. [...] The platform is
flawed. I don't have time to completely research the interface"
I'm sorry but you are displaying your total ignorance of the design of X and making completely unjustified and incorrect criticisms in bold font as if to boast of your misplaced confidence. Please read the design documentation for X before you post about X again.
X has always provided a mechanism for storing and communicating byte-sequences between X applications. Few X application programmers have bothered to read the excellent design documentation for X which is a shame because if they had they would understand how to implement cut-and-paste together with content negotiation. Implementing consistent cut-and-paste in X applications is really as simple as following the very clear guidelines in the excellent explanation by Jamie Zawinski written many years ago.
P.S. Your pseudo-Japanese username "Minna Kirai" (literally meaning that you hate everyone) would be better as Shigoto Kirai (literally meaning that you hate work like reading about the design of X).
I see there are people saying again that X cannot do flicker-free graphics because it lacks double-buffering. However, I'd like to point out that X has had the Double Buffer Extension since about 1994.
For an excellent example of how to do double-buffering in X, please read the source code (here) for the XSpectrum spectrum analyser (despite its age XSpectrum still runs faster than the newer gspectrum).
For the second time, homophones do not sound alike; the sounds must be identical to satisfy the definition! Yes, I wrote "sound-a-like" instead of sound-alike. I was wrong. Yippee!
No, that would be just as wrong as using "homonym" because "homophone" means a word that is pronounced the same way as another word but which has either a different meaning or a different spelling. A "homonym" means a word that has the same sound or spelling as another word. The words "tenet" and "tenant" are pronounced differently and spelt differently, so they are obviously neither homophones nor homonyms. Because they do not sound the same, merely similar, they are, therefore, sound-a-likes.
A "homograph" is a word that has the same spelling as another word but which differs in meaning. The clue is in the etymology of the word "graph" which is derived from the Greek word "graphos" which means to write.
No, because "homonym" means a word that has the same sound, and often the same spelling too, as another word whereas "sound-a-like" or "soundalike" [and OED] means a word that sounds like another word without necessarily being homonymous to it.
should be "this tenet of copyright law" because "tenet" means a principle whereas a "tenant" is someone who pays to use someone else's asset. There seems to be a recent trend among certain Slashdot users to use soundalike words instead of the standard ones.
To be fair, you didn't originally define what you meant by "better" in the context of one document being considered better than another. I do not think there is a universally acceptable definition of "better" in this context. "Better" may also have more than one component or dimension. Also, how should a "better" metric be used? Should it be applied to the inputs (each author's contribution), the output (the final collaborative document), or some combination of both? I agree coherency can probably only be assessed and controlled globally, i.e. by a small number of closely intercommunicating people editing the entire discourse (we know the latter process doesn't happen on Slashdot:-)
As for the Slashdot example, I think it illustrates an extremely useful source of collaboratively generated information that covers a narrow range of subjects. Slashdot, together with its comment moderation scheme, often results in collaborative documents (articles+comments) that contain a greater quantity of diverse and useful information on a selected topic than can be found anywhere else for the same amount of investment in research time. It works well for subjects which are accessible in terms of language and technical jargon to the a significant fraction of the slashdot audience but it doesn't work so well for subjects which require highly structured, technical discourse like mathematics or for subjects in which a large fraction of the audience generally have limited background knowledge, e.g. arts subjects.
Isn't the document being formed on Slashdot in this very discussion a prime example of the benefits of combining the thoughts of many people on an issue? Yes, there may be useless comments in any group discussion, but the sum total of all comments almost always includes some real gems of insight.
"The X color model is not designed around color matching or to-print color."
No, that's not true. X has excellent color management support. It's one of the best things about the design of X. You seem like so many other X critics highly confused about the design of X including the key concepts of an X server and an X application because you continue in your comment by criticising an application better known as xterm, which has absolutely nothing to do with the design of an X server. You are comparing apples and oranges. It is meaningless to compare X applications with X servers. Please read the design documentation for X. People who have not read the design documentation for X, wrongly believe they understand the design just by reading the man pages for X and then wrongly think they can produce valid criticisms of X.
Both the design of X and the implementation in XFree86 provide a very flexible and powerful color model based on color science. Here is not the right place for a tutorial on color science. Please read the excellent book by G.Wyszecki and W.S.Stiles, "Color Science: Concepts and Methods, Quantitative Data and Formulas", 2nd edition, 1982, published by Wiley, New York. Only after you are confident you have understood the theory of color science, please then read the X design document from "Chapter 6: Color Management Functions [in X]"
You are again wrong and confused in your criticism of xterm's color management. xterm like any X application built on Xlib/Xaw/Xt has the usual excellent color management support. You just don't understand how to use it. Read the X documentation for how to specify colors in a color space and how to specify a calibration for a color device. Also, you appear to be hopelessly confused about the differences between "visuals" and "colormaps" in X. Read the X design documents.
"X *does* have a higher latency than Windows (partly due to serialization of commands and partly due to the context-switch requirement)".
This is untrue. Serialisation and context-switching have insignificant effects on the speed of a locally displayed application. Did you really read my post? How do you know serialisation and context-switching are to blame for alleged high latency? Did you measure anything? Did you recompile X with profiling enabled and do a breakdown of the profiling results component by component? Properly written X applications running on a local X display can usually run as fast as MS-Windows applications. Amazingly some 2d graphics operations are faster in X than in some versions of MS-Windows. Some X applications would benefit from optimised graphics drivers which are only available for MS-Windows. XFree86 does not have optimised graphics drivers because the graphics card manufacturers have not provided programming information for their products. However, properly written X applications running on a local X display can usually run as fast as MS-Windows applications. Unfortunately, many toolkit libraries are not written to use X very well.
Your arguments fail because they are illogical. Whether or not X is really fast, "Face it, X is not goddamned Speedy Gonzalez, and everybody [blah blah...]" is not a logical argument. You claim it must be that X is not fast because your "modern" applications do not seem to run fast enough according to your taste. However, how would you know whether or not X is fast? Have you measured the speed of something? How did you measure it? Did you measure, separately, the speed of certain operations in a toolkit like Qt or Gtk, in an X-server like XFree86, and in a core library such as Xlib? Did you identify which parts of the complete system were responsible for slowness? If you didn't measure anything, why should we trust your perception to be objective? If you didn't measure anything, how could you possibly know the true relative speeds of the different components of an X application and an X server?
I do not agree that "Y Windows definitely has the right idea". The author clearly worked very hard on his project but I think he is unfortunately totally misguided. In his thesis he shows he has a very shallow understanding of the architecture of X, which he then proceeds to criticise. It is therefore no surprise he gets the wrong ideas and solves non-existent problems. For example, he says the color model in X is "overly complex", which, for anyone who actually understands color science, is an absurd criticism. His supervisor should have pointed out this and numerous other conceptual mistakes in his work before he wasted so much of his time.
"even if the app could draw directly into the... buffer"
No, an X application can always write directly into the X-server memory by using the Shared Memory Extension which is an even faster method than the already very fast default method of using unix domain sockets. I don't agree that slowness is caused by the design of X. You are probably basing your judgement on the performance you get using the XFree86 server, an implementation of X whose graphics card drivers are mostly without the benefit of full optimisation. This is because XFree86 writes its own graphics card drivers and the graphics card manufacturers have often not provided programming information on their products. This situation will change at some point as the manufacturers see Linux desktop usage continue its steady increase.
"perceived slowness [due to] separate window manager"
It is not the design of X itself including the positive feature of window management which causes any slowness. Firstly, XFree86 suffers from having non-optimised graphics card drivers (see previous paragraph). Secondly, window management is typically performed by a window manager, most of which were not written with graphics optimisation in mind. For example, I don't know of any open-source window manager which actually uses the shared memory extension although that would especially help speed up the dragging of large windows. It is unfair to criticise non-optimised window managers for being slow.
You are also wrong to criticise X for making the window management concept possible. If you don't like window managers, don't use them! X does not require you to use a window manager. Also, do not confuse "window manager" with "window management". Window management is required in X as it is in MS-Windows. However, the difference in X is that window management can be done by any or all of: X applications, toolkits, the X server, or separate window manager(s). Only X gives you that amazing choice!
Yes, that's right except an X application must be programmed to use the shared memory extension to X, otherwise it will use the default -- a unix domain socket in/tmp -- which is usually slightly slower than shared memory. However, it's worth noting that unix domain sockets are extremely efficiently implemented on Linux. The overhead in the X server for using domain sockets is so small it is insignificant compared to the graphics overhead in most toolkit libraries. If anyone's interested, it is tedious but possible to confirm the domain socket overhead is small either by analysing the output of strace -T Xserver_pid (on a separate display to avoid deadlock!) or preferably by recompiling X with profiling enabled.
It's also worth noting the slowest part of X applications is in the badly implemented toolkits they commonly use which do their X event handling clumsily and sub-optimally (graphics exposures).
No, the problem you imagine simply does not exist because X already has the "shared memory extension" to make it possible to write directly into the X-server's graphics memory bypassing the socket communications. In any case, XFree86 uses domain sockets for all local communications. Domain sockets are implemented extremely efficient on Linux. It is definitely not sockets that are causing any delays you may see on your user-interface. It is likely you are using a GNOME or KDE application which is badly implemented whether in itself or in the toolkit on which it is based.
"security implications this has as well"
No, there is no security problem. X defaults to have closed network access. Every PC should also use a firewall which provides a separate stronger access control mechanism. Nobody should be able to access your X-server remotely unless you have explicitly given them permission.
make xconfig is only useful if you are running X (I'm not) and I find it's not very easy navigating backwards and forwards in make menuconfig because the interface is rather clunky and slow. I don't know why there isn't a version of make menuconfig based on a curses interface which would be much faster.
In what ways do you think the architecture of X makes it too complicated to build upon? I'd welcome a well-argued complaint from you or anyone else because without one there's nothing to debate. Can you identify the "mistakes, workarounds, etc" you claim are present in the design of X?
"I still find XFree86 somewhat rubber-like [...] minimal delay when activating widgets, marking text and stuff. Feels like reluctance."
It could be you are using badly written applications and/or widget libraries. Which applications are you using? Out of interest, for how long have you been using XFree86?
A quick web search on alltheweb.com for "Intellimouse" and "XFree86" gave the following link which has instructions that may help you set it up: Configuring the Intellimouse Explorer in XFree86
Just edit the suggested modifications into your/etc/X11/XF86Config using a plain text editor, prepend the suggested xmodmap command to your.xinitrc file, and re-start XFree86.
Firstly, you are criticising X when you are actually likely using XFree86, the free non-commercial implementation of an X server. There are commercial X servers which in some cases run faster than XFree86. XFree86 writes its own device drivers but graphics hardware manufacturers have often provided little or no information to help XFree86 developers write better device drivers. The design of X is not the problem.
Secondly, the client-server design of X causes minimal delay on locally displayed, locally run applications. The X11 communications take place over the very efficient, low overhead Linux version of Unix domain sockets. Furthermore, there is the shared memory extension to X, XSHM, which bypasses the usual client-server model for XImages and XPixmaps so that applications which are locally displayed and locally run can directly read/write the data in shared memory in the X server thus avoiding client-server roundtrip communications for these common high-volume data-structures.
I use XFree86 on a variety of hardware ranging from an old 66MHz i486 PC to very recent Intel PCs, and find it runs as fast as Windows.
Actually the speed of X on PCs has little to do with the design of X and much to do with the implementation of XFree86 which is the software you run to get X on a PC. Don't criticise X when it's XFree86 that writes the drivers and many of the graphics hardware manufacturers do not write any device drivers for XFree86. Personally I find the speed of XFree86, when properly configured, is acceptable even on old hardware like 66MHZ i486 PCs and as fast as Windows.
Slashdot Mirror
"Arbitrarily large amounts" is the same as saying "any number of units between 1 and infinity". Are you talking about an X which is a Universal Turing Machine :-) Are you sure you meant to refer to X instead of XFree86. In other words, have you really identified a problem in the design of X rather than a bug in the implementation in XFree86? Whether or not you like the design of backing-store mechanism in X, there are commercial Xservers which have implementations of backing-store that correctly follow the X specification.
I'm sorry but you are displaying your total ignorance of the design of X and making completely unjustified and incorrect criticisms in bold font as if to boast of your misplaced confidence. Please read the design documentation for X before you post about X again.
X has always provided a mechanism for storing and communicating byte-sequences between X applications. Few X application programmers have bothered to read the excellent design documentation for X which is a shame because if they had they would understand how to implement cut-and-paste together with content negotiation. Implementing consistent cut-and-paste in X applications is really as simple as following the very clear guidelines in the excellent explanation by Jamie Zawinski written many years ago.
P.S. Your pseudo-Japanese username "Minna Kirai" (literally meaning that you hate everyone) would be better as Shigoto Kirai (literally meaning that you hate work like reading about the design of X).
For an excellent example of how to do double-buffering in X, please read the source code (here) for the XSpectrum spectrum analyser (despite its age XSpectrum still runs faster than the newer gspectrum).
For the second time, homophones do not sound alike; the sounds must be identical to satisfy the definition! Yes, I wrote "sound-a-like" instead of sound-alike. I was wrong. Yippee!
No, that would be just as wrong as using "homonym" because "homophone" means a word that is pronounced the same way as another word but which has either a different meaning or a different spelling. A "homonym" means a word that has the same sound or spelling as another word. The words "tenet" and "tenant" are pronounced differently and spelt differently, so they are obviously neither homophones nor homonyms. Because they do not sound the same, merely similar, they are, therefore, sound-a-likes .
A "homograph" is a word that has the same spelling as another word but which differs in meaning. The clue is in the etymology of the word "graph" which is derived from the Greek word "graphos" which means to write.
No, because "homonym" means a word that has the same sound, and often the same spelling too, as another word whereas "sound-a-like" or "soundalike" [and OED] means a word that sounds like another word without necessarily being homonymous to it.
should be "this tenet of copyright law" because "tenet" means a principle whereas a "tenant" is someone who pays to use someone else's asset. There seems to be a recent trend among certain Slashdot users to use soundalike words instead of the standard ones.
As for the Slashdot example, I think it illustrates an extremely useful source of collaboratively generated information that covers a narrow range of subjects. Slashdot, together with its comment moderation scheme, often results in collaborative documents (articles+comments) that contain a greater quantity of diverse and useful information on a selected topic than can be found anywhere else for the same amount of investment in research time. It works well for subjects which are accessible in terms of language and technical jargon to the a significant fraction of the slashdot audience but it doesn't work so well for subjects which require highly structured, technical discourse like mathematics or for subjects in which a large fraction of the audience generally have limited background knowledge, e.g. arts subjects.
Isn't the document being formed on Slashdot in this very discussion a prime example of the benefits of combining the thoughts of many people on an issue? Yes, there may be useless comments in any group discussion, but the sum total of all comments almost always includes some real gems of insight.
Has anyone tried the open-source collaborative editing/annotation tool called AnnotateIT?
"The X color model is not designed around color matching or to-print color."
No, that's not true. X has excellent color management support. It's one of the best things about the design of X. You seem like so many other X critics highly confused about the design of X including the key concepts of an X server and an X application because you continue in your comment by criticising an application better known as xterm, which has absolutely nothing to do with the design of an X server. You are comparing apples and oranges. It is meaningless to compare X applications with X servers. Please read the design documentation for X. People who have not read the design documentation for X, wrongly believe they understand the design just by reading the man pages for X and then wrongly think they can produce valid criticisms of X.
Both the design of X and the implementation in XFree86 provide a very flexible and powerful color model based on color science. Here is not the right place for a tutorial on color science. Please read the excellent book by G.Wyszecki and W.S.Stiles, "Color Science: Concepts and Methods, Quantitative Data and Formulas", 2nd edition, 1982, published by Wiley, New York. Only after you are confident you have understood the theory of color science, please then read the X design document from "Chapter 6: Color Management Functions [in X]"
You are again wrong and confused in your criticism of xterm's color management. xterm like any X application built on Xlib/Xaw/Xt has the usual excellent color management support. You just don't understand how to use it. Read the X documentation for how to specify colors in a color space and how to specify a calibration for a color device. Also, you appear to be hopelessly confused about the differences between "visuals" and "colormaps" in X. Read the X design documents.
This is untrue. Serialisation and context-switching have insignificant effects on the speed of a locally displayed application. Did you really read my post? How do you know serialisation and context-switching are to blame for alleged high latency? Did you measure anything? Did you recompile X with profiling enabled and do a breakdown of the profiling results component by component? Properly written X applications running on a local X display can usually run as fast as MS-Windows applications. Amazingly some 2d graphics operations are faster in X than in some versions of MS-Windows. Some X applications would benefit from optimised graphics drivers which are only available for MS-Windows. XFree86 does not have optimised graphics drivers because the graphics card manufacturers have not provided programming information for their products. However, properly written X applications running on a local X display can usually run as fast as MS-Windows applications. Unfortunately, many toolkit libraries are not written to use X very well.
Your arguments fail because they are illogical. Whether or not X is really fast, "Face it, X is not goddamned Speedy Gonzalez, and everybody [blah blah ...]" is not a logical argument. You claim it must be that X is not fast because your "modern" applications do not seem to run fast enough according to your taste. However, how would you know whether or not X is fast? Have you measured the speed of something? How did you measure it? Did you measure, separately, the speed of certain operations in a toolkit like Qt or Gtk, in an X-server like XFree86, and in a core library such as Xlib? Did you identify which parts of the complete system were responsible for slowness? If you didn't measure anything, why should we trust your perception to be objective? If you didn't measure anything, how could you possibly know the true relative speeds of the different components of an X application and an X server?
I do not agree that "Y Windows definitely has the right idea". The author clearly worked very hard on his project but I think he is unfortunately totally misguided. In his thesis he shows he has a very shallow understanding of the architecture of X, which he then proceeds to criticise. It is therefore no surprise he gets the wrong ideas and solves non-existent problems. For example, he says the color model in X is "overly complex", which, for anyone who actually understands color science, is an absurd criticism. His supervisor should have pointed out this and numerous other conceptual mistakes in his work before he wasted so much of his time.
"even if the app could draw directly into the
No, an X application can always write directly into the X-server memory by using the Shared Memory Extension which is an even faster method than the already very fast default method of using unix domain sockets. I don't agree that slowness is caused by the design of X. You are probably basing your judgement on the performance you get using the XFree86 server, an implementation of X whose graphics card drivers are mostly without the benefit of full optimisation. This is because XFree86 writes its own graphics card drivers and the graphics card manufacturers have often not provided programming information on their products. This situation will change at some point as the manufacturers see Linux desktop usage continue its steady increase.
"perceived slowness [due to] separate window manager"
It is not the design of X itself including the positive feature of window management which causes any slowness. Firstly, XFree86 suffers from having non-optimised graphics card drivers (see previous paragraph). Secondly, window management is typically performed by a window manager, most of which were not written with graphics optimisation in mind. For example, I don't know of any open-source window manager which actually uses the shared memory extension although that would especially help speed up the dragging of large windows. It is unfair to criticise non-optimised window managers for being slow.
You are also wrong to criticise X for making the window management concept possible. If you don't like window managers, don't use them! X does not require you to use a window manager. Also, do not confuse "window manager" with "window management". Window management is required in X as it is in MS-Windows. However, the difference in X is that window management can be done by any or all of: X applications, toolkits, the X server, or separate window manager(s). Only X gives you that amazing choice!
Yes, and those 10-year old Indy museumstations were fully protected by a carefully configured firewall so there was no security problem anyway :-)
Yes, I know you're absolutely right. I was typing too quickly :-)
It's also worth noting the slowest part of X applications is in the badly implemented toolkits they commonly use which do their X event handling clumsily and sub-optimally (graphics exposures).
No, the problem you imagine simply does not exist because X already has the "shared memory extension" to make it possible to write directly into the X-server's graphics memory bypassing the socket communications. In any case, XFree86 uses domain sockets for all local communications. Domain sockets are implemented extremely efficient on Linux. It is definitely not sockets that are causing any delays you may see on your user-interface. It is likely you are using a GNOME or KDE application which is badly implemented whether in itself or in the toolkit on which it is based.
"security implications this has as well"
No, there is no security problem. X defaults to have closed network access. Every PC should also use a firewall which provides a separate stronger access control mechanism. Nobody should be able to access your X-server remotely unless you have explicitly given them permission.
Like I said above, make xconfig is only useful if you are running X (I'm not).
make xconfig is only useful if you are running X (I'm not) and I find it's not very easy navigating backwards and forwards in make menuconfig because the interface is rather clunky and slow. I don't know why there isn't a version of make menuconfig based on a curses interface which would be much faster.
Wanted: The ability to edit any answer you give during make config without having to start over
In what ways do you think the architecture of X makes it too complicated to build upon? I'd welcome a well-argued complaint from you or anyone else because without one there's nothing to debate. Can you identify the "mistakes, workarounds, etc" you claim are present in the design of X?
"I still find XFree86 somewhat rubber-like [...] minimal delay when activating widgets, marking text and stuff. Feels like reluctance."
It could be you are using badly written applications and/or widget libraries. Which applications are you using? Out of interest, for how long have you been using XFree86?
A quick web search on alltheweb.com for "Intellimouse" and "XFree86" gave the following link which has instructions that may help you set it up: Configuring the Intellimouse Explorer in XFree86
Just edit the suggested modifications into your /etc/X11/XF86Config using a plain text editor, prepend the suggested xmodmap command to your .xinitrc file, and re-start XFree86.
Firstly, you are criticising X when you are actually likely using XFree86, the free non-commercial implementation of an X server. There are commercial X servers which in some cases run faster than XFree86. XFree86 writes its own device drivers but graphics hardware manufacturers have often provided little or no information to help XFree86 developers write better device drivers. The design of X is not the problem.
Secondly, the client-server design of X causes minimal delay on locally displayed, locally run applications. The X11 communications take place over the very efficient, low overhead Linux version of Unix domain sockets. Furthermore, there is the shared memory extension to X, XSHM, which bypasses the usual client-server model for XImages and XPixmaps so that applications which are locally displayed and locally run can directly read/write the data in shared memory in the X server thus avoiding client-server roundtrip communications for these common high-volume data-structures.
I use XFree86 on a variety of hardware ranging from an old 66MHz i486 PC to very recent Intel PCs, and find it runs as fast as Windows.
Actually the speed of X on PCs has little to do with the design of X and much to do with the implementation of XFree86 which is the software you run to get X on a PC. Don't criticise X when it's XFree86 that writes the drivers and many of the graphics hardware manufacturers do not write any device drivers for XFree86. Personally I find the speed of XFree86, when properly configured, is acceptable even on old hardware like 66MHZ i486 PCs and as fast as Windows.