Miguel De Icaza On Mono, Moonlight, and Gnome 328
Knuckles writes "Austrian newspaper Der Standard continues its recent series of in-depth interviews with free software developers. This time they sat down with Novell's Vice President of Developer Platform, Miguel de Icaza of Gnome and Mono fame. The interview was conducted at GUADEC (GNOME Users' And Developers' European Conference).
Miguel talks mainly about Mono 2.0 and .Net 3.5 compatibility, enhancing the collaboration with Microsoft over Silverlight ('Moonlight' in Mono), and the larger political situation of Mono and Moonlight. When the interviewer asks whether Moonlight is only validating Silverlight on the web, Miguel gives a quite detailed answer that includes a possibly well-deserved swipe at Mozilla ..."
Re:Open Microsoft (Score:3, Informative)
It might end up that at some point Microsoft just open ups .net, like Sun did with Java, that's always a possibility.
When you put it into the context of the history of Java, it is not all that far fetched.
Mono vs Wine (Score:5, Informative)
http://www.gnome.org/~seth/blog/mono [gnome.org]
As this blog post explains, while the current software patent situation exists, Mono is an unacceptable risk.
What makes Mono an 'unacceptable risk' but allows Wine to become one of the most often praised open source projects on Slashdot?
Wine can be used to run those few windows apps for which you do not have no linux replacement, under linux. Mono is a development environment which could be used for just about anything... what if gnome, or some important gnome apps, got ported to Mono, and the day after Microsoft comes up with the bill?.. or with usage restrictions of some kind... Please read the link in the parent post, before replying... Here it is again:
http://www.gnome.org/~seth/blog/mono [gnome.org]
Re:Open Microsoft (Score:3, Informative)
Sun has been a friend of the open source community for a long time:
NFS .NET is a copy of Java, which Microsoft created because Java was cross platform. Why would they ever open .NET, when the goal of .NET was to create a non-portable clone of Java?
OpenOffice
Solaris
Java
VirtualBox
Sun Grid Engine
etc
Re:Mono vs Wine (Score:4, Informative)
The entire point of the article is that Mono should not be integrated into GNOME. Exactly the same argument could be made for not integrating WINE into GNOME, but since no one is advocating doing this, no one feels the need to post things arguing against it.
Re:Makes good points (Score:5, Informative)
The only reason I usually turn off Flash on sites other then some game sites or YouTube, is because the Linux Flash player is just so crappy. I have a decent enough /etc/hosts file that blocks 98% of the ads, but if I leave Flash on, Firefox's CPU shoots to 80% just displaying a banner ad. Thankfully, I downgraded to an older version and it doesn't do it as much.
Ehm, this is not the linux flash player as such, it's the flash player, period. I get the exact same problem on some sites in windows. Also downgrading flash is a seriously stupid thing to do right now, as the recent vulnerability they discovered leaves you wide open to attack. (and it has been spotted in the wild, though generally targeted at windows)
Re:JavaScript (Score:5, Informative)
JavaScript is not slow. Most implementations of JavaScript are fairly slow because (like Ruby) they use direct AST execution, which is very slow. This is done deliberately, because startup time is more important than execution speed for most scripts on the web. The new WebKit JavaScript has a bytecode interpreter, which is quite fast (about as fast as most Smalltalk implementations).
Semantically, JavaScript is very close to Self, and implementations of Self were running at about 50% of the speed of the same algorithm implemented in C++ back in the '90s. These days we'd probably call that 'fast'.
JavaScript has a lot of advantages. It's got a fairly nice Self/Io style object model, first-class closures, and a huge number of people who know it. Supporting JavaScript's object model was one of the design goals for the Etoile Objective-C runtime library, and I hope to have it supported as a first-class development language by Etoile 0.6 (I wrote a Smalltalk JIT that uses the same object model as Objective-C for 0.4 and a lot of the code can be reused to support JavaScript).
Re:Makes good points (Score:3, Informative)
Re:Makes good points (Score:4, Informative)
That wouldn't make any sense. Code taint only occurs if you've ever had access to their internals--seeing something that's part of the public interface doesn't taint you.
Unless they're talking reverse engineering, but that seems beyond the legal requirement as well.
Re:It's A Trap (Score:1, Informative)
There is Google's Picassa for Linux.
Re:Makes good points (Score:3, Informative)
I don't think the situation isn't quite that rosy. Although SWF is an open format, there are lots and lots of other bits and pieces that you need, such as the library of GUI widgets, and the various audio and video codecs. Those are all proprietary. (Some, e.g., mp3, are only proprietary because someone else owns a patent. However, Adobe hasn't bothered to implement support for free codecs such as vorbis and theora.) It's true that there are third-party, open-source compilers such as haxe. However, there's nothing that's compatible at the source-code level with Adobe's tools. Therefore if you're trying to work on an existing flash project, or trying to learn flash development from books, you really have no option other than Adobe's proprietary tools. The last time I checked, their tools also came with nasty EULAs, which, e.g., forbid reverse-engineering, creation of competing products, or use on a mobile device.
Re:get over it (Score:3, Informative)
Actually, the reason .NET exists is because Microsoft was prohibited after the Sun/MS lawsuit in 1997 from making changes that they needed to Java.
The changes that Microsoft did to Java included J/Direct and delegates.
Although Java does have a mechanism for calling into native APIs using JNI, it is cumbersome to use. JNI is a technology that requires developers to write a chunk of code in C++ and a chunk in Java to bind the C++ code. Microsoft's alternative, J/Direct allows all the code to be written in the native language. It now exists in .NET as P/Invoke, and it makes calling native APIs easy, and does not require any native code to go with it (this is the reason that using the SWT library for Java requires you to ship architecture-specific glue code).
Some Java developers did notice that the lack of something like J/Direct was a pain, and eventually came up with a system built on top of JNI that does what J/Direct used to do, the Java Native Access APIs.
The other bit were delegates. Delegates are merely the object oriented version of function pointers, but in addition to capturing the address of a function, they also capture the instance that is associated with the object. At the time Sun published a paper describing why they did not like delegates (http://java.sun.com/docs/white/delegates.html). It is an interesting read considering that pretty much everything on their case against delegates turned out to be wrong. Java would me a much better language and a simpler language to develop for had they allowed delegates to go into it.
The 1997 Java lawsuit prevented them from using it, but that does not mean that Java did not add a lot of value and was not a great idea to begin with. So Microsoft had to write their own, from scratch. In the process they would add the features that they needed (and in Mono, we use those extensively) and with the hindsight of knowing what was good and bad about Java, they could build a better Java, and that is what they did.
Miguel.
Re:I just find it's terribly dumb (Score:3, Informative)
It reminds me the Roman empire Caesar Nero who had lots of enemies. He decided to invite all his enemies to great theatre performance. Nero's plan was to put on a production so beautiful that he would make his enemies love him.
Of course it didn't quite work out the way that he planned.
Java, lack of delgates, JNI (Score:3, Informative)
Java has a pretty slick dynamic dispatch of GUI events in the form of java.beans.EventHandler. Is this everything delegates do, maybe not. But it allows you to hook a named method of any active object instance into a menu, mouse action, or other GUI event. Maybe Sun doesn't promote its use beyond IDEs that handle Java Beans and Sun still wants you to use anonymous inner classes, but this facility is pretty powerful, I use it in my GUI programming, and it works just fine.
Whether P/Invoke is slicker than JNI is maybe in the eye of the beholder. If all you want to do is call a method in a Windows dll, P/Invoke is pretty streamlined. If you want to interact with a COM object under .NET, I guess it isn't too bad; if you want a .NET app to act as a COM object, there is some kind of registration/assembly boojum that I haven't figured out.
JNI may be kind of clunky on the C++ side, and it requires "cooperation" on the C++ side I don't see needed with P/Invoke. Also on the minus side, it only allows calls to C function on the C++ side, only allowing invocation of C++ object methods through some kind of handle and casting through static C function prototypes.
On the plus side, I have found JNI to be lucidly documented. If you respect the object locking conventions, I found JNI is perfectly bi-directional -- Java calls into C++, which can call back into Java, or the other way around. I don't know of any way for C++ to call back into .NET unless you register the .NET object as COM, and as I said, the process for COM registration of a .NET object makes JNI look simple and streamlined.
I also find JNI to be thoroughly platform agnostic. They have those naming conventions for the .so and .dll files under OS-X, Linux, Windows -- for a Java app calling down to C++ (for my work for a numeric package written in C++), you have to compile a separate C++ module for each target platform, but you give your users your .jar file and bundle of the different C++ modules, and the correct C++ target is called on whatever platform they are using.
The other thing that has me on Java these days is that I was pretty much hard-wired with my scientific visualization graphcs into Win32 on account of the WinG features developed in the early 90's to get DOS game programs to switch to Windows. I am pretty dependent on the capabilities of ScrollWindowEx() and CreateDIBSection() in order to have a scrollable frame buffer widget where I can set gray level or color of each and every pixel efficiently. Every other platform than Win32, and that includes all of the 'Nix stuff layered on top of X comes up short, as does Microsoft's Windows Forms of all things.
Guess what. Java supports what I want with their BufferedImage() class and if WinForms has anything near equivalent (I guess they do, but they spank your hand that you are doing something not-secure to lock the bytes of the frame buffer). BufferedImage() scrolls had been clunky on Unix owing to the limitations on X, but Sun has a workaround where you can use OpenGL automagically though a commandline switch to get the same WinG hardware accelerated goodness for frame buffer scrolls.
I am solidly a Win32 kind of person, especially with regard to graphics, and Java is a better front end to Win32 along with a way to port Win32 features to other platforms than .NET, wxWidgets, GTK, etc, etc.
Re:Makes good points (Score:2, Informative)
already been done. There's a platform that is so common, *everything* can call modules written in it.
Its called C. Probably not your prefered language, but that doesn't mean it doesn't fulfil your requirements.
Re:Makes good points (Score:1, Informative)
I just use the Firefox extension "Flashblock" which just turns flash animations into play buttons so they are only turned on when needed. Keeps the CPU overhead low :)
Re:Much ado about nothing? (Score:3, Informative)
I am actually not a fan of rewriting software that works. Rewriting is not a decision that must be taken lightly, you introduce regressions, you might drop features, a lot of knowledge embedded in the small details is lost and so on.
But there are certain cases where rewriting is worth doing. I would like to see a few applications rewritten. I do not really want to "rewrite" the panel, but instead come up with new interaction metaphors for the main application launcher. Gnome-Do for example (already written in Mono) is a great tool, but it is a tool for power-users, not a tool for most people.
I would like to see new research, and new ideas for new panels rewritten, and I do not particularly care about what language or platform is used, as long as it produces some nice new ideas, and new metaphors. Gimme is such an attempt by Alex Graveley, written in Python.
I believe that the engine in Moonlight is worth reusing for many new kinds of applications, and it opens the doors for some new creative UIs. And you get to choose if you want to use it or not. If it offends your sensibilities that its written with Mono and C#, then do not use it. It really is that simple, nobody is forcing anyone to use the software I work on. If your religion prohibits prevents you from using software based on Mono, that is fine, nobody is asking you to change your religion.
Miguel.
Re:Makes good points (Score:2, Informative)
Or you could use the open-source Flex SDK [adobe.com] (which includes all GUI widgets) with the free Flex Compiler Shell [adobe.com] to develop Flash content.
We've been developing Flash content without using the Flash IDE for years now. Time to check again?
Re:Open Microsoft (Score:3, Informative)
Yes, the project was started as such. Calling it a "copy" is inaccurate.
No, it isn't. .Net was started because Microsoft couldn't build on Java due to Sun v. Microsoft.
Java aims for Java-the-language penetration above all; Jython and JRuby are tolerated, but aren't anything close to first-class citizens.
You're drinking the anti-Java kool-aid a little too much. The Java Virtual Machine has always been cross-language capable. It was cool in the early days of Java for language developers to target Java bytecode with their compilers.
Jython and JRuby are more than tolerated. Their development is primarily funded by Sun, and the NetBeans IDE has garnered a lot of attention for being one of the best Ruby on Rails IDEs out there.
That being said, it is a fair criticism that the bytecode is Java-centric. Sun is working on changing that (the effort being led by one of the JRuby guys).
The CLR's specific goal is to get a lot of mutually interoperable languages on the same platform.
No, the goal was to create a VM similar to the Java VM that could host multiple languages. This is a subtle but important difference.
Java attempts to contain everything in managed code.
No, it doesn't. Java provides robust interfaces for calling out to native code. The fact that Microsoft refused to support the JNI doesn't change the fact that it exists.
The CLR is smarter than that and provides very powerful and very flexible ways to handle managed/native interop (in a reasonably cross-platform manner, too).
Actually, the CLR is dumber because it makes it too easy to go into native code. There are very few legitimate reasons to go into native code.
Microsoft only released Rotor and made an ECMA standard because they want it all on Windows. Right.
Removing your sarcasm, that's completely accurate. For one thing, Rotor is no longer supported. It's now the Shared Source Common Language Interface (SSCLI), and is licensed so as to not permit commercial use. If Microsoft wanted productive usage of .Net on other platforms, they would not have created such a limiting field of use restriction.
IIRC, Microsoft went and talked to Novell about the Mono project as part of their agreements, but I could be wrong.
The Mono project lived for a good deal before it became part of Novell. Microsoft said that it approached Linux distributions that it believed were infringing their IP. Novell was a particularly interesting target because the Mono project lives there, and necessarily infringes on several Microsoft patents.
I guess we'll see. Personally, I win either way. I use Windows as my primary OS. If Mono gets good, I get the lazy man's porting of applications to other OSes. If it ends up blowing up--well, my primary OS is still fine.
All this being said, I'm not anti-Mono. It just grates on my nerves when half-truths or "used to be" truths are bandied about as facts. Java has addressed quite a few of its shortcomings in the past few releases, and I don't think it's productive to deride Java based on things that just aren't true anymore.
Re:Java, lack of delgates, JNI (Score:3, Informative)
In the end, .NET delegates are really just syntactic sugar for Java listener interfaces - anyone who'd seen what a C# delegate declaration compiles to IL would know that. The only difference is that runtime inserts the glue code automatically.
Registration is a COM issue, not a .NET issue (you'd have to do it for a native COM component as well).
Anyway. On one hand, Java has a 3rd-party solution in form of J/Invoke [jinvoke.com], which is pretty slick. On the other, C# still beats it at interop because it has structs, unions (StructLayout.Explicit), unsigned integer types, and pointers - which is enough to express any, no matter how complicated, C or C++ API directly. This is rarely truly needed, but when it is, the ability to do it is invaluable.
There is a little-known trick there. You don't actually need to register COM objects to call them - .NET COM marshalling works for any .NET object if you pass it through P/Invoke to C++ code. You can manually declare a C++ COM-style interface (i.e., with AddRef/Release/QueryInterface in the first three vtable slots), write a function that takes a pointer to that, call it via P/Invoke passing it a .NET object, and it would just work. It even works in Mono on any supported platform, even though Linux doesn't have any Win32 COM infrastructure (including registration). In the same manner, you can return objects from C++ that are directly callable from .NET.
It's a well-known fact that any serious development using WinForms requires calling WinAPI via P/Invoke for something eventually, so no surprise there. A pity, but at least they make it easy to do so by exposing handles of all controls (on the other hand, it effectively kills portability right there). WPF is much better in that regard, though.
If only Java applications would look native on Win32... they made great progress with 1.5 and 1.6, but their font smoothing still sucks, and all file open/save dialogs are non-native (so you don't get customized favorites pane, and proper context menu with items from all Explorer plugins that are installed on the system).