New Fink Binary Distribution 0.5.2 31
dmalloc writes "The Fink Project community and contributors announced the availability of the Fink Binary Distribution 0.5.2, which adds binaries for KDE 3.1, Koffice 1.2.1, and Kdevelop 3.0a3, new documentation/manuals, and improved support for Apple's X11 Server along with speed improvements to fink itself. Download instructions are on the Fink site."
Include More Info (Score:5, Interesting)
Especially when the server is Slashdotted (admittedly not the case here) and the rest of us are wondering: "should I care about this?"
Re:Include More Info (Score:5, Informative)
Re:Include More Info (Score:1, Insightful)
But updating Fink for the purpose of upgrading Koffice is something I can not comprehend. I haven't been able to make Koffice useful for anything other than the simplest one page letters. Th
Re:Include More Info (Score:1, Informative)
Well, Power Macs and PowerBooks don't ship with AppleWorks, so the first half of that claim is incorrect.
As for the second part - have you used AppleWorks on OS X? It's totally horrible, and virtually hasn't seen an upgrade since 10.0 was released!
Re:Include More Info (Score:2)
AppleWorks is...fairly weak. But the "draw" component has saved my backside on a couple of occasions. If memory serves, the AppleWorks folks were originally the MacDraw people, and I think that's about the only thing that I like about the current package.
KOffice: glad to have you on board! (Score:5, Insightful)
Everybody benefits: another title for the Mac, it's free (as in beer), expanded KOffice user base, yet another reason for Mac users to use Fink, freedom of choice.....
It's an exciting time to be a Mac user. I honestly would not be surprised to hear that applications are becoming available to Mac users faster than new apps are being developed for Windows. In other words, the list of Mac-compatible desktop software titles may be growing at a faster rate than the list of Windows titles.
Upgrade Instructions (Score:5, Informative)
Info yes, Freshmeat no (Score:4, Insightful)
But I don't think this kind of announcement duplicates anything at Freshmeat. (What's Freshmeat?) That site is for people who already run specific platforms, and are curious to see what's being developed for those platforms. But you don't have to be a OS X enthusiast to be interested in the doings of the Fink team.
Fink and Mcafee virus (Score:2, Interesting)
Coes anyone know if the conflict is fixed?
Re:Fink and Mcafee virus (Score:3, Informative)
This is not Fink's fault, and there is *nothing* they can do to fix it. Want to complain? E-mail McAfee.
Re:FIXED! (Score:2, Informative)
Re:Fink and Mcafee virus (Score:4, Interesting)
The gist of the situation:
McAfee used Fink during the development of Virex, and as such, if you're using Virex and try to install Fink--well, you can't install Fink, so I won't finish that thought.
It's not a problem with Fink. Virex is causing the problem, and unfortunately, until McAfee get their act together, Fink and Virex can't be installed on the same machine.
Fink, when instaled, looks for
Check out this thread [macosxhints.com] for more discussion.
Re:Fink and Mcafee virus (Score:1)
Yeah, but has anyone ever had a virus on OS X? Do they even exist?
I'd take Fink over Virex any day.
Re:Fink and Mcafee virus (Score:5, Informative)
to fix a messed up fink from 7.2 just:
fink reinstall openssl-shlibs dlcompat-shlibs curl-ssl-shlibs
and you're set to go.
Re:Fink and Mcafee virus (Score:2, Informative)
2003-04-16: Virex problem resolved
McAfee has released Virex 7.2.1, which no longer overwrites the main Fink directory
Early reports indicate that upgrading Virex from 7.2 to 7.2.1 still leaves some problems however. If you upgrade Virex with Fink not installed, and subsequently wish to install Fink, you will need to delete the
Re:Fink and Mcafee virus (Score:1)
Don't use if your default shell is /bin/zsh (Score:4, Informative)
Re:Don't use if your default shell is /bin/zsh (Score:4, Informative)
Re:Don't use if your default shell is /bin/zsh (Score:4, Interesting)
I've heard this a number of times, mostly from an old Solaris admin I used to work with. Yet, in 8 or so years of administering all kinds of *nix boxes, I have yet to run into a single problem that was caused by changing root's shell. I can see being careful about it, but then again, you should be careful about everything you do as root. It seems to me that anything that relies on root having a specific shell is inherently broken software to begin with, and shouldn't be run as root at all.
I've administered everything from Solaris to FreeBSD to Linux and now Mac OS X, and I've used many shells for root among them, including ksh, zsh, csh, and bash. The day I'm forced to use a particular shell for root is the day I find a new operating system.
Re:Don't use if your default shell is /bin/zsh (Score:3, Informative)
Why ask why?
Seriously, there are many absolutely critical portions of the system that are simple (and not so simple) shell scripts, and these are only guaranteed/tested to work with the *default* shell. Messing with root's shell is only asking for trouble. Really.
Now, knowing this, if you still fell compelled to go and change it, by all means, go for it, but don't go complaining about things breaking as a result of your modification.
Re:Don't use if your default shell is /bin/zsh (Score:2)
Well, in that case, the script should be marked executable and the #! line should contain the proper shell to use. Or, perhaps just call the shell directly with the script as its argument? What's so hard about that?
My whole point was that if changing t
Re:Don't use if your default shell is /bin/zsh (Score:1)
It is actually a bug in zsh, since it seems to spawn and internal process to do some globs and that leads to a wrongly escaped string asfaiu
Perl and Fink (Score:3, Interesting)
For starters, if you upgrade Fink's version of perl, then all the old perl libraries will be binary incompatible. (And here, Apache + mod_perl counts as a "library" since it won't boot.)
Do I go and rebuild all my libraries? Or rebuild the default install of perl? Or muck about with @INC? I could do that... but it defeats the purpose of Fink.
Maybe it's safer to have multiple versions, and I can certainly uninstall Fink very easily, but it still seems to be a bit of a mess.
Even if you avoid the package manager and build everything manually Fink still saves a huge amount of time because all the annoying fixes are already there. But it's disappointing that we're not really that much better than Windows when it comes to simple issues like binary compatibility. (Honestly, how is it any different than DLL-hell?)
I'm *really* hoping that in the future, Apple is going to provide upgraded facilities for package management. My dream is that one day we'll have a utility that will analyze our system and all the little customizations we've made and get a full analysis, and the ability to easily turn things on and off... just like good old Extensions Manager, but universal.
Re:Perl and Fink (Score:1, Informative)
Simply make sure the
On the other hand, why did you install multiple perls by the way?
I have only one perl installed, Apple's Perl, and everything works fine. One X11, Apple's X11, and everything works fine. One teTeX, the one that came with some OSX native LaTeX editing apps I use, and everything work
Re:Perl and Fink (Score:1)
I also like the IO filters and all that nice stuff in 5.8.
Probably more important than the bleeding edge is being able to run older perl scripts. There are still some perl 4 scripts out there, and I'm not sure I'm even familiar enough with stuff like globs to be able to get them running in perl 5.
You really can't assume that because something ran on an older interpreter that it will run on a newer one. You
Re:Perl and Fink (Score:1)
Maybe I should file a bug report on this, because I'd *like* to use fink's
So what I've done lately is just blast Apple's Perl (sudo rm -rf {/System/,/}Library/Perl) and build perl from scrat