Slashdot Mirror

← Back to Stories (view on slashdot.org)

Mono Adds Mac OS X Package

Posted by timothy on from the for-your-conversion dept.

Good news for those of you who've went through the pain of trying to get Mono installed on Mac OS X: the team has quietly added a Mac OS X package. If you previously installed to /usr/local, however, be aware that the packaged version installs to /opt/local and adjust any paths accordingly. The Beta-1 Windows installer has also been fixed; download it here.

53 comments

  1. Aha! by byolinux · · Score: 0

    This will be very useful. I was actually going to install Mono tonight, and now it'll be a whole lot easier..

    Now all we need is Cocoa#

    Thanks Ximian!

    --
    Join the Free Software Foundation
    1. Re:Aha! by hak1du · · Score: 1

      Now all we need is Cocoa#

      Writing a Cocoa interface isn't hard to do; all it takes is a volunteer.

      But do you actually believe you would be programming in Cocoa using Mono?

    2. Re:Aha! by baryon351 · · Score: 1

      I'm fascinated with these different packaging types. One single "distro" of OSX, and each package seems to have multiple packages... where the opposite seems to happen with Linux. Just one package type for each of many distros.

      We can't make it easy on ourselves, can we :D

      Still, it's a concern. along with fink packages, independent packages installed in /opt, OSX style packages like gimp2 being put in /Applications (where the OS is built to handle them)... any others coming to light, to make things more complex?

    3. Re:Aha! by torpor · · Score: 1

      I *HATE* it that they have forced an '/opt' usage in OSX.

      THERE IS -NO- /opt IN OSX! FOR A REASON!!

      Godamnit, I'd just started to get over those fink morons and their /sw tree, now we gotta put up with an /opt.

      "ln -s ~/opt /opt" ... there, that oughta fix those dufus's...

      --
      ; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
    4. Re:Aha! by Alrescha · · Score: 3, Insightful

      "Godamnit, I'd just started to get over those fink morons and their /sw tree, now we gotta put up with an /opt."

      Where do you think it should go?

      It is a long-standing philisophy in some software development circles that you never install your software into system directories (/bin, /usr). If you're adding something yourself it goes into /usr/local. /opt was used for other software providers stuff.

      I think /opt and /sw are much better than installing into system-provided directories (which is an insane practice).

      A.

      --
      ...bringing you cynical quips since 1998
    5. Re:Aha! by byolinux · · Score: 1

      I don't really know. I'm just having this wonderful period where I can finally dump Visual Basic and play with nicer things.

      I was so happy when my CurrencyConverter.app compiled.

      Day job is becoming C# and if I can write all my stuff in Something# then it'd be quite nice.

      --
      Join the Free Software Foundation
    6. Re:Aha! by AndyElf · · Score: 1

      How about putting it into /usr/local/ as *BSDs do?

      Read hier(1).

      --

      --AP
    7. Re:Aha! by squiggleslash · · Score: 1

      In Mac OS X, the bulk ought to go whereever the user chooses (usually in /Applications), except for the genuinely central stuff (shared libraries, etc) which should go in one of the appropriate directories in /Library.

      --
      You are not alone. This is not normal. None of this is normal.
    8. Re:Aha! by b-baggins · · Score: 1

      It should go where the OS X file structure guidelines dictates it should go, or don't bother making an OS X package.

      --
      You can tell a great deal about the character of a man by observing those who hate him.
    9. Re:Aha! by hak1du · · Score: 1

      Well, Gtk# works well on Windows and Linux and will be available on Macintosh soon (if it's not already included in the beta, I haven't checked yet). Macintosh currently has Gtk/X11, but if Apple keeps being a viable platform at all, you are going to see a Quartz version of Gtk.

    10. Re:Aha! by Anonymous Coward · · Score: 0

      We're talking about unix-level stuff here. It would be royally stupid to put anything without a GUI in /Applications, that would be un-Mac-like. Nobody ever said that UNIX was Mac-like.

    11. Re:Aha! by squiggleslash · · Score: 1

      Your point being what exactly? Are you saying that because many of the tools probably shouldn't be in /Applications, the user shouldn't be allowed to determine where they go?

      --
      You are not alone. This is not normal. None of this is normal.
    12. Re:Aha! by torpor · · Score: 1

      Where do you think it should go?

      Let the USER decide. If you can't build a package that understands its own paths, and is re-locatable to any location, then its -not- finished, and you shouldn't release it.

      Fixed-path installs are brain-dead and only come about as the result of laziness, utter. The user has a ~/Library, a ~/Applications - both of these directories exist, are useful, and will survive backups made by your average user of their home directory. /opt is -not- something that someone is going to remember to include in their Toast-based backups easily enough ...

      OSX is a Unix for Users. Use it that way!

      --
      ; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
    13. Re:Aha! by Smurf · · Score: 2, Interesting
      If you can't build a package that understands its own paths, and is re-locatable to any location, then its -not- finished, and you shouldn't release it.
      I agree that all packages should be re-locatable. Unfortunately there are lots of *excellent* Unix/Linux and (gasp) Windows applications that are path dependent. I agree that they should be fixed when porting them to OS X, but meanwhile I prefer to have them even if they are "the result of laziness".

      OSX is a Unix for Users. Use it that way!
      Yes, but please don't break Unix in the process. Linking /proc to ~/proc is a terrible idea. MacOS X is finally a good multiuser system. Finally, all the members of a family or a workgroup can have their files in their own accounts without creating chaos and endangering the system. That's the goal of the users home directories.

      By linking proc to ~/proc, you will limit the use of Mono (or whatever is installed in /proc) to one user (unless you duplicate it in every user account). Programs that should be available to all users should NOT be installed in a particular user's directory. That's a terrible practice. If you are so convinced in thinking different(ly), link it to /Users/Share/proc, but then again you have an absolute path.

      Whose "utter"?

    14. Re:Aha! by code+shady · · Score: 1

      It should go in /Library.

      NOT /System/Library.

      of course, if you just want it to play around with on yoru own, you can just go for ~/Library.

      I, for one, have darwinports set up to use /Library/Ports

      --
      Look out honey cause I'm usin' technology
      Ain't got time to make no apologies
  2. Usability? by polyp2000 · · Score: 2

    Is Mono actually in a state where it can be deployed?

    --
    Electronic Music Made Using Linux http://soundcloud.com/polyp
    1. Re:Usability? by bay43270 · · Score: 4, Informative

      It's in it's first beta. 1.0 is due at the end of June. Here's the story. And the roadmap

    2. Re:Usability? by hak1du · · Score: 1

      It's called a "Beta1" release, which should tell you roughly what state it is actually in.

    3. Re:Usability? by Anonymous Coward · · Score: 0

      You're probably talking to someone using Firefox 0.8...

      Most Linux people I know have little regard for the beta-ness of software, as long as it "works".

    4. Re:Usability? by Anonymous Coward · · Score: 0

      That's what "beta" means: it's feature complete and has been tested extensively inside the development group and company. Now we are sending it out to users to get bug reports from the field for usages we didn't anticipate.

  3. DeDRMS by sameerd · · Score: 1

    Any one tried compiling DeDRMS with this? Any success?

    1. Re:DeDRMS by byolinux · · Score: 3, Informative

      Miguel has tried it albeit on GNU/Linux.

      --
      Join the Free Software Foundation
    2. Re:DeDRMS by fourfoot · · Score: 1

      I got it to compile just fine. It seemed to work, but I couldn't really use it because I don't have an iPod to get my key from. It just gave me an error about not being able to find a user key in ~/.drms.

    3. Re:DeDRMS by Anonymous Coward · · Score: 0

      You don't need an iPod to get user keys. I hate that the developers keep saying that you do. Keys from a Windows machine can be copied over just fine. They keep saying you need an iPod to make it seem more legit, somehow.

      Also, they don't mention that not every key works for every file. You have to play all the tracks you want to decrypt at least once, and then copy ALL of the generated keys.

    4. Re:DeDRMS by Anonymous Coward · · Score: 0

      Just before Apple broke the protection, I compiled Mono with DarwinPorts, grabbed my key from a VirtualPC installation with authorized iTunes and VLC, copied the key over and used DeDRMS and Mono to de-drm my music. It worked beautifully until iTunes 4.5.

  4. Is .Net on OS X a Good Thing? by mr_tap · · Score: 5, Interesting

    I am sure that others have expressed this view before, but is this necessarily going to be A Good Thing? Isn't this going to lead to developers less likely to have special OS X ports that take advantage of specific OS X features?

    Don't mean to be a whiner of course :)

    1. Re:Is .Net on OS X a Good Thing? by bay43270 · · Score: 3, Insightful

      I am sure that others have expressed this view before, but is this necessarily going to be A Good Thing? Isn't this going to lead to developers less likely to have special OS X ports that take advantage of specific OS X features?

      I think this is a great thing for OSX. OSX support will lead to full featured mono cocoa bindings. This will allow mono and .net developers to port the core logic of thier applications to the mac and still take advantage of OSX facilities for the UI and IO.

      Sure, there will always be the lazy programmers who just use mono's winforms implementation to move a windows app to the mac (like all those ugly X11 apps being moved to the mac today). In .net, those winforms implementations can be treated as a stop-gap until a new UI can be written for the app in cocoa#.

      I think mono is going to draw out a lot of windows programmers who always wanted to write for the mac or linux, but never wanted to learn the languages (Objective-C or C). Now they can keep working in C#, VB, or whatever. They just pickup a new API (cocoa# or gtk#) and start coding 'native' mac or linux apps.

    2. Re:Is .Net on OS X a Good Thing? by JimRay · · Score: 3, Insightful

      I've wondered this myself, especially given the "embrace and extend" mentality of Microsoft's past, but ultimatley I'm convinced that Mono on OS X is a good thing for the same reason Perl or Apache on OS X is a good thing. Like it or not, .Net seems not to suck. Like it or not, there seems to be a burgeoning open source community embracing .Net.

      For instance, I'm an Actionscript developer. A project I've taken great interest in is ASDocGen, which aims to bring JavaDoc-like functionality to Actionscript. This project is written in C# with the express purpose of being multi-platform via Mono.

      In the end, it makes OS X a richer platform to develop on. Rather than be limited to a few tools to do my job as a web developer, I have a vast array of options, from open source web servers to GUI text editors to Photoshop -- I can even open Word docs that clients send me without a problem. Having another tool in my aresenal only makes me a better developer.

      Apple has a very strong, committed developer base. They will continue to push great products for OS X. The ability to run some .Net apps will only make OS X better.

      --
      My other computer is your Windows box
    3. Re:Is .Net on OS X a Good Thing? by johnnliu · · Score: 1

      Is it better to have software with specific OS X features, or no software at all?

      If you have to write a software to suit customers on both Windows and Mac platforms, and you hate Java (which I do, for reasons of my own and I won't discuss here), mono for OS X is definitely a good thing.

  5. Serious question by revscat · · Score: 1, Troll

    Not trolling, but an honest question: Why should I give a tinker's cuss? Judging by the flood of comments this story has generated, I'm hardly alone in my apathy.

    1. Re:Serious question by squiggleslash · · Score: 1
      Well, essentially it's because Mac users can now run the great selection of software that runs under .NET.

      Ok, there really isn't any. Ok, well, what about the fact that Mono allows you to make your Mac work according to the latest Microsoft technologies and design practices? Yeah, that's it! This is something Mac users don't have at the moment, and boy I bet they're glad they're a step closer to having PCs that work and operate the same as everyone else's.

      OK, perhaps not.

      As a software developer, I may have found it useful if we weren't a Java shop. But we're a Java shop, and there are no plans to migrate to .NET.

      --
      You are not alone. This is not normal. None of this is normal.
  6. Explanation of /opt/local and /usr/local by Anonymous Coward · · Score: 1, Interesting

    Would someone who isn't feeling too cranky explain the usage of /opt/local versus /usr/local please? I would like to understand the differences in the organizational concepts. As it is now, I just have irritation at the software that installs in the location I am less "familiar" with. Thanks.

    1. Re:Explanation of /opt/local and /usr/local by frankie · · Score: 4, Informative
      /usr/local is a commonly used place in many unixish OSes, but Apple likes to think different. This means that whenever you install a Mac upgrade (or even certain updates) there is a possibility that any non-Apple additions to /usr (also /dev, /bin, /var, /etc) will be overwritten by Apple.

      Therefore, the safe-but-annoying choice is to put your 3rd party stuff somewhere else. For example, Fink defaults to the (previously nonexistent) /sw directory. Likewise, /opt does not exist in OSX (unless you install this Mono package)

    2. Re:Explanation of /opt/local and /usr/local by sleepypants · · Score: 2, Interesting
      Back in my slackware linux days, I always treated /opt as the location to install whole application trees, kind of like the "Program Files" directory in Windows. So if I download Mozilla, which untars into a "Mozilla-1.6" directory or something, I put it into /opt.

      Of course, if I was using slackware's 'official' package of Mozilla, it would probably put all the binaries in /usr/bin, all the libraries in /usr/lib and so on. But for downloading and trying out nightly builds or betas, I would always use /opt.

      /usr/local mirrors the structure of /usr (i.e. has bin,lib,share,src,etc.) so it was the place to install software that followed that structure.

      --
      I am Jack's witty signature line
    3. Re:Explanation of /opt/local and /usr/local by squiggleslash · · Score: 1

      Apple could do with documenting a little better the purpose of /Library.

      --
      You are not alone. This is not normal. None of this is normal.
    4. Re:Explanation of /opt/local and /usr/local by hawaiian717 · · Score: 1

      DarwinPorts also uses /opt.

      --
      End of Line.
    5. Re:Explanation of /opt/local and /usr/local by goon+america · · Score: 1

      Erm, I've upgraded a lot of times and I've never had anything overwritten in /usr/local

    6. Re:Explanation of /opt/local and /usr/local by Anonymous Coward · · Score: 1, Informative

      Almost, but not quite. /usr, /bin, etc. are part of the distribution. Anything placed in there could be overwritten with an OS update. This is entirely true with every *nix update. Now, if Apple view Darwin as "the OS" and all of their software as add-ons, then they would be correct in installing things in /usr/local. A lot of *nix distributions do this with things like curl, OpenSSL, lynx, etc. The reason fink uses a second alternative directory is because an Apple distribution already uses the first "standard" add-on location. /opt is just the same idea as /usr/local, but for some reason, some *nix distributions (IIRC, SunOS, SCO and hp-ux) decided to use that instead of /usr/local.

    7. Re:Explanation of /opt/local and /usr/local by b-baggins · · Score: 1

      They just made the mistake of thinking the word Library kind of self-documented its purpose. They forgot to realize that they're dealing with people who think vi is intuitive and makes sense.

      --
      You can tell a great deal about the character of a man by observing those who hate him.
    8. Re:Explanation of /opt/local and /usr/local by prockcore · · Score: 1

      They just made the mistake of thinking the word Library kind of self-documented its purpose.

      Oh, so it's the place where OSX stores all of its books?

    9. Re:Explanation of /opt/local and /usr/local by EccentricAnomaly · · Score: 1

      /opt is old school unix for 'optional'. /usr/local is for stuff that isn't part of the standard vendor's install. On OS X perl is in /usr/bin/ because it is provided by Apple. Apple shouldn't put things in /usr/local/, only the local SA should put stuff in /usr/local/.

      So why do installers like DarwinPorts put stuff in /opt/? So that you can wipe out /opt without breaking everything on your system. If you wipe out /usr you would be in pain, but you should be able to wipe out /opt without pain.

      --
      There are 10 types of people in this world, those who can count in binary and those who can't.
    10. Re:Explanation of /opt/local and /usr/local by trouser · · Score: 1

      that would be because /usr/local doesn't even exist in a standard OS X install. If they choose to add it in future rest assured whatever you've already installed there will probably be overwritten

      --
      Now wash your hands.
    11. Re:Explanation of /opt/local and /usr/local by joeyGibson · · Score: 1

      They forgot to realize that they're dealing with people who think vi is intuitive and makes sense

      Hey pal, them's fighting words...

  7. Finally. . .iFolder by Aiua · · Score: 4, Interesting

    I am excited about this quiet release. First, it opens up the possibility of compiling Novell's OSS iFolder on Mac OS X. Second, 60% of the computers in my company run Mac OS X, allowing for greater compatability between the remaining 40%. Third (and relating to the first), there was a recent evaluation of deploying iFolder company-wide, and the missing Mac OS X support was a critical issue. Now, the chances of the deployment happening have increased with the relase of Mono for Mac OS X. This should be great news for Apple fans.

    1. Re:Finally. . .iFolder by absurdhero · · Score: 1

      Portable.NET has been avaliable on the Mac for over a year now and even has support for SWF (the GUI library) on mac. Good to hear that Mono is also getting thereselves over to mac. Now if only the JIT would get written for it :)

  8. Darwinports by Anonymous Coward · · Score: 0

    As far as I'm aware mono has been available for a while under darwinports.

    mono devel/mono 0.91 Implementation of the .NET Development Framework

    mod_mono www/mod_mono 0.7 an Apache plug-in for hosting the Mono System.Web classes

  9. developer by undef24 · · Score: 1

    I'm a .NET developer who owns a powerbook. Can I now develop completely on my machine and simply copy my binaries to a windows machine?

    1. Re:developer by OmniVector · · Score: 2, Informative

      yes. and you could develop on your mac for some time now by installing mono via darwinports or fink.

      --
      - tristan
  10. May be a dumb question by Anonymous Coward · · Score: 0

    But is this just for development or can you deploy .Net app on OS X then, and if so does this mean you could run .asp pages on os x via apache?

  11. seems superfluous... by javax · · Score: 2, Insightful

    superb. Mono is available via DarwinPorts for a rather long time already.
    Why should we need this so urgently? There is no package for Debian or FreeBSD either... no one with a brain would think about making packages for those!

    1. Re:seems superfluous... by Anonymous Coward · · Score: 0

      you obviously have not tried to compile mono on mac os x!

      i bow down to those that compiled it on a stock 10.3 installation and got it working. the farthest i could get was mcs, and that was only barely working.

    2. Re:seems superfluous... by absurdhero · · Score: 1

      Portable.NET (http://dotgnu.org) has been avaliable for a long time via DarwinPorts and a separate disk image for a long time now as well. I am surprised that slashdotters don't seem to realize this!

  12. mod_mono compile fix by chasingporsches · · Score: 3, Informative

    for any of you that have tried to compile mod_mono 0.9 with the apple GCC and apache 1.3 stock installs, you may notice that it fails on "sudo make install" because it compiles it to a dylib instead of a so. here's a workaround: cd mod_mono-0.9/src; apxs -c -o libmod_mono.so -DAPACHE13 -I../include/ -I/usr/include/httpd/ mod_mono.c; apxs -i -a -n mono libmod_mono.so