Slashdot Mirror


New Fink Binary Distribution 0.5.2

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."

5 of 31 comments (clear)

  1. Include More Info by avalys · · Score: 4, Interesting

    If we're going to make Slashdot into Freshmeat (which is fine with me, to a point), submitters should at least include information on what the program actually does!

    Especially when the server is Slashdotted (admittedly not the case here) and the rest of us are wondering: "should I care about this?"

    --
    This space intentionally left blank.
  2. Fink and Mcafee virus by nilepoc · · Score: 2, Interesting

    I have not been following fink that closely, but I remember a conflict exixting between Fink and Mcafee virus protection. (the service that comes with .mac) I have forgone updating my virus coverage as a result. Because I want to try fink out.

    Coes anyone know if the conflict is fixed?

    1. Re:Fink and Mcafee virus by Mikey-San · · Score: 3, 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 /sw, and if it finds it, it doesn't install. This might look like Fink's problem, but in reality, it's Fink trying its absolute best not to do anything that might harm your machine. (They use /sw instead of other binary directories for the same reason.) Much applause to the Fink team for these conventions, I say. Developers looking out for users is always a good thing, even when some might think they [the developers] are being overly cautious.


      Check out this thread for more discussion.

      --
      Mikey-San
      Karma: +Eleventy billion (mostly affected by watching Celebrity Jeopardy)
  3. Re:Don't use if your default shell is /bin/zsh by ZxCv · · Score: 3, Interesting

    Why?

    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.

    --

    Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse;
  4. Perl and Fink by sco08y · · Score: 3, Interesting

    One problem I have is getting perl and Fink to behave. I don't think this is Fink's fault, but I've checked the site and haven't seen a very good solution.

    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.