Slashdot Mirror

Thanks to Dare Obasanjo for conducting this interview with [Miguel De Icaza], and sending it on to me. I've posted the interview below here - interesting answers, and very thorough. Well done, Dare.

Interview With Miguel de Icaza Bringing a component architecture to the UNIX platform

Summary
In this interview, Miguel de Icaza, the founder of GNOME and Ximian, talks about UNIX components, Bonobo, Mono and .NET.

By Dare (Carnage4Life) Obasanjo

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.

and you point out that Mono is merely an implementation of of the .NET development platform. Is there any plan by Ximian to implement other parts of the .NET strategy?

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.

We have also been providing professional services and support for people integrating free software based solutions.

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 ;-)

We've run several stories about Eazel, and recently posted word on its recent financial troubles and likely shutdown. Gramps writes "Eazel is indeed shutting down but the good news is that Nautilus development will continue. It's all in Bart Decrem's email to the gnome-hackers mailing list. It's been a great ride. Thanks, folks." (Read more.)

1010011010 pointed out this follow-up email from Darin Adler about the future of various projects maintained by former Eazel employees, including Nautilus, gnome-vfs, and various libraries, as well as bugtracking and other necessities.

Shutting down is never a happy event, but it's gratifying to see email from Andy Hertzfeld (also on the gnome-hackers list) in which he says: "I just want to reaffirm my personal commitment to the continuing development of Nautilus, the GNOME platform and free software in general. I plan to keep working hard to make free software easier to use and I'm still optimistic that our work can make a big difference to millions of users."

rexlam indicates this story from cnet on the shutdown as well. Best of luck to everyone at Eazel.

Revista do Linux writes "The final (1.0) version of Nautilus was released this morning. Binaries are available for RedHat 6.x and 7.x, everyone else should try the source code. This version includes a "preview" of the Eazel Services, which includes, among other things, a virtual disk. Grab your copy at the Eazel homepage." The download page has RPMs for RH 6.1/2, and 7. They've also got source that you can download as well If you want to check it out before downloading the demo page is pretty cool - but it looks like the server might be a wee bit overtaxed.

Revista do Linux writes "The final (1.0) version of Nautilus was released this morning. Binaries are available for RedHat 6.x and 7.x, everyone else should try the source code. This version includes a "preview" of the Eazel Services, which includes, among other things, a virtual disk. Grab your copy at the Eazel homepage." The download page has RPMs for RH 6.1/2, and 7. They've also got source that you can download as well If you want to check it out before downloading the demo page is pretty cool - but it looks like the server might be a wee bit overtaxed.

Revista do Linux writes "The final (1.0) version of Nautilus was released this morning. Binaries are available for RedHat 6.x and 7.x, everyone else should try the source code. This version includes a "preview" of the Eazel Services, which includes, among other things, a virtual disk. Grab your copy at the Eazel homepage." The download page has RPMs for RH 6.1/2, and 7. They've also got source that you can download as well If you want to check it out before downloading the demo page is pretty cool - but it looks like the server might be a wee bit overtaxed.

Maciej Stachowiak writes: "The GNOME 1.4 Release Team is proud to announce GNOME 1.4 Beta 2 "Hit Me Baby, One More Time". This is only a beta and there may be problems with compiling and running. However, if you are adventurous and would like to help with testing, get it from your favorite GNOME mirror site in /pub/gnome/stable/betas/gnome-1.4beta2. We would also like to announce the GNOME Fifth Toe 1.4 Beta 2 release, a collection of additional packages that are not part of the core desktop but designed to work well with GNOME. This should also be available on gnome mirrors in /pub/gnome/stable/betas/gnome-fifth-toe-1.4beta2. Bug reports for most packages should go in one of the following, depending on the module: GNOME Bugzilla, Eazel Bugzilla or Ximian Bugzilla."

Maciej Stachowiak writes: "The GNOME 1.4 Release Team is proud to announce GNOME 1.4 Beta 2 "Hit Me Baby, One More Time". This is only a beta and there may be problems with compiling and running. However, if you are adventurous and would like to help with testing, get it from your favorite GNOME mirror site in /pub/gnome/stable/betas/gnome-1.4beta2. We would also like to announce the GNOME Fifth Toe 1.4 Beta 2 release, a collection of additional packages that are not part of the core desktop but designed to work well with GNOME. This should also be available on gnome mirrors in /pub/gnome/stable/betas/gnome-fifth-toe-1.4beta2. Bug reports for most packages should go in one of the following, depending on the module: GNOME Bugzilla, Eazel Bugzilla or Ximian Bugzilla."

The folks at GNOME have released GNOME 1.4 beta 1, code name "oops, we did it again". You can find the packages at your favorite mirror. If you're testing, then please fill the bug reports in the "right place" (either Eazel's bugzilla or Ximian Bugzilla). Good work, guys.

Dan93 writes: "Here is an article on what is planned for GNOME 2.0. Pretty interesting stuff such as GNOME VFS, and the cleanup work that is supposed to fix every known architectural problem in GNOME." Also, I heard at LWCE as well from the Eazel folks that by this point in the evolution (ha ha) of GNOME, the nearly-ready-for-prime-time Eazel desktop will be included as well.

As the title says - KDE 2.1 Beta 2, and Nautilus Preview Release 3 are out. Both are in the last beta stages. So, if you like KDE or you like GNOME, then go ahead - download the source or binaries, install, test, torch it - and give bug reports. KDE announcment is here which includes LOTS of improvments, while on the Eazel side, there is a nice demo mode which you can test it here or download it here. Enjoy.

As the title says - KDE 2.1 Beta 2, and Nautilus Preview Release 3 are out. Both are in the last beta stages. So, if you like KDE or you like GNOME, then go ahead - download the source or binaries, install, test, torch it - and give bug reports. KDE announcment is here which includes LOTS of improvments, while on the Eazel side, there is a nice demo mode which you can test it here or download it here. Enjoy.

miester writes: "Sun has recently announced that it will take advantage of Eazel's Nautilus software. The article also mentions that Dell has invested in Eazel and will be shipping all Dell Linux workstations with Nautilus as well." The Nautilus previews have been slick and pretty -- you can tell that the Mac folks involved haven't lost their touch. And more hardware vendors installing a nice Open Source file manager can only be good for users.

miester writes: "Sun has recently announced that it will take advantage of Eazel's Nautilus software. The article also mentions that Dell has invested in Eazel and will be shipping all Dell Linux workstations with Nautilus as well." The Nautilus previews have been slick and pretty -- you can tell that the Mac folks involved haven't lost their touch. And more hardware vendors installing a nice Open Source file manager can only be good for users.

bratislav writes: "Eazel just released the 2nd Preview Release for the upcoming GNOME filemanager, browser and general-nice-app Nautilus. This new release comes with additional features, improved usability and a first look at Eazel Services. " The integrated network file system stuff is interesting.

bratislav writes: "Eazel just released the 2nd Preview Release for the upcoming GNOME filemanager, browser and general-nice-app Nautilus. This new release comes with additional features, improved usability and a first look at Eazel Services. " The integrated network file system stuff is interesting.

With a planned move to San Francisco next summer, last week saw San Jose's last Linux World Expo, at least for now. The future as always is stubbornly uncertain, but it's impressive that the serendipitous combination of Free tools (from GNU) and a Free kernel (from Linus) has inspired enough interest and prosperity to excite a larger group of people each year. If you've not had the chance to attend one of these expositions, we hope this article will give you a flavor of what it's like. Note: Here are a few pictures from the floor (Day 1 & Day 2) contributed by Sensei^); do you have any cool shots to link to in comments?

First, the prelude: If you've worked on the pre-show aspects of anything from a high-school play to a LAN party, you know all those booths, displays, people and computers don't materialize by themselves. For several days before the show floor opened on Tuesday, forklift crews zipped cargos of wooden, fiberglass, plastic, aluminum and steel cases from moving trucks to exhibit spaces. These contained banners, snap-together modules, computers, lighted signs -- and Yes, more gratis logo-imprinted toys than you can wave a TuxTops LED light at.

Spiderwebs of CAT-5 and electric cord (run beneath the show floor) sprouted from the centerpoints of many booths, with strands for each computer to be connected to the Net during the show. Rolls of padding and carpet came next, then the slow assembly of display booths. These ranged from no-nonsense fabric partitions that housed companies like TuxTops and Sendmail (and legions of volunteers from PerlMonks, the Simple End User Linux project, Flightgear, and many others), to elaborate constructions with motorized signs, projected lasers and huge illuminated logos. Note: Slashdot (the site) was put together last week mostly from the comfy chairs of the PerlMonks booth.

The "C" (as in conference) part of LWCE got started on Monday, and for the days that followed, attendees got instruction -- on everything from Linux security to evangelizing Free software to their bosses-- in half-day doses. Meanwhile, the setup work continued into the wee hours, as exhibitors raced the clock to make sure that at least their signs, if not their networks, were up for the next day. And at the OSDN booth (home of the red-carpeted Slashdot stage and beanbags), prep work included stacking thousands of boxed distributions of Debian, and attempted to pawn a few copies off on every passer by.

Tuesday morning, at a shade before 10:00, visitors willing to miss Michael Dell's keynote began to stream into the halls, on a quest to find new distros, old friends, and swag. It's amazing what companies will give away in order to snag a little nook in your brain. Besides the usual trinkets (keychains, T-shirts, stickers) and the distributions that a Linux show would be empty without, booth visitors were handed everything from knives (Sendmail) to cute monkeys (Helixcode) to embarrassing pictures of themselves (BSDi), as well as too many toys with embedded LEDs to bother counting. Rather than a full swag accounting (which would only annoy those unable to attend), let me just say that you won't hurt for toys when the chance presents itself. (CT:I just wanted to note that VA gave away 2300 pounds of shrink-wrapped boxed Debian. Like 5000 copies. It was beautiful)

The things on display around the LWCE floor were more interesting than the toys, though. (And unlike a museum, most were available for hands-on demonstration, not hidden behind glass.) Indrema showed a prototype player (not in the sleek black box you see on their Web site, but still sporting that cool blue LED) hooked up to a HDTV display, playing a very fast game of Quake. (CT:Actually it was an HDTV demo, they promised the real deal will be less vaporous before I have children) In the Intel booth were server clusters populated with quad Itanium processors, demonstrating failover when one system was rudely but intentionally shut down. The amazing-like-emacs-is-amazing Flightgear project showed a really nice looking demo which is enough incentive by itself to invest in a better video card for my system so I can play with it.

Both Helixcode and Eazel made their first LWCE appearance this time around, exciting for those filling their anti-FUD cannon for the perpetual "Linux is tough to use" argument. The Eazel folks showing off Nautilus seemed to be all but cackling as they showed off the smoothness of the zooming information available for documents and the cool music-integration abilities it contains. It would have been cool if they'd had some sample CDs, but they promise a developers' release soon. (CT:They also promised .deb's, but I'll believe it when I see it. The UI was awesome, I just hope that someone hacks in something like the GUI command line in EFM)

Considering that Sun was showing off the GNOME desktop on Solaris (hinting at its inclusion in stock Solaris systems sometime very soon, too) and that the GNOME project itself was not only in one of the small booths against the wall but the subject of a big announcement -- about the advent of the GNOME Foundation -- it looks it's showing up everywhere. Happily, there seems to be no shortage of room for window managers right now: the KDE folks were also there not only in their own booth, but showing up in software demonstrations all over the floor, as SuSE, Caldera and others demonstrated the very slick KDE 2.0. (Can't we all just get along, anyhow?)

SuSE, by the way, was the only distributor I noticed showing off Linux on Apple hardware, and their current distro was sweet and fast on a G4. Beyond the curious lack of Apples, and the obvious ubiquity of x86 machines, there were machines based on everything from microcontrollers to StrongArm, MIPS, Alpha, Itanium ... even the IBM S/390s which have gotten attention for the ridiculous number of concurrent Linux systems they can support.

For all the cool hardware and cusp-of-reality, bleeding-edge distros, it's interesting that the announcement which seemed to generate the most buzz of the entire show was the long-awaited release of Debian's Potato. Considering the reputation that Debian has for intelligent upgrading, stability, and diligence in guarding the license of the software which makes it up, it's not as surprising as it might otherwise be that Debian's new release made people sit up a bit more than the newest offerings from the large commercial distros.

(CT: Also extremely impressive was the Pocket Linux booth, where they actually had iPaq's running Linux. The first dude that demoed the box to me was very nice, but what I really wanted to see was X11 running on it ... oddly enough, I encountered one of his cohorts in the bar later that night who showed it to me: X, xeyes, xterm, and twm running on an iPaq. When they get the wireless action going on these things I'm totally there ... I'll just need to hack minimalist interfaces onto pronto and my MP3 player software and use the thing as a portable X terminal on the local 802.11 wireless lan. Yum.)

Oh, and there were people on the floor as well -- close to 20,000, all told. I met some folks I've known previously only through IRC, and quite a few I might never have otherwise encountered.

It's interesting to see in the space of a few hours many of the smart people who you may experience vicariously through writings, speeches, code, art or IRC chatter -- and it also belies the idea that software celebrities of the Free software world are becoming celebrities of the traditional variety, since everyone from ESR to Jon "maddog" Hall (and Linus himself) are willing to talk to anyone who catches up with them long enough to say hello. The atmosphere (especially outside the mondo corporate-castle booths) is mellow and accomodating, and suprisingly so even within most of those castles. There were undoubtably personality conflicts at work, but it seems like most people have the good grace to deal nicely with each other for these few days at least.

At the close of each day, people shuffle out to drop laptops, T-shirts and bags of stuff at their hotels, then thousands of them show up to parties sponsored by companies from AMD to Red hat to VA, which are full-blown events in themselves. Mandrake's party, for instance, had go-go dancers in cages, which may be the most bacchanal thing I have ever witnessed. Ironically, though, many coders couldn't attend even events sponsored by their own companies, or thrown in the honor of their projects, because of strict carding policies. Wouldn't a chem-free party or two be a thoughtful way to include people?

(CT: This has been a consistent problem for several years. Although I know at "Someones" party (no names *grin*) they weren't carding, and I recieved many a happy note from fellow attendees proclaiming that they were able to get in. The parties themselves weren't bad: the OSDN/Potato release party was fun, with San & Zak spinning the tunes (next time we'll force CowboyNeal to scratch for us under threat of death). They had 2 buildings: one was a pool hall, where we tormented The Pope for nearly an hour, carefully distracting him, and then returning his balls to the table. He never noticed. We also met up with Nitrozac from After Y2k, and I snuck accross the street to the Eazel party for a bit, and got to meet Dave "You might remember me from cheat codes in some first person shooter" Taylor.) Attendeees mostly filed out for flights or drives home Thursday and Friday, but some are still in San Jose for the Intel Developers Conference, or otherwise enjoying the Northern California weather. It's a strange familiarity that many of them will feel when the next big conference rolls around, to see many of the same fellow attendees or workers -- of course, by the time the next big conference happens, perhaps we'll all be too excited by the release of 2.4 to notice.

menthos writes: "Eazel released the first preview release of Nautilus, the new GNOME file manager in development, at the LinuxWorld Expo. You can Download Preview Release 1."

menthos writes: "Eazel released the first preview release of Nautilus, the new GNOME file manager in development, at the LinuxWorld Expo. You can Download Preview Release 1."

max cohen writes "Eazel has posted some new screenshots of Nautilus (as of August 2nd) and they're much improved from eariler versions. I can't wait to get my hands on the Nautilus preview release and give it a test drive!" They've come a long way since the last batch of shots: especially interesting is the way it handles albums of MP3s, and its integration with mozilla.

max cohen writes "Eazel has posted some new screenshots of Nautilus (as of August 2nd) and they're much improved from eariler versions. I can't wait to get my hands on the Nautilus preview release and give it a test drive!" They've come a long way since the last batch of shots: especially interesting is the way it handles albums of MP3s, and its integration with mozilla.

Soko writes: "Anybody want to see some screen shots of Nautilus, from Eazel? Cool." Check out the rest of the directory images -- the evolution of what's going on inside there is pretty cool to see.

In his responses to the Slashdot interview, Miguel shares the deadly truth about GNOME, the shocking story of the future of Bonobo and CORBA, and the titillating tale of adventure and intrigue that lies deep within the bowels of popular Free Software development projects. Okay, so it's not all that shocking, but Miguel has brought us some really great news and answers from his neck of the open source woods.

Printing and GNOME
by datazone

Printing and printer support is a major issue with the Linux desktop. How do you plan to address this in GNOME in the future? Or do you believe that it should be addressed in a lower level than at the desktop?

Miguel:

This is a very interesting question.

We have been working on the GNOME printing architecture, which so far consists of an imaging model, and some user interface elements for applications to use.

The GNOME printing architecture is interesting as it provides:

1. A postscript imaging model for programmers to use.

2. On top of the Postscript imaging model we added alpha transparency (and as an added bonus we also added anti-aliasing).

3. Native drivers (no need to generate Postscript first and manually process with Ghostscript a file for your printer, which has many problems from the user perspective, from the efficiency point of view, and from the quality point of views).

Currently the GNOME printing architecture includes a Postscript driver, an on-screen preview driver, a generic RGB driver (that can be used to generate images), a meta-file driver, and a black-and-white HP PCL driver (which needs work, and yes, we could use some help making more native drivers ;-).

Now, GNOME Print alone is not enough, it needs to be tied with the spooling system as well and have access to the features of a particular printer. So the GNOME printing system needs to integrate with these systems. We have been talking to the various people working on these projects, and GNOME print will integrate with a variety of spooling systems.

For example, GNOME print and the VA, and TurboLinux efforts for a printing architecture are complementary, so there is a good chance it will be our first spooling back-end.

So just to re-iterate, the printing problem can be divided in:

1. Application API for rendering data.

2. A spooling system: a way to query the printer queue, control the printer queue.

3. A printer capability system: which would let applications and users use the various features available in their printer.

4. User interface elements for enabling programmers to make the most out of the above features.

GNOME print is only attacking (1) and (4), and we are working with other people to provide a complete solution to the printing problems in Free systems.

Okay, alright....answer this HONESTLY
by SgtPepper

Just how well do you and the KDE guys REALLY get along....don't you GNOME people ever just want to get together all the Nerf gear you can and stage an all out war?

Seriously though, how much communication really does go on between the two camps? I would imagine at least some must if you and the KDE camp are to maintain interoperatability.

Miguel:

We talk in various mailing lists about these issues. For example, the wm-spec-list is very close to releasing a joint specification for window manager features that both GNOME and KDE can use.

On the other hand, I do personally like a lot some of the KDE developers like Kalle, Torben and Matthias. I have had the chance of meeting Kalle more times than any other of the KDE developer.

Also, recently an effort has been started to share widgets across Gtk+ and Qt. Both projects will announce the details when there is a more concrete plan about it.

But all in all, it is important that we agree on file formats for documents, which is what end users are exposed to.

User interface importance?
by zhobson

First off, I'd like to say that I love GNOME, it's been my primary environment since 1.0 was released.

Now then, how do you think GNOME will evolve in terms of usability? GNOME has certainly conquered the stability mountain (anyone who argues otherwise probably isn't using release versions), which is almost certainly a side-effect of the Free Software development model. However, while Free Software is generally powerful and easy to use for experienced users, it's not generally the kind of thing a novice can operate easily.

I remember hearing about a "usability group" or something like that for GNOME, to concentrate on interface issues. This is a great idea, but I haven't heard much about this group since then. Are modern user-interface issues a concern for GNOME,or is it mainly trying to match the interface conventions of other popular GUIs (like NeXT, MacOS and Windows)?

We started the GNOME User Interface improvements projects last year.

During the initial development of GNOME, we did not have a lot of time to discuss and incorporate ideas that flooded constantly. But later we realized that many genuinely good ideas were dropped because we did not have time to implement them at the pace they were coming (the standard reply in the early days of GNOME was `Want something changed? send a patch'. And we have basically changed this)

So the User Interface Improvements project was started to address this problem. It is coordinated by Jim Cape, and he works with other users and programmers to bring these usability changes into GNOME.

The UI team has been focusing on usability of the GNOME desktop by taking the input from the community. They are assembling and cataloging the suggestions for improving GNOME as well as providing mock-ups of how various GNOME tools could be improved.

As a result, I believe we are a lot more receptive to people's input than we were before, and this is something we want to keep enhancing as time passes.

Now, it is very hard to come up with good user interfaces. So there is definitely an element of copying existing interfaces. User interfaces and paradigms that are known to work and bring them to free software. But this is not stopping anyone from contributing new ideas and new user interface elements that can be incorporated into the system.

Contrast this with the people who want to reinvent computing as we know it (you can identify them at parties because they will start their senteces with `What is computing anyways?'). The GNOME project is not in this realm, but we would gladly take all the good ideas that both research and production communities produce and we will incorporate them. What we have not tried to do is become a user interface research project.

That being said, you have to keep in mind that it is very hard to start innovating user interfaces if you have zero lines of code. With the current GNOME system as it stands you can start from a working application that has already a few thousand lines, and work towards innovation.

It is like trying to design a car trying to ignore all the knowledge on mechanism, thermodynamic and engineering that has been accumulated over the years. It is a simpler task to innovate if you use the existing knowledge. As Isaac Newton said, you can view a lot further away because you are standing on the shoulders of giants.

For example, it is easier to innovate user interfaces for a spreadsheet once you have a fully working product (so that you can just remove the part you think can be removed, and plug your new code there), rather than trying to innovate the user interface and having to build all the infrastructure.

There are various companies that are working together with GNOME now, and they are bringing their expertise from their previous experience, which is very good for improving the general usability of GNOME (Eazel).

Andy is someone I really like for his vision on how computers should work, and his special attention to the end user.

Talking to him has changed a lot my view on what GNOME should be. In the beginning I thought "We need a desktop for free systems", now I think "We need the perfect user interface for end users to use on a free system". Achieving the best user/computer interface is a goal that many of us share.

But this is just a first step, we are of course working and integrating the ideas that will define the desktop computer of the future.

C++/Java/CORBA/Components/Frameworks (Score: 5, Interesting) by PureFiction

Do you see object oriented design and implementation playing any part in GNOME's future?

The architecture of GTK/GNOME is technically somewhat object oriented, however, without all of the benifits of an object-oriented language (at least the parts written in C).

It would seem to me that as the scope and size of the GNOME project increases, it would be increasingly advantageous to use C++ or Java with much more CORBA support and more structured design (UML design models?) for reference by the developers. Standard components and frameworks would also fit well into this type of extension.

Do you see GNOME increasing in complexity and size to the point where these types of development techniques would be required?

Miguel:

Yes, there is a lot of object oriented design going on in GNOME.

On using UML for modeling various components in GNOME:

Recently there has been a boom in creating UML diagrams for various GNOME components (particularly for new applications) as our Diagram application has become mature (http://www.gnome.org/gnome-office/dia.shtml).

Various GNOME module authors have different preferences on what languages they want to use, and it will be up to each of them to choose the language they want to use for their own modules. I myself want to use Python more and want to use Java more in my own developments.

Although, just because some of our code is written in C, does not mean you are left out of paradise.

Now, a big push right now within the GNOME effort is to use Bonobo components, which are basically reusable components built on top of CORBA, with a set of standard interfaces for component programming.

Outlook Interoperability with Evolution
by Cybersonic

My question actually has to do with Evolution, the upcoming Outlook killer.. :)

Will GNOME serve (Evolution) information to MAPI clients? Would be a nice way to get rid of those Exchange servers sitting in most companies' server rooms...

Miguel:

Evolution is probably the most exciting application that is being developed in the GNOME world right now.

First, Evolution is based entirely on Bonobo components. It is one of GNOME's proving grounds for component-based programming. We have spent over a year developing the Bonobo component model, and in Evolution it's beginning to pay off in a big way. Each component in Evolution (mail, calendar, tasks, notes, contacts) is a Bonobo component, fully CORBA accessible (to enable automation and scripting of applications, and yes, it is secure. We do not feed any unsecured data into components, in case you were wondering).

The component-based pluggable architecture means that we can make Evolution into a universal communicator. So, yes, we have every intention of integrating with Exchange environments. Picture an office populated by Outlook clients and an Exchange server or a Lotus Notes server; we can infiltrate that place from the bottom up by making Evolution talk to those Exchanges or Notes servers. Clients can upgrade to Evolution one by one, without the requirement of a top-down organizational decision to dump Microsoft.

This is how GNU/Linux won. This is how we will win.

But the beauty of Evolution's architecture goes much further. It is the first communications tool designed for modern users like the free software community. The free software community stays in touch thanks to e-mail and as we grow, we need more powerful and efficient tools to handle our communication loads.

For example, I receive about 2500 mails a day. Even with procmail and Gnus, filters, scoring and lots of complex scripts, I still spend about four hours a day on e-mail related tasks. And it is pretty hard to find information on the gigabyte of mail that I have archived over the last few years. Traditional mail tools are not keeping up with the demands of modern Internet citizens like myself.

We believe that the mail loads that most free software developers are handling these days are going to become the norm for normal users in the future as the Internet becomes more ubiquitous and e-mail becomes the tool of choice for communication.

Evolution scales to mammoth mail loads perfectly, though. The hackers in the Evolution team designed the entire system to scale: we avoid copying data wherever possible, we never load the whole message into memory even over IMAP, and we used asynchronous interfaces across the board.

Now, the real beauty is that we index all of the mail as we incorporate it into our mailboxes. Dan Winship wrote this beautiful indexing library called libibex which we use for indexing and Michael Zucchi is working together with him in our vFoldering setup. So you can treat all of your archived mail as a giant database, and perform queries on it (think "Altavista for your mail"). So you will finally be able to find information in your mailbox, and you will finally be able to keep track of things.

And then you can save that query as a "virtual folder" (vFolder). So in fact your folders are actually the results of searches on your mail.

Also every element in evolution can be annotated and annotations can be cross referenced, so you can keep track of your contacts, your tasks and your information flow more easily.

And that's just part of the whole system. We are working on fully networked calendaring and contact management, too. So you can schedule appointments with people over the Internet, and have servers storing address-books. We are going to have a gnome.org Evolution server with all of the address-book entries for all the GNOME hackers.

The system is still under development, of course, but it's the most fun thing to hack on, and we are applying a lot of the tricks we have learned over the past years and enjoying the result.

Evolution is not only limited to handling the standard Personal Information Management features, but through Bonobo components you can plug any sort of communication system and have it integrated with the rest of the system. So hopefully, your irc conversations will also be fully indexed, as well as any other personal messaging system that ships with Bonobo support.

Think "deep integration" and think "I can find that e-mail".

If you want to learn more about Evolution, I suggest you check its Web page here, and as with every other free software project, we would love to see you join the effort, and help us get this out and deployed.

WM interchange
by Wubby

The arguments over Linux Desktop adoption are well know. IMHO, I agree with the strength in diversity reasoning and WOULDN'T like to see GNOME/KDE/Other merge developement regardless of the benefits.

Despite this, do you think WM developers would work towards a set of interface or API standards (to facilitate interoperability) or would this place to great a restriction on innovation and the developement process?

Miguel:

Definitely. The WM spec list has been working for a few months on getting an inter-operable window manager specification for developers to use (and both KDE and GNOME as well as the various active window manager maintainers are contributing to this effort).

How important is COM-like architecture?
by Pike

It seems that the GNOME effort is throwing an awful lot of resources at a component-ized architecture (Bonobo) which aims to do for *nix what COM and ActiveX/OLE did for Windows. And yet it just doesn't seem necessary. I know it's possible for me to insert an Excel spreadsheet into a Word document, but I haven't used that feature in recent memory. None of the documents I exchange with co-workers do, either. Is Bonobo really very necessary? What does bonobo bring to the Linux desktop that users are crying out for, and how is its heavy consumption of development resources justified?

Miguel:

Bonobo is a mechanism for creating reusable software components as well as enabling users to talk to the components through a standardized programatic interface (CORBA).

As I have mentioned in the past, the GNOME project has focused strongly on building a solid infrastructure for people to use, and component programming is just another part of this equation.

The core idea of software reuse and software components is that you can reuse what other programmers did and there is a very precise contract on what the component provides, and the API it exports that you can use to talk to it (Brad Cox used to talk about Software IC, and I am convinced that Software IC did not come in the shape he expected, but in the shape of components).

Also, by writing components, you can mix and match the components: it does not matter which language you used to implement your component on (currently you can use C, C++, Java and Perl to write your components, it does not matter, as all of them will be able to talk to the others)

For example, we wanted to extend the drawing capabilities of Gnumeric, so instead of writing yet-another-half-cooked-vector-drawing-program on top of Gnumeric, we are working with the Dia guys (and in the future with the Sodipodi hackers) to use their editing engine inside Gnumeric.

This is thanks to the fact that we can have arbitrarily-shaped compound document embedding in GNOME, so when you insert a vector-based drawing into your spreadsheet, this drawing is not going to be even handled by the spreadsheet, it is handled by an actual full-blown application that does nothing but specialize on this specific task.

Reusable software components are not limited to visual components, nor embedding information. You can even have completely GUI-less components.

But your point is a valid point, we believe that it took proprietary companies 20 years to produce a few productivity applications, and they are not that fully featured, and they are not that impressive anyways. Specially, as the result is buggy software that slowly improves.

With the current proprietary tools, the whole world is waiting and depending on a few small teams around the world to provide them with their software solutions.

We are building applications that will go beyond the existing offerings: both in usability, simplicity and power. And to do this, we need to avoid the approach of building monolithic applications but rather have small applications cooperating with each other. This is pretty much like the original Unix spirit: write simple tools that do one thing correctly, and have this tool inter-operate with other tools. We have just taken the small tools to the next level: communication can be N-way and the information you exchange is rich and attribute tagged, rather than being free-text (this is the difference between HTML and XML).

You can learn more about the details of Bonobo in my Bonobo technical description.

Also, you have to keep in mind that component programming really goes hand in hand with the way Free Software is developed. With components you can isolate tasks into a module that can be easily understood and digested by a small team of programmers, instead of forcing your programmers to learn how an entire system works.

Given that free software contributors might not be able to commit to work on a project for a long time nor for a given number of hours a week (because of school, personal obligations, or other activities) it makes sense to isolate the tasks. You can then restructure components without affecting the other applications, or you can rewrite them, or you can upgrade them or you can change its behavior to work in different conditions (scalable service or doing work to simplify the code for mobile purposes).

Bonobo/CORBA fulfills the objective of having reusable software that can be shared across applications. Components go one step beyond the traditional object oriented mechanism for software reuse, as components can be implemented in any language, programmers do not depend on using a specific language or a specific application framework that is tied to a language to use components, they can choose the language and programming environment that better reflects their project needs.

Given the nature of Bonobo/CORBA of being language independent, you get the benefits that object oriented programming was designed to solve in a cross-language form.

So GNOME is developing and deploying the framework to create a component infrastructure for free systems to use, an infrastructure in which we will build the future applications. Remember, we are not in the business of selling the same application every two years, but in the business of solving the problem.

Bonobo is still a work in process project, and although various applications already use it (Gnumeric, Evolution, Glade, Nautilus, libGlade, ggv, eog, and gpdf) we are not yet ready to freeze its API.

GNOME has made a lot of advancements on the "traditional" interface front (I mean all of Xerox-derived WIMP land), both in the "easy (or efficient) to use" and "easy to learn" departments. I find case after case, subtle and not-so-subtle, where GNOME is markedly better with its main competition, Windows and Mac. My favorite example of this is Evolution -- can't wait to try it. Evolution may finally tear me away from textmode mail clients....mmmm, query-able databases :)

My question is, where do you see GNOME as fitting in to more groundbreaking user interface research? Not that anyone expects the GNOME team to start pondering lexicons for 3D interfaces (or are you contemplating such things!?!). But there's lots of crazy stuff that still goes on in traditional, 2D interface design. A lot of recent research has been in terms of PDA interface design. Do you see GNOME, with its obvious advantages of modularity and scalability, as having a role to play in that arena?

And what about fundamental changes to the way we use our desktops? I for one haven't really changed at all since the days when I used fvwm1. Sure, things have gotten much prettier, and more applet-filled :) but I'm doing fundamentally the same things, and none of the various ways of configuring things (GNOME + sawmill = many ways of configuring things) have so far seemed particularly radical or any more efficient.

How 'bout the rest of the folks? Anyone done anything truly funky with sawmill? A Turing-complete wm is a fun place to start ....

Miguel:

I definitely see GNOME playing an important role in innovative user interfaces. As I mentioned before, the GNOME foundation, the GNOME applications and the GNOME tools help users get closer to their final goal. For example, it is a lot easier to write an accounting system if you have the proper database libraries and user interface libraries than rolling your own.

So GNOME is this foundation you can start building from, and it is a foundation you can improve (given its open source/free software nature).

There are now people working on different dimensions with GNOME: from new and innovative user interfaces, to productivity applications, to embedding GNOME into small devices, to building component-based software and more.

I understand that for a seasoned Unix user GNOME might not bring a new paradigm for their way they work, but you have to think differently. You have to think how many people have or will be able to run free software on their desktops because it is easier to use.

We do plan on continuing improving GNOME, and catering to the needs of the people who are just starting to use computers and just starting to use GNU/Linux.

When did it take off?
by Uruk

When was it exactly that you knew (or had the feeling) that GNOME was a project that was going somewhere? Free software projects start with no guarantee of popularity, and for every GNOME, there's 1000 totally unknown applications.

Was there a particular application or library or component of GNOME after which you knew GNOME was going to be successful or in general "something special"? What did the GNOME project do that prevented it from sinking into obscurity like so many other free software projects?

Miguel:

I do not know if I ever thought of it that way. You have to understand that when we started the project, what we had in our minds was defending the freedom of software, and not allowing the future of GNU/Linux to be jeopardized by having its user interface be proprietary. Back when the project started I was working happily with my friend Ralf Baechle on the Linux/MIPS port for SGIs.

There are many other reasons that motivated the various members of the GNOME team to work on it: from freedom concerns, to personal joy, to friendship building, to helping other fellow humans to creating the best possible software out there, to learn how to do things and solve problems. And I bet there are many other reasons to do so.

Avoiding sinking I guess was a matter of a lot of hard work from all the involved parties, I do not think I have taken a lot of breaks from working on free software since the GNOME project started. It has been for me a non-stop effort since we began with perhaps three weeks of vacations total.

Also the Red Hat support back in the original days of the project was also very motivating, as they had the same concerns we had regarding the future of a fully-free system. They assembled a team that to this very day is working on GNOME and making the GNOME infrastructure more reliable, robust and usable: from coordinating GNOME documentation to maintaining the core libraries, to creating the new ultra kick-ass Pango architecture.

The GNOME team is large, and I can not speak for all of them, but I do love each and every contributor to GNOME, and I owe beers to them all. I actually, owe them more, but I don't want to go broke.

I love GNOME, but one thing that I really miss is good integration of sound. Let me be clear... I'm not just talking about blips and burps to coincide with user clicks on the standard window widgets... I want it to be easy for application developer to add in audio aspects to their applications UI presentation.

For example -- if I was developing a word processor, I'd want it to be straightforward for me the developer to add a pleasing click with each word that is highlighted.

I understand there are some technical problems to be solved here, but there are more than enough sharp people working on GNOME to make good sound UI happen -- if it is made a priority. I admit that I'm pretty ignorant as to how GNOME is approaching sound. Could you fill me in (and hopefully reassure me)?

Miguel:

I am not very up to date on the discussions on the sound architecture for GNOME. I know that currently we use ESound, and we provide an API for playing sounds to applications, but as your post suggests, attacking the problem correctly and coming up with a design that addresses the various requirements and needs from various sources is not a trivial problem.

And this is part of the discussions we have had these last few days on the GNOME-devel mailing list. If you have ideas that you want to contribute to, I encourage you to join the list, and help with ideas, code, or time the people who are working on this.

Mexico and OSS
by Vox

Hola, Miguel

As a fellow Mexican I want to know...what do you think is the impact of OSS in our country? I know all about the project of putting a whole bunch of Linux boxes in schools, so that's nice, but...what about developers? I don't really remember more than a couple of names of Mexican developers besides yours, which, in a way, also means that we don't have as much advocacy/knowledge about OSS in Mexico as we should (the MS tax kills easier here than in the U.S., for obvious reasons).

I guess as part of that question...what do you think should be done to "push" more developers into OSS here in Mexico?

Gracias por un excelente trabajo para todos nosotros.

Miguel:

I believe that Free Software will help countries with developing economies (like Mexico) to get a competitive advantage that they have lacked for so long. Most of these countries missed the industrial revolution, and for one reasons or another, they depend on external technology to keep up with the times.

Free Software helps in the fraction on depending on external technologies. For example, countries with developing economies can now avoid depending on proprietary software: they can keep the money they spent on proprietary software to themselves, and use it to either develop themselves, or they can use that money to produce free software that will solve their problems (and hopefully other countries problems).

The case of Mexico is the one I am most familiar with: Mexico does produce very little technology, depends a lot on foreign technology and pretty much our main exports are raw materials. Raw materials are extremely cheap (and in some cases it took nature a few million years to produce). For example, a barrel of petrol costs about $25 these days, and a copy of Microsoft Office and Microsoft Windows 2000 costs around $700. Which means that for each copy of Office+Windows 2000 the country is paying with 24 barrels of petrol.

Of course, it is not very easy to do a transition to free software in these countries (as it is not easy anywhere else), but the people governing the developing countries have the responsibility to their people of making the right decisions, and the right decision when it comes to software is not proprietary software.

In general, I believe that we must become software producers (and also technology and innovation producers), and not just consumers. Becoming free software users is a good first step, the next step is to become software producers.

The beauty of free software and GNOME is that part of the freedoms you receive is the freedom to learn from other people's techniques, strategies, and focus on problem solving. Something that has been unheard of in this industry (although it is a pretty common thing in science). So people have a chance to join the effort, and be part of the team of people that are producing knowledge, culture and as a result wealth.

Many smart people on the educational system realize this and that is why GNOME and free software have been very well received on the educational markets, and we are very happy to help them to provide the applications they need.

People should also know that the multi-million dollar efforts to bring computers into every classroom in Mexico and other countries should be equipped with Free Software/Open Source software. And encourage these people to become creative and become part of the creation process rather than just be users of pre-packaged solutions.

Will GNOME implement an API for installers to use? One thing that helps Windows is a common installer so that most software you put on your system is pretty easy to get on. You just click on the executable and then it installs. With GNOME's goal being to make a user-friendly system do you see this as part of that?

Miguel:

GNOME has a few applications for attacking this problem (the GIP), but the problem these days is not just being able to easily install applications, the problem is the slight, subtle and tricky fragmentation of the GNU/Linux distributions.

For example, Helix Code is shipping a pre-built GNOME for various platforms. Although we would love to just compile the code in a specific system and have it installed on the other distributions, it is not possible.

Hopefully the effort to create a standard GNU/Linux base will in the future get rid of this problem, but for now, you are right, it is a real problem and the one that might hurt more the deployment of free software.

Also Helix Code has an installer and an updater that we hope in the future will be turned into generic installer/updater programs that other people can use.

handicapped accessibility and GNOME (Score:5, Interesting) by esj at harvee

I would be interested to find out what are GNOME project's plans for handicapped accessibility. As it currently stands, GNOME is only usable by people with fully functioning eyes and hands. It would be nice to hear how GNOME will address handicapped accessibility for:

visual impairments
mobility impairments
hearing impairments

Miguel:

I know that we have added patches to a few applications to make them usable for visual impaired people and that there are a few applications for GNOME that do address this problem.

I know that Paolo has an infrastructure for visually-impaired people to use with GNOME, and that it hooks to various GNOME applications, but I have not seen this in action myself.

But we are open to extending and changing GNOME in the ways that are required for handicapped accessibility.

Print / display font unification
by elflord

Hi. As the author of the font HOWTO, one issue I've had to address is the lack of a WYSIWYG font system. It boils down to what I think of as the WYSIWYG Typography Problem -- which is this: show me some code that reliably displays a typeface on the screen, and prints text using the same typeface ( at a printer resolution, of course ).

The problem, of course, is that the printing (usually ) goes through ghostscript, while the screen fonts are handled by X11, which operates independently of ghostscript. However, given a screen ( ie X11 font ), there is no canonical way to get the corresponding outline file (pf[ab]|ttf) or the detailed metric information ( such as kerning ). This problem is quite deep in some sense, because the fact that the X client and X server run on different machines means they may not have the same typefaces available. In short, Linux's right hand does not know what it's left hand is doing when it comes to font management.

Applications such as Star Office and Applixware "solve" this problem by using a text configuration file that basically consists of a catalogue of mappings from screen fonts ( in particular, XFLDs ) and printing fonts ( including outline files, metric files and the printer font name ). While these solutions are all more or less satisfactory in their own right, there are too many of them -- we need one GUI font manager that all apps can share.

It is very unfortunate that there are several incompatible solutions to the problem, because it means that the Linux user needs to install their typefaces once for each WYSIWYG app they need. A standard would be a very good thing. Personally, I like the idea of a well documented XML configuration file that could be used by any app regardless of the GUI API used.

In conclusion, my question is this -- What are GNOMEs plans for attacking the WYSIWYG typography problem? And will the solution be GTK/GNOME specific?

Miguel:

There are many-fold, and it is a bit long to explain, but here I go.

You got all the basic problems right. And this is indeed the problem.

* The solution: the solution we have planned consists of using client-side rendering (there are a bag of tricks for making this efficient, if you are interested in these I can explain, but for the sake of the discussion, assume "efficient").

The basic idea is that we want to reuse the code from GnomePrint to load, parse and render type1 fonts. Add support on top of that for TrueType fonts and use those fonts for rendering on the screen and rendering them on the printer.

The core of the idea is: ignore the X fonts as they are useless anyways, and use the system installed Type1/TrueType fonts. And they are useless for a number of reasons: they are only available as bitmaps, not as outlines, and the font naming scheme is basically useless.

* Rendering outline-based fonts (TrueType/Type1) on the screen: Now, this posses the problem of outline fonts looking very bad at low resolutions (for example 12 pixels), and given the patents surrounding hinting in TrueType, it is not clear that we can just use these font technologies alone.

What needs to happen is that someone needs to implement the Hobby algorithm for coming up with beautiful bitmaps from the outline fonts. It is my understanding that someone from the FreeType team had been working on this

* The current approach: Gnome Print currently only pays attention to Postscript fonts, and uses those fonts. And it contains a setup for "guessing" a good match for the screen presentation, but this is far from optimal and will be replaced.

* The Pango project is attacking a load of other issues when it comes to fine typography and rendering of non-Latin1 characters.

Pango will be a standard component of the GNOME 2.0 development platform, at that point the Gnome Print will use Pango.

When I first started using Linux (about a year ago), what impressed me the most was that you weren't locked into a single, all-encompassing solution. Everything was (and is) so modular. Tools like grep, ls, cat, head, etc. and the use of pipes just seemed so refreshing to me, someone who had been using MS-DOS (including Win95) for as long as I can remember. Even in the GUI, there was the display server, the font server, the window manager...

I see desktop environments as being very contradictory to the traditional UNIX philosophy of "do one thing, but do it very well". We have the two leading desktop environments, Gnome and KDE, which are rapidly expanding to include everything under the sun. Is an office suite really part of a desktop environment? Is an email client? Terminal emulator? Web browser?

Personally, I think the answer is no. I want the freedom to choose my desktop shell, my e-mail client, my Web browser, and my office suite.

To get to the point, my question is this: do you believe that the notion of a "Complete Desktop Environment" contradicts the traditional UNIX philosophy? If so, why do you feel the need to change something that has obviously worked so well for so long?

If you would like to know, I would personally prefer that Gnome consist of the panel and shell ONLY, and then we could have something like Helix which could package the panel and shell with a nice browser (branded mozilla maybe), window manager (sawmill or e), etc. I definitely believe there is a need for an open-source office suite, but I think the development should go on outside of Gnome or KDE core.

The objective of the GNU project was to create a fully free operating system. The definition of operating system that Richard used back when he stated was something like "All the things you need to get your work done", or something like that.

Miguel:

If you want to call that GNOME, or you want to call it GNOME Office, or "The Thing" it is really a naming issue. The objective we have is to enable all users to replace a proprietary system on their desktop with our solution.

The fact that internally GNOME is composed of various modules is something that some users do not care, and seasoned users like you can easily configure, customize, replace and change.

So I do not believe there is a problem in GNOME attacking more problems than just being "a panel".

You have to keep in mind that GNOME is an umbrella project that includes the GNOME development platform, the GNOME desktop, and various GNOME-based applications.

Remember: we are doing components here, and you are free to choose the components that you want for your environment.

Best wishes, Miguel.

dfallon writes, "A GNOME development roadmap is available over on developer.gnome.org. Highlights include: a 1.2 release targeted for April, followed by another 1.X release in late summer (1.4?), which will include Nautilus, the desktop shell being worked on by Eazel, which will lead into a 2.0 release sometime in the fall. " This is, of course, subject to the mad revisions of Nat and Miguel - but it's cool to see what the future /might/ hold.

naasking writes, "A new desktop project has been started by former Apple and AOL employees. Their goal is to create a graphical environment for Linux that "your mother could use." The company doing it is called Eazel. " It also is supposed to be based on GNOME. CT: Several people noted that this shell is destined to be the GNOME 2.0 shell/file manager.