GNU C has never generated the best code for any platform--it purposely traded off retargetability for ultimate performance. Sun's compilers easily beat GNU C on SPARC, and even on the 68k there were proprietary compilers that generated better code. Anybody who has done any high performance computing with GNU C should know that, or they should perhaps start working in a different field. What GNU C does offer is decent performance, consistency across platforms, multiple integrated language front-ends, and some very useful extensions and features. Those advantages usually far outweigh a moderate performance gain.
I do a lot of high performance computing with GNU C. It doesn't matter to me how fast the Pentium works with some oddball proprietary compiler--the performance I get with GNU C is the performance an Intel-based machine has for my purposes. If that's less than optimal, that just makes Intel's platform less attractive. If Intel wants to do something about that, they should invest in improving the GNU C backend.
You have a fundamental misunderstanding of what open source is all about. Open source is not about producing the "best" software, it is producing about a variety of software that people can pick and choose from and adapt to their own needs. GNU C may not be the compiler I need, but unlike Intel's or Microsoft's compiler, I can hack GNU C and make it fit my needs.
Now, as for GNU C and benchmarks, GNU C has never produced the fastest code on any platform. Unless you lived under a rock and never did any high performance computing, you'd know that. And if you took the time to look at the GNU C documentation, you'd also know that this is no accident. But to most GNU C users, this fact never mattered. GNU C generates decent code and it has many other attributes that make it the "best" compiler for many applications.
You see, there is another misunderstanding that you and Bill Gates share: you think that there is a single "best" solution to everything. In real life, there isn't. What is "best" for you isn't necessarily "best" for me, and there may well be no way to reconcile our conflicting needs in the same piece of software.
I do agree that Slashdot moderation tends to exclude voices like yours and I think that's wrong. Why? So that one can point out how uninformed and confused you actually are.
There is only so much bandwidth to go around. You can allocate it one way or another. We have chosen to allocate it by frequency channels. That's simple and low-tech.
UWB doesn't give you any unused spectrum, it just degrades that the spectrum there is uniformly for everybody else. In small amounts, that may not be a problem, but in big amounts it is. Think of it like trash: the occasional piece of paper on the street isn't a problem, but if everybody dumps their garbage on the sidewalk, it's a big problem.
If UWB were ever widely deployed, you can think of it as generating noise kind of like one billion light switches turned on and off many times per second. It's best to put a stop to that before it starts. Or, if we are going to throw out frequency based allocation, let's do it consciously (and let's wait for the UWB patents to run out before we do it).
The patent office is completely overwhelmed with patents and examiners get rewarded by how many patents they actually process. Examiners neither have the time, nor the training, nor any incentive to reject patent claims or patents. Except in obviously bad cases (perpetual motion machines), it's easier and more rewarding to rubber stamp patents and let the courts sort things out. That wouldn't even be much of a problem if the legal system were set up for that, but the legal system still presumes that if a patent has been examined, it is valid, and invalidating it is very hard. Furthermore, companies obtaining invalid patents pay little but stand to gain a lot. The incentives are all skewed.
Given who sits at the head of the PTO and his background, this isn't going to change anytime soon.
I don't see any interesting claims in that patent on inventions that extend significantly hat was already known and used when it was filed. The patent was filed in 2000 (continuation from a patent filed in 1999) and the techniques claimed in the patent were then already being used by disconnected web browsing software, rsync, unison, and Plucker. The fact that several of those systems aren't even mentioned in the references suggests that this patent was filed out of ignorance rather than malice.
So, what it comes down to is that this is just another bad software patent, claiming inventions on things that someone of reasonable skill in the art should know.
Obviously, they should charge by volume. And they should have separate rates for traffic during peak and off-peak hours. You get high speed access, and they get properly reimbursed for their costs. If you want to hook up all your neighbors at that retail price, be their guest.
I don't understand why this is so terribly hard to figure out. I mean, that's the way you pay for electricity and gas. The only reason you don't pay that way for local phone service is because of some antiquated rules. And the only reason ISPs likely don't do it is because they don't have the necessary accounting software. Well, they should get it rather than try to establish non-sensical and invasive rules.
The hard part is to get the text corresponding to the encoded message so that you don't have to type it in. The ULeth Press Release has a JPEG (are you supposed to do OCR?), and the Go Figure web site has a really messy navigational structure and the message hidden in a PDF file. Now, getting it out requires experience with Adobe Acrobat or some other PDF tools. That's much harder than undoing the simple encoding or solving the trivial math problem.
There are lots of things that are good for the economy and efficiency that are clearly undesirable. Oil spills, for example, contribute to the GNP and productivity, but most of us don't want them.
So, yes, we probably do have a basic disagreement what constitutes "quality of life", and I suspect most people thinking it through carefully would tend to agree with my view rather than yours.
People already use GPS to retrieve navigational "messages" ("turn right here"), informational messages ("you are standing in front of the X"), messages during the maintenance of large structures ("the water pipe is 30ft ahead of you"), etc. Location-aware ads have been hyped in the valley for a few years. OK, so people update these databases a bit more dynamically, so what? This is just another instance of giving a fancy name to something that's been in common practice for years. I mean, what else would you use GPS for? Great sales job, boring technology.
More interesting perhaps are location-dependent messages sent out by beacons that transmit information (via Bluetooth or IR) locally--you really have to be physically there to receive the information. And those kinds of systems actually happen to be a little easier to deploy, since handhelds already have IR (and soon Bluetooth) built-in, while GPS is still an expensive option.
Hydrogen in bottled form is, of course, fairly common and fairly safe, but it may simply be too inconvenient for this application. For something that heavy and big, maybe it would be more better if it could run on alcohol ("a bottle of vodka"), bottled gas, or some solid hydride that is activated with water and later recycled.
I think that's another instance of confusing cause and effect. The US used to have compact cities, very similar to Germany. And to get from city to city, you could use trains (or nowadays planes).
Urban sprawl and poor land use was made possible in the US by policies that subsidized, directly and indirectly, the automobile. Geography does not have to be destiny in this case. If gas prices went up dramatically as a result of shortages and if public funding were redirected towards convenient and efficient public transportation, people would move back into the cities. It would help the environment, reduce traffic fatalities, improve communities, and result in an overall better quality of life.
Of course, there shouldn't be a sudden change in direction--doing so would be devastating. But it could be a goal for the next 30-60 years, with gradually phased in gas prices, gradual reductions in road building, and gradual changes in land use policies..
When you reconstruct a function from sampled data, there are an infinite number of possible reconstructions. That issue is resolved by making certain assumptions about the functions you are reconstructing. An assumption of band-limited data is useful because it approximates what happens in many communications systems and (perhaps more importantly) because it leads to simple and efficient algorithms (some comment about only having hammers and everything looking like nails is in order).
There are already many other methods for reconstructing functions from sparse, non-uniformly sampled data, so this paper doesn't solve an unsolved problem. Rather, it provides one more solution under a set of assumptions that are mathematically a bit more like those of the original sampling theorem.
Will it be useful? That's hard to tell at this point. I think it will take a lot more work to figure out whether this method is any better than existing methods on real-world problems, whether its application can be justified in real problems, and whether it leads to algorithms that are practical. It may also turn out that the method is closely related to methods already in use in other fields; for example, the kinds of function spaces they study have received some attention in neural networks, but the authors cite no papers from that work and may not be aware of it.
Doctor to patient, after looking at the reconstructed images: "Ah there is the problem. The cause of your headaches is that you have a bunch of inch-long bony spikes sticking out of your neck, plus a bunch of holes in your skull."
You need to think back a little further. Like, for example, why Somalia had a hunger crisis, why there were warlords, why there were lots of weapons, and why the situation there was as bleak as it was. The US, USSR, and Europe were involved in the region for centuries and have to accept responsibility for many of the conditions there. That isn't to say that Africa would be a paradise without outside involvement, but at least its crises would be of its own making. And while "food aid" may sound like a glorious justification in the short run, its delivery may cause even more problems in the long run.
"Look at the starving people" and "we need the oil" are both convenient justifications for diplomatic and military actions, but they don't get at the root causes. Such disasters can only be averted if we start thinking very far ahead, and we may well have to let a country sort out its problems for itself in order to eventually emerge as a cohesive and free nation. Or where do you think the US would be today if the UN, Britain, and Russia had sent in peace keepers during the US civil war?
Chomsky has a visceral hatred of the US Military and the US goverment, and its very evidne tin his writing and speech.
Well, Chomsky also has spent more time than you or me studying these issues and groups. Has it occurred to you that his "visceral dislike" may be based on the facts that he has uncovered? His antipathy is likely the effect, not the cause, of his studies.
I don't read Chomsky's writings. But I do read other books on 20th century US history, and the more one finds out, the more uncomfortable one feels: the US government has done lots of really sleazy things throughout its history. And at fault is a complacent citizenry that has nearly blind trust into their government, that is ignorant of political and economic interests in the world, and that questions almost nothing the government says or does. I suggest you read up on your US and world history a bit and start questioning your government--that isn't only your right, it's your duty in a democracy.
Unfortunately, oil IS currently a critical piece of our economy, until we figure out a workaround for that (i.e. fuel cell powered vehicles combined with efficient fusion, solar, geothermal, hydroelectric power generation on large scales).
The US could be energy self-sufficient if it used energy at the rates comparable to some of the more energy conserving advanced nations in the world. Our standard of living wouldn't be affected and we wouldn't lose any jobs.
US dependency on oil is not much different from US dependency on drugs: it's an addiction that makes lots of people very rich. In the case of oil, the oil companies love it, the military loves it, the car companies love it, and the politicians love it. Think about what trouble these powerful groups were in if we weren't dependent on oil, and it won't surprise you anymore why this country doesn't seem to be able to come up with decent energy conservation measures.
BTW, I'm not suggesting that this is some grand, deliberate conspiracy. Oil-friendly politicians, for example, probably think they are doing the right thing anyway. But it's a well-established scientific fact that you can't take money from some group and have your decisions not be influenced by their wishes.
Maybe he hopes for better performance and reliability than PowerDVD or WinDVD, both of which are kind of iffy. Or maybe he has a kiosk application in mind, where the bootable CD provides security and robustness. Or maybe he runs some business version of Windows that doesn't have DVD players but would like to be able to play a DVD on occasion. There are lots of possible reasons.
Granted, I don't use AOL (I was a subscriber briefly to see what it was like) and would prefer to keep it that way, like probably many other tech-savvy folks.
But why this hostility to AOL as an investor? Their funding of Mozilla seems to have benefitted the open source community greatly. Without that, I doubt Netscape or Mozilla would still be around in any form.
If RedHat investors find it advantageous to sell the company, I don't blame them if they do. RedHat's business model never really impressed me, and it might well be better off as an AOL subsidiary, kept alive as a hedge against Microsoft. And given that Linux is GPL'ed and that AOL has been reasonably well-behaved in the past, I don't see a problem. Let's give these people a break.
Re:MS Windows vs. X, same hardware
on
Xfree86 4.2.0 Out
·
· Score: 3, Interesting
There are VERY obvious performance differences between any version of Windows and as new of version of X as you want. X Windows programs flicker like mad when moving or resizing, objects aren't responsive, the mouse frame rate is low,
Those are problems with the toolkits. None of the modern toolkits (Gtk+, Qt, wxWindows, FLTK, Mozilla, etc.) use X11 very efficiently. The redraw logic in Gtk+, Qt, and Mozilla is, in fact, in violation of X11 guidelines. The reason is that these toolkits are mostly written with a Windows GDI mindset, either because that's what their authors are familiar with, or because they want to achieve cross-platform compatibility and it's easier to treat X11 as a second-class citizen.
applications all have inconsistent look and feel,
X11 is not a user interface or desktop, it's a network transparent windowing system. If your user interface is inconsistent, you only have yourself to blame for it: don't run X11 applications written for different toolkits or desktops. You get similar inconsistencies if you start running Motif or FLTK or wxWindows or Mozilla applications on Windows or MacOS.
And if you say that I need to tweek it to get it as fast as MS, then MS wins.
I'm posting this from Galeon running on a vanilla Debian installation on a 200MHz Pentium with 64M of RAM and a 5 year old graphics card. Windows wouldn't even boot on this configuration without excessive paging, and IE is a dog. In the past, all the graphics benchmarks I have done ran faster on good X11 implementations than on Windows. So, I challenge your implicit the claim that Linux+X11 is less efficient than Windows. But even if that were the case, on 1GHz machines with 512M of RAM, any such differences are academic.
However, the Gnome and KDE desktops are comparatively slow and resource intensive, probably similar to recent versions of Windows. I couldn't run them very well on this machine (although they do run). That is something you will have to take up with the authors of those desktops. But they, too, are designed for modern machines, where it really doesn't matter.
only poorly written applications are affected
on
Xfree86 4.2.0 Out
·
· Score: 3, Interesting
X11 batches requests, so the overhead of context switches compared to the overhead of drawing stuff is negligible. In fact, X11 is better off than, say, Windows GDI, which incurs similar context switches but hasn't been designed from the ground up with context switching in mind.
Now, about latency. If you compare local access to X11 with local access to, say, Windows or OSX, I don't think you'll see practically significant differences. (Well-written applications will use shared memory for any kind of bulk data transfer.)
About the graphics model. The X11 graphics model is complex. It really does expose a lot about the underlying graphics hardware to you and it gives you pixel accurate rendering. That was crucially important in the 1980's and has served X11 extremely well for nearly two decades. Today, it's less important, since you don't get a lot of low-depth screens anymore. I would expect that in the future, the RENDER extension will become the predominant graphics API and the core X11 graphics APIs will receive less attention. Implementing the core X11 graphics doesn't need to be a lot of code, and you don't have to worry about all the oddball bitmap formats if you don't want your applications to run with oddball display devices. But in some markets, that kind of control is important, and X11 provides it in a portable and network transparent manner.
Overall, X11 is an old system and has accumulated some cruft. It's also a complex system because it does some really nifty things that neither Windows nor MacOSX have really tackled well. On balance, I think it's still a very modern network transparent windowing system, and if you were to design something with similar functionality today, it wouldn't look all that different or be all that much simpler. So, I vote for keeping X11, not because it's widely used, but because it's actually quite good. And I hope people will spend the time to understand X11 better. The people who designed it were very good; give them the benefit of the doubt.
X11 solves the messy, low-level problems
on
Xfree86 4.2.0 Out
·
· Score: 2
I don't see what the point of moving away from X11 would be. X11 now supports antialiasing and transparency efficiently. You can build whatever GUI you want on top of that. And building a Mac OSX-like GUI doesn't get any easier if you throw out X11 first and start from scratch implementing low-level graphics routines.
X11 solves the nitty-gritty, uninteresting parts of writing a GUI, like drawing, acceleration, event handling and dispatch, clipping, input methods, remote access, security, window management protocols, and others. X11 extensions provide a host of other functionaliy, like 3D rendering, direct rendering, audio, printing, image processing, decompression, and embedding, clearly specified and all remotely and transparently accessible. You don't have to solve these problems again. And I think X11 solves these problems better than Windows or OSX.
I think it would be great if people started thinking again about implementing a high-quality GUI on top of X11, something that takes full advantage of X11's functionality. Sadly, all the popular toolkits right now (Gtk+, Qt, Mozilla, GNUStep, FLTK, wxWindows, Swing, etc.) take more of a Windows-like approach to building toolkits, and that just doesn't mesh well with X11. Since most of those toolkits want to be cross-platform,
they take a lowest-common-denominator approach. As a result, they have to cope with all the complexities of X11 without deriving much benefit from it.
So, please do think about designing a great toolkit and a great user interface--we need more of those. But don't waste your time on reimplementing the low-level stuff--X11 already does that probably better and more efficiently than anything else out there. Concentrate on what you want to do and take full advantage of X11 functionality--if you really do have a good idea for how to build a better UI, you'll be done much faster than if you start from scratch.
For an airline, to leave their wirless network at the airport completely unprotected is grossly negligent. This is something that you don't need to "deliberately hack into"--my wireless card would connect to that network if I turned on my laptop near one of their base stations. What do you propose now? Arrest anybody who turns on their laptop in the airport?
It is your kind of attitude that is responsible for the security holes that allow terrorist attacks in the first place. Airlines and airports must fix these problems preemptively. Apparently, they are unwilling to pay what that costs in this competitive market. It takes a big bang or public relations disaster to have them act decisively. If the people who found this problem just spoken to someone "in charge", nothing would have happened.
The temptation to haul anybody in on federal charges who does something that might be suspicious is unacceptable. We live in a free society, and lots of people will do things that are harmless but that my strike someone as suspicious. As in other areas of security, it's foolish to assume that the bad guys will have less knowledge than the general public, and it's foolish to assume that the bad guys won't have the resources to find the security problems easily and with low risk of detection. If you arrest everybody who appears to be trying to discover holes in your security systems, you'll mostly end up arresting harmless and you give police the tools to arrest anybody at their discretion; just about any activity can be construed to be suspicious. That's called a police state. Maybe that's where you want to live, but I don't. As far as security is concerned, the "get-tough" approach is a cop-out for companies that don't want to pay the money necessary for doing security right. It gives the appearance of security without delivering actual security.
Companies that have such security holes should get stiff fines, retroactively and for as long as the security holes persist. That's the only way to force them to invest the money up-front necessary to make their systems secure. And if that isn't sufficient, there needs to be federal regulations specifying rules and requirements for things like networking, screener training and salary, etc. People who discover security holes should be left alone (unless they try to take advdantage of them to do something illegal, of course).
Sure, it's Adobe's choice to ship to China. It's China's choice whether to create the environment in which companies like Adobe make money on their software. Neither side is obligated to the other.
When Adobe floats such ideas prior to pulling out of the market, it goes beyond a business decision--it becomes a threat, a political ploy, and public-relations issue.
My point is that no matter what China does or doesn't do, Adobe will keep shipping their software there. The cost is peanuts for Adobe compared to the threat of having an Asian competitor emerge.
You forgot the third option: making the kernel modular and distributing different "versions" [of individual drivers and modules] as separate binary packages [from different sources, where it makes sense].
Slashdot Mirror
I do a lot of high performance computing with GNU C. It doesn't matter to me how fast the Pentium works with some oddball proprietary compiler--the performance I get with GNU C is the performance an Intel-based machine has for my purposes. If that's less than optimal, that just makes Intel's platform less attractive. If Intel wants to do something about that, they should invest in improving the GNU C backend.
Now, as for GNU C and benchmarks, GNU C has never produced the fastest code on any platform. Unless you lived under a rock and never did any high performance computing, you'd know that. And if you took the time to look at the GNU C documentation, you'd also know that this is no accident. But to most GNU C users, this fact never mattered. GNU C generates decent code and it has many other attributes that make it the "best" compiler for many applications.
You see, there is another misunderstanding that you and Bill Gates share: you think that there is a single "best" solution to everything. In real life, there isn't. What is "best" for you isn't necessarily "best" for me, and there may well be no way to reconcile our conflicting needs in the same piece of software.
I do agree that Slashdot moderation tends to exclude voices like yours and I think that's wrong. Why? So that one can point out how uninformed and confused you actually are.
UWB doesn't give you any unused spectrum, it just degrades that the spectrum there is uniformly for everybody else. In small amounts, that may not be a problem, but in big amounts it is. Think of it like trash: the occasional piece of paper on the street isn't a problem, but if everybody dumps their garbage on the sidewalk, it's a big problem.
If UWB were ever widely deployed, you can think of it as generating noise kind of like one billion light switches turned on and off many times per second. It's best to put a stop to that before it starts. Or, if we are going to throw out frequency based allocation, let's do it consciously (and let's wait for the UWB patents to run out before we do it).
Given who sits at the head of the PTO and his background, this isn't going to change anytime soon.
So, what it comes down to is that this is just another bad software patent, claiming inventions on things that someone of reasonable skill in the art should know.
I don't understand why this is so terribly hard to figure out. I mean, that's the way you pay for electricity and gas. The only reason you don't pay that way for local phone service is because of some antiquated rules. And the only reason ISPs likely don't do it is because they don't have the necessary accounting software. Well, they should get it rather than try to establish non-sensical and invasive rules.
The hard part is to get the text corresponding to the encoded message so that you don't have to type it in. The ULeth Press Release has a JPEG (are you supposed to do OCR?), and the Go Figure web site has a really messy navigational structure and the message hidden in a PDF file. Now, getting it out requires experience with Adobe Acrobat or some other PDF tools. That's much harder than undoing the simple encoding or solving the trivial math problem.
So, yes, we probably do have a basic disagreement what constitutes "quality of life", and I suspect most people thinking it through carefully would tend to agree with my view rather than yours.
More interesting perhaps are location-dependent messages sent out by beacons that transmit information (via Bluetooth or IR) locally--you really have to be physically there to receive the information. And those kinds of systems actually happen to be a little easier to deploy, since handhelds already have IR (and soon Bluetooth) built-in, while GPS is still an expensive option.
Hydrogen in bottled form is, of course, fairly common and fairly safe, but it may simply be too inconvenient for this application. For something that heavy and big, maybe it would be more better if it could run on alcohol ("a bottle of vodka"), bottled gas, or some solid hydride that is activated with water and later recycled.
Urban sprawl and poor land use was made possible in the US by policies that subsidized, directly and indirectly, the automobile. Geography does not have to be destiny in this case. If gas prices went up dramatically as a result of shortages and if public funding were redirected towards convenient and efficient public transportation, people would move back into the cities. It would help the environment, reduce traffic fatalities, improve communities, and result in an overall better quality of life.
Of course, there shouldn't be a sudden change in direction--doing so would be devastating. But it could be a goal for the next 30-60 years, with gradually phased in gas prices, gradual reductions in road building, and gradual changes in land use policies..
There are already many other methods for reconstructing functions from sparse, non-uniformly sampled data, so this paper doesn't solve an unsolved problem. Rather, it provides one more solution under a set of assumptions that are mathematically a bit more like those of the original sampling theorem.
Will it be useful? That's hard to tell at this point. I think it will take a lot more work to figure out whether this method is any better than existing methods on real-world problems, whether its application can be justified in real problems, and whether it leads to algorithms that are practical. It may also turn out that the method is closely related to methods already in use in other fields; for example, the kinds of function spaces they study have received some attention in neural networks, but the authors cite no papers from that work and may not be aware of it.
Doctor to patient, after looking at the reconstructed images: "Ah there is the problem. The cause of your headaches is that you have a bunch of inch-long bony spikes sticking out of your neck, plus a bunch of holes in your skull."
"Look at the starving people" and "we need the oil" are both convenient justifications for diplomatic and military actions, but they don't get at the root causes. Such disasters can only be averted if we start thinking very far ahead, and we may well have to let a country sort out its problems for itself in order to eventually emerge as a cohesive and free nation. Or where do you think the US would be today if the UN, Britain, and Russia had sent in peace keepers during the US civil war?
Well, Chomsky also has spent more time than you or me studying these issues and groups. Has it occurred to you that his "visceral dislike" may be based on the facts that he has uncovered? His antipathy is likely the effect, not the cause, of his studies.
I don't read Chomsky's writings. But I do read other books on 20th century US history, and the more one finds out, the more uncomfortable one feels: the US government has done lots of really sleazy things throughout its history. And at fault is a complacent citizenry that has nearly blind trust into their government, that is ignorant of political and economic interests in the world, and that questions almost nothing the government says or does. I suggest you read up on your US and world history a bit and start questioning your government--that isn't only your right, it's your duty in a democracy.
The US could be energy self-sufficient if it used energy at the rates comparable to some of the more energy conserving advanced nations in the world. Our standard of living wouldn't be affected and we wouldn't lose any jobs.
US dependency on oil is not much different from US dependency on drugs: it's an addiction that makes lots of people very rich. In the case of oil, the oil companies love it, the military loves it, the car companies love it, and the politicians love it. Think about what trouble these powerful groups were in if we weren't dependent on oil, and it won't surprise you anymore why this country doesn't seem to be able to come up with decent energy conservation measures.
BTW, I'm not suggesting that this is some grand, deliberate conspiracy. Oil-friendly politicians, for example, probably think they are doing the right thing anyway. But it's a well-established scientific fact that you can't take money from some group and have your decisions not be influenced by their wishes.
Maybe he hopes for better performance and reliability than PowerDVD or WinDVD, both of which are kind of iffy. Or maybe he has a kiosk application in mind, where the bootable CD provides security and robustness. Or maybe he runs some business version of Windows that doesn't have DVD players but would like to be able to play a DVD on occasion. There are lots of possible reasons.
But why this hostility to AOL as an investor? Their funding of Mozilla seems to have benefitted the open source community greatly. Without that, I doubt Netscape or Mozilla would still be around in any form.
If RedHat investors find it advantageous to sell the company, I don't blame them if they do. RedHat's business model never really impressed me, and it might well be better off as an AOL subsidiary, kept alive as a hedge against Microsoft. And given that Linux is GPL'ed and that AOL has been reasonably well-behaved in the past, I don't see a problem. Let's give these people a break.
Those are problems with the toolkits. None of the modern toolkits (Gtk+, Qt, wxWindows, FLTK, Mozilla, etc.) use X11 very efficiently. The redraw logic in Gtk+, Qt, and Mozilla is, in fact, in violation of X11 guidelines. The reason is that these toolkits are mostly written with a Windows GDI mindset, either because that's what their authors are familiar with, or because they want to achieve cross-platform compatibility and it's easier to treat X11 as a second-class citizen.
applications all have inconsistent look and feel,
X11 is not a user interface or desktop, it's a network transparent windowing system. If your user interface is inconsistent, you only have yourself to blame for it: don't run X11 applications written for different toolkits or desktops. You get similar inconsistencies if you start running Motif or FLTK or wxWindows or Mozilla applications on Windows or MacOS.
And if you say that I need to tweek it to get it as fast as MS, then MS wins.
I'm posting this from Galeon running on a vanilla Debian installation on a 200MHz Pentium with 64M of RAM and a 5 year old graphics card. Windows wouldn't even boot on this configuration without excessive paging, and IE is a dog. In the past, all the graphics benchmarks I have done ran faster on good X11 implementations than on Windows. So, I challenge your implicit the claim that Linux+X11 is less efficient than Windows. But even if that were the case, on 1GHz machines with 512M of RAM, any such differences are academic.
However, the Gnome and KDE desktops are comparatively slow and resource intensive, probably similar to recent versions of Windows. I couldn't run them very well on this machine (although they do run). That is something you will have to take up with the authors of those desktops. But they, too, are designed for modern machines, where it really doesn't matter.
Now, about latency. If you compare local access to X11 with local access to, say, Windows or OSX, I don't think you'll see practically significant differences. (Well-written applications will use shared memory for any kind of bulk data transfer.)
About the graphics model. The X11 graphics model is complex. It really does expose a lot about the underlying graphics hardware to you and it gives you pixel accurate rendering. That was crucially important in the 1980's and has served X11 extremely well for nearly two decades. Today, it's less important, since you don't get a lot of low-depth screens anymore. I would expect that in the future, the RENDER extension will become the predominant graphics API and the core X11 graphics APIs will receive less attention. Implementing the core X11 graphics doesn't need to be a lot of code, and you don't have to worry about all the oddball bitmap formats if you don't want your applications to run with oddball display devices. But in some markets, that kind of control is important, and X11 provides it in a portable and network transparent manner.
Overall, X11 is an old system and has accumulated some cruft. It's also a complex system because it does some really nifty things that neither Windows nor MacOSX have really tackled well. On balance, I think it's still a very modern network transparent windowing system, and if you were to design something with similar functionality today, it wouldn't look all that different or be all that much simpler. So, I vote for keeping X11, not because it's widely used, but because it's actually quite good. And I hope people will spend the time to understand X11 better. The people who designed it were very good; give them the benefit of the doubt.
X11 solves the nitty-gritty, uninteresting parts of writing a GUI, like drawing, acceleration, event handling and dispatch, clipping, input methods, remote access, security, window management protocols, and others. X11 extensions provide a host of other functionaliy, like 3D rendering, direct rendering, audio, printing, image processing, decompression, and embedding, clearly specified and all remotely and transparently accessible. You don't have to solve these problems again. And I think X11 solves these problems better than Windows or OSX.
I think it would be great if people started thinking again about implementing a high-quality GUI on top of X11, something that takes full advantage of X11's functionality. Sadly, all the popular toolkits right now (Gtk+, Qt, Mozilla, GNUStep, FLTK, wxWindows, Swing, etc.) take more of a Windows-like approach to building toolkits, and that just doesn't mesh well with X11. Since most of those toolkits want to be cross-platform, they take a lowest-common-denominator approach. As a result, they have to cope with all the complexities of X11 without deriving much benefit from it.
So, please do think about designing a great toolkit and a great user interface--we need more of those. But don't waste your time on reimplementing the low-level stuff--X11 already does that probably better and more efficiently than anything else out there. Concentrate on what you want to do and take full advantage of X11 functionality--if you really do have a good idea for how to build a better UI, you'll be done much faster than if you start from scratch.
It is your kind of attitude that is responsible for the security holes that allow terrorist attacks in the first place. Airlines and airports must fix these problems preemptively. Apparently, they are unwilling to pay what that costs in this competitive market. It takes a big bang or public relations disaster to have them act decisively. If the people who found this problem just spoken to someone "in charge", nothing would have happened.
The temptation to haul anybody in on federal charges who does something that might be suspicious is unacceptable. We live in a free society, and lots of people will do things that are harmless but that my strike someone as suspicious. As in other areas of security, it's foolish to assume that the bad guys will have less knowledge than the general public, and it's foolish to assume that the bad guys won't have the resources to find the security problems easily and with low risk of detection. If you arrest everybody who appears to be trying to discover holes in your security systems, you'll mostly end up arresting harmless and you give police the tools to arrest anybody at their discretion; just about any activity can be construed to be suspicious. That's called a police state. Maybe that's where you want to live, but I don't. As far as security is concerned, the "get-tough" approach is a cop-out for companies that don't want to pay the money necessary for doing security right. It gives the appearance of security without delivering actual security.
Companies that have such security holes should get stiff fines, retroactively and for as long as the security holes persist. That's the only way to force them to invest the money up-front necessary to make their systems secure. And if that isn't sufficient, there needs to be federal regulations specifying rules and requirements for things like networking, screener training and salary, etc. People who discover security holes should be left alone (unless they try to take advdantage of them to do something illegal, of course).
IBM's low-end laptops have in the past come from Asian manufacturers. I think they do a bit of customization in terms of colors and keyboards.
When Adobe floats such ideas prior to pulling out of the market, it goes beyond a business decision--it becomes a threat, a political ploy, and public-relations issue.
My point is that no matter what China does or doesn't do, Adobe will keep shipping their software there. The cost is peanuts for Adobe compared to the threat of having an Asian competitor emerge.
You forgot the third option: making the kernel modular and distributing different "versions" [of individual drivers and modules] as separate binary packages [from different sources, where it makes sense].