You do get LINQ, we have supported it for about 10 months now in production (starting with Mono 2.0).

We are missing LINQ to SQL, but it will be bundled with our next release (Mono 2.6) or you can get it from the dbLINQ project today.

Right, "Type Erasure" means that none of the semantic information is preserved in the produced bytecode or metadata.

This has several problems, for example, the following is invalid in Java:

class Stack {
        T [] storage;

        Init ()
        {
              storage = new T [20];
        }
}

You might want to read "Generic Gotchas" for Java. There is no such problem with the C# version as they are first class citizens:

http://www.ibm.com/developerworks/java/library/j-jtp01255.html

The implementation is so arcane that it requires documents like this encyclopedic FAQ:

http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html

Or even Sun's Ken Arnold stating that "Generics are a mistake":

http://weblogs.java.net/blog/arnold/archive/2005/06/generics_consid_1.html

None of this problems happen in C# and .NET.

I cant be incompetent and at the same time succeed in derailing Linux application development. Pick one.

Your rage prevents you from making a cogent argument though; I did not "derail" any application development, if anything, I created a project that many people seem to enjoy using.

The fact that you can not tolerate that others do as they please, and that you feel that people need to obey is merely a manifestation of your fascist tendencies.

Both the JVM and the CIL engines can be used to run any programming language you want. They are both turing complete systems, so there is not really anything that will prevent you from targeting any language to run on top of either one of them.

The difference is that the JVM was designed for Java, and Java only.

The CLI originally ran a variation of C++ (they internally called it SMC, or "Smack") and later they created C# and retargeted VB to run on top of it.

But even before this went public, they launched an effort called "Project 7". The goal of this group was to port 7 proprietary languages and 7 research/open source languages to the CIL engine and learn from the exercise what changes were required to make the implementation more efficient. A large number of changes went directly into .NET 1.0, and they allowed the CIL to be a more efficient runtime for running C, C++, Eiffel, Fortran and Cobol than the JVM could. Direct memory manipulation, arbitrary vtable layouts, tail call optimizations all went into .NET 1.0

With .NET 2.0 a new round of languages was tried. The research on ILX and OCaml (mostly using F#) was introduced into the virtual machine, making generic types first-class citizens in the VM, not just entities that were emulated (as they remain to this day in Java). The feedback from Eiffel lead to the introduction of covariance and contravariance in the virtual machine, another feature missing from Java.

The work from Jim Hugunning on IronPython also drove the adoption of new low-level APIs that assisted the runtime in better supporting dynamic languages, all of these features appeared in .NET 2.0 and 3.5.

So certainly, you can target anything into anything else, at the end of the day, everything is running on top of some CPU. The difference is that with .NET you have to jump through less hoops, and the runtime is richer for language developers.

So in Java you can certainly emulate pointers and malloc for building a C compiler. The emulation will tkae the form of "Allocate big array, and emulate pointer operations there". Possible, but not very efficient.

Generics is another area that helped languages like C# get generics that actually make sense, and do not require a PhD to understand. This is an important difference: in Java generics are emulated, in C# they are native to the environment.

That being said, if you like Java, by all means, keep using Java.

Additionally, there are some glorious bindings for Qt called Qyoto now.

The Qyoto bindings power the very pretty Synapse IM client, it is worth taking it out for a spin, because the author has gone the extra mile to make his application good looking and very smooth:

http://eric.extremeboredom.net/2009/03/15/336

That was a research paper on ILX from 2001.

The research work from ILX was folded into .NET 2.0 and is part of ECMA 4th edition.

All of the instructions that you listed are deprecated, they never really made it into .NET, their much improved, polished and battle field tested versions did. And they are the foundation for C#'s generics support and Don Syme's F# compiler, both which run just fine in Mono today.

Of course, anyone who thinks they can "design-around" a patent will claim that the patent is not actually "necessary" to the desired function. In order to enjoy this "promise" you have to confess that the only way to achieve the standard is to infringe on a valid MS patent.

Another potentially worrying point is this exception:

So..., anyone who even "participates" in a patent suit against MS (including, presumably, a patent suit filed by MS), loses protection for not only their own products, but anything they "use." For example, if FSF got into a dust-up with MS, MS could still claim infringement by FSF (or anyone else) for using Mono, even though MS has chosen not to pursue the authors of Mono or other Mono users. Referring to it as a "personal promise" also calls into question its applicability to businesses/organizations.

I am being overly paranoid, but the fact is, like so many other legal "promises", the value of this one will only be seen in the implementation. As a cynical lawyer, I don't see anything here that absolutely precludes MS from asserting infringement by Mono or any other OSS project. If Microsoft truly wanted to be benevolent they could easily make a much broader promise with less grey area. For example, they could name the patents that they claim to cover the specs in question and offer royalty free licensing, or make a non-assert pledge with some actual teeth. All they are saying here is "we probably, maybe won't sue you unless we do."

The current Silverlight 3 preview release supports in addition to the proprietary codecs a pluggable framework for developers that wish to do so to use their own codecs.

As part of the Moonlight effort we now have implemented Vorbis, Theora and ADPCM and have a partial implementation of Dirac almost ready to use.

Our codecs work in both Silverlight 3 and our open source Moonlight implementation.

This means that the specifications can now be used to implement third party implementation and can be used by open source efforts to recreate Flash.

In the Silverlight world that was already possible as Microsoft publishes pretty much all of the specs necessary to implement Silverlight.

Both the Flash plugin from Adobe and the Silverlight plugin from Microsoft are proprietary products. Gnash, Sfwdec and Moonlight are open source implementations of these technology.

I agree that Visual Studio is a very nice tool.

Luckily the code that you produce with Visual Studio will run on Mono (no recompilations necessary) including code that uses ASP.NET MVC. And with the new support for ASP.NET precompiled sites in Mono (available in Mono 2.4) you do not even need to copy the source code to your target server.

Click "Publish" in visual studio, enter the location for your shared directory, and you have a fully working ASP.NET MVC app running on Linux, without leaving Windows.

We are working on various integration points for Visual Studio that will give developers even more: debugging from Visual Studio remote applications deployed on Linux systems and producing packages ready-for-distribution on Linux.

ASP.NET MVC runs on Mono 2.4 out of the box.

Not only does it run, but you can now install a MonoDevelop plugin that will provide all the tooling to get the Linux developer experience to match the Visual Studio experience for MVC development.

It is quite sweet.

Silverlight supports Firefox as well as it supports IE on both Windows and MacOS.

I do not remember the last time I even used IE on Windows to browse the web, and there have been *no* sites that use Silverlight that fail under firefox (we try a lot of them when looking for the "next sample to get working on Moonlight" from http://silverlight.net/Showcase).

If what you were implying though was that Moonlight 2.0 was not ready to run Silverlight 2.0 content, you are right. Moonlight, the open source version of Silverlight is not yet ready to render all of the 2.0 content, but it is very close to it.

Perhaps the Portugal government would like to fund the accelerated development of Moonlight by hiring a few developers to assist the project. That seems like a win-win for everyone involved. Faster Moonlight 2.0 and 3.0 and the warm cozy feeling that they made the world a better place.

Moonlight exists because we were able to put a prototype together in 21 days (you can read about our hack-a-thon here: http://tirania.org/blog/archive/2007/Jun-21.html).

Microsoft has since helped us by providing licensed codecs that can be used by Linux users; Providing us with Silverlight specs for a full open source impleentation (Although 100% of it is available on the web at msdn.microsoft.com) and they provided us with test suites to ensure that Moonlight passes every single Silverlight test suite that Microsoft uses internally.

No two implementations will be 100% compatible. In fact even fixing a bug means that version a and version a.0.0.0.1 with the bug fixed are not "100% compatible", so there is not much point in arguing about 100% compatibility in the first case, it is easy to prove that this will never be the case. But in that regard, no piece of software will ever be (not the kernel, not the browsers, not anything that ever gets bug fixed as a platform).

But we can get very close to the indented behavior as articulated in the test suites "This is what it is supposed to do as far as -we- humans could guarantee". There will certainly be bugs, but we do not have a problem fixing those, and the Microsoft engineers have been very helpful in answering any questions we might have.

Nuclear submarines, and especially ballistic missile submarines, don't communicate with anyone at sea unless it's absolutely critical. Communicating gives away your position, and for such submarines, the fact that nobody outside the hull knows exactly where it is is their number one means of survivability. In addition, ballistic missile subs don't have 'allies' - they treat even the surface and submarine forces of their own navy as 'potential hostiles' when at sea in order to maximize their survivability and to continually train to avoid such threats.

Collisions between submarines were fairly common during the Cold War, and were indicative of the amount of time subs spent playing 'hide and seek' with their opponents - because in order to gain intelligence on other submarines, or even to follow them reliably, subs have to be quite close relative to how long it takes them to stop or turn. As a result, however, most collisions were between or involved attack submarines. For two SSBNs to involved in such a bump, either one or the other had to be involved in SSN-like games, or pretty astronomical odds were just surmounted in a random collision. It's a big ocean. It'll be interesting to see precisely where the damage to the two boats is, as it might tell us what aspect they collided at - I have heard it was a slight angle from head-on. Even that doesn't meant they weren't playing silly buggers - if one submarine turned to check its baffles and the other didn't maneuver out of the way, that could result in an angled head-on.

Apple has now offered us a pay-to-play 'option' which fixes the display they broke in the first place (you can get matte as an option on the new 17" Macbook Pro for I think $50 but I'm not sure).