Conservatives believe in capitalism. Free trade is a choice tool of the free market, and hence an important part of capitalism. I thought it was the hippy liberals that wanted government to provide protection (read: welfare) for those who couldn't compete in the free market? A devotion to capitalism is one of the few things conservatives get right!
You can argue that it was not as effective as it could have been, and/or not as fair as it could have been, but failing to pass something in that session would have been political suicide for everybody involved. ----- And that is the fundemental problem with our system of government. We can't take the best actions, but rather, we must take the most popular action. The proper action to take would have been to say "you know, our existing infrastructure would have handled this case, and the real thing we need to do is make sure that our implementation lives up to our design." But people wouldn't have bought that. They want something new, something innovative! They want a magical solution to a problem that doesn't have one. By now, they have more or less forgotten about the freedoms they lost when the acts were passed, and don't even care whether they are safer for it, because their immediate bloodlust was satisfied.
I'm not talking so much about the federal government which, even when it is religious, is moreso in speech than in action. I'm talking about the immense religious influence of the people themselves, especially through state and local governments. I go to school in Georgia (home is in Virginia) and both states have some very odd laws influenced by religion. There are all sorts of sexually-repressed laws, as well as controversy about stuff like putting a monument to the Ten Commandments on the lawn of the Georga Supreme Court. Maybe its different in the rest of the country (I notice it much less in DC), but the influence of religion over government is quite strong at least in the South.
Many reports from people who should know indicate that suicide bombers are being taught that their actions guarantee entrance to the afterlife despite any sins. --- Shouldn't we distinguish what the religion teaches from what certain fringe groups pretend the religion teaches? When KKK people use religion to condone bombing an abortion clinic, do we call it an act of Christian terrorism? Does the fact that many people use patriotism to justify violence mean that teaching patriotism is akin to teaching violence?
The Christian population of the USA, to my knowledge, is no more likely to murder someone, per capita, than anyone else. --- The Muslim population of the USA is no more likely to commit terrorist actions than the Christian population. For every Muslim terrorist we've seen living in the US, we've seen a Christian terrorist sniping people or blowing up buildings.
But, being a American Christian is strongly correlated to being from the USA which may indicate more of a tendency to murder than a non-USAian. --- Would it be justified, then, for France to keep close tabs on visiting Americans? After all, they are about eight times more likely to kill someone during their stay than the average frenchman!
If I were in England during a rash of IRA bombings I'd expect to be questioned, I am Irish (from a Catholic family) and would likely be travelling between England and Ireland. --- Then your expectations obviously aren't high enough.
When a major religion teaches people that they can get ahead in the afterlife by killing others I tend to be wary. --- It doesn't. Martyrdom in the Quran has nothing to do with killing others, but being unjustly killed yourself. It'd by like Jesus being called a martyr because he died during a murderous rampage through the streets of Rome!
being Islamic is strongly correlated with suicide attacks on civilians. --- Being Christian is strongly correlated with murdering people. After all, the murder rates in the predominantly Christian United States are much higher than the murder rates in the oficially athiest China. And there are a whole lot more Christian murderers than Mulsim suicide bombers!
Do you suggest that we ignore racial or religious indicators when screening people? --- Yes. Unless you can prove that there is a *statistically significant* correlation between suicide bombers and being Muslim, then there is no basis for screening them. You've got a handful of Mulsim terrorists (relatively) and a handful of Christian terrorists (IRA, among others). Take all those factors into account, and I'd say that you'd have a hard time coming up with a mathematically significant correlation.
There are many more innocent people wearing Turbans than terrorists. --- Mulsims don't necessarily wear turbans. Arabs do.
That's true in a number of Islamic countries. 60% of university entrants in Iran, for example, are women. Three Islamic countries have elected women prime ministers, while the US has seen zero women presidents.
The biggest problem is in the country-side, where people are a lot more backwards. Even in the US, there are communities that believe that "a women's place is in the home, etc" and fifty years ago, there were womens' magazines giving advice like "always let your husband speak first at dinner, what he has to say is more important than what you have to say." If you consider the relatively worse situation of countries like Iraq and Iran (couple of decades behind, culturally, and many more people in the lower-class) its easy to put into perspective the relative position of women.
The problem here is that two US principles are in conflict. The US wants freedom, and at the same time, it wants the rule of the people. The two are, in many parts of the world, mutually exclusive. Just as we have communities in the US where the majority votes to restrict their own freedom (morality laws), we have countries like Iran where the people *choose* to instate a non-free theocracy.
Hopefully we can learn from mistakes like this --- The problem is that we don't. Its not just Iraq. We've supported many such regimes. Hell, we gave the Taliban the weapons they needed to come into power! In the last two years, we've toppled two regimes we helped to create! Hindsight may be 20/20, but those who don't learn from history are doomed to repeat it!
Religion wasn't as big a problem as politics. Iraq under Saddam was largely secular. As long as you kept a low profile politically, we were likely to be okay. The new Iraq will most likely be a lot more religiously conservative (if the "will of the people" is obeyed, anyway) though more free politically.
Preemptive comment about (2). If you were using a safe language (ML, Dylan, Scheme, etc) you could not only get rid of the server, but most of the OS as well. Just put everything in one address space running as seperate threads. Everything ends up being a lot faster --- you get rid of system call overhead, protocol overhead, excessive copies between protection domaians, etc. Because of this, X certainly isn't the best possible windowing system, even for the local case. However, it'll be a cold day in hell before we see a mainstream OS and its apps written in Dylan, and within the constraints of the current system, where the competitors are things like Aqua and the Windows GDI, X is quite good.
It's the round trip time, not the data rate, that causes the delay. Sluggish mouse tracking is very noticeable, and makes interactive applications impossible to use. Try running GIMP over a modem -- it's unusable! --- I think we are talking about efficiency on two different scales. I'm not trying to argue that X is the most efficient way to do distributed graphics. But that is not what you originally said. You said it was "slow." Over an broadband, a local network network, and locally, X is quite fast. And while I haven't tried running Gimp over a modem Linux, I do know that interactive applications are quite usable over a low-bandwidth (128kbps) broadband link, given good compression technology (like NX).
The application also has to send graphics commands back down to the server in response to mouse motion, which you have neglected to account for in your bytes/second calculation. --- Only if the application is actually drawing something in response to motion. IIRC, the mouse is handled server-side on X11.
So why not just download a graphics editor into the window server, so any other application can easily reuse it as a plug-in component? --- You are just moving the bottleneck. Whether your method is a net win or not depends on whether it takes more bandwidth to feed the display logic or more bandwidth to render the UI. If you are working on a high-resolution image, which can reach into the hundreds of megabytes, it'll take a lot more bandwidth if your application logic is server-side than if it is client-side.
You could implement distributed objects with PostScript graphics that download data to the NeWS server, where it's locally rendered as scalable PostScript graphics, without generating any unnecessary network activity. --- That's a very simplified situation. If we are talking about a real app like the Gimp editing professional-quality images, the data rate required to send those pixels over the wire would dwarf the data rate required to send the UI over the wire.
Ordinary users could use the graphics editor to create custom skins with structured PostScript graphics. With the built-in user interface editor, you could totally reconfigure the user interface while it was running. --- That's really not an advantage of putting stuff server-side, but having dynamically loadable UIs. GNOME allows for that sort of thing via SVG themes.
You illustrate my point for me. You kids take free infinite bandwidth for granted these days, so I bring up cell phones to remind you that bandwidth is neither infinite nor free. --- But its readily available and cheap enough. It does no good to criticize X for not being good over cell-phone links, especially when X does not claim to be a competitor in the cell-phone market, and when the original discussion was about desktop OSs.
What year are you living, in 1994? Zillions of app developers write their code in JavaScript every day. --- There is a big difference between getting web developers to do their UIs in Javascript and getting application developers to do things in Javascript. Applications developers see Javascript as a "scripting language." I think they're full of crap too, but applications are still mostly written in C for god's sake! Application developers have an absolute phobia about embracing new languages. applications, and even entire desktop windowing interfaces, in JavaScript.
Find a friend who has a Windows computer, and see for yourself how fast Fasteroids runs. --- Fasteroids is quite a leap from, say, Quake III.
When I'm writing a desktop application in JavaScript and dynamic HTML, and I need to do something that requires speed, unorthadox graphics or access to native libraries, I simply write an ActiveX control in C++, and go to town. --- You miss the whole point. ActiveX controls are not safe! If you load a control written in C++ into the display server, a crash of the control can easily crash the display server. Most desktop apps need custom display log
Pretty sure. This was the case at least as of a recent convention he attended. For a long time, he did not run Windows, because he said (paraphrasing) "anybody who knows me would know better than to send me MS Office documents" but he's become much more involved in the business world since then.
Which brings us back to my point, that "doing it on a web page" is using a NeWS-like architecture. --- Huh? I'm talking about rendering the web-page itself. Consider doing text-highlighting of an HTML page server-side. Its doable if you build-in all the logic of displaying a web-page into the server. For every application that has different display logic (word processor, spreadsheet, etc), you have to download all that display logic into the server. And you have to send large amounts of data over the wire to feed that display logic.
So what possible advantage is there to have the enormously complex layer of X-Windows in there, between the web browser and the operating system? --- Because people want to run more than just web browsers? HTML is essentially a form of (flexible) structured graphics. Structured graphics are very appropriate for certain types of applications, but history has shown that the rendering needs of apps are just too different for a structured API to be the primary graphics interface.
X-Windows is not solving any problems, if it's just introducing another huge layer that gets you nowhere towards you goal of "doing it on a web page". --- X is just a rendering layer. It draws graphics on the screen. You have to put pixels in the framebuffer somehow, and X is as good a way of doing it as any.
What do you mean by "is"? "Should always be in every case"? Or "X-Windows has always forced us to do it this way"? --- X makes you do input-processing application-side, but that doesn't really introduce an inefficiency. The data rate of a mouse/keyboard even uncompressed never approaches more than 100 bytes/second. That's really not a bottleneck for the roles X is aimed at.
Says who? I certainly see a need. Would you want to run an X-Windows server on a cell phone, where you have to pay for bandwidth and wait for round trips? Nope. --- Probably not. But nobody is trying to remote X over a cell-phone link. However, X is quite usable over a low-bandwidth link, given an appropriate compression technology.
A NeWS-like architecture is much more efficient for implementing distributed applications on cell phones, because it permits the application to download executable code to the phone, saves the user time and money, as provides a high quality, responsive user interface. --- Maybe, but cell-phone applications would necessarily have to be a lot-more limited than general-purpose desktop apps.
Have you ever heard of a language called "JavaScript"? --- Yes.
In case you never heard of it, believe me: there are a lot of people willing to download JavaScript code. --- If you can convince app developers to write their code in Javascript, than more power to you. But that's where I was getting at with the Lisp comment. To be really practical for modern desktop apps, you'd have to use something a lot faster than Javascript. For stuff like HTML rendering, there is a large computational bottleneck. Thus, you'd need a safe, yet fast language.
In case it's not obvious: The web browser / http server model IS a NeWS-like architecture. --- To tell the truth, the web-browser, http-server model is working just fine on top of X. The needs of an internet-based system are very different from a local/network-based system, and I really see little advantage to a NeWS style system targeted at the markets X is aimed at.
The main problem with your HTML/Javascript example is that it only works well because all applications use the same basic display logic (HTML/CSS). However, desktop applications in general do *not* use the same basic display logic. The display logic of a text-editor is very different from the display-logic of a photo editor. If you want to implement this differing display logic in a NeWS-style system, you end up loading large amounts of complex display code into the server. And to feed that display logic, you end up shipping large amounts of data over the wire.
- additional ranting deleted - --- There is no indication that X is holding back Linux on the desktop. What's holding back Linux on the desktop are ease of use and application support. X is quite competitive with the other two desktop systems out there (OS X's and Win XP's). With the freedesktop.org work, it'll be highly competitive with future UIs like Longhorn.
How would you do that in X-Windows? Please explain your approach to extending the X-Windows server to support local text selection in emacs (and local pop-up menus while you're at it), without any unnecessary network traffic? --- You most likely cannot do it in X Windows. But the needs of applications have changed a great deal since then. Consider doing text and graphics highlighting on an HTML page. HTML layout is extremely complex, and the layout data can be very large. Instead of a simple array of integers, you'd have to send all that layout data over the wire.
Or, consider modern widget-sets. All of them use a layout-engine architecture. It would be impractical to put that logic server-side, because that moves a whole lot of code out of the client into the server. Thus, modern applications would end up using a NeWS-style system just as they use X11, as a simple graphics engine.
X-Windows was designed to be a distributed window system, to operate over the network. --- Yep.
Yet it was foolishly not designed to support extensibility: --- Yes it was. Might want to clarify your definition of "extensibility."
dynamically downloading code to the server to perform local input processing --- Input processing is handled by the application. There is no need to download code into the server to do this. You need a safe language to do this (to avoid crashing the server with bad downloaded code), and I don't know if a lot of people would be willing to write their X code in Lisp.
feedback and graphics, and to vastly reduce the amount of network traffic. --- X is an immediate-mode graphics API. Experience with OpenGL has shown that the rendering needs of applications are just too varied for canned, server-side drawing routines to be practical. Plus, you're just moving the bottleneck. A server-side widget handling, say, the display of a spreadsheet needs extensive data from the application, so if the display widget is server-side, you have to ship all that data over the network.
If your web browser had to perform a round trip to the web server each time you press a key, would you say that's a good efficient design? --- I wouldn't say that, but X doesn't do that. Input and output are both heavily buffered. Applications still perform lots of roundtrips, but many of those are needless, and the problems are being fixed in the toolkits. For example, there used to be a lot of problems with round-trips while interning atoms at apps startup, and now, toolkits like Qt buffer atom interning during app startup, and intern them all at once with one round-trip. Further down the road, XCB is being designed to be very low-level, to allow toolkits to take maximum advantage of the protocol.
OS X uses GL only for window compositing!!! Its in Apple's Siggraph presentation! All drawing is done via Quartz 2D, which is rendered in software. Bit-blit acceleration is used for scrolls and drawing pixmaps.
But its not. X is very fast. You can run benchmarks yourself. For stuff like bitblits, X is as fast as DirectDraw (quite an accomplishment for a generalized graphics system!) On my machine, X can copy around ~2GB of 100x100 pixmaps per second, which makes for a bandwidth utilization of about ~4GB/sec. That's pretty close to the maximum memory bandwidth of my graphics card, which is 6.4GB/sec.
X has been quite fast in practice too. SGI shipped a very high-performance X implementation. The main issue is that until recently, there wasn't a lot of interest on X machines on the desktop, even that little interest was in the workstation market, where absolute performance matters more than the responsiveness of the UI. Now that there is interest on putting X on the desktop, people are working on making it more suitable for that role.
Its not so much its superiority to imake, as its superiority to the imake setup of XFree86. The XFree86 build scripts are horribly complex to understand, and while autoconf/automake suck too, they suck less. Plus, more people are familier with them, so there is less of a learning curve for developers.
Slashdot Mirror
Who is calling who the hippy?
Conservatives believe in capitalism. Free trade is a choice tool of the free market, and hence an important part of capitalism. I thought it was the hippy liberals that wanted government to provide protection (read: welfare) for those who couldn't compete in the free market? A devotion to capitalism is one of the few things conservatives get right!
The fact that we gave him weapons and political support did a lot to solidifying his regime. Hence, the "helped to create" rather than the "created."
You can argue that it was not as effective as it could have been, and/or not as fair as it could have been, but failing to pass something in that session would have been political suicide for everybody involved.
-----
And that is the fundemental problem with our system of government. We can't take the best actions, but rather, we must take the most popular action. The proper action to take would have been to say "you know, our existing infrastructure would have handled this case, and the real thing we need to do is make sure that our implementation lives up to our design." But people wouldn't have bought that. They want something new, something innovative! They want a magical solution to a problem that doesn't have one. By now, they have more or less forgotten about the freedoms they lost when the acts were passed, and don't even care whether they are safer for it, because their immediate bloodlust was satisfied.
I'm not talking so much about the federal government which, even when it is religious, is moreso in speech than in action. I'm talking about the immense religious influence of the people themselves, especially through state and local governments. I go to school in Georgia (home is in Virginia) and both states have some very odd laws influenced by religion. There are all sorts of sexually-repressed laws, as well as controversy about stuff like putting a monument to the Ten Commandments on the lawn of the Georga Supreme Court. Maybe its different in the rest of the country (I notice it much less in DC), but the influence of religion over government is quite strong at least in the South.
Many reports from people who should know indicate that suicide bombers are being taught that their actions guarantee entrance to the afterlife despite any sins.
---
Shouldn't we distinguish what the religion teaches from what certain fringe groups pretend the religion teaches? When KKK people use religion to condone bombing an abortion clinic, do we call it an act of Christian terrorism? Does the fact that many people use patriotism to justify violence mean that teaching patriotism is akin to teaching violence?
The Christian population of the USA, to my knowledge, is no more likely to murder someone, per capita, than anyone else.
---
The Muslim population of the USA is no more likely to commit terrorist actions than the Christian population. For every Muslim terrorist we've seen living in the US, we've seen a Christian terrorist sniping people or blowing up buildings.
But, being a American Christian is strongly correlated to being from the USA which may indicate more of a tendency to murder than a non-USAian.
---
Would it be justified, then, for France to keep close tabs on visiting Americans? After all, they are about eight times more likely to kill someone during their stay than the average frenchman!
If I were in England during a rash of IRA bombings I'd expect to be questioned, I am Irish (from a Catholic family) and would likely be travelling between England and Ireland.
---
Then your expectations obviously aren't high enough.
Hmm. Being freakishly religious hasn't seemed to stop the US from becoming a world power!
When a major religion teaches people that they can get ahead in the afterlife by killing others I tend to be wary.
---
It doesn't. Martyrdom in the Quran has nothing to do with killing others, but being unjustly killed yourself. It'd by like Jesus being called a martyr because he died during a murderous rampage through the streets of Rome!
being Islamic is strongly correlated with suicide attacks on civilians.
---
Being Christian is strongly correlated with murdering people. After all, the murder rates in the predominantly Christian United States are much higher than the murder rates in the oficially athiest China. And there are a whole lot more Christian murderers than Mulsim suicide bombers!
Do you suggest that we ignore racial or religious indicators when screening people?
---
Yes. Unless you can prove that there is a *statistically significant* correlation between suicide bombers and being Muslim, then there is no basis for screening them. You've got a handful of Mulsim terrorists (relatively) and a handful of Christian terrorists (IRA, among others). Take all those factors into account, and I'd say that you'd have a hard time coming up with a mathematically significant correlation.
There are many more innocent people wearing Turbans than terrorists.
---
Mulsims don't necessarily wear turbans. Arabs do.
That's true in a number of Islamic countries. 60% of university entrants in Iran, for example, are women. Three Islamic countries have elected women prime ministers, while the US has seen zero women presidents.
The biggest problem is in the country-side, where people are a lot more backwards. Even in the US, there are communities that believe that "a women's place is in the home, etc" and fifty years ago, there were womens' magazines giving advice like "always let your husband speak first at dinner, what he has to say is more important than what you have to say." If you consider the relatively worse situation of countries like Iraq and Iran (couple of decades behind, culturally, and many more people in the lower-class) its easy to put into perspective the relative position of women.
The problem here is that two US principles are in conflict. The US wants freedom, and at the same time, it wants the rule of the people. The two are, in many parts of the world, mutually exclusive. Just as we have communities in the US where the majority votes to restrict their own freedom (morality laws), we have countries like Iran where the people *choose* to instate a non-free theocracy.
Hopefully we can learn from mistakes like this
---
The problem is that we don't. Its not just Iraq. We've supported many such regimes. Hell, we gave the Taliban the weapons they needed to come into power! In the last two years, we've toppled two regimes we helped to create! Hindsight may be 20/20, but those who don't learn from history are doomed to repeat it!
Religion wasn't as big a problem as politics. Iraq under Saddam was largely secular. As long as you kept a low profile politically, we were likely to be okay. The new Iraq will most likely be a lot more religiously conservative (if the "will of the people" is obeyed, anyway) though more free politically.
Preemptive comment about (2). If you were using a safe language (ML, Dylan, Scheme, etc) you could not only get rid of the server, but most of the OS as well. Just put everything in one address space running as seperate threads. Everything ends up being a lot faster --- you get rid of system call overhead, protocol overhead, excessive copies between protection domaians, etc. Because of this, X certainly isn't the best possible windowing system, even for the local case. However, it'll be a cold day in hell before we see a mainstream OS and its apps written in Dylan, and within the constraints of the current system, where the competitors are things like Aqua and the Windows GDI, X is quite good.
It's the round trip time, not the data rate, that causes the delay. Sluggish mouse tracking is very noticeable, and makes interactive applications impossible to use. Try running GIMP over a modem -- it's unusable!
---
I think we are talking about efficiency on two different scales. I'm not trying to argue that X is the most efficient way to do distributed graphics. But that is not what you originally said. You said it was "slow." Over an broadband, a local network network, and locally, X is quite fast. And while I haven't tried running Gimp over a modem Linux, I do know that interactive applications are quite usable over a low-bandwidth (128kbps) broadband link, given good compression technology (like NX).
The application also has to send graphics commands back down to the server in response to mouse motion, which you have neglected to account for in your bytes/second calculation.
---
Only if the application is actually drawing something in response to motion. IIRC, the mouse is handled server-side on X11.
So why not just download a graphics editor into the window server, so any other application can easily reuse it as a plug-in component?
---
You are just moving the bottleneck. Whether your method is a net win or not depends on whether it takes more bandwidth to feed the display logic or more bandwidth to render the UI. If you are working on a high-resolution image, which can reach into the hundreds of megabytes, it'll take a lot more bandwidth if your application logic is server-side than if it is client-side.
You could implement distributed objects with PostScript graphics that download data to the NeWS server, where it's locally rendered as scalable PostScript graphics, without generating any unnecessary network activity.
---
That's a very simplified situation. If we are talking about a real app like the Gimp editing professional-quality images, the data rate required to send those pixels over the wire would dwarf the data rate required to send the UI over the wire.
Ordinary users could use the graphics editor to create custom skins with structured PostScript graphics. With the built-in user interface editor, you could totally reconfigure the user interface while it was running.
---
That's really not an advantage of putting stuff server-side, but having dynamically loadable UIs. GNOME allows for that sort of thing via SVG themes.
You illustrate my point for me. You kids take free infinite bandwidth for granted these days, so I bring up cell phones to remind you that bandwidth is neither infinite nor free.
---
But its readily available and cheap enough. It does no good to criticize X for not being good over cell-phone links, especially when X does not claim to be a competitor in the cell-phone market, and when the original discussion was about desktop OSs.
What year are you living, in 1994? Zillions of app developers write their code in JavaScript every day.
---
There is a big difference between getting web developers to do their UIs in Javascript and getting application developers to do things in Javascript. Applications developers see Javascript as a "scripting language." I think they're full of crap too, but applications are still mostly written in C for god's sake! Application developers have an absolute phobia about embracing new languages. applications, and even entire desktop windowing interfaces, in JavaScript.
Find a friend who has a Windows computer, and see for yourself how fast Fasteroids runs.
---
Fasteroids is quite a leap from, say, Quake III.
When I'm writing a desktop application in JavaScript and dynamic HTML, and I need to do something that requires speed, unorthadox graphics or access to native libraries, I simply write an ActiveX control in C++, and go to town.
---
You miss the whole point. ActiveX controls are not safe! If you load a control written in C++ into the display server, a crash of the control can easily crash the display server. Most desktop apps need custom display log
Pretty sure. This was the case at least as of a recent convention he attended. For a long time, he did not run Windows, because he said (paraphrasing) "anybody who knows me would know better than to send me MS Office documents" but he's become much more involved in the business world since then.
Which brings us back to my point, that "doing it on a web page" is using a NeWS-like architecture.
---
Huh? I'm talking about rendering the web-page itself. Consider doing text-highlighting of an HTML page server-side. Its doable if you build-in all the logic of displaying a web-page into the server. For every application that has different display logic (word processor, spreadsheet, etc), you have to download all that display logic into the server. And you have to send large amounts of data over the wire to feed that display logic.
So what possible advantage is there to have the enormously complex layer of X-Windows in there, between the web browser and the operating system?
---
Because people want to run more than just web browsers? HTML is essentially a form of (flexible) structured graphics. Structured graphics are very appropriate for certain types of applications, but history has shown that the rendering needs of apps are just too different for a structured API to be the primary graphics interface.
X-Windows is not solving any problems, if it's just introducing another huge layer that gets you nowhere towards you goal of "doing it on a web page".
---
X is just a rendering layer. It draws graphics on the screen. You have to put pixels in the framebuffer somehow, and X is as good a way of doing it as any.
What do you mean by "is"? "Should always be in every case"? Or "X-Windows has always forced us to do it this way"?
---
X makes you do input-processing application-side, but that doesn't really introduce an inefficiency. The data rate of a mouse/keyboard even uncompressed never approaches more than 100 bytes/second. That's really not a bottleneck for the roles X is aimed at.
Says who? I certainly see a need. Would you want to run an X-Windows server on a cell phone, where you have to pay for bandwidth and wait for round trips? Nope.
---
Probably not. But nobody is trying to remote X over a cell-phone link. However, X is quite usable over a low-bandwidth link, given an appropriate compression technology.
A NeWS-like architecture is much more efficient for implementing distributed applications on cell phones, because it permits the application to download executable code to the phone, saves the user time and money, as provides a high quality, responsive user interface.
---
Maybe, but cell-phone applications would necessarily have to be a lot-more limited than general-purpose desktop apps.
Have you ever heard of a language called "JavaScript"?
---
Yes.
In case you never heard of it, believe me: there are a lot of people willing to download JavaScript code.
---
If you can convince app developers to write their code in Javascript, than more power to you. But that's where I was getting at with the Lisp comment. To be really practical for modern desktop apps, you'd have to use something a lot faster than Javascript. For stuff like HTML rendering, there is a large computational bottleneck. Thus, you'd need a safe, yet fast language.
In case it's not obvious: The web browser / http server model IS a NeWS-like architecture.
---
To tell the truth, the web-browser, http-server model is working just fine on top of X. The needs of an internet-based system are very different from a local/network-based system, and I really see little advantage to a NeWS style system targeted at the markets X is aimed at.
The main problem with your HTML/Javascript example is that it only works well because all applications use the same basic display logic (HTML/CSS). However, desktop applications in general do *not* use the same basic display logic. The display logic of a text-editor is very different from the display-logic of a photo editor. If you want to implement this differing display logic in a NeWS-style system, you end up loading large amounts of complex display code into the server. And to feed that display logic, you end up shipping large amounts of data over the wire.
- additional ranting deleted -
---
There is no indication that X is holding back Linux on the desktop. What's holding back Linux on the desktop are ease of use and application support. X is quite competitive with the other two desktop systems out there (OS X's and Win XP's). With the freedesktop.org work, it'll be highly competitive with future UIs like Longhorn.
He dual-boots SuSE/KDE and Windows on a Sony VAIO laptop.
As a front-end to a Plan 9 machine :)
How would you do that in X-Windows? Please explain your approach to extending the X-Windows server to support local text selection in emacs (and local pop-up menus while you're at it), without any unnecessary network traffic?
---
You most likely cannot do it in X Windows. But the needs of applications have changed a great deal since then. Consider doing text and graphics highlighting on an HTML page. HTML layout is extremely complex, and the layout data can be very large. Instead of a simple array of integers, you'd have to send all that layout data over the wire.
Or, consider modern widget-sets. All of them use a layout-engine architecture. It would be impractical to put that logic server-side, because that moves a whole lot of code out of the client into the server. Thus, modern applications would end up using a NeWS-style system just as they use X11, as a simple graphics engine.
X-Windows was designed to be a distributed window system, to operate over the network.
---
Yep.
Yet it was foolishly not designed to support extensibility:
---
Yes it was. Might want to clarify your definition of "extensibility."
dynamically downloading code to the server to perform local input processing
---
Input processing is handled by the application. There is no need to download code into the server to do this. You need a safe language to do this (to avoid crashing the server with bad downloaded code), and I don't know if a lot of people would be willing to write their X code in Lisp.
feedback and graphics, and to vastly reduce the amount of network traffic.
---
X is an immediate-mode graphics API. Experience with OpenGL has shown that the rendering needs of applications are just too varied for canned, server-side drawing routines to be practical. Plus, you're just moving the bottleneck. A server-side widget handling, say, the display of a spreadsheet needs extensive data from the application, so if the display widget is server-side, you have to ship all that data over the network.
If your web browser had to perform a round trip to the web server each time you press a key,
would you say that's a good efficient design?
---
I wouldn't say that, but X doesn't do that. Input and output are both heavily buffered. Applications still perform lots of roundtrips, but many of those are needless, and the problems are being fixed in the toolkits. For example, there used to be a lot of problems with round-trips while interning atoms at apps startup, and now, toolkits like Qt buffer atom interning during app startup, and intern them all at once with one round-trip. Further down the road, XCB is being designed to be very low-level, to allow toolkits to take maximum advantage of the protocol.
Argh.
OS X uses GL only for window compositing!!! Its in Apple's Siggraph presentation! All drawing is done via Quartz 2D, which is rendered in software. Bit-blit acceleration is used for scrolls and drawing pixmaps.
But its not. X is very fast. You can run benchmarks yourself. For stuff like bitblits, X is as fast as DirectDraw (quite an accomplishment for a generalized graphics system!) On my machine, X can copy around ~2GB of 100x100 pixmaps per second, which makes for a bandwidth utilization of about ~4GB/sec. That's pretty close to the maximum memory bandwidth of my graphics card, which is 6.4GB/sec.
X has been quite fast in practice too. SGI shipped a very high-performance X implementation. The main issue is that until recently, there wasn't a lot of interest on X machines on the desktop, even that little interest was in the workstation market, where absolute performance matters more than the responsiveness of the UI. Now that there is interest on putting X on the desktop, people are working on making it more suitable for that role.
Its not so much its superiority to imake, as its superiority to the imake setup of XFree86. The XFree86 build scripts are horribly complex to understand, and while autoconf/automake suck too, they suck less. Plus, more people are familier with them, so there is less of a learning curve for developers.
I'm curious, what kind of hardware have you used it on?
I have used it on:
Pentium II 440LX chipset (Riva TNT)
Athlon XP SiS 730 chipset (GeForce2 MX)
Pentium 4 845M chipset (GeForce4 Go 440)
I don't use Xinerama or TV out very often.
It'd make a lot more sense to just use XCB instead?