Mono Progress In the Past Year

Eugenia writes "OSNews posted an article accounting the applications created in GTK# the past 8 months, since the release of Mono 1.0. While many of them are still in their infancy, it's clear that the platform had a healthy progress, with 'super-hits' like Tomboy, F-spot, MonoDevelop, Muine & Blam! and other, less known gems, like SportsTracker, PolarViewer, MooTag, GFax, GIB, Sonance and Bluefunk. The 2.0 version of Mono is expected around May, but the developers advised distros and users to upgrade to Mono 1.1.4 despite being a beta."

Comments

Mono talk w/ icaza

[camcorder]

Miguel de Icaza interview about mono on lug radio. Really nice one.

huh?

[utexaspunk]

Tomboy, F-spot, Muine & Blam! ... MooTag, GFax, GIB, Sonance and Bluefunk

WTF? Who comes up with names like these? I would blame the MBA's, but this is open source stuff, right?

Re:huh?

[SoCalChris]

Seriously...

At least give the program a somewhat descriptive name, ie Office, Internet Explorer, TurboTax, NotePad, Photoshop, etc...

If I were looking for a music player on Google, I wouldn't even give search results about programs named Muine, MooTag or Bluefunk a second glance, simply because they don't sound like music players.

Open Source programmers are good at a lot of things, but naming their programs isn't one of them. Just look at the whole Phoenix/Firebird/FireFox fiasco.

Beagle

[ultrabot]

Interestingly, the summary neglected to mention Beagle, the one Mono application I actually plan on using and that has created some momentum for getting the Mono into various distros.

If Mono proves to be snappier than, say, Java, there might be some hope for it but the spectre of living under the mercy of MSFT is not easy to dodge. It's still there, however much people tried to not talk or think about it.

Wrong punctuation?

[Speare]

with 'super-hits' like Tomboy, F-spot, MonoDevelop, Muine & Blam! and other, less known gems,

I haven't heard of even one of these "super hits." I think that should have been punctuated,

with 'super-hits' like Tomboy, F-spot, MonoDevelop, Muine & Blam! and other less-known gems,

Re:Wrong punctuation?

[Otter]

Yes, as a rabidly psychotic MooTag fanboy (Nothing has been holding back open-source more than the shortage of half-finished ID3 tag editors!) I am enraged at this obvious favoritism towards Blam! and F-spot!

[Insert requisite stream of sexist abuse towards Eugenia...]

C# Rocks - go mono go.

[Tanaka]

I'm just getting into C#, and I love it. One interesting thing I found was that if I ran a socket server app on Windows, I couldn't connect more than 64 clients in a single thread. I tried the same binary on Linux/Mono, and it bombed out at 1011 connections.

Keep up the good work - I'm loving it!

Re:C# Rocks - go mono go.

[jdunn14]

If you're curious about that 64 client limit check out winnt.h and look for MAXIMUM_WAIT_OBJECTS (in mine it's on line 1354):
#define MAXIMUM_WAIT_OBJECTS 64 // Maximum number of wait objects

This is the limit on the number of objects that can be waited for in WaitForMultipleObjects calls. The same limit is enforced in winsock2 for select calls, I believe because in the end microsoft's select implementation is using WaitForMultipleObjects underneath. (Also note that the winnt.h header file is entirely too large for a single header (9170 lines), but hey, that's window's style for ya).

Re:Mono is Wonderful

[FidelCatsro]

http://yro.slashdot.org/article.pl?sid=05/02/22/13 10232&tid=109&tid=155
This is the reason(meaning many simmilar things M$ have done) I currently dont use mono for any production systems ,
now this isnt totaly related , i do admit but the relationship is too close for comfort
. i feel on unsteady ground using it , not that it would matter as im in the EU (unless those *Explitives* get their way) ,Though i would hate to think any project i was working on could have the rug pulled so firmly out from underneath it and stop some of my freinds in america being unable to use said project legaly on a linux system .
Although i must also raise a glass to the mono team on an excelent job.

Well...

[Blue-Footed Boobie]

Mono is a huge part of my life!

Every morning I get up and feed F-Spot (my Beagle). Then, I get out some eggs, cheese, and MooTag to make myself an omelet. I learned how to cook omelets from Emeril. So, it's Muine & Blam! and my omelets done!

Next, I take a shower and wash off the Bluefunk. Once dressed in my suit and my PolarViewer glasses I call down to Tomboy (our doorman) and have him GIB up a cab.

Once at work it is non-stop Gfaxes and sneaking some time with my SportTracker.

Re:Mono is Wonderful

[m50d]

It does benefit them. Hopefully when Sun sees all the devs switching it will finally open up Java. If not, good riddance - C# includes all the good bits anyway.

Impressive

[Anonymous Coward]

I'm writing this as a mere user, not as a developer, but from my point of view mono really is impressive. Just looking over the list of apps on osnews shows that mono really seems to give developers a framework that let's them develop great application in a relatively short time and in the end it's users like me who profit from that. ;-D

Great works, mono devs.

And to all those trolls that will come out of the woodwork with every mono story, telling us that mono is the end of open source:
Please, for once in your miserable lifes try to provide arguments for your point that go beyond MS is evil (though I would readily agree with that) and therefor mono is the suX0r.

Re:Mono is Wonderful

[shird]

Is it really reverse engineering? I mean the full spec for the CLR and various other things with .NET have been published for the very reason to create VMs such as Mono on different platforms.

Geeks getting mono?

[Nine Tenths of The W]

This has to be a first.

it's not reverse engineering

[idlake]

Mono is a wonderful piece of reverse engineering

There is no "reverse engineering" involved. These applications are written in C#, an open ECMA standard, and the open source Gtk+ toolkit.

I fear the day when Microsoft will come and snatch this out from under the Mono team,

There is nothing to "snatch": these are applications implemented in a non-Microsoft toolkit using an open language standard.

I really think this benifits Microsoft

I don't see how writing Gnome applications in C# benefits Microsoft any more than writing Gnome applications in C++ or Python.

Re:it's not reverse engineering

[idlake]

Those same applications will also run under Windows,

These are not .NET applications, they are Gtk+ applications written in C#. As a result, they don't run on Windows or .NET out of the box.

You can run them on Windows, but you can do that with lots of other Gnome and KDE apps as well.

Plus, they can sell MS Office.NET to Linux users too, as it can run on Linux.

I think this would be great for Linux. Unfortunately, Mono will likely never be compatible enough for that, and hell would freeze over before Microsoft would even contemplate such a thing.

Re:it's not reverse engineering

[Patoski]

I fear the day when Microsoft will come and snatch this out from under the Mono team,

There is nothing to "snatch": these are applications implemented in a non-Microsoft toolkit using an open language standard.

This isn't 100% accurate since there is also the issue of patents to consider. In order to implement some parts of the .NET standard there would be some "use" of MS patents (I'm talking about ASP.NET and ADO.NET in particular). MS has never said anything about letting people use these parts of .NET and could easily go after Mono over this issue. Even the Mono team acknowledges this as an issue but they promise they'll somehow code around the patent or they just won't implement parts of the standard. Certainly not an optimal solution.

I don't see how writing Gnome applications in C# benefits Microsoft any more than writing Gnome applications in C++ or Python.

MS gets to say that their solution (C#) is cross platform and usable on numerous platforms. In short, publicity.

Re:it's not reverse engineering

[ultrabot]

There is nothing to "snatch": these are applications implemented in a non-Microsoft toolkit using an open language standard.

The catch is that C# and CLR are not open standards - they are just ECMA standards. Apparently it was a brilliant move by MSFT because now people will automatically believe CLR is somehow "open". In fact, a while ago Novell was asking MSFT for a clear declaration that Mono does not infringe MSFT IP. Guess what, we never heard what happened with that.

I don't see how writing Gnome applications in C# benefits Microsoft any more than writing Gnome applications in C++ or Python.

It provides a hose that MSFT can step on to end the distribution of the appications. The more critical the app is for Desktop Linux, the better for MSFT. Hopefully the apps that are written in C# will stay small and architecturally open enough to be easily rewritten in another language should that happen. We should never become too dependent on Mono, or Java, or any other proprietary technology.

Re:it's not reverse engineering

[beanlover]

Thank you for your post. I was one of those that believed because it was an ECMA standard that it was free and open.

I went to the ecma site and saw this page:

WARNINGS

The liability and responsibility for the implementation of an Ecma Standard rests with the implementor, and not with Ecma.

Below that was a warning and a linke about settling patent issues pertaining to ECMA standards. Scary.

B

Re:it's not reverse engineering

[idlake]

The catch is that C# and CLR are not open standards - they are just ECMA standards.

That is what an open standard is: something that is published by a recognized standards body and that anybody is free to implement.

Apparently it was a brilliant move by MSFT because now people will automatically believe CLR is somehow "open".

They believe that because it's true. .NET is not open, but ECMA C# is.

In fact, a while ago Novell was asking MSFT for a clear declaration that Mono does not infringe MSFT IP.

Yes, Novell did ask that. That question doesn't refer to ECMA C#, which is as open as any language standard, it refers to Mono's implementation of .NET.

It provides a hose that MSFT can step on to end the distribution of the appications.

Erroneous statements like that seem calculated to create unjustified fear, uncertainty, and doubt about C# in order to keep people from using it. ECMA C# is open. Microsoft can no more "step on its hose" than they can step on C++ or Python or Java (on which, incidentally, they may also hold related patents).

We should never become too dependent on Mono, or Java, or any other proprietary technology.

Mono is not proprietary technology: it's an open source project implementing a de-facto industry standard. As such, it is no different from Linux, for example. As such, Mono consists of two parts: a part that implements an open standard (ECMA C#), and a part that implements a proprietary set of APIs (the parts of .NET that are not in ECMA C#).

If you want to use purely open APIs, just use ECMA C# and Gtk# and don't use any of the non-standard .NET libraries that Mono happens to implement as well. That's what I do.

Re:it's not reverse engineering

[miguel]

I would be very suspicious about such contribution,
because most of the remoting code was written by
Lluis (for all the high-level channels), Dietmar
(for all the low-level remoting bits), Patrik
(which filled a lot of the mid-level details).

All I can think of are stubs, which are not really
useful.

Those were either Novell/Ximian/Intel employees,
and in no case we did disassemble.

For the other pieces like Soap/Remoting, the code
was so broken that it could not have possibly
been copied/decompiled given how useless it was
until we fixed it in various iterations.

I very much doubt your statement, but if it
happens to be true, we have records for each
contribution going to the day zero of the
project and we can track it down.

Miguel.

Re:it's not reverse engineering

[miguel]

Thanks for looking into this.

We are auditing the code, and the code that we have
in that area was either completely redone, or what
has not been redone is fairly broken.

I would be surprised if the implementation is
copied.

But if they decompiled to learn how it worked, we
will remove the code anyways.

Miguel.

C# is Better than Java(At least I think So)

[Laoping]

Ok, Microsoft Is evil, this I will give you, but C# rocks. After years in C and C++, I moved to Java, and It was good, then about 2 years ago I moved to C# and it was better. Now I program in both, for work and graduate school. I have to say they are very similar, but when I am doing a program in Java, I always miss a few of the C# features (virtual keyword for functions, Get/Set are better in C#, etc)

The only problem I have with C# was that it was not as portable as Java, but Mono came to my rescue. I was surprised how many of my program just worked in Mono (after removing winforms that is). I can't wait for version 2.0.

Really, Mono should be embraced /.ers . If we can start making programs for the general population that run on *nix systems, but look just like they do on windows, more people will use *nix. What we have to realize is that most people in the world(not on this website J) don't have 4 computers in their basement running different operations systems, they just have the one running windows.

P.S. And for some reason, they still have the sides on their computer case.......

Re:C# is Better than Java(At least I think So)

[Stephen Williams]

Get/Set are better in C#

I see loads of love for the C# property syntax, but I personally find it a bit irritating because you can't have different access qualifiers on the getter and setter. If you want, say, a public getter and a protected setter, you have to write a special setter method that defeats the purpose of having the special property syntax.

If the property syntax were modified to look like this, it'd be perfect:

string Foo
{
public get { return foo; }
protected set { foo = value; }
}

-Stephen

Re:C# is Better than Java(At least I think So)

[mattgreen]

This is slated for C# 2.0.

Re:C# is Better than Java(At least I think So)

[rabtech]

Funny story on that:

VB.NET originally supported this (different access on setter and getter) but since C# didn't support it they dropped it to be compatible... now that C# is gonna support it in the next version they are going back in and re-enabling the feature.

Why it wasn't in originally I don't know, it would seem to be an obvious feature.

From a mono developer..

[zbowling]

I just happen to be one of the few official developers for the mono project, just catching this artical early. Mono is quickly becoming better then ever. The biggest difference between Mono 1.0.x and Mono 1.1.x is the fact that our Just-In-Time compiler (or JIT) is getting more and more amazing every day. The 1.0.x series use a interprator capable of understanding things at the application start. One huge correction is that Mono will be called 1.2 in May not 2.0. While it is true that gtk-sharp-2.0 is moving to 2.0 from 1.0, the Mono runtime will remain at 1.2 as not to be confused with Microsoft.NET 2.0 (all though support for many of .NET 2.0 features will be included). Gtk# being based on Gtk+ 2.2 and Gtk# 2.0 being based on Gtk+ 2.4. Windows support is just as compatable with GTK# as it is on Linux, minus support for Gnome, VFS, GConf, GtkHtml 3 and DBus of course. Hope that helps!

Re:From a mono developer..

[zbowling]

Well, there really isn't an issue.

IP issues have been solved a long time ago. While Microsoft didn't publicly comment on IP issues in Mono, the legal department at Novell feels that any action taken by Microsoft against mono would be in amazingly bad faith and for 90% of Mono would be impossible to impose.

The sections that were released under the EMCA filing are public and they will be ours forever. The issues that maybe questionable are parts that were not released on the EMCA but Microsoft has released the source for those under a shared common licence (very restrictive) but allow anyone to "learn" from them as long as the don't take anything tangable (copy and paste, rigth it down) so as much as you can remember while looking at it is yours. The even make the comment in the licence that its a almost needed tool for implimenting your own runtimes. Mono has a personal policy not except code from people who even looked at to avoid all chances of something slipping up in the mess.

Microsoft has communicated with us in the past on different things and we have communictated with them when we find a security flaw in the framework. They even use our code deep in the depths of Microsoft for regression tests (as much as I have heard) and the even demo with our software at conferences and online broadcasts on the power of the .NET Framework.

With all the positive support they have given towards it would be in bad interests to suddenly change on that and would be against anti-trust laws. We are also protected by the EMCA filling because it proves that Microsoft intented for .NET to be a standard and not propiatary. Any patent that Microsoft would try to file would be quickly shot down because of prior art clauses and the fact that Mono is mostly a wrapper (when it comes to the classes not the compiler or the runtime) for libraries that already exist in Linux (in most cases this is true) they would have to file against libraries that even Microsoft used as the basis for their products publicly.

I just don't see any issue. It was a consern when we started before we had time to investigate. :-)

Re:Hmm, does realy Mono work..

[Coryoth]

If you're using Mono for GNOME/GTK development, it's actually quite stable, and much more usable than trying to write applications in old-fashioned C.

Yes, but let's be honest here: if you're writing a GTK/GNOME application you're writing a reasonably high level application and pretty much anything (Java, Python, hell even C++, bindings) would be "much more usable" than "old-fashioned C".

Please note that I am not dissing Mono. Variety is nice, and C# does provide a relatively nice language to be able to code GUI applications in. My issue is with the common implication that C# is unique in this - it isn't. Try out PyGTK for instance (particularly with libGlade).

Jedidiah.

Stop being a crusty slashbot.

[Inoshiro]

How is this not like life?

Ford Explorer -- does that also access the internet?

Hyundai Accent -- is it about the korean language?

Honda Accord -- music perhaps?

People make names which they feel are the best for something. They rely on something's ability to be good at it to spread the love, so to speak. If it's good, people will remember it. If it's not good, it goes away and it's no issue. Do you really like how people went to ultrageneric names and domain speculation on the Internet? Pets.com? Mail.com? News.com?

Take a look at things which people remember. What about Napster implies filesharing? What about Suprnova? What about Google implies searching?

Naming is a magic game. Just because you don't like how others play it, does not mean they are playing it wrong. This whole "incorrect naming" meme is stupid and pointless. Start thinking critically about what you're saying before you repeat it everywhere.

Re:good

[grfpopl]

Wow, it's really too bad that people these days think that OO is about a language spec. It's not! OO is a design paradigm! (ugh. i hate that word, but that's what it is.) Your design is either OO or not OO, and the language that you implement it in is irrelevant. All that c++ does that c doesn't is do a few checks in the compiler. You can implement OO designs in C, Scheme, and plenty of other languages that don't have built-in checks for such things. (and yes, c++ does have a number of other features, but they are wholly unrelated to OO) OO doesn't fix buffer overflows either. Why would it? If you have crappy design/use the wrong functions for the wrong things, then you're going to end up with buffer overflows. C# goes quite a ways, as a language, to prevent this, but don't confuse it with OO.

Re:You were right the first time.

[untaken_name]

Yeah well...I hear that Open Source is a total whore. Anyone who wants to can 'get in'. Bill shoulda known better.

Re:Story time

[ed__]

first, their is a published spec.

secondly, mono is more about enabling developers to use C# and CLR, rather than allowing people to run windows software on *nix, so there isn't the same necessity for bug-for-bug compatibility as there is in samba (where you want to look exactly like a Windows box from the outside).

What are the good bits of which you speak?

[pmike_bauer]

What are these good bits of which you speak? Or are we (yet again) confusing Java, the language, and Java, the platform? An argument can be made that the C# language learned and improved upon the Java language's experience. On the other hand, comparing the two platforms (i.e. runtimes and libraries) is a whole different bag. Granted, C# and .Net are possibly the best technologies to use if you are developing Windows applications. But, to assert that these are the best options in any other environment is simply ludicrous. Mono is in no way as mature, stable, feature rich (you name it) as the Java platform. Pray tell where is my Mono equivalent of Jakarta, Java3D, Maven, HotSpotVM, Tapestry, Eclipse, Netbeans, IntelliJ, yadatada? When you find them, then come back and tell me C# has "all the good bits." Mono may have the potential to become what Java is today, but its not there yet.

Re:Story time

[damiam]

The fate of samba? Last time I checked, Samba was alive and well. And if anything, Mono has an advantage over samba in that it doesn't have to be Windows-compatible to be useful. C# is a great language (supposedly; I've never used it) and an open-source Linux implementation can only be a good thing. All of the apps mentioned in the intro are native GTK apps, and will continue to work well and be developed even if MS does something to break Windows compatibility.

Re:Almost 100% Agreed.

[rjh]

Have you ever seen an OO design in PROLOG?

It usually starts with this: "First, implement LISP..."

Have you ever seen backwards-chaining declarative logic designs in Scheme?

It usually starts with "First, implement PROLOG..."

I wish I was kidding.

Re:Mono has a long way to go, even in OSS

[Sunspire]

It's all a matter of how you choose your metrics. Here's another one, desktop applications that don't suck horribly:

Java: Azureus, Eclipse.... I'm sure if I really searched I could find a third.
Mono: Beagle, Tomboy, F-Spot, Muine, MonoDevelop etc.

It's no sillier a metric than the amount of showelware on SourceForge for a given platform. For the Linux user it's certainly a more interesting one.

Even these so called crown jewels of the Java desktop can be spotted a mile away as Java programs. When you run Beagle or Tomboy you can not distinguish them from native GTK+ apps. For all intents and purposes they are native.

Java and Mono have chosen completely different paths at this point. It's futile to try to evangelize one language over the other at this point. Java has settled as a backend language for stuff like web services, while Mono/.NET competes with the incumbent C/C++, and Python to some extent, over the desktop. It's now a case of different tools for different jobs, and at this time it's already pretty clear that Mono is going to be a major force when it comes to the future of the Linux desktop.

Re:Did you forget about wxNET?

[Coryoth]

Each platform has different HIGs which determine how an application should behave as well as how it should look. Using the same UI code on multiple platforms results in apps that don't match the HIGs on any platform except (if you're lucky) the one on which they were developed.

Which raises the interesting question of whether we should be looking for another level of abstraction for GUIs beyond widget toolkits that let you write one codebase that then applies the HIG rules of the platform (which, of course, have to be something formally codified rather than just a spec document) to generate a (relatively speaking) HIG compliant UI.

Imagine having applications written on a level such that the "OK/Cancel" button order is determined by the platform rather than by where the code explicitly placed the buttons. Such would certainly make GNOME and KDE much more compatible. At the same time it would formalise the HIG from a "reccomended way of doing things" into a mandated consistent GUI.

Jedidiah.