You've apparently missed all the heartfelt and often tearful thank-yous they get from parents with their kids in the hospital. I was in the room only a few yards away from the woman who broke down crying during PAX East thanking them for doing Child's Play because such things meant so much to her. It's on the episode of their reality show for PAX East that came out recently if you want to see it for yourself. Child's Play does make a real difference in people's lives and that shouldn't be discounted.
That rat heart story is exciting, but it's not organ printing. I'd urge caution about the heart experiment. It's cool that they pulled it off, but some of the caveats from the Nature Medicine paper reporting it are that it doesn't beat nearly as strongly as a normal heart, nor is it beating properly in time. No actual blood flow has been pushed through the thing, so we don't know if it can perform well enough to replace even diseased tissue in a person. Finally, if you think about doing this in a person, you'd need a donor heart. There's very few of these available, and the vast majority of them are from old people who probably don't have the best hearts available. And it's not at all clear yet that we could print an effective heart scaffold de novo and have it work as well, although it's a possibility. Proof of concept is still waiting.
So, at least in this really challenging case (replacing a blood vessel and a heart aren't even remotely on the same scale of complexity) it really does look like we're still decades away.
To be fair, as you well know X driver hackers (or X hackers in general) are few and far between, and so aren't the easiest group to hire. Pretty much everyone got snapped up by Intel and RH, so there's no one competent for Canonical to hire right now. That said, I'd like to see some serious X/mesa/whatever code come out of Canonical too.
It's still far too young to see any real successes. Prior to the past year, there wasn't any realistic way to make use of stem cells in many circumstances because of the paucity of cell lines available. Now there's more coming online. The real breakthrough though, Induced pluripotent Stem (iPS) cell technology, is brand new, and people have spent the last year making it safer by removing cMyc and whatever other oncogenes were necessary in the original formulation. That's basically done now and iPS cells should be less cancerous, so people are starting to move forward.
Remember that clinical trials take a very long time, so don't expect to see results so soon. Clinical trials for stem cell therapy are underway and from what little I've read they seem to be going well. You're right that the cancer problem still needs to be solved, and that it's never a good idea to believe wild predictions, things are looking vastly more positive for stem cell therapy than you make out.
Rather than just reading the first paragraph, try reading the whole article.
In the Polanco case, as in Daniel's, there was no shortage of documentation. The account of the history teacher's interactions with the apparently suicidal boy came primarily from his teaching assistant, who wrote a detailed letter to administrators. In addition, students submitted written statements that were introduced at Polanco's hearing.
If you think that the TA is a "an emotionally disturbed 12 year old" then you fail at reading comprehension. Bringing your own prejudices to the article is cute and all, but no one, especially not a teacher should be telling a kid who tried to commit suicide that he should "Carve deeper next time". If you don't trust the TA's word then that's your business, but if you want to side with a teacher who's encouraging an eighth grader to commit suicide then I think you're one sick fuck.
Have you actually been in the channel recently? #debian has gotten a lot more civil than it used to be. On either oftc or freenode, honest (and there tends to be a lot of trolling fake newbs) questions get answered. Some of the questions are answered with a very polite version of RTFM, usually with a link of some sort or a factoid stored in the bot (named dpkg), but honestly those tend to be better answers than painfully working through a problem. Most of the time, even the experts don't know the real answer to the question, but we know how to go about finding out. That's where the RTFM-style answers tend to come from, because it's exactly what we'd do if we were in their situation. Most help-seekers in #debian seem to understand this.
I've run Debian for close to a decade now, and I doubt that most Debian users think that the defaults are bad, so much as just not what they're used to. Most of us have our peculiar choices that we've made and like to stick with. If you want a full featured vim on your system rather than the stripped down default, you need to install the appropriate packages. If you want emacs, you have to install it. If you don't like xchat because you've been using irssi for years, you have to install it. If you have no need for OpenOffice, but desperately need a LaTeX installation, you need to add it. If you like awesome or some other tiling window manager instead of gnome, you just install it and go. Many people using Debian, especially those of us who've been using it for a very long time, have specific needs that aren't really appropriate for everyone. Debian's great strength has long been the ease of managing software installation and removal to craft the system that you need and want. Debian users just tend to leverage that strength.
He continues....What would the world be like without Google?... Only C++ can allow you to create applications as powerful as MapReduce which allows them to create fast searches.
I totally agree. If Java ( or Pyhton etc. for that matter ) were fast enough why did Google choose C++ to build their insanely fast search engine. MapReduce rocks.. No Java solution can even come close.
I rest my case.
Apparently you've not heard of Hadoop which is written in Java and, unlike Google's MapReduce, actually available to people outside of Google today.
Jython is actually getting that love right now. Right around the time Sun hired the JRuby guys they also hired two Jython guys. Jython has a new improved backend and is rapidly approaching a 2.5 release which will bring it up to speed with the current stable CPython. They're going to get to work on py3k compatibility after that. Hopefully they'll be able to achieve parity with CPython within a year or so, but they're definitely making very real progress.
Javascript is actually quite a compact language if you use it well. Looking at the scriptaculous code, it looks well written to me. The code in question implements a lot of features though, including drag and drop, sortable trees, and a whole lot of events to deal with the realities of the DOM, which is totally independent from javascript.
Your characterization of javascript is rather bizarre. It has encapsulation via closure and inheritance via prototypes. Closures in javascript are critical to actually using the language in a nice way if you listen to Doug Crockford, whereas rubyists tend to ignore them and just pass lambdas that don't depend on closure around. That said, no other language in that list relies on lambdas in the same way. Python has them, but they're notoriously limited. So I agree with the grandparent that Javascript and Ruby are relatively close languages, when compared to the others on that list. About the only thing I can imagine that's closer to Javascript is Scheme or Lisp.
Squeak is most definitely not GPL. It was under a special Apple Open Source license thingy for a while (maybe the APL itself, I don't know) and has now been relicensed under an MIT/X11 license. The squeak community is actually very hostile to the GPL, so you'll see most projects under MIT/X11.
I used to be a pretty serious gamer. Then I installed linux and slowly started spending more of my time doing that and less time gaming. I just found it a lot more fun to learn about how to use UNIX or messing around with the system than playing games. I like to say that linux became my game. Eventually I transitioned in to actually helping develop the system I used and that was pretty much the end of my serious gaming days.
Strangely enough, I've been getting back in to gaming little by little over the past few years, although not on PC's. The sorry state of the PC gaming market has been discussed elsewhere, so I won't add to that, but I've been using games as a way to spend time with my girlfriend, which is something I simply can't do with linux. So we play the PS2 and the Wii and we've just started looking at good old board and card games over the past few days. It's not just me either, many of my hardcore linux developer friends are buying wii's and such these days. I never thought I'd return to gaming, but it's worked out very well as a social tool for this penguin.
Re:So when do we get its successor?
on
X Power Tools
·
· Score: 2, Interesting
(Argh, why did I not use preview? Sorry, posted again with formatting!)
It's not at all clear that we could gain anything by starting over, and in fact we'd probably lose quite a bit. Yes, there are old methods to do things, but they are being deprecated or replaced outright. XCB replacing Xlib is a particularly good example, as is the replacement of server-side fonts with client-side. Essentially these things aren't real issues any more, so they don't take up any real mental bandwidth when you need to work on X.
The drawing model and things that the UNIX Hater's Handbook talks about have been pretty well addressed over the last half decade. Cairo is the official replacement for the old drawing model that X provided, and Cairo works really well and is getting better all the time.
The problems you're talking about, like compositing well and having video work well with OpenGL, are not trivial problems, and they are often unsolved. We don't really know how to accelerate all sorts of rendering operations (glyph rendering is proving to be particularly difficult at the moment, for example) and for things like video in a composited opengl context it's highly unlikely that the code would get written any faster or cleaner if you were starting from scratch rather than reworking the existing codebase to make this necessarily complicated thing happen.
You're also ignoring many of the problems that X solves remarkably well. It's an incredibly modular design that allows for extensibility with simultaneous backwards compatibility. It actually does a very good job of managing windows. Finally, it does a ton of the dirty work like knowing how to read EDID blocks, parse a configuration file, or allow drivers to execute x86-mode BIOS calls on non-x86 hardware. All of this can be unpleasant code to write where you'd gain little or nothing by rewriting it.
So yeah, a cleaner design would be nice, but a vast amount of code has been fixed by deletion from the X server, to the point where the size of the server actually has gone down between some releases. So things are improving, and while it's slow, at least it's moving at a visible pace these days. Because of this, I'm really not convinced that starting over would get you more than the joy of reimplementing solutions to hard problems.
Re:So when do we get its successor?
on
X Power Tools
·
· Score: 1
It's not at all clear that we could gain anything by starting over, and in fact we'd probably lose quite a bit. Yes, there are old methods to do things, but they are being deprecated or replaced outright. XCB replacing Xlib is a particularly good example, as is the replacement of server-side fonts with client-side. Essentially these things aren't real issues any more, so they don't take up any real mental bandwidth when you need to work on X.
The drawing model and things that the UNIX Hater's Handbook talks about have been pretty well addressed over the last half decade. Cairo is the official replacement for the old drawing model that X provided, and Cairo works really well and is getting better all the time.
The problems you're talking about, like compositing well and having video work well with OpenGL, are not trivial problems, and they are often unsolved. We don't really know how to accelerate all sorts of rendering operations (glyph rendering is proving to be particularly difficult at the moment, for example) and for things like video in a composited opengl context it's highly unlikely that the code would get written any faster or cleaner if you were starting from scratch rather than reworking the existing codebase to make this necessarily complicated thing happen.
You're also ignoring many of the problems that X solves remarkably well. It's an incredibly modular design that allows for extensibility with simultaneous backwards compatibility. It actually does a very good job of managing windows. Finally, it does a ton of the dirty work like knowing how to read EDID blocks, parse a configuration file, or allow drivers to execute x86-mode BIOS calls on non-x86 hardware. All of this can be unpleasant code to write where you'd gain little or nothing by rewriting it.
So yeah, a cleaner design would be nice, but a vast amount of code has been fixed by deletion from the X server, to the point where the size of the server actually has gone down between some releases. So things are improving, and while it's slow, at least it's moving at a visible pace these days. Because of this, I'm really not convinced that starting over would get you more than the joy of reimplementing solutions to hard problems.
Re:My only suggestion for X
on
X Power Tools
·
· Score: 1
Very little is required to be in xorg.conf these days, and that amount has been getting less and less over time. You no longer need a serverlayout section, for example, because it's now inferred from the remaining sections. If you have no video card section one is automatically figured out for you. These are all relatively recent (last year or so) developments, but they do exist in the source tree today.
Causes For Rendering Bottlenecks
on
X Power Tools
·
· Score: 4, Informative
Jim is one of the original authors of X. Keith is essentially the de facto overlord of the current X.org, although he doesn't play dictator except in rare cases.
As for rendering bottlenecks, they are many and varied and none of them have to do with the network transparency issue. When local clients talk to a local server they do so via local sockets or shared memory, both of which are very fast and impose minimal or no penalties.
What accounts for bottlenecks are things like the inability to do compositing, leading to tearing of windows when they're being dragged. This is fixed by the composite extension and a fast compositing manager, like the one found in compiz.
Another issue is that the old driver architecture (XAA) was geared towards old-style drawings. These days we don't really look at stipple patterns much, so the new driver architecture (EXA) is geared towards solid fills and fast blits for bitmaps instead, which is what you end up doing on a modern desktop anyway. It turns out though that this is very hard to get right and the bugs are still being worked out. I don't think that this is really an issue with X being old so much as that this is just a damned hard problem to get right. It is being worked on (check out Carl Worth's blog for some examples on this particular front) so hopefully things will improve.
Finally, there's the constant bottleneck due to incomplete or inadequate drivers. The new radeonhd, for example, only recently gained 2d acceleration support, and still lacks any sort of 3d accel. This sort of problem prevents X from adequately taking advantage of all the hardware has to offer, so performance can suffer. As a result, you lose the ability to run things like compiz, which address these issues.
Finally, I haven't watched it yet, but I recommend you take a look at Keith Packard's google talk on remaking X. X has been largely rebuilt from the inside over the past several years, and things like Render, RandR, Composite, Damage, Fixes, Input Hotplug, and EXA have really sprung from that initiative. It's wort
For now, yes it is, but once Steve Jobs is gone the path will clear. Be it in ten or twenty years, once Jobs is gone Apple will once again lose its way and Linux will be able to continue onward and upward just as it always has. Some of us actually remember what Apple was like without Jobs at the helm. As it is, this just gives us more time to get Linux on the desktop polished and really ready.
Re:vim syntaxt is quite arcane
on
Hacking VIM
·
· Score: 1
You can script vim with several languages, including perl, python, and ruby. Not many scripts are written using them, but they are available provided that your vim build does enable those options.
I hope you're not trolling here. X.org has very few contributors as a whole. Maybe 20 or so, with about half who do real work on the graphics drivers. That's really not very many for such a large amount of code. So no, I'm sorry to break it to you, but there's no armies of experienced graphics driver coders just itching to write those drivers. If you believe that then you're living in a fantasy land.
On the flip side, it's becoming easier and easier to get involved, for those who are interested. XFree86's project management effectively prevented a community of graphics driver coders from forming in the same way that a community of kernel driver coders did. This was compounded by the fact that graphics chip specs have long been withheld, making it difficult for new people to get on board. Many people have asked over the years on the X.org devel list about how to help with driver development, and even though they've been pointed to some information by the community, there's been very little available for them to get going. This has been a serious problem. Luckily, the formation of X.org has solved the first problem, and now with Intel providing well documented drivers and ATI providing specs we should see people who want to learn have that ability to contribute.
Opening up the specs is, as has been said so many times before, no panacea, but Intel has benefited very noticeably by opening up their development process. They've gained a lot of goodwill and undoubtedly a lot of customers who just want the best Free drivers available. AMD stands to gain the same, which is something they simply can not get if they keep things closed. So there's a real tangible monetary benefit to opening up the process so that the community can contribute. The result of this is that people from several groups including AMD, SuSE, Redhat, and Tungsten Graphics will be working on the new driver (many of these people are the current ati driver maintainers, so they're seasoned and knowledgeable) so I wouldn't worry about manpower there.
Finally, it's very important to note that Intel itself doesn't maintain the driver that gets shipped in your distro, X.org does. Intel employs a lot of people to help maintain it, but they do their maintainance on X.org machines. So anyone who's a X.org developer (and you can become one the same way you can in other free software projects) can become an intel driver maintainer, even if they're not employed by Intel. So if you want to contribute to the driver and other components needed to make the composited linux desktop a reality, you can do so. Intel isn't stopping you, nor is anyone else.
RTFA. No one's bothered to really work on it because Intel already employs a fair number of developers to work on the driver out in the open. As a result, the majority of work on the driver is done by them. As Matthew says, anyone could do this if they wanted to, but the people who currently have the required skills at X.org and Intel are working on more pressing issues right now. X.org is still trying to recover from years of relatively closed development at XFree86, so there's groundwork to be covered (the current big one is a sane PCI backend) before worrying about finishing composite.
Slashdot Mirror
I personally hope he's just trolling. Especially if you're right and he has kids.
You've apparently missed all the heartfelt and often tearful thank-yous they get from parents with their kids in the hospital. I was in the room only a few yards away from the woman who broke down crying during PAX East thanking them for doing Child's Play because such things meant so much to her. It's on the episode of their reality show for PAX East that came out recently if you want to see it for yourself. Child's Play does make a real difference in people's lives and that shouldn't be discounted.
That rat heart story is exciting, but it's not organ printing. I'd urge caution about the heart experiment. It's cool that they pulled it off, but some of the caveats from the Nature Medicine paper reporting it are that it doesn't beat nearly as strongly as a normal heart, nor is it beating properly in time. No actual blood flow has been pushed through the thing, so we don't know if it can perform well enough to replace even diseased tissue in a person. Finally, if you think about doing this in a person, you'd need a donor heart. There's very few of these available, and the vast majority of them are from old people who probably don't have the best hearts available. And it's not at all clear yet that we could print an effective heart scaffold de novo and have it work as well, although it's a possibility. Proof of concept is still waiting.
So, at least in this really challenging case (replacing a blood vessel and a heart aren't even remotely on the same scale of complexity) it really does look like we're still decades away.
To be fair, as you well know X driver hackers (or X hackers in general) are few and far between, and so aren't the easiest group to hire. Pretty much everyone got snapped up by Intel and RH, so there's no one competent for Canonical to hire right now. That said, I'd like to see some serious X/mesa/whatever code come out of Canonical too.
It's still far too young to see any real successes. Prior to the past year, there wasn't any realistic way to make use of stem cells in many circumstances because of the paucity of cell lines available. Now there's more coming online. The real breakthrough though, Induced pluripotent Stem (iPS) cell technology, is brand new, and people have spent the last year making it safer by removing cMyc and whatever other oncogenes were necessary in the original formulation. That's basically done now and iPS cells should be less cancerous, so people are starting to move forward.
Remember that clinical trials take a very long time, so don't expect to see results so soon. Clinical trials for stem cell therapy are underway and from what little I've read they seem to be going well. You're right that the cancer problem still needs to be solved, and that it's never a good idea to believe wild predictions, things are looking vastly more positive for stem cell therapy than you make out.
Postscript (and by extension, PDF) doesn't reflow at all, which makes it a pain to use for different sized small screens like ebook readers.
If you think that the TA is a "an emotionally disturbed 12 year old" then you fail at reading comprehension. Bringing your own prejudices to the article is cute and all, but no one, especially not a teacher should be telling a kid who tried to commit suicide that he should "Carve deeper next time". If you don't trust the TA's word then that's your business, but if you want to side with a teacher who's encouraging an eighth grader to commit suicide then I think you're one sick fuck.
Have you actually been in the channel recently? #debian has gotten a lot more civil than it used to be. On either oftc or freenode, honest (and there tends to be a lot of trolling fake newbs) questions get answered. Some of the questions are answered with a very polite version of RTFM, usually with a link of some sort or a factoid stored in the bot (named dpkg), but honestly those tend to be better answers than painfully working through a problem. Most of the time, even the experts don't know the real answer to the question, but we know how to go about finding out. That's where the RTFM-style answers tend to come from, because it's exactly what we'd do if we were in their situation. Most help-seekers in #debian seem to understand this.
I've run Debian for close to a decade now, and I doubt that most Debian users think that the defaults are bad, so much as just not what they're used to. Most of us have our peculiar choices that we've made and like to stick with. If you want a full featured vim on your system rather than the stripped down default, you need to install the appropriate packages. If you want emacs, you have to install it. If you don't like xchat because you've been using irssi for years, you have to install it. If you have no need for OpenOffice, but desperately need a LaTeX installation, you need to add it. If you like awesome or some other tiling window manager instead of gnome, you just install it and go. Many people using Debian, especially those of us who've been using it for a very long time, have specific needs that aren't really appropriate for everyone. Debian's great strength has long been the ease of managing software installation and removal to craft the system that you need and want. Debian users just tend to leverage that strength.
Apparently you've not heard of Hadoop which is written in Java and, unlike Google's MapReduce, actually available to people outside of Google today.
Jython is actually getting that love right now. Right around the time Sun hired the JRuby guys they also hired two Jython guys. Jython has a new improved backend and is rapidly approaching a 2.5 release which will bring it up to speed with the current stable CPython. They're going to get to work on py3k compatibility after that. Hopefully they'll be able to achieve parity with CPython within a year or so, but they're definitely making very real progress.
Javascript is actually quite a compact language if you use it well. Looking at the scriptaculous code, it looks well written to me. The code in question implements a lot of features though, including drag and drop, sortable trees, and a whole lot of events to deal with the realities of the DOM, which is totally independent from javascript.
Your characterization of javascript is rather bizarre. It has encapsulation via closure and inheritance via prototypes. Closures in javascript are critical to actually using the language in a nice way if you listen to Doug Crockford, whereas rubyists tend to ignore them and just pass lambdas that don't depend on closure around. That said, no other language in that list relies on lambdas in the same way. Python has them, but they're notoriously limited. So I agree with the grandparent that Javascript and Ruby are relatively close languages, when compared to the others on that list. About the only thing I can imagine that's closer to Javascript is Scheme or Lisp.
Squeak is most definitely not GPL. It was under a special Apple Open Source license thingy for a while (maybe the APL itself, I don't know) and has now been relicensed under an MIT/X11 license. The squeak community is actually very hostile to the GPL, so you'll see most projects under MIT/X11.
I used to be a pretty serious gamer. Then I installed linux and slowly started spending more of my time doing that and less time gaming. I just found it a lot more fun to learn about how to use UNIX or messing around with the system than playing games. I like to say that linux became my game. Eventually I transitioned in to actually helping develop the system I used and that was pretty much the end of my serious gaming days.
Strangely enough, I've been getting back in to gaming little by little over the past few years, although not on PC's. The sorry state of the PC gaming market has been discussed elsewhere, so I won't add to that, but I've been using games as a way to spend time with my girlfriend, which is something I simply can't do with linux. So we play the PS2 and the Wii and we've just started looking at good old board and card games over the past few days. It's not just me either, many of my hardcore linux developer friends are buying wii's and such these days. I never thought I'd return to gaming, but it's worked out very well as a social tool for this penguin.
That would be Lego Mindstorms, not brainstorm.
(Argh, why did I not use preview? Sorry, posted again with formatting!)
It's not at all clear that we could gain anything by starting over, and in fact we'd probably lose quite a bit. Yes, there are old methods to do things, but they are being deprecated or replaced outright. XCB replacing Xlib is a particularly good example, as is the replacement of server-side fonts with client-side. Essentially these things aren't real issues any more, so they don't take up any real mental bandwidth when you need to work on X.
The drawing model and things that the UNIX Hater's Handbook talks about have been pretty well addressed over the last half decade. Cairo is the official replacement for the old drawing model that X provided, and Cairo works really well and is getting better all the time.
The problems you're talking about, like compositing well and having video work well with OpenGL, are not trivial problems, and they are often unsolved. We don't really know how to accelerate all sorts of rendering operations (glyph rendering is proving to be particularly difficult at the moment, for example) and for things like video in a composited opengl context it's highly unlikely that the code would get written any faster or cleaner if you were starting from scratch rather than reworking the existing codebase to make this necessarily complicated thing happen.
You're also ignoring many of the problems that X solves remarkably well. It's an incredibly modular design that allows for extensibility with simultaneous backwards compatibility. It actually does a very good job of managing windows. Finally, it does a ton of the dirty work like knowing how to read EDID blocks, parse a configuration file, or allow drivers to execute x86-mode BIOS calls on non-x86 hardware. All of this can be unpleasant code to write where you'd gain little or nothing by rewriting it.
So yeah, a cleaner design would be nice, but a vast amount of code has been fixed by deletion from the X server, to the point where the size of the server actually has gone down between some releases. So things are improving, and while it's slow, at least it's moving at a visible pace these days. Because of this, I'm really not convinced that starting over would get you more than the joy of reimplementing solutions to hard problems.
It's not at all clear that we could gain anything by starting over, and in fact we'd probably lose quite a bit. Yes, there are old methods to do things, but they are being deprecated or replaced outright. XCB replacing Xlib is a particularly good example, as is the replacement of server-side fonts with client-side. Essentially these things aren't real issues any more, so they don't take up any real mental bandwidth when you need to work on X. The drawing model and things that the UNIX Hater's Handbook talks about have been pretty well addressed over the last half decade. Cairo is the official replacement for the old drawing model that X provided, and Cairo works really well and is getting better all the time. The problems you're talking about, like compositing well and having video work well with OpenGL, are not trivial problems, and they are often unsolved. We don't really know how to accelerate all sorts of rendering operations (glyph rendering is proving to be particularly difficult at the moment, for example) and for things like video in a composited opengl context it's highly unlikely that the code would get written any faster or cleaner if you were starting from scratch rather than reworking the existing codebase to make this necessarily complicated thing happen. You're also ignoring many of the problems that X solves remarkably well. It's an incredibly modular design that allows for extensibility with simultaneous backwards compatibility. It actually does a very good job of managing windows. Finally, it does a ton of the dirty work like knowing how to read EDID blocks, parse a configuration file, or allow drivers to execute x86-mode BIOS calls on non-x86 hardware. All of this can be unpleasant code to write where you'd gain little or nothing by rewriting it. So yeah, a cleaner design would be nice, but a vast amount of code has been fixed by deletion from the X server, to the point where the size of the server actually has gone down between some releases. So things are improving, and while it's slow, at least it's moving at a visible pace these days. Because of this, I'm really not convinced that starting over would get you more than the joy of reimplementing solutions to hard problems.
Very little is required to be in xorg.conf these days, and that amount has been getting less and less over time. You no longer need a serverlayout section, for example, because it's now inferred from the remaining sections. If you have no video card section one is automatically figured out for you. These are all relatively recent (last year or so) developments, but they do exist in the source tree today.
Jim is one of the original authors of X. Keith is essentially the de facto overlord of the current X.org, although he doesn't play dictator except in rare cases.
As for rendering bottlenecks, they are many and varied and none of them have to do with the network transparency issue. When local clients talk to a local server they do so via local sockets or shared memory, both of which are very fast and impose minimal or no penalties.
What accounts for bottlenecks are things like the inability to do compositing, leading to tearing of windows when they're being dragged. This is fixed by the composite extension and a fast compositing manager, like the one found in compiz.
Another issue is that the old driver architecture (XAA) was geared towards old-style drawings. These days we don't really look at stipple patterns much, so the new driver architecture (EXA) is geared towards solid fills and fast blits for bitmaps instead, which is what you end up doing on a modern desktop anyway. It turns out though that this is very hard to get right and the bugs are still being worked out. I don't think that this is really an issue with X being old so much as that this is just a damned hard problem to get right. It is being worked on (check out Carl Worth's blog for some examples on this particular front) so hopefully things will improve.
Finally, there's the constant bottleneck due to incomplete or inadequate drivers. The new radeonhd, for example, only recently gained 2d acceleration support, and still lacks any sort of 3d accel. This sort of problem prevents X from adequately taking advantage of all the hardware has to offer, so performance can suffer. As a result, you lose the ability to run things like compiz, which address these issues.
Finally, I haven't watched it yet, but I recommend you take a look at Keith Packard's google talk on remaking X. X has been largely rebuilt from the inside over the past several years, and things like Render, RandR, Composite, Damage, Fixes, Input Hotplug, and EXA have really sprung from that initiative. It's wort
Then why doesn't the Ubuntu community set themselves up on a totally free infrastructure? Every other major distro has one these days.
For now, yes it is, but once Steve Jobs is gone the path will clear. Be it in ten or twenty years, once Jobs is gone Apple will once again lose its way and Linux will be able to continue onward and upward just as it always has. Some of us actually remember what Apple was like without Jobs at the helm. As it is, this just gives us more time to get Linux on the desktop polished and really ready.
You can script vim with several languages, including perl, python, and ruby. Not many scripts are written using them, but they are available provided that your vim build does enable those options.
I hope you're not trolling here. X.org has very few contributors as a whole. Maybe 20 or so, with about half who do real work on the graphics drivers. That's really not very many for such a large amount of code. So no, I'm sorry to break it to you, but there's no armies of experienced graphics driver coders just itching to write those drivers. If you believe that then you're living in a fantasy land.
On the flip side, it's becoming easier and easier to get involved, for those who are interested. XFree86's project management effectively prevented a community of graphics driver coders from forming in the same way that a community of kernel driver coders did. This was compounded by the fact that graphics chip specs have long been withheld, making it difficult for new people to get on board. Many people have asked over the years on the X.org devel list about how to help with driver development, and even though they've been pointed to some information by the community, there's been very little available for them to get going. This has been a serious problem. Luckily, the formation of X.org has solved the first problem, and now with Intel providing well documented drivers and ATI providing specs we should see people who want to learn have that ability to contribute.
Opening up the specs is, as has been said so many times before, no panacea, but Intel has benefited very noticeably by opening up their development process. They've gained a lot of goodwill and undoubtedly a lot of customers who just want the best Free drivers available. AMD stands to gain the same, which is something they simply can not get if they keep things closed. So there's a real tangible monetary benefit to opening up the process so that the community can contribute. The result of this is that people from several groups including AMD, SuSE, Redhat, and Tungsten Graphics will be working on the new driver (many of these people are the current ati driver maintainers, so they're seasoned and knowledgeable) so I wouldn't worry about manpower there.
Finally, it's very important to note that Intel itself doesn't maintain the driver that gets shipped in your distro, X.org does. Intel employs a lot of people to help maintain it, but they do their maintainance on X.org machines. So anyone who's a X.org developer (and you can become one the same way you can in other free software projects) can become an intel driver maintainer, even if they're not employed by Intel. So if you want to contribute to the driver and other components needed to make the composited linux desktop a reality, you can do so. Intel isn't stopping you, nor is anyone else.
RTFA. No one's bothered to really work on it because Intel already employs a fair number of developers to work on the driver out in the open. As a result, the majority of work on the driver is done by them. As Matthew says, anyone could do this if they wanted to, but the people who currently have the required skills at X.org and Intel are working on more pressing issues right now. X.org is still trying to recover from years of relatively closed development at XFree86, so there's groundwork to be covered (the current big one is a sane PCI backend) before worrying about finishing composite.