Either the quote is wrong, or I had was distracted when I said so.
The runtime was developed entirely by Mainsoft, with some help from us in a few areas. Microsoft was not involved in this process, am sorry for the miss-understanding.
The runtime and compiler were pretty much done before I was aware of any discussions between Novell and Microsoft. The major change since September has been that the compiler became self-hosting on Linux (compiles itself, and compiles its own runtime) and that we have had a chance to go from a research project to a product (of course, we will keep improving it)
We have been able to run code compiled with Microsoft Visual Basic for a very long time (1.0 was supported for a few years with the old runtime, and 2.0 has been supported for a few months with our new runtime).
But there were a few problems, ASP.NET for example would requite a compiler on the host to compile VB.NET-based ASP.NET pages. ASP.NET works by translating special commands and tags into your language and mixing your code with the resulting output with a technology called "CodeDOM".
So this particular scenario (ASP.NET with VB) was not supported due to the lack of a compiler.
This also allows Windows developers to do their work on Linux directly without having to use two machines to develop.
Our compiler and runtime are written entirely in portable CIL code that later gets translated into native code on each platform by the Mono JIT.
I believe you are referring to Microsoft's Visual Basic for applications (which is what Office uses) and which is an older version of the language which they are unable to port on its current shape (their stuff was an older version of the compiler that predated the CIL bytecodes).
According to our statistics, based on 1,500 applications that have been submitted using the Mono's Migration Analysis, 50% of the VB.NET applications do not depend on the operating system.
From the remaining 50%:
25% would require a week or so to port (replacing Windows library calls with Linux calls)
25% would require a month of so to work, and a Linux expert in house
25% would require a strong commitment to support Linux, and many months of work.
25% is not even worth attempting.
Nat went to China in September of 2005 and brought a bunch of electronic gadgets that he bought over there.
Among some of the gadgets that he purchased were various music/video playback devices (I forget the price, 30 dollars?) that he bough in Beijing, these devices were not up to the standards of beauty of the iPod, but mp3/video devices in China predated the video ipod.
What I found funny about one of these devices is that it was labeled "ipod".
Apple would introduce the Video iPod a few months later.
Another comment: although we would like to take credit for being there "first" when it comes to desktop search on the OS, we were not the first ones, we were just earlier than Spotlight.
We did not know when we built Beagle about the applications being shipped on the Windows space, but we were told at some point about "X1" for Windows. X1 is now known as Yahoo Desktop Search and the product was launched in 2002 (www.x1.com)
Nat Friedman and myself demostrated the "Dashboard" (http://www.nat.org/dashboard) in August 2003 at OSCon. Tim O'Reilly liked the idea so much that he started asking Apple to implement this feature. At the time, the major limitation to make the "Dashboard" useful was that we lacked a search infrastructure on the desktop. So we set to build this infrastructure (Jon Trowbridge, now at Google, lead the effort at the time). And we pitched our plans repeatedly at a number of conferences as we were trying to get momentum behind Beagle.
This is became the Beagle Desktop Search (http://beagle-project.org/Main_Page) which was available from SVN since its inception and developed in the public. The first public demo of Beagle in action (using the dedicated UI, and integrated into the file system chooser) was done in Norway in June of 2004.
Funnily enough, the first public demo of the Beagle desktop search was presented six hours before Steve Jobs did his presentation of Spotlight on Monday 28th (Nat was in Norway, Steve in San Francisco). There was minimal press at the Gnome Users and Developers Conference, compared to the Mac event:
It means that any software that is developed within the next five years and is included with SUSE and might infringe on any patents filed by Microsoft up to the end of the agreement will be covered by the agreement.
This means that if software is written in 4 years, 300 days that is shipped with SUSE it would be covered forever for any Novell customers. Software that infringes on *new patents filed after the end of the agreement* would not be covered.
The assurance program assures customers that if there is an intellectual property issue with Red Hat Enterprise Linux ("RHEL") or JBoss Enterprise Middleware Suite ("JEMS"), Red Hat will either (i) replace the infringing portion of the software, (ii) modify the software so that it becomes non-infringing, or (iii) obtain the rights necessary for a customer to continue its use of the software without interruption.
So everything is fine up to points (i) and (ii). The problem comes if the technology is deeply embedded enough that it can not be simply "replaced" or "modified to become non-infringing".
Per the service agreement that customers are signing up to with Red Hat, they would be forced to "obtain the rights necessary for a customer to continue its use of the software without interruption".
So the contract actually contradicts Red Hat's Mark public statements.
The Winforms application that you tried to run is a 2.0 Winforms application, as the error reports:/usr/lib/mono/gac/System.Windows.Forms/2.0.0.0__b7 7a5c561934e089/System.Windows.Forms.dll, referenced in assembly/path/to/Test.exe
I'm not suggesting that you should have wasted your time with developing Java if you didn't want to. However, as I remember it, you were a big fan of the language but didn't care for the fact that it wasn't "free" as in "libre". Yet you jumped on the chance to develop Mono even though anything Microsoft touches is suspect by definition. RMS himself scolded the Mono project for even suggesting putting it onto the critical path.
You are confusing specification from implementation.
TCP/IP is a specification. There are open source implementation, and proprietary implementations of it.
C, C++, Java, C#, they all came from proprietary vendors and now open alternatives exist. Unix and the Unix APIs that we use today, were designed and implemented by a proprietary company. C, C++ and Unix btw, were all designed and implemented by the hated-monopoly-of-the-day.
Regarding the implementation of a completely fresh VM instead of.NET, this is again a case of "If you care so much about it, go and do it yourself". As I previously said, I had my own reasons for not doing this.
The funny bit of course is that you seem to be OK suggesting that I should have worked on Free Java in 2000 (Java, btw, still proprietary) instead of.NET because one company is of a different level of trustiness or evilness. Lacking an Evil-o-Meter or an evil stock price and evil capitalization am left to my own data.
Which leads us back to your point of implementing something from scratch. Well, many people have done so (Parrot, Squeak, LLVM and countless others), if you like those, use those, contribute to those, you should stop obsessing with what I eat and watch your diet instead.
Mono has an optimizing JIT compiler for a number of architectures (x86, x86-64, Itanium, SPARC, SPARCv9, S390 and S390x mainframes, PowerPC and StrongARM) and works on a variety of operating systems beyond Linux, MacOS and Windows (see our web site for details).
Regarding.NET 2.0 we are working towards that goal, the core libraries are complete, System.XML is complete and ASP.NET and ADO.NET are halfway there. Today, pragmatically we tell people that if they depend on 2.0 we do not make any guarantees, but many projects have already moved to.NET 2.0, particularly those that build and test with Mono (as they know what is available and what is not right away).
These projects include Banshee and MonoDevelop, they are both using our C# 2.0 compiler with generics now (which we have had complete for a long time).
Now the open source ecosystem created on top of Java is just fantastic, it has created a lot of really innovative pieces. Apache in particular has become a highly efficient machine that pumps out useful code, most of it written in Java.
You could either accept that there will be diversity in the form of languages, runtimes, frameworks and libraries and live a happy life, or you can try to embark yourself on a crusade to evangelize the entire world to use your favorite technology and become a bitter old man (or a bitter teenager).
We started Mono for our own reasons (you can read the rationale I wrote around the time of Mono's launch here) and I have expanded on that a number of times ever since.
Free Java was making its own inroads and there were several people working on various angles of it (Kaffe, the Transgaming company, Classpath, Japhar and much more). The fact that a full Java later struggled is a topic worth debating, and I have put some thoughts in a recent blog post here.
Now, that being said, I am amused by your suggestion that *I* have to work on the projects that *you* consider important.
If you consider free Java important enough, you should step up and make it happen (contribute code, time or money). Am surprised that I have to spell this out for you.
I actually find myself in agreement with this comment.
As I discussed on my blog (here) none of the reasons in the article seemed to go to the core of the issue.
The real issue here is having an "enterprise grade" Java implementation to go with the recent JBoss acquisition. I do not know if people routinely run JBoss on a full open source stack, but I would doubt that many people are willing to go that way, yet.
I said on the blog:
Now, on the other hand, everyone clamoring for Sun to open source Java seems to be tacitly admitting that free software can not compete in out-engineering a proprietary company if the proprietary company gives their goods for free, a point that I have made previously ("Fork in the Open Source Java world" and Open Source Java, Part 2). Tom Tromey did have an interesting follow up to my negative outlook (finding the post is an exercise for the reader).
JIT compilers translate the code to the target architecture just-in-time; Any use of the code afterwards is completely native.
Both Microsoft's.NET and Mono offer pre-compilation of code so that you can take out JIT out of the equation. In Microsoft this is done with the "ngen" tool, in Mono this is done by requesting Mono to batch compile the code with the --aot flag to "mono"
Mono is not a monolith, its made up of different components. Some of those components are completely supported and some are not (we did a detailed description in our 1.0 release notes).
Today the VM, C#, ASP.NET, ADO.NET, System.XML and the core from.NET 1.1 are very well supported and used by many commercial products and companies to deploy applications and services. Some other areas are not completed (Windows.Forms and some Windows-specific APIs) and some others are unique to Mono (Gtk#, Mono.Cairo, Mono.Data.* and a bunch more).
A year ago the Mono team was split in three to pursue different goals based on the team skills:
* Performance, scalability and hardening: effectively maintaining Mono, improving it and making it scale. This group is in charge of making Mono shine and make sure that our users have no complains about it, making sure that we fix bugs, rewrite code for performance, harden it and write tests.
* Windows.Forms: one of the areas that we do not support in Mono: a large undertaking as it effectively means authoring a new GUI toolkit and something that we had paid very little attention. Not as important as the server side components as we already had Gtk# for developers to use.
* 2.0 features: we started work on 2.x features as soon as Microsoft released the specifications to ECMA which was about six months before the 2003 PDC Conference. A complete 2.x VM is part of Mono today (1.1.9), a complete C# 2.0 compiler implementation as well as System.XML 2.0
You are right that in the 2.0 universe we are missing some bits, mostly on ASP.NET 2.0 and a few of the new classes in System and System.Data. Although they are elaborate projects, none of those are impossible. Compared to the work that we have done so far it is certainly a small fraction.
I run the Mono project, so I can speak for our goals.
And one of our goals is to be compatible with the.NET implementation. This is part of what we do on a day-to-day basis when we write unit tests for the APIs we are implementing, when we keep track of any possible difference and we respond to bugs filed on our bug tracking system where the behavior differs by fixing the differences.
But our goal is not limited to *only* being compatible with Microsoft's.NET. We have also grown outside of the scope of what.NET has to offer, and this is why you see a very healthy ecosystem of libraries and applications *around* Mono which are not limited to being compatible.
We created Gtk#, the toolkit we recommend for new applications that are to be cross platform; The enhanced XML stack (Commons.RelaxNG and Mono.Xml.Ext), our extended security and cryptography stack (Mono.Security), our extended Database support (Mono.Data and all of the providers for proprietary and open source databases), our IL manipulation library (Cecil) and everything that goes with these libraries.
We try to make our libraries cross-platform, because the same code will reach more users and helps grow our community, but every once in a while we have to create OS-specific libraries. For example, the Mono.Posix library is not completely portable to Windows. The Cocoa# library only works on MacOS X, as it is designed to be just an interface to Cocoa.
There are a number of cross-platform commercial applications that run on Mono, for example:
* Novell's own iFolder client and servers (same code base, modulo UI which is native on each of the three platforms: Linux/Gtk, Windows/Winforms, Cocoa/OSX).
As for your question about what will happen when C# 2.0 comes out, we have good news, we already have implemented it (we are missing two fairly minimal features though), for details you can see our web page on the subject:
Generics, itereators, anonymous methods, nullable types, partial classes, per-accessor modifiers, static classes, fixed buffers and co/contra-variant delegates are all implemented and available today.
And we can not wait to implement the new features in C# 3.0
Slashdot Mirror
Either the quote is wrong, or I had was distracted when I said so.
The runtime was developed entirely by Mainsoft, with some help from us in a few areas. Microsoft was not involved in this process, am sorry for the miss-understanding.
The runtime and compiler were pretty much done before I was aware of any discussions between Novell and Microsoft. The major change since September has been that the compiler became self-hosting on Linux (compiles itself, and compiles its own runtime) and that we have had a chance to go from a research project to a product (of course, we will keep improving it)
Miguel.
We have been able to run code compiled with Microsoft Visual Basic for a very long time (1.0 was supported for a few years with the old runtime, and 2.0 has been supported for a few months with our new runtime).
But there were a few problems, ASP.NET for example would requite a compiler on the host to compile VB.NET-based ASP.NET pages. ASP.NET works by translating special commands and tags into your language and mixing your code with the resulting output with a technology called "CodeDOM".
So this particular scenario (ASP.NET with VB) was not supported due to the lack of a compiler.
This also allows Windows developers to do their work on Linux directly without having to use two machines to develop.
Miguel.
Yes, this does run on OSX Intel.
Our compiler and runtime are written entirely in portable CIL code that later gets translated into native code on each platform by the Mono JIT.
I believe you are referring to Microsoft's Visual Basic for applications (which is what Office uses) and which is an older version of the language which they are unable to port on its current shape (their stuff was an older version of the compiler that predated the CIL bytecodes).
Miguel
According to our statistics, based on 1,500 applications that have been submitted using the Mono's Migration Analysis, 50% of the VB.NET applications do not depend on the operating system.
From the remaining 50%:
25% would require a week or so to port (replacing Windows library calls with Linux calls)
25% would require a month of so to work, and a Linux expert in house
25% would require a strong commitment to support Linux, and many months of work.
25% is not even worth attempting.
Miguel.
Your understanding is incorrect.
/ 08/update-on-openxml-at-iso.aspx
There is a 5 month technical review period to iron out technical details and to get the standard through the balloting process:
http://blogs.msdn.com/brian_jones/archive/2007/02
Nat went to China in September of 2005 and brought a bunch of electronic gadgets that he bought over there.
Among some of the gadgets that he purchased were various music/video playback devices (I forget the price, 30 dollars?) that he bough in Beijing, these devices were not up to the standards of beauty of the iPod, but mp3/video devices in China predated the video ipod.
What I found funny about one of these devices is that it was labeled "ipod".
Apple would introduce the Video iPod a few months later.
Miguel
Another comment: although we would like to take credit for being there "first" when it comes to desktop search on the OS, we were not the first ones, we were just earlier than Spotlight.
We did not know when we built Beagle about the applications being shipped on the Windows space, but we were told at some point about "X1" for Windows. X1 is now known as Yahoo Desktop Search and the product was launched in 2002 (www.x1.com)
Nat Friedman and myself demostrated the "Dashboard" (http://www.nat.org/dashboard) in August 2003 at OSCon. Tim O'Reilly liked the idea so much that he started asking Apple to implement this feature. At the time, the major limitation to make the "Dashboard" useful was that we lacked a search infrastructure on the desktop. So we set to build this infrastructure (Jon Trowbridge, now at Google, lead the effort at the time). And we pitched our plans repeatedly at a number of conferences as we were trying to get momentum behind Beagle.
This is became the Beagle Desktop Search (http://beagle-project.org/Main_Page) which was available from SVN since its inception and developed in the public. The first public demo of Beagle in action (using the dedicated UI, and integrated into the file system chooser) was done in Norway in June of 2004.
Funnily enough, the first public demo of the Beagle desktop search was presented six hours before Steve Jobs did his presentation of Spotlight on Monday 28th (Nat was in Norway, Steve in San Francisco). There was minimal press at the Gnome Users and Developers Conference, compared to the Mac event:
http://2004.guadec.org/schedule/
Some early history of Beagle is available on Joe Shaw's presentation from this year's GUADE Conference:
joeshaw.org/Beagle-GUADEC2006.pdf
I could not find the GUADEC videos online anymore, but I have a copy at work of the Ogg streaming at the time.
That being said, as an open source developer, I do not find anything wrong with copying concepts that work.
Miguel
Mono has complete support for RelaxNG in the form of the Commons.Xml.Relaxng assembly.
In addition to RelaxNG, it provides NVDL and RNC support.
The "5 year" is miss understood.
It means that any software that is developed within the next five years and is included with SUSE and might infringe on any patents filed by Microsoft up to the end of the agreement will be covered by the agreement.
This means that if software is written in 4 years, 300 days that is shipped with SUSE it would be covered forever for any Novell customers. Software that infringes on *new patents filed after the end of the agreement* would not be covered.
Miguel
This is actually inacurrate. In Red Hat's case, as stated on their service contract:
http://www.redhat.com/rhel/details/assurance/
So everything is fine up to points (i) and (ii). The problem comes if the technology is deeply embedded enough that it can not be simply "replaced" or "modified to become non-infringing".
Per the service agreement that customers are signing up to with Red Hat, they would be forced to "obtain the rights necessary for a customer to continue its use of the software without interruption".
So the contract actually contradicts Red Hat's Mark public statements.
Miguel.
The Winforms application that you tried to run is a 2.0 Winforms application, as the error reports: /usr/lib/mono/gac/System.Windows.Forms/2.0.0.0__b7 7a5c561934e089/System.Windows.Forms.dll, referenced in assembly /path/to/Test.exe
SharpDevelop currently uses Windows.Forms 2.0, which Mono currently does not support.
We will start work on Winforms 2.0 soon, SharpDevelop should work when Mono 2.0 comes out.
I'm not suggesting that you should have wasted your time with developing Java if you didn't want to. However, as I remember it, you were a big fan of the language but didn't care for the fact that it wasn't "free" as in "libre". Yet you jumped on the chance to develop Mono even though anything Microsoft touches is suspect by definition. RMS himself scolded the Mono project for even suggesting putting it onto the critical path.
You are confusing specification from implementation.
TCP/IP is a specification. There are open source implementation, and proprietary implementations of it.
C, C++, Java, C#, they all came from proprietary vendors and now open alternatives exist. Unix and the Unix APIs that we use today, were designed and implemented by a proprietary company. C, C++ and Unix btw, were all designed and implemented by the hated-monopoly-of-the-day.
Regarding the implementation of a completely fresh VM instead of
The funny bit of course is that you seem to be OK suggesting that I should have worked on Free Java in 2000 (Java, btw, still proprietary) instead of
Which leads us back to your point of implementing something from scratch. Well, many people have done so (Parrot, Squeak, LLVM and countless others), if you like those, use those, contribute to those, you should stop obsessing with what I eat and watch your diet instead.
miguel.
Just a few corrections.
.NET 2.0 we are working towards that goal, the core libraries are complete, System.XML is complete and ASP.NET and ADO.NET are halfway there. Today, pragmatically we tell people that if they depend on 2.0 we do not make any guarantees, but many projects have already moved to .NET 2.0, particularly those that build and test with Mono (as they know what is available and what is not right away).
Mono has an optimizing JIT compiler for a number of architectures (x86, x86-64, Itanium, SPARC, SPARCv9, S390 and S390x mainframes, PowerPC and StrongARM) and works on a variety of operating systems beyond Linux, MacOS and Windows (see our web site for details).
Regarding
These projects include Banshee and MonoDevelop, they are both using our C# 2.0 compiler with generics now (which we have had complete for a long time).
Now the open source ecosystem created on top of Java is just fantastic, it has created a lot of really innovative pieces. Apache in particular has become a highly efficient machine that pumps out useful code, most of it written in Java.
You could either accept that there will be diversity in the form of languages, runtimes, frameworks and libraries and live a happy life, or you can try to embark yourself on a crusade to evangelize the entire world to use your favorite technology and become a bitter old man (or a bitter teenager).
Peace and Love,
Miguel.
Free Java was making its own inroads and there were several people working on various angles of it (Kaffe, the Transgaming company, Classpath, Japhar and much more). The fact that a full Java later struggled is a topic worth debating, and I have put some thoughts in a recent blog post here.
Now, that being said, I am amused by your suggestion that *I* have to work on the projects that *you* consider important.
If you consider free Java important enough, you should step up and make it happen (contribute code, time or money). Am surprised that I have to spell this out for you.
Miguel.
As I discussed on my blog (here) none of the reasons in the article seemed to go to the core of the issue.
The real issue here is having an "enterprise grade" Java implementation to go with the recent JBoss acquisition. I do not know if people routinely run JBoss on a full open source stack, but I would doubt that many people are willing to go that way, yet.
I said on the blog:
The recent beta of IronPython exposed some bugs in our 2.x VM implemnetation, luckly they have been fixed.
Download 1.1.13 (available now).
I added a few of my thoughts on my blog:
http://tirania.org/blog/archive/2005/Dec-28.html
Not really.
.NET and Mono offer pre-compilation of code so that you can take out JIT out of the equation. In Microsoft this is done with the "ngen" tool, in Mono this is done by requesting Mono to batch compile the code with the --aot flag to "mono"
JIT compilers translate the code to the target architecture just-in-time; Any use of the code afterwards is completely native.
Both Microsoft's
Miguel.
Mono is not a monolith, its made up of different components. Some of those components are completely supported and some are not (we did a detailed description in our 1.0 release notes).
.NET 1.1 are very well supported and used by many commercial products and companies to deploy applications and services. Some other areas are not completed (Windows.Forms and some Windows-specific APIs) and some others are unique to Mono (Gtk#, Mono.Cairo, Mono.Data.* and a bunch more).
Today the VM, C#, ASP.NET, ADO.NET, System.XML and the core from
A year ago the Mono team was split in three to pursue different goals based on the team skills:
* Performance, scalability and hardening: effectively maintaining Mono, improving it and making it scale. This group is in charge of making Mono shine and make sure that our users have no complains about it, making sure that we fix bugs, rewrite code for performance, harden it and write tests.
* Windows.Forms: one of the areas that we do not support in Mono: a large undertaking as it effectively means authoring a new GUI toolkit and something that we had paid very little attention. Not as important as the server side components as we already had Gtk# for developers to use.
* 2.0 features: we started work on 2.x features as soon as Microsoft released the specifications to ECMA which was about six months before the 2003 PDC Conference. A complete 2.x VM is part of Mono today (1.1.9), a complete C# 2.0 compiler implementation as well as System.XML 2.0
You are right that in the 2.0 universe we are missing some bits, mostly on ASP.NET 2.0 and a few of the new classes in System and System.Data. Although they are elaborate projects, none of those are impossible. Compared to the work that we have done so far it is certainly a small fraction.
Miguel.
I run the Mono project, so I can speak for our goals.
.NET implementation. This is part of what we do on a day-to-day basis when we write unit tests for the APIs we are implementing, when we keep track of any possible difference and we respond to bugs filed on our bug tracking system where the behavior differs by fixing the differences.
.NET. We have also grown outside of the scope of what .NET has to offer, and this is why you see a very healthy ecosystem of libraries and applications *around* Mono which are not limited to being compatible.
And one of our goals is to be compatible with the
But our goal is not limited to *only* being compatible with Microsoft's
We created Gtk#, the toolkit we recommend for new applications that are to be cross platform; The enhanced XML stack (Commons.RelaxNG and Mono.Xml.Ext), our extended security and cryptography stack (Mono.Security), our extended Database support (Mono.Data and all of the providers for proprietary and open source databases), our IL manipulation library (Cecil) and everything that goes with these libraries.
We try to make our libraries cross-platform, because the same code will reach more users and helps grow our community, but every once in a while we have to create OS-specific libraries. For example, the Mono.Posix library is not completely portable to Windows. The Cocoa# library only works on MacOS X, as it is designed to be just an interface to Cocoa.
Miguel.
There are a number of cross-platform commercial applications that run on Mono, for example:
.NET applications and various commercial applications.
* Novell's own iFolder client and servers (same code base, modulo UI which is native on each of the three platforms: Linux/Gtk, Windows/Winforms, Cocoa/OSX).
* (http:///www.medsphere.com) Medsphere's products (Mono/Gtk# based).
* Otee's Unity game engine (http://www.otee.dk/index.html).
You can look for the "Works with Mono" logo on open source
For a larger but still incomplete list, see:
http://www.mono-project.com/Software
As for your question about what will happen when C# 2.0 comes out, we have good news, we already have implemented it (we are missing two fairly minimal features though), for details you can see our web page on the subject:
http://www.mono-project.com/CSharp_Compiler
Generics, itereators, anonymous methods, nullable types, partial classes, per-accessor modifiers, static classes, fixed buffers and co/contra-variant delegates are all implemented and available today.
And we can not wait to implement the new features in C# 3.0
Miguel.
Seems fairly simple to intercept those calls and map them to managed code.
We might evaluate interception on a case-by-case basis.
Miguel.
Have you tried using Monodoc? We have documented most of the Gtk namespace, and most of the underlying libraries (Gdk, GObject).
There are a couple of missing pieces like the Accessibility Toolkit (Atk) or Pango, but we are working towards finishing it.
Miguel.