1. What are the main differences between the Fink Project and the Darwin Ports, technologically and... philosophically.
Jordan Hubbard: This is a hard question to answer in the general sense since the various people currently working on DarwinPorts have a number of reasons to be involved with the project, both technical and philosophical, and those reasons are as subjective as they are broad. What we can say is that a number of existing projects were looked at, among them Fink, Gentoo and the FreeBSD ports collection (which at least one of us is obviously rather familiar with), before the decision was ultimately reached, for our own highly subjective reasons of course, that we wanted something a little different from all of them. We wanted something with an architecture which was highly extensible and could cope gracefully with what would certainly be significant changes over time. We also wanted something which could be embedded into other software-building applications or front-ended in various unforseen ways, the chosen technology and licensing being rather important factors in reaching that goal.
While not taking anything away from fink, a highly successful project which has greatly benefited Mac OS X's Unix-savvy user base for some time now, we think there is still a lot of room for innovation concerning how to construct and maintain a port collection's infrastructure. That is the goal of DarwinPorts in a nutshell: To create an open-ended, 2nd generation architecture which benefits from a lot of the knowledge already gained through experience with systems like FreeBSD ports and fink. We also think that Landon Fuller and Kevin van Vechten, the system's two principle architects, have done a great job of this so far.
2. I see that you have almost 300 ports on your tree, while Fink has 2,300+. How are you going to increase the amount of software available for your ports tree?
Jordan Hubbard: Part of the reason we've put so much time and effort into the infrastructure of DarwinPorts and services like the WebDAV-accessible packages collection at http://packages.opendarwin.org is to make the system attractive to developers. It's those same developers who create the bulk of the initial ports, at least until a critical mass of ports-savvy users is reached, and get you from 353 ports (our current count) to 3,500 and beyond. Given the sheer number of Mac OS X and generic Unix 3rd party applications and libraries out there, we don't think 10,000 ports is an unrealistic number to shoot for, actually, and to get there DarwinPorts will not only need to have a lot of ports but also considerable infrastructure in place for testing, validating, debugging and packaging the whole collection so that a significant percentage of those ports are not "broken" at any given time. Some of the biggest issues facing a large collection aren't technical at all, they're organizational, and we're working on building such an infrastructure in parallel as our ports collection grows.
3. Is DarwinPorts (plus its GUI) going to be installed by default on a future version of MacOSX or its Server version?
Jordan Hubbard: Any predictions would be purely speculative at this point and it's simply too early in the game to worry about bundling DarwinPorts with anything right now anyway.
4. Is Apple interested in porting the KDE/Gnome libraries (I am not talking about the desktop environment in particular) and then make available a large number of X11-based applications to OSX to enrich its app base? If yes, would the infrastructure to run these apps would come by default on OSX?
Jordan Hubbard: Apple is clearly interested in seeing any number of developer libraries ported to Mac OS X, cooperation with the KDE folks regarding KHTML in Safari already being a matter of public record and hopefully just one of many such opportunities for open source collaboration. One possible infrastructure for building and packaging such libraries and applications might also be DarwinPorts, though it's certainly not the only option.
5. Do you have any plans on providing Altivec-optimized binaries?
Jordan Hubbard: It seems that most of the developers in the OpenDarwin community are currently focused primarily on just getting applications ported in their "vanilla" form, though quite a number of optimizations are certainly of interest and may be undertaken at some point. There certainly aren't any plans NOT to try to optimize for Altivec as such opportunities come up.
6. If you can tell us, what code has been put into OSX's source tree from FreeBSD 5.x, if any?
Jordan Hubbard: This question would probably be better asked when 10.3 comes out since it's only then that we'll have a truly definitive answer to it.
7. Why TCL was chosen as the backend language of choice, instead of, let's say... Python, or Perl?
Jordan Hubbard: Tcl is a comparatively simply language with a syntax which is both relatively forgiving of style differences (for things like whitespace) and easy to understand. It's also easy to embed in other applications, which furthers the goals outlined in the answer to question #1. Finally, it was simply a matter of personal preference. The other languages were looked at during the architectural design and Tcl was felt to embody all the desired characteristics for an interpreted language in this application.
We hope this helps to answer some of your questions, and for more information people are certainly encouraged to visit our web site. We'll also be giving a presentation on DarwinPorts at Apple's upcoming WWDC conference in San Francisco for those who will be attending. Thanks!