[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[DotGNU Announcement]This Year in DotGNU 2002
|
From: |
Peter Minten |
|
Subject: |
[DotGNU Announcement]This Year in DotGNU 2002 |
|
Date: |
Tue, 31 Dec 2002 19:19:02 +0100 |
######################################################################
# #
# This Year in DotGNU 2002 #
# #
# reporting on the state of DotGNU #
# #
# #
# "made it work, now making it work better" #
# -- from The Rhys Principle #
# #
######################################################################
**********************************************************************
* *
* Foreword *
* *
* by Peter Minten *
* *
**********************************************************************
2002 has been a year of maturation for DotGNU. Old plans were replaced
with new plans, old project with new projects and in a sense old
people with new people.
The year also carried some nasty surprises. One of the biggest problems
was (and still) is lack of developers. The other big problem was lack
of code. For the architecture projects the ground work of
specification writing had to be done first before any code could be
written, luckily the specs are in the final phase and coding work is
expected to begin soon.
But despite the slowdown created by these problems there were was a
cause for celebration. The Portable.NET project reached it's most
important milestone, the compiler can now compile the baselib removing
dependency on the Microsoft C# compiler.
In the fall the organization of DotGNU was reorganized. Working Groups
were created to support cooperation between similar projects. The
leaders of all the Working Groups come together in the DotGNU Working
Group which effectively acts like a cabinet for DotGNU. Each Working
Group will explain it's goals later in this text. The role of the
Steering Committee was scaled down a bit to that of high court. The SC
still acts as the highest power in DotGNU, but it doesn't set out the
course anymore.
Last but not least the focus of DotGNU is beginning to shift from
providing as much compatibility with .NET as possible to building a
webservice supporting system which is only compatible with .NET where
absolutely needed. The DotGNU system will be a bridge which
applications can use to communicate with other applications regardless
of where those applications run, in what language they are written,
etc.
That's about what happened in the second year of DotGNU. The rest of
this message contains some background info, information about the
various active projects, explanation on the individual Working Groups,
a Developer of the Year section, a who-is-who list and developer
testimonials.
----------------------------------------------------------------------
------------------------- BACKGROUND INFO ---------------------------
----------------------------------------------------------------------
**********************************************************************
* *
* Webservices - what's the mystery? *
* *
* by Peter Minten *
* *
**********************************************************************
Webservices, it's a buzzword in the software industry, MS best bet and
the core piece of the next generation internet. But still who really
understands what they are?
Webservices are a hype, the expectations people have of them are
simply too high to be justified. One of the reasons for this is that
not many people can describe what they actually are, without using
marketing terms like 'The Next Big Thing'.
So it's time for some education from somebody who thinks he knows what
he's talking about. First of all let's look at the official DotGNU
definition of webservices:
<quote from DotGNU FAQ>
1.05 How do you define "webservice"?
"Webservices" are any services that are offered on the web
(regardless of what technology is used to provide them).
In order to turn this statement into an actual definition,
these explanations need to be added:
a) With "service" we mean not only that some functionality is
provided, but that there should also be some description of
this functionality, namely how the service should be used and
what it provides.
b) With saying that the service is "offered on the web" we mean
that it's offered over a computer network (e.g. the internet
or an intranet) via standard protocols, i.e. protocols that
are open, widely published, and freely available for anyone
to implement.
It is sometimes useful to distinguish between "webservice
components" which are meant to be used by other webservices, and
"webservice applications" which are meant to be used by humans
more directly. Both "webservice components" and "webservice
applications" are "webservices" as defined above.
<end quote>
Let's translate this into clear English. Webservices are things that
use the web to communicate with other things. They provide
functionality (they do something) and also tell other things what they
do and how they should be used (what input they need).
Webservices use standard protocols for communication, note that this
is not obvious, it's perfectly possible that a group of people decide
to use secret patented protocols for their 'webservices'.
The definition also makes a difference between webservice components
(which are meant to be used by other applications) and webservice
applications (which are meant to be used by humans). There can be a
third form however, that communicates with both other applications and
humans. I recommend calling this form hybrid webservices. Note that I
don't talk about webservice components being used only by other
webservices because they can also be used by non-webservices.
So far for the pure definition stuff. Now what's the cool part
everybody is talking about?
The cool thing about webservices is that when you link them together
you could get a giant complex network of computing where the most
impossible things become possible without writing code for it. Now to
pop the bubble: this is not new, this is what the inventors of UNIX
had in mind too when they created pipes and standard streams.
The only new part is that a lot of important organizations are now
trying to put up protocols to solve old problems with communication
between applications. If they are successful (have to see that first
to believe it) all webservices can understand eachother.
But that doesn't automatically mean that communication between
webservices will be easy, since every webservice will be a little
different from other webservices in the details. These little
differences will become big differences as time goes by. At the same
time people will try to preserve interoperability. Various standards
will emerge and split the world of webservices.
This may sound like a doomsday scenario, but it's already taking
place. Just look at the multi-platform bytecode systems that form the
foundation of webservice platforms. You have IL from Microsoft there,
Java from Sun and Parrotcode from the Parrot developers (note that
DotGNU will support all major bytecodes). Don't think that in the end
one bytecode will win the market, MS and Sun are software super powers
that will create a stable undecided situation between their bytecodes,
and Parrotcode is Free Software with the support of a very large
community (Parrotcode is the bytecode of Perl and in the future
probably of Python and Ruby too).
The last topic I'm going to talk about is the user interface. The
'new' part of webservices is that they run on another computer and
communicate with the user using mostly a graphical user interface
without automatically needed a browser (though webservices can use a
browser, take Phpgroupware for example). Ever heard of X? X could
create user interfaces on a workstation while running on a server
since more than a decade ago.
Now, to give a clear answer to the central question of this text
(Webservices, what's the mystery?): what mystery?
**********************************************************************
* *
* Interoperability is what we do *
* *
* by Peter Minten *
* *
**********************************************************************
DotGNU is often accused of helping Microsoft with .NET, because we
support IL and happen to work in the same area of the software
universe. This is not fair however since (besides a lot of other
things) we don't only support IL, we (theoretically) support almost
all languages.
If you don't know it yet: .NET can not support all languages, it
cannot even support most of the popular languages. The reason for this
is the Common Type System used in .NET . The CTS is a set of classes
which all CLI (Common Language Interface, the specification that
governs .NET compilers, interpreters, languages, etc) compatible
languages must understand.
The problem with CTS is that many languages don't support it. To
support CTS a language has to be redefined at the base level to
support CTS data types and classes. A change of the data types of a
language changes the language as a whole causing incompatibility with
programs written for earlier versions of the language. Imagine the
problems when you'd redefine the Ruby fixnum (which can be infinitely
big) to a 32 bits integer.
That kind of problem is exactly the reason why only MS controlled
languages are used in .NET, MS can't change the data types of Java,
besides probably getting a lot of legal troubles with Sun there would
be at least 2 compilers that each compile a different version of the
language. Those problems don't exist with Visual Basic however since
the users of that language are at MS mercy. Of course the solution to
the incompatibility problem would be to create a new language designed
for the CTS. Enter C#.
Because all languages used in .NET have to be designed for the CTS,
existing languages which are going to be .NET compatible have to be
drastically modified. Some might call this progress, I call it
assimilation of languages.
DotGNU does not use a common type system as standard. Instead of
making languages compatible at the language design level we create a
compatibility layer at the webservice level. In other words, we make
languages understand eachother regardless of how their integers look.
This makes it possible that languages cooperate without turning into
another. Where MS assimilates, we cooperate.
For example when you have a webservice written in Ruby that
communicates with a webservice written in C. The Ruby webservice sends
a request to the C webservice to do something with some very large
numbers. When the webservice system gets to command from the Ruby
webservice to send the request it first checks if the data Ruby
delivers can fit into the data type which the C webservice wants, if
not an error is generated, else the Ruby data is nicely wrapped into
the standard format used to send data over the network. At the other
side the data is converted from standard format into C format and
passed to the C webservice.
Whether you want to write a webservice in C, C++, Perl, Python, Ruby,
C#, Java or another language, DotGNU will support it.
----------------------------------------------------------------------
----------------------------- PROJECTS -------------------------------
----------------------------------------------------------------------
**********************************************************************
* *
* Portable.NET *
* *
* by Peter Minten *
* *
**********************************************************************
Excerpt from the Portable.NET README (written by the project leader,
Rhys Weatherley):
<excerpt>
The goal of this project is to build a suite of Free Software tools
to build and execute .NET applications, including a C# compiler,
assembler, disassembler, and runtime engine. The initial target
platform is GNU/Linux, with other platforms to follow in the future.
<end excerpt>
It's a whole while back since that part of the Portable.NET README was
written. Today pnet (as we DotGNU folks refer to it) supports a
variety of GNU compatible platforms like Cygwin (UNIX emulation engine
for Windows) and MacOS X. The project is also not restricted anymore
to C#, a C compiler is being build. In the futue we will see even more
languages supported thanks to the plugin architecture of the compiler,
but for now the focus is on C#.
Pnet is currently approaching the 0.5.0 release with an working and
pretty complete C# compiler, runtime engine and base library.
Rhys said a year ago: "A year ago there was nothing, and now there is
something." For this year I'd like to say: "A year ago there was
something and now that something works."
**********************************************************************
* *
* DotGNU Execution Enviroment *
* *
* by Chris Smith *
* *
**********************************************************************
Put simply, the DotGNU Execution Environment is the core architectural
component that provides the functionality of accepting, validating and
satisfying web service requests.
The DGEE integrates the components on the web service execution path
into a unified application.
Such components would be network servers such as a web server, runtime
engines such as portable.net, and security and authentication servers.
In its basic form the DGEE allows the installation and removal of web
services within the repository, accepts XML-RPC requests for these web
services and generates browsable documentation for these web services
in HTML and XML form.
Installing a web service is extremely simple. You write your web
service, embedding within it any meta-information required to expose
callable methods, and then compile it. You then generate a web service
definition file from the compiled web service through a simple tool.
Both the compiled web service and definition files are then copied
into the DGEE repository. From this point forward your web service
methods will be visible via the online documentation system and via
XML-RPC.
The DGEE is extended by projects such as the SEE and VRS. These too
are execution environments and share the DGEE architecture at heart,
however they introduce the concept of distributed execution,
distributed storage and distinct ownership of web services.
These enhancements are achieved by replacing functional modules of the
basic DGEE with more elaborate versions, such that the web service
repository becomes encrypted and distributed in the case of the VRS,
or web service requests are forwarded on to another server if not
available locally in the case of the SEE.
The DGEE itself is really nothing more than an architecture model that
both the VRS and SEE inherit. By doing so they are able to share
design efforts, code and protocols.
That said, the DGEE is a fully functional system that implements the
core architecture described above. It may be used whenever the
complexity of the SEE or VRS is not required; and as a working model
for the development of extension projects.
**********************************************************************
* *
* Secure Execution Environment *
* *
* by Stephen Compall *
* *
**********************************************************************
The "Network SEE" project, code-named `antares', provides a stable,
multi-user, cross-platform, cross-language, multi-Virtual Machine,
minimally configured environment for writing responsive, trusted
network applications that can cooperate with each other over multiple
network transports chosen by their users.
That was a mouthful! The antares source tree has existed since June
2002; however, real work didn't start until the beginning of October,
when a new architecture description was written, Network SEE v2 [1].
Now, antares has a home in Savannah CVS [2], and developers are
looking at how various aspects of the SEE can be combined with VRS in
a common codebase, the DGEE.
Now that I've used all those buzzwords, I'll note why I think they
apply.
stable: Does a stable kernel crash when it runs out of memory? No,
but many applications considered stable choose to do so when they run
out of memory. This is unacceptable for the SEE.
SEE uses a multiprocess model with IPC between the various aspects of
its operation. When one dies, it doesn't take down the entire system,
and can be restarted by a guardian. Also, each network service runs
in a separate process (though not each connection), further preventing
a service from harming the SEE or fellow services. This is necessary
for multiple users....
Finally, the SEE doesn't try to do anything that would be better done
elsewhere, such as sandboxing services. That's better done by the
VMs.
multi-user: We're not about to extend the old "God, root, what's the
difference?" adage. Users can add their own services and network
transports. These are run at the users' privileges, of course,
another benefit of the multi-process model. Addition and removal can
be done at runtime.
cross-platform: The system is targeted at GNU systems primarily, with
BSD and MSWindows following. The codebase is designed with an aim at
adding more generally useful platform-dependent code to the GNU Common
C++ library. [3]
cross-language, multi-Virtual Machine: As VMs run in separate
processes, no common extension API need be adhered to; the VM
interaction runs only as far as OS-level VM startup. Provided that
the language and/or VM, or libraries, provide the basic facilities
(such as I/O and XML support) needed for SEE interaction, the service
can handle what is necessary.
minimally configured: Instead of name=val configuration files, we use
"config trees" that can be managed from your preferred file and
directory editor. The presence of a service executable file in the
right place provides all the information SEE needs to run it.
responsive: As the service guardian allows a single service process to
manage multiple requests at once, a simple responsiveness test can
tell the guardian whether or not it needs to start up another copy to
share the load.
trusted: Besides the sandboxing capabilities of VMs, the SEE also
contains a Virtual Identities system to identify the creator of a
service and to allow automated or manual decisions on whether software
is "trustworthy".
network applications: SEE supports client/server and P2P network
models. It can also manage installation of services and clients,
making even first-time service as easy as visiting a web site.
multiple network transports: The simple generalization we get from
pushing network transports into separate processes gives us great
power. Services and clients don't have to know what transport they
operate over; thus, the SEEs and users can choose. New transports can
be added and removed at runtime, so it is possible for a service to
one day operate over a transport that didn't even exist at the time of
its writing.
cooperative: The main defining difference between webservices and
network applications in general (for me) is that webservices cooperate
over a single network transport, whereas traditional network apps each
must stake out their own territory (i.e., a network port number).
[1] Network SEE architecture v2 was greatly inspired by my readings of
GNU Hurd architecture documents at the time, particularly the benefits
brought about by running the kernel as separate aspects in user-space,
increasing stability and allowing users to add their own kernel
modules without root access. See
http://csserver.evansville.edu/~sc87/see-arch.txt for the latest
version.
[2] CVSROOT=:pserver:address@hidden:/cvsroot/dotgnu-see,
module antares. Project page is
https://savannah.gnu.org/projects/dotgnu-see
[3] http://www.gnu.org/software/commonc++/
**********************************************************************
* *
* address@hidden *
* *
* by Mario D. Santana *
* *
**********************************************************************
MACS is the Modular Access Control System. It acts as a sort of plexer
for different security mechanisms, allowing several independent and
incompatible authentication, authorization, and user profiling
back-ends to be used as one multi-faceted system. This scheme allows
for centralized management of decentralized user stores, to the point
that the individual user stores need not be aware of MACS. See
http://macs.sf.net/ for more.
MACS is being developed and licensed under the GPL by Mario D. Santana
and Blake Mitchell, under the auspices of Medley Software Corporation.
Medley aims to sell installation, development and support services
around MACS. In the last year, MACS has come a long way, maturing in
its design and implementation. By year's end, 0.7 should be released --
the project's first beta.
FrePort is a scheme to give users total control over their personal
information, where it's stored, and who may access it, with as little
inconvenience to the user as possible. John Le'Brecage has led the
development of this project.
The FrePort project lost much of its code in a catastrophe a while
back. Because of this, the coding phase needs to fairly begin anew.
The union of these projects is address@hidden It promises to deliver
secure, private, distributed and convenient online identity management
capability to DotGNU. And it will improve the fit of your shoes.
(Really.)
**********************************************************************
* *
* DotGNU Forum System *
* *
* by Peter Minten *
* *
**********************************************************************
The DotGNU Forum System or simply Forum is a multi-user simultaneous
editing supporting system with an internal document web. That way too
complicated definition basically comes down to the following:
* Forum allows multiple users to work at a single document with
real-time updating of changes.
* Forum allows multiple users to communicate with each other while
editing.
* Forum allows documents to refer to other documents.
Working with Forum will be an experience of integrated communication
and work over large distances (if you'd build a large enough sender it
will work across the galaxy, you'd get a pretty high ping though
:-). An example:
In a normal situation you work alone on a document and send it to your
colleagues after some time. Since you are miles away from your
colleagues you'd probably use email, FTP or CVS to share the
document. To coordinate efforts you'd hold chat meetings using IRC or
an Instant Messenger. At such meetings you will get pointed to
resources on the intranet of the company. You will read those
resources and make notes on them which will be discussed at the next
chat meeting.
A pretty nice system one would say, but it can be improved:
In a normal Forum situation you work on a document, at the same time
your colleagues will have the document loaded too and all changes one
of you makes appear immediately on the screens of the others. While
editing you will chat with your colleagues about what changes have to
be made. Since the meeting is done at the same time as the work time
is saved. At a certain moment a colleague points you and the others to
resources in the forum you work in (a forum is basically an
overfeatured container for documents). You all go to the resource and
while reading discuss it.
That's basically how Forum will work when it's done. But that's a
still long way to go.
----------------------------------------------------------------------
--------------------------- WORKING GROUPS ---------------------------
----------------------------------------------------------------------
**********************************************************************
* *
* DotGNU *
* *
* by Peter Minten *
* *
**********************************************************************
The DotGNU Working Group (DG WG) is perhaps the most important the
most important WG of all. It's the central counsel that steers DotGNU
in the right direction. In the past this was the task of the Steering
Committee (SC), but it was handed over to the DotGNU Working Group to
reduce the load on the SC.
The DotGNU Working Group consists of seven members, who are also the
Working Group leaders of the seven smaller working groups. These
members decide on a democratic basis about plans for DotGNU. It's up
to the developers however to go with these plans or not.
At the moment the DotGNU Working Group may seem like too much
management, but in the future when DotGNU grows larger it will be
badly needed to guard the project against fragmentation.
But even at the moment the DotGNU Working Group has a positive impact
on DotGNU by discussing plans that transcend the individual working
groups (like a plan for authorization that requires support from the
architecture people).
**********************************************************************
* *
* Foundation Code *
* *
* by Peter Minten *
* *
**********************************************************************
The Foundation Code Working Group coordinates efforts of the compilers
and base library project in DotGNU. At the moment there isn't much to
do for this working group since there is only one active project in
it's area: Portable.NET. But it already has a leader: Andrew Mitchell.
**********************************************************************
* *
* Authorization *
* *
* by Peter Minten *
* *
**********************************************************************
The Authorization Working Group coordinates the development of the
DotGNU Virtual Identity systems. It's currently lead by Mario D. Santana.
**********************************************************************
* *
* Architecture *
* *
* by Peter Minten *
* *
**********************************************************************
The Architecture Working Group designs and implements the DotGNU
Execution Enviroment (DGEE). It's lead by Chris Smith.
**********************************************************************
* *
* Public Relations *
* *
* by Gopal V. *
* *
**********************************************************************
The DotGNU Public Relations working group is a small body of
developers who have taken up the responsibility of delivering the
project to the end users. After all, knowing is half the doing. In the
last year, this working group has been able to put out some very fine
announcements about DotGNU.
This working group is also a policy working group which decides on the
public policy of the project. In short, we say what needs to be said.
Also this includes avoiding possible controversial statements by the
project members representing the project teams. Various articles
appearing on news sites like slashdot, gnu-friends and newsforge have
squeezed out of this deceptively small door of this working group.
The Meet-a-thon was initially organized as part of the PR strategy
and became an integral part of public interaction for the projects.
Also the weekly IRC meetings have brought about a new level of
communication between the DotGNU developers around the world.
To conclude, this year has kept the PR team real busy, and we're glad
about that too !.
**********************************************************************
* *
* Philosophy *
* *
* by Peter Minten *
* *
**********************************************************************
The Philosophy Working Group is the guardian of Free Software
philosophy within DotGNU. It warns whenever dangerous compromises are
being made. It also maintains the DotGNU Manifesto, a document
describing what DotGNU is and why we work on it.
**********************************************************************
* *
* Webservices *
* *
* by Peter Minten *
* *
**********************************************************************
This working group is not active at the moment. In the future it will
support the webservice projects of DotGNU.
**********************************************************************
* *
* Business *
* *
* by Peter Minten *
* *
**********************************************************************
This working group is not active at the moment. In the future it will
try to set up a DotGNU cooperation to get payment to the developers of
DotGNU.
----------------------------------------------------------------------
------------------------------- PEOPLE -------------------------------
----------------------------------------------------------------------
**********************************************************************
* *
* Developer of the Year *
* *
* by Gopal V. and Peter Minten *
* *
**********************************************************************
Peter Minten writes:
And the winner is ... Rhys Weatherley, leader, guru and premier coder
of the Portable.NET project. History has shown one man can make a
difference. But when I look at what Rhys has done I'm tempted to
believe he's more than just 1 man. Can you imagine one man designing a
program and coding it with 5000 lines a week while still producing
almost perfect code? Well, Rhys is one of this kind.
--
Gopal V. writes:
In early 2001 there was a new storm brewing the .NET tea[1] cup and
don't blame the weather folks, blame the Weatherly. Yeah, I'm talking
about Rhys -5000-line-per-week- Weatherly. He is a code demon
disguised as a mild mannered RSI sufferer. Affectionately known as Mr
FFOD[2], he has churned out about half a million lines of code for
DotGNU. Rhys is the all in all of Southern Storm[3], Pty and the
general life blood of the Portable.Net project.
This guy is absolutely 100% dynamite , he's almost religious about
proper design, great coding and absolutely rolls over any bug
.... and guess what ?, writes regression tests ! .. In short he's the
"Perfect" software developer.
It's been a pleasure to work with his code and his special tools like
the TreeCC . I would never have dreamed about compilers (maybe just a
wee bit) otherwise. The C# compiler is amazingly fast and even I have
been unable to mess it up beyond repair. The runtime engine is well
documented with an excellent verifier on top of it. And it's fast on
any platform as well.
The long and short of it is "Rhys is this guy, y'know ".
----
[1] considering the fact that tea is as good a substitute to jav*cough*
coffee, I consider the pun acceptable.
[2] FFOD - Flying Fingers Of Death (on the keyboard , of course)
[3] "Australia" : "Southern", "Weather"ly : "Storm"..
**********************************************************************
* *
* Who is who in DotGNU *
* *
* by Peter Minten *
* *
**********************************************************************
Here is a list of the project leaders of active projects, Working
Group leaders and active Steering Committee members (sorted
alphabetically on family name):
Norbert Bollow (nb)
* Steering Commitee member
* Co-founder of DotGNU
Stephen Compall (S11001001)
* Network SEE project leader
Barry Fitzgerald (fitzix)
* Steering Commitee member
* Co-founder of DotGNU
Bill Lance (nickname unknown to me)
* VRS project leader
Peter Minten (silvernerd)
* DotGNU Working Group chairman
* Philosophy Working Group leader
* Forum project leader
Andrew Mitchell (ajmitch)
* Foundation Code Working Group leader
* DotGNU-Libs project leader
* Portable.NET developer
Chris Smith (cds)
* Architecture Working Group leader
* DGEE project leader
* VRS developer
Gopal V. (t3rmin4t0r)
* Public Relations Working Group leader
* Portable.NET lead developer and premier bughunter
* DotGNU-Libs project leader
Rhys Weatherley (rhysw)
* Portable.NET project leader
* Steering Committee member
**********************************************************************
* *
* Developer testimonials *
* *
* by various people *
* *
**********************************************************************
Peter Minten
When I looked at the DotGNU website (almost exactly a year ago)
I knew this was a project to keep an eye on. These guys actually
had the courage to go into direct competition with the biggest
software firm in the world on a key area for the future.
Like David threatening Goliath with a hard little rock named
Software Freedom they looked (and still look) Microsoft in the
eye and said "We will stop you".
Let's face it, there has never been a project as ambitious as
DotGNU since the GNU project. But if we don't let ambitions turn
into greed and stay on the Right Path to Software Freedom I'm
sure we will succeed.
Gopal V
One could almost say that I came into DotGNU more by accident
than by design. I was almost pushed in by one of the DotGNU
SC member , Arun, to start hacking around the new kid on the
block -- Portable.Net. Looking back across the last 1 year or
so of my involvement, I've learned a lot and did a few things
as well. In fact, I've learned more out of Rhys's code than
out of most textbooks.
We've come a long way in the last year and the last quarter has been
almost explosive in development. It has been an uphill climb , but
looking back it was all worth it. The last weeks of October 2002 were
the toughest of all. But well , all's well that ends well :-)
Watch out world, here we come !.
Stephen Compall
I find that the development environments available today are
inadequate. It's too hard to write portable applications. It's too
hard to write stable network services. It's too hard to distribute
your software in an easy-to-run format. I came here to help build
what's been called for by Barry Fitzgerald: the Best Dam*ed
Development Environment Ever. And I hope, in some small way, I can
help do that.
______________________________________________________________________
This Year in DotGNU 2002
All texts are Copyright (C) 2002 by their authors.
Compilation Copyright (C) 2002 Peter Minten
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1 or
any later version published by the Free Software Foundation, with the
invariant sections being the developer testimonials.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [DotGNU Announcement]This Year in DotGNU 2002,
Peter Minten <=