TeamTalk is a perfect example of this, it will not work on Mac, but will work perfectly on the Darkside. LOL.
Sent from my iPhone > On Dec 11, 2013, at 4:15 PM, Travis Siegel <tsie...@softcon.com> wrote: > > <rant mode on> > I absolutely hate macports. > I refuse to use anything in the macports library. > I strongly recommend others avoid the macports applications as well. > </rant off> > > Now, a little background and explanation. > Most of the macports apps I've seen would take a whole 30 minutes or so to > port properly to the mac. But, because folks are too lazy to do a proper > port, instead they throw in an environment that messes with your paths, > environment shell settings, and library search paths, all to save themselves > from going through the code os some programs and changing library call here, > an include file there, and rewriting a line or two of c/c++ code to adhere to > newer gcc compiler versions. All of which needs to be done anyway eventually > if the program is going to continue running on newer systems as they upgrade > themselves with newer releases of other unix like operating systems. > The whole macports thing is a nice idea, but one of the poorest > implementations I've ever seen of a software emulation layer (which it really > isn't supposed to be, but it gets used as such anyway). > I've taken programs (such as pine and lynx) that were in the macports > library, and compiled osx native versions of the same programs with very > little modifications, and there's no reason it couldn't be done by the > maintainers of said packages if so desired. The problem is, they don't want > to do it, and most folks don't know enough to do the job, so we wind up with > a stop gap measure like macports, and for some unknown reason, it becomes the > defacto distribution for all things mac in the terminal world (go figure). > Sometimes, it's possible to take the same exact source code used by the > macports version, and recompile the source in native osx, and it works w/o > any changes at all. Admittedly, those occasions are few, but it just goes to > show how needless the macports app library truly is. > > Now, with all that said, if you truly need the macports environment, then by > all means, use it. But I won't be caught with it on my system, not after it > truly hosed my system the last time I tried using it several years ago. I > now ignore, avoid, and actively discourage all things macports. If you have > the development tools installed, compiling your own versions of programs is > generally as easy as: > > ./configure > make > make install > > Of course, this is after changing to the folder containing the source code of > the program in question, and performing the final step as root, which is > usually done via the sudo command, but still, you get the point. > > Now, I'm specifically talking about pure terminal apps here, not XWindows > apps, or those using quartz, or quicktime libs for graphical output. Those > have their own set of difficulties, and I don't generally bother with such > apps, so their nonfunctionality doesn't affect me. :) > > But, to make a long rant short, if you wish to try an opensource app, simply > download the source, and have a whack at compiling it in terminal. Most of > the time it'll work without any changes, but if changes are necessary, > they're generally simple ones that an experienced unix coder can make in a > relatively short period of time. If you're not an experienced unix coder, it > will take you longer, but it can still be done with enough perseverance. > It's not complicated or difficult, merely time consuming looking up the > library versions, and tracking include files. > Of course, sometimes, it's a *lot* more complicated than that, but if that's > the case, then it won't make much difference if you're compiling for macports > or in native mode, since either one is equally likely not to work. :) > Anyway, that's my soapbox speech for the week, hope it helps someone. > And, if not, then at least forewarned is forearmed. > <--- Mac Access At Mac Access Dot Net ---> > > To reply to this post, please address your message to > mac-access@mac-access.net > > You can find an archive of all messages posted to the Mac-Access forum at > either the list's own dedicated web archive: > <http://mail.tft-bbs.co.uk/pipermail/mac-access/index.html> > or at the public Mail Archive: > <http://www.mail-archive.com/mac-access@mac-access.net/>. > Subscribe to the list's RSS feed from: > <http://www.mail-archive.com/mac-access@mac-access.net/maillist.xml> > > As the Mac Access Dot Net administrators, we do our very best to ensure that > the Mac-Access E-Mal list remains malware, spyware, Trojan, virus and > worm-free. However, this should in no way replace your own security > strategy. We assume neither liability nor responsibility should something > unpredictable happen. > > Please remember to update your membership preferences periodically by > visiting the list website at: > <http://mail.tft-bbs.co.uk/mailman/listinfo/mac-access/options/> > <--- Mac Access At Mac Access Dot Net ---> To reply to this post, please address your message to mac-access@mac-access.net You can find an archive of all messages posted to the Mac-Access forum at either the list's own dedicated web archive: <http://mail.tft-bbs.co.uk/pipermail/mac-access/index.html> or at the public Mail Archive: <http://www.mail-archive.com/mac-access@mac-access.net/>. Subscribe to the list's RSS feed from: <http://www.mail-archive.com/mac-access@mac-access.net/maillist.xml> As the Mac Access Dot Net administrators, we do our very best to ensure that the Mac-Access E-Mal list remains malware, spyware, Trojan, virus and worm-free. However, this should in no way replace your own security strategy. We assume neither liability nor responsibility should something unpredictable happen. Please remember to update your membership preferences periodically by visiting the list website at: <http://mail.tft-bbs.co.uk/mailman/listinfo/mac-access/options/>
