Glimps into the future?

[Telengard]

Re: Glimps into the future?

The more I read about Mono the more worrisome it becomes.

From what I have read, Microsoft .NET is the application framework that MS has been pushing since Windows 98 Second Edition. It was always Microsoft's intention to use .NET as a Java-killer, luring developers away from Java and Free Software. For those who don't know yet, the Java software platform is almost entirely made of open source or Free Software (GPL). So if Microsoft can kill Java (market-wise) then they have dealt a huge blow to Free Software.

Why does that relate to Mono? Because .NET is the C# API and Mono copies it.

Edit: As long as I am spouting off about things I barely understand, it would be nice if someone who knows the true facts could correct me on my mistakes or fill in the gaps a little.

[GreyGeek]

Re: Glimps into the future?

J++ was SUPPOSED to be the Java Killer, not .NET.

This wikipedia article explains pretty well the relationship between Java and .NET

.NET vs. Java and Java EE

The CLI and .NET languages such as C# and VB have many similarities to Sun's JVM and Java. They are strong competitors. Both are based on a virtual machine model that hides the details of the computer hardware on which their programs run. Both use their own intermediate byte-code, Microsoft calling theirs Common Intermediate Language (CIL; formerly MSIL) and Sun calling theirs Java bytecode. On .NET the byte-code is always compiled before execution, either Just In Time (JIT) or in advance of execution using the ngen.exe utility. With Java the byte-code is either interpreted, compiled in advance, or compiled JIT. Both provide extensive class libraries that address many common programming requirements and address many security issues that are present in other approaches. The namespaces provided in the .NET Framework closely resemble the platform packages in the Java EE API Specification in style and invocation.

.NET in its complete form (i.e., Microsoft's implementation, described in the Standardization and licensing section of this article) can only be installed on computers running a Microsoft Windows operating system[40][41][42] whereas Java in its entirety can be installed on computers running any one of a variety of operating systems such as Linux, Solaris, Mac OS or Windows. From its beginning .NET has supported multiple programming languages and at its core remains platform agnostic and standardized so that other vendors can implement it on other platforms (although Microsoft's implementation only targets Windows, Windows CE, and Xbox platforms). The Java Virtual Machine was also designed to be both language and operating system agnostic and was launched with the slogan "Write once, run anywhere." While Java has long remained the most used language on the JVM by a wide margin, recent support for dynamic languages has increased popularity of alternatives; in particular JRuby, Scala, and Groovy.[45] (see JVM languages).

Sun's reference implementation of Java (including the class library, the compiler, the virtual machine, and the various tools associated with the Java Platform) is open source under the GNU GPL license with Classpath exception. The source code for the .NET framework base class library is available for reference purposes only under the Microsoft Reference License.

The third-party Mono Project, sponsored by Novell, has been developing an open source implementation of the ECMA standards that are part of .NET Framework, as well as most of the other non-ECMA standardized libraries in Microsoft's .NET. The Mono implementation is meant to run on Linux, Solaris, Mac OS X, BSD, HP-UX, and Windows platforms. Mono includes the CLR, the class libraries, and compilers for C# and VB.NET. The current version supports all the APIs in version 2.0 of Microsoft's .NET. Full support exists for C# 3.0 LINQ to Objects and LINQ to Xml.

(BTW, Did you notice that last sentence about MONO? It "supports ALL the API's of version 2.0 of .NET". That's interesting BECAUSE NOT ALL of .NET 2.0's API is in the ECMA 334 &334 standard. Parts in MONO that are not in the ECMA are in violation of Microsoft's IP.)

However, what the Wikipedia doesn't tell you is that after MS began .NET they also started Visual j++, which was the REAL attempt to embrace and extend Java so that MS could extinguish it.

J++ Against the Java Standard

While J++ conformed to the Java standard in its language specification, Microsoft did not implement certain features of the official Java standard into its own Visual J++ product line. Remote Method Invocation (Java RMI) and Java Native Interface (JNI) are such examples.

In addition, J++ implemented other extensions that were not part of the Java standard. The inclusion of callbacks and delegates for event handling further contributed to defining J++ as a completely different language merely based on an already existing design concept.

Furthermore, J++ applications did not conform to the standardized method of accessing the underlying operating system functions as any other Java application under Sun's Java SDK. In Microsoft's implementation, an underlying framework called J/Direct provided a base mechanism that allowed J++ applications to completely circumvent Java's class libraries and API mediums in accessing the underlying operating system. Due to this short-cut around the original Java framework, J++ applications were more efficient in taking advantage of Win32 API functions than Java applications.

J++ applications using these specificities could not be run on Sun's Java SDK, but the Kaffe project developed extensions which made it possible to run J++ applications with these specificities on their open sourced JVM.

Sun Microsystems had originally licensed Java to Microsoft but finally initiated litigation against Microsoft for failing to adhere to the license agreements to implement the Java language specifications fully in the Visual J++ dev tool. Sun won the case so Microsoft had to either make Visual J++ conform to Sun's Java Standards or stop using Java. Microsoft countered by creating a dev tool which created a migration path for Java programs to .NET. That tool was called Visual J#.NET. Visual J++ last appeared in VS 2003. J#.NET saw its last appearance in VS 2005. Neither were popular among developers and now are not used at all.

Java is popular on MANY platforms, including Linux. C# is popular on Windows (and in MONO on LInux) precisely because it copies MANY of the features of Java. While some may consider c# to be a Java killer, Sun's own abuse of their Java certification procedure probably did more harm to Java than C#. That was relieved somewhat when Sun recently released Java under an open source license.

But, the same lethargy which prevents many companies from switching to Linux also prevent many java applications from being switched to C#..... it just takes too much time and money to rewrite a Java application as a C# application, or under any other language. It's the same reason there are still many COBOL programs still running on mainframes today.

[PhilT]

Re: Glimps into the future?

How can we all find out what the Kubuntu developers think about this? I would really like to know.

Have they perhaps been tasked to keep Kubuntu Mono-Free in future whatever happens to Gnome thereby preserving Kubuntu's current FOSS credentials? Could that be Shuttleworth's "Ace in the Hole" strategy? I really DO HOPE SO, but I have no idea about the resources that would be required to maintain the current position in the event of possible mono-dependence-creep. Maybe we should start a voluntary contributory Fund to build up a defense?

[GreyGeek]

Re: Glimps into the future?

I don't know what the Kubuntu developers plans are.

Before the MONO fiasco I was happy because the GNOME and KDE developers were working together to make GNOME and KDE work together seamlessly by creating mutual bindings like gambas2-gb-qt-kde, kcm-gtk, gtk-qt-engine, etc..., which essentially ended the Linux desktop flame wars. These inter-desktop bindings allow each desktop to smoothly run the other's applications, and allows both desktops a greater selection of functional applications. Each desktop fulfills a need in the community.

When I learned that there were plans afoot to re-engineer GNOME using MONO (it becomes based on MONO, not GTK) I became concerned that this would result in MONO-KDE bindings, thus tainting KDE. But, IF the KDE developers do not link MONO and KDE together then that means that every downstream distro that wants to make their distro dependent on MONO for what ever reason will require that THEIR developers create GNOME-MONO-KDE bindings. This would make supporting KDE upgrades a monumental and very repetitive task and only distros backed by Novell, Canonical or RedHat have the talent and money to do it. So, I suspect, there will be a LOT of pressure and legal threats against the KDE dev crew to create such MONO bindings in their source code to minimize the work downstream distro developers have to do, thus making KDE also dependent on MONO.

HOWEVER, I believe the possibility of the KDE dev crew succumbing to such pressure to be essentially impossible. Because of this I suspect that there will be a lot of pressure to "encourage" major distros to add a GNOME-MONO version, possibly by adding MONO based proprietary but free codecs and apps as freebies in the GNOME desktop, putting the KDE based distro at a disadvantage when it comes to multimedia support. Microsoft is working hard to get other nations to adopt US copyright and patent policies so that they can shut down Internet servers in countries which allow legal distribution of such codecs. This is one reason why I support png graphics and Vorbis/Ogg media formats. Free proprietary codecs may be enough to induce some of those distros to drop KDE and stay with GNOME as their only desktop.

One reason I believe the KDE dev crew won't succumb is that Qt is under the GPL and LGPL and it can be forked if the KDE dev crew betrayed the FOSS community the way Novell and GNOME has. (If you don't believe that Novell has betrayed Linux, FOSS and the community then you will have to explain to me why Novell pays Microsoft a ROYALTY for each copy of the SUSE Linux Enterprise Server it sells, as an "IP bridge" to Microsoft "because Linux contains MS IP", to say nothing of the rest of their "agreement" and the resulting dichotomy of the GPL rights.)

The Qt toolkit had an iron clad agreement with Trolltech and any successors that if Qt ever goes totally proprietary, or is abandon, then Qt would be released under the BSD. Since then, Trolltech has released Qt under the GPL vs & v3 and LGPL, so the BSD option is moot. Nokia has continued with the GPL, adding the right to link software under several other open licenses to Qt. The KDE dev crew can continue on with Qt regardless of what happens to Nokia or any other future owner of the proprietary version of Qt, and their version will be under the GPL, free of any IP, royalties or restrictive licenses. So besides having access to that last GPL version, the KDE dev crew, or anyone else, can take up Qt development and support in order to support KDE.

Regardless, the introduction of MONO will change the interoperability of GNOME and KDE, which is one reason, I believe, why it was promoted so heavily by de Icaza/Novell/Microsoft and all the .NET developers who think that .NET is the greatest invention since sliced bread. MONO will divide the two Linux desktops .... again.

I also believe that it is possible, since GNOME is under the GPL, that those who prefer a version of GNOME not tainted with MONO will fork it and the developers of that fork will continue to work with the KDE dev crew to continue interoperability, along with a greater emphasis on GPL codecs. I also believe that when faced with the choice between a GPL desktop like KDE4 and a MONO tainted GNOME desktop which Microsoft ultimately controls, people, SOHOs and corporations which moved to Linux to break free of Microsoft will move to a distro which features a non-MONO tainted version of GNOME or KDE4.

So, I believe that the future of KDE4 is as bright as ever, and so is the distro whose developers stay with the pure KDE4 desktop. I also believe that a MONO tainted GNOME desktop, and the distro it sets upon, will be brought down in misery, sooner or later, by Microsoft because of IP violations by the parts of MONO which are not in the ECMA 334 & 335 standards. The only way such an end could be avoided is IF Microsoft put ALL of .NET under the ECMA standards. Even then, using MONO would result in a 2nd Class desktop because MONO will be, is, and always has been, BEHIND .NET in features and capabilities, so a GNOME desktop will always be behind Windows.

[Raven-sb]

Re: Glimps into the future?

GG can you please post a link that talks about Gnome 3 being fully mono dependent. The articles I've read on the subject seem to say that whilst there will be some mono applications in Gnome 3 (such as Tomboy and Fspot), the main DE will not be dependent upon mono.

I remember reading an article on dot.kde.org a while back where the KDE developers basically came out and said that they would not make KDE dependent upon mono.

Lastly with regards to the article you linked where the author speaks about the ' "faux" Linux community ', I didn't interpret that article as the author stating that all anti-mono people are "faux" Linux community, but rather those anti-mono people like Mark Fink, who start flame wars and troll mailing lists etc as being the "faux" Linux community.

Regards,

Raven

[Telengard]

Re: Glimps into the future?

Lastly with regards to the article you linked where the author speaks about the ' "faux" Linux community ', I didn't interpret that article as the author stating that all anti-mono people are "faux" Linux community, but rather those anti-mono people like Mark Fink, who start flame wars and troll mailing lists etc as being the "faux" Linux community.

Maybe this issue is important enough to merit a flame war.

[Raven-sb]

Re: Glimps into the future?

Starting a flamewar doesn't help anything. If anything it turns people off. I'd rather read a non-emotive factual debate on these issues then a flamewar thread full of trolls sprouting emotive sentiments and calling those who disagree with them nasty names.

Reading through the ubuntu-devel list two things stood out: one, those anti-mono people who flamed the list, did not help their issue and two, the pro-mono people's response was if you don't want mono-apps in ubuntu then contribute to the community by writing non-mono apps that meet the functionally that the mono-apps do, and then lobby for them to be included. The contrast in attitudes was striking.

[GreyGeek]

Re: Glimps into the future?

...
Reading through the ubuntu-devel list two things stood out: one, those anti-mono people who flamed the list, did not help their issue and two, the pro-mono people's response was if you don't want mono-apps in ubuntu then contribute to the community by writing non-mono apps that meet the functionally that the mono-apps do, and then lobby for them to be included. The contrast in attitudes was striking.

Perhaps you didn't read all the posts? Did you notice "Lefty's" tomes?

Who the anti-MONO posters are and what their motives were are open to question. Unless they are well known members of the Linux community with a well defined Internet trail, you can't assume that they represent anyone but themselves, or that they are even "anti-MONO". Unlike "Fink", the "Remco" fellow wasn't bombastic or hostile. He just presented an anti-MONO viewpoint. I never heard of either of them. Fink's posts are void of valid technical information or a reasoned viewpoint, and posters like him are favorite "examples" that pro-MONO folks focus on and use as a brush to paint ALL anti-MONO view points. In the process "Lefty" paints "Fink" as a BoycottNovell agent (thus apposing the Novell/Microsoft agreement is another example of Microsoft "hate" because they have characterized the BN website as a "hate" website). Is that the kind of "contrast" you had in mind? But. Fink has no relationship with BoycottNovell, according to Roy Schestowitz. The same folks who accused Fink of being a BN plant also said that Schestowitz wasn't a programmer and wasn't "qualified" to comment on MONO, and claimed he was stealing Internet connection services from the University dormitory where he was enrolled. It turns out that he wasn't stealing those services and he was working on his PhD writing software for use in Medical Imaging, which he still has a year left to work on. I used to teach Calculus & Diff Eq in college and I've examined Schestowits's publications and they use math at the Diff Eq level. Again, is that the kind of "contrast" you had in mind?

What is really amazing to me is trying to correlate the statement made by Mark Shuttlesworth in an interview on May 3, 2009:

(12:24:03 PM) jcastro: QUESTION: Do you see Wine (and Windows-compatibilty in general) or native Linux ports as the more important ingredient in the success of Ubuntu, or do they each play an important role?

(12:24:18 PM) sabdfl: they both play an important role
(12:24:30 PM) sabdfl: but fundamentally, the free software ecosystem needs to thrive on its own rules
(12:24:41 PM) sabdfl: it is *different* to the proprietary software universe
(12:24:54 PM) sabdfl: we need to make a success of our own platform on our own terms
(12:25:08 PM) sabdfl: if Linux is just another way to run Windows apps, we can't win
(12:25:13 PM) sabdfl: OS/2 tried that

with the fact that Ubuntu will become DEPENDENT on an API, which itself is DEPENDENT on .NET, which Microsoft owns and has patented and has released only the non-GUI parts to the ECMA standard, but ALL of it has been ported to MONO. The article ends with:

Linux doesn't need to assume the role and identity of its competition for long term success, it can achieve that on its own merits.

How can Ubuntu "make a success of the Linux platform" if the desktop API is controlled by Microsoft? If it adopts MONO as its primary application development tool and utility library it will have snatched defeat from the jaws of victory.

This duality of personality is really strange because EXISTING (I.E. ALREADY WRITTEN) apps with an excellent GPL/FOSS track record are being ousted from the Ubuntu LiveCD so that over 40Mb of space can be used to include MONO, WHICH IS Microsoft's API, just to support a MONO app that GNote can totally replace. A special Developer's Board was also set up on 6/29/09 to fast track MONO applications into Ubuntu.

MONO is a Windows app in a way that WINE could never be. What is Shuttlesworth's true position?

You say pro-MONO folks should lobby, write software, etc... I'm Lobbying. Is it making a difference, or is speaking against MONO causing it to win? Damned of we do, damned if we don't? That's a no-win sceniero, according to you, but I don't believe that arguing against MONO is helping it. Writing software? What have Linux developers been doing since 1991? What is the GTK or the Qt4. Baking pies? GIMP is still out, MONO is in. And MONO NEEDS GTK bindings to be able to legally create GUI's to the MONO apps!!!

When pro MONO folks start talking about "we" (those who attend MONO developer meetings & events or contribute to MONO projects in some way or other) as the Linux community and refer to those not in that group as "invaders" and a "faux" Linux community the contrast in attitudes IS striking, especially when they smear anti MONO folks with the title "Fundamentalist" which, in today's society, is a curse. Might as well call us a Nazi and be done with it. And we are the bad guys? We want Linux to achieve success on its own merits. Somebody's head is not on straight if the way for Linux to achieve success on the desktop is to use Microsoft's API. Especially since KDE4 is superior to XP, VISTA and Win7, and Qt4 is superior to MONO 2.x, which is two versions and several years behind .NET 4.

The pro-MONO attitude implies that those who can't write apps should have their opinions ignored. What about folks who contribute time, documentation or even money to Linux things not MONO? They don't count? So, by their rules, users have no voice either, unless they agree with the pro-MONO position. Do you notice a trend? Opposition to MONO is not tolerated and any device or distraction, including using PC movements or other political means is used. The pro MONO crowd's ire has landed on any one and everyone who does not want MONO to be a part of Linux -- RMS, BoycottNovell, Sam Vargeese, ... just about anyone who disagrees with the plans for MONO on Linux. Their favorite weapon is ridicule, usually based on false claims or assertions, like this example, sprinkled with words like "hate", "exclusion" and other PC terms. Basically, folks who don't like MONO are "haters", "religious zealots", "anti-Microsoft", etc... I don't find it strange that almost without exception pro-MONO people are pro-Microsoft too. Ethics and morals don't count. It's usually cast as the "middle ground".

However, not all debates about MONO are like one on the Ubuntu dev list, but they are vigorous. Here is a classic example from LXer, which is contributed to by several Linux lights. Too bad it took place nearly a MONTH AFTER the Ubuntu Technical Board ruled, on 6/29/09, to make the Ubuntu Desktop Remix dependent on MONO.

BTW, the The Ubuntu-devel-discuss Archives is an excellent place to keep track of Ubuntu development, especially as to how it will play out with MONO in the mix. And, for MONO itself, the The Mono-devel-list Archives is the place to watch, especially if you want to know first hand the future of MONO as played out by the developers.

[Telengard]

Re: Glimps into the future?

How can Ubuntu "make a success of the Linux platform" if the desktop API is controlled by Microsoft? If it adopts MONO as its primary application development tool and utility library it will have snatched defeat from the jaws of victory.

Well said.

I use Wine to run a few Windows apps for which no comparable Linux program yet exists. Doom Builder for example will never have a Linux version because its developer says so. It just happens to be the best application for its purpose, so I use it. If I ever find a Linux native program that is as powerful and as easy to use then I'll probably switch.

Free Software development works, and it has been around longer than the GPL and longer than even commercial software. IMHO the GPL simply codifies what has been best practice for serious developers since the beginning.

[Raven-sb]

Re: Glimps into the future?

I did read all the posts, I did notice Lefty's tomes and I felt he raised some valid issues.

I also read an interview with Mark Shuttleworth where mono was touched on http://www.omgubuntu.co.uk/2009/04/m...ome-3-new.html

Question Recently, the idea of replacing Rhythmbox for Banshee in Karmic has resparked the Mono debate in the Ubuntu community. As the SABDFL, what is your view on Mono? Is it safe to build a distribution that depends on it?

MS: Yes, i believe mono is a reasonable runtime to include in a distribution like Ubuntu. I don't expect Microsoft to launch any IP assaults based on mono adoption, they have said they will not do that.

You misquoted me, I said the pro-mono people's response was if you don't want mono-apps in ubuntu then contribute to the community by writing non-mono apps that meet the functionally that the mono-apps do, and then lobby for them [ie for the non-mono apps] to be included.

That's not just to do with mono, that's a good policy to follow if you want any form of software included in a distribution. If those anti-mono people who spend their time trolling email lists and creating flamewars actually created some non-mono apps that were as good as or better then the mono apps, then they'd be in a stronger position.

Btw please post a link where the Gnome Developers say that Gnome is going to be rewritten in mono.



Thank you.

[GreyGeek]

Re: Glimps into the future?

I did read all the posts, I did notice Lefty's tomes and I felt he raised some valid issues.

I also read an interview with Mark Shuttleworth where mono was touched on http://www.omgubuntu.co.uk/2009/04/m...ome-3-new.html

Question Recently, the idea of replacing Rhythmbox for Banshee in Karmic has resparked the Mono debate in the Ubuntu community. As the SABDFL, what is your view on Mono? Is it safe to build a distribution that depends on it?

MS: Yes, i believe mono is a reasonable runtime to include in a distribution like Ubuntu. I don't expect Microsoft to launch any IP assaults based on mono adoption, they have said they will not do that.

Your citation adds to the contradiction in Shuttlesworth's "policy". How he can say that after having said

if Linux is just another way to run Windows apps, we can't win

is mind boggling. Having the Linux desktop dependent on MONO is more than "running Windows apps", it is BEING Windows. Here is a list of GUI MONO applications using Gtk#, Winforms, ASP.NET, Moonlight and Other Mono Applications. Not all are current. Some are a couple versions and years behind .NET and SilverLight. Notice that this is after 10 years of MONO development. Not a big list when one considers how much time has passed since de Icaza decided to port .NET to Linux. It also raises the question as to the real goal since that few number of apps doesn't represent any threat to the Linux desktop.

You misquoted me, I said the pro-mono people's response was if you don't want mono-apps in ubuntu then contribute to the community by writing non-mono apps that meet the functionally that the mono-apps do, and then lobby for them [ie for the non-mono apps] to be included.

That's not just to do with mono, that's a good policy to follow if you want any form of software included in a distribution. If those anti-mono people who spend their time trolling email lists and creating flamewars actually created some non-mono apps that were as good as or better then the mono apps, then they'd be in a stronger position.

Actually, I didn't "misquote" you. I understood what you wrote and what you meant. It's a common pro-MONO counter argument. It's like asking "Have you stopped beating your mother?" Yes or No presumes guilt without establishing that Momma is being beaten. IOW, the "crime" is ASSUMED. Calling a post arguing against MONO a troll doesn't answer the objections raised in the posting. Neither does ridicule, a common pro-MONO tactic, or guilt by association, even when the "association" is manufactured. That argument, as I previously pointed out, presumes that if someone can't code they have no right to voice complaints about the path Ubuntu/GNOME is taking. So, the message to non-MONO volunteer testers, document writers, money donors, etc., is to shut up.

Also, your assumption that shutting up and writing

non-mono apps that were as good as or better then the mono apps

assumes that the MONO apps are quality apps to begin with, or better than existing apps, which is a false premise. I pointed out that it doesn't matter because the issue is NOT about having "better apps" than those written by the MONO dev teams. It has grown into a political situation where "what is better" is totally subjective. For example, it is often argued that GIMP is not as good as Photoshop, so it is not a valid replacement for PhotoShop, ergo, Linux can't replace Windows. But, that logic "fails" when the coin is flipped:

Of course, F-Spot editors are nowhere close to Gimp's, and don't even aim too. But they cover 90% of your daily usage and are (probably) simpler to use than Gimp.

ergo, MONO apps that are 90% as good as non-MONO apps are good enough to make MONO replace the non-MONO app on the LiveCD.

Even Microsoft used the "good enough" argument when it released a shoddy IE to compete with Netscape, knowing they had a desktop monopoly that forced IE on the user. For most users it was easier to use a shoddy app that came pre-installed with the OS than to download and install the high quality Netscape browser. Now, with MONO apps coming "pre-installed" on the Ubuntu LiveCD, it will be easier to use preinstalled MONO apps than bother with "sudo apt-get remove manymonoapps && sudo apt-get install manyreplaceapps". So, as long as an app is written using MONO it only has to be 90% as good as the app it replaces. A dictionary example of a double standard. As the number of MONO apps continue to replace non-MONO apps it will become increasingly more difficult to replace MONO apps with non-MONO apps. With complete dependency it will become impossible without breaking GNOME or even Ubuntu. THAT is what DEPENDENCY means.

BTW, Stepane's Log, and other MONO dev blogs, are an excellent place to see what's in his mind, and what are his intents and, perhaps, of all the MONO developers. The title to one of his posts says it all:

Mono-ifying Gnome3, one dependency at a time

.

Btw please post a link where the Gnome Developers say that Gnome is going to be rewritten in mono.
Thank you.

A better way is to examine the MONO API and documentation, and the Accessibility Architecture documentation. IF MONO is merely a dev tool to write some .NET based applications it is extremely OVER engineered. But, that argument is a deduction.

Consider the Mozilla libraries sub-documentation, for example. Compare the Gecko namespace with the GtkSharp.GeckoSharp namespace, or Gtk with GtkDotNet/GtkSourceView. Much of the MONO namespace documentation is missing explanations but the MONO namespace replacements for legacy Gtk namespaces is EXTENSIVE and thorough. It is obvious once all the pieces of the puzzle are filled in all the Gtk namespaces can be replaced by identically functioning MONO namespaces. Meanwhile, Gtk# bindings linking MONO namespaces to their Gtk counterparts, mainly in the GUI areas, allows for increasing dependency on MONO without having the MONO GUI parts in place. Like Stephane said, "one dependency at a time". MONO is NOT about writing a few MONO apps to add to the Linux desktop, or replacing existing apps with MONO apps, it IS about taking over the entire Linux desktop completely, putting Microsoft's API in control of the Linux desktop.

Actually, it makes sense. Even de Icaza and his team are not good enough programmers (in fact no group is) to create a fully functional "GNOME" desktop built totally with MONO only and merely drop it into SUSE (or Ubuntu) all at once. So, for the next couple of years, you will see MONO get Gtk# bindings AND some Gtk names spaces get sidelined as their MONO replacement becomes totally functional, i.e. NO reliance on the Gtk API/namespace

There is a graphic on the "Accessibility Architecture" page which shows all of these technologies and layers put together, as they currently exist. Looking at the "Provider" side you'll see green, blue and tan areas. You'll see blue FireFox and OpenOffice boxes setting on the "accessibility" and "Assistive" technologies (the Linux middleware and kernel). The middle blue stack of boxes is the GNOME stack. As the MONO dev crew continues development the tan boxes will grow to the left, eating into the GNOME support stack until such time as Microsoft's UI Automation specifications & UI/ATK completely replaces the GNOME Gtk+/GAIL support stack, leaving GNOME dependent on the UIA. What people won't notice is that gradually the blue GNOME box will eaten away by the WinForms/MoonLight boxes until GNOME is GNOME in name only. At that point the GNOME desktop will be a MONO WinForm/MoonLight desktop based on Microsoft's .NET technology and totally and completely dependent on it.

The only flies in the ointment are that 1) MONO is several versions and years behind .NET so a MONO "GNOME" desktop can never match the functionality and capability of a Windows .NET desktop, and 2) WinForms is NOT yet under the ECMA 334 & 335 or Microsoft's "Community Promise", so Gtk# bindings are still required. MONO advocates are merely hand-waving when they say Microsoft can't or won't sue to block MONO's WinForm implementations in the future. There is NO legal question that Microsoft can sue NOW to block WinForm inclusion in MONO because WinForm is NOT under the ECMA 334 or 335 standard. Neither is ASP.NET, which is also in MONO 2.4.2. But, I suspect, MONO advocates believe that Microsoft will NOT sue PRECISELY because using MONO puts Microsoft in control of any application or desktop that uses it. That may explain why Microsoft hasn't sued yet, and why Microsoft works hand in hand with de Icaza and his team to make a MONO desktop a controlling force on Linux a reality. It will give Microsoft a desktop that is much more immune to malware than Win32 or .NET platforms are, and one on which Microsoft and its 3rd party "partners" can build their .NET applications for, without having to actually use Linux. (Which is how de Icaza claimed he developed his first MONO test apps.)

Notice that MONO currently uses Gtk# bindings to give MONO the ability to display windows and dialogs that the user can interact with because WinForms cannot be legally used. But, in all other uses where MONO has been integrated into GNOME (the non GUI parts), C# is used, not Gtk+. Who controls C#? The ECMA standard, as written in the MONO documentation says it all in the C# documentation, under "Scope":

ECMA-334 C# Language Specification
1: Scope (informative)

This clause is informative.

This ECMA Standard specifies the form and establishes the interpretation of programs written in the C# programming language. It specifies

* The representation of C# programs;
* The syntax and constraints of the C# language;
* The semantic rules for interpreting C# programs;
* The restrictions and limits imposed by a conforming implementation of C#.

This ECMA Standard does not specify

* The mechanism by which C# programs are transformed for use by a data-processing system;
* The mechanism by which C# applications are invoked for use by a data-processing system;
* The mechanism by which input data are transformed for use by a C# application;
* The mechanism by which output data are transformed after being produced by a C# application;
* The size or complexity of a program and its data that will exceed the capacity of any specific data-processing system or the capacity of a particular processor;
* All minimal requirements of a data-processing system that is capable of supporting a conforming implementation.

End of informative text.

Notice that the MONO dev team, or anyone else except Microsoft, CANNOT violate the rules Microsoft laid down regarding representation, syntax and constraints, semantic rules and restrictions and limits imposed by a conforming implementation of C#. Who determines "conformance"? Microsoft does, just the way Sun controls standardization or certification of Java implementations. Microsoft can legally change its C#/.NET standards any time it wants. It has done so repeatedly with its previous technologies in order to give it a market advantage.

It's a good thing that those who import a tool conform to the accepted standards for that tool. The problem is who created the standards and what additional purposes they have for that tool & standard. This whole thread was started because Microsoft ADDED to SilverLight 4.0 the COM technology, breaking the standards (extending in order to extinguish) that previous SilverLight and MoonLight iPhone apps followed. This action was taken almost immediately following the release of Win7, which gives Microsoft a market advantage over Apple. How long it will last is immaterial. The fact is that Microsoft broke their own standard to isolate previous versions of SilverLight/MoonLight iPhone apps while allowing their platform to enjoy both the previous standard and to add capabilities using the COM extension that its competitors cannot add. Thus, just like MONO on Linux, MONO's iPhone apps will be technically behind Microsoft's desktop .NET implementation.

The MONO GAPI tools make it easier to use Gtk# to bind to glib. This is a direct link to the basic Linux API and the kernel. When the Gtk GUI components are no longer needed it will be a MONO utility linking to the glib. In fact, it could be a MONO/C# app that could replace glib. Call it mlib.

The day after the Ubuntu Technical Board approved making Ubuntu dependent on MONO, de Icaza posted on his blog the following msg:

Yesterday we shipped Mono 2.4.2, our long-term supported version of Mono. It ships Microsoft's opensourced ASP.NET MVC stack for the first time (you could get it before on your own, but now it is integrated) and fixes over 150 reported bugs.
...
What Chris does not talk about on his post is that he was trying to use some .NET software that interfaces via USB to his glucose meter and was trying to get this to run on Linux. The tool is mostly .NET with the usual handful of P/Invokes to Win32. And this is how M/Invoke was born: a tool to retarget P/Invoke happy applications into becoming pure managed applications.

This opens new doors to forcefully port more apps to Linux.

"pure managed applications" are applications that are built with safe code using C#/.NET where there are no pointers and C# manages the garbage collection. "unsafe (unmanaged) code" doesn't use C#.


OK, about GNOME being rewritten using MONO.

Let's start with de Icaza's statement in 2002:

"I'd like to see Gnome applications written in .NET in version 4.0 - no, version 3.0. But Gnome 4.0 should be based on .NET," he told us. "A lot of people just see .NET as a fantastic upgrade for the development platform from Microsoft.

It is an excellent article and presages the arguments and counter arguments that have arisen, but even more so since MONO has grown to a size that it as attracted a LOT of Windows software developers who now claim to be FOSS developers and Linux community members while continuing to use Windows as their dev platform.

Here is the ThreePointZero plan, with GNOME 3.0 due out in September, 2010. Here are their goals:

Hence, it makes perfect sense to rework our platform and try to clarify it for newcomers. Here are some steps that should be considered:

* move all of the deprecated libraries out of the platform, so people stop using them in new code;
* create a staging area in the platform for libraries that aim to be in our platform but do not offer enough guarantees at the moment (like GStreamer): this will send a clear message on what should be used;
* include new exciting technologies that we're starting to see used in our desktop. Some obvious examples are 3D effects (with Clutter) and geolocalization (with GeoClue and libchamplain).
* rework the way we present the platform to also integrate some of the external dependencies: while, say, D-Bus or Avahi are external dependencies, they are definitely what we want developers to use. And it's easy to be more explicit about this.
* move the bindings closer to the platform when we talk about bindings, to make them even more visible and attract developers from all languages.

But, the making GNOME with .NET was the basis of experimentation from the very beginning:

Since December 2000, we had been amazed by the .NET Framework, and when
we discussed internally at Ximian its benefits, what we initially did
was to staff the "Labs" team to work on CORBA, SOAP and Perl teams to
work on the Gnome binding infrastructure (remember: our motivation at
this point was the vision of writing APIs once, and using them in every
language).
...
The team products were positive, but still fell short from everything
the .NET framework could do.

But when we were done with our study, it was clear that it was possible
to build this technology, which we consider key to the future of Gnome
and Linux on the desktop.
...
We remained quiet, as we moved the teams over from their existing
projects to the Mono effort, ...
...
It is obvious that a small team like this can not build a full .NET
replacement, so we planned to launch this as an open source project,

So officially the Mono project was launched on that date, but it had
been brewing for a very long time.....

Who came first is not an important question to me, because Mono to me is
a means to an end: a technology to help Linux succeed on the desktop.

A technology, I remind you, which is merely .NET ported to Linux. Comparing Qt4 to MONO, there is NO question about which API is best for the basis of an unencumbered Linux desktop.

It is ALSO undeniable that eventually, perhaps one binding at a time, GNOME will become a total .NET application, masquerading as MONO.

It has been a year since I last checked to see if GNOME would run if I completely removed libmono* from GNOME. It did. As long as I can remove MONO libs from GNOME and it still runs Ubuntu is still FOSS. On the day that removing the MONO libraries from GNOME causes it and/or Ubuntu to crash, is the day that GNOME has left FOSS.

Like I said before, Raven, it does not matter that parts of MONO are under the EMCA and even the GPL. MONO will always be behind .NET because it emulates .NET. MONO will always be a couple versions and years behind .NET, and so will any Linux desktop built with MONO be behind the capabilities of a Windows desktop built with the latest .NET.

Qt4 is already state of the art, totally and completely under the GPL, and so is the KDE 4.3.3 desktop. The KDE dev crew does not have to wait for any Microsoft technologies to be placed under the ECMA before they can pick it up and begin developing or enhancing features.

[Raven-sb]

Re: Glimps into the future?

Ok interesting. Thank you for your posts.

[GreyGeek]

Re: Glimps into the future?

Your welcome.

All has been said that needs to be said.

I think it is time to lock this thread.