Mono 2.0 is out!
Today we
released Mono 2.0 to
the world. You can download sources and binaries from
our download
page. And our
official release
notes are up as well. This of course would not be
possible without the open source contributors that worked
tirelessly on Mono sending patches, fixing bugs, helping the
community, answering questions, creating test cases and
supporting us all these years.
Mono 2.0 is both a runtime for application and a kit for developers for writing applications with C# and other ECMA CLI languages for a wide spectrum of uses.
Big thanks go to the fantastic Mono team at Novell that has kept the excitement and the pace over all these years (we started in 2001), the large contributions from Mainsoft, Unity3D and our users that pushed us to fix bugs, implement new features and tune Mono. Also, we very much appreciate the work of the ECMA 334 and 335 committee members that worked on the CLI and C# specifications and everyone at Microsoft that answered our questions over the years and specially those that licensed code under open source licenses.
We originally started to work on Mono, because we
wanted to make developers happier and more productive on
Linux. We liked C#, we liked the CIL and we wanted to have
those technologies available on our platform.
Since we have been active in the Linux Desktop world, it is not a surprise that the early use of Mono was mostly on Linux desktop applications, and Mono continues to shine there. Server-side use of Mono was a natural evolution and we soon were powering ASP.NET sites on Linux.
There is one area where we under-delivered in the past, and it has been a constant source of pain. Up until now, we did not have a working debugger. This has finally changed, and Mono 2.0 includes for the first time a debugger, the time for WriteLine() debugging is now behind us.
As the project matured, developers started taking advantage of Mono's open source nature: essentially .NET on their own terms. A platform that could be adapted, morphed, ported and modified to suit many different uses. Today Mono is embedded in portable mp3 players and powers Unity3D's game engine on the Apple iPhone, the Nintendo Wii, MacOS X and Windows (And Unity3D is soon coming to Linux!).
It has also been deployed to run code on large clusters of servers for SecondLife, powers our open source Silverlight implementation (Moonlight) and powers the popular DekiWiki: a Social Collaboration Tool.
Mono is a large project and it is hard to pick one feature to talk about as there are so many, so instead I put together a quick table of the major features that are part of this release:
| Compiler Support | .NET APIs | Mono APIs | |
Mono's Open Source Compilers:
|
Core API:
|
GUI APIs:
Mono Core:
|
We have ported Mono to a wide variety of platforms and operating systems on this 1.0 to 2.0 cycle. These platforms include:
- Linux (x86, x86-64, PowerPC32, Itanium, SPARC, ARM, s390, s390x.
- Solaris (x86-64, SPARC).
- MacOS X (x86, PowerPC32).
- Windows (x86, support for x86-64 will come in Mono 2.2).
- Nintendo's Wii.
- iPhone/iPod Touch (ARM, limited functionality due to licensing requirements; I will blog later this week about this).
- *BSD (x86, x86-64).
Developing with Mono
Long time Linux developers will probably continue to use Emacs and VI, but some new Linux developers might want to use an IDE. New developers can use our open source MonoDevelop IDE on Linux, or alternatively the commercial X-Develop IDE or SlickEdit.
If you are a Windows developer, you can continue using Visual Studio or your IDE of choice to write the code and compile it. Your binaries will run just fine on Linux.
To assist Windows developers in porting their applications to Unix, we have provided the Mono Migration Analysis tool.
Runtime Changes
The Mono Virtual Machine gained plenty of features since Mono 1.2 was released. We have added:
- Generic Code Sharing and VTable Compression have been implemented: this significantly reduces the use consumed by generic type instantiations, while still getting the speed benefits of using generics.
- AOT support: in addition to x86, we now also support ARM and x86-64.
- COM interop is now complete (works on Windows with "real COM" and can be used on Unix with Mainsoft's COM or Mozilla's XPCOM).
- AOT code can now AOT parts of 2.0 assemblies (assemblies that contain generics).
- Full AOT support (allows code to run JIT-less, this is limited to 1.0 code).
- CIL Verifier: Now Mono has a CIL verifier.
- CoreCLR Security: the security system used by Moonlight.
- Many optimizations that improve execution performance: New intrinsics operations (Math.Min/Max for example); various operations are now inlined by the JIT; managed allocations (no transition to unmanaged code for allocating memory); multi-array access is now tuned by the JIT; constant and block initializations are now handled by the JIT; Faster initialization and access to multi-dimensional arrays (4x faster).
- The runtime went on a diet, many runtime data structures are smaller making Mono lighter.
Tools
In addition the the Mono Debugger making its debut appearance on this release, we are very proud of our code analyzer Gendarme.
Gendarme is a extensible rule-based tool to find problems in .NET applications and libraries. Gendarme inspects programs and libraries that contain code in ECMA CIL format (Mono and .NET) and looks for common problems with the code, problems that compiler do not typically check or have not historically checked.
Feedback
Mono is not perfect, but we want to improve it. Like many other open source projects, we need your bug reports to improve Mono. If you have problems with Mono, help us by filing a bug report.
Special Thanks
Special thanks to Hacker Extraordinaire Aaron Bockover who not only brings us the best media player in the world, but created the new web site design and implemented and tuned it over very long extra hours up until 7am in the morning on his weekend.
And to our packaging and QA team that spend extra hours to get all the bits and pieces in place for the release.
Five Second Linux Boot
I loved this LWN article on the changes necessary to make Linux boot in 5 seconds on the Asus EEE PC (a relatively slow computer).
Hopefully all Linux distributions will adopt these changes for custom deployments.
Moonlight Update: Media Codecs
A couple of weeks ago we started the work on porting Microsoft's Media Codecs to Linux and we got the C version running.
Popfly in Firefox3/Linux/x86
Geoff, Fernando and Rolf have been hard at work on this, and have also added the infrastructure to download and install the codecs on demand.
The next step was getting all the assembly language supported in Linux, and today Geoff got the assembly optimized SSE1 audio decoder running (the first chunk of the decoders).
Of course, the rest of the team has been busy fixing bugs and improving the performance in preparation for the first public beta of Moonlight.
Microsoft changes the Managed Extensibility Framework License
A couple of weeks ago I suggested that developers interested in having their .NET software run in other platforms should avoid Microsoft's Managed Extensibility Framework (MEF) as it was not an open source library.
I had a chance to discuss with Glenn, Sam and Bob the benefits of using the MS-PL for this library first over twitter and then over email.
Representing .NET's loyal competitor, I did not think that we stood a chance of getting Microsoft to change the license, but I was pleasantly surprised. Glenn understood the value of open source, Sam wanted to do the right thing about this library and CodePlex and Bob argued that Mono already had Mono.Addins anyways.
Today Glenn announced that Microsoft has changed the license for MEF to the open source MS-PL license.
Thanks to everyone at Microsoft that helped change the license!
DbLINQ, LINQ to Databases and Mono
Atsushi Enomoto blogs about the work involved in bringing LINQ to Databases to Mono.
The effort was a joint collaboration between the awesome DbLINQ developers, Pablo Iñigo Blasco our Google Summer of Code Student and Novell's Atsushi Enomoto.
The DbLINQ developers had created a general purpose LINQ provider that could be used with database providers other than SQL Server. They also relicensed their code a few months ago to the MIT X11 license to allow for integration with Mono's code base.
Read Atsushi's description of how the effort was put together and how DbLINQ is being refactored to become a full System.Data.Linq implementation and still provide the foundation for third-parties to easily create database LINQ providers.
DbLINQ is a great project, and it needs your help to complete the effort.
Mono at the PDC 2008
Great News Mono Lovers!
Later this month I will be presenting the session "Mono and .NET" at the Microsoft Professional Developers Conference in LA.
Exciting times!
Update: My talk will cover new technologies that we have created as part of Mono. Some of them are reusable on .NET (we try to make our code cross platform) and some other are features that specific to Mono's implementation of the CLI.
Microsoft to incorporate jQuery into Visual Studio
This weekend the news came out that Microsoft was going to bundle and support John Resig's jQuery as part of Visual Studio and ASP.NET. From Scott's blog:
I'm excited today to announce that Microsoft will be shipping jQuery with Visual Studio going forward. We will distribute the jQuery JavaScript library as-is, and will not be forking or changing the source from the main jQuery branch. The files will continue to use and ship under the existing jQuery MIT license.
Beyond the obvious benefits to developers, what interests me is that Microsoft is now bundling an open source component into their commercial offerings.
This is a first time for Microsoft.
With IronPython they continued development of an open source project in house. With IronRuby, they were open to external contributions to the libraries of IronRuby. In both cases they were not taking external code or contributions directly into their core products.
Hopefully they will start using more open source code in their products. Maybe one day they will bundle Mono's Cecil or Mono's embeddable C# compiler.
Monovation: Assembly Injection into Live Processes
People are loving the C# Interactive Shell.
In the past people have embedded languages like Boo into their applications (MonoDevelop and Banshee for example both have options to embed Boo and a shell).
Zoltan designed a new system for Mono that allows developers to inject and execute code into running Mono applications. Paolo provided significant feedback and design guidelines for the code to be incorporated into Mono.
Thanks to both Zoltan and Paolo this functionality is now available through the Mono.Management assembly: you provide an executable and a PID, and the executable is injected and its Main method executed on the target process:
using Mono.Attach;
[..]
// Get a handle to a running Mono process.
VirtualMachine vm = new VirtualMachine (pid);
// Load hello.exe into the target process, and run it
vm.Attach ("/tmp/hello.exe", "");
You can use this for billions of things of course. You could patch running programs, you could attach logging software to a running program, or you could inject a C# evaluator into a live application and examine its state, or tweak it live.
Zoltan came up with a really cool extension to the the csharp command (this is the command-line C# Interactive Shell). The csharp command now takes an --attach command line argument and a PID.
The csharp shell can now use the Mono.Attach.VirtualMachine to injects itself into the remote process and then the client and server communicate through a couple of sockets.
For example, this is the sample that Zoltan used to pitch his idea for supporting attaching to the virtual machine. With the following you can pause a live Banshee process:
$ ps aux | grep banshee miguel 12359 17.0 2.7 141372 55708 pts/5 Sl+ 14:30 0:02 banshee-1 /usr/lib64/banshee-1/Nereid.exe $ csharp --attach 12359 csharp> using Banshee.ServiceStack; csharp> using Banshee.Gui; csharp> var s = ServiceManager.Get(); csharp> s.PlaybackActions ["PlayPauseAction"].Activate ();
All of the code is now on SVN, you need both the mono and mcs modules from trunk.
A GUI Shell
The above commands are a tiny bit risky and are also limited to the shell.
The above commands will execute on a separate thread from the application, and any commands that you execute would be executed on a separate thread which could corrupt the state of your application.
So this weekend, I wrote a tool that integrates with Gtk# applications, its called gsharp and you can find it in the mono-tools module (it borrows some code from Banshee).
gsharp is a Gtk# version of the csharp command. What is important is that it also supports injection of the code on other programs, but makes sure that all the code executes in the Gtk# thread, by issuing all of its commands from the Gtk# idle handler. This means that it is safe to use gsharp with your Gtk# applications.
GUI version of the tool.
Here you can select which project you want to inject the GUI into:
Needs some work, show process names.
This version shows the gsharp tool attached to F-Spot, as I am not very familiar with the codebase, I can not do very much with it:
We will need to implement one of these as well for Windows.Forms applications. This should luckily be easy to do as most of the smarts live in the Mono.CSharp assembly (our embeddable compiler).
Security of Agents
A couple of weeks ago, I asked for people to weigh in on a security concern for temporary files. This was for Zoltan's attach functionality.
The code is now implemented and I would love if security experts could do a source code audit of our implementation. And validate whether our assumptions are safe.
Here is the source code.
Public Service Announcement
In C# the defaut access level for members in classes and structs is "private".
There is no need to pepper the source code with "private" everywhere. It only introduces noise and makes your code more difficult to read.
Love World Domination!
Chris Anderson is wearing a Mono T-Shirt on this PDC interview and IronRuby.com is hosted on DekiWiki, a Mono-powered Wiki site.
This is clearly awesome.
In other news, the awesome hackers at Imendio have officially released Gtk+ for OSX packages.
Stream.CopyStream
Funkists, why does System.IO.Stream not have a CopyStream method, it seems like everyone ends up implementing this.
Discuss.
reCaptcha.NET
Kudos to Ben and the rest of the Captcha team.
Today I downloaded the binaries for reCaptcha.NET for a web page that I was setting up and it worked out of the box. No recompiles necessary:
- Drop the Recaptcha.dll in the bin directory of the ASP.NET app.
- Get your public/private key.
- Insert this in your page:
<recaptcha:RecaptchaControl ID="recaptcha" runat="server" Theme="red" PublicKey="YourKey" PrivateKey="YourOtherKey"/> - Hit refresh. Ta da!
Encrypted File Systems
I just found out about encfs, a user-space encrypted file system that runs on top of FUSE.
To use it, just type:
$ encfs ~/.encryptedstorage ~/secure
And follow the directions. You then will have a ~/secure directory where you can stash all the material that you would not want to become public if you were to lose your laptop.
But it gets better than this. You can use sshfs to store files on a remote server, and then use the sshfs-backed file system as your encrypted storage, you can then keep your files stashed on a remote server, completely encrypted.
Mono team, hiring again
Hey folks, it is that time of the year when we are looking to hire some developers to work on Mono.
We are looking for people with experience in Linux, with experience building software from source code and good C# or Java skills. Experience with ASP.NET and ADO.NET is a plus.
The positions this time are only available in Boston, if you are interested, send me an email.
Update: we have filled this position.
Securing a Unix Domain Socket: Looking for Help
There is a cool hack that we want to introduce in Mono that would allow a remote process to debug a examine data in a running Mono instance. The hack uses the embeddable compiler.
The proposed extension to Mono would use a socket on /tmp/mono-USER/.mono-PID created by the Mono process and set the permissions to read/write for the owner and nothing for the group or other users.
What can go wrong security-wise with the above setup? What should we check that is not immediately obvious?
So far:
- Create directory with 0600 permissions, bail if mkdir returns anything but 0.
- Create socket in directory; It should be safe at this point, and change the permissions of the socket (is this really needed?).