Slashdot Mirror
Jordan Hubbard Gives Last Intervew For Apple
acaben writes "MacSlash has posted what Jordan Hubbard says will be his last interview for Apple. Apple's Engineering Manager for the BSD Technology Group talks about the new BSDPorts initiative, his thoughts on working for Apple and Apple's Open Source strategy, and how Mac users new to Open Source can get involved and contribute to the community. He also gets delightfully geeky in comparing the differences between Darwin's VM envirnoment and FreeBSD's and explains that Darwin was built with things like working with Final Cut Pro in mind."
I'm sorry, but reading several hundred lines of italicized text is making me nauseous:
.deb packages and is really badly documented.
:-)
;-) I'm sure there are other areas where this can be improved besides these two examples.
:-)
Jordan Hubbard, Apple's Engineering Manager for the BSD technology group has been kind enough to answer the question you posed awhile ago. (The holdup in getting these posted was not Mr. Hubbard's fault, but a snag in Apple's PR department approving his answers.) Mr. Hubbard has said that this will be his last interview for Apple, and he will no longer have contact with the press. (Note, this doesn't mean he's leaving Apple. He's just not talking to the press as part of his duties at Apple.) We're glad to share his thoughts with you in the answers below.
Filesystems
by marmoset
I know that Darwin supports plug-in filesystems. Is anyone working on fault-resistance (softupdates, journalling) for future Darwin releases? I lost months worth of encoded MP3's to directory corruption last month (I didn't back them up because I had the original CD's, but still, it's a ton of lost effort) and I'd love to see some sort of more robust filesystem support show up.
As you may have noticed, we recently release journalling support for Mac OS X Server.
Building Darwin
OpenDarwin recently released the initial release of DarwinPorts, will the build system used on Apple's Darwin ever build using DarwinPorts? The reason I ask is that I've found the Darwin build system to be insanely difficult, it requires an incredible amount of bootstrapping, uses Debian style
JH: We are always looking for ways to make Darwin easier to build, but it is too soon to comment on whether DarwinPorts is the right solution.
Second related question. How are the people behind DarwinPorts working with the fink team? It seems like once DarwinPort matures there will be a lot of duplicated effort between the DarwinPorts and Fink teams? Are Fink's days numbered?
JH: The fink developers have actually been very supportive of the darwinports project and they seem to feel that any project which satisfies the overall goals of bringing lots of useful third-party software to Mac OS X is a good one, no matter what it's called. I haven't seen any real duplicated effort yet and expect to see more cooperation between the teams if and when that starts to be an issue.
Third DarwinPorts related question. One of my concerns with installing software from packages is that the way the packages are configured can never satisfy everyone. For example I always build expat before building python so that I can get access to Python's XML parsing functionality. Some people would prefer not to do that to preserve space. How will DarwinPorts be flexible enough to deal with those sorts of situation? Will it only be flexible enough if you build from source or do you see binary packages able to cope?
JH: Well, let me first say that if your build system doesn't cope with building "variants" for things then it's pretty unlikely that your package system will either since *something* has to build the bits you're packaging and it has to know what order to build them in, as you note with your expat and python example. Darwinports has the concept of port "variants" to handle this exact problem, and I expect whatever package system we end up gluing in as a back-end to Darwinports will simply name its packages such that if you want to provide versions of expat with XML and without, darwinports can build and package both. Then it simply becomes a matter of having a package management front-end give the user the option of selecting a package name and the variants they want and then use the same name-mangling rules to try and find that pre-built variant. Getting really clever, you might even end up sending a request to some darwinports server asking it to build you a custom package on the fly and send it back. It's probably still faster to have a dual XServe on the net build a package for you, even with others contending for the resource, than building it yourself on a G3/233 or something. With proper caching of pre-built packages, you wouldn't even need to compile stuff on the server all that often and this is obviously an area ripe for exploration.
Kernel level clustering?
by jessemckinney
Hello, Is there going to be clustering in some of the next builds? I would love to see OS X be able to cluster with any other mac on my lan. Can you imagine the possibilities?
JH: I'm not involved with any of that, so I really can't comment.
Working for Apple
by Anonymous Coward
Is your job at Apple what you thought it would be? What has been the greatest surprise?
JH: I didn't come to Apple with a lot of preconceived notions either way, so I wouldn't say I've been particularly surprised by anything here. If anything has been a surprise to me, it's been the degree to which people outside of Apple seem to care so intensely about what we're up to and where we're going.
What do the other *BSDs get out of Darwin?
by chrischow
We know the benefits of using *BSD code to improve Darwin and with it OSX but what about the other direction? How have FreeBSD and co. benefited (if at all) from Apple/Darwin development?
JH: Some patches and test suites have already made it across from Mac OS X into FreeBSD, one test suite in particular (a filesystem exerciser) being very useful to Matt Dillon and others in finding bugs in FreeBSD's NFS code and even in UFS's soft updates feature. There's also the PR angle, obviously, since it certainly doesn't hurt FreeBSD at all to get prominent mention in some of Apple's keynotes. Finally, given BSD's historic focus on the server room, having the whole "Unix on the desktop" issue actually getting quite a bit of positive spin for a change isn't hurting the Unix cause in general at all.
Mac OS X has done a tremendous amount to make the very idea of Unix on the desktop credible again and undoing a lot of damage which Unix did to itself back in the 1980's during the Unix/GUI wars. To be sure, the KDE and GNOME projects have also done a lot of good in enhancing Unix's reputation there as well, but for many users the word "Desktop" is synonymous with "office applications", "multimedia" or "mainstream games" and being able to run things like Microsoft Office, Cubase SX or Medal of Honor alongside traditional Unix applications like emacs For PERL is pretty cool no matter how you look at it.
intro to oss 101
by Snuffub
With the release of Mac OS X millions of less technical users have been introduced in one way or another to open source software. Im sure a good number of them would want to get involved in the community some way but they dont have the technical background to help in the obvious ways, programing etc. What would you say to someone who asked you how they could help out the various projects that are bringing great software to the platform?
JH: I would say the first thing to do is find a project, like opendarwin or fink or any of the dozen or so Mac OS X-related projects on sourceforge, which seems to be doing stuff you're interested in and start "hanging out" in the forums they provide. Reading the dicusssions for awhile will start to give you a better feel for where they seem to need help, whether it's in getting documentation written or doing more testing or helping to evangelize the project and get more developers involved, or whatever. After you have a good feel for how things are going, volunteer for something! You'd be amazed at how many of these projects are desperate for things as "non-technical" as having their web site spruced up or maybe getting a little artwork for the project's mascot (or coming up with one in the first place). It's not just technical work that needs doing by any means and any project with good presentation skills is one which is far more likely to be successful.
Advanced Security Features; Other Stuff
by zarafa
What can you tell us about plans to include some of the current or forthcoming "next-gen" security features from the other BSDs? Specifically, jailNG (http://www.watson.org/~robert/freebsd/jailng/), systrace (http://www.citi.umich.edu/u/provos/systrace/), ipfw2, the FreeBSD NATD rewrite, Mandatory Access Controls (from the TrustedBSD project), and similar things? I know those are in many cases emerging technologies, but will Darwin attempt to stay relatively current with them?In a similar but not directly-related vein, what about filesystem improvements like those in UFS2 (softupdates, snapshots, extended attributes, etc.)? Leaving aside the possibility for the moment of a brand-new filesystem, it would just be nice to have a modern UFS...And just for the record, how do you feel about the Darwin virtual memory system, specifically as it compares with that of FreeBSD?
JH: When your grandmother sits down to log in, unless your grandmother is someone like Grace Hopper, the last thing she probably needs to see is a message like "Please enter DSA key to unlock keychain or next passphrase in OPIE sequence." Unlike some other Unix vendors, Apple needs to preserve ease-of-use as a high-level goal while also providing the kind of low-level features that allow more sophisticated users to apply other security policies, especially in server environments. We are in fact looking at a lot of the stuff that the FreeBSD and TrustedBSD projects have done in addition to pursuing various security certification programs which are necessary for certain markets. As to whether we'll adopt jailNG or some of the other mechanisms you mention, I can't say, but we're certainly aware of such things and aren't adverse to incorporating any good ideas or mechanisms which fit in with the higher-level goals I mentioned.
The Darwin VM and FreeBSD VM systems are so different in both scope and purpose that it's actually pretty hard to compare them. Running applications like Final Cut Pro put some really unique demands on a VM system and Darwin's has been designed with those sorts of usage scenarios in mind, whereas FreeBSD tends to optimize for a very different historical area of server focus. It's all a matter of choosing the right resource allocation and quota trade-offs given a certain projected application mix and I think both VM systems have actually done a pretty good job of this.
How Did It All Start?
By Snuffub
everyone knows that youre a leading figure in the BSD community so it's no wonder that apple hired you to head up the darwin project, but how did the relationship start off? Did they contact you early on when they first decided to use BSD? or was it an out of the blue phone call? Either way what were your major reservations when you were first offered the job, given that at the time apple had no track record in terms of their comitment to the open source community?
JH: I was actually the first to contact Apple, though I found them very receptive to the idea of my working there when I did. I'd been frustrated by Unix's historical lack of success on the desktop for a long time, and took it rather personally since I used desktop machines a lot in my daily life and Windows was not my idea of an ideal desktop OS. After seeing FreeBSD grow and prosper for almost 10 years, I also felt that BSD had done an amazingly good job of breaking into the server market and I was very ready to see it take on some new challenges. When I saw the first developer preview of Mac OS X, I knew Apple had something special on its hands and I started itching to get more involved. When 10.1 came out, I called and asked for an interview.
As far as reservations go, I can't really say I had any significant ones. Sure, Apple is a big company and its open source strategy is still evolving, but the fact that it has an open source strategy at all and a real chance to bring Unix to the desktop and in front of a much different audience than that traditionally enjoyed by Unix is more than enough for me. I'll continue to try and play a strong role in expanding Apple's relationship with the open source community, of course, and just seeing how much the Unix community has embraced Mac OS X so far makes me very optimistic for the future.
"Macifying" the unix core?
by Van Halen
I'm wondering if there are any plans to modify the unix core to better handle Mac-specific quirks. Things like using carriage returns instead of newlines. Utilities like vi and less currently don't convert these to newlines, which can be a pain when looking at files created in more traditional Mac-type programs. Another example is file management utilities and resource forks. I think cp, tar, etc should handle resource forks transparently by default. Yes, there's ditto - but that's not a "standard" unix utility. Plus it requires an explicit command-line option. Back when I first got my OS X machine, I setup a crontab to backup my Quicken data using tar to an NFS mounted drive on my FreeBSD machine. It ran happily until about a month later when I needed to restore a backup - and discovered that Quicken stores most of its data in the resource fork, which was left behind! Not good. Are you guys working on anything like this? If not, will you consider it now that I've mentioned it?
JH: This is a tough area since you don't want to change *too* much about what makes Mac OS X a good Unix or interoperability and ease of administration suffers, and that's very important considering how heterogeneous the Unix world tends to be, especially in higher-education. That said, I think there's still a lot we can do to increase Mac-to-Unix interoperability. One example of a great Open Source project that helps in this area is rsync_hfs, hosted on opendarwin.org. It's a careful balancing act to make sure that we do things in such a way that the Unix experience is not compromised in the process of adapting to the Mac traditions, and I think that people are definitely going to see evolution in both directions, with some traditional Mac stuff migrating more towards open standards and some Unix things which have been traditionally unwieldy getting a much-needed face lift.
Needless to say, user feedback is always an important part of making these decisions and I hope both the traditional Mac and Unix communities continue to tell us what they like and don't like about Mac OS X - that's very important to us in setting our priorities in goals at Apple, and that's not just marketspeak, it's true, so keep those cards and letters coming, folks.
[Thanks to Macslash for giving me the opportunity to do this Interview]