Mono Project Releases Version 1.0

theblackdeer writes "Just poking around the go-mono.com Mono website; it's now the multi-colored mono-project.com. Even better, it updated before my eyes to include the 1.0 release. Screenshots are (slightly) updated, too. Mono 1.0 includes the Mono Develop IDE (based on SharpDevelop, I believe). Download now and start your GTK# engines!" Alliante adds "You can download the Release Notes and the Packages on their website."

Comments

Licensing concerns abated

[SIGALRM]

From the FAQ:

The Mono project has also sparked a lot of interest in developing C#-based components, libraries and frameworks

Yes it has. In our company's roadmap, we considered C# and Mono, but the controversial elements of their licensing (ASP.NET, ADO.NET, and Windows Forms subsets) gave us pause until we researched it further. Most of it is covered under the ECMA/ISO and the other technologies developed on top of it.

Looks like the Mono strategy is to work around the patent issues by using a different technique that retains the API but changes the mechanism.

beware...

[Anonymous Coward]

mono makes your throat sore. you get it from kissing girls. actually i guess that's not going to be a concern around here.

forgive the interruption.

Re:How important is this for Linux?

[Tobias Luetke]

As long as you either use GTK# ( download ), wxNet or console mode you won't even have to recompile it under mono on linux/MacOs/whatever. You will be able to just run it.

Why .NET and not Java?

[Sanity]

This may seem like flamebait, but they throw the first stone right there on From the Mono website:

...However, the Java runtime systems commonly available on Linux lack the performance that customers demand, and Java applications do not conform to the Linux GUI look and feel.

If these are the best justification for .NET over Java, then they are pretty weak.

As has been pointed out ad tedium in various Java-related discussions on /. - Java's early reputation for poor performance may have been justified in the 1.0 and 1.1 days, but modern Java VMs employ sophisticated JIT compilers which gives it comparable performance to natively compiled languages like C++, and easily matches .NET's CLR performance. Java's bytecode and .NET's bytecode are not that different, the main differences are in the APIs.

Which brings us on to the second justification for .NET over Java, native GUIs, which is even weaker. Java-Gnome does the same thing as Mono's GTK bindings, offering exactly the same GUI abilities, and SWT offers a truely cross-platform GUI API with a native look and feel on each platform it runs on.

Re:Why .NET and not Java?

[GlowStars]

...no distribution ships Sun's JVM...

WRONG! SuSE does.

Re:Why .NET and not Java?

[iwadasn]

That still seems a little weak. Most of the things you are trying to solve are either vacuous, or simply problems that should be solved at the VM layer without causing the users any additional pain.

Multi-Language: Please, they're all the same language designed to look like other languages. Java has multi language support to (Jython). This is not a fundamental reason.

Value Types: Use escape analysis and a better GC. This is a hack so programmers can give hints to a stupid GC.

Generics: Where are the C# generics? The version we're using at work doesn't have them. Java Generics will arrive first, but be worse off in the beginnnig. C# will arrive later, and initially have a better implementation. Java should fix their implementation in a future revision of the VM and bytecode standard.

Bindings: Spin the wheel and see which function gets called today. Not much needs to be said here, but there's something to be said for the precision of the java bindings as opposed to the pattern matching of the C# bindings.

ECMA: And patented by Microsoft. Fact it, Microsoft will embrace and extend it, or threaten lawsuit to keep their monopoly. The ECMA won't do jack about that.

C# language: The only even marginally valid claim. However, the lack of checked exceptions and sub-standard stack traces are pretty nasty. I don't think C# is a step up in any meaningful way, unless of course you like writing crappy code and just can't bear to know which exceptions you should be worried about. If that's the case, VB6 will always be waiting.

I'm not saying that the C# people are stupid, or anything like that. But this whole endeavor seems to demonstrate a monumental lack of foresight. Why fragment the world even further rather than uniting behind a standard the Microsoft doesn't own?

Re:Why .NET and not Java?

[Armchair Dissident]

I now have to use C# at work as our company has decided that this is what Microsoft's future is invested in. I've had a love-hate relationship with it, and my opinion of .NET is possibly clouded by my use of C#, rather than a criticism of .NET, but anyway:

• Multi-language support by design is a hack. It's not real. C++, for example is not C++ as I, as a C/C++ hack, know it. It's a thing that is something like, but not quite C++.
• structs as ValueTypes are a pain in the arse. They have the same syntactic semantics as classes but have no similarities. Because of this
  flibble foo = new flibble();
  flibble bar = new flibble();
  
  foo==bar"
  means two completely different things depending upon whether flibble is a struct or a class. Which has given me endless problems with DateTime.
• Generics are not yet a standard feature of of .NET CLR. This is the reason given by Microsoft for not including generics as part of C#.
• EMCA standardisation is a joke if the libraries can be butchered. The language is the least of the problems when portability is concerned. The precise way in which the libraries work and interoperate is the big problem.
• .NET - as far as I can see - was simply a way of touting a "write once, run anywhere" platform, without actually proving the case. C# takes some things out of Java, and some out of C++, but never asks the question "why are these here". Operator overloads without templates, and without a good distinction between references are pointers spring to mind. (what does 'foo == bar' do?)
• Some prefer C#, but I can't see why...

Sorry Miguel. Mono is a worthy project, and I have it running on OS/X - it's impressive from that point. But as .NET stands, and especially C#, Microsoft got it hideously wrong.

Try MonoDevelop

[Anonymous Coward]

For those looking for an IDE, try out MonoDevelop 0.5. It doesn't have a gui builder, but has code-completion(intellisense), class browser, project management, etc... It's a port of Sharpdevelop.

Congrats, mono is impressive

[Ars-Fartsica]

The mono team has released an incredible amount of code in a relatively short timespan. The mono codebase goes beyond a compiler and runtime - graphical bindings, documentation, and a full IDE are all being rolled out as one more strong alternative in the linux development world. Added to which there are already "for real" apps out there you can use today that are not just toys - for example the Muine music player.

Too many people will get hung up over the Microsoft angle and notions that mono is out to wipe out all other development toolkits. This is nonsense. What the mono team has done is upended a Microsoft strategy - that Windows is differentiated because of the .Net platform. Now we have a level playing field on top of all of the other inherent advantages of open source.

Bravo and thanks mono team.

Runtime Distribution

[Nurgled]

This Mono 1.0 release seems to be developer-oriented. Will they (or someone else) be creating smaller runtime packages which only include the stuff necessary to run applications?

It would be nice if there were an easy install package for Win32, too. This might seem pointless on the surface, but Microsoft.NET won't install on all Windows systems due to deliberate barriers, plus Microsoft's distribution does not come with GTk# and so forth.

I'm installing the full release on my main system, but it'd be nice to have a smaller runtime package that I can put on my other boxen to run any apps I create. Perhaps in a few hundred years Debian will have a runtime package which can be depended on by mono apps without having to pull in the whole development environment. (mono-runtime vs. mono-devel, both depending on mono-common)

(I see a page about the Mono runtime but it's talking about the runtime portion of the project rather than a specific runtime distribution.)

Re:Free as in 'Free from vendor lockin'

[MenTaLguY]

What I think they should do is embrace and extend the the .NET framework *NOW*, add features and support for things that the Windows .NET does not have. But also bring the extended version to Windows itself.

That's precisely what they've been doing all along. Until recently, they've just been very quiet about it...

You'll notice lately that Miguel's been talking about "API stacks" -- i.e. Gtk# et al versus Microsoft's SWF et al., both built on the safe substrate of the ECMA standard. They've been working on that stuff all along, but until recently not talking about it separately.

See also this post.

I believe they're offering packages without any of the Microsoft-specific bits now (to make e.g. Debian happy). And yes, this stuff works on Windows.

I don't think Microsoft quite realizes what's hit them yet. Embrace and extend again, but this time it's Microsoft on the receiving end.

Re:How important is this for Linux?

[Dalcius]

"The linux landscape is changing, its going mainstream, and there are a lot linux users who don't like that. I must humbly suggest to such people that you cannot do anything about it, and you should therefore either accept the reality or start moving to another system where you can feel more "l33t"."

You call others narrowminded but I don't think you yourself understand the reasons people are afraid of the side-effects of Linux growth. Maybe you're just hearing a vocal minority.

I personally cannot stand to use Windows these days, for many reasons... but one of the biggest is the environment. Under Linux searching for help, files or other content is particularly easy: the signal to noise ratio is quite good. Under Windows, it's "Sign up to download, we sell your email, now you can wait in a queue to get your file, but here are some ads to keep you busy". Pop-ups, spam, misdirection, just junk in general.

The bottom line for this reasoning is that Linux it's just easier to find what you want (or at least a definitive 'It doesn't exit') in a shorter time. When the community starts growing, we'll see lots of wannabe applications attempting to sell themselves to you, registration keys and website registrations, hassles downloading files or getting help, etc. This is a Bad Thing.

That all said, I'm in favor of Linux's growth and I think most people are. There aren't many true Linux users who do it just to be "leet" and I think its pretty silly to suggest that. Most Linux hobbiests do it because they are in control, in one way or another -- application choices, configurations, power, etc.

Slapping a dogma on someone and calling them an idiot isn't helping anyone. I think the Linux community is ready to expand and wants to expand, it's just afraid of how severe the consequences might be when the 'unwashed masses' start using this stuff.

Cheers

Re:What about the patent issues?

[Teancum]

First of all, Microsoft has been directly helping the Mono project, in terms of technical assistance. While this doesn't solve the patent issue, it does show a certain culpability on the part of Microsoft, and it would be a big fly in the ointment if MS decided to file a lawsuit.

Also, Mono is much closer to a "clean-room" development model, based almost exclusively on the API libraries and reverse engineering of data formats to become more compatable with MS function calls. Although Mono started with the core components being compiled with the free dotNet compiler from MS, it has been self-compiling for some time now.

The anti-trust issues won't help out MS either if they file a lawsuit against Novell. Novell has some relatively deep pockets, and it would be in their interest to get into a legal fight with Microsoft, particuarly one that MS initiated. From a sheer anti-trust viewpoint it would not be a good thing for MS to engage in something like this directly, and it could only be a direct threat from MS that would amount to be worth anything, unlike the SCO fiasco. No hiding behind serrogates for this fight. Furthermore, MS would risk a counter suit from several parties (Miguel to start with) if they tried to get the software pulled, potentially costing MS quite a bit of money.

Almost all of mono is derived from the ECMA documents, which also state rather clearly (with formal waivers signed by Microsoft) that anybody is free to create their own implementation of those standards.

Where the Mono Project could run into problems is if somebody (in a really stupid moment) decided to include some "shared source" source code from MS into Mono. This would be the same issue that Linux is facing from SCO, and when that goes to court it will have a final court ruling on that issue. If SCO wins by some act of God, it will become a huge issue for almost all open source/free software projects, not just Mono. I don't know if the courts have the political will to shut down a multi-billion dollar industry that easily over a technical ruling. Besides, the remedies to fix an issue like that are very easily done, and can even be done in a very pristine "clean room" atmosphere to replace any code that caused problems like that.

I would have no problem testifying in court that Mono and dotNet are two totally different pieces of software, from benchmarks and I/O behavior to variable names and even Mono-only software classes.

What is going to be interesting is that Mono, now that they are at version 1.0, is going to be in a position to actually drive mindshare with this system. I predict that you will seem MS backporting some of the mono class features (including method names... even a mono.* class naming system) into standard dotNet. The question would then become who is driving the development for whom?

Yes, I dont trust Microsoft, and won't rely upon their goodwill. True as well, if you had developed a completely independent virtual OS (like dotNet or Java), there might not be as much to argue here, but then again, you might even be in more danger of violating a patent, simply because you weren't aware of it.

I think a much bigger threat for a submarine patent that would threaten Mono would come from Sun, or even some silly 3rd party that filed a patent 5-10 years ago covering virtual operating systems. The concern then is not with Microsoft, but with the USPTO instead.