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

Miguel de Icaza miguel at novell.com
Tue Jul 3 01:44:01 EDT 2007


    This discussion seems to be now offtopic to the forum.   Am not sure
what is the relevance of this discussion about Javascript with .NET on

    If you do not need .NET on Unix, then this forum is not for you.  In
the same way that a forum on "Women issues in Chiapas" is probably not
interesting to you.   

    You seem to like Delphi very much, may I suggest that you join a
Delphi group?  

> 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.

You seem to be lumping together a bunch of unrelated concepts under the
"security vulnerability" umbrella.   

You will need to explain what you mean by "IL will regularly pave the
way to security breaches", because as it stand, that statement makes no

As for protecting intellectual property, I do not wish to be pedantic,
but intellectual property is a catch-all expression that is often
misused.   People usually mean one or more of copyright, patents and
trademarks.   My guess is that you might be worried that people can
decompile your code and find your secret sauce.

Secret sauce probably made sense 20 years ago, but today there are very
few new sauces and we all know how to make pesto or even better how to
find the recipe to make pesto.   And if you really have a secret sauce
and people want to get to it, chances are, they will get to it
regardless of whether you used IL or x86 assembly.

> An example of the former for instance would be an enterprise
> application submitting password access for whatever purpose. Even if
> encryption libraries are called, if the IL falls into the wrong hands,
> the data processed by IL calls into encryption libraries make it a
> relatively easy matter to break the ostensible security of the system.

You are describing security through obscurity, and that is known to be
among the worst things you can do security wise:


> A good example of the consequences is the imperative disabling of
> ActiveX. Even out of the box, Internet Explorer regularly fails to
> render content or processes on Microsoft sites. Crank up the security
> to where you should really have it, and good luck. 

The only secure network computer is a disconnected network computer.

Good luck with your browsing experience.

> .Net implementations on Windows are far slower than their
> native-compiled counterparts. Some claims are made that .Net math
> operations are something like 80% as fast as native operations, but
> these claimed cases are only possible if no boxing or unboxing are
> involved. 

Well, then do not box or unbox.  "Doctor, it hurts when I poke my eye".

> Well thanks for the tip, but imho, "managed" is quite an overstated
> virtue or advantage. Few C# developers probably truly know for
> instance what the best way is to implement dispose patterns. There is
> conflicting information on it. Visual Studio doesn't agree with
> Richter. Richter doesn't agree with another source I rely on. Then
> again, how many can expertly reply when and how to implement finalize?

It is trivial, you copy the documented pattern in the Framework
Guidelines (which are the same that ship with .NET).

> 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.

Foreach is actually six or seven different beasts, one of them is the
one you described.    It helps encapsulate a number of patterns for
iterating into a single expression.

I stopped at this point, as it seems like you are rambling without much
of a direction other than making a series of disconnected observations.


More information about the Mono-list mailing list