×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Mono Adds Mac OS X Package

timothy posted more than 9 years ago | from the for-your-conversion dept.

OS X 53

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.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

53 comments

Aha! (0)

byolinux (535260) | more than 9 years ago | (#9125696)

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!

Re:Aha! (1)

hak1du (761835) | more than 9 years ago | (#9126022)

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?

Re:Aha! (1)

byolinux (535260) | more than 9 years ago | (#9127025)

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.

Re:Aha! (1)

hak1du (761835) | more than 9 years ago | (#9130179)

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.

Re:Aha! (1)

baryon351 (626717) | more than 9 years ago | (#9126142)

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?

Re:Aha! (1)

torpor (458) | more than 9 years ago | (#9126242)

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

Re:Aha! (3, Insightful)

Alrescha (50745) | more than 9 years ago | (#9126959)

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

Re:Aha! (1)

squiggleslash (241428) | more than 9 years ago | (#9127813)

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.

Re:Aha! (0)

Anonymous Coward | more than 9 years ago | (#9132565)

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.

Re:Aha! (1)

squiggleslash (241428) | more than 9 years ago | (#9132636)

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?

Re:Aha! (1)

b-baggins (610215) | more than 9 years ago | (#9129478)

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

Re:Aha! (1)

torpor (458) | more than 9 years ago | (#9136854)

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!

Re:Aha! (2, Interesting)

Smurf (7981) | more than 9 years ago | (#9145983)

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

Re:Aha! (1)

code shady (637051) | more than 9 years ago | (#9174572)

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

Usability? (2)

polyp2000 (444682) | more than 9 years ago | (#9125752)

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

Re:Usability? (1)

hak1du (761835) | more than 9 years ago | (#9126000)

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

Re:Usability? (0)

Anonymous Coward | more than 9 years ago | (#9126178)

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

Re:Usability? (0)

Anonymous Coward | more than 9 years ago | (#9126213)

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.

DeDRMS (1)

sameerd (445449) | more than 9 years ago | (#9125839)

Any one tried compiling DeDRMS with this? Any success?

Re:DeDRMS (1)

fourfoot (769468) | more than 9 years ago | (#9130332)

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.

Re:DeDRMS (0)

Anonymous Coward | more than 9 years ago | (#9132604)

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.

Re:DeDRMS (0)

Anonymous Coward | more than 9 years ago | (#9141222)

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.

Is .Net on OS X a Good Thing? (5, Interesting)

mr_tap (693311) | more than 9 years ago | (#9126058)

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 :)

Re:Is .Net on OS X a Good Thing? (3, Insightful)

bay43270 (267213) | more than 9 years ago | (#9127235)

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.

Re:Is .Net on OS X a Good Thing? (3, Insightful)

JimRay (6620) | more than 9 years ago | (#9127692)

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 [asdocgen.org] , 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 [barebones.com] 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.

Re:Is .Net on OS X a Good Thing? (1)

johnnliu (454880) | more than 9 years ago | (#9134691)

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.

Serious question (1, Troll)

revscat (35618) | more than 9 years ago | (#9126229)

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.

Re:Serious question (1)

squiggleslash (241428) | more than 9 years ago | (#9127883)

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.

Explanation of /opt/local and /usr/local (1, Interesting)

Anonymous Coward | more than 9 years ago | (#9126238)

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.

Re:Explanation of /opt/local and /usr/local (4, Informative)

frankie (91710) | more than 9 years ago | (#9126757)

/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)

Re:Explanation of /opt/local and /usr/local (1)

squiggleslash (241428) | more than 9 years ago | (#9127960)

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

Re:Explanation of /opt/local and /usr/local (1)

b-baggins (610215) | more than 9 years ago | (#9129524)

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.

Re:Explanation of /opt/local and /usr/local (1)

prockcore (543967) | more than 9 years ago | (#9133248)

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?

Re:Explanation of /opt/local and /usr/local (1)

joeyGibson (30462) | more than 9 years ago | (#9147864)

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

Hey pal, them's fighting words...

Re:Explanation of /opt/local and /usr/local (1)

goon america (536413) | more than 9 years ago | (#9128239)

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

Re:Explanation of /opt/local and /usr/local (1)

trouser (149900) | more than 9 years ago | (#9136743)

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

Re:Explanation of /opt/local and /usr/local (1, Informative)

Anonymous Coward | more than 9 years ago | (#9128994)

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.

Re:Explanation of /opt/local and /usr/local (2, Interesting)

sleepypants (599905) | more than 9 years ago | (#9127060)

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.

Re:Explanation of /opt/local and /usr/local (1)

EccentricAnomaly (451326) | more than 9 years ago | (#9135697)

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

Finally. . .iFolder (4, Interesting)

Aiua (688192) | more than 9 years ago | (#9127322)

I am excited about this quiet release. First, it opens up the possibility of compiling Novell's OSS iFolder [novell.com] 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.

Re:Finally. . .iFolder (1)

absurdhero (614828) | more than 9 years ago | (#9269738)

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 :)

Darwinports (0)

Anonymous Coward | more than 9 years ago | (#9127408)

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

developer (1)

undef24 (159451) | more than 9 years ago | (#9127935)

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?

Re:developer (2, Informative)

OmniVector (569062) | more than 9 years ago | (#9128307)

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

May be a dumb question (0)

Anonymous Coward | more than 9 years ago | (#9127966)

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?

seems superfluous... (2, Insightful)

javax (598925) | more than 9 years ago | (#9130371)

superb. Mono is available via DarwinPorts [opendarwin.org] 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!

Re:seems superfluous... (0)

Anonymous Coward | more than 9 years ago | (#9152599)

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.

Re:seems superfluous... (1)

absurdhero (614828) | more than 9 years ago | (#9269684)

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!

mod_mono compile fix (3, Informative)

chasingporsches (659844) | more than 9 years ago | (#9136636)

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
Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...