Slashdot Mirror
Inline Review With Miguel De Icaza
Interview With Miguel de Icaza Bringing a component architecture to the UNIX platform
SummaryBy Dare (Carnage4Life) Obasanjo
In this interview, Miguel de Icaza, the founder of GNOME and Ximian, talks about UNIX components, Bonobo, Mono and .NET.
Dare Obasanjo: You have recently been in the press due to Ximian's announcement that it shall create an Open Source implementation of Microsoft's .NET development platform. Before the recent furor you've been notable for the work you've done with GNOME and Bonobo. Can you give a brief overview of your involvement in Free Software from your earlier projects up to Mono?
Miguel de Icaza: I have been working for the past four years on the GNOME project in various areas: organization of it, libraries and applications. Before that I used to work on the Linux kernel, I worked for a long time on the SPARC port, then on the software raid and some on the Linux/SGI effort. Before that I had written the Midnight Commander file manager.
Dare Obasanjo: In your Let's Make Unix Not Suck series you mention that UNIX development has long been hampered by a lack of code reuse. You specifically mention Brad Cox's concept of Software Integrated Circuits, where software is built primarily by combining reusable components, as a vision of how code reuse should occur. Many have countered your arguments by stating that UNIX is built on the concept of using reusable components to build programs by connecting the output of smaller programs with pipes. What are your opinions of this counter-argument?
Miguel de Icaza: Well, the paper addresses that
question in detail. A `pipe' is hardly
a complete component system. It is a transport
mechanism that is used
with some well known protocols (lines, characters,
buffers) to process
information. The protocol only has a flow of
information.
Details are on the paper:
http://primates.ximian.com/~miguel/bongo-bong.html
[Dare -- check the section
entitled "Unix Components: Small is Beautiful"]
Dare Obasanjo: Bonobo was your attempt to create a UNIX component architecture using CORBA as the underlying base. What are the reasons you have decided to focus on Mono instead?
Miguel de Icaza: The GNOME project goal was to bring missing technologies to Unix and make it competitive in the current market place for desktop applications. We also realized early on that language independence was important, and that is why GNOME APIs were coded using a standard that allowed the APIs to be easily wrapped for other languages. Our APIs are available to most programming languages on Unix (Perl, Python, Scheme, C++, Objective-C, Ada).
Later on we decided to use better methods for encapsulating our APIs, and we started to use CORBA to define interfaces to components. We complemented it with policy and a set of standard GNOME interfaces for easily creating reusable, language independent components, controls and compound documents. This technology is known as Bonobo. Interfaces to Bonobo exist for C, Perl, Python, and Java.
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.
I also wrote at some point:My interest in .NET comes from the attempts that we have made before in the GNOME project to achieve some of the things .NET does:
- APIs that are exposed to multiple languages.
- Cross-language integration.
- Contract/interface based programming.
And on top of things, I always loved various things about Java. I just did not love the Java combo that you were supposed to give or take.
APIs exposed to many languages we tried by having a common object base (GtkObject) and then following an API contract and a format that would allow others to wrap the APIs easily for their programming language. We even have a Scheme-based definition of the API that is used to generate wrappers on the fly. This solution is suboptimal for many reasons.
The Cross-language integration we have been doing with CORBA, sort of like COM, but with an imposed marshalling penalty. It works pretty well for non inProc components. But for inProc components the story is pretty bad: since there was no CORBA ABI that we could use, the result is so horrible, that I have no words to describe it.
On top of this problem, we have a proliferation of libraries. Most of them follow our coding conventions pretty accurately. Every once in a while they either wont or we would adopt a library written by someone else. This had lead to a mix of libraries that although powerful in result implement multiple programming models, sometimes different allocation and ownership policies and after a while you are dealing with 5 different kind of "ref/unref" behaviours (CORBA local references, CORBA object references on Unknown objects, reference count on object wrappers) and this was turning into a gigantic mess.
We have of course been trying to fix all these issues, and things are looking better (the GNOME 2.x platform does solve many of these issues, but still).
.NET seemed to me like an upgrade for Win32 developers: they had the same problems we had when dealing with APIs that have been designed over many years, a great deal of inconsistency. So I want to have some of this new "fresh air" available for building my own applications.
Dare Obasanjo: Bonobo is slightly based on COM and OLE2 as can be gleaned from the fact that Bonobo interfaces are all based on the Bonobo::Unknown interface which provides two basic services: object lifetime management and object functionality-discovery and only contains three methods:
module Bonobo {
interface Unknown {
void ref ();
void unref ();
Object query_interface (in string repoid);
};
};
which is very similar to Microsoft's COM IUnknown
interface which has the
following methods
HRESULT QueryInterface(REFIID riid, void **ppvObject);
ULONG AddRef();
ULONG Release();
Does the fact that .NET seems to spell the impending
death of COM mean that
Mono will spell the end of of Bonobo? Similarly
considering that .NET plans
to have semi-transparent
COM/.NET interoperability, is there a similar plan
for Mono and Bonobo?
Miguel de Icaza: Definetly. Mono will have to interoperate with a number of systems out there including Bonobo on GNOME.
Dare Obasanjo: A number of parties have claimed that Microsoft's NET platform is a poor clone of the Java(TM) platform. If this is the case why hasn't Ximian decided to clone or use the Java platform instead of cloning Microsoft's .NET platform?
Miguel de Icaza: We were interested in the CLR because it solves a problem that we face every day. The Java VM did not solve this problem.
Dare Obasanjo: On the Mono Rationale page it is pointed out that Microsoft's .NET strategy encompasses many efforts including
- The .NET development platform, a new platform for writing software.
- Web services.
- Microsoft Server Applications.
- New tools that use the new development platform.
- Hailstorm, the Passport centralized single-signon system that is being integrated into Windows XP.
Miguel de Icaza: Not at this point. We have a commitment to develop currently:
- A CLI runtime with a JITer for x86 CPUs.
- A C# compiler.
- A class library
All of the above with the help of external contributors. You have to understand that this is a big undertaking and that without the various people who have donated their time, expertise and code to the project we would not even have a chance of delivering a complete product any time soon.
We are doing this for selfish reasons: we want a better way of developing Linux and Unix applications ourselves and we see the CLI as such a thing.
That being said, Ximian being in the services and support business would not mind extending its effort towards making the Mono project tackle other things like porting to new platforms, or improving the JIT engine, or focusing on a particular area of Mono.
But other than this, we do not have plans at this point to go beyond the three basic announcements that we have made.
Dare Obasanjo: There are a number of other projects that are implementing other parts of .NET on Free platforms that seem to be have friction with the Mono project. Section 7.2 of Portable.NET's FAQ seems to indicate they have had conflict with the Mono project as does the banning of Martin Coxall from the dotGNU mailing list. What are your thoughts on this?
Miguel de Icaza: I did not pay attention to the actual details of the banning of Martin from the DotGNU mailing lists. Usenet and Internet mailing lists are a culture of their own and I think this is just another instance of what usually happens on the net. It is definitely sad.
The focus of Mono and .NET is slightly different: we are writing as much as we can in a high level language like C#, and writing reusable pieces of software out of it. Portable.NET is being written in C.
Dare Obasanjo: There have been conflicting reports about Ximian's relationship with Microsoft. On one hand there are reports that seem to indicate that there may be licensing problems between the license that will govern .NET and the GPL. On the other hand there is an indication that some within Microsoft are enthusiastic about Mono. So exactly what is Ximian's current relationship is with Microsoft and what will be done to ensure that Mono does not violate Microsoft's licenses on .NET if they turn out to be restrictive?
Miguel de Icaza: Well, for one we are writing everything from scratch.
We are trying to stay on the safe side regarding patents. That means that we implement things in a way that has been used in the past and we are not doing tremendously elaborate or efficient things in Mono yet. We are still very far from that. But just using existing technologies and techniques.
Dare Obasanjo: It has been pointed out that Sun retracted Java(TM) from standards processes at least twice, will the Mono project continue if .NET stops being an open standard for any reason?
Miguel de Icaza: The upgrade on our development platform has a value independently of whether it is a standard or not. The fact that Microsoft has submitted its specifications to a standards body has helped, since people who know about these problems have looked at the problem and can pin point problems for interoperability.
Dare Obasanjo: Similarly what happens if Dan Kusnetzky's prediction comes true and Microsoft changes the .NET APIs in the future? Will the Mono project play catchup or will it become an incompatible implementation of .NET on UNIX platforms?
Miguel de Icaza: Microsoft is remarkably good at keeping their APIs backwards compatible (and this is one of the reasons I think they have had so much success as a platform vendor). So I think that this would not be a problem.
Now, even if this was a problem, it is always possible to have multiple implementations of the same APIs and use the correct one by choosing at runtime the proper "assembly". Assemblies are a new way of dealing with software bundles and the files that are part of an assembly can be cryptographically checksummed and their APIs programmatically tested for compatibility. [Dare -- Description of Assemblies from MSDN gloassary]
So even if they deviate from the initial release, it would be possible to provide assemblies that are backwards compatible (we can both do that: Microsoft and ourselves)
Dare Obasanjo: Looking at the Mono class status page I noticed that a large number of .NET class libraries are not being implemented in Mono such as WinForms, ADO.NET, Web Services, XML schemas, reflection and a number of others. This means that it is very likely that when Mono and .NET are finally released apps written for .NET will not be portable to Mono. Is there any plan to rectify this in the future or is creating a portable .NET platform not a goal of the Mono project? Similarly what are the short and long term goals of the Mono project?
Miguel de Icaza: The status web page reflects the classes that people have "requested" to work on. The status web page is just a way of saying `Hey, I am working on this class as of this date' to avoid code duplication. If someone registers their interest in working on something and they do not do something after some period of time, then we can reclaim the class.
We are on the very early stages of the project, so you do see more work going on the foundational classes than on the end user classes.
I was not even expecting so many great and talented programmers to contribute so early in the project. My original prediction is that we would spend the first three months hacking on our own in public with no external contributions, but I have been proved wrong.
You have to realize that the goals of the Mono project are not only the goals of Ximian. Ximian has a set of goals, but every contributor to the project has his own goals: some people want to learn, some people like working on C#, some people want full .NET compatibility on Linux, some people want language independence, some people like to optimize code, some people like low level programming and some people want to compete with Microsoft, some people like the way .NET services work.
So the direction of the project is steered by those that contribute to it. Many people are very interested in having a compatible .NET implementation for non-Windows platforms, and they are contributing towards filling those gaps.
Dare Obasanjo: How does Ximian plan to pay for the costs of developing Mono especially after the failure of a number of recent venture funded, Free Software-based companies like Indrema, Eazel and Great Bridge and the fact that a sizable percentage of the remaining Free Software based companies are on the ropes? Specifically how does Ximian plan to make money at Free Software in general and Mono in particular?
Miguel de Icaza:Ximian provides support and services. We announced a few of our services recently, and more products and services have been on the pipeline for quite a while and would be announced during the next six months.
Those we announced recently are:
- Red Carpet Express: a subscription service for those who want a reliable high speed access to the Red Carpet servers.
- Red Carpet Corporate Connect: We modified our Red Carpet updater technology to help people manage networks of Linux workstations easily and to deploy and maintain custom software packages.
- Support and services for the GNOME desktop and Evolution: Our latest boxed products are our way of selling support services for the various products we ship.
The particular case of Mono is interesting. We are working on Mono to reduce our development costs. A very nice foundation has been laid and submitted to ECMA. Now, with the help of other interested parties that also realize the power of it, we are developing the Mono runtime and development tools to help us improve our productivity.
Indeed, the team working on Mono at Ximian is the same team that provided infrastructural help to the rest of the company in the past.
Dare Obasanjo: It is probably little known in some corners that you once interviewed with Microsoft to work on the SPARC port of Internet Explorer. Considering the impact you have had on the Free Software community since then, have you ever wondered what your life would have been like if you had become a Microsoft employee?
Miguel de Icaza: I have not given it a lot of thought, no. But I did ask everyone I interviewed at Microsoft to open source Internet Explorer, way before Netscape Communicator was Open Sourced ;-)
He didn't ask what we're all dying to know:
Why does the ximian logo look exactly like a spider shoved up somebody's left nostril?
I saw this on k5 yesterday. I guess Dare thinks you're only worthy of also-ran status, Hemos.
so, Miguel is obsoleting bonobo before it is even ready for primetime? If you pay attention troughout the interview in the end it just boils down to..
"we were having a really tough time meeting our goals so we've decided to do this instead, Microsoft was doing it so we thought if they can make billions off of it maybe we can make a few mil."
You know, I used to love Gnome when the people behind it knew what they were driving towards an object based unix framework.. nowadays they haven't a clue, KDE has put up and it's time Miguel shut up.
--iamnotayam
i like that last line of the interview.
= i asked microsoft to give away everything that they had paid developers to make for the last 3 years for free...
every contributor to the project has his own goals: some people want to learn, some people like working on C#, some people want full .NET compatibility on Linux, some people want language independence, some people like to optimize code, some people like low level programming and some people want to compete with Microsoft, some people like the way .NET services work.
Does any contributor's goal include a focus on usability issues and user experience design? If so, they weren't apparently worth listing.
As in many other interviews, de Icaza's comments are focused almost entirely on technical issues, and not on design issues. Component architectures may be fascinating for engineers, but they don't deliver an enhanced experience for the user by themselves.
To really improve the Linux user experience will require the kind of passionate engagement with the user that Apple has had, but instead we seem to be seeing a very programmer-centered set of interests and preoccupations at Ximian.
Tim
Basicly, yes. There might be some cases where diarrhea might get some bonus points. An overwhelming stench, interesting color, or identifyable food chunks, might earn a couple of points. The highest rating I would feel comfortable giving diarrhea is a 2. Today's bowel movement was semi-solid, so it gets a 3.
I still don't see how mono will solve the inter language problems in unix. Will they have a
Will updating a
Anyway, I'm kind of happy people are starting to address the inter language issues. I have a template based C++ library (NURBS++ if you care to know), I'd like to integrate it in other languages easilly so I can add scripting to it.
Scheme might be better then C++ for RAD and idea testing. Not sure, but with something like
Why did you poast this on slashdot too?
Y'know, I hear this all the time, but it just ain't true. The C++ support for Gnome is horrendous. It's been a few months since I've last looked, though. Has it improved at all?
As an example, I'd like to use the canvas in a project I'm planning but there wasn't any C++ interface when last I looked.
I've always wondered what the point of the interpretted code was. Why not just make a new object format, or extend an existing one, but make it pure intel object code? You could even just mandate use a subset of it to make it easier to write an interpreter on non-Intel platforms. This seems like it would be much more effecient. The real gain from .NET is a common object format for OO languages, so why not just make ELF better?
Engineering and the Ultimate
Does any contributor's goal include a focus on usability issues and user experience design? If so, they weren't apparently worth listing.
Considering that they are currently working on the compiler, the language runtime and base class libraries for Mono I fail to see what user interfaces have to do with anything at this stage in the development process.
On the other hand if this was an interview about GNOME, which it isn't then I assume he would have mentioned the user interface issues.
I think this will put a major crunch into development projects like Mono and .Net
Obviously this interview was probably done a few weeks ago, so I wonder how things have changed over there.
I'm just wonder how much demand there will be for projects like this, especially if MS is betting the farm on it. You can only bet the farm so many times before you loose.
"It is a greater offense to steal men's labor, than their clothes"
What we need is a cross-platform component model, not a UNIX-only affair. Something like Trolltech are doing.
Unable to read configuration file '/bigassraid/htdig//conf/14229.conf'
Geocrawler error message.
On the question on what they are supposed to live on:
* Red Carpet Express: a subscription service for those who want a reliable high speed access to the Red Carpet servers.
* Red Carpet Corporate Connect: We modified our Red Carpet updater technology to help people manage networks of Linux workstations easily and to deploy and maintain custom software packages.
* Support and services for the GNOME desktop and Evolution: Our latest boxed products are our way of selling support services for the various products we ship.
Are you kidding?
Failure of Gnome is its lack of believablity. Never before, in history of unix is a software more buggy and bloated. Nor a leader more misguided, nieve than Migual (well there was steve job)
It so bloated that gnome doll is used as a floating booyie. We need a really solution that will make linux desktop more acceptable. Unfornately Gnome does not offer any real options...only promises(like Microsoft). I believe its time we reinvent the wheel and design our own application system. One that is not bloated and does not have the smell of ass kissing. A bold new fresh way that seeks the heart of the operating system.
I don't get it. Is that like an interview?
That might be why he's using the .NET standard
It's here now, and it's called KDE
cd wine
:-)
vi profiles/file.c
(..)
* Copyright 1993 Miguel de Icaza
If it is the very same person, he was *always* fascinated by MS 'technology'
Yeah, except that libsigc++ is horribly unportable compared to the highly portable moc, which has been ported to every major compiler that Qt runs on (on Linux, Solaris, HP/UX, Windows, and even MacOS).
KDE sucks.
Gnome sucks.
Computers, in general, suck.
This interview wasn't about Gnome; it was about a component model that might be better than the one Gnome currently uses. Although MS doesn't often come up with good ideas, it does employ some extremely bright people; if some of those bright people come up with a good idea, it behooves us to learn.
In this way, perhaps computers will someday suck less.
Microsoft is to software what Budweiser is to beer.
I would like to see a cook-off between Mono and Parrot though, for similar high-level code. It would seem smart to use the best underlying VM for all of these high level languages.
The best GPL'd thing that comes closest is doxygen. Try it, you'll like it. A lot of opensource projects use it (abiword/libstdc++-v3, others)
I had thought about trying to implement a tree-view in nautilus. I might still try this: it would be cool to
1) use the XML dump for gcc data structures
2) dump this as part of the build process into some kind of file
3) parse this with a tool into tree graphs
4) (optional) config nautilus to work with it.
Why would anyone want a Windows .NET clone? We want choice.
Portable.NET has a different focus to Mono. Writing the compiler in C has two benefits: speed and bootstrapping. A well-crafted compiler in C will always be faster than one written in a garbage collected language, no matter how good the JIT is.
Bootstrapping is also easier with a C compiler: anyone with gcc can install Portable.NET and get it to run on their system. To bootstrap Mono, you have to have Microsoft's system installed.
There are many people who don't have Windows or don't want Windows. They then have to install the binary version of Mono. This introduces a security problem: you have to trust that the binary is correct, because you cannot guarantee that the published source matches the binary. With Portable.NET, if you trust your copy of gcc, and you can't find any backdoors in the code, you can trust your copy of Portable.NET.
In reality, it comes down to preference: I prefer to write compilers in C, because I believe that is the best language for writing compilers. Miguel has a different preference.
Rhys Weatherley - author of Portable.NETl
http://www.southern-storm.com.au/portable_net.htm
See above. Ximian must be cashing in quite good on consulting fees from Sun and HP while helping them migrate to GNOME. (Altough HPaq might be questionable right now :-)
Mikael
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
i've been behind gnome and ximian (helix) 100 percent for a long time now. i really like miguel a lot, but it just goes to show what people will do for money.
you wouldn't see linus torvalds making a decision like this. linus seems more concerned about principal than money.
Is there actually something good about C# that I don't know about? Not even all the pathetic MS development instuctors I've been hanging out with think it has a prayer for survival. For what it's worth: Over the entire summer at a major program development teaching company I worked for, not a single request was made for C# instruction, while Java courses were being requested on a daily basis.
There is this long list of languages for the JVM. It seems like it's not too hard to adjust to the JVM - wouldn't that be preferable to creating a completely new thing, especially given that modern JVMs are pretty mature? Or are the JVMs too much adjusted to the Java programming language and don't work well (= fast) for other languages?
I don't know how much many of you know this, but bonobo's are actually a species of monkey with hyper-sexual behavior. Gives a whole new meaning to the idea of interfacing bonobo components with each other...
A deep unwavering belief is a sure sign you're missing something...
I agree that, technologically, both
In that system, I could build my OS from a custom set of components to create an OS optimized for my purposes. I could even have multiple "themes" that I had designed to accomplish certain tasks, and switch between them without a reboot. For instance, I could have my web-browse/email/irc theme (optimized to the kernel level for that type of work), or my multitrack digital audio recorder theme (again, optimized to kernel level), or my http/ftp server theme, etc, etc.
With the type of system I'm talking about, application developers could build a web-browser out of their choice of reusable components using a Themebuilder application. I can then download the theme, which defines all of the components I will need to build the application and automatically download them as well. Any components I already have, will of course not be downloaded again. Then, if I don't like something about it, I can open it up in my Themebuilder and switch out the HTML rendering engine. Boom. Mozilla using the IE engine (or whatever). And, this method should be applicable down to the kernel level. Don't like this kernel, switch it out for that other one.
Of course, all of this would have tremendous overhead, decreasing performance. But why not design the system in such a way that the Themebuilder can compile an application into a static image that is efficiently optimized?
And, to the point of free software. Build it in as a part of the system (even if an optional one). Create the component packager in such a way that, given the proper command, it includes a full compressed copy of the original source code inside the binary distribution of the component along with a copy of the GPL
I guess what I'm saying is that, we seem to be at a crossroads in operating system design. Do we want to keep building crap on top of crap just to make the original crap capable of doing a half-assed job of what it should? Or do we want to put our heads together, think about everything that we and others have learned, think about what we can imagine as the operating system of the future, and make it happen?
Just my two cents. Maybe I'm crazy. And, maybe I'm the one who missed the point. But, I'd love to hear others' ideas of their ideal operating system of the future.
thanks.
I agree totally with what you're saying. I have seen one cognitively unsound design after another being pumped out of Ximian. Some of the stuff I've seen in the Ximian installers (and one nasty beast called metatheme) are things that no HCI professional worth his salt would implement. Miguel either is uninterested in good UI design or has no idea as to what it is. He's interested in doing what microsoft does: creating desktop applications that are a programmer's dream and an end-user's nightmare. Not that I'm singling Miguel out for being like this, because virtually all people working on the GNOME environment have this programmer-centric tunnel vision that has lead them to hang themselves with their own rope.
IMHO, the only way the linux user experience will be improved is if people from the mac community who are disenchanted with the direction that Apple has taken and marketshare limitations of the PowerPC architecture create a new desktop environment that "just happens to use the linux kernel" (as opposed to a desktop environment that "brings linux to the desktop") and puts the greatest emphasis on how people use technology, not the technology itself.
bonobo's are actually a species of monkey with hyper-sexual behavior.
Ape.
Your comment violated the postersubj compression filter. Comment aborted.
(more crap to get mast the l***ness filter)
(yet more crap)
(this is my fourth try now)
god DAMN you people!
grrr...
(Use the Preview Button! Check those URLs! Don't forget the http://!)
I have a positive modifier on Troll. When I mod someone Troll their karma should go UP!
Cos their boring(!)
http://usability.gnome.org and usability@gnome.org are the primary mailing lists for the GNOME usability project...
-Seth
I have used both, and you are half right.
Gtk-- is by far the most elegant. It actually uses C++ as it is intended to be used, giving a statically typesafe interface unlike Qt, and not depending on ugly special purpose preprocessor hacks.
However, Qt is way more comfortable. Stable well documented API's beats any amount of elegance, and the ugly hacks are easy to use. The lack of static typesafety is something most programmers are used to deal with.
I switched from Gtk-- to Qt and haven't regretted it, it gets the work done, but sometime the academician in me miss the superior elegance of Gtk--.
I read the article and am very excited about "componentizing" Unix...so has work been dropped on this front or is it still ongoing? I find this approach, and HURD's, very elegant and better in the long run. Unix is way to complex as it is will hundreds of libraries, independent executables, and configuration files strewn all over. We need to move to a higher level of abstraction, a component model. It looks like Ximian is going even further and embracing .NET, although I doubt that this will ever be useful at the system level. A "native" RPC mechanism like CORBA is probably required (um, we can't exactly be sending gigantic SOAP requests around to read a block from a device). So, is there any Bonobo work being done outside Gnome, at the system level?
It's 10 PM. Do you know if you're un-American?
Micros~1 ripped Anders Heilsberg, C# chief architect, from Borland, as well as several Borland's Senior Engineers.
Anders wrote Turbo Pascal in 1982, and was chief architect of Delphi 1.0 and 2.0
Ander Heilsberg received the 2001 Dr. Dobb's Excellence in Programming Award.
Actually, it is a Chimpanzee not a monkey, and is more similiar to humans than the common chimp. (over 98% identical) Also, it is not new, it was discovered in the 1920s.