Today, we host a mini-interview with Fink’s project leader, Max Horn. The Fink project wants to bring the full world of Unix Open Source software to Darwin and Mac OS X. They modify Unix software so that it compiles and runs on Mac OS X and make it available for download as a coherent distribution. Fink uses Debian tools like dpkg and apt-get to provide powerful binary package management and you can choose whether you want to download precompiled binary packages or build everything from source.
1. Has the Fink project considered adding the FinkCommander as part of the whole project, for easier usage by the Mac OS X users?
Max Horn: For the upcoming Fink release, 0.5.2, we plan to include FinkCommander as part of the binary installer disk image. We also want to mention it in some more spots of our docs. However, it still is and probably always will be, a separate product. We work together with its author whenever needed, but there are no plans to make it part of the Fink project itself.
2. Is the Fink Project working together with Apple in order to guarantee better compatibility of its ported X applications to the Apple X11 server (which is currently in beta)?
Max Horn: You really should be asking: Is Apple working together with us? 🙂
They are the big ones, and they choose whether they want to ignore us or work with us. Luckily, the answer is (at least to a degree) yes. There are numerous Apple employees on the Fink mailing lists, and in fact two of our project members work for Apple (although their involvement with Fink is a purely private thing and not in any way endorsed by Apple). For example there was one serious bug in Apple X11 beta 1 which caused (not only us) lots of headaches, and this was resolved in collaboration: Apple employee’s discussed the problem with us on fink-devel (our fink developer mailing list), and fixed it. And in the meantime we implemented a workaround as part of our system-xfree86 package with their help (to bridge the time till beta 2 was released).
Overall, the mood at Apple seems to be friendly towards Fink, they refer to us in various places of their homepage, for example.
3. Please tell us about the team that consists Fink. How many members are there, how many maintainers and also, do you have a kind of quality control to ensure that the ported apps work as they supposed to?
Max Horn: We currently have three project leads (Benjamin Reed, David R. Morrison, and me). The SF.net project currently lists 31 members, but that number is pretty irrelevant. Roughly half of them are actively
working on the project. By my last count, there are about 130 different package maintainers. 23 of those maintain 10 or more packages, and 4 maintain more than 100 packages. Benjamin Reed hold the record with 185 – but many of those are semi-automatically generated language packages for KDE (luckily!).
Which already gives a hint at the second part of your question: Obviously, providing quality control for over 2000 packages is a tough thing. For each package its maintainer is the primary responsible person. If you maintain more than 100 (or, for that matter, more than
30 🙂 packages, that’s a burden. I believe we need to reduce the number of packages per maintainer on the long run. We are working on this.
For QA we adopted a system somewhat similar to that employed by debian. The first line of defense is the fink package validator which scans an .info file and the resulting .deb files for certain typical problems. New packages (or new versions of old packages) first go to
the unstable-CVS tree. There, we mostly relay on feedback by users on these packages (both positive and negative feedback). After some time, if no problems are found, but sufficiently enough people have reported good success, the package may be moved to the stable-CVS tree. Finally, when it comes to the time when we make a new binary distribution, the stable tree is once more combed for any problem with packages in it, before we release this to the general public.
For all this we make heavy use of our bug tracker. If your or anybody thinks (s)he has found a bug in Fink or one of its packages, I strongly encourage that you report it there, we are trying hard to fix
4. How about offering more “integrated” ports to OSX? For example, when you port Gnome or KDE and their apps, how about using by default OSX fonts and themes that resemble that of native OSX’s? Also, what about drag-n-drop and copy/paste between native and X apps?
Max Horn: These two examples are actually to radically different things 🙂
As to making Gnome/KDE use default OSX fonts and themes, we have the
applesystemfonts package which makes all OSX font available to X11.
Also, Apple’s X11 does the same for you. If you use Apple’s X11 and
their quartzwm window manager, window borders are in the aqua look. We
also have the mosfet-liquid and xliquid-gtk2 packages for KDE/GTK2
which more or less provide an Aqua look-alike. But both are optional,
and we currently have no plans to make them a required default.
Copy/paste integration is not in Fink’s, but in XFree86’s domain, and
at least for text has been reality for a long time – see here. That document is slightly outdated though, as it doesn’t mention Apple’s X11. There, you can copy text via Cmd-C / Edit-Copy. For some reasons, Cmd-V / Edit-Paste doesn’t work, though. So to paste text, you have to do it the X11 way with the middle mouse button (if you only have one, pressing Alt/Option while clicking will do the trick).
Making drag&drop work between OS X and KDE/Gnome would be quite a mammoth task and is definitely out of scope for Fink. That’s more something for the KDE/Gnome/XFree86/Apple X11 teams to worry about .
5. What are the next plans for the Fink project. What new features or advancements are you cooking for the Mac users?
Max Horn: Besides packaging more and more stuff, and keeping our existing 2333 packages (last count) up-to-date and functional, you mean? 🙂
For one thing, we are working towards the 0.5.2 binary release, which is hopefully going to be released soon (CVS has already been tagged, but QA and some other things still need time). I already mentioned it
will feature FinkCommander, and more binary packages than ever. Overall I believe it will be the best Fink release so far, as the team (and Dave Morrison in particular) has worked hard to fix bugs and resolve certain issues that troubled previous binary releases.
There are various other things in the planning, for example a revamped dependency engine (a very complicated task), adding so-called “variants” to the build engine, providing our own source file repository (a joined effort with the OpenDarwin project), and more. Stay tuned.
6. Do you have any plans on providing some application binaries that are G4/Altivec-optimized?
Max Horn: Currently, we do little in that direction, mostly due to our policy that ask for binaries to be identical (as far as possible) on all systems. The motivation for that is to make maintenance possible for
us; plus it’s of course important that binaries from the binary distribution work on all systems. Providing optimized binaries has not been high on our task list for that reason. In fact, there are quite some packages out there which are only built with minimal optimization
(-O) and even with debug information (-g). Usually because it’s the default setting for many packages.
There are exception, the atlas package for example (a scientific package with highly optimized linear algebra functions) optimizes itself to the system it is built on. It allows you to build with Altivec support enabled. Another package which is highly optimized (although not Altivec specific) is KDE, which Benjamin Reeds tweaked
so much that now it’s many times faster than its first version on OS X were.
Right now, there are still quite some G3 users out there, for whom an Altivec-only package would be annoying. OTOH, maintaining 2 versions of a package (one with Altivec, one without) can be tedious (or even 4 or 8, if you have also the choice between optional X11and SSL support). We have been planning to add support for “variants” to the
Fink .info format for some time now, which would make it very easy to provide special Altivec enabled versions of a package when building on a G4.
Finally, one thing one shouldn’t forget: optimizing something for Altivec is not just a matter of throwing in a “-faltivec” switch. The Apple GCC currently has little ability (any?) to automatically vectorize operations. Thus, code has to be hand rolled to take advantage of it, and that means it’s really the job of the upstream
maintainer, and not ours, to do it. We distribute software, we don’t make it (except for the fink tools themselves, of course).