I question not so much the free software crowd's love of Mozilla, as the hate for KHTML. Why hate this _other_ free and excellent library for web rendering?
Apple made a perfectly valid choice, and contributed their changes back to the free software community. Yet another great free software project now benefits from Apple, at IE/Microsoft's expense of market share on Mac desktops.
Don't draw any conclusions you don't have to. I love Mozilla, too, but Apple made a decision, and one which even most Mozilla developers feel was a valid technical choice, even if it wasn't the one they themselves would have made.
(1) The ATA/100 would still gain you the larger address space, allowing larger capacities. Since 160GB drives are here (and a scant us$250 to boot), this is quite important.
(2) I agree that the faster bus in theory won't get you more performance with a _single_ drive. But the fact is, that benchmarks say otherwise. For whatever reason, the faster burst speed of the bus has slightly improved the overall speed. I'm not a particularly good hardware engineer, but when I run `hdparm` on a couple of drives, I like the faster speed regardless of reason... (I still hate IDE and would much prefer SCSI, but I can't get a 160GB SCSI drive for $250.)
(3) ATA/100 controllers are dirt cheap. I can't believe that the extra few bucks wouldn't be worth it in marketing value alone.
Correct. AFAIK (and I think I'm up to date on this), there are no 'native' firewire drives. The firewire drives just include IDE logic and present a firewire interface. This is why they cost $100 or so for the enclosure alone. A simple external drive enclosure/power supply would cost much less.
A 160GB firewire drive may allow full capacity because the IDE logic (necessarily ATA-100+) is inside the drive enclosure, and the IDE addressing is done there. The Firewire storage/drive spec just has to support the larger sizes, and it does.
Sadly, this is an area where Apple really has dropped the ball. It used to be that machines came with SCSI drives and interfaces, in a technology push similar to the USB push of a few years ago, and the current Firewire bonanza.
Now, while Apple's FireWire support is certainly commendable, lack of USB 2.0 (in a slight war with Intel in competition with Firewire) and the inferior hard drives that ship with even the best machines is lackluster at best.
It is time to let Apple know that drive performance is just as high on our list as such cool things as 1394. I can't plug my DV camcorder up to it (which certainly does reduce marketing value), but a fast IDE bus is still extremely important.
If you're in the mac market, or own one now, make sure to let Apple sales know what you think.
Just wanted to take the opportunity to advertise another public nethack server at http://dtype.org/nethack/ which just went up in the past couple of weeks as well.
This server will be around for awhile, and has great low-latency connections to the US and North America, and decent ones to more patient people elsewhere.
We'll also stop that confusing practice of confronting people with password prompts from now on. If we just assume they are who they claim, we're less likely to have stress and confusion.
That topic is well covered in the compatibility section of the GnuPG FAQ. The issue is compatible encryption algorithms. Since it is easy to specify which algorithms to use, this really isn't a problem. (at least hasn't been for me yet)
Please note that SpecWeb99 is highly software dependent, however. A lot of the test centers around two things: TCP/IP and network card performance, and software implementation of the dynamic part of the test suite.
In general, Windows 2000 can beat Linux performance in the TCP/IP stack at the high end. (According to my own tests at >300Mbit). Linux tends to cap at certain speeds. We're looking into why this happens but will be feeding results as we get them to kernel development lists.
The software implementation of the dynamic suites is also highly important in the tests. There are easily 50x differences in a CGI implementation vs. the IIS implementation that is included with the suite. Presumably, a more efficient implementation is also possible. This likely also had something to do with the score difference.
Lastly, Linux is a much better webserver platform that Win2K. This is not necessarily due to performance, but to stability/management/etc.
Spec is a funny test, and pushes webservers in ways I don't think a good benchmark should. It emphasizes TCP/IP performance too heavily IMO, and depends too much on a vendor writing a good dynamic suite. While this does give flexibility, it also mitigates the actual OS choice in SpecWeb99 score.
Anyway... great news for Linux, and I'll be looking forward to getting my hands on more specific information about this test. It is nice to have a benchmark go our way every once in awhile...
The FreeBSD Ports site at first glance looks fantastic. I'll definately email the webmaster for ideas. I'd love to see something along this lines for other Unices as well, and perhaps even for Linux/BSD/Unix porting as well.
--- SourceForge Programmer Type - http://sourceforge.net
I see a lot of questions regarding what is available on the Compile Farm, and a lot of great ideas as well. I'd like to dispel a couple of myths and offer some insight as to where this is going as well.
First, this is not a web-only service. We do like to provide web interfaces to as much as possible, but we do realize that for some things, program compliation and testing included, nothing can substitute for shell access.
A lot of people are asking about other hardware architectures and OS's. For now, the Compile Farm is i386 based, and contains several Linux distributions and FreeBSD. This does not mean that we have ruled out other possibilities. This is just another step in what we hope can be an expanding feature set for Open Source developers on SourceForge.
There is a lot of setup involved in something like this Compile Farm, not the least of which is having thousands of skilled Open Source developers with shell accounts on a set of boxes. We're attempting to keep things as secure as possible while also offering enough features to make this thing useful. One reason for the limited number of distributions/architectures/OS's now is the limitation of variables in a very complex system. Hopefully, we can work out the kinks in this system soon so that it can become a valuable resource to developers who might not otherwise have the capability of getting their hands on so many different machines.
We're also working on giving users the advantages ot having a cluster of machines available. Uriah Welcome worked very hard to provide parallel make capability to projects, and this is being tested now. (Parallel makes will allow you to take advantage of multiple dual-processor machines simultaneously in your compiles.)
Please be patient as we test this new system. We're definately open to criticism, but please also be constructive with it so that we can continue to improve these services. Thanks to all of the SourceForge users who have contributed patches, criticism, and helpful suggestions. Every day my confidence in the Open Source model increases...
--- SourceForge Programmer Type - http://sourceforge.net
1. I'm sorry that us giving things away hurts you so much.
2. I don't understand the 'handing over your work' comment since authors maintain the copyright on their code, which is Open Source anyway.
3. I was personally involved in the creation of SourceForge and am a little offended at your comments that VA 'dropped support' for OpenProjects for some weird reason. We've hosted OpenProjects for some time now and are continuing to maintain that server. SourceForge was created to offer an outstanding service package that was of a scale different than anything done before.
4. I'm an Open Source developer and don't plan to take over anything. I'm also an admin at SourceForge.
I'd love to talk with you about these issues, seriously. Please feel free to email me about it.
Sorry for the confusion there. Our intent was to promote these products in general and to give users something to download initially from our servers... sort of 'seeds'. We do print at the top of all 'seeded' project pages: NOTE: This project entry is maintained by the SourceForge staff. We are not the official site for this product. And we link to their own homepages as the project homepage. Should we not provide access to these projects at all, or is there a better way we could do this?
The main difference is probably the hardware and a full time staff and Linux company behind it. We're not trying to compete with anyone on this, just trying to give something to the OpenSource community. In the end, I think having 'competing' services like this will drive them all to be better.
Slashdot Mirror
I question not so much the free software crowd's love of Mozilla, as the hate for KHTML. Why hate this _other_ free and excellent library for web rendering?
Apple made a perfectly valid choice, and contributed their changes back to the free software community. Yet another great free software project now benefits from Apple, at IE/Microsoft's expense of market share on Mac desktops.
Don't draw any conclusions you don't have to. I love Mozilla, too, but Apple made a decision, and one which even most Mozilla developers feel was a valid technical choice, even if it wasn't the one they themselves would have made.
What exactly did Apple do wrong again?
There is. Everything from freedb is GPL'd, and always available for download.
(1) The ATA/100 would still gain you the larger address space, allowing larger capacities. Since
160GB drives are here (and a scant us$250 to boot), this is quite important.
(2) I agree that the faster bus in theory won't get you more performance with a _single_ drive. But the fact is, that benchmarks say otherwise. For whatever reason, the faster burst speed of the bus has slightly improved the overall speed. I'm not a particularly good hardware engineer, but when I run `hdparm` on a couple of drives, I like the faster speed regardless of reason... (I still hate IDE and would much prefer SCSI, but I can't get a 160GB SCSI drive for $250.)
(3) ATA/100 controllers are dirt cheap. I can't believe that the extra few bucks wouldn't be worth it in marketing value alone.
A 160GB firewire drive may allow full capacity because the IDE logic (necessarily ATA-100+) is inside the drive enclosure, and the IDE addressing is done there. The Firewire storage/drive spec just has to support the larger sizes, and it does.
Now, while Apple's FireWire support is certainly commendable, lack of USB 2.0 (in a slight war with Intel in competition with Firewire) and the inferior hard drives that ship with even the best machines is lackluster at best.
It is time to let Apple know that drive performance is just as high on our list as such cool things as 1394. I can't plug my DV camcorder up to it (which certainly does reduce marketing value), but a fast IDE bus is still extremely important.
If you're in the mac market, or own one now, make sure to let Apple sales know what you think.
This server will be around for awhile, and has great low-latency connections to the US and North America, and decent ones to more patient people elsewhere.
In the spirit of "make sure it says online", I've made yet one more mirror at http://dtype.org/available/657.zip.
---
Drew Streib, dtype.org
---
Drew Streib, dtype.org
As usual, there is a mirror via:
SourceForge FTP.
---
Drew Streib
Please note that SpecWeb99 is highly software dependent, however. A lot of the test centers around two things: TCP/IP and network card performance, and software implementation of the dynamic part of the test suite.
In general, Windows 2000 can beat Linux performance in the TCP/IP stack at the high end. (According to my own tests at >300Mbit). Linux tends to cap at certain speeds. We're looking into why this happens but will be feeding results as we get them to kernel development lists.
The software implementation of the dynamic suites is also highly important in the tests. There are easily 50x differences in a CGI implementation vs. the IIS implementation that is included with the suite. Presumably, a more efficient implementation is also possible. This likely also had something to do with the score difference.
Lastly, Linux is a much better webserver platform that Win2K. This is not necessarily due to performance, but to stability/management/etc.
Spec is a funny test, and pushes webservers in ways I don't think a good benchmark should. It emphasizes TCP/IP performance too heavily IMO, and depends too much on a vendor writing a good dynamic suite. While this does give flexibility, it also mitigates the actual OS choice in SpecWeb99 score.
Anyway... great news for Linux, and I'll be looking forward to getting my hands on more specific information about this test. It is nice to have a benchmark go our way every once in awhile...
---
Drew Streib
---
SourceForge Programmer Type - http://sourceforge.net
ftp://download.sourceforge.net/ pub/mirrors/XFree86/
---
SourceForge Programmer Type - http://sourceforge.net
The FreeBSD Ports site at first glance looks fantastic. I'll definately email the webmaster for ideas. I'd love to see something along this lines for other Unices as well, and perhaps even for Linux/BSD/Unix porting as well.
---
SourceForge Programmer Type - http://sourceforge.net
I see a lot of questions regarding what is available on the Compile Farm, and a lot of great ideas as well. I'd like to dispel a couple of myths and offer some insight as to where this is going as well.
First, this is not a web-only service. We do like to provide web interfaces to as much as possible, but we do realize that for some things, program compliation and testing included, nothing can substitute for shell access.
A lot of people are asking about other hardware architectures and OS's. For now, the Compile Farm is i386 based, and contains several Linux distributions and FreeBSD. This does not mean that we have ruled out other possibilities. This is just another step in what we hope can be an expanding feature set for Open Source developers on SourceForge.
There is a lot of setup involved in something like this Compile Farm, not the least of which is having thousands of skilled Open Source developers with shell accounts on a set of boxes. We're attempting to keep things as secure as possible while also offering enough features to make this thing useful. One reason for the limited number of distributions/architectures/OS's now is the limitation of variables in a very complex system. Hopefully, we can work out the kinks in this system soon so that it can become a valuable resource to developers who might not otherwise have the capability of getting their hands on so many different machines.
We're also working on giving users the advantages ot having a cluster of machines available. Uriah Welcome worked very hard to provide parallel make capability to projects, and this is being tested now. (Parallel makes will allow you to take advantage of multiple dual-processor machines simultaneously in your compiles.)
Please be patient as we test this new system. We're definately open to criticism, but please also be constructive with it so that we can continue to improve these services. Thanks to all of the SourceForge users who have contributed patches, criticism, and helpful suggestions. Every day my confidence in the Open Source model increases...
---
SourceForge Programmer Type - http://sourceforge.net
---
SourceForge Programmer Type - http://sourceforge.net
1. I'm sorry that us giving things away hurts you so much.
2. I don't understand the 'handing over your work' comment since authors maintain the copyright on their code, which is Open Source anyway.
3. I was personally involved in the creation of SourceForge and am a little offended at your comments that VA 'dropped support' for OpenProjects for some weird reason. We've hosted OpenProjects for some time now and are continuing to maintain that server. SourceForge was created to offer an outstanding service package that was of a scale different than anything done before.
4. I'm an Open Source developer and don't plan to take over anything. I'm also an admin at SourceForge.
I'd love to talk with you about these issues, seriously. Please feel free to email me about it.
Sorry for the confusion there. Our intent was to promote these products in general and to give users something to download initially from our servers... sort of 'seeds'. We do print at the top of all 'seeded' project pages: NOTE: This project entry is maintained by the SourceForge staff. We are not the official site for this product. And we link to their own homepages as the project homepage. Should we not provide access to these projects at all, or is there a better way we could do this?
The main difference is probably the hardware and a full time staff and Linux company behind it. We're not trying to compete with anyone on this, just trying to give something to the OpenSource community. In the end, I think having 'competing' services like this will drive them all to be better.