Other LWN stuff:
 Daily Updates
 Calendar
 Linux Stocks Page
 Book reviews
 Penguin Gallery

 Archives/search
 Use LWN headlines
 Advertise here
 Contact us

Recent features:
- RMS Interview
- 2001 Timeline
- O'Reilly Open Source Conference
- OLS 2001
- Gaël Duval
- Kernel Summit
- Singapore Linux Conference
- djbdns

Here is the permanent site for this page.

See also: last week's LWN.

Leading items and editorials

A response to the challenge. Last week LWN called for a free software response to Microsoft's .NET and HailStorm initiatives that went beyond mere copying of Microsoft's design. In response to our challenge, the community has rallied and announced two initiatives in this area. The Free Software Foundation has put out a press release announcing its support for both projects. We are gratified that our challenge was received in this way.

What...? You say all that was happening anyway? And, besides, nobody made it through our editorial? OK, maybe so...

Anyway, as stated, there are two independent projects which have announced their existence over the last week, plus one other which has not put out any formal announcements so far. They differ significantly in their scope and goals; we'll have a look at all three.

Ximian's Mono project came out with an announcement of its existence on July 9. Of the two projects, Mono is less ambitious at the design level - it has set itself the task of reproducing a number of Microsoft-designed components that facilitate the development of .NET applications. In particular, Mono plans to produce:

• A compiler for the C# language which produces "Common Language Runtime" (CLR) bytecodes. Interestingly, this compiler will not be based on the gcc backend.

• A reimplementation of the Microsoft class libraries that work with the CLR.

• A "Common Language Infrastructure" virtual machine which will make the whole thing work.

This project probably needs to happen, but there are a couple of immediate concerns that come up. One is that Microsoft is being allowed to set the agenda; Mono is playing the "catch up" game creating free implementations of systems designed by others. It helps that Microsoft has submitted the relevant specifications for standards approval, but, in the end, it would not be surprising to see the company "embrace and extend" its own standards.

The other concern is the "shared source" release of some of the .NET code. Those who hack on Mono are going to have to be tremendously careful to avoid any sort of exposure to the .NET code, or the whole project could find itself open to lawsuits. As Eric Raymond put it a week ago, the shared source license is the truly viral one - a look at Microsoft's code can contaminate everything a programmer produces.

Playing the game with Microsoft brings exposure to those sorts of hazards, but somebody probably has to do it. The .NET infrastructure is likely to prove hard to avoid. And, it is said, it even has some nice features. So we wish Ximian luck in its project. (See also: the Mono Project home page).

Then, there's DotGNU. At first, the DotGNU Project looks quite similar to Mono. There is a difference, though: while Mono is concentrating on the low-level plumbing for developers, DotGNU is looking hard at the services that will be implemented on top of that plumbing. Mono, for example, is not concerned with the HailStorm authentication services (other than providing a platform on which they can run); DotGNU, instead, describes HailStorm as "dangerous stuff" and has plans for the implementation of a freer alternative.

DotGNU is not ignoring plumbing, though. Three of the project's highest priorities are:

• The "DotGNU Core Platform," which is essentially a bytecode specification for a new virtual execution environment. Rather than go with the "Common Language" scheme, DotGNU wants to start over.

• The "DotGNU Secure Execution Environment," a virtual machine which runs the core platform bytecodes.

• The "DotGNU Distributed Execution Environment" takes the execution environment into a wide area clustered mode.

This would all be cool stuff to have, but one must question the wisdom of creating yet another virtual machine definition. It seems like substantial amounts of effort could be saved by, for example, starting with the Java virtual machine - for which multiple free implementations already exist. The reason for this decision, according to DotGNU designer Norbert Bollow, is to support the needs of the distributed execution environment. The end result may look much like the Java platform, but some enhancements will be necessary.

Also on DotGNU's list is:

• "DotGNU Virtual Identities," the project's answer to HailStorm. The Virtual Identities scheme will not involve central servers or any single source of personal information;

This is an area where DotGNU could, perhaps, make a real difference. A proper set of open, distributed personal information protocols could, simultaneously, make life easier for users of network services and address the concerns that surround HailStorm and its "Passport" system.

DotGNU faces an uphill battle. The project is new, with no code to show. It's sponsoring organization, FreeDevelopers.net, is a distributed company with utopian ideals but little cash and no track record. And the project is ambitious, to say the least. DotGNU may well get to where it wants to be, but chances are that it will have to find some partners and/or backers first. It will also need to define a revenue model, since FreeDevelopers.net really is supposed to generate paychecks for its developers at some point.

Finally, DotGNU and Mono would be well advised to find effective ways of working together. There is no room for misunderstandings and duplication of effort on a project of this scale. Given the different emphasis that each project has, it should be possible for the two to complement each other, with much better chances of success in the end.

The Island of Project Nareau? A third contender for the next generation of Internet services exists, but, while its architecture and design process is well advanced, it has not yet started issuing press releases. The Nareau Project has set out to develop "an open, user centric, cross platform, Internet3.0 platform," based on standard, existing components. If all goes well, the project will have code to show next month.

Nareau developers do not see the need to create an entire new framework, as is being done by both Mono and DotGNU in their respective ways. Instead, Nareau plans to make use of the many tools and protocols that already exist. Thus, the project will be built on top of components like:

• Server software: Apache, parts of Zope, Jabber, Jakarta
• Client software: Mozilla, Komodo
• Protocols: SOAP, Kerberos

The Nareau vision sees a net with a great many "nodes," which can be anything from a cellular phone to a large server. These nodes communicate directly with each other, generally without the need for central servers, using Jabber to send messages back and forth. These messages will be interpreted by objects living on the recipient systems, possibly intermediated by a set of rules implemented in a middle layer.

A crucial component of Nareau will be the "CloudServer," which handles messaging and object publishing, but which does not concern itself with user interface issues. The Nareau rules system will be implemented in the CloudServer, as will authentication and access in general. It is thus the security gateway for a Nareau node; it is also hoped that it will make rule scripting easy to the point that most users will take advantage of the capability.

The authentication aspect of Nareau is handled through a protocol called Sunshine; it is Nareau's answer to HailStorm. It is, of course, a decentralized system, meaning that no single company can position itself as the sole arbiter of access to network services. Any reasonable system has to be that way, but that does leave each participant on the net with the problem of deciding which identity services it trusts. Finding a secure and simple solution to this problem will be a major and unavoidable challenge for any future identity service.

Implementation of Sunshine is one of Nareau's first priorities.

The interface to Nareau seen by most users will be a separate component called a "SpaceStation." The SpaceStation uses Mozilla to provide a user interface to the net. Since, like any proper, modern system, Nareau is designed around peer-to-peer principles, every SpaceStation will include a CloudServer as well. Thus, the SpaceStation will not only allow users to "browse" the net and control their experience there; it will also allow them to participate and publish their own objects.

The Nareau developers hope to have a first release (implementing a calendaring system) available for release at JabberCon in August, with a more complete release sometime around the end of the year. Until then, the project appears to be operating in a cathedral mode, with no downloads or public mailing lists available.

The Nareau developers are hoping, eventually, to make money from the project, through the sales of consulting services, and, perhaps, proprietary components (though the base system will be released under the GPL). There may also be an "enterprise version" of the CloudServer subsystem. Even there, the project is talking about a "source available commercial license" - just don't call it "shared source."

Inside this LWN.net weekly edition:

• Security: NAI gets DARPA funding, bugs in dip, OpenSSL, OpenSSH, lmail, tetex, tripwire, xdm, xloadimage, Oracle8i.
• Kernel: Piggyback tarballs; the challenge of 64-bit DMA.
• Distributions: Red Hat DMA issue, PowerPC options.
• On the Desktop: Windows on Linux, units clarification and KDE 2.2Beta1
• Development: BlueBox distributed computing, BusyBox 0.52, Samba 2.2.1, TMDA anti-spam for qmail, GNU Medical Record Project
• Commerce: BRU and TOLIS group; Mitel Networks acquires e-smith; device driver book updated.
• History: KDE/GNOME flamewars, gaming platforms.
• Letters: LSB and Debian; .NET; IPFilter license.

This Week's LWN was brought to you by:

• Jonathan Corbet, Executive Editor
• Elizabeth O. Coolbaugh, Managing Editor
• Michael J. Hammel, Senior Editor

Next: Security