We are aware of a bug in the JIT compiler in the PPC, something that we are actively fixing.
(We do not officially support the MacOS X for this very reason: we are not done yet with the port, the technical detail has to do with the patching of generated methods to point to new methods that are JIT compiled on demand, and the issue there is that the PPC needs more room to do calls that span the +32/-32 meg barrier, so you need to build some thunks, not hard to fix, and on our todo list) The Mono C# compiler works on OS X, we use it to build all the class libraries and Gtk# as well.
The trick is that C# code is compiled to the Common Intermediate Language, so you compile in one platform, and you run in another one. All you need is a virtual machine running on the target system
We have turned Wine into a library, very much like Gtk+ is a toolkit on top of X, or Motif is a toolkit on top of X, we have turned Wine into a toolkit on top of X.
The reason for doing so is that Windows.Forms is not a perfect API, it is modeled after the Win32 API, and this Win32-ism is exposed at various points, for example every Control in Windows.Forms can override the Wndproc method and handle Win32 messages itself to implement some of the advanced features that are not possible with the simple binding provided.
Most GUI special effects are achieved in this way, and most third-party libraries that you can download from the network will call into the Win32 layer, skipping the Windows.Forms API.
It is certainly possible to emulate a lot of this without using Wine, but you would just end up replicating a lot of the work that has been done in Wine.
So instead, we chose to turn Wine into a library that we dynamically load whenever a component needs to use Windows.Forms.
We made Wine work on multiple platforms (so you can run your Windows.Forms applications on MacOS X for instance), and we also are integrating it with the Gnome desktop, so things look and feel the same to end users.
You can learn more about the technical details here: http://www.go-mono.com/winforms.html
We read with interest the piece from Neil on the purpose of Mono, and I wanted to clarify a few things, because Mr Neil does not seem to have looked at the Mono Roadmap, nor tried a recent release, since code signing (authenticode and strongnames is implemented, remoting is completed (soap, binary, http, tcp transports) and most of the side-by-side assemblies work is done, and will be part of 1.0).
The Mono Roadmap (www.go-mono.com/mono-roadmap.html) contains the release time frames for the various features of Mono and will help him and other readers understand what exact plans are: no speculation, and no half-cooked facts.
I am surprised by the motivation to do so little research on our project given that Mr Neil is the technical director of a company that sells.NET software; You would think that the use of Mono would help him reach customers using Linux, using mainframes or MacOS X.
Mono is based on the ECMA 334 and 355 standards. We like the C# language and its runtime (as does Mr Neil's company) because it increases our developer productivity, reduces the time to market of our new products, this despite the fact that we do not implement Code Access Security, which will only be used in embedded situations, a segment that we are not ready to address in Mono 1.0.
We want to improve the productivity of developers in Linux, mainframe and OS X developers by brining this unique platform to other platforms. Just like Borland, SGI, Sun and IBM provide compilers, runtimes and tools for other languages, we provide such a piece for C#/.NET.
Mr Neil does not seem to understand why bootstrapping a C# compiler is important, so let me explain this in terms he would understand: it is important because:
* Using C# to write a C# compiler means that it improves our
development speed.
* To be able to harvest the benefits of productivity of C# on
Unix, we need a bootstrapping system.
* It allows us to write software on Unix without and be
self-sufficient to develop software as opposed to require
a Windows machine to develop software, and another to run it.
* It means that we trust our technology enough and it is solid
to the point that a relatively complex piece of software not
only runs, but is binary-compatible with the Microsoft
runtime.
Mono's objectives are not "To break Microsoft's monopoly". We do not define ourselves in this way, there are more important social causes to fight. We look at the ECMA 334/335 standards as a solid foundation to improve Linux and bring more software, more quickly to it, and make the development process more fun.
Alessandro Forin used to work for CMU on the Mach kernel and presented at Usenix in 1994 a new file system that used FAT as its storage, and had been extended to support extended file names.
* There were never any Windows.Forms cooperation plans. Each group has chosen a different implementation path.
* We never pulled Windows.Forms out of Mono, we continue to develop it.
Your conspiracy theory on the marketability of Gtk# is pure nonsense. We develop Gtk# to build Gnome applications, we have no choice if we want to leverage all the platform code available.
We develop Windows.Forms and other APIs to remain compatible with code that people develop on Windows, and move it to Linux. As simple as that: Mono is not only a great platform to create *new* software with Unix-isms, it is also a platform to enable the growth of Linux by bringing the Windows people over.
Novell will continue to support KDE on SuSE, distribute its packages and maintain this offering which is a prime choice of people.
We will also integrate Ximian Desktop into their offering, because it is a more fine-tuned desktop than the default Gnome one, and leverages all the enterprise features we added to it.
NDS is part of the Linux Software Services stack that was announced for Linux earlier in the year. So do not worry about that.
Solaris does have a few areas where they have done a fantastic job.
For example, when it comes to debugging threaded applications, and having a reliable debugger, they beat us every single time. This is a mix of debugger support, kernel support, libraries support and god knows what else.
Their thread implementation is also very robust. I have no clue about their performance, but I know that you can depend on their implementations being robust. On Linux plenty of thread-related issues are still flaky (big progress being made there), but today, I really wish I had Solaris to debug a few problems.
And there are tons of other little things they get right. My suggestion is that we should focus on what is wrong in our platform, and focus on what is good in their platform, to find out what needs to be solved.
Man, the dude writing that stuff is sure one paranoid fellow. A paranoid fellow with little or no vision. No offense, but the guy is drowning in a quite empty glass of water.
Lets take the following premise:
`Mono succeeds, and Microsoft then changes the APIs so Mono can not catch up, hence Linux looses'.
Lets take a sample that is closer to us: Linux and Unix. Linux and GNU are implementations of a fairly popular and interesting technology: the Unix operating system.
Now, if the Unix creators introduced a new API, or changed a Unix API when Linux was successful, did that change the success of Linux?
For example, lets assume that tomorrow SCO introduces a new API call into SCO Unix, lets call it "hasuseraclue()" [1]. The system call is highly proprietary and undocumented. Now, will Linux and GNU users suffer from the lack of this API? I am going to leave that as an exercise to the reader.
[1] Note: by reverse engineering the code, we know that above system call return 0 when ran on the system of the author of the previous paper.
In a world where Mono is vastly successful, if Microsoft changes/introduce new APIs, do you think it will matter?
We will continue to implement the.NET APIs while they remain open, and will continue to use open protocols whenever possible (for example, our System.DirectoryServices implementation talks LDAP).
But Mono has not stopped at implementing the.NET APIs we have been actively implementing our own framework that maps into the Unix world.
For example, Microsoft has chosen XML Schema for representing, mhm, XML schemas. But the world of XML has been leaning towards Relax NG. Well, we implement Relax NG.
We implement Mozilla bindings, OpenGL bindings, Gtk+ bindings, Qt bindings, Unix bindings.
They implement support for 3 databases, we implement support for 11 databases.
Mono ships with plenty of other libraries, like a BigNum library and APIs to manipulate.NET binaries.
I love research, and more than anything I love the people involved in doing research: those who create, explore and can give us future direction. But I also believe that the research must be truthful if we want to build on it.
The Y presentation paper is interesting on the ideas it introduced (we could argue whether they are new or not, since NeWS did did before, in fact, with a more extensible system) but it fails on presenting X correctly.
The document goes on to show that the X-based approach has lead to major GUI fragmentation, and how the MacOS and Windows do not have this problem.
On the screenshots where X looks bad, the author shows some old graphics program running together:, xpdf and two modern apps: mozilla/xul and gnome calculator. All of those programs have Gtk-based or Qt-based equivalents that would have made the whole experience consistent.
The screenshot should instead be presented as a proof that X can still run applications that were developed 12 years ago.
Then he shows the Mac and Windows. Again, not really honest screenshots, because even Apple is shipping two different GUI views: the brushed metal theme and the aqua theme (this combination kills me) and Microsoft is not exactly known for keeping their GUI look consistent across their product line: Office, MSN and the rest of the desktop use different styles and widgets.
So summing it up: the screenshots are presented to prove a point which happens to not be there.
Now, to make things even more interesting, here is a little bit that the author of Y might not be aware of: widget rendering on MacOS X happens on the client side, and the operation that the server supports is basically "uptade-rectangle-with-this-RGB-buffer", there is no magic of server-side widget rendering on MacOS X.
Also, doing an X protocol translator is not an easy job, but I wish them good luck pursuing this new adventure, it defintely sounds interesting.
1. Measuring speed is difficult, but to give you an example, the Mono C# compiler compiles itself on 3.5 seconds (50,000 lines of code).
2. development is faster, I would say 3x to 6x depending on the task. In the case of ASP.NET vs J2EE, we know from two studies (ours and Forrester/Giga) that it is 20-28% more effective (see my blog for details).
3. Is it cross platform? Yes, it is. The Mono C# compiler was originally built/compiled on Windows. Today, it does not matter. We routinely run large applications (web services, console, gui) on it.
4. It offers plenty of functionality that is hard to find elsewhere: cross-language interop, unified GC/threading/io
5. Patents: the ECMA core has been freed of any patents, see: primates.ximian.com/~miguel/tmp/map.png
Phase 1: DotGNU and Mono announced on the same day by the FSF. Mono to work on the framework, DotGNU to do the more undefined parts of.NET. Whatever that meant.
At this point cooperation was not possible, because it turned out the DotGNU team wanted to invent a new virtual machine that supported Java and.NET at the same time. I could see this as interesting research, but not something I particularly cared about.
Then we were asked something like `you will work with us better than with proprietary companies'. This is ridiculous in that you cant make this kind of promises. Specially with a team of people (the DotGnu) who had no track record of writing anything of large scale. So to us, a relatively experienced team of developers, being told this by a team of self-appointed "core team" of unexperienced people was a non-starter.
Phase 2: Portable.NET bends over and accepts every wacky idea of DotGNUers. The idea here is that Portable.NET had to please the desires of the dotgnu kids, so a promise to support JVM binaries at the same time and generating code for both was made. They got this working to some extent, but again, its slow, untested, and very broken.
Phase 3: the code donation. Mono received under the terms of the MIT X11 license, a copy of the I18N code. A pretty small chunk of code, and lots of data files that come from the IBM ICU library (about 4k lines of code, plus 46k of data files).
This was the beginning of cooperation.
The cooperation did not last long, because even when we submitted fixes to them, and pointed them to new codecs, they decided to change the license of their code to GNU GPL, because they felt cooperation with us was useless.
Licensing:
We use the more liberal MIT X11 code, which they have liberally integrated into their code base, but since we are commited to eliminate any potential licensing problem that a proprietary software developer might have with Mono, we will not use the GNU GPL or GNU LGPL in our libraries.
We could not use PNet's code for two reasons: we just plain dont like the coding style (coming from the Linux/Gnome coding conventions), and second the reverse engineering that was done in Australia (what Norbert claims is ok) would put anyone distributing the software in the US under a potentially interesting legal situation.
It is our responsability to the contributors of Mono who have devoted tons of hours to it, and to the users to make sure that there is not the slightest potential legal problem with the code that would make their contribution useless. We dont want anyone FUDing in the future like its being done with SCO. So we had to have more strict legal procedures.
For instance, we recommended people not to look at Rotor source code until we had the equivalent Rotor functionality implemented. Pnet follows a different approach: read Rotor, and do a new implementation of it. Might be better for interop, but I sleep better at night:-)
Miguel.
Re:Looks too much like XP
on
Aethera 1.0
·
· Score: 2, Informative
AT&T Unix was never open source.
It was distributed to universities under a research license.
The lawsuit issue is more complex, because it was never discussed in court, instead USL and Berkeley settled the case.
Berkeley agreed to remove all the files that still contained ATT code. That used to be called "4.4 BSD Lite" which could not boot, as opposed to "4.4BSD Encumbered" which was a complete implementation.
The free BSD distros of today derive from BSD Lite 4.4
Projectors are usually a source of pain in Linux. I typically run my laptop at 1400x1280, some projectors are able to deal with 1024x768, but some others can only cope with 800x600.
Although my IBM laptop is better than the other laptops I had in the past when it comes to having various options on the output, it still falls short sometimes, and the output is chopped on the projectors.
What I do today is I keep 2 XFree config files, and I run a second X server at low-res during presentations, but I would definitely like to avoid this.
The red parts are components that Microsoft has not submited to ECMA for standarization and hence have no explicit patent grant. Whether there is an enforceable patent there is unknown, but is dubious, as for the most part they are wrappers to existing technology, or implementations of concepts already available.
The green parts are components that we have developed outside of the Microsoft world (they do not have a Microsoft equivalent). Whether there are patents or not is uncertain as they are also wrappers for existing technologies (Gtk, Mozilla, etc). Microsoft would certainly not have a Mozilla# patent;-)
C# and the CLI (ECMA standards 334 and 335) have no patent fees attached to it, it is completely patent free.
The ironic thing is that *today* the fastest fully open source Java VM that can run Eclipse is Mono plus IKVM.NET (the open source Java VM that generates CIL code on the flight;-)
Various publishers are working on books about Mono that will cover exactly what you want.
But everything you learn in Don's Essential.NET book applies directly to Mono. In fact, before Don joined Microsoft, he was kind enough to let us preview his book, and that helped us understand various internals of the.NET framework.
Mono is an implementation of the ECMA 334 and 335 standards which are available for anyone to implement (no patent strings attached, check the Mono FAQ for details).
On top of that Mono implements plenty of class libraries: both the non-standarized class libraries from Microsoft, as well as our own universe of class libraries that take advantage of Unix-specific features.
Slashdot Mirror
We are aware of a bug in the JIT compiler in the PPC,
something that we are actively fixing.
(We do not officially support the MacOS X for this
very reason: we are not done yet with the port,
the technical detail has to do with the patching
of generated methods to point to new methods that
are JIT compiled on demand, and the issue there
is that the PPC needs more room to do calls that
span the +32/-32 meg barrier, so you need to build
some thunks, not hard to fix, and on our todo list)
The Mono C# compiler works on OS X, we use it to
build all the class libraries and Gtk# as well.
Miguel
That is correct.
But we have. We support SPARC, SPARC 64 bits, HPPA (32 and 64), StrongARM and PPC in a wide range of operating systems.
The trick is that C# code is compiled to the
Common Intermediate Language, so you compile in
one platform, and you run in another one. All you
need is a virtual machine running on the target
system
The Mono team has grown as a result of the Novell
acquisition, from five developers to a team of
fifteen developers.
We are only working on Gtk# support.
You are incorrect.
We have turned Wine into a library, very much like Gtk+ is a toolkit on top of X, or Motif is a
toolkit on top of X, we have turned Wine into a toolkit on top of X.
The reason for doing so is that Windows.Forms is not a perfect API, it is modeled after the
Win32 API, and this Win32-ism is exposed at various points, for example every Control in
Windows.Forms can override the Wndproc method and handle Win32 messages itself to implement
some of the advanced features that are not possible with the simple binding provided.
Most GUI special effects are achieved in this way, and most third-party libraries that you can
download from the network will call into the Win32 layer, skipping the Windows.Forms API.
It is certainly possible to emulate a lot of this without using Wine, but you would just end up
replicating a lot of the work that has been done in Wine.
So instead, we chose to turn Wine into a library that we dynamically load whenever a
component needs to use Windows.Forms.
We made Wine work on multiple platforms (so you can run your Windows.Forms applications on
MacOS X for instance), and we also are integrating it with the Gnome desktop,
so things look and feel the same to end users.
You can learn more about the technical details here: http://www.go-mono.com/winforms.html
We read with interest the piece from Neil on the purpose of Mono, and
.NET software; You would think that the use of Mono would help
I wanted to clarify a few things, because Mr Neil does not seem to
have looked at the Mono Roadmap, nor tried a recent release, since
code signing (authenticode and strongnames is implemented, remoting is
completed (soap, binary, http, tcp transports) and most of the
side-by-side assemblies work is done, and will be part of 1.0).
The Mono Roadmap (www.go-mono.com/mono-roadmap.html) contains the
release time frames for the various features of Mono and will help him
and other readers understand what exact plans are: no speculation, and
no half-cooked facts.
I am surprised by the motivation to do so little research on our
project given that Mr Neil is the technical director of a company that
sells
him reach customers using Linux, using mainframes or MacOS X.
Mono is based on the ECMA 334 and 355 standards. We like the C#
language and its runtime (as does Mr Neil's company) because it
increases our developer productivity, reduces the time to market of
our new products, this despite the fact that we do not implement Code
Access Security, which will only be used in embedded situations, a
segment that we are not ready to address in Mono 1.0.
We want to improve the productivity of developers in Linux, mainframe
and OS X developers by brining this unique platform to other
platforms. Just like Borland, SGI, Sun and IBM provide compilers,
runtimes and tools for other languages, we provide such a piece for
C#/.NET.
Mr Neil does not seem to understand why bootstrapping a C# compiler is
important, so let me explain this in terms he would understand: it is
important because:
* Using C# to write a C# compiler means that it improves our
development speed.
* To be able to harvest the benefits of productivity of C# on
Unix, we need a bootstrapping system.
* It allows us to write software on Unix without and be
self-sufficient to develop software as opposed to require
a Windows machine to develop software, and another to run it.
* It means that we trust our technology enough and it is solid
to the point that a relatively complex piece of software not
only runs, but is binary-compatible with the Microsoft
runtime.
Mono's objectives are not "To break Microsoft's monopoly". We do not
define ourselves in this way, there are more important social causes
to fight. We look at the ECMA 334/335 standards as a solid foundation
to improve Linux and bring more software, more quickly to it, and make
the development process more fun.
There is a lot more about this on:
http://www.go-mono.com/rationale.html
And a few other interviews
Well, it might be in the spec, but it is not in a released product, just like the SDK 1.5 is not in a released product.
They are both in the works.
Might be useful to some:
l ic /www/doc/abstracts/dos-fs.html
l ished/do s-fs.ps
Alessandro Forin used to work for CMU on the Mach kernel and presented at Usenix in 1994 a new file system that used FAT as its storage, and had been extended to support extended file names.
He later joined Microsoft.
The abstract:
http://www-2.cs.cmu.edu/afs/cs/project/mach/pub
The paper:
ftp://ftp.cs.cmu.edu/project/mach/doc/pub
I wrote my impressions from Microsoft's Professional Developers Conference and the new technologies presented there in:
m l
http://primates.ximian.com/~miguel/texts/pdc.ht
There is a potential for XAML and WVG to become standards just because of the large deployments of these technologies.
Miguel.
Two lies above:
* There were never any Windows.Forms cooperation plans. Each group has chosen a different implementation path.
* We never pulled Windows.Forms out of Mono, we continue to develop it.
Your conspiracy theory on the marketability of Gtk# is pure nonsense. We develop Gtk# to build Gnome applications, we have no choice if we want to leverage all the platform code available.
We develop Windows.Forms and other APIs to remain compatible with code that people develop on Windows, and move it to Linux. As simple as that: Mono is not only a great platform to create *new* software with Unix-isms, it is also a platform to enable the growth of Linux by bringing the Windows people over.
Miguel
Novell will continue to support KDE on SuSE, distribute its packages and maintain this offering which is a prime choice of people.
We will also integrate Ximian Desktop into their offering, because it is a more fine-tuned desktop than the default Gnome one, and leverages all the enterprise features we added to it.
NDS is part of the Linux Software Services stack that was announced for Linux earlier in the year. So do not worry about that.
Miguel.
You are free to remove the free software you got, and install your commercial software on top: you still got all of the choice you need.
But by default you are encouraging people to look at a new system, which also happens to be free.
Miguel
Mono supports both JIT compilation, as well as precompilation (mono --aot program will precompile your code), improving startup code significantly.
If anything Mono feels *faster* every day, as we improve the JIT engine.
It seems you have not bothered to even use Mono, since we have great startup times.
Pretty sweet! Considering that they have so few songs not bad, not bad at all.
Solaris does have a few areas where they have done a fantastic job.
For example, when it comes to debugging threaded applications, and having a reliable debugger, they beat us every single time. This is a mix of debugger support, kernel support, libraries support and god knows what else.
Their thread implementation is also very robust. I have no clue about their performance, but I know that you can depend on their implementations being robust. On Linux plenty of thread-related issues are still flaky (big progress being made there), but today, I really wish I had Solaris to debug a few problems.
And there are tons of other little things they get right. My suggestion is that we should focus on what is wrong in our platform, and focus on what is good in their platform, to find out what needs to be solved.
Miguel.
Man, the dude writing that stuff is sure one paranoid fellow. A paranoid fellow with little or no vision. No offense, but the guy is drowning in a quite empty glass of water.
.NET APIs while they remain open, and will continue to use open protocols whenever possible (for example, our System.DirectoryServices implementation talks LDAP).
.NET APIs we have been actively implementing our own framework that maps into the Unix world.
.NET binaries.
Lets take the following premise:
`Mono succeeds, and Microsoft then changes the APIs so Mono can not catch up, hence Linux looses'.
Lets take a sample that is closer to us: Linux and Unix. Linux and GNU are implementations of a fairly popular and interesting technology: the Unix operating system.
Now, if the Unix creators introduced a new API, or changed a Unix API when Linux was successful, did that change the success of Linux?
For example, lets assume that tomorrow SCO introduces a new API call into SCO Unix, lets call it "hasuseraclue()" [1]. The system call is highly proprietary and undocumented. Now, will Linux and GNU users suffer from the lack of this API? I am going to leave that as an exercise to the reader.
[1] Note: by reverse engineering the code, we know that above system call return 0 when ran on the system of the author of the previous paper.
In a world where Mono is vastly successful, if Microsoft changes/introduce new APIs, do you think it will matter?
We will continue to implement the
But Mono has not stopped at implementing the
For example, Microsoft has chosen XML Schema for representing, mhm, XML schemas. But the world of XML has been leaning towards Relax NG. Well, we implement Relax NG.
We implement Mozilla bindings, OpenGL bindings, Gtk+ bindings, Qt bindings, Unix bindings.
They implement support for 3 databases, we implement support for 11 databases.
Mono ships with plenty of other libraries, like a BigNum library and APIs to manipulate
miguel.
I see some flaws in the document posted.
I love research, and more than anything I love the people involved in doing research: those who create, explore and can give us future direction. But I also believe that the research must be truthful if we want to build on it.
The Y presentation paper is interesting on the ideas it introduced (we could argue whether they are new or not, since NeWS did did before, in fact, with a more extensible system) but it fails on presenting X correctly.
The document goes on to show that the X-based approach has lead to major GUI fragmentation, and how the MacOS and Windows do not have this problem.
On the screenshots where X looks bad, the author shows some old graphics program running together:, xpdf and two modern apps: mozilla/xul and gnome calculator. All of those programs have Gtk-based or Qt-based equivalents that would have made the whole experience consistent.
The screenshot should instead be presented as a proof that X can still run applications that were developed 12 years ago.
Then he shows the Mac and Windows. Again, not really honest screenshots, because even Apple is shipping two different GUI views: the brushed metal theme and the aqua theme (this combination kills me) and Microsoft is not exactly known for keeping their GUI look consistent across their product line: Office, MSN and the rest of the desktop use different styles and widgets.
So summing it up: the screenshots are presented to prove a point which happens to not be there.
Now, to make things even more interesting, here is a little bit that the author of Y might not be aware of: widget rendering on MacOS X happens on the client side, and the operation that the server supports is basically "uptade-rectangle-with-this-RGB-buffer", there is no magic of server-side widget rendering on MacOS X.
Also, doing an X protocol translator is not an easy job, but I wish them good luck pursuing this new adventure, it defintely sounds interesting.
Miguel.
You got the questions with the wrong answers:
1. Measuring speed is difficult, but to give you an example, the Mono C# compiler compiles itself on 3.5 seconds (50,000 lines of code).
2. development is faster, I would say 3x to 6x depending on the task. In the case of ASP.NET vs J2EE, we know from two studies (ours and Forrester/Giga) that it is 20-28% more effective (see my blog for details).
3. Is it cross platform? Yes, it is. The Mono C# compiler was originally built/compiled on Windows. Today, it does not matter. We routinely run large applications (web services, console, gui) on it.
4. It offers plenty of functionality that is hard to find elsewhere: cross-language interop, unified GC/threading/io
5. Patents: the ECMA core has been freed of any patents, see: primates.ximian.com/~miguel/tmp/map.png
Well, a few corrections.
.NET. Whatever that meant.
.NET at the same time. I could see this as interesting research, but not something I particularly cared about.
:-)
Phase 1: DotGNU and Mono announced on the same day by the FSF. Mono to work on the framework, DotGNU to do the more undefined parts of
At this point cooperation was not possible, because it turned out the DotGNU team wanted to invent a new virtual machine that supported Java and
Then we were asked something like `you will work with us better than with proprietary companies'. This is ridiculous in that you cant make this kind of promises. Specially with a team of people (the DotGnu) who had no track record of writing anything of large scale. So to us, a relatively experienced team of developers, being told this by a team of self-appointed "core team" of unexperienced people was a non-starter.
Phase 2: Portable.NET bends over and accepts every wacky idea of DotGNUers. The idea here is that Portable.NET had to please the desires of the dotgnu kids, so a promise to support JVM binaries at the same time and generating code for both was made. They got this working to some extent, but again, its slow, untested, and very broken.
Phase 3: the code donation. Mono received under the terms of the MIT X11 license, a copy of the I18N code. A pretty small chunk of code, and lots of data files that come from the IBM ICU library (about 4k lines of code, plus 46k of data files).
This was the beginning of cooperation.
The cooperation did not last long, because even when we submitted fixes to them, and pointed them to new codecs, they decided to change the license of their code to GNU GPL, because they felt cooperation with us was useless.
Licensing:
We use the more liberal MIT X11 code, which they have liberally integrated into their code base, but since we are commited to eliminate any potential licensing problem that a proprietary software developer might have with Mono, we will not use the GNU GPL or GNU LGPL in our libraries.
We could not use PNet's code for two reasons: we just plain dont like the coding style (coming from the Linux/Gnome coding conventions), and second the reverse engineering that was done in Australia (what Norbert claims is ok) would put anyone distributing the software in the US under a potentially interesting legal situation.
It is our responsability to the contributors of Mono who have devoted tons of hours to it, and to the users to make sure that there is not the slightest potential legal problem with the code that would make their contribution useless. We dont want anyone FUDing in the future like its being done with SCO. So we had to have more strict legal procedures.
For instance, we recommended people not to look at Rotor source code until we had the equivalent Rotor functionality implemented. Pnet follows a different approach: read Rotor, and do a new implementation of it. Might be better for interop, but I sleep better at night
Miguel.
AT&T Unix was never open source.
It was distributed to universities under a research license.
The lawsuit issue is more complex, because it was never discussed in court, instead USL and Berkeley settled the case.
Berkeley agreed to remove all the files that still contained ATT code. That used to be called "4.4 BSD Lite" which could not boot, as opposed to "4.4BSD Encumbered" which was a complete implementation.
The free BSD distros of today derive from BSD Lite 4.4
Projectors are usually a source of pain in Linux. I typically run my laptop at 1400x1280, some projectors are able to deal with 1024x768, but some others can only cope with 800x600.
Although my IBM laptop is better than the other laptops I had in the past when it comes to having various options on the output, it still falls short sometimes, and the output is chopped on the projectors.
What I do today is I keep 2 XFree config files, and I run a second X server at low-res during presentations, but I would definitely like to avoid this.
Miguel.
The red parts are components that Microsoft has not submited to ECMA for standarization and hence have no explicit patent grant. Whether there is an enforceable patent there is unknown, but is dubious, as for the most part they are wrappers to existing technology, or implementations of concepts already available.
;-)
The green parts are components that we have developed outside of the Microsoft world (they do not have a Microsoft equivalent). Whether there are patents or not is uncertain as they are also wrappers for existing technologies (Gtk, Mozilla, etc). Microsoft would certainly not have a Mozilla# patent
Miguel.
C# and the CLI (ECMA standards 334 and 335) have no patent fees attached to it, it is completely patent free.
;-)
The ironic thing is that *today* the fastest fully open source Java VM that can run Eclipse is Mono plus IKVM.NET (the open source Java VM that generates CIL code on the flight
Miguel.
Various publishers are working on books about Mono that will cover exactly what you want.
.NET book applies directly to Mono. In fact, before Don joined Microsoft, he was kind enough to let us preview his book, and that helped us understand various internals of the .NET framework.
But everything you learn in Don's Essential
Miguel.
Mono is an implementation of the ECMA 334 and 335 standards which are available for anyone to implement (no patent strings attached, check the Mono FAQ for details).
On top of that Mono implements plenty of class libraries: both the non-standarized class libraries from Microsoft, as well as our own universe of class libraries that take advantage of Unix-specific features.
Here is a link: Mono Map (abridged).
Miguel.