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

[Alan McGovern]

Hi,

I've left some comments inline. Also, sorry about the double email, forgot
to CC the list first.

In other words, I have thought from the beginning that the Microsoft
> philosophy is wrong. In fact knowing the weakness of accommodating unknown,
> interoperable objects well has permitted me on several systems to survive --
> without ever deploying anti-viral ware -- literally probably more than a
> million Windows viruses, with none ever unleashing. The trick to this has
> been wholly disabling ActiveX -- whereas Microsoft's interests in .Net are
> making that more impossible every day.
>

But .NET has built in security measures which prevent malware of any kind
from taking over your system. Silverlight, the new browser plugin, contains
a new simplified security system which makes it very difficult for anything
to overtly install itself. You can't even access a file on the hardrive
without going through a trusted path which (i believe) means popping up a
file selection dialog for the user to select the file in.

My Firefox installations for instance are always configured not to run
> JavaScript. Even as I occasionally approve some JavaScript manually, I
> regularly object to much of its usage. It's plain unnecessary. But it is
> others' business if they do these things, and I do expect browsers to remain
> available which continue to provide means of eliminating potentially
> unwanted executability of any kind.
>

Lots of things are unneccessary. Coloured text is unneccesary. Hyperlinks
are unneccessary. Colour images on web pages are unnecessary. However all
three are very useful.


I have found particularly that even relatively straightforward graphics
> processes are extremely poorly performant compared to the tools I recently
> left behind.
>

I hope you weren't accessing the pixels one by one using GetPixel and
SetPixel. They are known to be very slow and are the reason why the unsafe
LockBits() method is offered which allows you to directly access the bytes
of the image and write c-style code which is every bit as fast (or at least
has the potential to be).

Theoretically however, the C# (reference/handle based) approach is an
> equally advantageous way of building applications, if compiled into native
> executables.
>

C# is compiled into a native executable when it is launched. There are also
tools out there which generate native executables from CIL code. Sometimes
these tools generate code that runs slower than if the code were just
JIT'ed. So technically speaking, CIL code *always* runs "natively" on your
platform of choice.


As a result, i don't think your proposition has actually proposed *anything*
that mono doesn't already do. Unless of course you were actually proposing
that the whole Mono framework is rewritten in C or C++ or whatever non-CIL
language of your choice and a thin c# wrapper is placed over that to provide
interoperability with existing .NET libraries. If that's what you're
suggesting, you obviously have completely missed the benefits gained when
writing in a managed language.

Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-list/attachments/20070702/23957cac/attachment.html