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
things.
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).
Its a great project, it allows you to run Unix OSS on the elgant and user friendly Mac platform. Interesting project, especially for Mac users.
If you have a PC, and a Mac its usually not worth the hassle though.
OS X introduced me to the world of Unix, but fink made that world seem worthwhile.
Thanks for all your hard work.
A program that introduced me to quality accomplishments,that speak for themselves. I get to be part of “Nix’s” evolutionary
permaculture of inspired initiatives. How cool is that.
I was going to post a list of what I have off of Fink, but a quick ‘fink list -i’ yielded a list too long (I have 176 packages installed).
My only complaint is that fink doesn’t puts (is) a nonstandard interface to apt.
There are a few packages I would like to be able to get (links, Frozen Bubble, MAME, ScummVM, Snes9x, OpenOffice, Mac OS 10.3), but wow the things that work so easily.
One warning for fink. Once you try it you may find it hard to ever justify compiling software manualy for install (and maybe even doing a D&D install).
Auto-vec is something that’s not available on compilers. Cray tried for many years to add such functionnality to their compiler and they thown the towel away.
A real project would be to write optimizing option that would vectorize code. Anyone knows of such project being put into place somewhere ?
Ludo
—
http://www.yatoo.ch
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).
Argh, this is one of my biggest complaints with Apple’s X11! Why don’t they make Cmd-V send the middle click event to the raised application? Certainly this wouldn’t work for every application, but it’s better than having Cmd-V do nothing. Option-Click is very annoying, especially on an iBook with no external mouse.
“Auto-vec is something that’s not available on compilers. Cray tried for many years to add such functionnality to their compiler and they thown the towel away. ”
Clearly you have never coded for a CRAY, haven’t you? If there is something that cray compilers are good at, is vectorizing code. Grated that it deals mostly with loop intensive vectorization… esp. with Fortran code. That is also why cray compilers cost an arm and a leg.
BTW. Alti-VEC is a SIMD unit, not vectorial… marketing hype.
Quite annoying when marketroids get to ruin architecture terms.
Well with Apple’s X11 ctrl-c and control-v seem to cut and paste just fine.
Mind you, I only use fink for GIMP and PAN, so it may be a GNOME thing.
Dave
I want to thank the authors, maintainers and contributors on the Fink and FinkCommander projects. By creating these applications, and by combining them with the powerful Dpkg and Apt-Get tools, the world of command-line utilities and X/KDE/GNOME applications has been made readily accessible to thousands of users that would otherwise, through technical inexpertise or ignorance, would not be able to harness these tools.
Being able to run these tools side-by-side with the MacOS X environment and its applications, and have some level of integration betwixt the two, and having a measure of unofficial support and technical work from Apple, means that Macintosh users are prepared for a future where open standards and open source are the rule, rather than the exception, on desktop, portal, middleware and backend systems.
The Macintosh has a chance of becoming what has eluded it since it’s inception: an accepted, supported business platform outside of the niche markets that Apple currently serves. This also has benefits to the wider community as Apple has already demonstrated its’ willingness to contribute to existing projects and spawn new projects that can then be adopted on compatible platforms, such as BSDs and Linux distributions.
I have read a number of stories of outfits in the scientific and multimedia markets being able to replace two computers (PC w/ Windows + PC w/ UNIX-derviative) with one (Macintosh w/ MacOS X), since the latter can run their BSD/Linux or X-based applications as well as many “standard” business applications required for administration and collaboration. I have no double that Fink played a key role in this.
I can also attest that Fink has enhanced my work as well, since I have a fully-built KDE with many applications, a number of which fill in gaps in the MacOS X software market. By combining the two, I have a full solution for all my requirements except gaming (which I have on a separate, Windows-based computer).
So, for myself, as for thousands of other Macintosh users out there, some of whom are not using Fink, but will in the future and will be glad that it is there, I want to say a big thank-you to the Fink team, and also to the FinkCommander team. Your efforts have helped the Macintosh platform remain a viable choice in markets where the odds are all stacked heavily in favor of particular players, and where the pundits have more than once left the Macintosh for dead.
As a FreeBSD user and a FreeBSD ports user (OS X), I’d highly recommend Fink to those who love to tweak…, endlessly…, continually, ceaselessly, unendingly, interminably…; I think you get the idea. If you do not mind the eternally tiring tweaking required just to get most apps and libraries in order, endless trips to the terminal to “correct” inherent glitches, incessant error messages in the console, then Fink is for you.
Is opendarwin’s darwin ports a competing project or a parallel one?
http://www.opendarwin.org/projects/darwinports/
Well with Apple’s X11 ctrl-c and control-v seem to cut and paste just fine.
Mind you, I only use fink for GIMP and PAN, so it may be a GNOME thing.
This is application specific. It will not, for example, work with an xterm.
From the article.
” Fink uses Debian tools like dpkg and apt-get to provide powerful binary package management “
I asked myself the same question a while ago when DarwinPorts was announced last year. Short answer, Fink is GNU-based – DarwinPorts is BSD-based. Both kids play nice in the sandbox known as your Mac. Package maintainers from both ‘Distros’ work together to get past difficulties in porting to Darwin/OSX, and that’s where the collaboration is important. Some maintainers commit to both projects, actually.
I think this post/thread best explains it: http://www.omnigroup.com/mailman/archive/macosx-talk/2002-November/…
D.
Aliasing Ctrl-V (Paste clipboard) to middle click (Paste current text selection) would be like someone connecting the brake and clutch lines together in your car “Well, it’s pretty much the same sort of thing, anyway I usually can’t remember the difference anyway”. Argh!
xterm doesn’t have a way to paste the clipboard contents. It doesn’t on MacOS/ Fink and it doesn’t on FreeBSD, or Linux or on any system. If you want such a feature you probably won’t get it, but you could try asking the current xterm maintainer.
What xterm does have, as do almost all text entry type widgets, is a way to paste the current selection, that is, the last bit of text you highlighted. This is the NOT the same thing as the clipboard, it’s just a power user feature and you don’t NEED to learn about it. The vast majority of apps have ordinary Edit+Cut/Copy/Paste menu as well as this power user feature. That includes all the modern xterm-like Terminal emulators included with GNOME and KDE and so on.
[And Ctrl-V would be a particularly stupid thing to alias in an xterm because that Ctrl-sequence is needed…]
The description linked from that Fink interview is wrong too. Cut buffers are a 1980s legacy. They’re obsolete. If Apple and/or XFree engineers are trying to connect Apple’s clipboard to the X11 clipboard via Cut buffers then someone needs to show them the “new features” of X11R6 (how old is that now?)
Hopefully the poor understanding is restricted to the guy who wrote the FAQ. If not I’ll take a look tomorrow when I can get at an OS X machine and start filing some bugs <sigh>
“Get a life” with the real Debian. Cheers fink team.
http://www.debian.org/
I agree I prefer to work with Debian for most stuff.
However there’s a couple of issues that force me to work in MacOS X quite often:
– Proprietay apps you need to use for work. There’s not that many in my case, but Flash MX is one of em.
– Hardware that does thesame: with the new powerbooks with Nvidia hardware, there is no hw-accelerated 3D for Linux+PowerPC. That’s a damn shame.
– Some of the MacOSX goodness (iCal I’m quite fond of, and there’s other stuff too)
For those reasons, I really wish Fink was Debian/[Darwin|OSX] – a straight Debian Port that lives together with MacOSX. The major advantage would be that a lot of the work would be already done by the Debian community (a lot of the packages require nothing more than a recompile on OSX)
I’d assume because of the big differences there would neet to be some glue, but considering Debian is seriously working on a Debian/BSD port, I’d assume the problems are solvable. And long term, more realistic considering the 12000 packages that are in Debian right now…
I already read this article a week ago. You can also get all these packages in an easy to install format on cd-rom from BSD Mall. It’s called UNIX Utilities for OS X. I bought it and plan to install it on my eMac when I get it – the eMac- in a few days.
Thanks for posting the link re Darwinports/Fink. Clears up some confusion.