A few days ago we featured an interview with one of Fink‘s project leaders regarding their package management solution which breeds more Unix software to MacOSX. Today, we host an interview with Jordan Hubbard regarding the DarwinPorts, speaking for the DarwinPorts Team which a similar effort to bring more Unix software on Mac OS X. Jordan is currently working at Apple and OpenDarwin (while many will know Jordan as the FreeBSD co-founder).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!
Does this little statement mean that OS X 10.3 is based on FreeBSD 5.x ??
*Based* in its entirely no. But added source code from FreeBSD 5.x, advancements etc., sure. Why not?
You can also get BSD ports in an easy to install package on cd-rom from BSD Mall. It is called UNIX Utilities for OS X. I bought it at my local Mac store and will install it when my eMac arrives from MacMall in a couple of days. If anyone is interested I can give a review. I am a graphic designer so I would review applications relevant to me. I have used Open Source ports on Windows and Linux, so I could compare performance and ease of installation, etc.
Looks like the choice of Tcl (over, say Python) is worth questioning. RMS believed it was a limited language and a bad foundation:
http://www.vanderburg.org/Tcl/war/0000.html
Maybe Tcl has caught up and become stronger, or it might be good for this domain. But I wonder if systems coders just make bad choices when building applications. For example, Hubbard’s criticism of Python is weird; I’ve never known anyone to have problems with whitespace. Can anyone maintain code where the indentation isn’t aligned?
The rest of what he says is fine; no doubt Tcl has a longer history being embedded in apps, and he says it really was a subjective choice. I just wonder if systems guys have a blindspot.
Why do you care what RMS says? He even later recanted his initial criticisms, but the damage was already done. The reason for including Tcl is likely because it’s designed to be embedded in applications; Python is not. Tcl is simple. You don’t need bells and whistles for something like this. End users need never see the language that’s being used, so does it really make a big difference?
I to am befuddled.
Python while it does impose strick controls on how you get stuff done is a great language..it is easy to learn, easy to read, easy to manage, and powerful. and since it used TK or realy any widget set you liek there is no reason not to use it over tcl.
I guess JH is just one of those hackers who like to have the ability to make the code look the way they like even if they do use good formating practices.
AFAIK, you can. infact I know python provides a c lib(and I think it is usable in C++ or they have a lib for C++) that calls the python interpreter and runs the code in the braces.
now, I have never used tcl but unless gcc can compile tcl code along with the c code around it, I don’t see how else you can embed the language.
I certainly never said that Python could not be embedded in other applications, I simply like Tcl’s C/C++ API for doing so quite a bit. It’s simple, powerful and gives you ample capability for calling into C to Tcl and vice-versa with full access to variables, trace-points and all the other features of the language.
If you also read the DarwinPorts FAQ at http://www.opendarwin.org/projects/darwinports/en/faq.php you’ll see that we were also shooting for a simple key/value pair syntax in the Portfiles so that end-users wouldn’t even have to know that they were dealing with an interpreted language. Tcl’s simplicity made that possible, which is largely what I was referring to when I talked about whitespace and style.
Regarding embedding Python in applications. The MMO game EVE uses python for it’s ingame scripting and partially also GUI.
Well, Jordan has provided us with an answer. Please correct me if I’m wrong, but it seems TCL was in part due to preference (as Debman suggested). I can’t blame anybody for using what they like. Isn’t it great to have the freedom to choose? I think so.
I did want to comment on this part of Debman’s post though:
Python while it does impose strick controls on how you get stuff done is a great language..it is easy to learn, easy to read, easy to manage, and powerful. and since it used TK or realy any widget set you liek there is no reason not to use it over tcl.
I agree. Python is a great language. At first I hated the way it made you indent the body of functions, classes, loops, etc. However, after working on a project with other programmers using Python, I found this feature of the language very handy. It forced everybody to write code that was ledgible and easier to maintain.
I do disagree with the TKinter comment though. TKinter is a good reason NOT to use Python in my opinion.
Fortunately, there are other graphics frameworks, such as my personal favorite wxPython, which make Python really really cool for programming GUIs. In fact, wxPython provides me with what I always wanted out of Java, but never quite got.
Very interesting interview! Way to go Eugenia and thanks to JH!
Thanks for making that clearer!
To make my post clear for RJW, quoting Stallman was done because he wrote Emacs, noted for its extension language, and so I’m inclined to think he has interesting views on this topic. His argument was that longterm needs need to balance with shortterm goals, because often it happens your software grows faster than your foundation lets it.
If he did recant his criticism, I’m not having much luck finding it; but I wouldn’t be surprised if he did.
Mainly the whitespace criticism sounded like everyone else’s whitespace criticism.
You hear it so often, it’s surprising when there’s a good usability argument in there.
Looks like the choice of Tcl (over, say Python) is worth questioning. RMS believed it was a limited language and a bad foundation:
It’s hard to weigh the pros and cons of a language across all applications. There are opponents to every language that I have ever heard of. Try TCL yourself, if you like it fine, if not that’s ok to.
How is it? How does it compare to Fink? How well do the 2 co-exist?
Thanks!
I am a developer for DarwinPorts (Go consolle Othello!) and I use fink as well. Fink is based on the concepts in Debian’s apt system. It, in fact, uses apt to manage its collection of ports.
DarwinPorts is based upon the FreeBSD ports system but instead of installing apps in their typical Unix places like FreeBSD ports, Darwin uses its /opt (I think Solaris does this as well).
Fink and DarwinPorts can coexist just fine but they just ignore each other. Say, for instance, you need gtk as a dependency for a fink package and have it it installed via DarwinPorts, fink will not detect it and will install its own gtk. The reverse works is true as well.
Both Tcl and Python are fine, but for scripting, and every other kind of programming, Ruby is really the way to go. http://www.rubylang.org/en
You’re right anon, I checked the archives and he didn’t recant his statements about Tcl, however he did soften his approach, which you can see if you read some of his later posts in the “Tcl War”.
Here’s some questions I wish were asked in the interview:
Is DarwinPorts funded by Apple?
Is this based on libh?
Does this have the potential to become FreeBSD’s next-generation ports system?
These are not so much of a question IMHO.
> Is DarwinPorts funded by Apple?
The guys who work on it are mostly Apple engineers from their Unix department, AFAIK.
> Is this based on libh?
Does it really matter, as long it works?
>Does this have the potential to become FreeBSD’s next-generation ports system?
Jordan is not part of the FreeBSD project anymore, so such a decision are solely of FreeBSD’s.
ehhh
I don’t know…..ruby is ok, but it is not as…nice….to learn as Python IMHO. there are some oddities in there.
realy, when you compair ruby to python to perl, they all can do the same things (out side of graphics which AFAIK perl can not do) and they can do it well. so if you like to program with a bagillion diffrent ways to do one thing then perl is great for you, if you like easy to read and manage then python is for you…and ruby is close enough to python than it is good for readability and manageability(does ruby have better performance than python?)
Ben Huot said:
“You can also get BSD ports in an easy to install package on cd-rom from BSD Mall. It is called UNIX Utilities for OS X. ”
I bought BSD Mall’s Office Applications for OS X. Overall I am pleased with my purchase, even though I’ve never used 1/2 the software. The install is fairly painless and the X windows and programs work well.
The only flaw is spotty documentation and help functions for the various programs. I’ve not yet been able to figure out how to resize/resample a photo in gimp. (I do it all the time in Pshop and Corel). There’s also a little utility that’s supposed to let you copy from Aqua to X and vice versa. NO HELP file whatsoever, and it’s not intuitive to use. After contacting the folks at BSD Mall, I’ve been able to copy X to Aqua, but Aqua to X hasn’t worked.
Despite these annoyances, it’s a good product and money well spent.
Were those screenshots linked in the Interview and the ones on the OpenDarwin website taken under OSX, or was the app skinned to look like Aqua.
Since I am not a Mac User I found it strange to not see the usual Mac bar at the top. I understand the dock can be hidden.
It was just an abstract, a detail of the desktop, not the whole desktop.
las time I read the BSD licence IT CAN BE USED WITH OUT PAYMENT IN ANY CODE. if you are gonna be a moron, open your mouth on something a bit more nebulas like politics.
I thought Jordan was still part of the FreeBSD project, but simply no longer a core member?
I was under the impression that he quit core and decided to take backseat for a while — seeing as how Apple & OpenDarwin likely consume most of his time.
it could also be on a second monitor.
RMS believed it was a limited language and a bad foundation
Can’t say much about the language limits, as all languages have limitations that enable you to structure your code properly (except maybe Perl, where most don’t care). The bad foundation criticism was quite valid once, but not starting with TCL 8 and its new interpreter. I wouldn’t be surprised if RMS’s comment was outdated when he made it, though.
For example, Hubbard’s criticism of Python is weird; I’ve never known anyone to have problems with whitespace. Can anyone maintain code where the indentation isn’t aligned?
The problem with Python whitespace handling comes when some people use spaces to indent and others use tabs. The code looks like it’s indented the same to the naked eye, but not to Python. The naked eye’s interpretation is used by the maintainer and Python’s is used by the interpreter (or whatever) – if they don’t coincide, then the code is unmaintainable. You can’t assume that tabs correspond to the same number of spaces either, as that varies based on the editor settings. Python is why most Linux code editors make whitespace visible (a rarity outside of Linux), so you can see your syntax.
Other than that, I have no major problems with either language.
For those questioning Tcl, do some research. It is way beyond the days when RMS whined about it. It is the best language for this kind of environment, all things considered.
To make my post clear for RJW, quoting Stallman was done because he wrote Emacs, noted for its extension language, and so I’m inclined to think he has interesting views on this topic.
FWIW, my experience has been that the wider Lisp community looks on ELisp in about the same way RMS did TCL. No one I know of believes it’s a well-designed (or implemented) language; most only tolerate it because there aren’t any alternatives. Even the GNU folks were looking at replacing it with Guile.
I’ve never known anyone to have problems with whitespace. Can anyone maintain code where the indentation isn’t aligned? </blockquote>
Python may be the best thing since sliced rabbit, but, as a matter of fact whitespace is hard to maintain across years of development. My company has a strict indentation policy, and even offers a .vimrc for developers to use.
The usual trick for embedding Tcl is to embed the interpreter. It’s C code with a clean API. This is the technique used by the EDA applications like Cadence and IBM.
Re: RMS and Tcl. To put his comments in context, at the time they were made Tcl was a couple years old, Windows 95 was not yet released, and the 486 was the hot CPU. Many things have changed since then, including Tcl. His criticism helped drive Tcl’s evolution.