Posted by
chrisd
on from the what's-a-nice-coder-like-you-doing-in-a-place-like-this dept.
twigman writes "MSDN has an interview with Ximian CTO Miguel de Icaza about Mono and past Ximian projects. It's a surprisingly objective discussion, definitely worth a read." Of course we're not surprised Miguel is objective...
Why does working with Microsoft imply an abandonment of GNU values? Ximian are clearly deeply involved in open source projects (i.e. Gnome & Mono) - and as a company are busy working out how to make money from this investment.
You could argue that what open-source needs most is more collaboration with MS. For example, just imagine what it would do for acceptance of Linux if a company worked with MS to produce a reliable up-to-date version of Word for Linux. Of course, if you get into bed with MS, there is a fair chance you're going to get screwed - but that just means that Ximian (or anyone) has to be very careful in their negotiations.
While branding MS as the devil is easy & popular - it may be possible to work with them without selling your soul:-)
No one was banned from DotGNU lists
by
bkuhn
·
· Score: 5, Informative
There is a factual error in the interview.
No one was banned from any DotGNU lists. A few times in the early days of the project, the lists were put into moderation mode when discussion got inappropriately heated or off topic. Martin claimed that having this moderation imposed constitued banning, but that simply isn't the case. It's unfortunate that Martin felt rejected by the need for moderation, but we didn't intend it as such.
I even personally had some of my posts rejected during one of the moderation periods.
Bradley M. Kuhn, member of the DotGNU Steering Committee
Ximian has been doing a good job balancing financial practicality with free software ideoligy. They make a GPL'd PIM (Evolution) and sell a proprietary interface to a proprietary server software. They have to make money, right? Exchange Connector only hurts the people who are already using Exchange.
The idea of using the.NET standard to create a robust component architecture is a pretty good idea. Microsoft is betting the farm on.NET. It is going to succeed. What is the harm in having a GPL implimentation of it? Even if it doesn't help *IX interoperate with the MS world, GNOME (and everybody in the GNU world) get a seemingly good technology. Morover, having Mono will allow the millions of.NET developers to make GPL stuff in the evenings without having to climb a steep learning curve.
We could have had a working Mono two years ago.
by
mj6798
·
· Score: 5, Insightful
I'm glad to see that there are open source projects based on a language and runtime that supports a component architecture and runtime safety from the ground up. I think a Linux desktop environment and services platform based on C#/CLR will be so much better, more efficient, and more robust than the current systems based on plain C or C++. This has long been overdue.
What I am disappointed about is that the Linux community could have started on this several years ago. While there are some cosmetic differences between C#/CLR and Java/JVM, the object models and performance of the two languages and runtimes are essentially the same. And there actually are already several open source, high performance Java implementations already.
Even today, I think it still makes more sense to use something like GNU gcj or Intel's Open Runtime and maybe the existing native Gnome widgets (for which there are already Java bindings). But Mono is obviously not going to go that route. Too bad.
Nice to see Brad Cox mentioned
by
LizardKing
·
· Score: 5, Interesting
I was pleased to see Brad Cox mentioned - the man who invented Objective C (the lesser known Object Oriented C derivative). His seminal book on Object Oriented Programming was the first thing I read on the subject, and although I was disappointed in one sense - I was expecting the equivalent of K&R for Objective C - it was a great read on why software hadn't advanced in the same leaps and bounds as hardware. The books goals (maximium code reuse through self contained components called software IC's) have still not been fully realised, but Java Beans and Bonobo components are definitely a step in the right direction.
Re:Miguel is the smart fellow
by
Metrol
·
· Score: 5, Insightful
KDE's DCOP and KParts are rather incomplete imitations of CORBA.
First off, I'm not a developer. At best I just read a fair amount about what folks are doing. One of the things I personally found interesting about this interview was Miguel listing problems with Bonobo and CORBA that sounded a LOT like the reasons KDE doesn't use those technologies. Essentially that bindings such as CORBA are like swatting a fly with a hammer for desktop apps, thus a simpler approach was taken with things like DCOP.
Again, I'm not in the trenches, but from an observers point of view it seems that Gnome is just needing that next set of bindings to be developed sometime later over and over again. Everything was going to be better with CORBA and Bonobo linking everything. Now that's all the wrong approach, and Mono is needed. I may be way of base here, it just seems like it's the "bindings to be developed" of the month club.
On the other hand, KDE made the call to move things to DCOP a while ago and they seem to be sticking to their guns on it. The developers are extending where needed, but leaving the core intact as it's doing what they intended from the onset. I honestly don't know if this is a good or bad thing in practice. It seems like a more reasoned approach, and it's certainly produced a wonderful desktop environment.
Early into next year both projects are looking to have major releases. I guess we'll see which approach provides the payoff of a more robust environment that developers prefer to work on.
-- The line must be drawn here. This far. No further.
The MS APIs have been reasonably consistent since Windows 3. A new OS or library only adds functions, doesn't revise old ones. You should be able to compile Win 3.x code on XP with little problem should you so wish.
Re:Miguel is the smart fellow
by
Anonymous Coward
·
· Score: 5, Interesting
> One of the things I personally found
> interesting about this interview was Miguel
> listing problems with Bonobo and CORBA that
> sounded a LOT like the reasons KDE doesn't use
> those technologies. Essentially that bindings
> such as CORBA are like swatting a fly with a
> hammer for desktop apps, thus a simpler
> approach was taken with things like DCOP.
Actually, he didn't say this. He said, "CORBA is good when you define coarse interfaces, and most Bonobo interfaces are coarse. The only problem is that Bonobo/CORBA interfaces are not good for small interfaces. For example, an XML parsing Bonobo/CORBA component would be inefficient compared to a C API."
Basically, CORBA is good enough for it's current use (GUI components and general application interfacing) but it's a bit heavy for simple things like a (high performance) XML parsing library. DCOP isn't any more efficient. It's likely less efficient since with DCOP there's a lot of serialization/deserialization to strings whereas that serialization doesn't take place if you're using Orbit (GNOME's CORBA) as an inproc procedure. Even when it happens, it's binary serialization/deserialization so it's likely more efficient.
> Again, I'm not in the trenches, but from an
> observers point of view it seems that Gnome is
> just needing that next set of bindings to be
> developed sometime later over and over again.
> Everything was going to be better with CORBA
> and Bonobo linking everything. Now that's all
> the wrong approach, and Mono is needed. I may
> be way of base here, it just seems like it's
> the "bindings to be developed" of the month club.
Again, no. Bonobo is still good and it solves problems that Mono doesn't. Bonobo interfaces are being added to Mono, just like Gtk+ bindings and gnomedb bindings.
One thing Mono has the power to do is unify GNOME and KDE. Mono is getting full GNOME bindings. From what I understand, there are KDE developers who are working on KDE bindings (including DCOP). Because of the way the C# component architecture works, you can use components with little knowledge on how they were actually built, so you can mix and match more easily. Once the work is done, you should be able to embed a KPart in a GNOME component that's embedded in a KDE component that's embedded in a WinForm component.
I don't know about you, but I think that it's cool enough to be woth pursuing.
GNOME != Ximian
by
ambrosius27
·
· Score: 4, Insightful
"Again, I'm not in the trenches, but from an observers point of view it seems that Gnome is just needing that next set of bindings to be developed sometime later over and over again. "
GNOME *is* sticking to its guns with CORBA and Bonobo. The developers are actively working on the Bonobo component model and Orbit2, and they plan on using them for the forseeable future. They're actually quite excited at the possibilities these tools are bringing to them and their desktop environment. From what I've seen on the lists, the developers have been hard at work ironing out wrinkles in the inproc/out-of-proc components and are happy with the speed of Orbit.
Now, I will concede that you're right in that *Miguel* has moved on. Even before Bonobo had fully matured (that's happening with GNOME2 development after the GNOME 1.4 experimentation), Miguel decided that the.NET framework is the way to go. I say, good for him! If Miguel and Ximian can make MONO into a beautiful development platform that is better than Bonobo, that's great! If that does happen (and it's going to be at least year before we can tell how it's doing), GNOME will probably be happy to start using MONO and employ Bonobo as a bridge to the new platform. Until then, GNOME is quite happy with Bonobo.
Jonathan Ingram posted in a thread that if Orbit really proves great, KDE would be happy to use it. In the meantime, KDE is using their own solution (which they like quite well) and will let GNOME do the Orbit development. You can compare GNOME's stance with MONO in the same way: wait and see.
Remember Miguel != GNOME and even Ximian != GNOME. Both are big players in GNOME, but GNOME is larger than them. Cheers!
In my (rather limited) experience in programming Win32 and MSDOS I have encountered this:
Setting the line dash style broke in Win98 and WinME. This appears to be a direct attempt to break non-MFC programs that tried to simulate the mouse highlight. It broke Qt, the GTK port, and FLTK. It appears to be fixed again in XP and always worked in NT.
Append, join, subst, (ie every single program that could do anything similar to a symbolic link) disappeared or broke in Window 3.1. Again I think this is a direct attempt by MicroSoft to disallow Unix compatability (symbolic links would allow the MSDOS file system to match a Unix file system, and are probably easy to implement, so I cannot think of any other reason they don't do it).
Support for switchar disappeared in MSDOS 6. This broke most of my programs which exec'd other programs, and again appears to have been done purposely to break Unix compatability (they could instead have made the programs accept either - or / easily enough...).
Storage and retrival of the current directory changed in MSDOS 5 to uppercase the name and turn all forward slashes into backward slashes and truncated all the filenames at 8.3 characters. This broke an enormous amount of Unix-ported software and required it to be rewritten to store the current directory locally.
Since I have done very little Windows programming, yet have encountered these, I would say the claim that Windows remains compatable between versions is false. It also seems to me that most of the changes are on purpose to sabotage the ability to write portable programs.
Slashdot Mirror
Blah blah.. standard crap about reading your own site :)
Why does working with Microsoft imply an abandonment of GNU values? Ximian are clearly deeply involved in open source projects (i.e. Gnome & Mono) - and as a company are busy working out how to make money from this investment.
:-)
You could argue that what open-source needs most is more collaboration with MS. For example, just imagine what it would do for acceptance of Linux if a company worked with MS to produce a reliable up-to-date version of Word for Linux. Of course, if you get into bed with MS, there is a fair chance you're going to get screwed - but that just means that Ximian (or anyone) has to be very careful in their negotiations.
While branding MS as the devil is easy & popular - it may be possible to work with them without selling your soul
There is a factual error in the interview.
No one was banned from any DotGNU lists. A few times in the early days of the project, the lists were put into moderation mode when discussion got inappropriately heated or off topic. Martin claimed that having this moderation imposed constitued banning, but that simply isn't the case. It's unfortunate that Martin felt rejected by the need for moderation, but we didn't intend it as such.
I even personally had some of my posts rejected during one of the moderation periods.
Bradley M. Kuhn, member of the DotGNU Steering Committee
Ximian has been doing a good job balancing financial practicality with free software ideoligy. They make a GPL'd PIM (Evolution) and sell a proprietary interface to a proprietary server software. They have to make money, right? Exchange Connector only hurts the people who are already using Exchange.
.NET standard to create a robust component architecture is a pretty good idea. Microsoft is betting the farm on .NET. It is going to succeed. What is the harm in having a GPL implimentation of it? Even if it doesn't help *IX interoperate with the MS world, GNOME (and everybody in the GNU world) get a seemingly good technology. Morover, having Mono will allow the millions of .NET developers to make GPL stuff in the evenings without having to climb a steep learning curve.
The idea of using the
What I am disappointed about is that the Linux community could have started on this several years ago. While there are some cosmetic differences between C#/CLR and Java/JVM, the object models and performance of the two languages and runtimes are essentially the same. And there actually are already several open source, high performance Java implementations already.
Even today, I think it still makes more sense to use something like GNU gcj or Intel's Open Runtime and maybe the existing native Gnome widgets (for which there are already Java bindings). But Mono is obviously not going to go that route. Too bad.
I was pleased to see Brad Cox mentioned - the man who invented Objective C (the lesser known Object Oriented C derivative). His seminal book on Object Oriented Programming was the first thing I read on the subject, and although I was disappointed in one sense - I was expecting the equivalent of K&R for Objective C - it was a great read on why software hadn't advanced in the same leaps and bounds as hardware. The books goals (maximium code reuse through self contained components called software IC's) have still not been fully realised, but Java Beans and Bonobo components are definitely a step in the right direction.
KDE's DCOP and KParts are rather incomplete imitations of CORBA.
First off, I'm not a developer. At best I just read a fair amount about what folks are doing. One of the things I personally found interesting about this interview was Miguel listing problems with Bonobo and CORBA that sounded a LOT like the reasons KDE doesn't use those technologies. Essentially that bindings such as CORBA are like swatting a fly with a hammer for desktop apps, thus a simpler approach was taken with things like DCOP.
Again, I'm not in the trenches, but from an observers point of view it seems that Gnome is just needing that next set of bindings to be developed sometime later over and over again. Everything was going to be better with CORBA and Bonobo linking everything. Now that's all the wrong approach, and Mono is needed. I may be way of base here, it just seems like it's the "bindings to be developed" of the month club.
On the other hand, KDE made the call to move things to DCOP a while ago and they seem to be sticking to their guns on it. The developers are extending where needed, but leaving the core intact as it's doing what they intended from the onset. I honestly don't know if this is a good or bad thing in practice. It seems like a more reasoned approach, and it's certainly produced a wonderful desktop environment.
Early into next year both projects are looking to have major releases. I guess we'll see which approach provides the payoff of a more robust environment that developers prefer to work on.
The line must be drawn here. This far. No further.
The MS APIs have been reasonably consistent since Windows 3. A new OS or library only adds functions, doesn't revise old ones. You should be able to compile Win 3.x code on XP with little problem should you so wish.
"An interview with Miguel de Icaza on MSDN?"
-- I thought --
"Hey, maybe they arent such a bad bunch after all..."
Then, I clicked on the link, and my netscape browser promptly crashed.
Given that Linux perceives Microsoft as Threat Number One (see most links here) one can't stop wonder what Ximians hidden agenda is.
:-)
> One of the things I personally found
> interesting about this interview was Miguel
> listing problems with Bonobo and CORBA that
> sounded a LOT like the reasons KDE doesn't use
> those technologies. Essentially that bindings
> such as CORBA are like swatting a fly with a
> hammer for desktop apps, thus a simpler
> approach was taken with things like DCOP.
Actually, he didn't say this. He said, "CORBA is good when you define coarse interfaces, and most Bonobo interfaces are coarse. The only problem is that Bonobo/CORBA interfaces are not good for small interfaces. For example, an XML parsing Bonobo/CORBA component would be inefficient compared to a C API."
Basically, CORBA is good enough for it's current use (GUI components and general application interfacing) but it's a bit heavy for simple things like a (high performance) XML parsing library. DCOP isn't any more efficient. It's likely less efficient since with DCOP there's a lot of serialization/deserialization to strings whereas that serialization doesn't take place if you're using Orbit (GNOME's CORBA) as an inproc procedure. Even when it happens, it's binary serialization/deserialization so it's likely more efficient.
> Again, I'm not in the trenches, but from an
> observers point of view it seems that Gnome is
> just needing that next set of bindings to be
> developed sometime later over and over again.
> Everything was going to be better with CORBA
> and Bonobo linking everything. Now that's all
> the wrong approach, and Mono is needed. I may
> be way of base here, it just seems like it's
> the "bindings to be developed" of the month club.
Again, no. Bonobo is still good and it solves problems that Mono doesn't. Bonobo interfaces are being added to Mono, just like Gtk+ bindings and gnomedb bindings.
One thing Mono has the power to do is unify GNOME and KDE. Mono is getting full GNOME bindings. From what I understand, there are KDE developers who are working on KDE bindings (including DCOP). Because of the way the C# component architecture works, you can use components with little knowledge on how they were actually built, so you can mix and match more easily. Once the work is done, you should be able to embed a KPart in a GNOME component that's embedded in a KDE component that's embedded in a WinForm component.
I don't know about you, but I think that it's cool enough to be woth pursuing.
"Again, I'm not in the trenches, but from an observers point of view it seems that Gnome is just needing that next set of bindings to be developed sometime later over and over again. "
.NET framework is the way to go. I say, good for him! If Miguel and Ximian can make MONO into a beautiful development platform that is better than Bonobo, that's great! If that does happen (and it's going to be at least year before we can tell how it's doing), GNOME will probably be happy to start using MONO and employ Bonobo as a bridge to the new platform. Until then, GNOME is quite happy with Bonobo.
GNOME *is* sticking to its guns with CORBA and Bonobo. The developers are actively working on the Bonobo component model and Orbit2, and they plan on using them for the forseeable future. They're actually quite excited at the possibilities these tools are bringing to them and their desktop environment. From what I've seen on the lists, the developers have been hard at work ironing out wrinkles in the inproc/out-of-proc components and are happy with the speed of Orbit.
Now, I will concede that you're right in that *Miguel* has moved on. Even before Bonobo had fully matured (that's happening with GNOME2 development after the GNOME 1.4 experimentation), Miguel decided that the
Jonathan Ingram posted in a thread that if Orbit really proves great, KDE would be happy to use it. In the meantime, KDE is using their own solution (which they like quite well) and will let GNOME do the Orbit development. You can compare GNOME's stance with MONO in the same way: wait and see.
Remember Miguel != GNOME and even Ximian != GNOME. Both are big players in GNOME, but GNOME is larger than them. Cheers!
~~~~~~~~~
dissertus scribendo latine videri volo.
Setting the line dash style broke in Win98 and WinME. This appears to be a direct attempt to break non-MFC programs that tried to simulate the mouse highlight. It broke Qt, the GTK port, and FLTK. It appears to be fixed again in XP and always worked in NT.
Append, join, subst, (ie every single program that could do anything similar to a symbolic link) disappeared or broke in Window 3.1. Again I think this is a direct attempt by MicroSoft to disallow Unix compatability (symbolic links would allow the MSDOS file system to match a Unix file system, and are probably easy to implement, so I cannot think of any other reason they don't do it).
Support for switchar disappeared in MSDOS 6. This broke most of my programs which exec'd other programs, and again appears to have been done purposely to break Unix compatability (they could instead have made the programs accept either - or / easily enough...).
Storage and retrival of the current directory changed in MSDOS 5 to uppercase the name and turn all forward slashes into backward slashes and truncated all the filenames at 8.3 characters. This broke an enormous amount of Unix-ported software and required it to be rewritten to store the current directory locally.
Since I have done very little Windows programming, yet have encountered these, I would say the claim that Windows remains compatable between versions is false. It also seems to me that most of the changes are on purpose to sabotage the ability to write portable programs.