[Mono-list] Philosophical Question - Why .NET on UNIX?

[Lluis Sanchez]

Hi,

No offense, but what I thought when I read your mail and your first
reply to Alan is that you had no clue about what .NET/Mono is and how it
works. I guess that the other people that replied had the same feeling.
If you find the answers obvious, then you clearly failed in explaining
your message.

Let me summarize some of the statements you made that lead me to believe
your lack of knowledge of .NET/Mono:

> What I don't understand is why MONO just *followed* Microsoft down the
> questionable path of Java.
> A principal purpose of .Net of course was to defeat Java because
> Microsoft was losing so many developers to Java, but not because
> Java was better than other object oriented alternatives such
> as Delphi or C++Builder

My conclusion here was that you didn't know what the Mono project was
about. The Mono community *do* believe in the path initiated by Java and
later improved by Microsoft (that is, in a managed, language agnostic,
portable, object oriented development platform). That's why the Mono
project was created. The question of "why Mono just *followed*
Microsoft" doesn't make any sense, since Mono *is* an implementation of
Microsoft .NET, for the good and for the bad (of course Mono is not only
MS.NET. We embraced, and we extended it).

> Another reason I believe Microsoft followed Java is that Microsoft
doesn't
> want to abandon it's greatest security risk -- ActiveX -- and, that
> because they will not do that, they will never understand how to build
a
> secure OS. What sense does it make then for UNIX/Linux to follow this
path
> (...)
> Adhering to a concept of transmitting only data between web
applications
> wholly eliminates the need to follow the COM/ActiveX pattern

My conclusion after those statements is that you have a great confusion,
because you are talking about technologies which are not related at all
with Mono. Mono has no relation at all with COM/ActiveX. So the question
"What sense does it make then for UNIX/Linux to follow this path" does
not make any sense by itself.

> Assumably, abstracting support for the .Net libraries within an
equivalent
> .Net environment running on Linux/UNIX is approximately the same thing
as
> reorganizing that support so .Net code runs *NATIVE* on Linux/UNIX. In
other
> words, the overhead of supporting native .Net executables 
> running far faster than Windows counterparts running as IL is 
> theoretically little different: Libraries, and their relationship to 
> a compiler, are simply organized somewhat differently.
> (...)
> Thus if engineers working with .Net implementations originally
intended for 
> Windows .Net could run the same code base, or even a restricted code
base
> or roughly similar code base, as native executables on Linux/UNIX, 
> obviously *that* is a place we *really* want to go today.

My first reaction after reading this was to think that you didn't
know .NET/Mono compiles IL into native code on the fly, and that there
are tools which can convert portable assemblies to native libraries. The
sentence "running far faster than Windows counterparts running as IL"
was specially misleading, as IL is never interpreted, but compiled to
native code. In fact, when you install .NET on windows, all assemblies
of the framework are compiled no native libraries. Maybe you already
know all this, but everybody reading that paragraph will believe the
contrary.

> One obvious security vulnerability (assumably of all .Net
implementations, 
> because all implementations generate IL), is that the very IL will
regularly 
> pave the way to security breaches. Likewise, IL makes it very
difficult if not 
> impractical to protect intellectual property.
(...)
> The .Net environment imposes relatively basic security measures. Yet
keys
> can be stolen, signatures can be impersonated, new assemblies can be 
> distributed to impersonate others... etc..

You don't say it, but I assumed here that "IL will regularly pave the
way to security breaches" because it is easy to decompile. It made me
smile because you are using the same argument that some people use to
attack open source, saying that it is less secure because everybody can
read the code. I know that not all code is meant to be read by people,
but it made me smile anyway.

You then talked about keys being stolen, signature impersonation and so
on. This seemed a really poor argument to me, since those security
technologies are not specific of .NET, but they are used everywhere. If
you don't rely on keys, signatures and certificates, you should stop
using SSL, SSH, GPG and many other technologies.

All this also made me believe that you didn't know what is CAS, and how
it can help running untrusted code in a secure way.

> Well thanks for the tip, but imho, "managed" is quite an overstated
virtue or
> advantage.
> (...)
> What is the ostensible advantage of ForEach? Underneath your call to
ForEach 
> is an iterative process which has to make the well known, routine call
to
> iterate count minus 1. The same thing has to be done. There's nothing
managed
> for you at this level. If the count changes before iteration is
complete, the
> only thing you can hope to account for that is the compiler -- and I
think it
> should be clear that isn't necessarily anything that the compiler 
> should assume. If this can happen in your case, it is your
responsibility 
> to anticipate that and use an appropriate structure.

This paragraph made me believe that you don't know the meaning of
"managed", because the fact that .NET/Mono is a managed platform has
*nothing* to do with language features or compiler tricks.

> Now, if you're trying to tell me MONO runs as fast as Cocoa on OS X

Yet another sentence that people will interpret as a deep lack of
knowledge of what Mono is. Mono can't be compared to Cocoa. It's like
asking if Python is faster than Motif. Nonsense.

So, summarizing, the impression I got is that you had a superficial idea
of what .NET/Mono is. Maybe it's a wrong impression, but that's what I
believed after reading your mails. 

And yes, after all this I really felt the need of teaching ABCs before
discussing other more advanced proposals.

I also came to the following conclusions:

      * You don't see any benefit on the fact that .NET binaries are
        portable across platforms.
      * You think that the security measures that .NET provides are
        useless, including the sandbox.
      * You don't believe that the protection that a managed platform
        provides has any advantage.
      * You don't think that a language-agnostic platform such as .NET
        is of any use.
      * You also don't believe that developing with .NET/Mono is more
        productive than developing in other platforms (after all, the
        productivity you get from a development platform is the sum of
        all its features, including the previous ones in this list).

The Mono project was created because we believe in all those values. If
you don't believe on them, Mono is clearly not for you.

Lluis.

El dt 03 de 07 del 2007 a les 08:56 -0700, en/na mike montagne va
escriure:
> 
> 
> This is utterly ridiculous. All these things are obvious. I mean,
> suggesting I join a Delphi forum? (previous post) As if somehow I
> hadn't participated in so many for so many years -- or a guy who has
> possibly the most marked up copy of CLR via C# extant doesn't even get
> the basic concept of .Net yet. I think there's a better thing to do. .
> 
> You people evidently have your goals quite set, and that's quite fine
> with me. Obviously I understand that Mono is not a browser technology.
> My concern is *running* *anything* that does anything more than
> *render* something in my browser (or anywhere else) -- and therefore I
> consider all the overlappings of .Net dedicated to running *anything*
> I don't *know* about conclusively as a potential risk.
> 
> That's all. But that's a big thing to me. Still, I my purpose in
> mentioning this was to point out a division -- MS is betting on
> diverse executables everywhere; the succeeding, competing browsers are
> excelling because they are providing ways to *cut off* *all* those
> kinds of things... right down to JavaScript (mentioned too just as an
> example of *the extent* of the *desirable* protection from these
> executables). That spells an opportunity to me -- an opportunity to
> point sights at a place down the road where instead of multivarious
> styles of web development tolerating *any* number of executables, we
> have found we better tolerate no unknown executables, and perform all
> rendering with a known application and/or its plugins. To this, this
> forum replies *color is unnecessary,* as a defense of those
> executables? 
> 
> That's very interesting, not because it is enlightening (of course),
> but because it comes from this forum.
> 
> I also understand of course that we don't have to use .Net for these
> things -- my mail sufficiently emphasized that as well. My point
> was... well, actually my full point might seem offensive. I didn't
> intend that. Now we're defending Mono by thinking we're teaching ABCs;
> and obviously this is going nowhere.
> 
> Good luck to you all. It's been an experience.
> 
> 
> 
> Andreas Färber wrote: 
> > Mike, 
> > 
> > In short, you are mixing up concepts. 
> > 
> > First, the CLI is not ActiveX. To my knowledge Mono does not have
> > dependencies on any COM replacement technologies. 
> > 
> > Second, the big difference between C#/Java and Delphi/Pascal/... is
> > not the C-like-or-not syntax but the managed environment it's
> > executed in, replacing null pointer references previously leading to
> > immediate segmentation faults with exceptions the program can easily
> > handle. Mono and .NET handle many languages, not just C#. 
> > 
> > Third, .NET is not just a replacement for Java. It fixes many
> > limitations Java still has and C#/VB.NET introduced some nice
> > aglnuage features which Java got only afterwards (1.5). Java is
> > still lacking a convenient bridge algorithm like p/invoke (JNI is
> > not an equivalent, it compares better to embedding Mono). 
> > 
> > Fourth, in your argument that you don't want JavaScript and ActiveX
> > in your browser you are completely missing the point that Mono is
> > not a browser technology. It can be used for exactly what you
> > expressed a wish for, transmitting data from one location to another
> > without rendering. 
> > 
> > Hope this clarifies some things. 
> > 
> > Andreas 
> > 
> > 
> _______________________________________________
> Mono-list maillist  -  Mono-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list