Building in an environment with little legacy infrastructure can provide excellent oppportunities for deploying new technologies. Are you considering suggesting Linux for voice services (e.g. for example, my own project, Asterisk) as well as data?
If you want to use paypal for donating to the gaim defense fund, use "paypal@linux-support.net" as the recipient. All funds donated here will go to the defense, and anything left over if we are unable to pursue the defense will be refunded as much as possible with the paypal system.
People have asked which lawyer it is that we have found to do the letter, and it is Russel Balch of Akridge & Balch who has some experience dealing with legal issues related Free Software.
Remember that static linking glibc into a commercial application violates the LGPL. The LGPL only allows dynamic linking without forcing you into LGPL/GPL.
I have been developing the Asterisk Open Source PBX. Right now its channel support is somewhat limited, but the first release should be coming out either later this year or early next year at the latest, and it can already be accessed via CVS (anonymous coming shortly). Feel free to join the Asterisk mailing list (directions available at the web site) if you'd like to talk about what kinds of VoIP you'd like to bring into it.
I've noticed there are large file patches available for Linux (here for example), and glibc 2.1 (as included with RH 6.0) has userspace support for the LFS calls. When (if ever) can we expect to see such support in the standard Linux kernels?
Look here for my study on Linux vs NT performance with TCP. NT's stack is indeed inefficient, but the performance may also be related to really lousy interrupt handling as well.
Of course, I tried to post this to/. a few times and it didn't make it. Oh well. Maybe people will find it appropriate to this thread.
I have an essay overdue on proof by contradiction, but let me try to apply it here...
It is clearly true that an expensive system with bloat, high defect density, and a remarkable snobishness towards customer feedback has indeed become quite mainstream, particularly in the operating system market, so this argument is fairly weak from the beginning.
Now, it is not really clear whether Linux will or will not suffer from the kinds of bloat and creeping featuritis that he describes. Speaking of the kernel itself, its creation still lies with one person who reads and re-reads every single patch which is applied to be sure everything is done correctly. This is a distinguishing characteristic of Linux kernel which almost certainly contributes greatly to the tightness of its code, particularly given its large featureset.
As for maintainance, the problem is clearly alot easier with open source software. One has the same recourses as before (complain to the author/vendor) with the added benefit that they can complain to any arbitrary third party and get them to fix the problem, then submit a patch to have it fixed generally if they so choose.
Basically, the trouble with his argument is that it is entirely speculation, without any evidence to support it. It is logical to think that free software could not possibly work conceptually, particularly with proprietary software being so much more profitable, but it is also demonstrable that this is not the case.
In general, it is free software's more efficient nature (compare RedHat's employee count and market penetration to Sun's employee count and market penetration) that will make it work, most likely.
Slashdot Mirror
Building in an environment with little legacy infrastructure can provide excellent oppportunities for deploying new technologies. Are you considering suggesting Linux for voice services (e.g. for example, my own project, Asterisk) as well as data?
If you want to use paypal for donating to the gaim defense fund, use "paypal@linux-support.net" as the recipient. All funds donated here will go to the defense, and anything left over if we are unable to pursue the defense will be refunded as much as possible with the paypal system.
People have asked which lawyer it is that we have found to do the letter, and it is Russel Balch of Akridge & Balch who has some experience dealing with legal issues related Free Software.
Remember that static linking glibc into a commercial application violates the LGPL. The LGPL only allows dynamic linking without forcing you into LGPL/GPL.
I have been developing the Asterisk Open Source PBX. Right now its channel support is somewhat limited, but the first release should be coming out either later this year or early next year at the latest, and it can already be accessed via CVS (anonymous coming shortly). Feel free to join the Asterisk mailing list (directions available at the web site) if you'd like to talk about what kinds of VoIP you'd like to bring into it.
I've noticed there are large file patches available for Linux (here for example), and glibc 2.1 (as included with RH 6.0) has userspace support for the LFS calls. When (if ever) can we expect to see such support in the standard Linux kernels?
Of course, I tried to post this to /. a few times and it didn't make it. Oh well. Maybe people will find it appropriate to this thread.
Excellent work. I was suspicious of what kind of a rebuttal there was going to be, but this was remarkably well done and well thought out.
It is clearly true that an expensive system with bloat, high defect density, and a remarkable snobishness towards customer feedback has indeed become quite mainstream, particularly in the operating system market, so this argument is fairly weak from the beginning.
Now, it is not really clear whether Linux will or will not suffer from the kinds of bloat and creeping featuritis that he describes. Speaking of the kernel itself, its creation still lies with one person who reads and re-reads every single patch which is applied to be sure everything is done correctly. This is a distinguishing characteristic of Linux kernel which almost certainly contributes greatly to the tightness of its code, particularly given its large featureset.
As for maintainance, the problem is clearly alot easier with open source software. One has the same recourses as before (complain to the author/vendor) with the added benefit that they can complain to any arbitrary third party and get them to fix the problem, then submit a patch to have it fixed generally if they so choose.
Basically, the trouble with his argument is that it is entirely speculation, without any evidence to support it. It is logical to think that free software could not possibly work conceptually, particularly with proprietary software being so much more profitable, but it is also demonstrable that this is not the case.
In general, it is free software's more efficient nature (compare RedHat's employee count and market penetration to Sun's employee count and market penetration) that will make it work, most likely.