If you were serious about wanting to be the UI designer for a FOSS project, please check out http://explicans.wikidot.com/ and maybe email me or post a message to the mailing list. This project needs a lead designer.
Of course I'm biased, but IMHO this project has the potential to be big and the UI design of it is really interesting.
This isn't pitched as a heavy-duty corporate solution, but SyncML is supported my most phones today. It is an open protocol that lets you sync addressbook information, notes, bookmarks, etc. with a server (and open source servers like funambol already exist). There are also sites like Mobical which offer free SyncML hosting.
Basically, here's how it works: You set your phone up to sync automatically with the SyncML server every couple days. Then whenever you add, say, a contact, it gets uploaded to the server. If you lose your phone or just upgrade, you point your new phone at the server and sync to recover your contacts. The protocol only sends updates, so it is relatively quick and bandwidth friendly. The sync is bidirectional, so you can also add contacts to your phone from your web browser (if your syncml server has a web interface).
Backing up using SIM cards is pretty inconvenient by comparison. You have to manually swap out the SIM whenever you backup, and the SIM protocol is very basic (it can only hold one number per name I believe).
I'm not aware of the Taiwanese incident you mention, but for Korea are you talking about the Gwangju_Massacre? I think different attitudes to this and the Tiananmen Square protests are mostly caused by the fact that South Korea has apologized for the Gwangju Massacre and president Chun Doo-hwan, who most consider responsible, was sentenced to death. (He wasn't actually executed though.)
If China apologized to the students at Tiananmen Square and sentenced Li Peng (China's prime minister at the time) to death, I think Americans would feel much differently about the Chinese government. So I don't think there's some big conspiracy here.
But you are right that the US supported a lot of immoral policies in other countries, many of which weren't necessary (or even helpful) for winning the cold war.
About China's ascendancy, I think you overestimate the ability for the US to "run everything". In fact, one could look at America's current foreign policy and doubt they could run anything! China's foreign policy is generally unhelpful at the moment and I don't see why the world would be better off with a more militarily and politically assertive China.
Corporate mergers, buyouts, and bancrupties are part of natrual selection. Consumers migrating to one company's offering can lead to 'natural selection'. One company having a big bank roll and buying out weaker competitors is also a form of selection.
One company buying out a weaker competitor and destroying their product isn't natural selection, and doesn't lead to an increase in adaptation. The environment isn't "selecting" for any trait---it just so happens that the first company on the scene has more money/patents and wins. If the timing was reversed the other company would win. I think a biologist would call this random drift:)
Red Hat is a company of course, and concerned with making money, but I like Szulik's comments. It's nice to see a CEO that believes (for whatever reason) that having a lot of specialized Linux distros is a good thing.
Perhaps in the future Evince will be the best thing ever, but I'm not sure why it's getting so much hype. At the moment it just seems to be a prettier ghostview.
The true purpose of schooling, according to Gatto, is to produce an easily manageable workforce to serve employers in a mass-production economy. Actual education is a secondary and even counterproductive result since educated people tend to be more difficult to control.
I'm currently teaching now (college level) and my parents were both public school teachers (elementary and high school level) all in the US. So I'm so glad I found out that our true purpose all this time wasn't to educate people! Congrats on enlightening us!
But seriously, large organizations have no single "true" purpose which determines their effect, but are composed of tens of thousands of people, who each have different goals. Much more important is what the people actually doing the work (all the teachers and principles, who actually interact with the children) are trying to do, what their purpose is. It's laughable that we are against "actual education".
Of course certain structural reforms could improve education. But to say that the true purpose of the American educational system is against education is silly.
The very concept may be a joke, but I'm referring to this line from the application:
[0043] Moreover, although the foregoing exemplary embodiments relate to the provision of graduated translucency in the direction of from opaque to translucent, those skilled in the art will appreciate that the graduated change in visual output can also be applied from translucent to opaque.
Or does someone at Apple really think that only someone "skilled in the art" would realize that if opaque->transparent is possible then so is transparent->opaque.
I guess before that insight all the windows gradually faded away and disappeared.
It may be useful to distinguish two ways in which Fedora was supposed to be different from the previous series.
Fedora was supposed to strike a different compromise between being stable and being up-to-date. It should come out frequently, try new and exciting features, and have the latest versions of everything.
The community was supposed to have more of a say in the overall direction. With RH Linux, the company decided which packages would be included in the main distribution and what the defaults would be. With Fedora US (and thus presumably RH Fedora) the users submit and check packages and decide overall direction.
RH Fedora is a success with respect to #1, but has failed at #2. I run RH Fedora and it seems to be a reasonable stable and up-to-date distro, and tries out features like SELinux. As other people have pointed out, FC2 is on target and should be released soon.
But as far as #2 goes it is a failure. There has been no integration with Fedora.us and, as the dialogue shows, RH still decides on all the packages and defaults in a relatively closed way.
Some people have asked why RH, being a for-profit company, could open up development. There seems to be an obvious answer: so the community could help it more. RedHat could still exercise a high degree of control as long as it contributed heavily to the new community project. That's why many people were excited at the new structure---it implied that RH was still committed to develop the distribution, but would make sure that the community was heavily involved as well. Otherwise it wouldn't be worth their effort to "open it up."
Monads are like continuations, if you've ever programmed in that style with C.
Functions are passed their usual arguments, plus an extra parameter which is the thing that should be called after this function has done its work. This function parameter can have a lot of extra stuff inside it which represents the 'state' of the system.
You are mistaken, or at least explaining things in a confusing way. Contiuation passing style and monads aren't related. In Haskell you can using monads without using continuations or vice-versa.
Monads exploit the type system, not an extra argument. For instance the Haskell function putStr has type String -> IO (). There is no need to pass any extra parameter; you just pass it a string, and it prints it, returning a null value. Another way to do IO is to have a special "world" object that functions pass between each other (is this what you're describing?) but there are obvious drawbacks to this. For instance, what if a function modified the world object, and then passed back both the new and old versions?? Then your program would have to duplicate the world...
Thus, there's a MASSIVE performance loss when a functional programming language is executed on any of the existing processors. Because the compilers can't think and optimise the code to best fit the imperative model. Where as the human being s can. That's why we should stick to imperative programming languages.
You are exaggerating the performance penalty. See for instance the old version of The Great Computer Language Shootout where Haskell is ranked faster than Java. Of course those benchmarks don't tell the whole story and should be taken with a grain of salt. In my experience though, Haskell is only about 4 times slower than C, compared to, for instance, Python, which is about 20 times slower (I am a big python fan, so this isn't a criticism of Python).
Just as plenty of people are willing to put up with Python's slowness in exchange for better debugging, faster development, dynamic typing, etc., I think plenty of people would benefit by moving from C to Haskell, which is purely functional, has a great type inferencing system, never seg faults, etc.
One final note is that Haskell programs can often be optimized in Haskell itself and approach C speeds. This is because Haskell is compiled and statically typed and can deal with unboxed elements and so forth. This is a big difference from Python and other dynamically typed languages where optimization sometimes must be done in C for best results.
way back when in college, the most interesting thing was that the program couldn't do I/O during the execution, only as an exit value. That makes useful daily programs difficult to write in a 'purely functional' language. The review talks about monads being a solution, but I can't see that putting something on the screen our worse a printer is something that can be undone. Therefore, I/O must be a side-effect, so how can a real 'purely functional' language like haskel do I/O?
Good question. There have been a variety of different alternatives proposed. For instance, some earlier functional languages took the entire program being a single function from the input (conceived of as a linked list) to the output (another linked list). However, since linked lists can be lazily generated in pure functional programming languages, this model does not imply that all the output must happen before all the input. The program would read the input and generate the output as it went along.
But the monad model is considered more flexible. Basically IO monads are just a way to use the type system to force a strict division between thinking (which is purely functional) and acting (which is imperative).
For instance, in C, it is possible that getchar() != getchar(). They can be compared because they are both ints. This is obviously non-functional (remember the definition of a function?). In Haskell, though, getChar isn't a function to ints, is a function to int monads (type IO Char). And you can't compare IO Chars, so getChar == getChar raises a type error. Voila, no functional violations. Similarly, any result which has a side effect or reads from the environment ends up with type IO.
Who is the target audience for this book? I would assume programmers, of at least moderate experience.
Actually, the book is targeted mainly at novices (although experienced programmers who have never seen Haskell will also learn). In fact, the author even mentions high school students. This is from the preface (page xvi):
All the material in this textbook can be covered in one semester as an advanced undergraduate course. For lower-level courses, including possible use in high school, some mathematics may cause problems, but for bright students I suspect most of the material can still be covered.
So obviously an intimate knowledge of red-black trees is not required.
The foreign language interface manual. Since Haskell has a small library you will probably need to call functions written in C a lot to get anything done. Luckily, Haskell's foreign function interface is quite nice.
I've read this book and think this is a good book for learning Haskell (perhaps the best one) and that it explains monads well.
However, it won't get the reader fully up and running as a productive Haskell programmer, because for that it is basically required that you master the GHC's (Glorious/Glasgow Haskell Compiler) standard library. Otherwise you won't know how to use a fast unboxed array, etc. This library is actually intelligently designed, but it is poorly documented, and there are lots of quirks for people who aren't totally familiar with Haskell yet. The best way to learn still seems to be to read the Haskell newsgroup and look at other people's code.
But Haskell is an extremely interesting language and well worth learning IMHO.
The only thing China risks is reproachful looks at the UN for a while, then after everybody there is done looking really shocked, Taiwan will be history. Proof is, if the rest of the world had any kind of power against China's actions, Tibet would have been freed a long time ago.
Tibet and Taiwan aren't quite analogous. Here are a few differences:
China already controls Tibet. It is easier to keep a country from annexing than to "liberate" some existing portion of it.
Tibet is inaccessible, Taiwan is easily reached by the American navy.
The US has formalized their relation to Taiwan in the Taiwan Relations Act (1979?) which doesn't promise that the US will protect Taiwan, but comes close in diplomacy-speak.
Taiwan is much more important to the US culturally and especially economically than Tibet.
China is now seen by many as the country posing the biggest long term threat to the US. During the cold war the US has shown significant ability to keep long term threats from invading at will.
I don't know about the rest of you, but the fact that i've been a contributor to Red Hat's distrib since May of 1998 was not only something I was personally proud of, it was something I put on my resume'. I have to remove that line now, because it's now impossible for me (or any of you) to directly contribute code to Red Hat Linux.
I don't understand. It was always hard (at least since 6.x) to contribute to the Red Hat distributions directly. As far as the community was concerned, there would be some secretive decision on what software to include in Red Hat and what not to, and then the community could only complain about it afterwards. The most a developer could do to get his/her project into Red Hat was to upload an rpm to bero.redhat.com, which was about as effective as sending it to/dev/null.
That's why I was happy with their decision to merge with the Fedora project, which I had already been packaging for. Hopefully in the future developers can contribute to Red Hat Fedora in a way they never could with Red Hat x.x.
Quote from Diamond Age
on
Quicksilver
·
· Score: 1
Although I probably liked Snow Crash better myself, I enjoyed Diamond Age also. What makes Stephenson so good isn't his novel's plot, I think, but all the interesting passages sprinkled throughout. Here's a discussion I liked from Diamond Age:
"Because they were hypocrites," Finkle McGraw said, "the Victorians were despised in the late twentieth century. Many of the persons who held such opinions were, of course, guilty of the most nefandous conduct themselves, and yet saw no paradox in holding such views because they were now hypocrites themselves---they took no moral stances and lived by none."
"So they were morally superior to the Victorians---" Major Napier said, still a bit snowed under.
"---even though---in fact, because---they had no morals at all."
An insightful passage I think, very relevant today. Anyway, this kind of stuff is characteristic of Stephenson's writing, so I think the books can be forgiven if they don't have good endings.
This contest concerned virtual racing tracks. The winner was the one who submitted the trace which would pilot the car as fast as possible around the track. (See the problem description for more information.)
Thus the judges never ran the program on their computers, and in theory could have judged the contest without even looking at source code. To me this seems a bit unfair because the winner could just be the one with the fastest computer, not the best code. I noticed that the first prize team used 16 dual Xeons.
So did anyone here compete? In practice are the results greatly influenced by how much hardware the contestants had access to?
It is a bit of a surprise that C++ won, because in previous years the winners were usually using Ocaml or Haskell (two "modern" functional languages with an advanced type system).
In previous years, the majority of the entries were not C or C++. See for instance the 2002 entry list. In fact the entry list is interesting in itself to see all the languages people use.
And it's true that there are more C++ programmers, but many of the smart ones probably experiment with other languages. On the other hand no one is programming Haskell now because that's the only thing they learned in school and they want a job somewhere.
Yes, previous years have featured Python and Ruby contestants. I believe one year Python won the judge's award, but IIRC neither language has come in first or second.
I think the problem with Python and Ruby are that they are both about 10+ times slower than Ocaml/C++ (to name two lanuages that often do well in the contest) and often running time is heavily weighted in the scoring.
Exactly. Everyone is dumping on the Free Software Foundation for no reason again. The FSF says that the APSL is a free software license (a high form of praise indeed coming from the FSF), but that it is somewhat unfair to users, mainly because it gives Apple rights that other users don't. Thus it recommends that the licensed not be used for new products.
This seems entirely reasonable to me. FSF is telling people not to use the APSL because they will be giving some of their rights to Apple. Duh! No one would do this anyway.
Slashdot: say something obvious and get flamed for it.
Re:Conundrum with open source?
on
SCO SCO SCO!
·
· Score: 1
Actually the quote is from Mark F. Radcliffe, a columnist, not a SCO person. He seems very skeptical of SCO's claims, and not necessarly anti-FOSS.
But you and others make a good point, in that it is harder to get away with with cheating in FOSS, and there are fewer economic incentives to do so. These two factors should make cheating less common with open source software.
However, there is one point pushing in the other direction: In free software projects, people do not have economic dis-incentives to cheat either. A proprietary programmer might (in theory) be fired for copyright infringment. But FOSS projects often accept contributions from people with "nothing to lose"---if they get caught then they remain anonymous, but if they succeed then they may get prestige, thanks, etc. As one poster above said, you should only accept contributions from people you trust. Software companies may not trust their employees per se, but they usually have more of a relationship with them than FOSS project leaders have with the average contributor.
But I don't see any reason to think this last reason outweighs the previous two, and agree that cheating does not seem to be an issue with free software in particular.
Conundrum with open source?
on
SCO SCO SCO!
·
· Score: 5, Interesting
The article, although rightfully skeptical about SCO's claims, appears to make a good point about a problem with open source:
since the programs have many contributors, it is difficult to be sure that the final product does not include unauthorized proprietary code. It only takes one sloppy contributor or someone who is sceptical about intellectual property to make problems for everyone. Pragmatically, the same thing can happen in a proprietary product, but the customer has someone to hold responsible in that situation (the developer of the product) so the economic incentives discourage such illegal contributions. The challenge for LINUX is that with multiple contributors and distributors, how do you set up similar economic incentives for contributors to ensure that they only add code that they have the right to add? That conundrum remains.
However, it seems to me that the incentives are totally analogous. Programmers in the open source world code (mainly) to help others, or show off their skills (for prestige or a better job). If they are caught cheating then they obviously are not helping, and plus they lose a lot prestige.
Similarly, the people who manage open source projects clearly want their project to be successful and popular. If they accept infringing contributions then they jeopardise this, so they have an incentive not to. There may not be a direct economic incentive, but that doesn't mean the incentive isn't just as strong. The only conundrum is the familiar one that, in the free software world, people do things for reasons other than money.
As far as I can tell, the only practical impact of this is a slap in the face to the HURD developers, who have just been bypassed by yet *another* kernel project...
This project isn't a competitor to the hurd. The HURD is a bunch of services that need a microkernel to run on top of. So if anything, HURD developers should be happy, because they now have the option of porting their kernel from Mach to the theoretically speedier L4.
One interesting argument mentioned in the article is from Ned Block. As a counterexample to the thesis that the turing test is a good test for intelligence, Block imagines a device which is just a huge table connecting inputs to preprogrammed outputs. This "blockhead" (not named by Ned Block I think) would clearly not be intelligent, as it is just a very simple database, but if the outputs were correctly set up it could pass the Turing test with flying colors. Thus passing any Turing-like test does not necessarily imply intelligence---we'd have to know something more about the structure of the machine first.
Slashdot Mirror
If you were serious about wanting to be the UI designer for a FOSS project, please check out http://explicans.wikidot.com/ and maybe email me or post a message to the mailing list. This project needs a lead designer.
Of course I'm biased, but IMHO this project has the potential to be big and the UI design of it is really interesting.
This isn't pitched as a heavy-duty corporate solution, but SyncML is supported my most phones today. It is an open protocol that lets you sync addressbook information, notes, bookmarks, etc. with a server (and open source servers like funambol already exist). There are also sites like Mobical which offer free SyncML hosting.
Basically, here's how it works: You set your phone up to sync automatically with the SyncML server every couple days. Then whenever you add, say, a contact, it gets uploaded to the server. If you lose your phone or just upgrade, you point your new phone at the server and sync to recover your contacts. The protocol only sends updates, so it is relatively quick and bandwidth friendly. The sync is bidirectional, so you can also add contacts to your phone from your web browser (if your syncml server has a web interface).
Backing up using SIM cards is pretty inconvenient by comparison. You have to manually swap out the SIM whenever you backup, and the SIM protocol is very basic (it can only hold one number per name I believe).
I'm not aware of the Taiwanese incident you mention, but for Korea are you talking about the Gwangju_Massacre? I think different attitudes to this and the Tiananmen Square protests are mostly caused by the fact that South Korea has apologized for the Gwangju Massacre and president Chun Doo-hwan, who most consider responsible, was sentenced to death. (He wasn't actually executed though.)
If China apologized to the students at Tiananmen Square and sentenced Li Peng (China's prime minister at the time) to death, I think Americans would feel much differently about the Chinese government. So I don't think there's some big conspiracy here.
But you are right that the US supported a lot of immoral policies in other countries, many of which weren't necessary (or even helpful) for winning the cold war.
About China's ascendancy, I think you overestimate the ability for the US to "run everything". In fact, one could look at America's current foreign policy and doubt they could run anything! China's foreign policy is generally unhelpful at the moment and I don't see why the world would be better off with a more militarily and politically assertive China.
Red Hat is a company of course, and concerned with making money, but I like Szulik's comments. It's nice to see a CEO that believes (for whatever reason) that having a lot of specialized Linux distros is a good thing.
I think Evince has been over-hyped. For instance, the Fedora Core 4 release notes says that Evince supports pdf, ps, "and many others". In fact pdf and ps are the only 2 formats Evince fully supports. The Fedora 4 version of Evince doesn't even display dvi files.
Perhaps in the future Evince will be the best thing ever, but I'm not sure why it's getting so much hype. At the moment it just seems to be a prettier ghostview.
But seriously, large organizations have no single "true" purpose which determines their effect, but are composed of tens of thousands of people, who each have different goals. Much more important is what the people actually doing the work (all the teachers and principles, who actually interact with the children) are trying to do, what their purpose is. It's laughable that we are against "actual education".
Of course certain structural reforms could improve education. But to say that the true purpose of the American educational system is against education is silly.
I guess before that insight all the windows gradually faded away and disappeared.
RH Fedora is a success with respect to #1, but has failed at #2. I run RH Fedora and it seems to be a reasonable stable and up-to-date distro, and tries out features like SELinux. As other people have pointed out, FC2 is on target and should be released soon.
But as far as #2 goes it is a failure. There has been no integration with Fedora.us and, as the dialogue shows, RH still decides on all the packages and defaults in a relatively closed way.
Some people have asked why RH, being a for-profit company, could open up development. There seems to be an obvious answer: so the community could help it more. RedHat could still exercise a high degree of control as long as it contributed heavily to the new community project. That's why many people were excited at the new structure---it implied that RH was still committed to develop the distribution, but would make sure that the community was heavily involved as well. Otherwise it wouldn't be worth their effort to "open it up."
Monads exploit the type system, not an extra argument. For instance the Haskell function putStr has type String -> IO (). There is no need to pass any extra parameter; you just pass it a string, and it prints it, returning a null value. Another way to do IO is to have a special "world" object that functions pass between each other (is this what you're describing?) but there are obvious drawbacks to this. For instance, what if a function modified the world object, and then passed back both the new and old versions?? Then your program would have to duplicate the world...
Just as plenty of people are willing to put up with Python's slowness in exchange for better debugging, faster development, dynamic typing, etc., I think plenty of people would benefit by moving from C to Haskell, which is purely functional, has a great type inferencing system, never seg faults, etc.
One final note is that Haskell programs can often be optimized in Haskell itself and approach C speeds. This is because Haskell is compiled and statically typed and can deal with unboxed elements and so forth. This is a big difference from Python and other dynamically typed languages where optimization sometimes must be done in C for best results.
But the monad model is considered more flexible. Basically IO monads are just a way to use the type system to force a strict division between thinking (which is purely functional) and acting (which is imperative).
For instance, in C, it is possible that getchar() != getchar(). They can be compared because they are both ints. This is obviously non-functional (remember the definition of a function?). In Haskell, though, getChar isn't a function to ints, is a function to int monads (type IO Char). And you can't compare IO Chars, so getChar == getChar raises a type error. Voila, no functional violations. Similarly, any result which has a side effect or reads from the environment ends up with type IO.
I've read this book and think this is a good book for learning Haskell (perhaps the best one) and that it explains monads well.
However, it won't get the reader fully up and running as a productive Haskell programmer, because for that it is basically required that you master the GHC's (Glorious/Glasgow Haskell Compiler) standard library. Otherwise you won't know how to use a fast unboxed array, etc. This library is actually intelligently designed, but it is poorly documented, and there are lots of quirks for people who aren't totally familiar with Haskell yet. The best way to learn still seems to be to read the Haskell newsgroup and look at other people's code.
But Haskell is an extremely interesting language and well worth learning IMHO.
That's why I was happy with their decision to merge with the Fedora project, which I had already been packaging for. Hopefully in the future developers can contribute to Red Hat Fedora in a way they never could with Red Hat x.x.
An insightful passage I think, very relevant today. Anyway, this kind of stuff is characteristic of Stephenson's writing, so I think the books can be forgiven if they don't have good endings.
This contest concerned virtual racing tracks. The winner was the one who submitted the trace which would pilot the car as fast as possible around the track. (See the problem description for more information.)
Thus the judges never ran the program on their computers, and in theory could have judged the contest without even looking at source code. To me this seems a bit unfair because the winner could just be the one with the fastest computer, not the best code. I noticed that the first prize team used 16 dual Xeons.
So did anyone here compete? In practice are the results greatly influenced by how much hardware the contestants had access to?
It is a bit of a surprise that C++ won, because in previous years the winners were usually using Ocaml or Haskell (two "modern" functional languages with an advanced type system).
In previous years, the majority of the entries were not C or C++. See for instance the 2002 entry list. In fact the entry list is interesting in itself to see all the languages people use.
And it's true that there are more C++ programmers, but many of the smart ones probably experiment with other languages. On the other hand no one is programming Haskell now because that's the only thing they learned in school and they want a job somewhere.
Yes, previous years have featured Python and Ruby contestants. I believe one year Python won the judge's award, but IIRC neither language has come in first or second.
I think the problem with Python and Ruby are that they are both about 10+ times slower than Ocaml/C++ (to name two lanuages that often do well in the contest) and often running time is heavily weighted in the scoring.
Exactly. Everyone is dumping on the Free Software Foundation for no reason again. The FSF says that the APSL is a free software license (a high form of praise indeed coming from the FSF), but that it is somewhat unfair to users, mainly because it gives Apple rights that other users don't. Thus it recommends that the licensed not be used for new products.
This seems entirely reasonable to me. FSF is telling people not to use the APSL because they will be giving some of their rights to Apple. Duh! No one would do this anyway.
Slashdot: say something obvious and get flamed for it.
Actually the quote is from Mark F. Radcliffe, a columnist, not a SCO person. He seems very skeptical of SCO's claims, and not necessarly anti-FOSS.
But you and others make a good point, in that it is harder to get away with with cheating in FOSS, and there are fewer economic incentives to do so. These two factors should make cheating less common with open source software.
However, there is one point pushing in the other direction: In free software projects, people do not have economic dis-incentives to cheat either. A proprietary programmer might (in theory) be fired for copyright infringment. But FOSS projects often accept contributions from people with "nothing to lose"---if they get caught then they remain anonymous, but if they succeed then they may get prestige, thanks, etc. As one poster above said, you should only accept contributions from people you trust. Software companies may not trust their employees per se, but they usually have more of a relationship with them than FOSS project leaders have with the average contributor.
But I don't see any reason to think this last reason outweighs the previous two, and agree that cheating does not seem to be an issue with free software in particular.
However, it seems to me that the incentives are totally analogous. Programmers in the open source world code (mainly) to help others, or show off their skills (for prestige or a better job). If they are caught cheating then they obviously are not helping, and plus they lose a lot prestige.
Similarly, the people who manage open source projects clearly want their project to be successful and popular. If they accept infringing contributions then they jeopardise this, so they have an incentive not to. There may not be a direct economic incentive, but that doesn't mean the incentive isn't just as strong. The only conundrum is the familiar one that, in the free software world, people do things for reasons other than money.
As far as I can tell, the only practical impact of this is a slap in the face to the HURD developers, who have just been bypassed by yet *another* kernel project...
This project isn't a competitor to the hurd. The HURD is a bunch of services that need a microkernel to run on top of. So if anything, HURD developers should be happy, because they now have the option of porting their kernel from Mach to the theoretically speedier L4.
One interesting argument mentioned in the article is from Ned Block. As a counterexample to the thesis that the turing test is a good test for intelligence, Block imagines a device which is just a huge table connecting inputs to preprogrammed outputs. This "blockhead" (not named by Ned Block I think) would clearly not be intelligent, as it is just a very simple database, but if the outputs were correctly set up it could pass the Turing test with flying colors. Thus passing any Turing-like test does not necessarily imply intelligence---we'd have to know something more about the structure of the machine first.