Another one of those "is-is not" debates.
Those of us in the scientific community coming from *NIX/Linux have lots
of home grown codes, plus generic ancillary routines, that we take for
granted. We are attempting to use the computer as a tool to get a job
done as quickly and painlessly as possible, ie, we want the computer to
help us do our job, not be our job. Hence, being able to "port" code via
fink to run under OS X makes OS X much more useable to the scientific
community. Without fink, the viability of OS X in the scientific
community would be reduced, at least until someone ported the ancillary
routines that we take for granted as native apps.
I will use a related example from where I work. We have someone who is
trying to convince upper management that Windows is a great replacement
for UNIX workstations because it is so much cheaper and everything you
can do on UNIX you can do on Windows. Except once you have lost all of
the UNIX tools, you are left trying to manipulate all of your data with
Excel. I have seen people spend days trying to do something in Windows
that would have taken 5 minutes on a UNIX box. In a related manner, fink
brings a much richer toolset to OS X than the default OS load. Remember
the early versions of OS X, where things like python were not included?
Apple cannot -- and should not -- provide all the tools available in fink
as part of the OS load.
If fink works for you (it has for me), great. If not, why be so bothered
that other folk find it useful?
Don Jones
>On Jan 26, 2004, at 2:59 PM, Sean Ahern wrote:
>
>> Rich Cook wrote:
>>> Hmmm... How is placing a useful library in a standard location like
>>> /usr/local/lib "pollution?"
>>
>> When you install into /usr/local, and Apple installs into /usr/local,
>> you
>> can never be sure where a particular library comes from. And if
>> everyone
>> installs into /usr/local, what if two packages want two different
>> versions
>> of a library? You start running into "DLL Hell", to use a Windows
>> term.
>>
>> And also because Apple can blow away anything in /usr/local at any
>> time they
>> like with one of their system updates.
>
>Apple never installs into /usr/local, presumably they will install into
>/. In fact, I believe that if you check right now, you will see that
>/usr/local/ doesn't exist on OS X unless you create it! So there is no
>collision with system libs/binaries/etc.
>
>>
>>> It has to be put somewhere, and although it does make it easier to
>>> automate their maintenance if they are segregated into Frameworks,
>>> having
>>> this great Apple scheme to put libraries in unusual paths with unusual
>>> compiler flags to access them is a bother to people who just want to
>>> port
>>> to OS X codes that already run on Unix.
>>
>> Yes and no. There are codes that I know of for Linux, SGI, etc. that
>> carry
>> around their own copy of things like Inventor, JPEG, HDF, VTK, etc. so
>> that
>> they always know they can rely on their dependencies being around.
>> This is
>> the "UNIX" solution to Frameworks.
>
>And what's wrong with it? It solves a certain class of problems that
>would exist, frameworks or not.
>
>>> The only way for Apple to win this battle is to make it easy to do it
>>> the
>>> "right" way and the "wrong" way at the same time.
>>
>> I agree. And I think that's the situation we're in. You are able to
>> the
>> "carry around your own library" method both in the "standard" way and
>> the
>> Framework way. You can install DarwinPorts, fink, both, or neither.
>> You
>> can install into /usr/local, or wherever you like. I think the
>> situation
>> we're in is nice, from a developer's point of view, because you can do
>> pretty much anything you like. The downside is that there isn't "one
>> way to
>> do it", which means you can't rely on how someone else might do it.
>
>I'd say it's a good tradeoff, and I agree this is the current
>situation. Frameworks freaks, go for it. /usr/localites, live it up!
>
>--
>Richard Cook
>Lawrence Livermore National Laboratory
>Bldg-451 Rm-2043, Mail Stop L-561
>7000 East Avenue, Livermore, CA, 94550, USA
>phone (925) 423-9605 (work) fax (925) 423-8704
>---
>Information Management & Graphics Grp., Services & Development Div.,
>Integrated Computing & Communications Dept.
>(opinions expressed herein are mine and not those of LLNL)
>_______________________________________________
>scitech mailing list | email@hidden
>Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/
scitech
>Do not post admin requests to the list. They will be ignored.
_______________________________________________
scitech mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/scitech
Do not post admin requests to the list. They will be ignored.
