[Mono-list] FAQ additions - One (crazy?) guy responds...

[Jay Freeman (saurik)]

OK, seeing my last post actually get through the system made it obvious to
me what happened, I sent it as an HTML e-mail and the system doesn't strip
out the HTML in the HTML e-mail (as I have gotten to the point of expecting
it to except on the lists dominated by windows people).  I've made sure that
I don't send HTML to the list any more by telling my client that mono-list
only receives plain text, sorry about that.  If the moderator could kill the
really large one, that would be handy.
--------

Seeing as I am sick of coding for the night, and got intrigued by some of
these questions, I thought I might answer them.  No one likely cares, but if
you are interested, go ahead and read on.  I'm also not that afraid of being
yelled at, so I'm likely to answer some questions than casual list readers
would, and more bluntly than Ximian would feel confortable with.  I'm also a
Windows developer, have been working with .NET for a year now since the
initial pre-beta release, have written a C# decompiler for the first Beta of
the technology, and feel confortable saying that I know more about the
technical aspects of this technology than many of the open source Unix
developers who are likely on this list.

I removed the questions that have to do with politics that I don't really
understand (specifically Red Hat and some of the internal operations of
Ximian) as I don't really have a good comment on them.  To the people on my
net-tech mailing list, I cross posted this there as I thought some of you
might be interested and might not yet be on the mono-list (if you aren't,
you might want to look into getting on it: http://www.ximian.com/mono/ ).


1. Why should we direct such considerable resources to such a marginal and
risky project? Aren't these precious resources better directed elsewhere?

I left this one for last, and I don't have the strength to answer it.  Even
thinking about it gives me a headache :-).  Besides, I don't really have
anything good to say for this one.


2. Can't MS thwart Mono by creating technical or intellectual property
roadblocks?

This is really determined by what your success metric for Mono is.  They've
already released a lot of their IP to the ECMA.  As for technical
roadblocks, yes, they would (trivially, not even leaving specs) be able to
keep their own products from running on Mono.  I don't think anyone really
expects to be compatible there, anyway, so let's cut to the chase: what if
they do something to fork the developer community.  This is what they seem
to have attempted with Java (although I don't know if we can directly fault
them for a bad implementation of libraries and a want to have better COM
interop), and they managed quite nicely before Sun shut them down.  This
_is_ a large issue, and if anyone claims otherwise, says anything about how
specifications will be everyone's ally, they haven't thought through the
problem of "who requires users to follow specs" much.  In some ways it is
the same thing that Netscape used originally to gain browser superiority
(adding background color to tables and other such things were Netscape
extensions, Netscape didn't care much about standards until they were on the
butt end of these issues) and then that Microsoft used to take it away from
them: add a few features that make your version easier that can't easily be
implemented in someone else's version without breaking it and you have them.

It all comes back to a rather fundamental principal:  some things are not
easy to port.  Back when the PDC bits came out and it didn't look like
cross-platform was all that much to think about (the way to look at it was
"it simply isn't going to happen"), I started looking at the System.Net
classes.  I had been working on a COM networking abstraction for a _long_
time (long enough to be fooled by early reports that COM+ was going to be an
entirely different development experience that I lost a few months of
development to waiting for it to happen, and then not being able to figure
out if it happened yet or not), thinking through how streams should be
supported, coming up with a way that end-users would be able to customize
applications written using the streams system... I had quite a bit of stuff
on paper.  This had all started because I had run into major, fundamental
problems with MS's Winsock control, and couldn't find a replacement that
worked the way I wanted it to.  I had constructed a few initial releases of
the socket component and released it to people online as a preview, and
reports were very positive.  This wasn't something I was doing for a day
job, so work was going slowly on this project.

Then I hear about MS's .NET, and how it was going to be a very, very
redesigned set of classes that would revamp VB (the rest didn't click yet).
The first thing I did was take a look at the socket libraries.  First off,
they didn't do very well.  Really, as far as I'm concerned, it was a step
_backwards_.  I wanted to have events from the socket ripple forward through
different streams to fire events on the other end, now we weren't even going
to have a good event-oriented base for recieving network events at all.  I
put together the more technical issues together and sent them in an e-mail
to the DOTNET mailing list:
http://discuss.develop.com/archives/wa.exe?A2=ind0009B&L=DOTNET&P=R11720 :,
and got contacted by a MS representative (partly because I expressed
interest in a job with them, then to talk about aspects that might be
improved in the library).  Apparently the main reason they went this way was
for later cross-platform support.  If they went the Winsock 2 way, later
implementation on Unix would be almost impossible (Unix's sockets haven't
advanced much in... well, they haven't).

If Microsoft wants to fork off an incompatible suite of .NET applications
and related developers, all they need to do is start implenting forking
points such as this.  Winsock 2 support in the framework would rather
quickly cause Unix framework developers massive headaches (it could be done,
but it would take a long time and it would require a good amount of overhead
to simulate some of the abstractions at a higher level) and split off a
number of network developers if architected to make development much easier.
System.Windows.Forms is already rather highly adapted to their GUI (as this
was never considered an important piece to port using), but it could be made
more so.  The general idea is: find some low-level glue that maps to
something in the OS and, rather than either mapping it to the Unix
compatible APIs that Microsoft has been dragging around with them for years
now or building a general abstraction that would make it easy to port to
other OSs later, map it to the Windows specific APIs that handle that
feature instead.

To me, the most important thing for Mono to do is to just implement the
standards, and maybe even then extend it _themselves_ to better take
advantage of Unix with a System.X.Forms or System.GTK.Forms or whatever
anyone wants to call it.  This would promote the usage of the standards, and
also generate people who want to write applications for _just_ Unix using
.NET rather than being forced into most simple of the levels of abstraction
that exist in the core.  As for this goal, Microsoft doesn't have much power
over it.

It _is_ important to realize that MS's implementation isn't even going to be
up to spec for V1.  One such example (as was mentioned on the DOTNET mailing
list recently) is the 1024 byte limitation of class names and the such.
These small (limiting!) incompatibilities, if not noticed soon and pointed
out strongly, could cause future issues.  In this way, by starting now, Mono
is doing something important.  However, Rhys (the owner of Southern Storm,
Ltd., mentioned in question 18) has been working on this for a _while_ now
(started at the end of last year using the PDC bits, although put most of
the work on hold until Beta 1 was out) as well and already initial
implementations of such tools, thereby lowering the importance of the Mono
project for this purpose.  I have also been spending time implementing
metadata libraries that are compatible with MS's interfaces to make things
easier to port (as well as to feel more confident that future changes to
lower-level formats aren't going to cause problems with the higher-level
interfaces).


3. Don't existing open source projects offer capabilities equivalent to
.Net? Can't we use them instead of mono?

Surprisingly (?), no.  Most open source efforts at runtimes have been
implementations of JVMs or specialized VMs for other languages (such as the
Smalltalk VM that was mentioned earlier on this list).  All this has done is
furthered the split between language camps.  There is a good amount of code
out there written in Perl that I currently can't easily use from a C++
application, and a ton of C code that I can't easily use from a shell
script.  The only people in the open-source world who have put any effort
into integrating the development arenas has been the GNOME project (which
includes Ximian).  The idea there was that, by using CORBA to abstract
object representation, people could write code in one language and easily
use it in another.  The problem with this is that CORBA does this by
providing very high level abstractions of data types that need to be
martialled down to whatever you are working with.  Also, there aren't many
good, open source (or even just $0) ORBs (which are what broker the data
type conversion) available.  CORBA simply wasn't designed to be what GNOME
was trying to use it as: a response to Microsoft's COM.  CORBA was designed
as a networking protocol (where the overhead of the network will assuradly
surpass any overhead from martialling), and was starting to get in the way
despite the efforts of the GNOME group (especially one developer whom I
believe I remember being named "Michael") to slim it down to the bare
essentials.

Another project to look at is Intel's ORP (about which I will cover more in
your question #18).


4. What are the commercial alternatives to Mono?

In as much as the attempt to allow for developers to utilize programming
languages together efficiently, pretty much just Microsoft's implementation
of .NET.  There have been a number of smaller scale attempts to allow for
VMs to take over, but they were all concentrating on a very small target
market segment.  The main one that I know of is Omni..something.. that,
interestingly enough, was bought by Microsoft :-).


6. What level of performance can be expected? What if Mono can't achieve
that level of performance?

The expectation is that you should be able to get near native performance.
Various Java VMs in the past have shown that, when done right, this isn't
that far out there, as has Microsoft's Beta versions of .NET (which should
only get faster as they near release and start lessening the debug code).
If Mono can't achieve this level of performance it will be quite a loss to
the open source development community (as they will not be able to feel
confortable writing all of their code for this architecture), but it won't
neccessarily cause _too_ much harm to Mono itself.


7. MS is releasing shared source on FreeBSD. Isn't it better to convert to
FreeBSD rather than fight the .Net battle? Isn't the gain in open vs. shared
source too small for such a major effort?

I, at least, _am_ switching to FreeBSD.  There is something important that
needs to be pointed out here, however.  It doesn't seem obvious yet (to me,
at least) whether the "shared source" implementation will be available for
usage on production systems for corporate purposes.  In interviews that have
been conducted with the implementation team, it has been mentioned that the
"shared source" implementation will not be for academic usage only and not
for corporations' usage.  The way it has been worded has reminded me of
applications like Netscape (other examples aren't coming to me now for some
reason, but I come across them all the time... some anti-virus packages for
instance) that could be used at home but not in a corporate environment.
This clause may just apply to the usage of the source code itself, however;
thereby making it so that the code can't be used in a corporate project and
sold.  What makes me second guess that interpretation is how eerily similar
that is to GPL (where you can use the code for anything as long as you don't
try to use it in a closed source project), with only a few extra limiting
cases (companies in a business like Red Hat's thereby ending up in a squidgy
middle ground).


8. Isn't Mono a foil in negotiating .Net licensing for Linux? Won't mono
project be dropped if .Net for Linux is licensed?

This is likely not to be the case.  It is important to understand that, in
the standard "cathedral" vs. "bazaar" comparison of closed vs. open source,
"free software" (which GNU advocates, and is also the stand Ximian is
behind) is best brought up as a "protest" or a "crusade".  It isn't enough
that someone writes software, or even that they release the code for it.  If
it isn't under a truly open license that preserves the freedom of the code,
or at least capable of being converted into a totally open license that
preserves the freedom of the code, then the work isn't done.  Now, Ximian
might get a lot less interesting from Ximian programmers if it isn't far
along before Mono exists on Linux, but it definitely won't get "dropped" by
the entire community.


11. Is the real purpose of Mono to counterpunch MS?

I would say "no".  While there are many reasons to adopt a frameowork like
.NET (some of which I've already touched on), I would claim that the "real"
purpose of Mono is to save GNOME.  GNOME made a lot of promises initially.
While they have come up with a great desktop environment, many of these
promises haven't been made good on, and don't look like they will if they
continue the direction they are going in.  A few weeks ago a few Red Hat
engineers made some rather low-voiced announcements (partially prompted by a
website that claims that a talk will be given about it in Auguest, a fact
which the engineers responsible claim was a mistake...) about a new
architecture called Hub that would allow for speedy in-process components to
be built (no more overhead than a virtual function call, the same overhead
that COM has), yet still allow for some aspects of cross-language ability
(much like COM).  Whether it is just going to be COM with a few
modifications, or whether the entire project will now be scrapped is
anyone's guess.


12. Isn't Mono important only because .Net will be popular?

Well, right now *nux doesn't really have anything that compares well.  Java
_could_ have taken this spot, but Sun is overly sensitive about their
technology and isn't going to make the modifications required to allow for
great things in .NET to boost them as well.  A big reason for this is that
it would invalidate their existing byte code, the consistency of which they
consider tantemount to their success: how can they convince people that Java
should run on everything if they keep changing the design and no one can
keep up?  They were even advocating getting it running on hardware for a
while (which, unlike .NET, it has some hope in accomplishing).  If a new
binary format came out later that was required to access new features, their
empire might crumble.  It's a pitty, too.  Had they marketted themselves
slightly differently they might have been able to be stronger at this point.


13. Is MS trying to bash Linux by offering .Net on BSD? Isn't it a divide
and conquer gambit? Is it really about licensing terms?

While I want to agree with the "divide and conquer statement", I really do
feel Microsoft's pain when it comes to the GPL.  There is an important point
to make here:

A while back I was contacted by a Microsoft engineer about my decompiler who
was offering me support with it (I ended up asking him to help me with some
potential legal problems I was having with another Microsoft employee as a
result of working on Unix ports and ended up losing contact with him, so
none of this ended up working out, but...).  One of the things he was asking
was if I could change the license from GPL to LGPL which would give them
more "room" to help.  On one hand, there is the possibility that this is a
decree from higher-ups that GPL shouldn't be gotten near with a 10,000-foot
pole.  Another is that they actually wanted to incorporate my decompiler or
some of its code generation routines (which I've been working on improving)
into Visual Studio and wanted it to be easier to accomplish.  A third
interpretation (one that I find very likely) is that they simply didn't want
to have any legal problems themselves.  If, at some later point, they
accidentally use my code (no matter how small or trivial) or some idea of it
that ends up producing very similar algorithms (as this is uncharted legal
water), they may accidentally throw all of their code under GPL.  At least
with commercial code they could be sued and put under a restraining order,
at worst have to remove the code and pay damanges, as they would have
violated some license term that states "don't use this code".  In the case
of the GPL code, there is no legal rubberband to snap back on them, they
have now released something under GPL and are violating license to _not_
release the code.  This is not an acceptable risk for any closed-source
company to take.

As for me, all code I release for my decompiler and such from now on (as I
haven't gotten any code from anyone else yet and still have all of the
copyright) will be under a modified BSD license.


14. Do we really know if .Net achieves an acceptable performance level?

Yes, we do.  It exists, and it works very, very well.


15. Isn't Sun's controlling attitude responsible for MS need for .Net?

Initially, yes.  The history of C# and .NET can be seen back many years now.
I actually have a book sitting next to me copyright 1997 ("Active Template
Library: A Developer's Guide") that has an appendix that goes into many of
the issues relating to .NET.  It then goes on to show a snippit of code that
looks as eerily simple as MC++ that is apparently how it will be handled
"with COM+ support".  There is also overwhelming (and obvious) evidence that
C# is in fact COOL, a language that MS was working on as an alternative to
Java to solve their problems.  The "COR" designation (COM Object Runtime)
can be traced back to at least 1999 in header files shipped with the
Microsoft Platform SDK (specifically, IMAGE_DIRECTORY_ENTRY_COR_DESCRIPTOR
comes to mind).

MS may very well have attempted to adapt Java to serve their purposes rather
than creating .NET, but the result would have been just as incompatible with
Java and therefor just as much a separate entity as .NET is.


16. If Mono succeeds, who are the winners and losers?

This is a quite difficult question to answer.  One thing to point out is
that Microsoft's motives aren't very clear.  To make a blanket statement
like "developers do", or "everybody does" is quite naieve.  You have to look
at everything that is being done as a cohesive unit, and see how it
interconnections... Complexity Theory relates as much to Microsoft as it
does to any other group of people.  I started answering this question after
answering question #17, so there will be a small amount of overlap, and then
you should just read that one for the rest.

It looks like MS's strategy right now is one of a magician.  This is
something that even some media sources are starting to pick up on.  They are
making loud noise in one arena to make it seem like everyone should be
looking there, while quitely taking control over something entirely
different.  One big aspect to this specific trick is that it doesn't matter
where software is running as components become services.  Just because you
have a Unix web server doesn't mean you aren't still using MS's
authentication technologies.  If people don't look more closely at this
aspect of Microsoft's strategy all could be lost but for the want of one
battle.

If you haven't been payin attention to what Microsoft is doing, and have
been sitting around working in your Unix desktop environments with your Unix
applications and feel content with your software, I urge you to look at
where Microsoft is taking the 90% of the population who don't even
understand what Unix is.  Hotmail is being integrated with Outlook Express,
MSN Messenger is being integrated into Office, and Passport is being
integrated into everything, including the OS.  When everyone has a Passport,
it is going to be much easier to start sliding websites over to this
architecture.


17. This is a MS play. They'll win no matter what.

Not really question, I guess I can answer this with: "true"?  The bigger
question is: what is MS's play?  My guess is that they want to control the
services.  Open source operating systems won't matter much once the hardware
becomes closed, a move that is already in the works.  This is all really a
shell game to keep people from paying attention to the important moves that
MS is making:

A) Microsoft has been hard at work in the area of content protection.

One of these efforts is in signed drivers.  Originally signed drivers were a
way to allow users to know that such-and-such a driver was actually written
to play well with other drivers (something hardware manufacturers are
terrible at if left to their own devices).  The way this would happen is the
driver would be sent to Microsoft or one of their affiliates to be verified.
Lately, more and more requirements have been tacked on.  An example:  to
have a signed audio driver, you must provide a mechanism to deactivate
digital outputs when copyrighted audio is played.  The same concept goes for
DVD's, you can't have non-encrypted digital outputs (such as current LCD
panels) or non-macrovision encoded TV outputs active while playing
copyrighted DVDs.  Having this support in the driver, of course, isn't
enough, the software must tell these devices to deactivate.  Microsoft Media
Player is one such software application.  If you attempt to play copyrighted
music to a non-signed driver with the newest versions, it simply won't play.
Same goes for DVD's through both Microsoft's current software (as well as a
few other popular brands, such as Intervideo).

OK, so you just don't use Microsoft's software, right?  You build your own
OS, and you use your own tools.  Nope, not going to help.  Just try to
support the encrypted channels that exist in the next line of LCD panels
that are coming next year if you can't license the encryption technology to
include with your OS.  Even worse, some companies are looking into adding
this technology to rather standard hardware such as hard drives.  As
mentioned on Slashdot a few months ago, IBM finally decided against adding
content protection (can't store copyrighted files, and won't talk with
drivers that don't support telling it about copyrighted files) to its IDE
drives; unfortunately this was only because Pheonix came forward with plans
to add similar technology to the BIOS itself, something much more
fundamental to an OSs execution than a new series of hard drives.

B) Microsoft seems to be more about the services.

One of the failed companies I have been a part of over the last year and
half was one designed to compete with Microsoft's Passport by being a more
powerful system that would be available on more platforms (with the
connector bits being open source so it could be ported into everything
rapidly, we're selling a service here, not a 50k piece of software) called
Data Universal.  Part of it was to securely store user data in the
databases, giving end-users more fine grained control over who has access to
what data, even later being able to use this to slowly force websites to
understand that someone's name isn't even a required element of their data
in most cases (long term, interesting goal).  This is the same kind of goal
as HailStorm.  I have spent long enough thinking about this to know about
the power of this technology.  If you don't believe what it can do if done
right, watch the episode "Please Press One" of the television show
"Sliders".  A short synopsis can be found here (
http://greene.xtn.net/~lucast/sliders/season5/please/episode.html ), and
yes, our company _was_ based on theirs :).  We simply felt we could do it in
such a way as to not end up as bad (besides, the point was to start a
company, and they seemed to be rather successful... right?... right?!?).  I
also urge you to read
http://www.thestandard.com/article/0,1902,27685,00.html , "Microsoft Could
Hold Passport to Net", a recent article from "The Standard".



18. What is ORP and why is it being considered for a VM?

ORP is a project that has been put together by the Microprocessor Research
Laboritory at Intel.  Part of the reason it is being looked into is because
I have been telling Miguel about it for many months now (although it would
have been run across anyway, as it was brought up on the mono-hackers list
if you read through the entries for last month by a developer who hadn't
heard of it before and was likely just combing for related projects),
initially due to a project I was trying to get support for (failed at this)
to write a Unix implementation of .NET based on it, hopefully with Intel's
support.  If anyone is interested in reading it for kicks, the best initial
project write-up can be found here in my mailing list archives:
http://lists.saurik.net/message.xsp?id=62 .  The e-mail is in response to
one sent to a mailing list for another of the earlier projects that was
started by a company in Australia named Southern Storm, Ltd.  Their project
can be found here:  http://www.southern-storm.com.au/portable_net.html .

Something to point out is that ORP isn't really a "JVM" (as someone else who
just responded to this question said), Intel doesn't call it that, and I
wish other people would stop as well (as it makes people think that it is
_just_ Java technology).  ORP is a VM, "initially" designed to support Java
byte codes, that has a clear seperation between runtime, JIT, and GC.  The
idea is to allow for research to be done on better JITs and GCs without
requiring a new runtime to be written (which severely taints any performance
data).

Because of this architecture, ORP is ideal for writing a cross-platform JIT,
or for slowly improving a GC over time as newer methods come into existance.
Intel is already considering support of the CLI, as indicated in a recent
presentation at Java Grande 2001 (you can get the slides from this
presentation from the files section of their sourceforge project at
http://www.sourceforge.net/projects/orp/ ).  So far they have a codebase
licensed under a BSD-type license that runs under both Linux and Windows
(using Visual Studio, not requiring cygwin or some other porting layer), and
have a JIT for IA32.

Working with Intel has an added benefit of giving credibility to the
project, both in the eyes of end users but, more importantly, to
corporations looking to use .NET technology in their infrastructure (who
take more note of this kind of thing than your average techie).  This
involvement has, in the past, been incredabely effective, as is seen by
Sun's involvement in some of the Apache XML technologies and IBM's support
of Linux in general.


19. Isn't .Net vaporware?

No, it currently exists.  I'm running it right now and am working on
building a few applications using it.  Hell, I've already written a
decompiler for it :).


20. If mono succeeds, won't MS quit sharing source?

Is that really a big deal?  If we everyone already has the source they need,
then if Microsoft stops sharing it there isn't any big loss.