Slashdot Mirror
New Mono Roadmap, DotGNU 0.1 On CD
msh104 writes "The Mono project just released a nice status update for Mono. They also preview a roadmap for what the future will be like. It's quite nice to read if you want to find out if writing .Net programs for Linux will have a future for you. The Mono roadmap is available here." And gibbon writes "The DotGNU Project announced the availability of the DotGNU 0.1 CD-ROM release.
It runs on many platforms and the CD contains documentation, packages for GNU/Linux, FreeBSD and MS Windows.
It is now possible to use the base class libraries and XML. System.Windows.Forms and the web services are coming along well, too. The announcement contains more information and download links."
I work for a large IT consultancy and we have a number of high-profile projects in the .NET stream. So yes, there is a market for it currently. In the future... who knows. But .NET is the sort of thing M$ is not going to let go off easily. They'll put a lot of money behind it, in marketting, development, etc. So in practice, even if it was a really crappy product, all that money behind it would make it a reality. I don't like .NET, but I would bank on it surviving for quite a few years.
Daniel
Carpe Diem
I'm asking this half sarcastically and half seriously.
.NET and why would we expect Micro$oft to NOT shut Mono down cold if it goes anywhere so it becomes a threat to them?
Could someone please explain to me: Isn't Mono basically an open source
The DotGNU project is 100% committed to making Windows.Forms mature. We're even offering significant cash prizes as an additional incentive to help move this forward as fast as possible.
Such a summary should IMO be written by an objective outsider who does not have a vested interest in the success of either of the two projects. As far as I know, so far no-one has written a reasonably objective comparisom.
Why don't these projects merge?
I have made multiple attempts to establish cooperation between DotGNU and Mono. This has not worked out. I want to leave it at that. If I say what I, from my DotGNU perspective, think were the reasons, and the Mono folks respond by saying what they think were the reasons, we get just another round of pointless bickering, that would be a total waste of time.
I think it would be great though if someone with skills in the study of contemporary history wanted to study this question. The challenge here is that only an outsider can be sufficiently objective, but it will probably be difficult for an outsider to gain a good understanding of what has really been going on behind the scenes.
If one can say that there are two successful component-software frameworks out there, they would have to be Java and ActiveX. Java is single-language and multi-platform, but multi-platform in that one is running the Java platform under all the different OS's. ActiveX is, unfortunately single platform (Windows), but it is really, truly, multi-language (besides Visual Basic, there is Delphi, C++/MFC, the scripting languages, Matlab, VS.NET hosts ActiveX controls quite well, thank you, and yes, even Java SWT that supports it in one form or another). It is multi-language in a sense that .NET isn't (really syntax skins over CLR-compatible languages).
With ActiveX, you have two things going on: pure COM objects and then ActiveX objects proper. COM is kind of like Mono/.NET without Windows.Forms, and ActiveX is like Windows.Forms. In fact, ActiveX support under .NET is integrated into Windows.Forms. COM is simple enough and clean enough that you could really have COM across platform. ActiveX tries mightily to hide it, but it really has the Windows handle and API behind it, and is the thing that ties you down to Windows.
Now Windows.Forms does have a clean, generic GUI API that could be ported to other systems, but on the other hand, it exposes both Window handle and displace context (DC). Not only that, all of the Longhorn revelations suggests that Microsoft plans to ditch Windows.Forms and move to something else.
Leaving out all the worries about patents and Microsoft behavior and all that, for Mono to succeed, it has to do more than just the COM part to .NET, it has to do an ActiveX-like part as well. As a Windows-constrained person, I see Windows.Forms as a waste of time because 1) ActiveX not only works with .NET quite well but it works with the legacy Windows stuff (VB 6 and all the sundry Web pages and scripting languages), and 2) it looks like Windows.Forms is going to be superceded by something else.
Windows.Forms components are only a little bit easier to use than ActiveX, and they are sure a heck of a lot easier to develop than ActiveX (don't get me started about IDispatch, QueryInterface, Automation data types, IDL, and type-library generation and maintenance). But for all its warts, ActiveX generated a whole lot of buzz. Matlab is cross platform, but the Windows version supports it. Data Translation supplies A/D card controller widgets in it. Eclipse Java-SWT supports it (again, only on Windows). Where's the buzz with Windows.Forms? Is Matlab rushing to come out with a version to host Windows.Forms widgets? Is Data Translation coming out with .NET native widgets for their A/D cards? Eclipse-SWT already supports Windows so it doesn't need to host Windows.Forms.
If I as a Windows developer think Windows.Forms is a waste of time (no future to putting a lot of work porting and polishing a GUI component library into Windows.Forms), perhaps Mono should invent its own GUI framework and try to beat MS to the punch regarding whatever MS has up its sleeve.
Windows.Forms does not have this big mass of reusable component software or people falling over themselves to make containers to host it, and I don't think it ever will -- it looks like a bride until Microsoft makes up its mind. If I could pick a direction, I would suggest cloning the Eclipse SWT API, and teaming up with the Eclipse people to agree on extension.
the DotGNU implementation of SWF is not "hacked". They just decided to write it on top of Xlib on non-windows platforms instead of going the mono route with wine being a dependency.
.NET binaries that rely on SWF on dotgnu in the near future, but you will be able to run DotGNU binaries using SWF on windows. Hopefully they'll get some theme support going so it looks native.
No, you won't be able to run
.Net on Linux is always going to lag behind .Net on Windows. Linux is a dominant presence in the server market, yet the aspects of .Net that Mono suggest they are least likely to implement are the enterprise server features, so only the client-side features of .Net are likely to be anywhere near complete.
There is a language and system already available on almost every platform that has complete client and enterprise features and open source versions (GCJ, Kaffe) - its called Java.
So why bother?
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